@dzhechkov/skills-feature-adr 1.3.41 → 1.3.42

package/README.md

@@ -347,6 +347,27 @@ gate — not discovered in production.
 
 *\* Extended skills (marked with \*) are only available with `--full-qe-extended`*
 
+### ADR quality gate (Step 3 generates → Step 8 enforces)
+
+Step 3 and Step 8 share an ADR best-practices contract distilled from the
+[architecture-decision-record monograph](https://github.com/architecture-decision-record/architecture-decision-record):
+
+- **Step 3** emits a **MADR-structured** ADR — invariant core (Title/Status/Context/Decision/Consequences),
+  ranked **Decision Drivers**, **Considered Options** (the chosen approach framed as an option alongside the
+  rejected ones, symmetric pros/cons), **Rationale** mapped to drivers, negative consequences + follow-up
+  links + after-action review, a **`## Confirmation`** stanza (method, monitoring, success metric, owner)
+  naming the load-bearing property, and a **`## Links`** traceability block. Template weight is tier-mapped:
+  S/M → Nygard/ITD-lightweight, L/XL → MADR + Confirmation.
+- **Step 8** runs a **13-point ADR fitness checklist** (`qe-code-reviewer`) against every generated ADR and
+  **fails the gate** on any miss — decision-shaped title, controlled-vocabulary Status + reversibility,
+  neutral Context-before-Decision, symmetric options, driver-mapped rationale, concrete/testable decision,
+  negative consequences, traceability links, no placeholder, and **rejects explainer-masquerading-as-ADR**.
+  The **Confirmation→test link is load-bearing**: if the named safety property has no automated test the ADR
+  grades no better than C.
+
+The pipeline **dog-foods** this: a harness test runs the gate against feature-adr's own generated ADR, so a
+Step-3↔Step-8 drift fails CI rather than shipping.
+
 ### The `Model` / `Fable?` columns — read this before swapping models
 
 The `Model` column is the **default recommendation, fully overridable** — the routing rule is

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@dzhechkov/skills-feature-adr",
-  "version": "1.3.41",
+  "version": "1.3.42",
   "description": "Adaptive Feature Development skill pack for Claude Code — 11-step pipeline with Complexity Router (S/M/L/XL), ADR-driven architecture, 15 agentic-qe skills, multi-agent fleet QE. Supports --full-qe, --full-qe-extended, --with-learning, and --knowledge-extractor modes.",
   "bin": {
     "skills-feature-adr": "./bin/cli.js"

package/templates/.claude/skills/feature-adr/SKILL.md

@@ -132,7 +132,7 @@ Step                         | S | M | L | XL | Model  | Agentic QE Skill
 0  Complexity Router         | ✓ | ✓ | ✓ | ✓  | haiku  | —                      |
 1  Requirements              | ✓ | ✓ | ✓ | ✓  | sonnet | —                      |
 2  Research                  | - | - | ✓ | ✓  | sonnet | —                      |
-3  ADR + Shift-Left          | - | ✓ | ✓ | ✓  | opus   | shift-left-testing     |
+3  ADR + Shift-Left          | - | ✓ Nygard/ITD | ✓ MADR+Confirmation | ✓ MADR+Confirmation | opus   | shift-left-testing     |
 3.5 QCSD Ideation Swarm     | - | ✓ | ✓ | ✓  | sonnet | qcsd-ideation-swarm    |
 4  DDD                       | - | - | ✓ | ✓  | opus   | —                      |
 5  Architecture              | - | ✓ | ✓ | ✓  | opus   | —                      |
@@ -205,6 +205,8 @@ Execute protocol
 After Step 8 (or Step 9 for L/XL) completes, verify:
 - All mandatory artifacts exist per tier
 - QE checks passed
+- Every generated ADR passes the Step-8 ADR fitness checklist
+- Every ADR Confirmation load-bearing property has a named automated test/fitness check
 - ADR decisions are traceable to code (L/XL)
 - QCSD quality risks are mitigated (M+)
 - Gap detection loop closed with zero remaining gaps

package/templates/.claude/skills/feature-adr/modules/00-complexity-router.md

@@ -57,7 +57,7 @@ Load `references/complexity-matrix.md` for the full matrix. Summary:
 | 0 Complexity Router | ✓ | ✓ | ✓ | ✓ |
 | 1 Requirements | ✓ light | ✓ | ✓ | ✓ |
 | 2 Research | - | - | ✓ | ✓ |
-| 3 ADR + Shift-Left | - | ✓ (1 ADR) | ✓ (N ADRs) | ✓ (N ADRs) |
+| 3 ADR + Shift-Left | - | ✓ (1 ADR, Nygard/ITD-light) | ✓ (N ADRs, MADR+Confirmation) | ✓ (N ADRs, MADR+Confirmation) |
 | 3.5 QCSD Ideation Swarm | - | ✓ | ✓ | ✓ |
 | 4 DDD | - | - | ✓ | ✓ |
 | 5 Architecture | - | ✓ light | ✓ | ✓ |
@@ -68,6 +68,13 @@ Load `references/complexity-matrix.md` for the full matrix. Summary:
 
 > Steps 3.5 (M+) and 9 (L/XL) are mandatory — skipping them is a BLOCK per the shard Anti-Patterns.
 
+ADR template weight is part of routing:
+- Summary: S/M -> Nygard/ITD-light; L/XL -> MADR+Confirmation.
+- S: normally skip Step 3; if an ADR is explicitly forced, use Nygard as the lightweight fallback.
+- M: use Nygard/ITD-lightweight ADRs with the invariant core plus drivers, options, rationale, consequences, and Confirmation.
+- L/XL: use full MADR structure with an NHS Wales Confirmation stanza for each significant decision.
+- All generated ADRs must keep the invariant core: Title, Status, Context, Decision, Consequences; one decision per ADR.
+
 ### 5. Calculate Time Budget
 
 | Tier | Total Budget | Distribution |

package/templates/.claude/skills/feature-adr/modules/03-adr.md

@@ -1,12 +1,13 @@
 # Step 3: Architecture Decision Records
 
-> Document each significant architectural decision with context, alternatives, and rationale.
+> Document each significant architectural decision with context, rejected options, consequences, and a named verification method before implementation begins.
 
 ## When
 
 M+ tiers. Depth varies:
-- **M:** 1 ADR for the main decision
-- **L/XL:** N ADRs for each significant decision
+- **S:** skipped by default; if explicitly forced, use Nygard as the lightweight fallback.
+- **M:** 1 Nygard/ITD-light ADR for the main decision, with the invariant core plus drivers, options, rationale, consequences, and Confirmation.
+- **L/XL:** N MADR+Confirmation ADRs, one per significant decision.
 
 Can run **in parallel** with Step 2 (Research) for L/XL tiers.
 
@@ -36,94 +37,164 @@ Scan requirements for decision points:
 | Trade-off | "Consistency vs. availability?" |
 
 For M-tier: pick the SINGLE most impactful decision.
-For L/XL: identify ALL decisions, prioritize by impact.
+For L/XL: identify ALL significant decisions, prioritize by architectural impact, and split them into separate ADRs.
 
-### 2. Draft ADR per Decision
+Reject explainer-masquerading-as-ADR: a document that describes a space but makes no concrete decision is not an ADR.
 
-Use template from `references/adr-template.md`:
+### 2. Choose Template Weight
+
+All ADRs must emit the invariant core:
+- Title
+- Status
+- Context
+- Decision
+- Consequences
+
+Template routing:
+- S forced ADR: Nygard fallback.
+- M: Nygard/ITD-light form with drivers, options, rationale, consequences, and Confirmation.
+- L/XL: MADR structure plus an NHS Wales Confirmation stanza.
+
+The chosen template may be short, but it must still satisfy the Step-8 ADR fitness checklist.
+
+### 3. Enforce File Naming
+
+Create ADRs in `features/<slug>/03_adr/` as:
+
+```text
+NNN-{decision-slug}.md
+```
+
+Slug rules:
+- lowercase kebab-case
+- present-tense imperative verb phrase
+- no dates
+- no ticket numbers
+- no camelCase, snake_case, or spaces
+
+Good examples: `001-choose-event-store.md`, `002-enforce-adr-fitness.md`, `003-format-timestamps.md`.
+
+### 4. Draft ADR per Decision
+
+Use `references/adr-template.md`.
+
+Minimum structure:
 
 ```markdown
-# ADR-{NNN}: {Title}
+# ADR-{NNN}: {decision-shaped title}
 
 ## Status
-Proposed | Accepted | Superseded by ADR-{M}
+proposed - Reversible until {condition}; revisit when {trigger}.
 
 ## Context
-What is the issue that we're seeing that is motivating this decision?
+{Neutral problem context written before the decision. State forces and constraints without selling the chosen option.}
 
 ## Decision Drivers
-- {driver 1}
-- {driver 2}
+1. {Driver D1} (weight: high|medium|low)
+2. {Driver D2} (weight: high|medium|low)
 
 ## Considered Options
-1. {Option A} — {1-line summary}
-2. {Option B} — {1-line summary}
-3. {Option C} — {1-line summary}
+### {Option A}
+Pros:
+- {real strength}
+Cons:
+- {real weakness}
+
+### {Option B}
+Pros:
+- {real strength}
+Cons:
+- {real weakness}
 
 ## Decision
-We chose **{Option X}** because...
+We will {concrete choice with exact names, versions, formats, paths, commands, APIs, or conventions}.
+
+## Rationale
+- D1: {why the chosen option satisfies the driver}
+- D2: {why rejected options lost despite their strengths}
 
 ## Consequences
 ### Positive
-- ...
-### Negative
-- ...
-### Risks
-- ...
-```
+- {benefit}
 
-### 3. Evaluate Alternatives
+### Negative / Accepted Downsides
+- {cost or risk} - Mitigation: {mitigation}
 
-For each ADR, evaluate alternatives using a decision matrix:
+### Follow-up ADRs
+- {ADR-NNN or "None required now"} - {why}
 
-| Criterion | Weight | Option A | Option B | Option C |
-|-----------|--------|----------|----------|----------|
-| Simplicity | 3 | ⭐⭐⭐ | ⭐⭐ | ⭐ |
-| Performance | 2 | ⭐⭐ | ⭐⭐⭐ | ⭐⭐ |
-| Maintainability | 3 | ⭐⭐ | ⭐⭐ | ⭐⭐⭐ |
-| Team familiarity | 2 | ⭐⭐⭐ | ⭐ | ⭐⭐ |
+### After-action Review
+- Owner: {person/team}
+- Schedule: {about one month after acceptance, or a concrete date if known}
 
-If decision involves complex trade-offs, load `problem-solver-enhanced` for TRIZ analysis.
+## Confirmation
+- Method: {test, review, demo, audit, or fitness function}
+- Monitoring: {ongoing automated check/audit/training}
+- Success metric: {objective pass/fail or numeric metric}
+- Owner: {responsible person/team}
+- Load-bearing property: {the safety property Step 8 must assert has a test}
+- Required automated check: {test file/name, command, or ArchUnit/ArchUnitTS suggestion}
+```
+
+For L/XL ADRs, add a decision matrix or comparison table after Considered Options. Keep per-option pros/cons symmetric.
 
-### 4. Validate Against Requirements
+### 5. Validate Against Requirements
 
 Each ADR must trace back to specific requirements:
 - Which FR-{N} does this decision support?
-- Does the decision satisfy all relevant NFRs?
-- Does the decision respect constraints?
+- Which NFRs does it satisfy?
+- Which constraints does it respect?
+- Which safety property must be tested because the ADR's Confirmation names it?
+
+### 6. Lifecycle Discipline
+
+- Status vocabulary is controlled: `proposed`, `accepted`, `rejected`, `deprecated`, `superseded`.
+- Status must include a reversibility or revisit clause.
+- Supersession mints a NEW ADR and sets the old ADR to `superseded by ADR-{NNN}`; do not edit accepted/rejected ADR content in place.
+- If a living-document amendment is unavoidable, add a dated "arrived after the decision" note instead of silently rewriting the original reasoning.
 
 ## Anti-Patterns
 
 | Anti-Pattern | Detection | Fix |
 |-------------|-----------|-----|
-| Only one alternative | Less than 2 options considered | Require ≥2 alternatives |
+| Explainer masquerading as ADR | Describes a domain but has no concrete Decision | BLOCK; write a decision-shaped ADR |
+| Only one alternative | Less than 2 options considered | Require chosen plus rejected options |
+| Strawman rejected option | Loser has only cons | Add real strengths and fair trade-offs |
 | No consequences | Missing positive/negative analysis | BLOCK until filled |
-| Decision without context | Why is unclear | Add context section |
-| Premature optimization | Choosing complex option for hypothetical scale | Prefer simpler option |
+| Benefits-only consequences | No accepted downside | Add negative outcomes and mitigations |
+| Decision without context | Why is unclear | Add neutral Context before Decision |
+| Vague decision | "use a modern database" | Name exact product/version/format/path/API |
+| Placeholder text | Template hints or TODOs remain | Remove or fill before checkpoint |
+| Supersession in-place | Existing ADR rewritten | Mint a new ADR and link it |
 
 ## Output
 
 Create `features/<slug>/03_adr/` directory with:
-- `001-{decision-slug}.md` for each ADR
-- Each ADR follows the template
+- `NNN-{decision-slug}.md` for each ADR
+- Each ADR follows the template and satisfies the fitness checklist
 
-Set `{ADR_DECISIONS}` variable with list of decisions.
+Set `{ADR_DECISIONS}` variable with list of decisions and their Confirmation load-bearing properties.
 
 ## Checkpoint Format
 
-```
-═══════════════════════════════════════════════════════
-⏸️ STEP 3/8: ADR Complete
+```text
+=======================================================
+STEP 3/8: ADR Complete
 Tier: {COMPLEXITY_TIER}
 
 {N} architectural decisions documented:
-1. ADR-001: {title} → chose {option}
-2. ADR-002: {title} → chose {option}
-
-• "ок" — proceed
-• "пересмотри ADR-{N}" — reconsider decision
-• "добавь ADR для [topic]" — add new decision
-═══════════════════════════════════════════════════════
+1. ADR-001: {title} -> chose {option}; Confirmation: {method}, {metric}, owner {owner}
+2. ADR-002: {title} -> chose {option}; Confirmation: {method}, {metric}, owner {owner}
+
+Fitness readiness:
+- Invariant core present: PASS|FAIL
+- Concrete/testable decisions: PASS|FAIL
+- Confirmation properties named for Step 8: PASS|FAIL
+
+- "ok" - proceed
+- "revise ADR-{N}" - reconsider decision
+- "add ADR for [topic]" - add new decision
+=======================================================
 ```
 
 ## Shift-Left Validation (after ADR creation)
@@ -136,8 +207,14 @@ After all ADRs are drafted, apply **shift-left-testing** protocol (Level 4: Risk
 
 For each ADR decision, run risk analysis:
 
-```
+```text
 ADR-{NNN}: {Title}
+  Confirmation:
+    Method: {verification method}
+    Monitoring: {ongoing monitoring}
+    Success metric: {metric}
+    Owner: {owner}
+    Load-bearing property: {property}
   Testability Questions:
     1. What happens when {chosen option} fails under load?
     2. How do we handle {alternative failure modes}?
@@ -147,6 +224,8 @@ ADR-{NNN}: {Title}
     Given {precondition from ADR context}
     When {action that exercises the decision}
     Then {expected outcome per ADR consequences}
+  Required Automated Check:
+    {test file/name/command or ArchUnit/ArchUnitTS fitness function}
   Risk Level: LOW | MEDIUM | HIGH
 ```
 
@@ -155,24 +234,35 @@ ADR-{NNN}: {Title}
 | Check | Threshold |
 |-------|-----------|
 | All ADRs have testability questions answered | 100% |
-| BDD scenarios generated for non-trivial decisions | ≥1 per ADR |
+| Each ADR has a Confirmation stanza | 100% |
+| Each Confirmation names method, monitoring, success metric, owner | 100% |
+| Each load-bearing property has a proposed automated check | 100% |
+| BDD scenarios generated for non-trivial decisions | >=1 per ADR |
 | No HIGH risk without mitigation documented | 0 unmitigated |
 
-If any ADR has HIGH risk without mitigation → flag at checkpoint for user decision.
+If any ADR has HIGH risk without mitigation, or a Confirmation property with no proposed automated check, flag at checkpoint for user decision.
 
-### Integration with Step 3.5
+### Integration with Step 3.5 and Step 8
 
 The shift-left validation output feeds directly into Step 3.5 (QCSD Ideation Swarm):
 - BDD scenarios become input for the requirements-validator agent
 - Risk analysis feeds the risk-assessor agent
 - Testability questions inform the quality-criteria-recommender
 
+Step 8 must read the Confirmation stanza and assert that the named load-bearing property has a real automated test or fitness function in the shipped code. For architecture dependency/layering/interface rules, suggest ArchUnit or ArchUnitTS.
+
 ## Quality Gates
 
-- [ ] Every ADR has ≥2 alternatives considered
-- [ ] Every ADR has consequences (positive + negative)
-- [ ] Every ADR traces to requirements
-- [ ] Decision matrix used for non-trivial choices
-- [ ] No premature optimization detected
-- [ ] Shift-left testability check passed for all ADRs
-- [ ] BDD scenarios generated for non-trivial ADRs
+- [ ] Every ADR has the invariant core: Title, Status, Context, Decision, Consequences
+- [ ] Every ADR records exactly one decision
+- [ ] Filename slug is kebab-case, imperative, dateless, and ticketless
+- [ ] Status uses controlled vocabulary plus a reversibility clause
+- [ ] Context is neutral and appears before Decision
+- [ ] Decision drivers are ranked or weighted
+- [ ] Considered options include rejected options with symmetric pros/cons
+- [ ] Rationale maps each point to a driver and explains why losers were rejected
+- [ ] Decision is concrete/testable with exact names/versions/formats/paths/APIs
+- [ ] Consequences include positive and negative outcomes/accepted downsides
+- [ ] Consequences link follow-up ADRs and schedule an after-action review
+- [ ] Confirmation names method, monitoring, success metric, owner, load-bearing property, and required automated check
+- [ ] No placeholder text or generation scaffolding remains

package/templates/.claude/skills/feature-adr/modules/08-qe.md

@@ -129,6 +129,35 @@ Choose review mode based on context:
    - 🟡 **WARNING** — should fix, but not blocking (Ramsay mode: "This is RAW")
    - 🔵 **SUGGESTION** — nice to have improvement
 
+### 3.1 ADR Fitness Checklist Gate (M+)
+
+Before final grading, read every generated ADR in `features/<slug>/03_adr/NNN-*.md`.
+
+Fail the ADR gate for any miss:
+
+| Check | Required Evidence |
+|-------|-------------------|
+| Decision-shaped title | Title names one concrete decision, not a vague topic |
+| One decision per ADR | No bundled independent decisions |
+| Filename discipline | `03_adr/NNN-{decision-slug}.md`; slug is lowercase kebab-case, imperative, dateless, ticketless |
+| Status vocabulary | `proposed`, `accepted`, `rejected`, `deprecated`, or `superseded` |
+| Reversibility clause | Status states when/how to revisit or why it is irreversible |
+| Neutral Context before Decision | Context states problem/forces without advocating the chosen solution |
+| Drivers ranked or weighted | Decision Drivers are explicit and prioritized |
+| Considered Options | Chosen and rejected options are present |
+| Symmetric pros/cons | Each option has real strengths and weaknesses; no strawman loser |
+| Rationale maps to drivers | Every rationale point names the driver it satisfies and why rejected options lost |
+| Concrete/testable Decision | Exact names, versions, formats, paths, commands, APIs, or conventions |
+| Negative consequences | Consequences include accepted downsides/risks, not only benefits |
+| Follow-up discipline | Consequences link follow-up ADRs or state none; after-action review is scheduled |
+| Confirmation stanza | Names verification method, monitoring, success metric, and owner |
+| Confirmation-to-test link | The named load-bearing property has a real automated test/fitness check by file/name |
+| No placeholders | No TODO, template hint text, raw prompt/generation scaffold, or empty tail sections |
+
+Reject explainer-masquerading-as-ADR: if the document describes a problem space or technology landscape but has no concrete `Decision`, record a BLOCKER.
+
+The Confirmation-to-test link is load-bearing. If absent, grade no better than C and record a blocker gap; for architecture dependency/layering/interface rules, recommend an ArchUnit or ArchUnitTS fitness function.
+
 ### 4. Multi-Agent Review Panel (L/XL)
 
 For L/XL features, spawn 3 parallel review agents using brutal-honesty modes:
@@ -150,6 +179,7 @@ After review findings are compiled, run a gap check:
 ITERATION {N}:
   1. Check: Every FR-{N} from requirements → has passing test or verification
   2. Check: Every ADR decision → reflected in code
+  2a. Check: Every ADR Confirmation load-bearing property → has a named automated test/fitness check
   3. Check: Every critical risk from QCSD → has mitigation in code
   4. Check: Every 🔴 BLOCKER → has fix plan
 
@@ -199,6 +229,11 @@ Compile all findings into a structured report:
 ## Review Findings
 {list of findings with severity}
 
+## ADR Fitness Checklist
+| ADR | Fitness | Confirmation Test Evidence | Gaps |
+|-----|---------|----------------------------|------|
+| ADR-001 | PASS/FAIL | {test file/name or missing} | {none or blocker} |
+
 ## Acceptance Criteria
 {FR-N status table}
 

package/templates/.claude/skills/feature-adr/references/adr-template.md

@@ -1,102 +1,158 @@
 # ADR Template
 
-Use this template for every Architecture Decision Record.
+Use this template for every Architecture Decision Record generated by feature-adr.
+
+Template weight:
+- S forced ADR: Nygard fallback.
+- M: Nygard/ITD-light with drivers, options, rationale, consequences, and Confirmation.
+- L/XL: MADR structure plus NHS Wales Confirmation.
+
+Every ADR must keep the invariant core: Title, Status, Context, Decision, Consequences. Record exactly one decision per ADR.
 
 ---
 
 ```markdown
-# ADR-{NNN}: {Short Title of Decision}
+# ADR-{NNN}: {Decision-shaped title}
 
 ## Status
 
-{Proposed | Accepted | Deprecated | Superseded by ADR-{M}}
+proposed - Reversible until {condition}; revisit when {trigger}.
 
-## Date
-
-{YYYY-MM-DD}
+Allowed status values: `proposed`, `accepted`, `rejected`, `deprecated`, `superseded`.
 
 ## Context
 
-{What is the issue that we're seeing that is motivating this decision or change?
-Describe the forces at play — technical, business, political, social.
-Describe the problem space, not the solution.}
+{Neutral problem statement written before the decision. Describe the forces, constraints, requirements, team context, and trade-offs without advocating the chosen option.}
 
 ## Decision Drivers
 
-- {driver 1: e.g., "Team has no experience with technology X"}
-- {driver 2: e.g., "Feature requires sub-100ms latency"}
-- {driver 3: e.g., "Must integrate with existing auth system"}
+1. {Driver D1} (weight: high|medium|low; traces to FR/NFR/constraint)
+2. {Driver D2} (weight: high|medium|low; traces to FR/NFR/constraint)
+3. {Driver D3} (weight: high|medium|low; traces to FR/NFR/constraint)
 
 ## Considered Options
 
-### Option 1: {Name}
+### {Option A}
+
+{Short description.}
 
-{1-2 paragraph description of this option}
+Pros:
+- {Real strength}
+- {Real strength}
 
-- ✅ {Pro 1}
-- ✅ {Pro 2}
-- ❌ {Con 1}
-- ❌ {Con 2}
+Cons:
+- {Real weakness}
+- {Real weakness}
 
-### Option 2: {Name}
+### {Option B}
 
-{1-2 paragraph description}
+{Short description.}
 
-- ✅ {Pro 1}
-- ❌ {Con 1}
+Pros:
+- {Real strength}
+- {Real strength}
 
-### Option 3: {Name} (optional)
+Cons:
+- {Real weakness}
+- {Real weakness}
 
-{1-2 paragraph description}
+### {Option C, optional}
 
-- ✅ {Pro 1}
-- ❌ {Con 1}
+{Short description.}
+
+Pros:
+- {Real strength}
+
+Cons:
+- {Real weakness}
 
 ## Decision Matrix
 
-| Criterion | Weight | Option 1 | Option 2 | Option 3 |
-|-----------|--------|----------|----------|----------|
-| {Criterion 1} | {1-5} | {1-5} | {1-5} | {1-5} |
-| {Criterion 2} | {1-5} | {1-5} | {1-5} | {1-5} |
-| {Criterion 3} | {1-5} | {1-5} | {1-5} | {1-5} |
-| **Weighted Total** | | **{sum}** | **{sum}** | **{sum}** |
+Use for non-trivial M decisions and all L/XL decisions.
+
+| Driver | Weight | Option A | Option B | Option C |
+|--------|--------|----------|----------|----------|
+| D1 | high | {score/rationale} | {score/rationale} | {score/rationale} |
+| D2 | medium | {score/rationale} | {score/rationale} | {score/rationale} |
+| D3 | low | {score/rationale} | {score/rationale} | {score/rationale} |
 
 ## Decision
 
-We chose **{Option N}** because {1-2 sentence rationale linking back to decision drivers}.
+We will {concrete, testable choice with exact names, versions, formats, paths, commands, APIs, or conventions}.
+
+## Rationale
+
+- D1: {Why the chosen option best satisfies this driver.}
+- D2: {Why the chosen option best satisfies this driver.}
+- Rejected {Option B}: {Why it lost despite its real strengths.}
 
 ## Consequences
 
 ### Positive
-- {Positive consequence 1}
-- {Positive consequence 2}
+- {Positive consequence}
+- {Positive consequence}
 
-### Negative
-- {Negative consequence 1 — with mitigation strategy}
+### Negative / Accepted Downsides
+- {Negative consequence or accepted downside} - Mitigation: {mitigation}
+- {Risk with likelihood/impact if relevant} - Mitigation: {mitigation}
 
-### Risks
-- {Risk 1} — Mitigation: {how to mitigate}
-- {Risk 2} — Mitigation: {how to mitigate}
+### Follow-up ADRs
+- {ADR-NNN: title, or "None required now"} - {why}
 
-## Links
+### After-action Review
+- Owner: {person/team}
+- Schedule: {about one month after acceptance, or a concrete date if known}
+- Review question: Did the expected benefits and accepted downsides match reality?
 
-- Requirement: FR-{N}
-- Related: ADR-{M} (if any)
-```
+## Confirmation
 
----
+- Method: {How the decision is verified: automated test, fitness function, review, demo, audit}
+- Monitoring: {How compliance is monitored over time}
+- Success metric: {Objective pass/fail or numeric metric}
+- Owner: {responsible person/team}
+- Load-bearing property: {The safety property Step 8 must assert has a test}
+- Required automated check: {test file/name, command, or ArchUnit/ArchUnitTS suggestion}
 
-## ADR Numbering
+## Links
 
-- Start from 001 for each feature
-- Use kebab-case slugs: `001-choose-database-engine.md`
-- Keep sequential within a feature, no gaps
+- Requirement: FR-{N} / NFR-{N}
+- Related ADRs: {ADR links, typed if relevant: Refines, Supersedes, Superseded by, Follow-up}
+- Evidence: {research, code path, benchmark, external source}
+```
 
-## ADR Quality Checklist
+---
 
-- [ ] At least 2 options considered
-- [ ] Every option has both pros and cons
-- [ ] Decision matrix used for non-trivial decisions
-- [ ] Consequences include both positive AND negative
-- [ ] Risks have mitigation strategies
-- [ ] Links to requirements present
+## ADR Numbering and Slugs
+
+- Start from 001 for each feature.
+- Keep numbers sequential within a feature, no gaps.
+- Use `NNN-{decision-slug}.md`.
+- The slug must be lowercase kebab-case, present-tense imperative, dateless, and ticketless.
+- Good: `001-choose-database-engine.md`, `002-enforce-adr-fitness.md`, `003-format-timestamps.md`.
+- Bad: `001-database.md`, `001-ADR-1234-database.md`, `001-2026-07-08-database.md`.
+
+## ADR Fitness Checklist
+
+- [ ] Title is decision-shaped and records one decision only
+- [ ] Status is one of `proposed`, `accepted`, `rejected`, `deprecated`, `superseded`
+- [ ] Status includes a reversibility or revisit clause
+- [ ] Context is neutral and appears before Decision
+- [ ] Decision drivers are ranked/weighted
+- [ ] Considered options include chosen and rejected options
+- [ ] Every option has symmetric pros and cons
+- [ ] Rationale maps each point to a stated driver
+- [ ] Rationale explains why rejected options lost
+- [ ] Decision is concrete/testable with exact names, versions, formats, paths, commands, APIs, or conventions
+- [ ] Consequences include positive and negative outcomes/accepted downsides
+- [ ] Consequences link follow-up ADRs or explicitly say none
+- [ ] Consequences schedule an after-action review
+- [ ] Confirmation names verification method, monitoring, success metric, and owner
+- [ ] Confirmation names the load-bearing property and required automated check
+- [ ] No placeholder text, raw prompt text, or template hints remain
+- [ ] The document is not an explainer masquerading as an ADR
+
+## Lifecycle
+
+- Supersession mints a new ADR and links it; do not edit accepted/rejected ADR content in place.
+- If an amendment is unavoidable, add a dated note that the information arrived after the decision.
+- Rejected ADRs must record why the option was rejected to avoid re-litigating it.

package/templates/.claude/skills/feature-adr/references/complexity-matrix.md

@@ -64,6 +64,8 @@
 
 ## Step Activation by Tier
 
+ADR template weight: S/M -> Nygard/ITD-light; L/XL -> MADR+Confirmation.
+
 ### Tier S (Score 6-8)
 
 ```
@@ -73,6 +75,7 @@ Skipped: 2, 3, 4, 5
 
 **Step adaptations:**
 - Step 1: 3-5 bullet requirements, no formal document
+- Step 3: skipped by default; if explicitly forced, use Nygard as the lightweight fallback
 - Step 6: Inline in conversation, no separate file
 - Step 8: Smoke tests only — does it compile? Do existing tests pass?
 
@@ -84,7 +87,7 @@ Skipped: 2, 4, 9
 ```
 
 **Step adaptations:**
-- Step 3: Single ADR for the main architectural decision
+- Step 3: Single Nygard/ITD-light ADR for the main architectural decision; keep the invariant core plus drivers, options, rationale, consequences, and Confirmation
 - Step 3.5: QCSD ideation swarm — 3 core agents + GO/CONDITIONAL/NO-GO verdict (mandatory for M+ — skipping is a BLOCK)
 - Step 5: Component diagram only, no full C4
 
@@ -97,7 +100,7 @@ Parallel groups: (2,3) and (4,5); Step 3.5 runs after Step 3, Step 9 after Step
 
 **Step adaptations:**
 - Step 2: Research analogues in codebase and external patterns
-- Step 3: Multiple ADRs for each significant decision
+- Step 3: Multiple MADR+Confirmation ADRs for each significant decision
 - Step 3.5: QCSD ideation swarm — 3-9 parallel agents + GO/CONDITIONAL/NO-GO verdict (mandatory for M+ — skipping is a BLOCK)
 - Step 4: Bounded contexts + ubiquitous language
 - Step 5: Full C4 (Context + Container + Component)
@@ -113,6 +116,7 @@ Parallel groups: (2,3), (4,5 — after 3.5), (7 per module)
 
 **Step adaptations:**
 - All steps at full depth
+- Step 3: Full MADR+Confirmation ADRs; one decision per ADR with typed follow-up links
 - Step 3.5: QCSD ideation swarm — 3-9 parallel agents + GO/CONDITIONAL/NO-GO verdict (mandatory for M+ — skipping is a BLOCK)
 - Step 7: Multiple parallel agents, one per module/domain
 - Step 8: Full QE — unit + integration + e2e + performance + security review

package/templates/.claude/workflows/feature-adr.js

@@ -226,14 +226,46 @@ function modelLabel(opts) {
   return 'session'
 }
 
+// needsLandedBarrier — mirror of harness-core's pure gate (feature-adr-routing.ts). TRUE only when a
+// stage resolved to Codex. A Claude stage is synchronous (artifact on disk when agent() returns), so
+// this is FALSE and the barrier below is never constructed → an all-Claude run, and a Claude-design +
+// Codex-QE run, do ZERO extra work (byte-identical to today).
+function needsLandedBarrier(opts) { return !!(opts && opts.agentType === 'codex:codex-rescue') }
+
+// A Bash one-liner that waits for a Codex OUT-OF-BAND artifact write to LAND: polls up to ~40s until
+// the file exists, is non-empty, AND its size is stable across two reads (write finished). Assumes a
+// fresh feature slug (no stale same-path artifact) — true for a normal /feature-adr run.
+function landedProbeCmd(f) {
+  return 'f="' + f + '"; last=-1; for i in 1 2 3 4 5 6 7 8; do if [ -s "$f" ]; then s=$(wc -c < "$f"); if [ "$s" = "$last" ]; then break; fi; last=$s; fi; sleep 5; done; [ -s "$f" ] && echo "landed=$(wc -c < "$f")" || echo "absent"'
+}
+
+// designStage — run a DESIGN artifact-writing stage with a Codex-landed barrier (Step-7.5 pattern,
+// extended to the design stages). GATED on codex (see needsLandedBarrier): Claude stages run exactly
+// as before (schema-validated, synchronous, zero barrier). For codex we (a) drop the ARTIFACT schema —
+// codex-rescue returns finalMessage text, not StructuredOutput; success is proven by the file landing —
+// (b) add a FOREGROUND hint so the codex runtime blocks until the write completes, (c) poll the
+// artifact, and (d) fall back to a Claude agent if it never lands (never blocks the pipeline).
+async function designStage(promptText, opts, artifactPath) {
+  if (!needsLandedBarrier(opts)) return await agent(promptText, opts)
+  const codexOpts = {}
+  for (const k in opts) if (k !== 'schema') codexOpts[k] = opts[k]
+  const res = await agent(promptText + ' IMPORTANT: run the Codex task in FOREGROUND (synchronous — do NOT pass --background) so this call blocks until the file is fully written to disk.', codexOpts)
+  const probe = await agent('Confirm a Codex OUT-OF-BAND artifact write has LANDED before the next stage reads it. Run EXACTLY this via Bash and return its stdout verbatim, nothing else:\n' + landedProbeCmd(artifactPath), { label: 'design:confirm-landed', phase: 'Design', effort: 'low' })
+  if (res && probe && /landed=/.test(String(probe))) return { wrote: [artifactPath], summary: String(res).slice(0, 300) }
+  log('design artifact did not land on codex (' + artifactPath + ') — falling back to Claude')
+  return await agent(promptText, mergeOpts({ label: (opts.label || 'design') + ':claude-fb', phase: 'Design', schema: ARTIFACT }, {}))
+}
+
 const ROUTER = { type: 'object', additionalProperties: false, required: ['tier', 'activeSteps', 'rationale'], properties: { tier: { type: 'string', enum: ['S', 'M', 'L', 'XL'] }, activeSteps: { type: 'array', items: { type: 'number' } }, rationale: { type: 'string' } } }
 const ARTIFACT = { type: 'object', additionalProperties: false, required: ['wrote', 'summary'], properties: { wrote: { type: 'array', items: { type: 'string' } }, summary: { type: 'string' } } }
 const QE = { type: 'object', additionalProperties: false, required: ['grade', 'gaps', 'codeTestsAdequate', 'docTestsPresent'], properties: { grade: { type: 'string' }, codeTestsAdequate: { type: 'boolean' }, docTestsPresent: { type: 'boolean' }, gaps: { type: 'array', items: { type: 'object', additionalProperties: false, required: ['sev', 'what'], properties: { sev: { type: 'string' }, what: { type: 'string' } } } } } }
+const ADR_TEMPLATE_GUIDE = 'ADR best-practices for Step 3: emit exactly one decision per ADR with the invariant core Title, Status, Context, Decision, Consequences. Template weight is tier-routed: S/M use Nygard/ITD-lightweight form but still include decision drivers, considered options, rationale, consequences, and Confirmation; L/XL use MADR structure plus an NHS Wales Confirmation stanza. Confirmation MUST name verification method, monitoring, success metric, and owner, and its load-bearing safety property MUST be tied to a Step-8 automated test/fitness function. Use status vocabulary proposed/accepted/rejected/deprecated/superseded plus a reversibility clause. Context must be neutral and appear before Decision. Considered Options must include rejected options with symmetric pros/cons. Rationale points must map to stated drivers and explain why losers were rejected. Consequences must include positive and negative outcomes/accepted downsides, follow-up ADR links, an after-action review schedule, and supersession discipline: supersession mints a new ADR and never edits accepted/rejected ADR content in place. Decision must be concrete/testable with exact names, versions, formats, paths, commands, or APIs. Reject explainer-masquerading-as-ADR: a domain overview with no concrete Decision is not an ADR. File names under 03_adr MUST be sequential NNN-{decision-slug}.md with lowercase kebab-case, dateless, ticketless slugs (the auto-001 ADR tracks the feature slug, so the present-tense imperative signal lives in the ADR Title; model-named additional ADRs use imperative slugs). Add a ## Links traceability block (requirements, driving use case, related ADRs) and a one-line provenance note (model-generated, edited for clarity); for a long ADR include a top-of-file table of contents.'
+const ADR_FITNESS_CHECKLIST = 'ADR fitness checklist for Step 8: read every ' + FDIR + '/03_adr/NNN-*.md ADR and fail the QE gate for any miss. Required checks: (1) filename is 03_adr/NNN-{decision-slug}.md where the slug is lowercase kebab-case, imperative, dateless, and ticketless; (2) title is decision-shaped and the ADR records one decision only; (3) Status is non-empty controlled vocabulary proposed/accepted/rejected/deprecated/superseded and includes a reversibility/revisit clause; (4) Context is neutral, problem-first, and appears before Decision; (5) Decision Drivers are stated and ranked/weighted; (6) Considered Options include the chosen and rejected options, each with symmetric pros and cons; (7) Rationale maps each point back to a driver and explains why rejected options lost; (8) Decision is concrete/testable with exact names, versions, formats, paths, commands, or APIs; (9) Consequences include positive and negative outcomes/accepted downsides, follow-up ADR links, and an after-action review schedule; (10) Confirmation names verification method, monitoring, success metric, and owner, then links the load-bearing safety property to an automated test/fitness function; (11) no placeholder text, template hints, raw generation scaffolding, or fake Markdown structure; (12) reject explainer-masquerading-as-ADR: describing a space with no concrete Decision is a blocker; (13) a Related/Links traceability block maps the ADR to its requirements, driving use case, and related ADRs. The ADR Confirmation check is load-bearing: assert the named safety property has a real test by file/name; if absent, grade no better than C and record a blocker gap.'
 
 // Step 0: Router + MANDATORY self-learning recall
 phase('Router')
 await usageProbe('Router')
-const routerPrompt = 'You are Step 0 (Complexity Router) of the /feature-adr pipeline. TWO jobs. (1) MANDATORY SELF-LEARNING RECALL (never skip — run BOTH Bash commands VERBATIM, do not summarize instead of running them): the learned patterns live in the CANONICAL BRAIN store at `' + BRAIN + '` — pin every recall to it. Via your Bash tool run EXACTLY `' + DZ_RECALL('<the key domain terms of this feature>') + '` (and `' + DZ_RECALL('<the key domain terms of this feature>') + ' --all` if narrow) to load relevant LEARNED PATTERNS from the brain. Preserve recalled pattern TEXT, reward, domain, and any visible id in the rationale as a concrete list so Step 8 can compare candidate lessons against it. Then run `dz statusline --fa-record --slug ' + SLUG + ' --step "Step 0 recall" --recalled <count> --mode ' + MODE + ' --project ' + REPO + '`. Summarize the top 3 applicable patterns in the rationale. (2) Classify S/M/L/XL + active steps. Feature: "' + DESC + '". Code: ' + CODE_HINT + '. S=1-3 files (0,1,6,7,8); M=4-10 (0,1,3,3.5,5,6,7,8); L=11-30 (all+9); XL=30+ (full+9). Return {tier, activeSteps, rationale} with the recalled patterns folded into rationale.'
+const routerPrompt = 'You are Step 0 (Complexity Router) of the /feature-adr pipeline. TWO jobs. (1) MANDATORY SELF-LEARNING RECALL (never skip — run BOTH Bash commands VERBATIM, do not summarize instead of running them): the learned patterns live in the CANONICAL BRAIN store at `' + BRAIN + '` — pin every recall to it. Via your Bash tool run EXACTLY `' + DZ_RECALL('<the key domain terms of this feature>') + '` (and `' + DZ_RECALL('<the key domain terms of this feature>') + ' --all` if narrow) to load relevant LEARNED PATTERNS from the brain. Preserve recalled pattern TEXT, reward, domain, and any visible id in the rationale as a concrete list so Step 8 can compare candidate lessons against it. Then run `dz statusline --fa-record --slug ' + SLUG + ' --step "Step 0 recall" --recalled <count> --mode ' + MODE + ' --project ' + REPO + '`. Summarize the top 3 applicable patterns in the rationale. (2) Classify S/M/L/XL + active steps. Feature: "' + DESC + '". Code: ' + CODE_HINT + '. S=1-3 files (0,1,6,7,8; if an ADR is explicitly forced, use Nygard as the lightweight fallback); M=4-10 (0,1,3,3.5,5,6,7,8; Nygard/ITD-light ADR); L=11-30 (all+9; MADR+Confirmation ADRs); XL=30+ (full+9; MADR+Confirmation ADRs). ADR template-weight rule: S/M -> Nygard/ITD-light; L/XL -> MADR + NHS Wales Confirmation, while every generated ADR still carries the invariant core. Return {tier, activeSteps, rationale} with the recalled patterns folded into rationale.'
 const routerOpts = mergeOpts({ label: 'router+recall', phase: 'Router', schema: ROUTER, effort: 'low' }, resolveStageModel('router'))
 modelsUsed.router = modelLabel(routerOpts)
 const router = await agent(routerPrompt, routerOpts)
@@ -265,12 +297,12 @@ modelsUsed.adr = modelLabel(adrOpts)
 modelsUsed.ideation = modelLabel(qcsdOpts)
 modelsUsed.architecture = modelLabel(archOpts)
 modelsUsed.ddd = modelLabel(archOpts)
-designThunks.push(() => agent('Step 1 (Requirements)' + (isLplus ? ' + Step 2 (Research)' : '') + ' of /feature-adr for "' + DESC + '" (tier ' + tier + ', slug ' + SLUG + '). Code: ' + CODE_HINT + '. APPLY these Step-0 recalled LEARNED PATTERNS (fold the applicable ones into requirements/constraints - the loop paying off): ' + LEARNED + '. Write ' + FDIR + '/01_requirements.md (functional + non-functional requirements, acceptance criteria, constraints, and an "Applied learned patterns" note).' + reqExtra + ' Return wrote[] + a 1-line summary.', reqOpts))
+designThunks.push(() => designStage('Step 1 (Requirements)' + (isLplus ? ' + Step 2 (Research)' : '') + ' of /feature-adr for "' + DESC + '" (tier ' + tier + ', slug ' + SLUG + '). Code: ' + CODE_HINT + '. APPLY these Step-0 recalled LEARNED PATTERNS (fold the applicable ones into requirements/constraints - the loop paying off): ' + LEARNED + '. Write ' + FDIR + '/01_requirements.md (functional + non-functional requirements, acceptance criteria, constraints, and an "Applied learned patterns" note).' + reqExtra + ' Return wrote[] + a 1-line summary.', reqOpts, FDIR + '/01_requirements.md'))
 if (isMplus) {
-  designThunks.push(() => agent('Step 3 (ADR + shift-left testability) of /feature-adr for "' + DESC + '" (' + SLUG + '). READ the actual code (' + CODE_HINT + ') to ground it. Write ' + FDIR + '/03_adr/001-' + SLUG + '.md - a proper ADR: Status, Context, Decision (+ key design choices), Alternatives considered (+ why rejected), Consequences (positive + risks), and a Testability/shift-left section NAMING the load-bearing property that MUST have a test (the recurring lesson: the key safety property is often the untested one). Return wrote[] + summary.', adrOpts))
-  designThunks.push(() => agent('Step 3.5 (QCSD ideation swarm - HTSM quality criteria + SFDIPOT risk) of /feature-adr for "' + DESC + '" (' + SLUG + '). Assess quality criteria + product-factors risk. Write ' + FDIR + '/03.5_ideation_report.md with a GO/CONDITIONAL/NO-GO verdict + top quality risks for QE. Return wrote[] + summary.', qcsdOpts))
+  designThunks.push(() => designStage('Step 3 (ADR + shift-left testability) of /feature-adr for "' + DESC + '" (' + SLUG + '). READ the actual code (' + CODE_HINT + ') to ground it. ' + ADR_TEMPLATE_GUIDE + ' Write ' + FDIR + '/03_adr/001-' + SLUG + '.md as a MADR-structured ADR that PASSES the Step-8 ADR fitness checklist (do NOT emit the legacy shape). Emit ALL of these sections, in order: a decision-shaped # Title (present-tense imperative verb — the auto-filename tracks the feature slug, so the IMPERATIVE signal lives in the title); ## Status (proposed/accepted/rejected/deprecated/superseded + a reversibility/revisit clause); ## Context (neutral, problem-first, BEFORE the Decision); ## Decision Drivers (ranked/weighted D1, D2, …); ## Considered Options (frame the CHOSEN approach as one option ALONGSIDE the rejected ones, each with symmetric Pros:/Cons:); ## Decision (concrete/testable — exact names, versions, paths, commands); ## Rationale (map each point to a driver Dn + why the losers lost); ## Consequences (Positive + Negative/Accepted Downsides + Follow-up ADRs + After-action Review with owner + date); a REQUIRED ## Confirmation stanza with Method:, Monitoring:, Success metric:, Owner:, Load-bearing property:, and Required automated check: `<test file>` NAMING the load-bearing property that MUST have a Step-8 test (the recurring lesson: the key safety property is often the untested one); and a ## Links traceability block (requirements, driving use case, related ADRs). Add a one-line provenance note (model-generated, edited for clarity) and, for a long ADR, a top-of-file table of contents. Do NOT use an "Alternatives considered" or "Testability/shift-left" heading in place of Considered Options / Confirmation. When creating ADDITIONAL ADRs, name them 03_adr/NNN-{decision-slug}.md with a lowercase-kebab, present-tense imperative, dateless, ticketless slug. Return wrote[] + summary.', adrOpts, FDIR + '/03_adr/001-' + SLUG + '.md'))
+  designThunks.push(() => designStage('Step 3.5 (QCSD ideation swarm - HTSM quality criteria + SFDIPOT risk) of /feature-adr for "' + DESC + '" (' + SLUG + '). Assess quality criteria + product-factors risk. Write ' + FDIR + '/03.5_ideation_report.md with a GO/CONDITIONAL/NO-GO verdict + top quality risks for QE. Return wrote[] + summary.', qcsdOpts, FDIR + '/03.5_ideation_report.md'))
   const archExtra = isLplus ? ' Also ' + FDIR + '/04_domain_model.md (DDD).' : ''
-  designThunks.push(() => agent((isLplus ? 'Step 4 (DDD) + ' : '') + 'Step 5 (Architecture) of /feature-adr for "' + DESC + '" (' + SLUG + '). READ the code. Write ' + FDIR + '/05_architecture.md (components, data flow, integration points, the emit/merge/wiring shape).' + archExtra + ' Return wrote[] + summary.', archOpts))
+  designThunks.push(() => designStage((isLplus ? 'Step 4 (DDD) + ' : '') + 'Step 5 (Architecture) of /feature-adr for "' + DESC + '" (' + SLUG + '). READ the code. Write ' + FDIR + '/05_architecture.md (components, data flow, integration points, the emit/merge/wiring shape).' + archExtra + ' Return wrote[] + summary.', archOpts, FDIR + '/05_architecture.md'))
 }
 const design = await parallel(designThunks)
 
@@ -289,12 +321,15 @@ let plan = null
 if (planIsCodex) {
   modelsUsed.plan = (planModel.agentType === 'codex:codex-rescue') ? modelLabel(planModel) : ('codex:' + CODEX_MODEL + ':high')
   const codexPlanOpts = mergeOpts({ label: 'plan:codex', phase: 'Plan', agentType: 'codex:codex-rescue' }, planModel.agentType ? planModel : {})
-  const codexPlan = await agent(planPrompt, codexPlanOpts)
-  if (codexPlan) {
+  const codexPlan = await agent(planPrompt + ' IMPORTANT: run the Codex task in FOREGROUND (synchronous — do NOT pass --background) so this call blocks until 06_implementation_plan.md is fully written to disk.', codexPlanOpts)
+  // Codex-landed barrier for the plan artifact: a stub return is NOT proof the file was written
+  // (codex writes out-of-band). Require the artifact to LAND; otherwise fall through to the Claude planner.
+  const planLanded = codexPlan ? await agent('Confirm the Codex plan write has LANDED. Run EXACTLY this via Bash and return its stdout verbatim, nothing else:\n' + landedProbeCmd(FDIR + '/06_implementation_plan.md'), { label: 'plan:confirm-landed', phase: 'Plan', effort: 'low' }) : null
+  if (codexPlan && planLanded && /landed=/.test(String(planLanded))) {
     plan = { wrote: [FDIR + '/06_implementation_plan.md'], summary: String(codexPlan).slice(0, 500), planner: 'codex' }
-    log('Plan: Codex (top model)')
+    log('Plan: Codex (top model) — artifact landed')
   } else {
-    log('Plan: Codex unavailable — falling back to the default planner')
+    log('Plan: Codex plan did not land — falling back to the default planner')
   }
 }
 if (plan === null && planIsCodex) reactiveBelt('Plan')
@@ -358,7 +393,7 @@ if (coderUsed === 'codex' || coderUsed === 'codex-fallback') {
 // Step 8: QE (brutal-honesty, agentic-qe) + MANDATORY teach
 phase('QE')
 await usageProbe('QE')
-const qePrompt = 'Step 8 (QE - brutal-honesty review, agentic-qe) of /feature-adr for "' + DESC + '" (' + SLUG + '). Adversarially review the SHIPPED code (read it): correctness, edge cases, error handling, and the LOAD-BEARING property the ADR named (ASSERT it has a test - the recurring lesson). Grade A/B/C/D honestly. Assess code-test adequacy + doc-test presence. List CONFIRMED gaps with severity. Write ' + FDIR + '/08_qe_report.md. MANDATORY SELF-LEARNING STORE (close the loop, never skip): compare every candidate lesson against the Step-0 recalled LEARNED patterns above. Teach ONLY lessons NOT covered by Step-0 recall. On overlap, run `dz teach --reinforce "<recalled pattern id or exact text>" --project ' + BRAIN + '` instead of minting a near-duplicate; if --reinforce is unavailable, skip the duplicate teach and report `reinforced existing pattern <id>` in the QE report. Store every genuinely new lesson in the CANONICAL BRAIN store at `' + BRAIN + '` so it is NOT lost to a target repo you may have cd`d into. Via Bash run EXACTLY `' + DZ_TEACH('<a durable reusable lesson from this feature - a rule/pattern/pitfall, NOT a checkpoint echo>', '<0.7-0.95>', '<area>') + '` for each genuine NEW lesson (1-3 max, high-signal) — the `cd ' + BRAIN + ' &&` prefix + `--project ' + BRAIN + '` pin guarantee the lesson lands in the brain regardless of your CWD. Then run `' + DZ + ' statusline --fa-record --slug ' + SLUG + ' --step "Step 8 QE" --recalled 3 --stored <count taught> --reinforced <count reinforced> --mode ' + MODE + ' --project ' + REPO + '` (run it verbatim via Bash, do not skip). Do NOT teach trivia or invent gaps. Return {grade, gaps, codeTestsAdequate, docTestsPresent}.' + landedNote
+const qePrompt = 'Step 8 (QE - brutal-honesty review, agentic-qe) of /feature-adr for "' + DESC + '" (' + SLUG + '). Adversarially review the SHIPPED code (read it): correctness, edge cases, error handling, and the LOAD-BEARING property the ADR named (ASSERT it has a test - the recurring lesson). Run this ADR gate before final grading: ' + ADR_FITNESS_CHECKLIST + ' Grade A/B/C/D honestly. Assess code-test adequacy + doc-test presence. List CONFIRMED gaps with severity. Write ' + FDIR + '/08_qe_report.md with an ADR Fitness Checklist section showing PASS/FAIL per ADR and evidence for the Confirmation-linked test. MANDATORY SELF-LEARNING STORE (close the loop, never skip): compare every candidate lesson against the Step-0 recalled LEARNED patterns above. Teach ONLY lessons NOT covered by Step-0 recall. On overlap, run `dz teach --reinforce "<recalled pattern id or exact text>" --project ' + BRAIN + '` instead of minting a near-duplicate; if --reinforce is unavailable, skip the duplicate teach and report `reinforced existing pattern <id>` in the QE report. Store every genuinely new lesson in the CANONICAL BRAIN store at `' + BRAIN + '` so it is NOT lost to a target repo you may have cd`d into. Via Bash run EXACTLY `' + DZ_TEACH('<a durable reusable lesson from this feature - a rule/pattern/pitfall, NOT a checkpoint echo>', '<0.7-0.95>', '<area>') + '` for each genuine NEW lesson (1-3 max, high-signal) — the `cd ' + BRAIN + ' &&` prefix + `--project ' + BRAIN + '` pin guarantee the lesson lands in the brain regardless of your CWD. Then run `' + DZ + ' statusline --fa-record --slug ' + SLUG + ' --step "Step 8 QE" --recalled 3 --stored <count taught> --reinforced <count reinforced> --mode ' + MODE + ' --project ' + REPO + '` (run it verbatim via Bash, do not skip). Do NOT teach trivia or invent gaps. Return {grade, gaps, codeTestsAdequate, docTestsPresent}.' + landedNote
 // CROSS-MODEL QE (load-bearing): resolveStageModel('qe') derives the OTHER family than the resolved
 // coder when args.models.qe is unset (coder-codex ⇒ opus; coder-Claude ⇒ codex, or opus if codex absent).
 // An explicit args.models.qe wins. A Claude qe spec is merged onto the qe-code-reviewer base (role