@windyroad/itil 2.0.0 → 2.1.0

package/.claude-plugin/plugin.json

@@ -497,5 +497,5 @@
     }
   },
   "name": "wr-itil",
-  "version": "2.0.0"
+  "version": "2.1.0"
 }

package/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "wr-itil",
-  "version": "2.0.0",
+  "version": "2.1.0",
   "description": "ITIL problem-management workflows for AI coding agents",
   "author": {
     "name": "Windy Road Technology",

package/bin/wr-itil-is-close-blocked

@@ -0,0 +1,51 @@
+#!/usr/bin/env bash
+# Generated by scripts/sync-shim-wrappers.sh from
+# packages/shared/lib/shim-wrapper-template.sh. DO NOT EDIT individual
+# shim files in packages/*/bin/wr-* directly; edit the template + run
+# `npm run sync:shim-wrappers` to regenerate.
+#
+# Resolution (highest-version-wins-shim-wrapper-for-plugin-scaffold-template-shims-architecture-rule):
+#   1. If the wrapper's parent dir is semver-shaped, treat as installed-
+#      cache execution and resolve to the highest-version sibling's
+#      scripts/ entry below.
+#   2. Otherwise (parent dir is e.g. `architect`), treat as source-
+#      monorepo execution and dispatch to own scripts/. The source-repo-
+#      guard `exec` is the anchor parsed by
+#      packages/retrospective/scripts/check-tarball-shipped-shims.sh.
+#   3. If the cache parent contains zero semver-shaped siblings, exit
+#      127 with a stderr message naming the cache parent (per SQ-080-2).
+#
+# @adr highest-version-wins-shim-wrapper-for-plugin-scaffold-template-shims-architecture-rule (highest-version-wins shim wrapper plugin scaffold)
+# @adr plugin-bundled-scripts-invoked-from-skill-md-resolve-via-bin-on-path-architecture-rule (plugin-bundled scripts resolve via bin/ on $PATH — amended)
+# @problem install-updates-refreshes-the-global-plugin-cache-but-does-not-fix-path-ordering-stale-plugin-version-shims-stay-first-on-path-so-subsequent-shim-invocations-run-old-code-problem (mid-session staleness window)
+
+set -euo pipefail
+
+SHIM_DIR="$(cd "$(dirname "$0")" && pwd)"
+OWN_VERSION_DIR="$(dirname "$SHIM_DIR")"
+OWN_VERSION_NAME="$(basename "$OWN_VERSION_DIR")"
+CACHE_PARENT="$(dirname "$OWN_VERSION_DIR")"
+
+SEMVER_RE='^[0-9]+\.[0-9]+\.[0-9]+([-+][0-9A-Za-z.-]+)?$'
+
+# Source-repo guard: own parent dir is NOT semver → dispatch to own scripts/.
+if ! [[ "$OWN_VERSION_NAME" =~ $SEMVER_RE ]]; then
+  exec "$SHIM_DIR/../scripts/is-close-blocked.sh" "$@"
+fi
+
+# Cache execution: pick the highest-semver sibling under CACHE_PARENT.
+HIGHEST=""
+while IFS= read -r dir; do
+  name="$(basename "$dir")"
+  [[ "$name" =~ $SEMVER_RE ]] || continue
+  if [[ -z "$HIGHEST" ]] || [[ "$(printf '%s\n%s\n' "$HIGHEST" "$name" | sort -V | tail -1)" == "$name" ]]; then
+    HIGHEST="$name"
+  fi
+done < <(find "$CACHE_PARENT" -mindepth 1 -maxdepth 1 -type d 2>/dev/null)
+
+if [[ -z "$HIGHEST" ]]; then
+  printf 'wr-shim: no cached versions in %s\n' "$CACHE_PARENT" >&2
+  exit 127
+fi
+
+exec "$CACHE_PARENT/$HIGHEST/scripts/is-close-blocked.sh" "$@"

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@windyroad/itil",
-  "version": "2.0.0",
+  "version": "2.1.0",
   "description": "ITIL-aligned IT service management for Claude Code and Codex",
   "bin": {
     "windyroad-itil": "./bin/install.mjs"

package/scripts/is-close-blocked.sh

@@ -0,0 +1,93 @@
+#!/usr/bin/env bash
+# wr-itil — predicate: is a ticket's closure explicitly blocked? (the-verification-pending-closed-transition-is-reserved-for-the-maintainer-so-evidence-based-closure-never-fires-and-the-verification-queue-grows-without-bound-problem)
+#
+# Sibling of packages/architect/scripts/is-decision-unconfirmed.sh: answers ONE
+# question for ONE ticket via its EXIT CODE, for the Verification Pending ->
+# Closed guard in /wr-itil:transition-problem, /wr-itil:transition-problems,
+# /wr-itil:manage-problem and /wr-itil:work-problems.
+#
+# Evidence-backed closure is agent-authorised (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 predicate is the
+# machine-checkable half of the carve-out that keeps genuine ambiguity on the
+# maintainer's surface: a ticket carrying an explicit DO-NOT-CLOSE marker keeps
+# blocking closure even when the evidence would otherwise satisfy the ticket's
+# own close criterion. Making the marker a field read rather than prose the
+# next agent must happen to notice is what stops the carve-out eroding.
+#
+# Marker shape (LINE-ANCHORED, per 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 advisory-A2 lesson): the literal
+# uppercase `DO NOT CLOSE` in a markdown heading line, or in a bold/bullet
+# marker line. A mention inside a fenced code block or mid-prose is NOT a
+# marker — that is how tickets *discuss* the mechanism, and treating discussion
+# as a block would re-strand the queue this predicate exists to let drain.
+#
+# Usage:
+#   is-close-blocked.sh <ticket-ref> [PROBLEMS_DIR]
+#     <ticket-ref>  = P<NNN> | <NNN> | path/to/<NNN>-title.md
+#     PROBLEMS_DIR  defaults to docs/problems
+#
+# Exit codes:
+#   0 = BLOCKED — marker present. Prints the matching line on stdout.
+#   1 = not blocked. No stdout.
+#   2 = ticket not found / unreadable ref. No stdout; reason on stderr.
+#
+# @adr plugin-bundled-scripts-invoked-from-skill-md-resolve-via-bin-on-path-architecture-rule (bin/ on PATH shim — adopter-safe script resolution)
+# @adr problem-lifecycle-add-a-verification-pending-status-between-known-error-and-closed-architecture-rule (Verifying lifecycle — the V->C transition this guards)
+# @adr decision-delegation-contract-when-agents-act-on-the-framework-vs-ask-the-user-architecture-rule (framework-resolution boundary — the marker is the recorded
+#               signal that routes a close back to the user's surface)
+# @adr agent-output-grounding-no-fabricated-quantitative-estimates-cite-persist-uncertainty-architecture-rule (agent output grounding)
+# @problem the-verification-pending-closed-transition-is-reserved-for-the-maintainer-so-evidence-based-closure-never-fires-and-the-verification-queue-grows-without-bound-problem (evidence-backed closure is agent-authorised; ambiguity is not)
+
+set -uo pipefail
+
+REF="${1:-}"
+PROBLEMS_DIR="${2:-docs/problems}"
+
+if [ -z "$REF" ]; then
+  echo "is-close-blocked: missing <ticket-ref>" >&2
+  echo "usage: is-close-blocked.sh <ticket-ref> [PROBLEMS_DIR]" >&2
+  exit 2
+fi
+
+# --- Resolve the ticket file -----------------------------------------------
+file=""
+if [ -f "$REF" ]; then
+  file="$REF"
+else
+  id="${REF#[Pp]}"
+  # Zero-pad a bare number to the three-digit ticket convention.
+  case "$id" in
+    ''|*[!0-9]*) : ;;
+    *) id="$(printf '%03d' "$((10#$id))")" ;;
+  esac
+  # Dual-tolerant per docs-problems-flat-layout-migration-per-state-subdirs-adopter-auto-migration-release-design: per-state subdirs AND the flat legacy layout.
+  for cand in \
+    "$PROBLEMS_DIR"/*/"$id"-*.md \
+    "$PROBLEMS_DIR"/"$id"-*.md
+  do
+    [ -f "$cand" ] || continue
+    file="$cand"
+    break
+  done
+fi
+
+if [ -z "$file" ] || [ ! -r "$file" ]; then
+  echo "is-close-blocked: no readable ticket for ref '$REF' under '$PROBLEMS_DIR'" >&2
+  exit 2
+fi
+
+# --- Scan for the marker, skipping fenced code blocks ----------------------
+match="$(awk '
+  # Toggle fence state on ``` or ~~~ openers/closers.
+  /^[[:space:]]*(```|~~~)/ { fenced = !fenced; next }
+  fenced { next }
+  # Line-anchored: a heading, or a bold/bullet marker line.
+  /^[[:space:]]*(#{1,6}[[:space:]]|[-*+][[:space:]]|\*\*)/ {
+    if (index($0, "DO NOT CLOSE") > 0) { print; exit }
+  }
+' "$file")"
+
+if [ -n "$match" ]; then
+  printf '%s\n' "$match"
+  exit 0
+fi
+
+exit 1

package/skills/manage-problem/SKILL.md

@@ -43,10 +43,11 @@ The preamble check is a one-shot; the `.intake-scaffold-done` and `.intake-scaff
 - **Work**: `problem work` — runs a review first, then begins working the highest-WSJF problem
 - **Review**: `problem review` — re-assess all open problems: update priorities per RISK-POLICY.md, estimate effort, calculate WSJF, and update files
 
-**Closing problems:** Problems are closed ONLY after the user verifies the fix in production — not when the fix is committed or released. The workflow (per the "Problem lifecycle — add a Verification Pending status between Known Error and Closed" architecture rule):
-1. When the fix is released: `git mv` the file from `.known-error.md` to `.verifying.md`, update the Status field to "Verification Pending", AND add a `## Fix Released` section (e.g., `Deployed in v0.26.X. Awaiting user verification.`). All three edits land in the same commit per the "Governance Skills Commit Their Own Completed Work" architecture rule.
-2. When the user explicitly confirms ("it's fixed", "verified", "working"): `git mv` from `.verifying.md` to `.closed.md`, update the Status field to "Closed", and reference the problem in the commit message (e.g., "Closes the "Problem 008: AskUserQuestion Unavailable When --channels Is Active" problem").
-3. Never assume the fix works — always wait for explicit user confirmation before closing.
+**Closing problems:** Problems are closed when the fix is **verified** — not when it is committed or released. Verification comes from cited evidence or from the user; it never comes from assuming. The workflow (per the "Problem lifecycle — add a Verification Pending status between Known Error and Closed" architecture rule, amended by 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):
+1. When the fix is released: `git mv` the file from `.known-error.md` to `.verifying.md`, update the Status field to "Verification Pending", AND add a `## Fix Released` section (e.g., `Deployed in v0.26.X. Awaiting verification.`). All three edits land in the same commit per the "Governance Skills Commit Their Own Completed Work" architecture rule.
+2. When the fix is **verified** — either by cited evidence the agent can point at (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 an existing `yes — observed: <citation>` Verification Queue cell) **or** by the user explicitly confirming ("it's fixed", "verified", "working"): `git mv` from `.verifying.md` to `.closed.md`, update the Status field to "Closed", record the citation in the closure, and reference the problem in the commit message (e.g., "Closes the "Problem 008: AskUserQuestion Unavailable When --channels Is Active" problem"). **Evidence-backed closure is agent-authorised** and is a mechanical stage — do NOT fire `AskUserQuestion` for it (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). It is cheap and reversible: report `Recovery: rerun /wr-itil:transition-problem <NNN> known-error to reopen` alongside every close.
+3. **Never close on inference — absence of evidence is not evidence.** A ticket nobody exercised stays Verification Pending, however old and however plausible the fix looks. "The fix is on disk", "it has been months" and "the ADR that prescribed it shipped" are inference, not observation (the "Relevance-close evaluator over-fires — a bare ADR/skill citation is read as "fix shipped", so live tickets return CLOSE-CANDIDATE" problem). Closing tickets nobody exercised is the opposite failure and is exactly as wrong as never closing any.
+4. **Genuine ambiguity is the user's surface** — contested evidence, a fix covering only part of the ticket, or a recorded do-not-close marker. Run `wr-itil-is-close-blocked <NNN> docs/problems` before closing; exit 0 means BLOCKED (do not close, whatever the evidence says — flip back or queue for the user), exit 1 means not blocked, exit 2 means the ref did not resolve and is a pre-flight failure rather than permission.
 
 The `.verifying.md` suffix distinguishes "fix released, awaiting user verification" from "root cause identified AND workaround documented; fix not yet proposed" (the Known Error meaning per the "Problem lifecycle — add a Verification Pending status between Known Error and Closed" architecture rule corrected semantics, 2026-06-08 amendment; the fix proposal happens AFTER Known Error and draws a release row on a story map). See the "Problem lifecycle — add a Verification Pending status between Known Error and Closed" architecture rule for rationale.
 
@@ -56,9 +57,9 @@ The `.verifying.md` suffix distinguishes "fix released, awaiting user verificati
 |--------|-----------|---------|----------------|
 | **Open** | `.open.md` | Reported, under investigation | New problem identified |
 | **Known Error** | `.known-error.md` | Root cause identified AND workaround documented; **fix not yet proposed** (the fix proposal draws a release row on a story map) | Root cause documented, reproduction test exists, workaround in place |
-| **Verification Pending** | `.verifying.md` | Fix released, awaiting user verification (the "Problem lifecycle — add a Verification Pending status between Known Error and Closed" architecture rule) | Fix shipped; `## Fix Released` section written; user action remaining |
+| **Verification Pending** | `.verifying.md` | Fix released, awaiting verification (the "Problem lifecycle — add a Verification Pending status between Known Error and Closed" architecture rule) | Fix shipped; `## Fix Released` section written; verification outstanding — by cited evidence or by the user |
 | **Parked** | `.parked.md` | Blocked on upstream or suspended by user decision | Upstream blocker identified, or user explicitly suspends; reason and un-park trigger documented |
-| **Closed** | `.closed.md` | Fix verified in production OR ticket determined no longer relevant via evidence | (a) User explicitly confirms the released fix works (canonical Verifying → Closed path), OR (b) auto-closed by `/wr-itil:review-problems` Step 4.6 relevance-close pass per 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 Phase 1 + Phase 2 evidence shapes — `file-no-longer-exists` / `ADR-shipped-confirmed` / `named-skill-or-feature-exists` / `self-marker-in-body` / `driver-child-ticket-closed` (cumulative; multi-shape matches emit comma-joined) with `## Closed as no longer relevant` audit section per the "Agent output grounding — no fabricated quantitative estimates, cite + persist + uncertainty" architecture rule grounding (extends the "Problem lifecycle — add a Verification Pending status between Known Error and Closed" architecture rule lifecycle: Open\|Known Error → Closed bypasses Verifying when no fix was released). Partial-scope umbrellas emit `CLOSE-CANDIDATE-WITH-CAVEAT` and ride the maintainer's `AskUserQuestion` surface-batch-confirm path. |
+| **Closed** | `.closed.md` | Fix verified in production OR ticket determined no longer relevant via evidence | (a) The released fix is verified — either by cited evidence meeting the ticket's own close criterion (agent-authorised, mechanical, no `AskUserQuestion`; blocked when `wr-itil-is-close-blocked` exits 0) or by the user explicitly confirming (canonical Verifying → Closed path; 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), OR (b) auto-closed by `/wr-itil:review-problems` Step 4.6 relevance-close pass per 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 Phase 1 + Phase 2 evidence shapes — `file-no-longer-exists` / `ADR-shipped-confirmed` / `named-skill-or-feature-exists` / `self-marker-in-body` / `driver-child-ticket-closed` (cumulative; multi-shape matches emit comma-joined) with `## Closed as no longer relevant` audit section per the "Agent output grounding — no fabricated quantitative estimates, cite + persist + uncertainty" architecture rule grounding (extends the "Problem lifecycle — add a Verification Pending status between Known Error and Closed" architecture rule lifecycle: Open\|Known Error → Closed bypasses Verifying when no fix was released). Partial-scope umbrellas emit `CLOSE-CANDIDATE-WITH-CAVEAT` and ride the maintainer's `AskUserQuestion` surface-batch-confirm path. |
 
 **Parked problems** are excluded from WSJF ranking and work selection. They are listed separately in review output so users can see them without them polluting the backlog. To park a problem:
 1. **If the park reason is `upstream-blocked`**, run the external-root-cause detection block at Step 7 first (see "External-root-cause detection (the "Problem 063: manage-problem does not trigger /wr-itil:report-upstream when root cause is external" problem)"). Park without recording the upstream dependency in `## Related` would be the canonical audit-trail gap this block closes.
@@ -68,7 +69,7 @@ The `.verifying.md` suffix distinguishes "fix released, awaiting user verificati
 
 To un-park: `git mv` back to `docs/problems/open/<NNN>-<title>.md` (or `docs/problems/known-error/<NNN>-<title>.md` if root cause is confirmed), update Status, remove `## Parked` section.
 
-**Verification Pending problems** are also excluded from WSJF ranking — their remaining work is user-side verification, not dev effort. They appear in a dedicated "Verification Queue" section in review output so the user can see what's waiting on them without mixing with dev-work ranking. See step 9c for the queue layout.
+**Verification Pending problems** are also excluded from WSJF ranking — their remaining work is verification — by evidence or by the user, not dev effort. They appear in a dedicated "Verification Queue" section in review output so the user can see what's waiting on them without mixing with dev-work ranking. See step 9c for the queue layout.
 
 **Allowed optional appendages**: a problem ticket file may carry a `## Reported Upstream` section appended after the standard sections. This is written by the `/wr-itil:report-upstream` skill (per the "Cross-project problem-reporting contract — `report-upstream` skill in `@windyroad/itil`" architecture rule Confirmation criterion 3a) and records the upstream URL — an issue, a pull request (per the "Prefer an upstream pull request over an issue when the upstream accepts pull requests" architecture rule), or an advisory — plus the matched template and the disclosure path. The presence or absence of this section does not affect WSJF ranking or status transitions.
 
@@ -833,11 +834,26 @@ Then edit the file:
 
 Re-stage the `.verifying.md` file explicitly after the `Edit` tool runs (the "Problem 057: `git mv` + Edit + `git add` staging-ordering trap drops content edits from the commit" problem). The trailing `git add` above is NOT redundant — `git mv` alone stages only the rename, not the subsequent content edit; the same `git add` also re-stages the seed Edit content carried across the rename (single staging call, two Edit windows; the "derive-release-vehicle helper requires pre-edit of ticket changeset reference — three-touch when one-touch would suffice" problem + the "Problem 057: `git mv` + Edit + `git add` staging-ordering trap drops content edits from the commit" problem).
 
-Both the `git mv` and the file edits belong in the same commit as the fix implementation per the "Governance Skills Commit Their Own Completed Work" architecture rule (governance skills commit their own work). 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.
+Both the `git mv` and the file edits belong in the same commit as the fix implementation per the "Governance Skills Commit Their Own Completed Work" architecture rule (governance skills commit their own work). 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.
 
-**Verification Pending → Closed** (user confirms):
+**Verification Pending → Closed** (verified — by evidence or by the user):
 
-Only the user can make this call. When they explicitly confirm the fix works in production:
+**Sibling-with `/wr-itil:transition-problem` Step 4** per the "Rename `wr-problem` Plugin to `wr-itil`" architecture rule amended the "Problem 093: `/wr-itil:transition-problem` ↔ `/wr-itil:manage-problem` circular delegation for `<NNN> <status>` args" problem (copy-not-move — edit both or neither; drift here is the class 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 fixed). Two admissible triggers:
+
+- **Cited evidence** meeting 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 an existing `yes — observed: <citation>` Verification Queue cell. The agent closes on its own authority and records the citation in the closure. **Mechanical stage — do NOT fire `AskUserQuestion`** (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). Report `Recovery: rerun /wr-itil:transition-problem <NNN> known-error to reopen`.
+
+  **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; an unresolved or non-issue inbound origin performs no issue mutation. An issue on another maintainer's tracker receives the comment but stays open on our evidence alone; that upstream party's confirmation may authorize closure. Pull requests remain comment-only.
+- **Explicit user confirmation** that the fix works in production.
+
+**Never close on inference** — absence of evidence is not evidence; a ticket nobody exercised stays Verification Pending. **Do-not-close guard**, before either trigger:
+
+```bash
+wr-itil-is-close-blocked <NNN> docs/problems && close_blocked=1
+```
+
+Exit 0 → BLOCKED; do not close whatever the evidence says (flip back to `known-error` or queue for the user). Exit 1 → not blocked. Exit 2 → the ref did not resolve; a pre-flight failure, not permission.
+
+When one of the two triggers holds and the guard is clear:
 
 ```bash
 git mv docs/problems/verifying/<NNN>-<title>.md docs/problems/closed/<NNN>-<title>.md
@@ -845,7 +861,14 @@ git mv docs/problems/verifying/<NNN>-<title>.md docs/problems/closed/<NNN>-<titl
 git add docs/problems/closed/<NNN>-<title>.md
 ```
 
-Update the "Status" field to "Closed". Reference the problem ID in the closure commit message (e.g., "Closes the "Problem 008: AskUserQuestion Unavailable When --channels Is Active" problem"). Step 9d's verification prompt is the structured path that fires this transition during `manage-problem review`. Re-stage the `.closed.md` file explicitly after the Edit (the "Problem 057: `git mv` + Edit + `git add` staging-ordering trap drops content edits from the commit" problem staging trap).
+**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.
+
+Reference the problem ID in the closure commit message (e.g., "Closes the "Problem 008: AskUserQuestion Unavailable When --channels Is Active" problem"). Step 9d's verification prompt is the structured path that fires this transition during `manage-problem review`. Re-stage the `.closed.md` file explicitly after the Edit (the "Problem 057: `git mv` + Edit + `git add` staging-ordering trap drops content edits from the commit" problem staging trap).
 
 #### README.md refresh on every transition (the "Problem 062: `manage-problem` does not refresh `docs/problems/README.md` on single-ticket transitions; fast-path cache goes stale silently" problem)
 

package/skills/review-problems/SKILL.md

@@ -21,7 +21,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.
 
@@ -113,7 +113,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 `AskUserQuestion` 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-AskUserQuestion 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 `AskUserQuestion` — 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 `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 `AskUserQuestion` 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/transition-problem/SKILL.md

@@ -18,7 +18,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 Claude Code 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>`.
 
@@ -68,8 +68,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
@@ -117,9 +121,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 `AskUserQuestion`** (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
+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)
 
@@ -195,7 +224,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.
 
@@ -230,10 +259,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/transition-problems/SKILL.md

@@ -35,7 +35,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:**
 
@@ -100,13 +100,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 `AskUserQuestion`-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 `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.
 
@@ -151,10 +157,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.