lfe-plan-critique

name: lfe-plan-critique description: Run a 5-lens pre-build critique of the approved active plan before the Builder starts. Acts as the Architect persona, read-only on src/. Writes .plans/plan_critique.md. Use immediately after Brain approves active_plan.md.

LFE Plan Critique — Pre-Build 5-Lens Review

Position in Pipeline

Phase: 1.5 (between Architect plan approval and Builder start)
Persona: Architect (read-only — no src/ write access)
Trigger: Automatically after Brain approves active_plan.md — before /lfe-builder is invoked
Next Step: /lfe-builder (on PASS) or /lfe-architect revision loop (on BLOCK)

Mission

Stress-test the approved plan from five angles before a single line of code is written. Catch ambiguous acceptance criteria, untestable requirements, domain boundary violations, structural impact, and cross-edit incoherence before they become bugs in src/. The five lenses are judgment calls; a mechanical pre-pass (Step 1.5) first surfaces the objective, checkable defects into Lens 2 (glob reach, line-count and existence-check antipatterns) and Lens 5 (orphan-word candidates), so the judgment lenses reason over verified facts rather than guesses.

Hard Rules

Zero Code Writes: This skill operates on .plans/ and .docs/ only — src/ stays untouched.
5-Lens Sequential: Run all five lenses in order, every time — even when an earlier lens passed cleanly. Run the mechanical pre-pass (Step 1.5) first, so Lens 2 and Lens 5 reason over its findings.
Single Output File: All findings aggregate into one plan_critique.md — no per-lens files.
Verdict is Decisive: A single BLOCK finding stops the Builder. WARN requires an explicit, file-recorded Brain confirmation before Builder starts (see Step 7 — brain_confirmation frontmatter field).
Domain Library Is Truth: All domain boundary and architectural judgments must cite a specific .docs/ file and line, not general knowledge.
Revision Counter (file-based): The revision: field in plan_critique.md frontmatter is the physical substrate for the 2-revision limit (GOVERNANCE Cycle Limits). On every run, read any existing plan_critique.md first to determine the current revision number. On a 2nd BLOCK, halt and present Brain triage instead of looping back. This rule exists because the file is overwritten each run — without the counter, the limit would be conversation-only and lost on crash.

Workflow

Step 0: Counter Check (must run first)

Before loading any other context, check whether .plans/plan_critique.md already exists for the current slice:

File does not exist → this is Revision 1. Continue to Step 1.
File exists — read its frontmatter:
- verdict: PASS or verdict: WARN with brain_confirmation set → the gate is already open; this skill should not have been invoked. Halt and instruct the Brain to proceed to /lfe-builder.
- verdict: WARN with brain_confirmation: null → Brain has not yet confirmed; re-presenting the existing WARN is correct. Skip to Step 7 (Branch on Verdict) — re-present rather than re-running the lenses.
- verdict: BLOCK and revision: 1 → the Architect has revised active_plan.md and is re-running. This is Revision 2. Continue to Step 1.
- verdict: BLOCK and revision: 2 → the 2-revision limit is exhausted. Halt immediately — present the Brain with three triage options instead of re-running the lenses (per LOOP_ARCHITECTURE.md Scenario 1.4):
  - A — Revert to PRD: loop back to /lfe-to-issues from 02_prd.md.
  - B — Accept WARN and proceed: Brain explicitly downgrades the BLOCK to a WARN and authorises Builder. If chosen, update plan_critique.md frontmatter: verdict: WARN, brain_confirmation: <ISO-8601>. Set Active Persona: Builder.
  - C — Abort mission: wipe .plans/ execution files; mission cancelled.

Record the determined revision number — it must appear in the frontmatter of the file you eventually write.

Step 1: Load Context

Read in this order:

.plans/active_plan.md — the plan under review
.plans/02_prd.md — the PRD (acceptance criteria source)
.plans/03_slices.md — slice boundaries and definition of done
.docs/domain/ — domain rules and boundaries
.docs/architecture/ (if present) — architectural constraints

Step 1.5: Run the Mechanical Pre-Pass

