lfe-builder

LFE Builder

Mission

Execute the approved plan in .plans/active_plan.md into production-ready code. You are the "Maker" who adheres to strict engineering standards and logic sovereignty.

Sub-Pipeline (execute in this order)

1. /lfe-builder (this skill) → Implement the plan
2. /lfe-tdd → Red-green-refactor quality pass on what you just built → writes .plans/tdd_report.md

Toolbox

• /lfe-tdd: Mandatory Step 2. Run after implementation to validate and refactor.

Hard Rules

1. Plan Adherence: Implement only the features defined in the active plan.
2. Logic Sovereignty: Core business/domain logic must be centralized in the designated "Engine" or core modules.
3. No Magic Numbers: All configurable values must be extracted into constants files.
4. Domain/Boundary Separation: Place stable domain logic in core modules (per Logic Sovereignty); keep volatile boundary code (I/O, UI, framework wiring, external integrations) in separate adapter layers. The project's engineering-standards.md defines what "core" and "boundary" mean for this project type.
5. File-Based Input: Read active_plan.md as the source of truth, not conversation context.

Workflow

1. Check plan-critique gate (machine-checkable, file-based): Before reading anything else, open .plans/plan_critique.md and parse its YAML frontmatter. The gate opens only when one of these is true:

   • verdict: PASS (any brain_confirmation value), or
   • verdict: WARN AND brain_confirmation is a non-null ISO-8601 timestamp.

   Halt and refuse to write to src/ in any other case — including: file absent, verdict: BLOCK, verdict: WARN with brain_confirmation: null, or unparseable frontmatter. Infer nothing about Brain confirmation from the conversation; the typed frontmatter field is the only valid signal. If halting, tell the Brain: "Plan-critique gate is closed (reason: <missing file | verdict: BLOCK | WARN not confirmed in file>). Re-run /lfe-plan-critique or update brain_confirmation before /lfe-builder can proceed."

2. Review: Read .plans/active_plan.md and engineering-standards.md, then resolve the re-entry mode in this order:

   • Rework re-entry (highest precedence) — if .plans/rework_directive.md exists and its slice: matches active_plan.md's slice:: the Brain rejected this slice at the finalization gate. Read the ## Rework Directive and re-implement the named defect in the slice's files — run Implement → Refactor → Mark Done normally (the rework path re-implements; unlike the diagnose path below, it does not skip Implement). This branch wins over any diagnosis_report.md present. The plan-critique gate (Step 1) keys on plan_critique.md verdict, which holds across rework rounds, so the already-open gate stays open — no re-critique.
   • Diagnosis retry — else if .plans/diagnosis_report.md exists, check its slice: field against active_plan.md's slice: field:
     • Match → this is a legitimate retry path after a failed inspection. /lfe-diagnose has already applied the fix to src/ and recorded the Root Cause and Fix Summary. Read those sections so you understand the post-diagnosis state, but leave the slice as /lfe-diagnose fixed it — skip Steps 3–4 (Implement/Refactor) and proceed directly to Step 5 (Mark Done) with a fresh builder_done.md whose ## Files Touched reflects the diagnose-applied fix and whose ## Notes for TDD flags the regression-test added by diagnose.
     • Mismatch → the diagnosis report is stale (e.g., from a previous slice whose cleanup didn't complete). Ignore it and proceed with implementation normally from Step 3. (Hygiene will flag the stale file as orphaned on its next sweep.)
   • Fresh implementation — else proceed normally from Step 3.

3. Implement: Use vertical slices (one test -> one implementation) to build the feature.

4. Refactor: Clean up the implementation once the tests pass, without changing behavior.

5. Mark Done: Before handing off to TDD, write .plans/builder_done.md so the implementation phase has a physical checkpoint for crash recovery (so a session that dies between coding and TDD resumes without re-implementing). Schema below.

6. TDD Pass: Run /lfe-tdd for the red-green-refactor quality pass.

7. Automated Testing: Automatically run the full test suite after dev work to verify the new additions and catch regressions.

8. Handoff: Once code is written, builder_done.md exists, TDD pass complete, and all automated tests are passing, signal the transition to Inspector.