@windyroad/itil 2.0.0 → 2.1.1-preview.1128

package/skills-codex/manage-rfc/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: wr-itil:manage-rfc
+name: manage-rfc
 description: Heavyweight RFC intake + lifecycle management following the "Problem-RFC-Story framework with mandatory problem-trace and unified problem ontology" architecture rule Problem-RFC-Story framework. Creates new RFCs (delegates to /wr-itil:capture-rfc for the lightweight path), updates existing RFCs, transitions through proposed → accepted → in-progress → verifying → closed lifecycle, runs WSJF re-rank reviews, and refreshes docs/rfcs/README.md per the "Problem 062: `manage-problem` does not refresh `docs/problems/README.md` on single-ticket transitions; fast-path cache goes stale silently" problem / the "Problem 094: `/wr-itil:manage-problem` does not refresh `docs/problems/README.md` on ticket creation" problem contract pattern.
 allowed-tools: Read, Write, Edit, Bash, Grep, Glob, Task
 ---

package/skills-codex/manage-story/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: wr-itil:manage-story
+name: manage-story
 description: Heavyweight story intake + lifecycle management following the "Problem-RFC-Story framework with mandatory problem-trace and unified problem ontology" architecture rule Phase 2. Creates and updates story tickets, transitions through draft → accepted → in-progress → done → archived lifecycle, enforces I7 + I8 trace-gate at the accepted transition, runs INVEST checks per I10 at acceptance, auto-detects accepted→in-progress on the first implementing commit and in-progress→done on all-criteria-ticked + linked RFC closes (per the "A story cannot be implemented while in draft — implementation requires accepted" architecture rule a draft story is NEVER implementable — draft→in-progress is removed; the itil-no-implement-draft-gate blocks implementing a draft story), and refreshes docs/stories/README.md per the "Problem 062: `manage-problem` does not refresh `docs/problems/README.md` on single-ticket transitions; fast-path cache goes stale silently" problem / the "Problem 094: `/wr-itil:manage-problem` does not refresh `docs/problems/README.md` on ticket creation" problem contract pattern. Companion to /wr-itil:capture-story (lightweight aside surface).
 allowed-tools: Read, Write, Edit, Bash, Grep, Glob
 ---

package/skills-codex/manage-story-map/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: wr-itil:manage-story-map
+name: manage-story-map
 description: Heavyweight story-map intake + lifecycle management following the "Problem-RFC-Story framework with mandatory problem-trace and unified problem ontology" architecture rule Phase 2. Authors backbone × ribs × slices structure on draft maps, transitions through draft → accepted → in-progress → completed → archived, re-validates I3 + I4 invariants at every transition, and refreshes docs/story-maps/README.md per the "Problem 062: `manage-problem` does not refresh `docs/problems/README.md` on single-ticket transitions; fast-path cache goes stale silently" problem / the "Problem 094: `/wr-itil:manage-problem` does not refresh `docs/problems/README.md` on ticket creation" problem contract pattern. Companion to /wr-itil:capture-story-map (lightweight aside surface).
 allowed-tools: Read, Write, Edit, Bash, Grep, Glob
 ---

package/skills-codex/mitigate-incident/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: wr-itil:mitigate-incident
+name: mitigate-incident
 description: Record a mitigation attempt against an incident — transitions an investigating incident to mitigating on the first attempt, appends subsequent attempts to the Mitigation attempts timeline. Evidence-first gate enforced per the "Add `manage-incident` Skill to `wr-itil` Plugin" architecture rule.
 allowed-tools: Read, Write, Edit, Bash, Glob, Grep, request_user_input, Skill
 ---

package/skills-codex/reconcile-readme/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: wr-itil:reconcile-readme
+name: reconcile-readme
 description: Detect and correct drift between docs/problems/README.md and the on-disk ticket inventory. Wraps the diagnose-only `<itil-plugin-root>/scripts/reconcile-readme.sh` script with an agent-applied-edits pattern that preserves narrative content (the "Last reviewed" prose paragraph and Closed-section closure-via free text). Use when README WSJF Rankings, Verification Queue, or Closed sections drift from filesystem state — typically detected by manage-problem Step 0 preflight or work-problems Step 0 preflight.
 allowed-tools: Read, Edit, Write, Bash, Grep, Glob
 ---

package/skills-codex/reconcile-stories/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: wr-itil:reconcile-stories
+name: reconcile-stories
 description: Detect and correct drift between docs/stories/README.md and the on-disk story inventory. Wraps the diagnose-only <itil-plugin-root>/scripts/reconcile-stories.sh script with an agent-applied-edits pattern that preserves narrative content (the "Last reviewed" prose paragraph). Use when docs/stories/README.md Story Rankings or Done sections drift from filesystem state — typically detected by manage-story Step 0 preflight or work-problems preflight on RFC iters with story-tier traces.
 allowed-tools: Read, Write, Edit, Bash, Grep, Glob
 ---

package/skills-codex/reconcile-story-maps/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: wr-itil:reconcile-story-maps
+name: reconcile-story-maps
 description: Detect and correct drift between docs/story-maps/README.md and the on-disk story-map HTML inventory. Wraps the diagnose-only <itil-plugin-root>/scripts/reconcile-story-maps.sh script with an agent-applied-edits pattern preserving narrative content.
 allowed-tools: Read, Write, Edit, Bash, Grep, Glob
 ---

package/skills-codex/report-upstream/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: wr-itil:report-upstream
+name: report-upstream
 description: Report a local problem ticket as a structured issue against an upstream repository, with bidirectional cross-references and SECURITY.md-aware routing for security-classified tickets. Implements the contract in the "Cross-project problem-reporting contract — `report-upstream` skill in `@windyroad/itil`" architecture rule, with the "Report-upstream classifier is problem-first — supersedes Decision Outcome Steps 3 + 5" architecture rule governing problem-first classifier + default body shape.
 allowed-tools: Read, Write, Edit, Bash, Glob, Grep, request_user_input, Skill, Agent
 ---

package/skills-codex/restore-incident/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: wr-itil:restore-incident
+name: restore-incident
 description: Mark an incident as service-restored — transitions a mitigating incident to restored, appends a Timeline entry, and hands off to /wr-itil:manage-problem for linked-problem creation or update per the "Add `manage-incident` Skill to `wr-itil` Plugin" architecture rule.
 allowed-tools: Read, Write, Edit, Bash, Glob, Grep, request_user_input, Skill
 ---

package/skills-codex/review-problems/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: wr-itil:review-problems
+name: review-problems
 description: Re-assess every open and known-error problem ticket in docs/problems/ — re-read RISK-POLICY.md, re-rate Impact × Likelihood, re-estimate Effort, recalculate WSJF, surface pending verifications, auto-transition Open → Known Error where warranted, and rewrite docs/problems/README.md with the refreshed ranking. Writes to problem files and the README cache; commits the refresh per the "Governance Skills Commit Their Own Completed Work" architecture rule.
 allowed-tools: Read, Write, Edit, Bash, Glob, Grep, request_user_input, Skill
 ---