Before the judgment lenses, scan active_plan.md for four objective, mechanically-checkable defect classes. This is reasoning, not tooling — read the plan's acceptance criteria and verification commands and reason over them directly; run no scripts. Carry each finding into the lens noted.

glob-count → Lens 2: for every acceptance criterion that asserts a count over a glob, resolve the glob against the repository, report the files it actually reaches, and flag any stated count that contradicts that reach.
test-path → Lens 2: flag any existence check that iterates a directory's children and tests derived paths instead of testing the target path directly — it silently tests the wrong paths and can false-negative on correct substrate.
line-count → Lens 2: flag any acceptance criterion that pins an exact or narrow line count; content renders single- vs multi-line, so a tight assertion false-positives on a correct substrate.
orphan-word → Lens 5: enumerate the orphan-prone words (unchanged, now, still, previously, no longer, was always) in text the plan preserves, as high-recall candidates. The pre-pass only lists them; Lens 5 decides whether each still reads correctly after the edit.

Record the results in the ## Mechanical Pre-Pass Findings (Step 1.5) section of the output; the consuming lens must explicitly adjudicate each one — confirm it as a finding or dismiss it with a reason.

Step 2: Lens 1 — Acceptance Criteria Scrutiny

For every acceptance criterion listed in active_plan.md:

