@windyroad/architect 0.23.9-preview.1293 → 1.0.0-preview.1296

package/.claude-plugin/plugin.json

@@ -123,5 +123,5 @@
     }
   },
   "name": "wr-architect",
-  "version": "0.23.9"
+  "version": "1.0.0"
 }

package/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "wr-architect",
-  "version": "0.23.9",
+  "version": "1.0.0",
   "description": "Architecture decision enforcement for AI coding agents",
   "author": {
     "name": "Windy Road Technology",

package/agents/agent.md

@@ -15,6 +15,10 @@ model: inherit
 
 You are the Architect. You review proposed changes against the project's architectural decisions before any architecture-bearing file is edited. You are a reviewer, not an editor.
 
+## One headline, no riders
+
+Each ADR records only one independently changeable headline decision. Split multiple decisions into separate ADRs. Include context, alternatives, rationale, consequences and decision-level confirmation criteria. Keep implementation instructions, commands, resource configuration and delivery tasks outside ADRs. No riders: ratification covers only the single explicitly presented headline decision. Additional decisions, clauses or conditions require separate ratification. Context, rationale, consequences and confirmation criteria must not introduce additional mandatory choices. Preserve ratified substance; propose amendments through separate successor proposals rather than rewriting it unilaterally.
+
 ## Your Role
 
 1. Read `docs/decisions/README.md` — the generated **Decisions Compendium**. It carries every ADR's chosen option, confirmation criteria, and relationship graph in a compact form (~40 KB vs ~1.6 MB for the full body set; ~40× reduction). **This is the routine load surface for compliance review** (per the decisions-compendium load rule). If `docs/decisions/README.md` does not exist, fall back to globbing `docs/decisions/*.md` (skip the absent README) — the project may predate the decisions-compendium load rule or be a fresh install. If `docs/decisions/` itself does not exist, that is fine; proceed noting that no prior decisions are recorded. **Load a specific ADR's full body** (`docs/decisions/<NNN>-*.md`) **only when the compendium entry is insufficient for the current review** — deep-dive on a contested change, evolving a decision, ratifying a new ADR via `/wr-architect:create-adr`, or confirming a substance question the compendium summary does not resolve. The per-ADR body remains the authoritative substance (the state-based problem-directory layout rule); the compendium is a derived view.
@@ -34,7 +38,7 @@ In pre-edit mode:
 - If you receive a review request describing PROPOSED changes (not-yet-applied), classify alignment of the PROPOSAL itself. Not-yet-applied state of the proposed change is the EXPECTED baseline of a pre-edit gate. Do NOT treat "edits aren't applied yet" / "the residual old state is still live" / "the change isn't on disk yet" as ISSUES FOUND — that is the gate's design intent (the pre-edit review catch-22 closes this catch-22).
 - The ground truth you classify against is the **proposal** as described in the calling prompt (the diff sketch, the fix-strategy prose, the file-edit plan). The disk state is the legitimate "old state" the proposal is about to replace.
 - PASS the review when the proposal aligns with existing decisions, the proposal does not require a new decision the user hasn't pinned, and the proposal's substance is sound. ISSUES FOUND on a pre-edit review must cite a problem with the **proposal**, not with the not-yet-applied-ness of the proposal.
-- All other review machinery below (Decision Staleness, Existing Decision Compliance, Confirmation Criteria, New Decision Detection, Runtime-Path Performance, Decision Quality, Unratified Dependency, Needs Direction) applies normally — pre-edit mode does not relax any of those substantive checks. It constrains only the verdict-grammar around the not-yet-applied baseline.
+- All other review machinery below (Decision Staleness, Existing Decision Compliance, Confirmation Criteria, New Decision Detection, Runtime-Path Performance, Decision Quality, Premature Acceptance, Needs Direction) applies normally — pre-edit mode does not relax any of those substantive checks. It constrains only the verdict-grammar around the not-yet-applied baseline.
 
 **Post-edit mode (the explicit drift-detection or applied-change review).** The calling prompt asks you to verify already-applied edits against decisions — typically a `/wr-architect:review-design` invocation against staged changes and recent commits, or a release-gate audit. Recognition signals: the prompt names "staged changes", "recent commits", "the current diff", "verify compliance", or "review the applied changes against …". In post-edit mode you may flag drift between disk state and decisions exactly as the original verdict grammar describes — the change is on disk by construction; the not-yet-applied carve-out does not apply.
 
@@ -128,8 +132,10 @@ When a change includes a new or modified decision file in `docs/decisions/`:
 - Does it follow MADR 4.0 format with required sections?
 - Does the frontmatter have all required fields (status, date, decision-makers, consulted, informed)?
 - Does it list at least 2 considered options with pros/cons?
+- Does it record one independently changeable headline only, without additional mandatory choices in supporting sections? Split any rider into a separately ratifiable proposal.
+- Are implementation instructions, commands, resource configuration and delivery tasks kept outside the ADR?
 - Does it include reassessment criteria?
-- If it supersedes another decision, is the old decision properly updated?
+- If it supersedes another decision, is the existing supersession procedure followed without rewriting ratified substance?
 - **Is `docs/decisions/README.md` (the compendium) refreshed and staged?** Per the decisions-compendium load rule, the compendium is the architect agent's routine load surface and MUST be regenerated whenever an ADR body changes. Skills (`/wr-architect:create-adr`, `/wr-architect:capture-adr`, `/wr-architect:review-decisions`) regenerate it automatically; off-skill hand-edits and bulk renames must regenerate it explicitly. Flag any change that touches `docs/decisions/<NNN>-*.md` without also staging a fresh `docs/decisions/README.md`. Recovery is mechanical: `wr-architect-generate-decisions-compendium && git add docs/decisions/README.md`. The `architect-compendium-refresh-discipline.sh` commit-time hook is the safety-net backstop, not the primary mechanism.
 
 ## Output Formatting
@@ -180,17 +186,13 @@ Emit **NEEDS DIRECTION** only when ALL of the following hold:
 
 Do NOT emit Needs Direction for the "obvious choice" / only-one-viable-option case (see "When NOT to flag" above) — over-firing on obvious choices is the over-ask trap CLAUDE.md the mechanical-stage over-asking failure warns against. Needs Direction is the architect-surface instance of the decision-delegation rule category 1 (direction-setting); `AskUserQuestion` remains a primary-agent affordance — you name the question + options, the main agent owns the ask.
 
-### When to flag [Unratified Dependency] (the ratify substance before dependent work rule surface 3)
-
-When the change or plan under review **explicitly cites or implements** a specific ADR (e.g. the diff/prose says "per the propose-fix RFC requirement", a `Refs: ADR-NNN`, or it is authoring the work the ADR governs), check whether that ADR has been **ratified** before letting the change stand. You have Read/Glob/Grep (no Bash), so perform the **read-only equivalent** of `packages/architect/scripts/is-decision-unconfirmed.sh` — mirror ALL THREE halves of its "unconfirmed" definition:
+### Proposal implementation and [Premature Acceptance]
 
-1. **Frontmatter-scoped marker check.** Read the cited ADR file and inspect ONLY its YAML frontmatter (the block between the leading `---` and the next `---`). The ADR is **ratified** iff that frontmatter contains a line matching `human-oversight: confirmed` — case-insensitive, tolerating trailing whitespace (the canonical predicate greps `-iE '^human-oversight:[[:space:]]*confirmed[[:space:]]*$'`). A body mention of that string does NOT count — it must be in frontmatter.
-2. **Superseded skip.** A `*.superseded.md` ADR is retired — treat it as ratified-equivalent (do NOT flag); a newer ADR replaced it.
-3. **Rejected-pending-supersede skip** (the architecture human-oversight rule amendment per the rejected-decision drain recurrence). An ADR whose frontmatter carries BOTH `human-oversight: rejected-pending-supersede` AND `supersede-ticket: P<NNN>` is ratified-equivalent — the user has explicitly rejected the ADR and pinned a supersede in flight. Treat as ratified (do NOT flag). The marker alone (without the `supersede-ticket:` scalar) does NOT skip — it is malformed and surfaces as unratified so the un-tracked case doesn't silently rot.
+A documented proposed ADR can guide implementation with `human-oversight: unconfirmed`. Missing ratification alone is never an implementation blocker. Review its substance and the applicable architecture, job, story-map, risk, and release requirements normally. Ask for direction only when the substantive choice is genuinely unpinned.
 
-Emit **ISSUES FOUND / [Unratified Dependency]** only when the cited ADR's frontmatter lacks the `confirmed` marker AND it is not superseded AND it does not carry the rejected-pending-supersede + supersede-ticket pair — action: "ratify ADR-NNN via `/wr-architect:review-decisions` before this lands." 
+For an acceptance change, inspect the ADR frontmatter for `human-oversight: confirmed` and its Confirmation section for evidence sufficient to demonstrate that the chosen architecture worked in actual production use. Operational receipts and delivery instructions belong in the delivery artifact. Both are required. Local tests, CI, publication, previews, staging, and synthetic evaluations alone do not demonstrate production use. Emit **ISSUES FOUND / [Premature Acceptance]** if either prerequisite is missing; keep the ADR proposed and continue authorized implementation and evidence gathering.
 
-**Key the flag on the oversight marker, NEVER on `status:`.** `status: proposed`/`accepted` and `human-oversight:` are orthogonal axes (the architecture human-oversight rule). Building on a **ratified** ADR is fine even when its `status` is still `proposed` — do NOT flag it. Only the *unratified* (marker-absent, non-superseded) case flags. In steady state almost every ADR is ratified (born-confirmed via `create-adr` + the review-decisions drain), so this fires on essentially nothing — do not over-scan or flag transitive/ambient dependence on governed code, only an explicit cite/implement of a specific unratified ADR (the inverse missed strong-correction capture failure / the mechanical-stage over-asking failure over-fire guard).
+A superseded ADR is historical; a rejected proposal cannot authorize implementation. Do not flag transitive or ambient dependence merely because an ADR remains proposed. Never fabricate ratification or evidence.
 
 Issue types:
 - **[Decision Conflict]**: Change conflicts with an accepted/proposed decision
@@ -200,7 +202,7 @@ Issue types:
 - **[Missing Supersession]**: A new decision should supersede an old one but doesn't
 - **[Amendment To Ratified Decision]**: The change edits the body of a decision that carries `human-oversight: confirmed`, or adds an `### Amendment` section, or adds an `amends:` frontmatter key. A ratified decision is immutable — see below.
 - **[Confirmation Violation]**: New code violates a confirmation criterion of an existing decision
-- **[Unratified Dependency]**: The change/plan explicitly cites or implements an ADR that is **unratified** (its frontmatter lacks `human-oversight: confirmed`, and it is not `*.superseded.md`) — building on it before a human ratifies its substance is the unratified dependent-work failure failure mode (the ratify substance before dependent work rule enforcement surface 3)
+- **[Premature Acceptance]**: An acceptance change lacks human ratification of the final substance or evidence of successful actual production use.
 - **[First-Match Footgun]**: A first-match read from a non-unique collection controls identity, authorization, or data binding without an explicit ambiguity policy
 
 ## Constraints

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@windyroad/architect",
-  "version": "0.23.9-preview.1293",
+  "version": "1.0.0-preview.1296",
   "description": "Architecture decision enforcement for AI coding agents",
   "bin": {
     "windyroad-architect": "./bin/install.mjs"

package/skills/capture-adr/SKILL.md

@@ -26,6 +26,18 @@ An unsolicited adjacent suggestion is not a considered option. Omit it from the
 
 This skill is the foreground-lightweight-capture variant of `/wr-architect:create-adr`'s new-ADR path per the governance-skill invocation rule. The deferred background-capture variant named in the governance-skill invocation rule's original taxonomy remains deferred per the context-blind retrospective failure settlement.
 
+## One headline, no riders
+
+Each ADR records only one independently changeable headline decision. Split multiple decisions into separate ADRs. Include context, alternatives, rationale, consequences and decision-level confirmation criteria. Keep implementation instructions, commands, resource configuration and delivery tasks outside ADRs. No riders: ratification covers only the single explicitly presented headline decision. Additional decisions, clauses or conditions require separate ratification. Context, rationale, consequences and confirmation criteria must not introduce additional mandatory choices. Preserve ratified substance; propose amendments through separate successor proposals rather than rewriting it unilaterally.
+
+## ADR lifecycle: propose, use, then accept
+
+A proposed ADR may guide implementation before human ratification. Keep it `status: proposed` and `human-oversight: unconfirmed` while building and learning; proposal implementation does not grant acceptance. Do not request final ratification merely to unblock implementation.
+
+Acceptance requires **both** explicit human ratification of the final decision substance **and** evidence of successful actual production use satisfying its Confirmation criteria. Confirmation must contain evidence that the chosen architecture has worked in actual production use, sufficient for a human to evaluate it. Operational receipts and delivery instructions belong in the delivery artifact. Local tests, CI, publication, previews, staging, and synthetic evaluations alone are insufficient. Missing either condition means the ADR stays proposed. Do not invent evidence or automatically promote historical ADRs.
+
+Once production evidence is complete, finish the draft, obtain cognitive accessibility review, present the complete substance, and seek human ratification through the existing ratification flow. Only then record acceptance; preserve existing supersession procedures. Direction to experiment or build is not final ratification. Existing architecture, story-map, job, risk, and release gates still apply.
+
 ## When to invoke
 
 - **Mid-iter design decision**: agent or user lands on a design choice during foreground work and cannot afford the ~10-15 turn ceremony of `/wr-architect:create-adr`.
@@ -35,7 +47,7 @@ This skill is the foreground-lightweight-capture variant of `/wr-architect:creat
 **Use `/wr-architect:create-adr` instead** when:
 - The user wants to walk the full interactive intake flow and author the sections themselves (Considered Options ≥2, Decision Drivers, full Consequences, Confirmation criteria, Pros/Cons of Options via request_user_input).
 - The decision is contested or under-specified in-session — silent derivation needs a real decision context to derive FROM; if the options were never actually weighed, create-adr's interactive intake is the honest surface.
-- The decision needs immediate architect review + acceptance (capture-adr writes `.proposed.md`; acceptance review is a follow-up via `/wr-architect:create-adr` or direct architect-agent review).
+- The decision has production evidence and needs final architect review + acceptance (capture-adr writes `.proposed.md`; acceptance review is a follow-up via `/wr-architect:create-adr` or direct architect-agent review).
 
 ## Rule 6 audit (per the governance-skill invocation rule + the structured governance interaction rule)
 
@@ -46,7 +58,7 @@ This skill has **zero request_user_input branches** by design. Each potentially-
 | Considered Options ≥2 | Silent derivation (the decision-delegation rule category-4): write the chosen option PLUS every alternative the decision-maker actually weighed and rejected in the decision context (`$ARGUMENTS` + the invoking session). An unsolicited adjacent suggestion is not an option. Real options with one-line summaries — never a placeholder sibling. If the context genuinely weighed only one option, derive the strongest do-nothing / status-quo alternative and say why it lost. |
 | Decision drivers | Silent derivation: extract the forces that actually drove the decision from the context (the problem's symptoms, the constraint that ruled options out, the user's stated priorities). |
 | Consequences | Silent derivation: real Good/Neutral/Bad trade-off analysis of the chosen option. The invoking agent performs the analysis at capture — it has more decision context in-session than any later expansion pass would. |
-| Confirmation criteria | Silent derivation: testable criteria (a command, an observable behaviour, a hook that fires) confirming the decision is implemented and holding. |
+| Confirmation criteria | Silent derivation: decision-level criteria (observable behavior demonstrating the chosen architecture) confirming the decision is implemented and holding. |
 | Reassessment criteria | Silent derivation: real conditions that would reopen the decision, plus `reassessment-date` default 3 months from today (matches `create-adr` Step 4 default). |
 | Decision-makers / consulted / informed | Silent derivation: `decision-makers: [<git config user.name>]` plus any decision-owner named in `$ARGUMENTS`; `consulted`/`informed` from context or `[]`. Never a sentinel string. |
 | Empty `$ARGUMENTS` | Halt-with-stderr-directive: print "capture-adr requires Title + 1-line Context + 1-line Decision in $ARGUMENTS — invoke /wr-architect:create-adr instead for the full intake flow" and exit. AFK orchestrators MUST NOT invoke capture-adr with empty arguments — caller-side contract. |
@@ -154,7 +166,7 @@ Chosen option: **"<Chosen option>"**, because <the real reason from $ARGUMENTS/c
 
 ## Confirmation
 
-<testable criteria: a command, an observable behaviour, a gate that fires — how a future reader verifies the decision is implemented and holding>
+<decision-level observable outcomes demonstrating the chosen architecture; keep commands and delivery tasks in the delivery artifact>
 
 ## Pros and Cons of the Options
 
@@ -215,12 +227,12 @@ The `capture` verb is the audit signal that this ADR landed via the lightweight
 After the commit, report:
 
 - The new ADR file path and ID.
-- Trailing pointer: `ADR-<NNN> was captured with derived substance and is human-oversight: unconfirmed — the SessionStart oversight nudge will surface it for ratification at /wr-architect:review-decisions (or ratify now if interactive).`
+- Trailing pointer: `ADR-<NNN> was captured with derived substance and is human-oversight: unconfirmed — the SessionStart oversight nudge will surface it for ratification at /wr-architect:review-decisions (after successful actual production-use evidence is available).`
 - Note any renumber-from-origin-collision log line from Step 2.
 
 The trailing pointer is **not optional** — it is the user-visible signal that the derived substance awaits human ratification. Unlike the pre-the full-substance capture implementation design contract there is no expansion step: the sections are already real; the drain confirms or amends them.
 
-**Confirm-every-ADR gate (the Needs-Direction handoff rule):** a capture-adr ADR is recorded `proposed` with derived substance but WITHOUT human review of that substance. It must NOT be promoted to `accepted` until a human has ratified the derived content via `/wr-architect:review-decisions` (or a `/wr-architect:create-adr` review-and-confirm pass). Capture records the decision quickly; the ratification — not the capture — is what gives it human oversight. This is prong 1 of the unpinned architecture direction requirement.
+**Confirm-every-ADR gate (the Needs-Direction handoff rule):** a capture-adr ADR is recorded `proposed` with derived substance but WITHOUT human review of that substance. It must NOT be promoted to `accepted` until successful actual production use is evidenced and a human has ratified the final derived content via `/wr-architect:review-decisions` (or a `/wr-architect:create-adr` review-and-confirm pass). Capture records the decision quickly; the ratification — not the capture — is what gives it human oversight. This is prong 1 of the unpinned architecture direction requirement.
 
 **Oversight marker discipline (the genuine ratification marker rule / the false human-oversight marker failure).** A capture-adr ADR MUST be born `human-oversight: unconfirmed` — NOT `confirmed`. Capture is the AFK-friendly aside surface; there is no substance-confirm `request_user_input` pass in this flow, so `confirmed` would be a hollow marker (the false human-oversight marker failure bug class). The `architect-oversight-marker-discipline.sh` PreToolUse hook will DENY any Edit/Write that introduces `human-oversight: confirmed` without a matching session-scoped evidence marker. The frontmatter (Step 3 above) MUST include `human-oversight: unconfirmed` so the ADR enters the world honestly self-identified as needing user confirmation. The drain (`/wr-architect:review-decisions`) and a `/wr-architect:create-adr <NNN>` review pass are the surfaces that legitimately promote it to `confirmed` via `bash "<architect-plugin-root>/scripts/mark-oversight-confirmed.sh"` + the gated marker write.
 

package/skills/create-adr/SKILL.md

@@ -24,6 +24,18 @@ The user's pinned subject bounds every ADR section: do not add adjacent populati
 When asked for the ADR file body, output only that body. Do not append a recap of excluded rollout work or unsolicited suggestions after it.
 An unsolicited adjacent suggestion is not a considered option. Omit it from the entire ADR, including reassessment criteria, and do not revive it in post-ADR notes or follow-up offers unless the decision-maker actually chose to consider it.
 
+## One headline, no riders
+
+Each ADR records only one independently changeable headline decision. Split multiple decisions into separate ADRs. Include context, alternatives, rationale, consequences and decision-level confirmation criteria. Keep implementation instructions, commands, resource configuration and delivery tasks outside ADRs. No riders: ratification covers only the single explicitly presented headline decision. Additional decisions, clauses or conditions require separate ratification. Context, rationale, consequences and confirmation criteria must not introduce additional mandatory choices. Preserve ratified substance; propose amendments through separate successor proposals rather than rewriting it unilaterally.
+
+## ADR lifecycle: propose, use, then accept
+
+A proposed ADR may guide implementation before human ratification. Keep it `status: proposed` and `human-oversight: unconfirmed` while building and learning; proposal implementation does not grant acceptance. Do not request final ratification merely to unblock implementation.
+
+Acceptance requires **both** explicit human ratification of the final decision substance **and** evidence of successful actual production use satisfying its Confirmation criteria. Confirmation must contain evidence that the chosen architecture has worked in actual production use, sufficient for a human to evaluate it. Operational receipts and delivery instructions belong in the delivery artifact. Local tests, CI, publication, previews, staging, and synthetic evaluations alone are insufficient. Missing either condition means the ADR stays proposed. Do not invent evidence or automatically promote historical ADRs.
+
+Once production evidence is complete, finish the draft, obtain cognitive accessibility review, present the complete substance, and seek human ratification through the existing ratification flow. Only then record acceptance; preserve existing supersession procedures. Direction to experiment or build is not final ratification. Existing architecture, story-map, job, risk, and release gates still apply.
+
 ## Needs-Direction handoff + confirm-every-ADR (the Needs-Direction handoff rule)
 
 When a `wr-architect:agent` review returns a **NEEDS DIRECTION** verdict (a new decision with 2+ viable options and no pinned direction, per the Needs-Direction handoff rule), the option choice is the user's, not the agent's — this skill is the translation surface. The architect's named question + options become the Step 2 cat-1 `request_user_input` calls (Considered Options / Decision Outcome), and the Step 5 confirm is the load-bearing **review-and-confirm-every-ADR** gate: an ADR must not stand as a human-oversighted decision (reach `accepted`) without that confirm pass. A `/wr-architect:capture-adr` ADR — zero-ask, with its decision pre-pinned in `$ARGUMENTS` and its remaining sections silently DERIVED at capture per the governance-skill invocation rule derived-substance amendment (the full-substance capture implementation design) — must still have its derived substance human-ratified (via `/wr-architect:review-decisions` or this skill's confirm) before promotion to `accepted`. When direction IS already pinned (same-turn / same-session / accepted ADR / RISK-POLICY.md / CLAUDE.md mandatory rule), act on it — do not re-ask (the inverse over-ask guard).
@@ -107,30 +119,9 @@ ADR titles must name the **decision outcome** as a short noun phrase, not the qu
 
 (Serves the automated governance user outcome — skimmable titles speed the read path for the governance-enforcement persona.)
 
-### 2b. Decision-boundary analysis (multi-decision check)
-
-Before writing the ADR file, perform a decision-boundary analysis on the gathered context to prevent conflated ADRs that block independent status transitions and weaken auditability (the multi-decision ADR intake failure).
-This check applies only to decisions the user actually asked to make; splitting or keeping decisions together never authorizes an unrequested rider.
-
-**Self-check**: Read the context gathered in step 2. Answer: "How many distinct decisions are present? If each could be independently accepted, rejected, or superseded without affecting the others, they are distinct."
+### 2b. Decision-boundary analysis — mandatory split
 
-- **Single decision** (one coherent question with one chosen option): proceed directly to step 3.
-- **Multiple decisions** (two or more distinct questions, different components, or different decision drivers that do not share the same trade-off): present a split prompt.
-
-**Split prompt** — use `request_user_input`:
-- `header: "Multi-decision input"`
-- `multiSelect: false`
-- Options:
-  1. `Split into separate ADRs (Recommended)` — description: "Create one ADR per distinct decision, with consecutive IDs. Each ADR can be accepted, rejected, or superseded independently."
-  2. `Keep as a single ADR` — description: "Create one ADR covering all decisions. Use this only if the decisions are so tightly coupled that they cannot be made independently."
-
-**Non-interactive fallback**: When `request_user_input` is unavailable (e.g., non-interactive/AFK mode), automatically split into separate ADRs with consecutive IDs and note the auto-split in output. Do not block creation.
-
-**the structured governance interaction rule Rule 6 carve-out audit (the AFK question queue-and-continue rule, 2026-06-06 amendment)**: the universal AFK default is **queue-and-continue**; this site is a documented **AUTO-DEFAULT** carve-out. Authorising principle: policy-authorised safe default per the decision-delegation rule category 4 (silent framework). Splitting is fully reversible (manual combine via supersession), the framework's WSJF / lifecycle model rewards explicit per-decision ranking, and "split when in doubt" is the persona-correct safe heuristic for the unattended backlog progress user outcome. Note: the Step 5 substance-confirm HALT below is a separate carve-out authorised by the ratify substance before dependent work rule — substance-confirm cannot AUTO-DEFAULT because the dependent work (Decision Outcome / Consequences / Confirmation / Pros and Cons drafting) is built ON the chosen option.
-
-**Split implementation**: When splitting, assign consecutive IDs. Cross-reference each ADR in the other's Related section or as a linked decision in the consequences.
-
-**Scope**: Scoped to new ADR creation only (steps 2–5). Does not apply to supersession handling (step 6), where the scope of the new decision is already known and bounded.
+Read the gathered context and identify independently changeable headline decisions. Split each into its own ADR with consecutive IDs. This is mechanical; do not ask whether to keep several independent choices in one ADR, including in unattended runs. Explain the split in the report. Supporting sections cannot add mandatory choices or expand the scope of ratification. Apply the same check to successor proposals.
 
 ### 3. Determine sequence number and filename
 
@@ -248,6 +239,10 @@ Use this runtime-specific review path. Supply the shared rubric and complete ADR
 
 After the final `PASS`, do not edit the ADR before presenting the summary, ADR file, and structured substance question. If any later answer requires an ADR edit, return to this step and obtain another `PASS` before re-presentation.
 
+### 4.6 Check production evidence before final ratification
+
+If successful actual production use has not yet been evidenced in Confirmation, save and commit the complete ADR as proposed/unconfirmed, refresh the compendium, report the missing evidence, and continue authorized implementation. Skip Step 5 and do not retire predecessors. Intake option selection pins an experiment; it does not approve the architecture permanently.
+
 ### 5. Confirm the substance with the user (the option-selection-before-drafting requirement + the substance-confirmation evidence requirement)
 
 The optional draft-quality question occurred before cognitive review and does not gate the marker. Step 5 now fires only the separate substance-confirm question: the user picks the chosen option from the considered-options set, and that answer gates the born-confirmed marker write.
@@ -284,7 +279,7 @@ options:
 
 **Defer the marker write until the draft is final.** Complete the retitle, optional draft-quality edits, and any `supersedes:` declaration before cognitive review. A matching substance-confirm answer then authorises `human-oversight: confirmed` as the final content write in Step 5b. This ordering is required because a confirmed ADR is immutable. AFK iter subprocesses spawned via `claude -p` have no `request_user_input` access; they MUST leave `human-oversight: unconfirmed` for the interactive drain.
 
-**the structured governance interaction rule Rule 6 carve-out audit (the AFK question queue-and-continue rule, 2026-06-06 amendment)**: the universal AFK default is queue-and-continue. This Step 5 substance-confirm HALT-and-write-`human-oversight: unconfirmed` shape is a documented carve-out, authorised by **the ratify substance before dependent work rule** (Confirm decision substance before building dependent work). Rationale: an ADR with `human-oversight: confirmed` enters the world born-confirmed (it does not appear in `/wr-architect:review-decisions`' unoversighted set), so dependent work — every implementation that cites this ADR as authority — would be built on substance that was never user-affirmed. AFK writing `human-oversight: unconfirmed` IS the queue-and-continue shape: the loop continues; the substance-confirm decision is queued to the next interactive drain. Persona-correct for the unattended backlog progress user outcome; the carve-out is from the auto-confirm shape, not from queue-and-continue itself.
+**AFK rule:** leave `human-oversight: unconfirmed`, keep the ADR proposed, and continue authorized implementation. Queue final ratification only after successful actual production-use evidence is available. Missing a ratification interaction is not an ADR implementation blocker.
 
 **Mismatch handling.** If the substance-confirm answer selects a DIFFERENT option than the draft was authored against:
 
@@ -324,7 +319,7 @@ human-oversight: confirmed
 oversight-date: YYYY-MM-DD   # today
 ```
 
-The PostToolUse hook writes the session-scoped evidence marker consumed by `architect-oversight-marker-discipline.sh`. Calling the helper without a real substance-confirm event is forbidden. Once these lines land, do not edit the ADR body or clear the marker; a later choice requires a new superseding ADR.
+The PostToolUse hook writes the session-scoped evidence marker consumed by `architect-oversight-marker-discipline.sh`. Calling the helper without a real substance-confirm event is forbidden. After recording these lines, set `status: accepted` as part of the same final acceptance write; both production evidence and human ratification must already exist. Do not subsequently edit the accepted ADR body or clear its marker; a later choice requires a new superseding ADR. Rename the newly accepted file from `*.proposed.md` to `*.accepted.md` with `git mv` so filename-based readers observe the same accepted state.
 
 If the new ADR supersedes an older decision, now rename the older file to `*.superseded.md` with `git mv`. Do not edit the old decision's frontmatter or body. This eliminates the rename-and-stage ordering failure staging trap: there is no post-rename edit.
 

package/skills/review-decisions/SKILL.md

@@ -21,6 +21,18 @@ Lift auto-made architecture decisions to human decisions. Many ADRs were recorde
 
 This is the unpinned architecture direction requirement prong-2 drain surface. It is the eat-our-own-dogfood loop: confirming a decision is itself a human decision, so it goes through `request_user_input`.
 
+## One headline, no riders
+
+Each ADR records only one independently changeable headline decision. Split multiple decisions into separate ADRs. Include context, alternatives, rationale, consequences and decision-level confirmation criteria. Keep implementation instructions, commands, resource configuration and delivery tasks outside ADRs. No riders: ratification covers only the single explicitly presented headline decision. Additional decisions, clauses or conditions require separate ratification. Context, rationale, consequences and confirmation criteria must not introduce additional mandatory choices. Preserve ratified substance; propose amendments through separate successor proposals rather than rewriting it unilaterally.
+
+## ADR lifecycle: propose, use, then accept
+
+A proposed ADR may guide implementation before human ratification. Keep it `status: proposed` and `human-oversight: unconfirmed` while building and learning; proposal implementation does not grant acceptance. Do not request final ratification merely to unblock implementation.
+
+Acceptance requires **both** explicit human ratification of the final decision substance **and** evidence of successful actual production use satisfying its Confirmation criteria. Confirmation must contain evidence that the chosen architecture has worked in actual production use, sufficient for a human to evaluate it. Operational receipts and delivery instructions belong in the delivery artifact. Local tests, CI, publication, previews, staging, and synthetic evaluations alone are insufficient. Missing either condition means the ADR stays proposed. Do not invent evidence or automatically promote historical ADRs.
+
+Once production evidence is complete, finish the draft, obtain cognitive accessibility review, present the complete substance, and seek human ratification through the existing ratification flow. Only then record acceptance; preserve existing supersession procedures. Direction to experiment or build is not final ratification. Existing architecture, story-map, job, risk, and release gates still apply.
+
 ## When to use
 
 - The session-start nudge reported `N decisions lack human oversight`.
@@ -46,6 +58,10 @@ The `bash "<architect-plugin-root>/scripts/detect-unoversighted.sh"` command is
 
 Read **only the frontmatter + title + Decision Outcome** of each unoversighted ADR (not full bodies — keep it cheap). Group by topic cluster (e.g. release-cadence, governance-gates, AFK-orchestration, decision-recording) and order **load-bearing first**: ADRs that other ADRs cite as parents, that are `accepted` (already shipped — highest drift cost if the auto-pick was wrong), or that govern a hook/gate the user interacts with daily. Defer narrow / low-coupling ADRs.
 
+### Step 2.4: Check production evidence
+
+Before the ratification review, read each ADR's Confirmation section. Missing successful actual production-use evidence means HOLD: leave it proposed/unconfirmed, report the evidence gap, and continue authorized implementation. Do not ask for final ratification of an unproven proposal. For an ADR whose production use is evidenced, proceed to cognitive review and human ratification of the final substance. Ratification alone, or production evidence alone, never grants acceptance.
+
 ### Step 2.5: Cognitive-accessibility review before ratification
 
 For each ADR, read `../../references/cognitive-accessibility-rubric.md`, relative to this `SKILL.md`, and the complete unconfirmed ADR. Supply both in the reviewer prompt.
@@ -87,7 +103,7 @@ This is a genuine human-decision surface (the whole point of the unpinned archit
 
 ### Step 4: Apply the outcome
 
-- **Confirm**: run `bash "<architect-plugin-root>/scripts/mark-oversight-confirmed.sh" <adr-path>` as a standalone Bash command; do not combine it with another command, because its PostToolUse event binds the evidence to this exact session and ADR. Then write `human-oversight: confirmed` + `oversight-date: <today, YYYY-MM-DD>` into the ADR's frontmatter (insert after the `date:` line if absent; never duplicate). Confirmation is the final content write.
+- **Confirm**: run `bash "<architect-plugin-root>/scripts/mark-oversight-confirmed.sh" <adr-path>` as a standalone Bash command; do not combine it with another command, because its PostToolUse event binds the evidence to this exact session and ADR. Then write `human-oversight: confirmed` + `oversight-date: <today, YYYY-MM-DD>` into the ADR's frontmatter (insert after the `date:` line if absent; never duplicate). Confirmation and `status: accepted` form the final acceptance write, after the production evidence check and explicit human ratification. Rename the newly accepted file from `*.proposed.md` to `*.accepted.md` with `git mv` so filename-based readers observe acceptance. Preserve the existing supersession procedure without rewriting historical bodies.
 - **Amend**: apply the directed change, then return to Step 2.5. Obtain another cognitive accessibility `PASS` and re-present the summary, ADR file, and structured question. Do not write the oversight marker until a later Confirm answer matches the reviewed ADR.
 - **Reject / supersede** (the architecture human-oversight rule amendment per the rejected-decision drain recurrence):
   1. Capture the supersede ticket via a follow-up `request_user_input`: "Which problem ticket tracks the supersede?" — options: existing `P<NNN>` IDs surfaced from `docs/problems/`, **Capture a new ticket** (delegate to `/wr-itil:capture-problem`), or **Defer (leave un-tracked for now)**.
@@ -126,7 +142,7 @@ Commit the drained batch per the governance skills commit completed work rule. R
 
 - **Never re-ask or rewrite** — a confirmed ADR carries the marker permanently and is excluded from future runs (the session-scoped marker lifecycle rule never-re-ask principle). Ratification closes that document: do not clear its marker or edit its body. A later choice belongs in a new ADR that supersedes it. The same write-once permanence applies to `rejected-pending-supersede`: once the user rejects an unconfirmed ADR with a tracked ticket, the drain stops asking. When the successor lands, renaming the original to `*.superseded.md` retires it without rewriting its confirmed or rejected content.
 - **AFK** — this skill is interactive by construction (the confirm IS the human decision). It is not dispatched inside AFK iteration subprocesses; the session-start nudge self-suppresses there (`WR_SUPPRESS_OVERSIGHT_NUDGE=1`) so the drain is never half-run by an absent user.
-- **Born-confirmed going forward** — `/wr-architect:create-adr` writes the marker at its Step 5 confirm, so new ADRs enter the set already oversighted and the unoversighted count only shrinks.
+- **Proposed going forward** — new ADRs remain proposed/unconfirmed during implementation; the final acceptance flow runs only after successful actual production-use evidence is available.
 
 ## Related
 

package/skills/review-design/SKILL.md

@@ -21,6 +21,18 @@ Run an architecture compliance review on demand — outside the pre-tool-use hoo
 
 This skill is **read-only**. It does not commit, push, or modify files.
 
+## One headline, no riders
+
+Each ADR records only one independently changeable headline decision. Split multiple decisions into separate ADRs. Include context, alternatives, rationale, consequences and decision-level confirmation criteria. Keep implementation instructions, commands, resource configuration and delivery tasks outside ADRs. No riders: ratification covers only the single explicitly presented headline decision. Additional decisions, clauses or conditions require separate ratification. Context, rationale, consequences and confirmation criteria must not introduce additional mandatory choices. Preserve ratified substance; propose amendments through separate successor proposals rather than rewriting it unilaterally.
+
+## ADR lifecycle: propose, use, then accept
+
+A proposed ADR may guide implementation before human ratification. Keep it `status: proposed` and `human-oversight: unconfirmed` while building and learning; proposal implementation does not grant acceptance. Do not request final ratification merely to unblock implementation.
+
+Acceptance requires **both** explicit human ratification of the final decision substance **and** evidence of successful actual production use satisfying its Confirmation criteria. Confirmation must contain evidence that the chosen architecture has worked in actual production use, sufficient for a human to evaluate it. Operational receipts and delivery instructions belong in the delivery artifact. Local tests, CI, publication, previews, staging, and synthetic evaluations alone are insufficient. Missing either condition means the ADR stays proposed. Do not invent evidence or automatically promote historical ADRs.
+
+Once production evidence is complete, finish the draft, obtain cognitive accessibility review, present the complete substance, and seek human ratification through the existing ratification flow. Only then record acceptance; preserve existing supersession procedures. Direction to experiment or build is not final ratification. Existing architecture, story-map, job, risk, and release gates still apply.
+
 ## When to use
 
 - Pre-flight before a release or client handover: confirm no ADR violations crept in
@@ -78,7 +90,7 @@ Build a self-contained prompt for the architect subagent that includes:
 - Any explicit scope from the user
 - The request: "Review these proposed changes against the project's ADRs. Flag any violations, gaps that need a new ADR, or compliance questions."
 
-The architect's verdict taxonomy includes **[Unratified Dependency]** (the ratify substance before dependent work rule surface 3): if the plan/change explicitly cites or implements an ADR that lacks `human-oversight: confirmed` (unratified, non-superseded), the architect flags ISSUES FOUND with a "ratify via /wr-architect:review-decisions first" action. This applies to plan review exactly as to edit review — a plan built on an unratified decision should not proceed until that decision's substance is ratified. No extra prompt wiring is needed (the agent owns the check); this note records that the surface-3 check is in-scope for plan review.
+The architect permits implementation against documented proposals without prior ratification. It flags **[Premature Acceptance]** when acceptance lacks either final human ratification or successful actual production-use evidence. Apply this distinction to plans and edits alike; missing ratification alone does not block building.
 
 ### 5. Delegate to the architect agent