@@ -32,7 +32,7 @@ When referencing problem IDs, ADR IDs, JTBD IDs, or RFC IDs in prose output (the
 **In scope** (the ": docs/problems/ flat layout migration — per-state subdirs + adopter auto-migration" release design migration window — each glob is dual-tolerant, covering BOTH the flat `docs/problems/<NNN>-<title>.<state>.md` filename-suffix layout AND the per-state subdir `docs/problems/<state>/<NNN>-<title>.md` layout):
 
 - `docs/problems/*.open.md` + `docs/problems/open/*.md` and `docs/problems/*.known-error.md` + `docs/problems/known-error/*.md` — re-scored (Impact × Likelihood × Effort → WSJF); Priority + Effort + WSJF lines updated when they change.
-- `docs/problems/*.verifying.md` + `docs/problems/verifying/*.md` — surfaced in the Verification Queue and fed to Step 4's verification prompt (Known Error → Closed path when the user confirms).
+- `docs/problems/*.verifying.md` + `docs/problems/verifying/*.md` — surfaced in the Verification Queue and fed to Step 4's verification routing (the Verification Pending → Closed path — Bucket 1 closes on evidence, Bucket 2 asks, Bucket 3 flips back).
 - `docs/problems/*.parked.md` + `docs/problems/parked/*.md` — listed in the Parked section; NOT re-scored (WSJF multiplier is 0).
 - `docs/problems/README.md` — rewritten with the refreshed WSJF Rankings + Verification Queue + Parked tables; staged and committed with the review.
 
@@ -124,7 +124,7 @@ Omit an empty section rather than rendering an empty header.
 
 Target the dual-tolerant glob `docs/problems/*.verifying.md docs/problems/verifying/*.md` (the ": docs/problems/ flat layout migration — per-state subdirs + adopter auto-migration" release design migration window) — do NOT scan `.known-error.md` bodies for a `## Fix Released` section (per the "Problem lifecycle — add a Verification Pending status between Known Error and Closed" architecture rule, Verification Pending is a first-class status, not a substring marker). Bucket each verifying ticket by its Step-3 `Likely verified?` cell (the "VQ `Likely verified?` column uses age-based heuristic (≥14 days = yes) instead of session-observed evidence — sibling proxy-for-evidence anti-pattern to" problem evidence-first cell shape: `yes — observed: <evidence>` / `no — not observed` / `no — observed regression`) and route each bucket differently. **Do NOT fire one `request_user_input` per ticket** — the evidence-backed subset closes on evidence; only the unobserved subset asks.
 
-**Bucket 1 — `yes — observed: <evidence>` → close-on-evidence (framework-mediated, silent agent action per the "— Decision-Delegation Contract: when agents act on the framework vs ask the user" architecture rule + the "Decision-delegation contract — agents over-apply Rule 1's interactive default to framework-resolved decisions; codify the framework-resolution boundary + AFK loop's batched-questions-as-deliverable + lazy-request_user_input measurement" problem).** These rows carry the "Agent output grounding — no fabricated quantitative estimates, cite + persist + uncertainty" architecture rule-grounded cited evidence (a prior Step 4 user confirmation, an in-session test invocation + observable outcome, or a `run-retro` Step 4a close-on-evidence citation — see the Step 3 cell definition). The framework has resolved this decision: a `.verifying.md` ticket with specific cited evidence IS verified per the "Problem lifecycle — add a Verification Pending status between Known Error and Closed" architecture rule's evidence semantics, so close it mechanically WITHOUT `request_user_input` — mirroring the shipped `run-retro` Step 4a step 5 close-on-evidence. A per-candidate ask here is lazy deferral (sub-contracting a framework-resolved decision back to the user) per the Step 2d Ask Hygiene Pass. For each such ticket: close the problem (`git mv` from `.verifying.md` to `.closed.md`, update Status to "Closed", re-stage per the "Problem 057: `git mv` + Edit + `git add` staging-ordering trap drops content edits from the commit" problem staging trap) and update the `Likely verified?` cell to `yes — observed: closed-on-evidence <YYYY-MM-DD> — <citation>`. Report each closure in the review output with a documented reversible recovery path: `Recovery: rerun /wr-itil:transition-problem <NNN> known-error to reopen` — closes are cheap and reversible; user disagreement surfaces via authentic-correction (the "— Decision-Delegation Contract: when agents act on the framework vs ask the user" architecture rule category 6), not a pre-close consent gate.
+**Bucket 1 — `yes — observed: <evidence>` → close-on-evidence.** Specific observed evidence authorizes a mechanical close without asking again. First run `<itil-plugin-root>/bin/wr-itil-is-close-blocked <NNN> docs/problems`: exit 0 keeps the ticket open and reports the matched marker; exit 2 is a pre-flight failure; exit 1 proceeds. Move the ticket to `.closed.md`, re-stage it, and persist the authority in `**Status**: Closed (closed-on-evidence <YYYY-MM-DD> — <citation>. Recovery: rerun /wr-itil:transition-problem <NNN> known-error to reopen)`. A provenance-proven GitHub issue on this project's tracker receives the gated comment and closes; unresolved or non-issue inbound provenance performs no issue mutation. A foreign issue receives the comment but stays open on local evidence alone, while that upstream party's confirmation may authorize closure. Pull requests remain comment-only. Update the review cell with the same evidence citation and report the reversible recovery path.
 
 **Bucket 2 — `no — not observed` → ask (genuine user-authority).** No session-observable evidence yet, so the user may hold out-of-band production knowledge the agent cannot observe — this is the genuine user-input surface. Use `request_user_input` to ask whether the fix has been verified in production. The question MUST include a fix summary extracted from the `## Fix Released` section — inline the first sentence (or first bullet list) of that section in the question body or option description per the brief-before-ID discipline, so the user can answer without reading the full problem file. Do NOT ask with only the problem ID + title + version.
 - If the user confirms: close the problem (`git mv` from `.verifying.md` to `.closed.md`, update Status to "Closed", re-stage per the "Problem 057: `git mv` + Edit + `git add` staging-ordering trap drops content edits from the commit" problem staging trap). Update the `Likely verified?` cell to `yes — observed: user confirmed <YYYY-MM-DD>`.

package/skills-codex/scaffold-intake/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: wr-itil:scaffold-intake
+name: scaffold-intake
 description: Scaffold the four OSS intake surfaces (.github/ISSUE_TEMPLATE/, SECURITY.md, SUPPORT.md, CONTRIBUTING.md) for a downstream project that adopts @windyroad/itil. Idempotent, foreground-synchronous, and respects the "Gate Marker Lifecycle: TTL + Drift, Not Stop-Hook Reset" architecture rule marker semantics. Implements the contract in the "Scaffold downstream OSS intake — skill + layered triggers" architecture rule.
 allowed-tools: Read, Write, Edit, Bash, Glob, Grep, request_user_input
 ---

package/skills-codex/transition-problem/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: wr-itil:transition-problem
+name: transition-problem
 description: Advance a problem ticket's lifecycle status — Open → Known Error, Known Error → Verification Pending (verifying), Verification Pending → Closed. Renames the ticket file, updates the Status field, and refreshes docs/problems/README.md in the same commit. Hosts the transition execution inline (pre-flight checks, the "Problem 057: `git mv` + Edit + `git add` staging-ordering trap drops content edits from the commit" problem staging-trap handling, the "Problem 063: manage-problem does not trigger /wr-itil:report-upstream when root cause is external" problem external-root-cause detection, the "Problem 062: `manage-problem` does not refresh `docs/problems/README.md` on single-ticket transitions; fast-path cache goes stale silently" problem README refresh, the "Governance Skills Commit Their Own Completed Work" architecture rule commit) per the "Rename `wr-problem` Plugin to `wr-itil`" architecture rule amended "Split-skill execution ownership". Use when the user asks to "transition", "close", "mark known-error", or "release" a specific ticket.
 allowed-tools: Read, Write, Edit, Bash, Glob, Grep, request_user_input, Skill
 ---
@@ -29,7 +29,7 @@ The deprecated `/wr-itil:manage-problem <NNN> known-error` subcommand route rema
 - `<status>` — the destination status. One of:
   - `known-error` — Open → Known Error (root cause identified AND workaround documented; fix not yet proposed — per the "Problem lifecycle — add a Verification Pending status between Known Error and Closed" architecture rule corrected semantics; the fix proposal draws a release row on a story map).
   - `verifying` — Known Error → Verification Pending (fix released, awaiting user verification per the "Problem lifecycle — add a Verification Pending status between Known Error and Closed" architecture rule).
-  - `close` — Verification Pending → Closed (user has confirmed the fix works in production).
+  - `close` — Verification Pending → Closed (cited evidence meets the ticket's own close criterion, OR the user has confirmed the fix works in production — see Step 4).
 
 The `<NNN>` and `<status>` tokens are **data parameters**, not word-subcommands. Per the "Problem 071: Argument-based skill subcommands are not discoverable in Codex autocomplete" problem split rule (the "Rename `wr-problem` Plugin to `wr-itil`" architecture rule amended), data parameters (IDs, paths, URLs, enum destinations) are permitted; word-subcommands that name distinct user intents are not. This skill's argument shape is `data + data`, which is the same shape as `/wr-itil:report-upstream <NNN>`.
 
@@ -79,8 +79,12 @@ Check the current filename suffix and verify the destination status is reachable
 | `.open.md` | `known-error` | yes |
 | `.known-error.md` | `verifying` | yes |
 | `.verifying.md` | `close` | yes |
+| `.verifying.md` | `known-error` | yes — **flip-back**: the fix recurred or proved incomplete. Required by `review-problems` Bucket 3, `manage-problem`, and `run-retro` Step 4a, all of which already instruct it. |
+| `.closed.md` | `known-error` | yes — **reopen**: a close was wrong. This is the recovery path every evidence-authorised close reports (the "The Verification Pending → Closed transition is reserved for the maintainer, so evidence-based closure never fires and the verification queue grows without bound" problem), so it has to be reachable or the reversibility that justifies closing without a consent gate is fiction. |
 | any other pairing | — | no — emit an error and stop |
 
+The two backward pairings are what make an agent-authorised close safe to make. The argument for closing on evidence without asking is that the close is cheap and reversible; a reopen route the skill refuses would make that argument false. Both are ordinary renames — `git mv` back to `known-error/`, Status field back to `Known Error`, append the recurrence or mis-close citation to the ticket body, refresh the README, one commit per the "Governance Skills Commit Their Own Completed Work" architecture rule — and neither re-runs the Open → Known Error pre-flight, because root cause and workaround were established the first time round. (the "The transition lifecycle table rejects both the fix-on-capture fast path and its own documented recovery path" problem tracks the wider set of missing pairings, including the fix-on-capture fast path.)
+
 If the pairing is invalid, emit a clear message naming the current status, the requested destination, and the valid next step. Do not silently skip or auto-correct — invalid transitions are almost always user typos and a clear error is the cheapest recovery.
 
 ### 4. Run pre-flight checks
@@ -128,9 +132,34 @@ Emit a structured report naming each deferred section + the lifted condition + t
 
 This check fires BEFORE the "derive-release-vehicle helper requires pre-edit of ticket changeset reference — three-touch when one-touch would suffice" problem Release-vehicle seed step in Step 6 — halt-on-conditional-deferral is the outer gate, seed-and-rename is the inner mechanic.
 
-**Verification Pending → Closed** (`<status>` = `close`) requires:
+**Verification Pending → Closed** (`<status>` = `close`) requires **either** of:
+
+- [ ] **Cited evidence** that meets the ticket's own stated close criterion — a test invocation and its outcome, a commit SHA whose diff covers the fix path, a skill or hook invocation that exercised the fix and behaved as the fix contracts, a post-release invocation of the shipped artefact that behaved as the fix contracts, or a `yes — observed: <citation>` cell already carried in the Verification Queue. The agent closes on its own authority and records the citation in the closure. **Mechanical stage — do NOT fire `request_user_input`** (the "Agents over-ask in interactive sessions — conflating mechanical-stages with user-interactive-stages of multi-stage skill contracts (inverse-)" problem / the "— Decision-Delegation Contract: when agents act on the framework vs ask the user" architecture rule category 4, mirroring the shipped `review-problems` Step 4 Bucket 1 and `run-retro` Step 4a sub-step 5). Surface the recovery path alongside the close: `Recovery: rerun /wr-itil:transition-problem <NNN> known-error to reopen`.
+- [ ] **The user has explicitly confirmed** the fix works in production, or an orchestrator supplied the `close` argument under prior user authorisation.
+
+**Never close on inference — absence of evidence is not evidence.** A ticket nobody exercised stays Verification Pending, however old it is and however plausible the fix looks. "The fix is on disk", "it has been months", "that area has been touched a lot" and "the ADR that prescribed it shipped" are inference, not observation — see the "Relevance-close evaluator over-fires — a bare ADR/skill citation is read as "fix shipped", so live tickets return CLOSE-CANDIDATE" problem for what happens when a bare citation is read as proof of shipping. Closing tickets nobody exercised is the opposite failure and is exactly as wrong as never closing any.
+
+**Genuine ambiguity stays the user's surface** — contested evidence, a fix that covers only part of the ticket, or a recorded do-not-close marker. Run the mechanical check first; it is a field read, not a judgement:
+
+```bash
+<itil-plugin-root>/bin/wr-itil-is-close-blocked <NNN> docs/problems && close_blocked=1
+```
+
+Exit 0 means **BLOCKED**: the ticket carries a line-anchored `DO NOT CLOSE` marker (`docs/problems/verifying/151-*.md` § "Regression / incomplete observed … DO NOT CLOSE" is the canonical shape). Do NOT close it whatever the evidence says — route it to the `verifying → known-error` flip-back, or queue it for the user. Exit 1 means not blocked. Exit 2 means the ticket ref did not resolve — treat as a pre-flight failure, not as permission.
+
+**Evidence-authorised tracker updates.** Write the basis into the ticket's `**Status**:` line alongside the citation (`**Status**: Closed (closed-on-evidence <YYYY-MM-DD> — <citation>. Recovery: rerun /wr-itil:transition-problem <NNN> known-error to reopen)`). A provenance-proven GitHub issue on this project's tracker receives the gated comment and closes; unresolved or non-issue inbound provenance performs no issue mutation. A foreign issue receives the comment but stays open on our evidence alone; that upstream party's confirmation may authorize closure. Pull requests remain comment-only.
 
-- [ ] The user has explicitly confirmed the fix works in production (this skill never auto-closes on inference — only on explicit user confirmation or orchestrator-supplied `close` argument)
+Authority: the "— Decision-Delegation Contract: when agents act on the framework vs ask the user" architecture rule (framework-resolution boundary — evidence-backed close is category 4, silent framework action; contested or absent evidence is category 1, queued not guessed), the "Agent output grounding — no fabricated quantitative estimates, cite + persist + uncertainty" architecture rule (cite the evidence, persist it, state the uncertainty), the "Structured User Interaction for Governance-Skill Decisions" architecture rule Rule 5 (policy-authorised silent proceed), the "Evidence-based relevance-close pass for the problem backlog (Phase 1: file-no-longer-exists; Phase 2: ADR-shipped-confirmed + named-skill-exists + self-marker-in-body + driver-child-closed + Phase 1 false-positive fixes)" architecture rule (evidence-based closure precedent on the open/known-error side of the same lifecycle), the "The Verification Pending → Closed transition is reserved for the maintainer, so evidence-based closure never fires and the verification queue grows without bound" problem (this contract).
+
+**Verification Pending → Known Error** (`<status>` = `known-error` — flip-back) requires:
+
+- [ ] A recurrence or incompleteness citation: what was observed, and when. Append it to the ticket body; the `Likely verified?` cell becomes `no — observed regression — <one-line citation>`.
+
+**Closed → Known Error** (`<status>` = `known-error` — reopen) requires:
+
+- [ ] A stated reason the close was wrong. Nothing more — this is the recovery path for an evidence-authorised close and it must stay one command deep, or the reversibility that justifies closing without a consent gate is not real.
+
+Neither backward pairing re-runs the Open → Known Error pre-flight above: root cause and workaround were established when the ticket first reached Known Error and are still on the ticket. Neither fires the "Problem 063: manage-problem does not trigger /wr-itil:report-upstream when root cause is external" problem external-root-cause detection (Step 5 is Open → Known Error only).
 
 ### 5. External-root-cause detection (the "Problem 063: manage-problem does not trigger /wr-itil:report-upstream when root cause is external" problem — Open → Known Error only)
 
@@ -206,7 +235,7 @@ git mv docs/problems/known-error/<NNN>-<title>.md docs/problems/verifying/<NNN>-
 git add docs/problems/verifying/<NNN>-<title>.md
 ```
 
-The `## Fix Released` section contains: release marker (version, commit SHA, or date), one-sentence fix summary, "Awaiting user verification" line, and any exercise evidence from the releasing session. The `.verifying.md` suffix signals to every downstream consumer (work-problems classifier, review step 9d, README rendering) that the remaining work is user-side verification — no file-body scan needed.
+The `## Fix Released` section contains: release marker (version, commit SHA, or date), one-sentence fix summary, "Awaiting user verification" line, and any exercise evidence from the releasing session. The `.verifying.md` suffix signals to every downstream consumer (work-problems classifier, review step 9d, README rendering) that the remaining work is verification — by evidence or by the user — no file-body scan needed.
 
 When this transition is folded into a `fix(<scope>): ... (closes P<NNN>)` commit (the common case), the `git mv` + `Edit` + re-stage + README refresh all join that single commit — never split across commits.
 
@@ -241,10 +270,17 @@ Use the structured values verbatim when authoring the `## Fix Released` section'
 
 ```bash
 git mv docs/problems/verifying/<NNN>-<title>.md docs/problems/closed/<NNN>-<title>.md
-# ... use the Edit tool to update the Status field to "Closed" ...
+# ... use the Edit tool to update the Status field per the shape below ...
 git add docs/problems/closed/<NNN>-<title>.md
 ```
 
+**Write the close's authority basis into the Status field.** The Status line is the only place the basis survives — the `Likely verified?` cell lives in the README's Verification Queue table, and that row is deleted by this very transition, so a downstream reader (Step 7b's upstream leg) would find nothing there. Shape, matching what the 2026-07-15 closes already wrote (`docs/problems/closed/186-*.md:3`):
+
+- Evidence-authorised: `**Status**: Closed (closed-on-evidence <YYYY-MM-DD> — <citation>. Recovery: rerun /wr-itil:transition-problem <NNN> known-error to reopen)`
+- User-confirmed: `**Status**: Closed (user-confirmed <YYYY-MM-DD>)`
+
+`closed-on-evidence` is what the outbound leg reads to keep a foreign issue open on our evidence alone. The inbound leg uses committed issue-channel provenance instead: ambiguity fails closed before any issue operation.
+
 ### 7. Refresh docs/problems/README.md (the "Problem 062: `manage-problem` does not refresh `docs/problems/README.md` on single-ticket transitions; fast-path cache goes stale silently" problem)
 
 Every Step 7 status transition regenerates `docs/problems/README.md` and stages it in the same commit so the dev-work table, Verification Queue, Parked section, and "Last reviewed" line never lag the on-disk ticket inventory. Without this step, README.md accumulates staleness between review invocations.

package/skills-codex/transition-problems/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: wr-itil:transition-problems
+name: transition-problems
 description: "Batch-advance multiple problem tickets through the lifecycle in one invocation — Open → Known Error, Known Error → Verification Pending, Verification Pending → Closed. Loops the per-ticket /wr-itil:transition-problem mechanic (rename, Status edit, the "Problem 057: `git mv` + Edit + `git add` staging-ordering trap drops content edits from the commit" problem re-stage, the "Problem 063: manage-problem does not trigger /wr-itil:report-upstream when root cause is external" problem external-root-cause detection, the "Problem 062: `manage-problem` does not refresh `docs/problems/README.md` on single-ticket transitions; fast-path cache goes stale silently" problem README refresh) without paying N× SKILL.md reload latency or violating split-skill execution ownership. Produces ONE shared commit covering all surviving transitions per the "Governance Skills Commit Their Own Completed Work" architecture rule batch-grain. Use when closing the Verification Queue at the end of a `/wr-retrospective:run-retro` Step 4a pass, batch-closing release-aged verifyings during `/wr-itil:work-problems` AFK orchestration, or confirming multiple Step 9d verifications in `/wr-itil:manage-problem review`. Singular sibling — `/wr-itil:transition-problem` (one ticket per invocation)."
 allowed-tools: Read, Write, Edit, Bash, Glob, Grep, request_user_input, Skill, Agent
 ---
@@ -46,7 +46,7 @@ A space-separated list of `<NNN> <status>` pairs. Repeating the singular skill's
 - `<status>` — destination status. One of:
   - `known-error` — Open → Known Error (root cause + workaround documented).
   - `verifying` — Known Error → Verification Pending (fix released; awaiting user verification per the "Problem lifecycle — add a Verification Pending status between Known Error and Closed" architecture rule).
-  - `close` — Verification Pending → Closed (user has confirmed the fix works in production).
+  - `close` — Verification Pending → Closed (cited evidence meets the ticket's own close criterion, OR the user has confirmed the fix works in production — see Step 2c).
 
 **Examples:**
 
@@ -111,13 +111,19 @@ If no file is found OR multiple files are found (suffix-exclusive lifecycle viol
 | `.open.md` | `known-error` | yes |
 | `.known-error.md` | `verifying` | yes |
 | `.verifying.md` | `close` | yes |
+| `.verifying.md` | `known-error` | yes — **flip-back**: the fix recurred or proved incomplete. `review-problems` Bucket 3 already instructs this and had no batch path. |
+| `.closed.md` | `known-error` | yes — **reopen**: a close was wrong. The recovery path every evidence-authorised close reports (the "The Verification Pending → Closed transition is reserved for the maintainer, so evidence-based closure never fires and the verification queue grows without bound" problem). |
 | any other pairing | — | no — record as `invalid-transition` and continue |
 
+Lockstep with `/wr-itil:transition-problem` Step 3 per the drift clause below — the singular and plural tables move together or neither moves. The two backward pairings are what make an agent-authorised close safe: the argument for closing on evidence without asking is that the close is cheap and reversible, and a reopen route either skill refuses would make that argument false. Both are ordinary renames; neither re-runs the Open → Known Error pre-flight (root cause and workaround were established the first time round) and neither fires the "Problem 063: manage-problem does not trigger /wr-itil:report-upstream when root cause is external" problem detection at 2d.
+
 **2c. Run pre-flight checks** for the destination (same gating as the singular):
 
 - Open → Known Error (`known-error`): root cause documented; ≥ 1 investigation task ticked; reproduction test or reference; workaround documented; effort bucket re-rated if scope shifted (the "Problem 047: WSJF effort buckets are coarse and not re-rated at lifecycle transitions" problem); status multiplier re-rated from Open 1.0 to Known Error 2.0 and WSJF recomputed with the post-transition status and current Effort (the "WSJF uses the pre-transition status multiplier" problem).
 - Known Error → Verification Pending (`verifying`): fix implemented; release marker available (version, commit SHA, or date) for the `## Fix Released` section.
-- Verification Pending → Closed (`close`): user has explicitly confirmed the fix works in production. AFK callers (work-problems orchestrator) MUST supply the close pair via prior user authorisation (e.g. an `request_user_input`-batched closure prompt at the orchestrator layer); this skill never auto-closes on inference.
+- Verification Pending → Closed (`close`): cited observed evidence or explicit user confirmation authorizes closure. Evidence-backed closure is mechanical and does not require another question. Record the citation and recovery path (`/wr-itil:transition-problem <NNN> known-error`) in each ticket's Status line. A provenance-proven GitHub issue on this project's tracker receives the gated comment and closes; unresolved or non-issue inbound provenance performs no issue mutation. A foreign issue receives the comment but stays open on local evidence alone; that upstream party's confirmation may authorize closure. Pull requests remain comment-only.
+
+  **Never close on inference** — absence of evidence is not evidence. A pair whose ticket carries no citation records as `pre-flight-failed` with reason `no-evidence` and stays Verification Pending; age, plausibility, and "the fix is on disk" are not observations. **Do-not-close marker check** — run `<itil-plugin-root>/bin/wr-itil-is-close-blocked <NNN> docs/problems` per pair before closing. Exit 0 → record the pair as `pre-flight-failed` with reason `close-blocked` plus the matched marker line, and continue to the next pair; do NOT close it whatever the evidence says. Exit 2 (unresolvable ref) is a pre-flight failure, not permission.
 
 If any pre-flight fails, record the pair as `pre-flight-failed` with the failed-check list and continue to the next pair.
 
@@ -162,10 +168,18 @@ git add docs/problems/verifying/<NNN>-<title>.md
 ```bash
 # Verification Pending → Closed
 git mv docs/problems/verifying/<NNN>-<title>.md docs/problems/closed/<NNN>-<title>.md
-# Edit Status field to "Closed"
+# Edit Status field per the shape below
 git add docs/problems/closed/<NNN>-<title>.md
 ```
 
+**Write the close's authority basis into the Status field.** The Status line is the only place the basis survives — the `Likely verified?` cell lives in the README's Verification Queue table, and that row is deleted by this very transition, so a downstream reader (Step 7b's upstream leg) would find nothing there. Shape, matching what the 2026-07-15 closes already wrote (`docs/problems/closed/186-*.md:3`):
+
+- Evidence-authorised: `**Status**: Closed (closed-on-evidence <YYYY-MM-DD> — <citation>. Recovery: rerun /wr-itil:transition-problem <NNN> known-error to reopen)`
+- User-confirmed: `**Status**: Closed (user-confirmed <YYYY-MM-DD>)`
+
+`closed-on-evidence` is what the outbound leg reads to keep a foreign issue open on our evidence alone. The inbound leg uses committed issue-channel provenance instead: ambiguity fails closed before any issue operation.
+
+
 If `git mv` or `git add` fails for a pair (e.g. the file has been moved by a parallel process), record the pair as `git-failed` with the error and continue to the next pair. Do NOT attempt to roll back prior pairs' staged renames — those are now part of the in-progress batch.
 
 Record each pair's outcome (succeeded / failed-with-reason) for the summary in Step 5.

package/skills-codex/update-upstream/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: wr-itil:update-upstream
+name: update-upstream
 description: Post a lifecycle-update comment to an upstream issue when a local problem ticket transitions. Drafts a transition-specific update (root-cause confirmed / fix released / closed), composes the prose through the external-comms risk gate + voice-tone gate, auto-posts within appetite, queues above-appetite. Reciprocal sibling to /wr-itil:report-upstream — initial-filing vs lifecycle-update split per the "Cross-project problem-reporting contract — `report-upstream` skill in `@windyroad/itil`" architecture rule amendment (the "Problem 080: No bidirectional update of upstream-reported problems — local lifecycle transitions never propagate back to the reporter" problem).
 allowed-tools: Read, Write, Edit, Bash, Glob, Grep, request_user_input, Skill, Agent
 ---
@@ -178,7 +178,7 @@ Update from <downstream-repo-url>/<local-ticket-relative-path>:
 
 <one-sentence summary from the local ticket's ## Fix Released section>
 
-Please upgrade and verify when convenient. We'll close this issue after your confirmation OR after a 14-day quiet period (per the "Problem 048: manage-problem does not surface Fix Released problems as verification candidates when the fix path has been exercised" problem default). Local tracking: P<NNN>.
+Please upgrade and verify when convenient. We'll close this issue after your confirmation. If you'd rather we closed it without one, say so here. Local tracking: P<NNN>.
 ```
 
 #### Verification Pending → Closed template
@@ -186,12 +186,38 @@ Please upgrade and verify when convenient. We'll close this issue after your con
 ```markdown
 Update from <downstream-repo-url>/<local-ticket-relative-path>:
 
-**Status**: Closed locally after user-side verification.
+**Status**: Closed locally after verification.
 
-Closing this issue to match. Thanks for the report — your filing is what got this on the queue. Local tracking: P<NNN>.
+Thanks for the report — your filing is what got this on the queue. Local tracking: P<NNN>.
 ```
 
-After posting the Verifying → Closed comment, the skill also runs `gh issue close <n>` (per Step 5b below) so the upstream tracker matches local state.
+After posting the Verifying → Closed comment, leave the foreign issue open by default. Closing it requires the target-bound upstream-party confirmation below.
+
+#### Foreign issues close only on target-bound upstream-party confirmation
+
+Local evidence or local user confirmation can close our ticket, but neither decides another maintainer's tracker state. Post the lifecycle comment and **stop there** unless the local ticket's `## Reported Upstream` section carries this durable, target-bound signal:
+
+```markdown
+- **Closure authority**: upstream-confirmed <exact GitHub issue-comment URL>
+```
+
+Before running `gh issue close`, validate that URL read-only: it MUST be an `#issuecomment-<id>` URL on the exact `UPSTREAM_OWNER_REPO/issues/UPSTREAM_ISSUE_NUMBER` target; `gh api repos/<owner>/<repo>/issues/comments/<id>` MUST return that exact issue URL; `author_association` MUST be `OWNER`, `MEMBER`, or `COLLABORATOR`; and the comment body MUST unambiguously authorize closing this issue. A missing marker, URL mismatch, API failure, non-maintainer association, or ambiguous body leaves the issue open. Never infer this authority from a local `user-confirmed` Status marker.
+
+Read the Status line, not the README's `Likely verified?` cell: the close deletes that row from the Verification Queue before this step runs, so the cell is gone by the time anything could read it.
+
+Confirmation from the upstream party may authorize closing their issue; their word, not our evidence, supplies the missing authority. Do not promise a quiet-period close that no mechanism delivers.
+
+When target-bound confirmation is absent, use the evidence-authorised local-close-only variant below and record `posted-comment-local-close-only` in the back-write disclosure path. When validation succeeds, use the ordinary Closed template and record `posted-comment-and-closed`.
+
+```markdown
+Update from <downstream-repo-url>/<local-ticket-relative-path>:
+
+**Status**: Closed locally. We verified the fix on our side — <one-line evidence citation>.
+
+Leaving this issue open for you. Close it whenever you have confirmed the fix works in your setup. Local tracking: P<NNN>.
+```
+
+On this leg, without validated target-bound confirmation from them: comment, do not close. Pull requests are always comment-only, even if they carry a confirmation marker.
 
 #### Template-filling rules
 
@@ -267,7 +293,7 @@ gh issue comment "${UPSTREAM_ISSUE_NUMBER}" \
 
 Capture the returned comment URL (gh prints `https://github.com/<owner>/<repo>/issues/<n>#issuecomment-<id>`).
 
-On the **Verifying → Closed** transition, after posting the comment, also close the upstream issue:
+On the **Verifying → Closed** transition, after posting the comment, close the upstream issue only when the target-bound `Closure authority` validation above passed:
 
 ```bash
 gh issue close "${UPSTREAM_ISSUE_NUMBER}" \
@@ -298,7 +324,7 @@ Append a log entry to the local ticket's `## Upstream Lifecycle Updates` section
 - **<YYYY-MM-DD>** — Open → Known Error
   - **Target URL**: <upstream-issue-url>
   - **Comment URL**: <posted-comment-url> (or "queued — see ## Queued Upstream Update" when above-appetite)
-  - **Disclosure path**: posted-comment | posted-pr-comment (pull-request target, the "Prefer an upstream pull request over an issue when the upstream accepts pull requests" architecture rule — never closed) | posted-comment-and-closed (Verifying → Closed, issue targets only) | queued-above-appetite | closed-already-upstream | skipped-out-of-band
+  - **Disclosure path**: posted-comment | posted-pr-comment (pull-request target — never closed) | posted-comment-and-closed (confirmed Verifying → Closed, issue targets only) | posted-comment-local-close-only (outbound evidence-authorised close) | queued-above-appetite | closed-already-upstream | skipped-out-of-band
   - **Gate verdict**: external-comms <band/score> + voice-tone <pass|fail>
 
 - **<YYYY-MM-DD>** — Known Error → Verification Pending
@@ -317,7 +343,51 @@ This leg runs **in addition to** Steps 2–6 (the outbound `## Reported Upstream
 
 #### I1. Parse the inbound origin
 
-From the `**Origin**: inbound-reported (#NN)` field, extract the originating issue number `NN`. Resolve the repo it lives on as **our own repo** — the `gh` default for the current working tree (`gh repo view --json nameWithOwner -q .nameWithOwner`), NOT an external upstream owner/repo. If the `**Origin**` field is `internal` or absent, this leg does not run (the no-op is already handled at Step 1 when both surfaces are absent).
+From the `**Origin**: inbound-reported (#NN)` field, extract the candidate number `NN`. That untyped number is not proof of an issue: issues, discussions, and advisories have distinct mutation paths, and numeric identifiers can collide.
+
+Before any inbound `gh issue view`, `gh issue comment`, or `gh issue close`, prove the channel from the committed discovery cache:
+
+```bash
+OWN_OWNER_REPO=$(gh repo view --json nameWithOwner -q .nameWithOwner)
+LOCAL_TICKET_ID="P${LOCAL_ID}"
+ISSUE_CHANNEL="github-issues:${OWN_OWNER_REPO}"
+CACHE_REF="HEAD:docs/problems/.upstream-cache.json"
+CACHE_JSON=$(git show "${CACHE_REF}" 2>/dev/null) || CACHE_JSON='{}'
+
+ISSUE_NUMBER_MATCHES=$(printf '%s' "${CACHE_JSON}" | jq \
+  --arg channel "${ISSUE_CHANNEL}" \
+  --argjson number "${NN}" \
+  '[.channels[$channel].reports[]? | select(.number == $number)] | length' \
+  2>/dev/null) || ISSUE_NUMBER_MATCHES=0
+
+ISSUE_TICKET_MATCHES=$(printf '%s' "${CACHE_JSON}" | jq \
+  --arg channel "${ISSUE_CHANNEL}" \
+  --argjson number "${NN}" \
+  --arg ticket "${LOCAL_TICKET_ID}" \
+  '[.channels[$channel].reports[]? |
+    select(.number == $number and .matched_local_ticket == $ticket)] | length' \
+  2>/dev/null) || ISSUE_TICKET_MATCHES=0
+
+NON_ISSUE_MATCHES=$(printf '%s' "${CACHE_JSON}" | jq \
+  --arg issue_channel "${ISSUE_CHANNEL}" \
+  --arg repo_suffix ":${OWN_OWNER_REPO}" \
+  --argjson number "${NN}" \
+  '[.channels | to_entries[] |
+    select(.key != $issue_channel and (.key | endswith($repo_suffix))) |
+    .value.reports[]? | select(.number == $number)] | length' \
+  2>/dev/null) || NON_ISSUE_MATCHES=0
+
+if [ "${ISSUE_NUMBER_MATCHES}" -ne 1 ] || \
+   [ "${ISSUE_TICKET_MATCHES}" -ne 1 ] || \
+   [ "${NON_ISSUE_MATCHES}" -ne 0 ]; then
+  echo "inbound-channel-unresolved: ${LOCAL_TICKET_ID} #${NN}"
+  INBOUND_CHANNEL_RESOLVED=0
+else
+  INBOUND_CHANNEL_RESOLVED=1
+fi
+```
+
+When `INBOUND_CHANNEL_RESOLVED=0`, skip I2–I6 and perform no inbound issue operation; an independent outbound leg may still continue. Missing committed cache data, zero or multiple issue matches, a repository mismatch, a wrong `matched_local_ticket`, or a discussion/advisory collision all take this path. If the Origin field is `internal` or absent, this leg does not run.
 
 #### I2. Determine the transition (same suffix logic as Step 3)
 
@@ -441,12 +511,14 @@ Above-appetite handling is identical to Step 5c (silent risk-reduce + re-score;
 gh issue comment "${NN}" --repo "${OWN_OWNER_REPO}" --body "${INBOUND_BODY}"
 ```
 
-On the **Verification Pending → Closed** transition, after the comment, also close the originating issue so our own tracker matches the local `.closed.md` state (this addresses the "work-problems orchestrator carries prior-ticket Fix Strategy text into iter dispatch without re-grounding in design intent" problem #97 *silent-and-unclosed* witness):
+On the **Verification Pending → Closed** transition, after the comment, close the provenance-proven issue on this project's tracker whether the local close was confirmed or evidence-authorised:
 
 ```bash
 gh issue close "${NN}" --repo "${OWN_OWNER_REPO}" --comment "" --reason completed
 ```
 
+This outbound guard does not apply to a provenance-proven GitHub issue on this project's own repository. After the gated comment, close it whether the local close was evidence-authorised or confirmed; the reporter can reopen it. Unknown or non-issue inbound channels already stopped at the provenance guard.
+
 If the issue is already closed (someone closed it manually), `gh issue close` returns a benign error — record `closed-already` in the disclosure path and continue.
 
 #### I6. Back-write to the lifecycle log
@@ -457,7 +529,7 @@ Append to the same `## Upstream Lifecycle Updates` log (Step 6 shape), tagged fo
 - **<YYYY-MM-DD>** — Known Error → Verification Pending (inbound)
   - **Target**: inbound #<NN> (own repo <OWN_OWNER_REPO>)
   - **Comment URL**: <posted-comment-url> (or "skipped — already-posted-inbound" when the idempotency guard matched, or "queued — see ## Queued Upstream Update" when above-appetite)
-  - **Disclosure path**: posted-inbound-comment | posted-inbound-comment-and-closed (Verifying → Closed) | already-posted-inbound | queued-above-appetite | closed-already
+  - **Disclosure path**: posted-inbound-comment | posted-inbound-comment-and-closed (proven owned issue, confirmed or evidence-authorised close) | already-posted-inbound | queued-above-appetite | closed-already | inbound-channel-unresolved
   - **Gate verdict**: external-comms <band/score> + voice-tone <pass|fail>
 ```
 

package/skills-codex/work-problem/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: wr-itil:work-problem
+name: work-problem
 description: Pick the highest-WSJF open or known-error problem ticket and work it — investigate, implement, commit, and release per the standard manage-problem workflow. Selection is framework-mediated (WSJF + documented tie-break ladder per the "— Decision-Delegation Contract: when agents act on the framework vs ask the user" architecture rule); singular variant; distinct from /wr-itil:work-problems (plural AFK orchestrator). Use this when the user asks to "work the next problem", "work the top of the queue", or "grind through one ticket".
 allowed-tools: Read, Write, Edit, Bash, Glob, Grep, request_user_input, Skill, Agent
 ---

package/skills-codex/work-problems/SKILL.md

@@ -1,6 +1,6 @@
 ---
-name: wr-itil:work-problems
-description: Drain the ITIL problem backlog in WSJF order using native Codex subagents, governed commits, pushes, and releases.
+name: work-problems
+description: Drain the ITIL problem backlog in WSJF order using isolated Codex CLI iterations, governed commits, pushes, and releases.
 ---
 
 <!-- Generated from the runtime-neutral skill source. Do not edit. -->
@@ -16,32 +16,85 @@ description: Drain the ITIL problem backlog in WSJF order using native Codex sub
 
 # Work Problems in Codex
 
-Continuously work the highest-priority actionable problem until the backlog is drained, the user stops, or a real governance dependency requires human direction. Use Codex's native subagent tools. Never invoke `codex exec`, start a nested Codex CLI, or implement process/PID polling.
+Continuously work the highest-priority actionable problem until the backlog is drained, the user stops, or a real governance dependency requires human direction. Run each selected problem in one fresh `codex exec` process and consume its structured result before continuing.
 
 ## Preflight
 
 1. If `docs/problems/` is absent, direct the user to `/wr-itil:scaffold-intake` and stop.
 2. Run the installed ITIL maintenance commands required by the repository, including layout migration, README reconciliation, catch-up scanning, stale upstream-cache checks, and unresolved-response checks. Resolve them from the plugin's bundled `bin/`; do not use source-repository paths.
-3. Preserve unrelated working-tree changes. Revert only changes created by a failed preflight.
-4. If the task has a persistent Codex goal, keep it active until this drain reaches a genuine terminal state. A slow tool or subagent is not a blocker.
+3. Resolve the exact checkout with `git rev-parse --show-toplevel`. Preserve unrelated working-tree changes and record the pre-iteration status. Revert only paths proven to have been created by a failed iteration.
+4. If the task has a persistent Codex goal, keep it active until this drain reaches a genuine terminal state. A slow process is not a blocker.
 
 ## Loop
 
 1. Read the problem index and current ticket files. Select the highest WSJF problem in the highest non-empty actionable tier. Use the documented tie-break rules.
 2. Skip tickets whose required JTBD, decision, risk, or story-map oversight is unconfirmed. Record one structured outstanding question for each genuinely user-answerable dependency; do not ask mid-loop.
 3. Run the relevance and stop-condition checks. Before declaring `ALL_DONE`, run the repository's unconditional pre-completion gates and rescan the backlog.
-4. Spawn one native Codex subagent for the selected ticket. Give it the exact checkout, ticket, applicable decisions, and this contract:
-   - invoke `/wr-itil:manage-problem` for the ticket and follow its lifecycle rules;
-   - make only in-scope changes and preserve unrelated work;
-   - run focused tests and the required architecture/risk checks;
-   - create the required changeset for shippable plugin behavior;
-   - commit the completed iteration, but do not push or release;
-   - return one `ITERATION_SUMMARY` JSON object containing ticket, action, commits, tests, risks, outstanding questions, and remaining work.
-5. Wait for that same subagent. Do not cancel, replace, retry, or fan out merely because Cruise or normal model execution makes the call slow. When it completes, consume its summary and close it.
-6. Validate the summary with `<itil-plugin-root>/bin/wr-itil-verify-iter-summary`. If the subagent failed after changing the checkout, inspect and safely complete or revert only its own partial work before continuing.
+4. Dispatch exactly the selected ticket through the isolated Codex command below. Do not select or work a second ticket inside that process.
+5. Wait for that same process. Do not cancel, replace, retry, or fan out merely because normal model execution is slow.
+6. Classify the exit and JSONL metadata before reading the final-output file. On success, validate the summary with `<itil-plugin-root>/bin/wr-itil-verify-iter-summary` and consume it. On failure, apply the recovery contract below and halt.
 7. Run inter-iteration verification. If the iteration produced committed shippable work, complete the repository's governed push and release cadence when risk is within appetite. Above-appetite risk is a remediation instruction: reduce scope or split the change; never ask the user to approve risk above appetite.
 8. Report only material progress, then rescan and repeat.
 
+## Isolated Codex iteration
+
+Build a self-contained prompt containing the selected ticket ID and title, the exact checkout, applicable confirmed decisions, and these requirements:
+
+- invoke `/wr-itil:manage-problem <number>` and work only that problem;
+- preserve unrelated work and use path-scoped staging;
+- load and obey the installed governance skills, agents, and hooks;
+- run focused tests and required architecture, JTBD, voice, accessibility, and risk checks when their gates apply;
+- add a changeset for shippable package behavior;
+- commit completed iteration work, but do not push or release;
+- invoke `/wr-retrospective:run-retro` before the final response, commit any retro-owned briefing refresh through its governed path, and continue to the summary even if retro reports a non-blocking failure;
+- end with one `ITERATION_SUMMARY` containing ticket, action, outcome, commit state, tests, risks, outstanding questions, remaining work, and notes.
+
+Run the nested process in the outer session's installed Codex environment. Do not replace `CODEX_HOME` or ignore user configuration: the inherited plugin registry and hooks are the governance surface. Export the three AFK guards so pending interactive questions, oversight nudges, and machine-authored correction text do not leak into the isolated turn.
+
+```bash
+ITERATION_CHECKOUT="$(git rev-parse --show-toplevel)"
+ITERATION_JSONL="$(mktemp)"
+ITERATION_FINAL="$(mktemp)"
+
+export WR_SUPPRESS_PENDING_QUESTIONS=1
+export WR_SUPPRESS_OVERSIGHT_NUDGE=1
+export WR_SUPPRESS_CORRECTION_DETECT=1
+
+codex exec \
+  --ephemeral \
+  --dangerously-bypass-approvals-and-sandbox \
+  --dangerously-bypass-hook-trust \
+  --cd "$ITERATION_CHECKOUT" \
+  --json \
+  --output-last-message "$ITERATION_FINAL" \
+  "$ITERATION_PROMPT" \
+  >"$ITERATION_JSONL" 2>&1
+ITERATION_EXIT=$?
+```
+
+The two output channels are load-bearing and must stay separate:
+
+- `ITERATION_JSONL` carries progress and error metadata only. Parse it as JSONL; never scrape the final agent message from this stream.
+- `ITERATION_FINAL` carries the final agent message. Read `ITERATION_SUMMARY` only from this file after the exit and metadata checks pass.
+
+Always remove both temporary files after their contents have been classified and consumed.
+
+## Error classification and recovery
+
+Classify in this order:
+
+1. A non-zero process exit halts the loop. Use the exit code plus JSONL error messages to report `quota exhausted`, `rate limited`, `authentication failed`, `service overloaded`, or `execution failed`; do not call a quota failure merely unavailable.
+2. Exit zero with a JSONL `error` or `turn.failed` event also halts before summary parsing. Apply the same message classification. A final-output file does not override an error event.
+3. Exit zero without an error event permits final-output parsing. The file must contain exactly one valid `ITERATION_SUMMARY` for the selected ticket; otherwise halt as `invalid iteration summary`.
+
+After every exit, record the checkout delta against the pre-iteration status for diagnosis, without mutation. Recovery may begin only after exit zero, error-free JSONL, and exactly one valid `ITERATION_SUMMARY` for the selected ticket. Missing, multiple, or wrong-ticket summaries halt without recovery. Then compare the checkout with the recorded pre-iteration status:
+
+- A clean checkout proceeds normally.
+- A coherent commit named by the valid summary proceeds to inter-iteration verification.
+- Coherent staged work attributable only to the selected ticket may be recovered only after its focused tests and governance gates pass again in the outer session.
+- Ambiguous, unstaged, or unrelated changes hard-block recovery. Report their paths and halt without mutation.
+- When a failed iteration created known disposable paths, restore only the explicit verified path list with path-scoped Git commands. Never use a broad reset, clean, checkout, restore, or stash operation.
+
 ## Fix Proposal Rule
 
 A fix proposal is a release row on an existing story map, never a new file under `docs/rfcs/`. The row has an identity from `<itil-plugin-root>/bin/wr-itil-next-rfc-id`, at least one story card, and a story whose `problems:` list names the driving problem. Creating a new map, activity column, job, or uncovered architectural choice requires a queued human decision rather than a silent edit.
@@ -50,9 +103,9 @@ A fix proposal is a release row on an existing story map, never a new file under
 
 - Batch outstanding questions at loop end with `request_user_input`, no more than four per call. Brief substance before IDs.
 - Continue past skipped tickets when another actionable ticket exists.
-- Stop only for an explicit user stop, a fully drained backlog, a governance dependency that blocks every remaining ticket, or an unrecoverable tool/repository failure.
-- Never describe a delayed native tool or subagent as unavailable, hung, or blocked without an actual error or terminal failure.
+- Stop only for an explicit user stop, a fully drained backlog, a governance dependency that blocks every remaining ticket, confirmed quota exhaustion, or an unrecoverable process or repository failure.
+- Never describe a delayed process as unavailable, hung, or blocked without an actual error or terminal failure.
 
 ## Final Report
 
-Report completed and skipped tickets, commits, tests, push/release outcomes, remaining backlog, and outstanding design questions. Preserve the distinction between committed, pushed, released, and production-verified states.
+Report completed and skipped tickets, commits, tests, push and release outcomes, remaining backlog, and outstanding design questions. Preserve the distinction between committed, pushed, released, and production-verified states.