Code Forge

Step 3: Implement Per Component

For each component in planned order, generate code and tests together — tests are not an afterthought.

Every component:

• Prefer the simpler path first. Before writing custom code: does a stdlib function, platform built-in, or existing dependency already cover this? If yes, use it. Can it be expressed in shorter code? Use that. Write custom code only when the simpler options genuinely fall short.
• Place in the correct architecture layer per framework:architecture; dependency direction follows the loaded architecture rules.
• Apply framework:clean-code self-validation during generation. Inline checks: SRP compliance, meaningful naming, low cyclomatic complexity, proper error handling, no magic values, clean function signatures, no dead code, appropriate abstraction level, clear control flow, minimal comments (the code documents itself).
• Write tests using framework:test-quality self-validation.
• Run what you wrote, where the environment allows: execute the component's tests before presenting and include the result in the compliance note. If execution is not available, say so — never imply tests passed when they were only written.

Conditional checks per component:

• Domain layer → apply framework:domain-driven-design self-validation.
• Trust boundary (HTTP handler, external API call, user-input processing, file I/O) → apply framework:secure-coding self-validation.
• Blueprint exists AND Level 4 was confirmed present in Step 1 → verify the component fulfills its L4 (Contracts) specification; flag any deviation from the agreed contract. If the user proceeded without L4 (Check 2 failed), skip this check — there are no contracts to verify against.

Post-generation verification (every component, all review modes):

After generating each component, before presenting it to the user:

1. Run the Self-Validation Checklist from each applicable atom against every function/class in the component. Atoms use imperative STOP-verify language — follow it literally.
2. Run the Active Anti-Pattern Scan from each applicable atom; check every box on the scan list.
3. Violations found → fix before presenting.
4. Judgment calls flagged (see each atom's Ambiguity Signals) → collect them and present via the framework:collaborative-judgment protocol before showing code. Never silently resolve.
5. All checks pass with no flagged judgment calls → present with a brief compliance note ("All clean-code, DDD checks pass") — one line when clean; verbose only when reporting violations and fixes.

Pacing — follow the user's chosen review mode:

• Layer-by-layer: implement all components within a layer, present the full layer (code + tests) for review before starting the next layer.
• Full autonomy: implement all layers continuously; present the complete implementation (all code + tests) at the end, then skip to Step 4.
• Component-by-component: present each component with its tests individually; wait for approval before the next.
• Exception (all modes): a component needs a significant deviation from the plan (new dependency, changed contract, unexpected complexity) → STOP: pause immediately and discuss before continuing, regardless of the chosen review mode.

Step 4: Cross-Component Verification

These checks verify architecture coherence, not code quality (already verified per-component in Step 3). After all components are implemented:

• With blueprint: verify interaction flows match the L3 (Interactions) design — every designed interaction is traceable in the code.
• Dependency direction: apply framework:architecture verification across all components — inter-component dependency direction follows the loaded architecture rules; no layer imports from a layer it is not permitted to depend on.
• Zero Implementation Rule: check that no new components, interactions, or contracts were introduced beyond the Step 2 plan. Something added → flag it — it may be necessary, but it must be a conscious decision, not scope creep.
• Final security scan: apply framework:secure-coding across component boundaries — data flowing between components crosses trust bounds safely.
• Learnings check: if operational learnings were loaded in Step 1, verify that previously-flagged patterns did not recur in this implementation.

Step 5: Enrich Context

Throughout Steps 3-4, use framework:context-anchoring Enrich behavior to keep the living doc current:

• Add key files as created — path + role in the doc's Key Files table (skip a path already listed).
• Capture implementation decisions — library choices, pattern selections, deviations from the blueprint, tradeoffs made, as Decisions Log entries (decision, reasoning, alternatives considered).
• Resolve open questions — when a design-phase question gets answered during implementation, log the answer as a decision entry AND remove the question from the Open Questions list.
• No context doc exists and significant implementation decisions were made → suggest creating one.

Harvest learnings: run framework:learning-harvest Harvest behavior. Session context: "implementation session — code generation from design contracts". Synthesize and propose cross-cutting patterns from this session — implementation gotchas, design-to-reality gaps, library/framework lessons. The user confirms what enters the document. STOP: run this before closing the feature lifecycle below.

Close the feature lifecycle: write status: complete into the context doc frontmatter. STOP: required discrete file edit.

STOP: do not write status to requirement_doc. The requirement's status belongs to whoever manages it — a human, or an external system it may live in. This molecule manages only its own context doc.

After enriching the context doc, recommend review:

"Implementation complete. Recommend running /review on the generated code before considering the feature done — it provides an independent quality assessment against the same atom standards, catches issues the generator may be blind to, and captures learnings for future sessions."