specfuse-loop 0.3.21__tar.gz → 0.3.23__tar.gz

{specfuse_loop-0.3.21/specfuse_loop.egg-info → specfuse_loop-0.3.23}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: specfuse-loop
-Version: 0.3.21
+Version: 0.3.23
 Summary: Local-first executor for the Specfuse Plan + Work Unit gate-cycle methodology.
 Author: Specfuse contributors
 License: Apache-2.0

{specfuse_loop-0.3.21 → specfuse_loop-0.3.23}/pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "setuptools.build_meta"
 
 [project]
 name = "specfuse-loop"
-version = "0.3.21"
+version = "0.3.23"
 description = "Local-first executor for the Specfuse Plan + Work Unit gate-cycle methodology."
 readme = "README.md"
 requires-python = ">=3.10"

specfuse_loop-0.3.23/specfuse/loop/data/VERSION

@@ -0,0 +1 @@
+0.3.23

{specfuse_loop-0.3.21 → specfuse_loop-0.3.23}/specfuse/loop/data/docs/methodology.md

@@ -147,6 +147,18 @@ WU's** frontmatter. The predicate keys on the implementation WUs' cost and
 plan-conformance and cannot see what a close verifies, so a substantive close
 must be marked must-run or its verification is silently skipped (#189).
 
+**Hedged verdicts leave a trail** — a close that ends `met_locally` (everything
+locally verifiable passed; something structurally could not be verified here)
+leaves every terminal surface un-flipped (driver >= 0.3.21: gate
+`awaiting_review`, roadmap row `active`, PLAN.md `active`) AND must produce a
+follow-up record — in the gate review or `RETROSPECTIVE.md` — naming each
+unmet criterion, why it was unverifiable in this environment, and the exact
+re-run condition that would upgrade the verdict to `met`. Without the record,
+`met_locally` is a dead end; with it, the feature is resumable by anyone. See
+`.specfuse/rules/close-discipline.md` §2 for the record's shape and the other
+close-time obligations (fresh oracle re-runs, consumer-visible-change
+enumeration).
+
 **Predicate-version transparency** — every `auto_close_decision` event in
 `events.jsonl` carries a `predicate_version` field (e.g., `predicate_version:
 v1`). Future revisions to the predicate constants increment this version, so

specfuse_loop-0.3.23/specfuse/loop/data/rules/close-discipline.md

@@ -0,0 +1,74 @@
+<!--
+Copyright 2026 Specfuse Contributors
+Licensed under the Apache License, Version 2.0. See LICENSE.
+-->
+
+# Rule: close discipline
+
+Three obligations for `close` and `close-intermediate` WUs, binding at close
+time. Sibling of [`planning-discipline.md`](planning-discipline.md) (plan/arm
+time) and of the per-WU closing obligations in
+[`result-contract.md`](result-contract.md). Provenance: FEAT-2026-0049
+(the specfuse-generator dogfood), where three gates auto-closed at
+`attempts: 0` and the one close forced to run caught two false-`done` WUs and
+an unsatisfiable predicate — 48% of the feature's spend landed after the
+terminal gate had already "auto-closed". A close that only writes prose
+verifies nothing.
+
+A close whose acceptance criteria include ANY obligation below is
+**load-bearing**: the plan author sets `auto_close_disabled: true` in that
+WU's frontmatter so the auto-close predicate cannot optimize it away (#189).
+
+## 1. Oracles re-run fresh
+
+The close re-runs every oracle the feature's acceptance criteria name — the
+full test command(s), plus any compile/execution gates — fresh, in this
+session, exit codes read directly. Never inherit a producing WU's
+self-report: `done` is a claim, the re-run is the verification. When the
+feature's criteria assert on generated artifacts, regenerate into a clean
+output directory before asserting — stale output satisfies any assertion.
+
+> **Provenance.** A WU reported `done` while its source was untouched and its
+> oracle never ran; the driver-side produces-vs-diff guard now refuses that
+> pass (specfuse-loop >= 0.3.21), but only the close's own fresh re-run
+> catches the composite: all WUs individually green while the feature-level
+> oracle fails.
+
+## 2. Hedged-verdict follow-up record
+
+On `met_locally`, the close must produce a named record — in the gate review
+or `RETROSPECTIVE.md` — with one entry per unmet criterion:
+
+- the criterion, verbatim;
+- why it is unverifiable in this environment;
+- the exact re-run condition that would upgrade the verdict to `met`.
+
+The driver (>= 0.3.21) already guarantees the surfaces stay un-flipped on a
+hedged verdict (gate `awaiting_review`, roadmap `active`, PLAN `active`);
+this record is the other half: without it, `met_locally` is a dead end —
+no artifact says what would make it `met`, and the honest hedged verdict
+degrades into a polite synonym for "unknown".
+
+## 3. Consumer-visible contract changes enumerated, human-acknowledged
+
+The close enumerates every consumer-visible addition, removal, or rename the
+feature makes across ALL its producing WUs — API surface, generated models,
+published schemas, CLI flags, whatever contract consumers depend on — and
+blocks on explicit human acknowledgment of the list. A feature with no such
+changes writes exactly: `n/a — no consumer-visible contract change` (do not
+fabricate an empty enumeration; the n/a line is the reviewed claim).
+
+A close carrying this obligation is always load-bearing
+(`auto_close_disabled: true`).
+
+> **Provenance.** A breaking removal from a generated model survived four
+> gates unreviewed because no close surface owned the breaking-change list.
+> A silent breaking change is the most expensive false-done, and it is not
+> language-specific — any generated or published contract has this surface.
+
+## Split with project-local rules
+
+These are the generic obligations. The concrete grounding — which command is
+the oracle, which surface is "the API", project-specific regeneration
+hazards — is per-project and belongs in that project's
+`.specfuse/rules-local/` (never touched by upgrade), referencing this rule.

specfuse_loop-0.3.23/specfuse/loop/data/rules/planning-discipline.md

@@ -0,0 +1,119 @@
+<!--
+Copyright 2026 Specfuse Contributors
+Licensed under the Apache License, Version 2.0. See LICENSE.
+-->
+
+# Rule: planning discipline
+
+Encodes hard-won discipline from feature retrospectives — the checks that, applied
+at design and arming time, would have prevented the most expensive re-plans. Each
+check below is cheap (a grep, a sentence, a table, one local run) and guards a
+failure mode that cost multiple gates when skipped. Provenance is named per check so
+the reasoning survives the rule (the FEAT-2026-0049 / F1–F4 references resolve in the
+retrospective of the specfuse-generator dogfood feature that motivated these checks).
+
+These are **binding at draft, plan-next, and arm time**. A gate armed in violation
+of any check is not ready, regardless of what a WU's frontmatter says.
+
+## 1. Existing-mechanism search — before designing any enforcement or measurement
+
+Before an ADR designs a validation rule, a severity level, an enforcement gate, or a
+measurement, it must first establish that the mechanism does not already exist. The
+ADR is **incomplete** without this section.
+
+- **Grep the inventory.** Search the directory that holds the mechanism's
+  siblings — for a validation rule, the project's rules directory (e.g.
+  `grep -rl <concept> <path/to/validation/rules/>`); for an artifact, the
+  tool's own inventory command (e.g. `<tool> templates`); for any other
+  check, the directory that holds its siblings.
+- **Record the grep command and its verdict** in the ADR — the exact command, and
+  either "no existing mechanism, building new" or "found `<X>`, reusing / extending
+  it". A verdict of "reusing" that then builds new anyway must say why.
+- **Read the javadoc/description of anything the grep surfaces.** A rule that already
+  covers the property may say so in its own words.
+
+> **Provenance (FEAT-2026-0049 / F3).** The feature spent three gates building a
+> `WARNING→ERROR` ladder on a new rule while the enforcement it needed already existed
+> in `RelationshipSymmetryValidationRule` — whose javadoc (F-029, 2026-05-29) literally
+> said the debt "surfaces as a Saturday-night surprise when the inference rule changes."
+> A one-line grep of the rules directory at ADR time would have found it. Cost: two
+> gates and a full pivot.
+
+## 2. Escalation-predicate satisfiability — for any severity flip
+
+Any plan that raises a check to `ERROR`, flips a `WARNING` to blocking, or asserts a
+"zero issues" close predicate must answer, in writing, one question:
+
+> **What does this rule report on a spec/input already in its intended final state?**
+
+If the answer is anything other than **zero**, the predicate is **unsatisfiable** —
+the rule fires on correct inputs, so "zero issues" can never be reached and the
+severity flip forces wrong changes. **Stop and redesign** before arming: fix the rule
+so a correct input reports zero, or route enforcement to a different mechanism (see §1).
+
+> **Provenance (FEAT-2026-0049 / F3).** ADR D3 ("omission = intent — a non-owning
+> reference is declared by omission") and D6 ("`ERROR` when the rule reports zero
+> issues") contradicted each other inside the same document: post-flip, every correct
+> omission still tripped the rule, so "zero" was unreachable. The contradiction was
+> answerable by reading the ADR against itself. Separately, the *shipped* rule
+> false-positived ~35 of 49 on real specs (#821) — a severity flip forcing wrong
+> changes, exactly what this check prevents.
+
+## 3. Flag-scope table — for any WU introducing or flipping a behavior flag
+
+A WU that introduces, gates on, or flips a behavior flag must contain a **flag-scope
+table**: every code path the flag is claimed to affect, marked *gated* / *not gated*,
+with a one-line *why* per row. The arming review checks the feature's headline claim
+("the flip retires inference", "the flag makes X strict") against the table — a claim
+the table does not support is a scope mismatch, and scope mismatches surface gates
+later as defects, not at arming.
+
+| Code path | Gated by flag? | Why |
+|---|---|---|
+| `<path/method>` | yes / no | <one line> |
+
+> **Provenance (FEAT-2026-0049 / F1).** The plan enumerated both inference paths
+> (bare-FK and `$ref`) on day one, but no document ever crossed "which paths does the
+> `explicitRelationshipsOnly` flag gate" against "the flip retires inference." The flag
+> was built FK-path-only, deliberately and correctly — but the mismatch with the
+> headline claim surfaced two gates later (F1), and again as a runtime defect (F4).
+
+## 4. Runtime probe before arming a default/severity flip
+
+A gate whose WUs flip a **default value** or a **severity** may **not** be armed on
+"mechanical, nothing design-open." Before arming, apply the change locally and run the
+**exact command the WU's tests gate will run** (the full oracle, not a subset), and
+paste the resulting failure list into the gate review. The probe is the arming
+evidence; "nothing design-open" without it is a claim, not a fact.
+
+- Run the *full* oracle. A subset hides failures in the paths the change touches that
+  the subset does not exercise.
+- The probe's failure list becomes the WU's enumerated test surface — the WU no longer
+  discovers its own breakage attempt by attempt.
+
+> **Provenance (FEAT-2026-0049 / F4).** Gate 4 was armed on "nothing is design-open"
+> without ever applying the default flip and running the full suite once. The WU then
+> spun three times (~$14) on a real defect that one local run exposed in seconds — and
+> the first two diagnoses were made against a *subset*, missing failures the full suite
+> showed. Contrast: an earlier gate's "measure before drafting" probe (a `WARNING` run
+> over the real specs) worked and correctly shrank the next WU's scope.
+
+## 5. Planning-WU cost floor
+
+`plan-next` and `close` / `close-intermediate` WUs are systematically under-estimated.
+When drafting their `planned_cost_usd`, use a **floor of $5.00** — never the $2–3 that
+"it's just bookkeeping" suggests. A gate `cost_budget_usd` set to the sum of $2–3
+planning estimates is a brake that fires by construction on the first real close.
+
+> **Provenance (FEAT-2026-0049 + LEARNINGS [FEAT-2026-0044]).** Planning/close WUs ran
+> 2.8–5.2× their $2–3 estimates: `plan-next` at $5.90 and $15.65, `close-intermediate`
+> at $5.67, against $2–3 drafts. LEARNINGS `[FEAT-2026-0044]` had already predicted this
+> systematic under-estimation; the floor makes the prediction binding.
+
+## Why these live together
+
+Each is a one-time check that trades a minute at design/arm time against a gate (or
+three) of rework. They share a root: **automation and authors both trust a claim
+without the cheap check that would test it** — a grep not run (§1), a contradiction not
+read (§2), a scope not tabled (§3), a suite not run (§4), an estimate not calibrated
+(§5). State the check, run it, record the verdict. Every plan, every arm.

{specfuse_loop-0.3.21 → specfuse_loop-0.3.23}/specfuse/loop/data/rules/result-contract.md

@@ -107,6 +107,33 @@ blocked_reason: <present only when status is blocked>
 5. **No secret-looking values in evidence.** The RESULT block is read by the driver
    and may be archived. See [`security-boundaries.md`](security-boundaries.md).
 
+## Closing obligations for implementation WUs (FEAT-2026-0049)
+
+Four binding obligations before `status: complete`. Each guards a way a prior WU
+closed on nothing:
+
+1. **Diff against `produces:` first.** Every path in the WU's `produces:` list must
+   show a working-tree change, or the RESULT must justify each unchanged path
+   explicitly: "no change needed because X; here is the evidence the deliverable
+   already holds: `<command + output>`." Silence on an unchanged deliverable is not
+   a valid close. (The driver enforces this mechanically since specfuse-loop 0.3.21
+   — #198, outcome `produces_not_in_diff`; the obligation binds regardless of
+   driver version.)
+2. **A plan-level contradiction is `blocked`, not `complete`.** If mid-WU you find
+   the plan cannot be delivered as written (a decision contradicts another, a
+   deliverable cannot exist), emit `status: blocked` with the finding in
+   `blocked_reason`. Never write the finding into a gate document and close
+   `complete`. `complete` means the deliverables exist; `blocked` means they cannot
+   or should not.
+3. **Every `evidence:` cites an executed command** — its observed exit code/output.
+   Reading source, grepping for a string, or citing another WU's RESULT is not
+   verification. For a validation-rule or severity claim the evidence must include a
+   negative observation (the rule seen rejecting a purpose-built bad input); see
+   [`verification-discipline.md`](verification-discipline.md) §3.
+4. **Analysis without edits is not a silent attempt.** If an attempt produces
+   analysis but no file edits, say so explicitly and end `blocked` (or with a
+   concrete next-edit plan). Do not exhaust the attempt on prose.
+
 ## Why this matters
 
 The driver's trust model is that the RESULT block is an honest claim about what

{specfuse_loop-0.3.21 → specfuse_loop-0.3.23}/specfuse/loop/data/rules/verification-discipline.md

@@ -39,6 +39,12 @@ Two generic meanings, both apply unless the unit narrows the scope:
   decide done. Run them yourself first, in declared order, with full output.
   Generic verifications — "I assume the tests still pass" — are not verifications.
   The commands are the verification.
+- **Observe behavior, not source.** A claim that code does X is verified by making
+  X happen and reading the output — never by reading the source that looks like it
+  does X. A rule read as `ERROR` in source may be gated off and never fire; only a
+  run proves it. For any rule or severity claim, include a **negative observation**:
+  the rule seen rejecting a purpose-built bad input. A rule that fires on nothing
+  passes every test.
 
 **Verification is the exit oracle.** The agent's own report is advisory; done is
 decided by the checks passing, not by the agent's belief. If a check fails you are

specfuse_loop-0.3.23/specfuse/loop/data/rules-local/README.md

@@ -0,0 +1,43 @@
+<!--
+Copyright 2026 Specfuse Contributors
+Licensed under the Apache License, Version 2.0. See LICENSE.
+-->
+
+# Project-authored rules (`rules-local/`)
+
+This directory belongs to **your project**, not to Specfuse. Put binding rules
+here that are specific to this repository — its tools, its paths, its failure
+modes — and that should survive every scaffold upgrade.
+
+**The contract:** `specfuse upgrade` never writes, overwrites, or prunes
+anything in `rules-local/`. That is the opposite of the sibling
+`.specfuse/rules/` directory, which is versioned: upgrades overwrite its files
+with the shipped versions and delete files the shipped scaffold no longer
+carries. A project rule placed in `rules/` will be lost on upgrade; the same
+rule placed here is permanent.
+
+## When to write a rule here vs. upstream
+
+- **Here:** the rule names your project's directories, commands, tools, or
+  conventions ("grep `src/main/java/.../validation/rules/` before designing a
+  rule", "the generator jar's `templates` command lists artifacts"). Upstream
+  would have to genericize away exactly the specifics that make it useful to
+  you.
+- **Upstream (a PR to the scaffold's `rules/`):** the failure mode is
+  project-agnostic and other Specfuse projects would hit it too. Keep the
+  provenance; genericize the examples.
+
+## Wiring a rule into the loop
+
+Rules load via the `@`-references in your `.claude/CLAUDE.md` Specfuse rules
+block. Add one line per rule you author:
+
+```markdown
+@.specfuse/rules-local/<your-rule>.md
+```
+
+Follow the shipped rules' format: one failure mode per rule, the check stated
+imperatively, provenance recorded so the reasoning survives the rule (see
+`.specfuse/rules/planning-discipline.md` for the model).
+
+This README is seeded once and never overwritten — edit it freely.

{specfuse_loop-0.3.21 → specfuse_loop-0.3.23}/specfuse/loop/data/templates/GATE.template.md

@@ -30,6 +30,23 @@ here for human review-and-arm: read the review artifact, accept or edit the draf
 next-gate work units, flip the accepted ones to `pending`, set this gate's status to
 `passed`, and re-run.
 
+## Arming discipline (see `.specfuse/rules/planning-discipline.md`)
+
+Before flipping this gate's next-gate WUs to `pending`:
+
+- **Runtime probe for a default/severity flip (§4).** If any WU in the gate being armed
+  flips a **default value** or a **severity**, it may **not** be armed on "mechanical,
+  nothing design-open." Apply the change locally, run the **exact command the WU's tests
+  gate will run** (the full oracle, not a subset), and paste the failure list into
+  `GATE-NN-REVIEW.md`. That list becomes the WU's enumerated test surface. Arming such a
+  gate without a probe is what makes an implementation WU spin on a defect one local run
+  would have shown.
+- **Flag-scope table (§3).** If a WU introduces or flips a behavior flag, confirm it
+  carries a flag-scope table and that the feature's headline claim matches it.
+- **Escalation-predicate satisfiability (§2).** If a WU raises a check to `ERROR` or
+  asserts a "zero issues" predicate, confirm PLAN.md answered "what does the rule report
+  on a correct input" and that the answer is zero.
+
 ## Reflection notes
 
 <Written by the human at review time. What surprised you, what you changed in the

{specfuse_loop-0.3.21 → specfuse_loop-0.3.23}/specfuse/loop/data/templates/PLAN.template.md

@@ -23,6 +23,32 @@ each WU file owns its own status, and each GATE file owns its gate's status. Det
 only as far as the next gate; plan-next drafts the gate after that from the
 retrospective and lessons.
 
+## Existing-mechanism search (mandatory — see `.specfuse/rules/planning-discipline.md` §1)
+
+Before any ADR or gate designs a validation rule, a severity level, an enforcement
+gate, or a measurement, establish that it does not already exist. **An ADR without
+this section is incomplete.** If this feature designs no such mechanism, write
+exactly `n/a — no enforcement or measurement designed` and stop — do not fabricate
+a grep to fill the section.
+
+- **Grep command run:** `<the exact command — e.g. grep -rl <concept>
+  src/main/java/.../validation/rules/>`
+- **Verdict:** `<"no existing mechanism, building new" | "found <X>, reusing/extending">`
+- **If reusing:** name `<X>` and quote the line of its javadoc/description that
+  confirms it covers the property. If building new despite a hit, say why the hit does
+  not suffice.
+
+## Escalation-predicate satisfiability (mandatory for any severity flip — §2)
+
+If this feature raises a check to `ERROR`, flips a `WARNING` to blocking, or asserts a
+"zero issues" close predicate, answer here:
+
+- **What does the rule report on an input already in its intended final state?**
+  `<answer>`
+- If that answer is **not zero**, the predicate is unsatisfiable — the rule fires on
+  correct inputs. **Redesign before drafting gates:** fix the rule so a correct input
+  reports zero, or route enforcement to the mechanism found in the search above.
+
 ## Task graph
 
 ```yaml

{specfuse_loop-0.3.21 → specfuse_loop-0.3.23}/specfuse/loop/data/templates/WU.template.md

@@ -28,6 +28,10 @@ AUTHOR-SET FIELDS — fill or override these at draft/arm time:
   `xhigh` | `max`. Absent → type-keyed default. `low`/`medium` add a terseness directive.
 - `planned_cost_usd` — OPTIONAL. Estimated USD at draft time. Compared against actual in close
   WU's cost analysis. Lint WARN when absent on active/draft WUs (non-blocking).
+  **Planning-WU cost floor (`.specfuse/rules/planning-discipline.md` §5):** for `plan-next`,
+  `close`, and `close-intermediate` WUs, draft `planned_cost_usd` at a **floor of $5.00** — these
+  run 2.8–5.2× the $2–3 that "it's just bookkeeping" suggests. A gate `cost_budget_usd` set to
+  the sum of $2–3 planning estimates is a brake that fires by construction on the first real close.
 - `generated_surfaces` — OPTIONAL. Paths to generated files this unit's acceptance depends on.
 - `oracle_env` — OPTIONAL. Environment the verifying oracle runs in: `macos_local`,
   `linux_docker`, `github_actions_ci`, or an operator-named string. Lint WARN when AC mentions
@@ -77,6 +81,37 @@ cheapest hollow-pass guard; see `/authoring-work-units` §12 for the contract an
 the carve-outs (refactor, migration, pure-data → explicit `Red-test exempt:
 <reason>` line in the WU body).
 
+**Flag-scope table** (REQUIRED only when this WU introduces, gates on, or flips a
+behavior flag; omit otherwise — see `.specfuse/rules/planning-discipline.md` §3). Every
+code path the flag is claimed to affect, marked gated / not gated, with a one-line why.
+The arming review checks the feature's headline claim ("the flip retires X") against
+this table; a claim the table does not support is a scope mismatch that surfaces as a
+defect gates later.
+
+| Code path | Gated by flag? | Why |
+|---|---|---|
+| `<path/method>` | yes / no | <one line> |
+
+**Close obligations** (REQUIRED only for `close` / `close-intermediate` WUs; omit
+otherwise — see `.specfuse/rules/close-discipline.md`). The close's acceptance
+criteria must cover:
+
+1. **Oracles re-run fresh** (§1): every oracle the feature's criteria name,
+   full command(s), exit codes read directly — never a producing WU's
+   self-report; regenerate into a clean dir before asserting on generated
+   artifacts.
+2. **Hedged follow-up record** (§2): on `met_locally`, a named record per
+   unmet criterion — criterion, why unverifiable here, exact re-run condition
+   that upgrades it to `met`.
+3. **Consumer-visible contract changes** (§3): enumerate every addition /
+   removal / rename across the feature's producing WUs and block on human
+   acknowledgment, or write exactly `n/a — no consumer-visible contract
+   change`.
+
+A close whose criteria include any of these is load-bearing — set
+`auto_close_disabled: true` in this WU's frontmatter so the auto-close
+predicate cannot skip it.
+
 **Do not touch.** Generated directories (`_generated/`, `gen-src/`, or the repo's
 declared equivalent), files owned by other work units in this gate, secrets,
 `.git/`. The driver owns all git operations — you edit files only. See

{specfuse_loop-0.3.21 → specfuse_loop-0.3.23}/specfuse/loop/lint_plan.py

@@ -335,6 +335,56 @@ def check_planned_cost(feature_dir: Path, plan_fm: dict, gates: list) -> None:
             )
 
 
+# Planning-discipline section names (#201, second half). Canonical since the
+# FEAT-2026-0049 planning-discipline drop (PR #211): PLAN.md carries the two
+# ADR sections; each gate file carries the arming-discipline section. Names
+# are shared vocabulary with downstream planning tooling — do not rename here
+# without a template/coordination change.
+PLAN_DISCIPLINE_SECTIONS = (
+    "Existing-mechanism search",
+    "Escalation-predicate satisfiability",
+)
+GATE_ARMING_SECTION = "Arming discipline"
+
+
+def check_planning_sections(
+    feature_dir: Path, plan_fm: dict, plan_body: str, gates: list,
+) -> None:
+    """WARN when the planning-discipline sections are absent (#201).
+
+    Presence-only: the PLAN template's sections allow an explicit n/a line, so
+    content is the arming reviewer's job — this check only catches the section
+    never being written at all (pre-0.3.22 drafts, or a plan-next that dropped
+    it). Sealed features (plan status done/abandoned) are history and skipped.
+    WARN-only, exit code 0, like the rest of the planning-lint family.
+    """
+    if plan_fm.get("status") in ("done", "abandoned"):
+        return
+    for section in PLAN_DISCIPLINE_SECTIONS:
+        if not _slice_section(plan_body, section).strip():
+            print(
+                f"WARN: {feature_dir}/PLAN.md: missing '{section}' section "
+                f"(planning-discipline; write it or an explicit 'n/a' line). "
+                f"See .specfuse/rules/planning-discipline.md."
+            )
+    for g in gates:
+        gate_file = g.get("file")
+        if not gate_file:
+            continue
+        gate_path = feature_dir / gate_file
+        if not gate_path.exists():
+            continue
+        gfm, gbody = read_frontmatter(gate_path)
+        if gfm.get("status") == "passed":
+            continue
+        if not _slice_section(gbody, GATE_ARMING_SECTION).strip():
+            print(
+                f"WARN: {gate_file}: missing '{GATE_ARMING_SECTION}' section "
+                f"(runtime-probe / flag-scope / predicate checks before "
+                f"arming). See .specfuse/rules/planning-discipline.md."
+            )
+
+
 def lint(feature_dir: Path) -> list[str]:
     errs: list[str] = []
     plan = feature_dir / "PLAN.md"
@@ -623,6 +673,8 @@ def lint(feature_dir: Path) -> list[str]:
 
     # Planned-cost capture: WARN on missing/divergent planned_cost_usd fields.
     check_planned_cost(feature_dir, fm, gates)
+    # Planning-discipline section presence (#201): WARN-only.
+    check_planning_sections(feature_dir, fm, body, gates)
 
     # Cross-gate mixed-shape check. Two directions of mix:
     #

{specfuse_loop-0.3.21 → specfuse_loop-0.3.23}/specfuse/loop/loop.py

@@ -64,7 +64,7 @@ SPECFUSE_DIR = Path(".specfuse")
 REPO_ROOT = SPECFUSE_DIR.parent
 FEATURES_DIR = SPECFUSE_DIR / "features"
 VERIFICATION_PATH = SPECFUSE_DIR / "verification.yml"
-DRIVER_VERSION = "0.3.21"
+DRIVER_VERSION = "0.3.23"
 # Oldest scaffold layout this driver can drive. init.sh stamps the scaffold's own
 # version into `.specfuse/VERSION`; check_scaffold_version() fails loud at startup if
 # the consumer's scaffold is older than this, pointing at `specfuse upgrade`. Bump
@@ -1537,15 +1537,20 @@ def gate_budget_usd(gate_file: Path) -> float | None:
 
 
 def gate_spent_usd(plan: dict, gate: dict, feature_dir: Path) -> float:
-    """Sum lifetime cost across the gate's done WUs (closing-sequence included).
+    """Sum lifetime recorded cost across ALL of the gate's WUs.
 
     Reads each WU file's frontmatter from `gate["work_units"]` and adds
     `cost_usd` PLUS `cumulative_cost_usd` (prior re-arm cycles' spend, folded
-    by fold_cumulative_on_rearm — #199) when the WU's status is "done". WUs
-    whose frontmatter omits both — cost tracking off, or the attempt didn't
-    record a cost — contribute 0.0. `plan` is the feature frontmatter dict and
-    is accepted for signature symmetry with the broader gate-budget helpers;
-    the spent total is derived from WU files alone.
+    by fold_cumulative_on_rearm — #199) regardless of WU status (#219):
+    write_cost_to_wu records cost on every outcome — pass, blocked, spinning —
+    so cost on a non-done WU is real spend, not an estimate. The pre-#219
+    done-only filter left a blocked WU's re-arm burn invisible to the budget
+    brake until the WU finally passed (FEAT-2026-0049/WU-06: $30.29 across 9
+    attempts, contributing $0 while blocked). WUs whose frontmatter omits both
+    fields — cost tracking off, never dispatched, or the attempt didn't record
+    a cost — contribute 0.0. `plan` is the feature frontmatter dict and is
+    accepted for signature symmetry with the broader gate-budget helpers; the
+    spent total is derived from WU files alone.
     """
     del plan  # signature symmetry — sum is derived from WU files only
     total = 0.0
@@ -1557,8 +1562,6 @@ def gate_spent_usd(plan: dict, gate: dict, feature_dir: Path) -> float:
         if not wu_path.exists():
             continue
         fm, _ = read_frontmatter(wu_path)
-        if fm.get("status") != "done":
-            continue
         # Lifetime spend, not per-cycle (#199): fold_cumulative_on_rearm
         # moves each prior dispatch cycle's cost into cumulative_cost_usd and
         # zeroes cost_usd, so summing cost_usd alone undercounts every