Code Production Process
Overview
A six-stage quality-gate pipeline that every non-trivial implementation passes through before
being declared complete. Each stage produces a concrete artifact and must clear a defined gate
before the next begins. The pipeline exists because quality must be enforced by automated gates
inside the agent pipeline, not by human review after the fact. The critic operates in isolated
context to prevent anchoring bias from the implementer's framing.
Trigger Conditions
Triggers when the task will produce >50 lines of source, touch >1 source file, or contains
implementation verbs ("implement", "build", "refactor", "fix bug in ..."). Also triggers
post-dispatch if git diff --stat shows source changes. Does NOT trigger for documentation,
commit messages, config-only changes, or dependency bumps. When in doubt, trigger — a false
positive costs one critic dispatch; a false negative ships broken code.
The Six Stages
| Stage |
Agent |
Artifact |
Gate |
| 1. Research |
research |
Spec citing existing code |
Spec exists, references prior code, NO implementation |
| 2. Architect |
engineer (design mode) |
Interface spec (signatures, types, error model) |
Interface exists, ZERO implementation logic |
| 3. Implement |
engineer |
Source + tests |
Type checker and tests output provided, zero errors |
| 3.5 Tests gate |
PM |
(evaluation) |
Tests pass green — failing tests return to Stage 3, skip critic |
| 4. Critic |
code-critic |
Verdict + finding table |
Verdict returned (see code-review-standards) |
| 5. Security |
security |
Finding list |
Zero CRITICAL/HIGH security findings |
Critic Isolation Rule
The critic dispatch MUST contain only the spec, the interface, the implementation, and the
test output. It MUST NOT contain the engineer's commit message, stated rationale, or any PM
summary of what the engineer did. An engineer who pre-argues ("I chose this because the
alternative is slower") subtly disarms the critic. The critic must encounter the code cold.
Verdict Protocol
- APPROVE (no CRITICAL/HIGH): proceed to security; pass MEDIUM/LOW notes to docs handoff.
- WARN (HIGH, no CRITICAL): proceed to security, but append finding table to handoff and
log it — never silently drop HIGH findings.
- BLOCK (any CRITICAL): halt, surface findings verbatim to the user, await direction. Do
NOT auto-re-dispatch the engineer without user input.
Skip Rules
- Standard path: all 6 stages (required for features, refactors, auth, data models).
- Hotfix path: stages 1-2 skippable only when the bug is confirmed in production, the fix
is <=20 lines across <=2 files, and it does not touch auth/crypto/serialization. Stages 3-5
remain mandatory.
- Docs/config-only path: all stages skipped when
git diff --stat shows no source changes.
1---2name: code-production-process-33description: Production-readiness process checklist covering the code-production pipeline — research, architecture, implementation, tests, critic review, and security gates4license: MIT5---67# Code Production Process89## Overview1011A six-stage quality-gate pipeline that every non-trivial implementation passes through before12being declared complete. Each stage produces a concrete artifact and must clear a defined gate13before the next begins. The pipeline exists because quality must be enforced by automated gates14inside the agent pipeline, not by human review after the fact. The critic operates in isolated15context to prevent anchoring bias from the implementer's framing.1617## Trigger Conditions1819Triggers when the task will produce >50 lines of source, touch >1 source file, or contains20implementation verbs ("implement", "build", "refactor", "fix bug in ..."). Also triggers21post-dispatch if `git diff --stat` shows source changes. Does NOT trigger for documentation,22commit messages, config-only changes, or dependency bumps. When in doubt, trigger — a false23positive costs one critic dispatch; a false negative ships broken code.2425## The Six Stages2627| Stage | Agent | Artifact | Gate |28|-------|-------|----------|------|29| 1. Research | research | Spec citing existing code | Spec exists, references prior code, NO implementation |30| 2. Architect | engineer (design mode) | Interface spec (signatures, types, error model) | Interface exists, ZERO implementation logic |31| 3. Implement | engineer | Source + tests | Type checker and tests output provided, zero errors |32| 3.5 Tests gate | PM | (evaluation) | Tests pass green — failing tests return to Stage 3, skip critic |33| 4. Critic | code-critic | Verdict + finding table | Verdict returned (see `code-review-standards`) |34| 5. Security | security | Finding list | Zero CRITICAL/HIGH security findings |3536## Critic Isolation Rule3738The critic dispatch MUST contain only the spec, the interface, the implementation, and the39test output. It MUST NOT contain the engineer's commit message, stated rationale, or any PM40summary of what the engineer did. An engineer who pre-argues ("I chose this because the41alternative is slower") subtly disarms the critic. The critic must encounter the code cold.4243## Verdict Protocol4445- **APPROVE** (no CRITICAL/HIGH): proceed to security; pass MEDIUM/LOW notes to docs handoff.46- **WARN** (HIGH, no CRITICAL): proceed to security, but append finding table to handoff and47 log it — never silently drop HIGH findings.48- **BLOCK** (any CRITICAL): halt, surface findings verbatim to the user, await direction. Do49 NOT auto-re-dispatch the engineer without user input.5051## Skip Rules5253- **Standard path:** all 6 stages (required for features, refactors, auth, data models).54- **Hotfix path:** stages 1-2 skippable only when the bug is confirmed in production, the fix55 is <=20 lines across <=2 files, and it does not touch auth/crypto/serialization. Stages 3-556 remain mandatory.57- **Docs/config-only path:** all stages skipped when `git diff --stat` shows no source changes.
bobmatnyc