@windyroad/retrospective 0.27.4 → 0.27.5

package/.claude-plugin/plugin.json

@@ -78,5 +78,5 @@
     }
   },
   "name": "wr-retrospective",
-  "version": "0.27.4"
+  "version": "0.27.5"
 }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@windyroad/retrospective",
-  "version": "0.27.4",
+  "version": "0.27.5",
   "description": "Session retrospectives that update briefings and create problem tickets",
   "bin": {
     "windyroad-retrospective": "./bin/install.mjs"

package/skills/run-retro/SKILL.md

@@ -133,7 +133,7 @@ Step 2's reflection prompts are framed around the product-code work the session
 
 The shape mirrors P068's Step 4a Verification-close housekeeping: glob / evidence-scan / categorise / dedup / prompt. The ownership boundary is the same — run-retro surfaces the detection and delegates ticket creation to `/wr-itil:manage-problem` via the Skill tool; run-retro does not rename, edit, or commit problem-ticket files on its own (per ADR-014).
 
-**Ownership boundary**: run-retro surfaces the detection and its specific citations; `/wr-itil:manage-problem` creates or updates the ticket and commits per ADR-014. run-retro does not write `.open.md` files directly — it delegates through the ticketing skill so the audit trail, WSJF scoring, and concern-boundary analysis all apply consistently. This matches Step 4a's boundary to manage-problem Step 7 and Step 4b Stage 1's boundary to manage-problem creation.
+**Ownership boundary**: run-retro surfaces the detection and its specific citations; `/wr-itil:manage-problem` creates or updates the ticket and commits per ADR-014. run-retro does not write `.open.md` files directly — it delegates through the ticketing skill so the audit trail, WSJF scoring, and concern-boundary analysis all apply consistently. This matches Step 4a's boundary to `/wr-itil:transition-problem`, the ADR-010 P093 authoritative executor and Step 4b Stage 1's boundary to manage-problem creation.
 
 **Signal categories** — each detection is tagged with the primary category. A detection may match multiple categories; pick the one whose fix path is most concrete.
 
@@ -403,9 +403,9 @@ For each item identified in "What was harder than it should have been", "What fa
 
 ### 4a. Verification-close housekeeping (P068)
 
-Problems whose fix shipped but whose closure is still pending (`docs/problems/*.verifying.md` per ADR-022) accumulate across sessions. When this session's activity exercised a pending fix successfully, run-retro surfaces the evidence so the user can close on observed fact rather than by calendar age (P048's `Likely verified` heuristic) or deferred user review (manage-problem Step 9d's baseline user-initiated path). This step extends those paths with **session-context evidence**; the close decision remains the user's.
+Problems whose fix shipped but whose closure is still pending (`docs/problems/*.verifying.md` per ADR-022) accumulate across sessions. When this session's activity exercised a pending fix successfully, run-retro surfaces the evidence so the user can close on observed fact rather than by calendar age (P048's `Likely verified` heuristic) or deferred user review (manage-problem Step 9d's baseline user-initiated path). This step extends those paths with **session-context evidence**. Closing on that evidence is the agent's call, not a question for the user — sub-step 5 below closes silently, in AFK too, and has since P135 (see P519 for the sweep that removed the contradictory prose this sentence used to carry). What stays the user's are the cases evidence does not settle: no citation collected (absence of evidence is not evidence — the ticket simply stays Verification Pending), contested evidence, a fix covering only part of the ticket, and any ticket a recorded do-not-close marker blocks (`wr-itil-is-close-blocked <NNN> docs/problems` exits 0).
 
-**Ownership boundary**: run-retro surfaces evidence and asks; `/wr-itil:manage-problem` Step 7 Verification Pending → Closed transition (rename + Status edit + P057 re-stage + ADR-014 commit per ADR-022) is invoked via the Skill tool to perform the actual file rename and commit. run-retro does **not** rename, edit the Status field, or commit — those remain `manage-problem`'s responsibility. ADR-014 lists run-retro as out of scope for its own commits; the delegated manage-problem call commits per ADR-014 + ADR-022 and that boundary is preserved.
+**Ownership boundary**: run-retro gathers the evidence and decides; `/wr-itil:transition-problem <NNN> close` — the authoritative V→C executor per ADR-010 amended P093 — is invoked via the Skill tool to perform the rename + Status edit + P057 re-stage + README refresh + ADR-014 commit. run-retro does **not** rename, edit the Status field, or commit — those remain the transition skill's responsibility. (Corrected 2026-08-24 per P519: this used to say run-retro "surfaces evidence and asks" and named `manage-problem` Step 7, both of which the sub-steps below have contradicted since P135.) ADR-014 lists run-retro as out of scope for its own commits; the delegated manage-problem call commits per ADR-014 + ADR-022 and that boundary is preserved.
 
 **Steps:**
 
@@ -418,14 +418,20 @@ Problems whose fix shipped but whose closure is still pending (`docs/problems/*.
    - **Commits** whose diff covered the fix's source path (cite the commit SHA and path).
    - **Skill invocations** that rely on the fix (e.g. `manage-problem` using P056's corrected next-ID lookup; cite the invocation and the observable that the fix contract held — "ID 072 computed without origin_max blob-SHA false-match").
    - **Hook firings** on gate paths the fix established (cite the tool call that triggered the hook and the hook's observed behaviour).
-   - **Release cycles** (`push:watch` / `release:watch`) that shipped a commit dependent on the fix (cite the workflow run ID and exit status).
+   - **Release cycles** (`push:watch` / `release:watch`) that shipped a commit dependent on the fix (cite the workflow run ID and exit status). Narrow: the shipping alone is not the observation — a ticket is in `verifying` *because* a fix was released, so "it shipped" is true of every row by construction and would collapse the bucket. What counts is that the shipped artefact was then **invoked** and behaved as the fix contracts. Sub-step 8's same-session exclusion stops the degenerate reading here, but state it rather than rely on it (P519).
 
 4. **Categorise** each `.verifying.md` ticket into one of three buckets:
    - **Exercised successfully in-session** — at least one citation from step 3. Record the ticket as a close-candidate. Citations MUST be specific (tool invocation + observable outcome), not bare counts — per ADR-026 grounding. If no specific citation can be produced, the ticket does NOT go in this bucket regardless of how often the fix's area was touched.
    - **Not exercised in-session** — no citation collected. Leave as Verification Pending; nothing surfaces for this ticket.
    - **Exercised with regression** — the fix's contract observably failed (test red, hook misfired, skill produced incorrect output). This is a distinct problem, not a closure candidate. Flag it in the retro report as a new problem ticket (route via Step 4) with the regression evidence, and leave the `.verifying.md` file alone.
 
-5. **Close-on-evidence (silent agent action per P135 / ADR-044)** — for each close-candidate in the "Exercised successfully in-session" bucket, the agent delegates to `/wr-itil:transition-problem <NNN> close` (per ADR-014 commit grain) WITHOUT firing `AskUserQuestion`. The framework has resolved this decision: `.verifying.md` files with specific in-session evidence (test invocation + observable outcome per ADR-026 grounding) ARE verified per ADR-022's evidence semantics. Per-candidate `AskUserQuestion` is sub-contracting the framework-resolved decision back to the user (lazy deferral per Step 2d Ask Hygiene Pass classification).
+5. **Close-on-evidence (silent agent action per P135 / ADR-044)** — for each close-candidate in the "Exercised successfully in-session" bucket, first run the do-not-close guard:
+
+   ```bash
+   wr-itil-is-close-blocked <NNN> docs/problems && close_blocked=1
+   ```
+
+   Exit 0 → **drop the candidate**; the ticket carries a recorded do-not-close marker, which outranks any evidence. Record the matched marker line as the reason in the Step 5 summary rather than dropping it silently. Exit 1 → proceed. Exit 2 → the ref did not resolve; drop and record a pre-flight failure. For each surviving candidate the agent delegates to `/wr-itil:transition-problem <NNN> close` (per ADR-014 commit grain) WITHOUT firing `AskUserQuestion`. The framework has resolved this decision: `.verifying.md` files with specific in-session evidence (test invocation + observable outcome per ADR-026 grounding) ARE verified per ADR-022's evidence semantics. Per-candidate `AskUserQuestion` is sub-contracting the framework-resolved decision back to the user (lazy deferral per Step 2d Ask Hygiene Pass classification).
 
    The Step 5 retro summary's `## Verification Candidates` table records each close action with the citation that triggered it AND a documented recovery path (per the cross-plugin dispatch + recovery-path bats coverage in P135 Phase 2 — `run-retro-step-4a-cross-plugin-dispatch.bats` + `run-retro-step-4a-recovery-path.bats`). User reads the summary; if a close was wrong, user invokes the recovery path: `/wr-itil:transition-problem <NNN> known-error` (or equivalent) — closes are reversible. User disagreement surfaces via authentic-correction (ADR-044 category 6 / P078 capture-on-correction surface) — the agent does not need permission per-close because the recovery path is cheap and reversible.