quality-standards

<mission_control> Ensure all completion claims have fresh verification evidence through systematic quality gates and three-way audits <success_criteria>All claims backed by fresh verification output; all 6 gates pass sequentially</success_criteria> <iron_law> NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE

If you haven't run the verification command in this message, you cannot claim it passes. This is non-negotiable. </iron_law> </mission_control>

Quality Standards

The 6-Phase Gate System

| Phase | Gate | What It Checks | Command Pattern | Evidence Required | | ----- | ------------ | ----------------------------------- | ----------------------------------------------------------- | ----------------- | ---- | ---------- | | 1 | BUILD | Compilation succeeds, deps resolved | npm run build, cargo build, pnpm build, mvn compile | Exit code 0 | | 2 | TYPE | Type safety, no type errors | tsc --noEmit, pyright, go vet, mypy | 0 type errors | | 3 | LINT | Code style, anti-patterns | eslint, pylint, cargo clippy, flake8 | 0 errors/warnings | | 4 | TEST | Tests pass, 80%+ coverage | npm test, pytest --cov, cargo test --coverage | All pass, ≥80% | | 5 | SECURITY | No secrets, console.logs, vulns | Grep diff + npm audit, pip-audit | 0 issues | | 6 | DIFF | Intentional changes, no TODOs | Grep git diff for TODO | FIXME | // | Clean diff |

The Gate Function

BEFORE claiming any status or expressing satisfaction:

1. IDENTIFY: What command proves this claim?
2. RUN: Execute the FULL command (fresh, complete)
3. READ: Full output, check exit code, count failures
4. VERIFY: Does output confirm the claim?
   • If NO: State actual status with evidence
   • If YES: State claim WITH evidence
5. ONLY THEN: Make the claim

Skip any step = lying, not verifying.

Component Validation Checklist

Three-Way Review Pattern

Identify gaps: Intent misalignment, standards violations, completeness issues.

Red Flags - STOP

• Using "should", "probably", "seems to"
• Expressing satisfaction before verification ("Great!", "Perfect!", "Done!")
• About to commit/push without verification
• Trusting agent success reports
• Relying on partial verification
• Thinking "just this once"

Rationalization Prevention

Sequential Enforcement

Gates pass in order. If a gate fails:

1. Stop verification immediately
2. Report failure with details
3. Do not run subsequent gates
4. Provide actionable error messages

When To Apply

ALWAYS before:

• ANY success/completion claims
• ANY expression of satisfaction
• Committing, PR creation, task completion
• Moving to next task
• Delegating to agents

References

---

Genetic Code

This component carries essential Seed System principles for context: fork isolation:

<critical_constraint> MANDATORY: All components MUST be self-contained (zero .claude/rules dependency) MANDATORY: Achieve 80-95% autonomy (0-5 AskUserQuestion rounds per session) MANDATORY: Description MUST use What-When-Not format in third person MANDATORY: No component references another component by name in description MANDATORY: Progressive disclosure - references/ for detailed content MANDATORY: Use XML for control (mission_control, critical_constraint), Markdown for data No exceptions. Portability invariant must be maintained. </critical_constraint>

Delta Standard: Good Component = Expert Knowledge − What Claude Already Knows

Recognition Questions:

• "Would Claude know this without being told?" → Delete (zero delta)
• "Can this work standalone?" → Fix if no (non-self-sufficient)
• "Did I read the actual file, or just see it in grep?" → Verify before claiming

---

<critical_constraint> MANDATORY: Gates pass in sequence—stop on first failure MANDATORY: Each claim requires fresh verification output MANDATORY: Compare Request vs Delivery vs Standards in audits MANDATORY: No completion claims without fresh evidence MANDATORY: Show evidence (output) for every gate check No exceptions. Quality gates exist to prevent substandard work and completion hallucinations. </critical_constraint>

---