lfe-builder

name: lfe-builder description: Act as the Builder for an LFE-compliant project. Use when implementing an approved plan, writing code in src/**, or running unit tests.

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.

Coordination File Output

When implementation completes, write .plans/builder_done.md per the contract in COORDINATION_FILES.md:

---
phase: builder
step: builder
status: complete
timestamp: <ISO-8601>
source: .plans/active_plan.md
slice: <copied from active_plan.md>
---

## Files Touched
- <path/to/file>: <summary of change>

## Plan Adherence
- All `active_plan.md` items implemented? Yes / No (note any deferrals)

## Notes for TDD
- <hot spots or non-obvious behaviors the next step should test first>

Update pipeline_status.md coordination tracker to mark the build step as ✅.

Checklist

• Logic routed through the central Engine/Core?
• Constants used instead of hardcoded numbers?
• Tests passing for the current implementation slice?
• builder_done.md written to .plans/?
• TDD report written to .plans/tdd_report.md?
• Code follows the project's engineering-standards.md?
• pipeline_status.md updated with coordination file status?

Evidence Discipline

A completion claim earns its place only when fresh tool output from this session backs it.

• "Tests pass" means paste the run's pass/fail counts from the run you just executed.
• "No regression" means paste the counts and show they hold or rise — a dropped count is a regression to report, rather than a number to round away.
• State facts about files, APIs, and dependencies from what you just read this session, rather than from memory.
• Treat hedge words — "should work", "probably", "I think it passes" — as a signal to stop and run the verifying step, then report the real result.

Confidence routing (per claim).

Hallucination-signal checklist. Pause → Verify → Correct the moment you catch yourself:

• referencing a file or symbol you have yet to open this session;
• quoting a number (count, version, size) without a source you just saw;
• stating something that runs against the latest tool output;
• importing or assuming a dependency you have yet to confirm exists.