Building

Building (Code Generation + TDD)

Iron Law: NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST.

Reference Files

Read only what's needed:

• references/testing-patterns.md — test structure, isolation, naming; load when writing the first test of a cycle or a test feels awkward to structure
• references/test-data-and-mocks.md — mock discipline, test data factories; load when a test needs fixtures/factories or you are about to mock anything
• references/integration-and-live-proof.md — integration test guidance, live verification; load when the slice crosses a service/DB/API boundary or the plan names live proof

Test Process Discipline

• Always use run mode: CI=true npm test, npx vitest run (NOT npx vitest), CI=true npx jest — watch mode never exits, so the agent hangs waiting for a prompt that never returns
• Timeout guard: timeout 60s npx vitest run if uncertain about CI=true
• After TDD cycle: pgrep -f "vitest|jest" || echo "Clean". Kill if found — orphaned watchers hold ports and re-run stale code, producing false greens in later cycles.
• IDE vs CLI truth: If CLI tests pass with exit 0, trust CLI over IDE/LSP errors (stale cache)

RED → GREEN → REFACTOR

RED — Failing Test First

Write one failing test for the current slice. Run it. RED = a behavioral failure ("X is not a function", "expected 3, received undefined") — never a bare exit code.

False-RED guard (CRITICAL): Exit 1 from an import/syntax/collection ERROR is a broken harness, not a RED — fix the harness and re-run. Record the observed failure reason verbatim.

GREEN — Minimal Code

Write the minimum code to pass the test. No extra features, no abstractions for hypothetical futures. No unrelated test breakage. If existing tests break, fix the code not the tests.

REFACTOR — Clean Up

Improve code quality while keeping tests green. If tests fail during refactor, revert — a red test proves it wasn't a refactor, and debugging forward mixes two changes. Re-run after every refactor step.

Safety-Check Guard (MANDATORY): Never simplify away a safety check during refactoring. Safety checks include:

• Input validation at trust boundaries (API entry points, user input, external data)
• Error handling that prevents data loss or corruption
• Security checks (auth, authorization, sanitization)
• Accessibility checks (ARIA, keyboard navigation, semantic HTML)

If a safety check seems unnecessary, verify with a test that proves it's dead code before removing. "Looks redundant" is not sufficient evidence.

Vertical Slicing (CRITICAL)

Build in thin vertical slices that cross all layers: UI → API → logic → data → test. A horizontal slice (all UI, then all API, then all logic — or all tests first, then all implementation) defers integration risk to the end and produces untestable layers. Each slice should be independently verifiable and shippable.

Seam Discipline

One seam, one test, one minimal implementation per cycle. Each test is a tracer bullet that responds to what the last cycle taught you — work one vertical slice at a time.

Test only at pre-agreed seams. A seam is the place where a module's interface lives: where you can observe or alter behavior without editing in that place, which is how a test observes behavior without reaching inside (cc10x:codebase-design defines the term). Before writing any test, know which seam you're testing at. Prefer existing seams to new ones; use the highest seam possible; the fewer seams across the codebase, the better (ideal is one). If the plan provides a ### Test Seams subsection or an Interfaces block, draw your seams from there.

Implementation-coupled anti-pattern. A test is implementation-coupled if it mocks internal collaborators, tests private methods, or verifies through a side channel (querying the database instead of using the interface). The tell: the test breaks when you refactor but behavior hasn't changed. Test through the public interface, not internals.

Record your seams (enforced contract fields). Your Router Contract carries two seam fields:

• TEST_SEAMS: [seam names you actually tested at]
• SEAM_GATE_STATUS: "confirmed" | "proposed" | "disagreed" | "not_applicable"

Set SEAM_GATE_STATUS as follows:

• confirmed — the plan provided test_seams and you used them (TEST_SEAMS non-empty, matching the plan).
• proposed — no plan (direct/no-plan path) OR a legacy plan whose phase omits test_seams; you proposed seams at BUILD_PREFLIGHT (TEST_SEAMS non-empty).
• disagreed — the plan's proposed seam cannot exercise the phase's real risk. Record the disagreement in DECISIONS and either propose a better seam (TEST_SEAMS non-empty with the better seam) or block on genuine ambiguity (STATUS: FAIL, REMEDIATION_REASON: "Ambiguous test surface — no seam exercises the real risk").
• not_applicable — build_scope=trivial; no seam expectation.

The router validates these per build_scope (see the contract-override table). This is the enforced gate — not advisory.

Study Project Patterns First

Before writing code: read 2-3 existing similar components in the repo. Match naming, file structure, export style, test patterns. Follow the project's conventions — don't introduce a new pattern when an existing one works.

LSP before writing: Use LSP to find definitions, references, and type information before writing code that interfaces with existing modules.

Scope Escalation (SCOPE_INCREASES)

If the build scope grows beyond the approved phase — new files not in the plan, new dependencies, API contract changes — emit SCOPE_INCREASES: ["new scope item"] in the contract. The router decides whether to escalate to a full BUILD (with planner + reviewer) or approve the expansion.

Decision Checkpoints (return FAIL when triggered):