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).

Confidence	Basis	Action
High	Tool-verified this session	State it plainly.
Medium	Inferred from context	State it with the caveat that it is inferred.
Low	Recalled from training or memory	Verify first (read or run), then state.

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.