Is it falsifiable? (Can you write a test that fails when it's broken?)
Is it unambiguous? (Would two engineers agree on what "done" means?)
Is it traceable to the PRD? (Every AC must map to a requirement in 02_prd.md)

Flag any AC that is vague, unmeasurable, or absent from the PRD.

For slices that create, edit, or archive structured documentation, additionally check each AC against the doc-edit / archive-move AC-design patterns the Architect's Plan-Composition Discipline enumerates (section-name conformance, cross-reference semantic-inversion anchoring, byte-identity sidecar fixtures, section-boundary extraction caveats, cross-file scope symmetry, edit-mechanism ACs, archive-move ACs). A doc-slice AC that omits the applicable pattern is a WARN — the downstream verification will likely escape the defect class that pattern guards.

Step 3: Lens 2 — Test Feasibility

Review the Verification Strategy section of active_plan.md:

Can each listed test be realistically written (no hidden infrastructure gaps)?
Does the test strategy avoid mock-explosion (more mocks than real behaviour)?
Are side effects (file I/O, network, DB, time) explicitly addressed?
Is the test pyramid reasonable (unit/integration/e2e balance)?

Flag any test idea that requires unavailable tooling, excessive mocking, or no clear assertion path.

Consume the Step 1.5 pre-pass here. Fold in its glob-count, test-path, and line-count findings: a glob whose resolved reach contradicts a stated count is a WARN; an existence check that iterates a directory's children instead of testing the path directly is a WARN; an exact or narrow line-count AC is a WARN (recommend a widened tolerance band). Sanity-check each resolved glob's reach against the plan's intent.

Step 4: Lens 3 — Domain Alignment

Cross-reference the implementation approach against domain documentation:

Does the plan respect domain boundaries in .docs/domain/?
Does the plan introduce any business logic not documented in the Library?
Does the plan rename, restructure, or redefine any documented concept?

Any undocumented business logic introduced by the plan is a BLOCK — it violates Logic Sovereignty. Cite the specific .docs/ file where the boundary is defined.

Step 5: Lens 4 — Structural Impact

Assess the plan's effect on existing architecture:

Does the plan introduce coupling between modules that the architecture keeps separate?
Does the plan duplicate logic that already exists (identified via Step-by-Step Implementation section)?
Does the plan require changes to shared interfaces or contracts that other slices depend on?
Does the plan's scope creep beyond the current slice boundary in 03_slices.md?

Flag any structural drift from established architecture. Cite .docs/architecture/ if present.

Step 5.5: Lens 5 — Coherence Simulation

Mentally execute the plan's edits and check that the surrounding, preserved text still reads correctly afterward. This lens catches the cross-edit incoherence the other four miss — text that referred to something an edit removes or changes elsewhere. Two scans:

Word-level (adjudicate the Step 1.5 orphan-word candidates): for each orphan-prone word the pre-pass flagged in preserved text — unchanged, now, still, previously, no longer, was always — ask: does it still make sense after the edit, or does it now dangle (e.g. "the doc still references the old row" when the edit deletes that row; "unchanged" next to something the plan changes)? The pre-pass lists high-recall candidates; you adjudicate — most are fine, but each must be checked, not skipped. A genuine dangling reference is a WARN.
Section-level: when an edit replaces a subsection, re-read the parent section's intro/framing paragraph — does it still accurately characterize all subsections (e.g. an intro saying "these are optional" when the edit made one mandatory; "four" when the edit made it five)? A framing/content mismatch is a WARN.

This lens answers the failure class where an edit's blast radius leaves stale references behind. Dogfood it on the plan's own diff.

Step 6: Write `plan_critique.md`

---
phase: architect
step: plan_critique
status: complete
timestamp: <ISO-8601>
source: .plans/active_plan.md
slice: <copied from active_plan.md>
verdict: PASS | WARN | BLOCK
revision: 1 | 2                        # from Step 0 counter check
brain_confirmation: <ISO-8601 | null>   # null on first write; set by Step 7 when Brain confirms a WARN
---

Body structure:

## Verdict: PASS | WARN | BLOCK

## Lens 1 — Acceptance Criteria Scrutiny
- <Finding or "All criteria are falsifiable and traceable.">

## Lens 2 — Test Feasibility
- <Finding or "Test strategy is realistic and complete.">

## Lens 3 — Domain Alignment
- <Finding or "Plan stays within documented domain boundaries.">

## Lens 4 — Structural Impact
- <Finding or "No architectural drift detected.">

## Lens 5 — Coherence Simulation
- <Finding (dangling reference / framing mismatch) or "Edits leave surrounding text coherent; no orphaned references.">

## Mechanical Pre-Pass Findings (Step 1.5)
- <Summary of the pre-pass findings and how each was adjudicated, or "Clean.">

## Recommended Actions
- <Specific change to active_plan.md needed before Builder starts, or "None — proceed.">

Step 7: Branch on Verdict

PASS → Notify Brain ("Plan critique passed — Builder may proceed."). Mark plan_critique ✅ in pipeline_status.md. Set Active Persona: Builder. Leave brain_confirmation: null in the file (PASS does not require explicit confirmation).
WARN → Present findings to Brain. Brain decides: accept and proceed, or loop back to Architect.
- If Brain confirms: re-write plan_critique.md with the same body but update frontmatter brain_confirmation: <ISO-8601>. This is the file-based signal the Builder's Step 1 gate parses; conversational confirmation is not sufficient. Set Active Persona: Builder.
- If Brain rejects: loop back to Architect (Step 4) for plan revision. The next /lfe-plan-critique run will see this file as verdict: WARN, brain_confirmation: null (Step 0 will re-present rather than re-run lenses; if Brain wants a fresh critique on the revised plan, the Architect should delete the existing plan_critique.md so Step 0 treats it as Revision 1 of a re-scoped plan — document this in the plan revision notes).
BLOCK → Loop back to Architect. Architect revises active_plan.md to address the finding(s). Re-run /lfe-plan-critique. Step 0 reads the existing file to detect this is Revision 2; on a 2nd BLOCK, Step 0 halts and presents Brain triage rather than re-running lenses (per Scenario 1.4 and the Cycle Limits in GOVERNANCE.md).

Checklist

Step 0 counter check executed before any lens work?
Step 1.5 mechanical pre-pass run and its findings carried into Lens 2 + Lens 5?
All five lenses applied sequentially?
Each pre-pass finding explicitly adjudicated (confirmed or dismissed with reason)?
Every BLOCK finding cites a specific .docs/ file?
plan_critique.md written with correct frontmatter (verdict, revision, brain_confirmation)?
WARN path: brain_confirmation left null on initial write; updated to ISO-8601 only after Brain explicitly confirms?
Builder NOT started until verdict: PASS OR (verdict: WARN AND brain_confirmation is non-null)?

name: lfe-plan-critique description: Run a 5-lens pre-build critique of the approved active plan before the Builder starts. Acts as the Architect persona, read-only on src/. Writes .plans/plan_critique.md. Use immediately after Brain approves active_plan.md.