@windyroad/itil 0.44.0 → 0.44.2-preview.507

package/.claude-plugin/plugin.json

@@ -497,5 +497,5 @@
     }
   },
   "name": "wr-itil",
-  "version": "0.44.0"
+  "version": "0.44.2"
 }

package/bin/wr-itil-verify-iter-summary

@@ -0,0 +1,2 @@
+#!/usr/bin/env bash
+exec "$(dirname "$0")/../scripts/verify-iter-summary.sh" "$@"

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@windyroad/itil",
-  "version": "0.44.0",
+  "version": "0.44.2-preview.507",
   "description": "ITIL-aligned IT service management for Claude Code (problem, and future incident/change skills)",
   "bin": {
     "windyroad-itil": "./bin/install.mjs"
@@ -26,6 +26,7 @@
     "skills/",
     "scripts/",
     ".claude-plugin/",
-    "lib/"
+    "lib/",
+    "!skills/*/eval/"
   ]
 }

package/scripts/test/verify-iter-summary.bats

@@ -0,0 +1,196 @@
+#!/usr/bin/env bats
+
+# @problem P335 — AFK iter subprocess over-claims completion in
+# ITERATION_SUMMARY notes / commit message while on-disk Confirmation
+# checkboxes remain `[ ]`. Step 6.75 currently runs `git status --porcelain`
+# only — catches commit-didn't-land but not commit-landed-with-false-claim.
+# This verifier closes the gap.
+#
+# Contract: `verify-iter-summary.sh` (or PATH shim
+# `wr-itil-verify-iter-summary`) reads:
+#   $1 = commit_sha (the iter's landed commit)
+#   $2 = path to a file containing the ITERATION_SUMMARY notes field
+#   $3 = repo root (optional; defaults to `git rev-parse --show-toplevel`)
+#
+# Mechanism:
+#   1. Extract `ADR-NNN` identifiers from the commit message
+#      (`git log -1 --format=%B <sha>`) AND the notes file.
+#   2. For each identifier, resolve to `docs/decisions/<NNN>-*.md` (any
+#      status suffix — `.proposed.md` / `.accepted.md` / etc).
+#   3. Detect completion-claim signal in commit message OR notes (regex
+#      family: `all .*(green|complete|done|checked|ticked)`,
+#      `\([a-z]\)\s*[-–]\s*\([a-z]\)\s+(green|complete|all)`,
+#      `all\s+Confirmation\s+items`).
+#   4. When signal present AND any `- [ ]` item exists in the cited ADR's
+#      `## Confirmation` section → emit `OVER-CLAIM:` line and exit 1.
+#   5. Otherwise exit 0.
+#
+# Exit codes:
+#   0 = OK (no signal, or signal-and-all-items-checked, or no ADR referenced)
+#   1 = OVER-CLAIM detected
+#   2 = invocation error (missing args, bad sha, etc)
+#
+# @adr ADR-032 (subprocess-boundary trust contract — orchestrator decides
+#               trust boundary; verifier is the policy-authorised silent check)
+# @adr ADR-049 (Plugin-bundled scripts ship as bin/ PATH shims;
+#               wr-itil-verify-iter-summary is the shim name)
+# @adr ADR-052 (Behavioural tests for skill testing; this bats covers
+#               the OVER-CLAIM detection behaviour, not script structure)
+# @jtbd JTBD-006 (Progress the Backlog While I'm Away — orchestrator-side
+#                 verification keeps AFK loop integrity intact when iter
+#                 self-certification fails)
+
+setup() {
+  SCRIPTS_DIR="$(cd "$(dirname "$BATS_TEST_FILENAME")/.." && pwd)"
+  SCRIPT="$SCRIPTS_DIR/verify-iter-summary.sh"
+  FIXTURE_DIR="$(mktemp -d)"
+  cd "$FIXTURE_DIR"
+  git init -q
+  git config user.email test@example.com
+  git config user.name "Test"
+  mkdir -p docs/decisions
+}
+
+teardown() {
+  cd /
+  rm -rf "$FIXTURE_DIR"
+}
+
+# Helper: create a fake ADR with the given Confirmation-section body.
+_make_adr() {
+  local num="$1" status="$2" confirmation_body="$3"
+  cat > "docs/decisions/${num}-fake-adr.${status}.md" <<EOF
+# ${num}. Fake ADR
+
+## Status
+${status}
+
+## Confirmation
+${confirmation_body}
+EOF
+}
+
+# Helper: commit a file with the given message; return the SHA via stdout.
+_commit_with_message() {
+  local message="$1"
+  echo "dummy" > dummy.txt
+  git add dummy.txt
+  git commit -q -m "$message"
+  git log -1 --format=%H
+}
+
+# ── Existence + executable ──────────────────────────────────────────────────
+
+@test "verify-iter-summary: script exists" {
+  [ -f "$SCRIPT" ]
+}
+
+@test "verify-iter-summary: script is executable" {
+  [ -x "$SCRIPT" ]
+}
+
+# ── Exit 0: no completion-claim signal ──────────────────────────────────────
+
+@test "verify-iter-summary: notes mention ADR but no completion-claim signal → OK" {
+  _make_adr 077 proposed "- [ ] **(a) Item A**
+- [ ] **(b) Item B**"
+  local sha; sha=$(_commit_with_message "feat(architect): ADR-077 Slice 1 partial work")
+  echo "P327 progressed; partial slice landed; further work needed for Confirmation items (a)+(b)." > notes.txt
+
+  run "$SCRIPT" "$sha" notes.txt "$FIXTURE_DIR"
+  [ "$status" -eq 0 ]
+}
+
+@test "verify-iter-summary: no ADR referenced at all → OK" {
+  local sha; sha=$(_commit_with_message "fix(itil): rename helper variable")
+  echo "Bugfix; no governance impact." > notes.txt
+
+  run "$SCRIPT" "$sha" notes.txt "$FIXTURE_DIR"
+  [ "$status" -eq 0 ]
+}
+
+# ── Exit 0: signal present but all items checked ────────────────────────────
+
+@test "verify-iter-summary: completion-claim signal AND all items checked → OK" {
+  _make_adr 077 proposed "- [x] **(a) Item A**
+- [x] **(b) Item B**"
+  local sha; sha=$(_commit_with_message "feat(architect): ADR-077 — all Confirmation items complete")
+  echo "All ADR-077 Confirmation items green." > notes.txt
+
+  run "$SCRIPT" "$sha" notes.txt "$FIXTURE_DIR"
+  [ "$status" -eq 0 ]
+}
+
+# ── Exit 1: P335 witness shape — claim "all green" + unchecked items ────────
+
+@test "verify-iter-summary: claim 'all green at source' + unchecked items → OVER-CLAIM" {
+  # The P335 session 8 iter 1 witness shape: commit message claims (a)–(j)
+  # green; all 10 boxes are `[ ]`.
+  _make_adr 077 proposed "- [ ] **(a) Agent prompt amendment**
+- [ ] **(b) Generator script**
+- [ ] **(c) Initial compendium**
+- [ ] **(d) create-adr integration**
+- [ ] **(e) capture-adr integration**
+- [ ] **(f) review-decisions integration**
+- [ ] **(g) CI drift bats**
+- [ ] **(h) Pre-commit hook**
+- [ ] **(i) ADR-031 assertion**
+- [ ] **(j) No silent regression**"
+  local sha; sha=$(_commit_with_message "feat(architect): ADR-077 Slice 3 — all (a)-(j) green at source")
+  echo "ADR-077 Slice 3 — Confirmation items (a)-(j) all green at source." > notes.txt
+
+  run "$SCRIPT" "$sha" notes.txt "$FIXTURE_DIR"
+  [ "$status" -eq 1 ]
+  echo "$output" | grep -q "OVER-CLAIM"
+  echo "$output" | grep -q "ADR-077"
+}
+
+@test "verify-iter-summary: claim 'all Confirmation items complete' + unchecked → OVER-CLAIM" {
+  _make_adr 100 accepted "- [x] **(a) Done**
+- [ ] **(b) Still pending**"
+  local sha; sha=$(_commit_with_message "feat: ADR-100 — all Confirmation items complete")
+  echo "Implementation finished." > notes.txt
+
+  run "$SCRIPT" "$sha" notes.txt "$FIXTURE_DIR"
+  [ "$status" -eq 1 ]
+  echo "$output" | grep -q "OVER-CLAIM"
+}
+
+@test "verify-iter-summary: signal only in notes (not commit msg) + unchecked → OVER-CLAIM" {
+  _make_adr 200 proposed "- [ ] **(a) Missing**"
+  local sha; sha=$(_commit_with_message "feat: ADR-200 progress")
+  # Note completion signal lives in notes, not the commit subject.
+  echo "All Confirmation items ticked for ADR-200." > notes.txt
+
+  run "$SCRIPT" "$sha" notes.txt "$FIXTURE_DIR"
+  [ "$status" -eq 1 ]
+  echo "$output" | grep -q "OVER-CLAIM"
+  echo "$output" | grep -q "ADR-200"
+}
+
+# ── Invocation errors ───────────────────────────────────────────────────────
+
+@test "verify-iter-summary: missing notes file → invocation error" {
+  local sha; sha=$(_commit_with_message "init")
+  run "$SCRIPT" "$sha" /nonexistent/notes.txt "$FIXTURE_DIR"
+  [ "$status" -eq 2 ]
+}
+
+@test "verify-iter-summary: missing sha → invocation error" {
+  echo "" > notes.txt
+  run "$SCRIPT" "" notes.txt "$FIXTURE_DIR"
+  [ "$status" -eq 2 ]
+}
+
+# ── Multi-ADR case ──────────────────────────────────────────────────────────
+
+@test "verify-iter-summary: two ADRs cited — one clean, one over-claim → OVER-CLAIM only on the bad one" {
+  _make_adr 050 accepted "- [x] **(a) Clean**"
+  _make_adr 060 proposed "- [ ] **(a) Dirty**"
+  local sha; sha=$(_commit_with_message "feat: ADR-050 + ADR-060 — all green")
+  echo "Both ADRs progressed; all items green." > notes.txt
+
+  run "$SCRIPT" "$sha" notes.txt "$FIXTURE_DIR"
+  [ "$status" -eq 1 ]
+  echo "$output" | grep -q "ADR-060"
+}

package/scripts/verify-iter-summary.sh

@@ -0,0 +1,129 @@
+#!/usr/bin/env bash
+# verify-iter-summary.sh — detect ITERATION_SUMMARY over-claim against
+# on-disk ADR Confirmation state.
+#
+# Closes P335: AFK iter subprocess over-claims completion in ITERATION_SUMMARY
+# while on-disk Confirmation `[ ]` boxes remain. Step 6.75 of work-problems
+# dispatches this script between iter completion and Step 7 loop-back.
+#
+# Contract:
+#   verify-iter-summary.sh <commit_sha> <notes_file> [<repo_root>]
+#
+# Exit codes:
+#   0 = OK (no completion-claim signal, OR signal but all items checked, OR
+#           no ADR referenced)
+#   1 = OVER-CLAIM detected — at least one cited ADR has a completion-claim
+#           signal AND unchecked `- [ ]` items in its `## Confirmation`
+#           section
+#   2 = invocation error (missing args, missing notes file, bad sha)
+#
+# Per ADR-049, this script is invoked via the PATH shim
+# `wr-itil-verify-iter-summary` from SKILL.md prose — never via the
+# repo-relative `packages/itil/scripts/...` path.
+
+set -u
+
+commit_sha="${1:-}"
+notes_file="${2:-}"
+repo_root="${3:-}"
+
+if [ -z "$commit_sha" ] || [ -z "$notes_file" ]; then
+  echo "verify-iter-summary: missing required arg(s); usage: verify-iter-summary.sh <commit_sha> <notes_file> [<repo_root>]" >&2
+  exit 2
+fi
+
+if [ ! -f "$notes_file" ]; then
+  echo "verify-iter-summary: notes_file not found: $notes_file" >&2
+  exit 2
+fi
+
+if [ -z "$repo_root" ]; then
+  repo_root="$(git rev-parse --show-toplevel 2>/dev/null || echo ".")"
+fi
+
+# Pull commit message; combine with notes for the full claim surface.
+commit_message="$(git -C "$repo_root" log -1 --format=%B "$commit_sha" 2>/dev/null)"
+if [ -z "$commit_message" ]; then
+  echo "verify-iter-summary: could not read commit message for $commit_sha" >&2
+  exit 2
+fi
+notes_content="$(cat "$notes_file")"
+combined="$commit_message
+$notes_content"
+
+# Extract ADR identifiers (ADR-NNN, 1-4 digit numeric).
+adr_ids="$(echo "$combined" | grep -oE 'ADR-[0-9]{1,4}' | sort -u || true)"
+
+if [ -z "$adr_ids" ]; then
+  exit 0
+fi
+
+# Detect completion-claim signal in the combined claim surface.
+# Patterns (case-insensitive):
+#   - "all <something> green|complete|done|checked|ticked"
+#   - "every <something> green|complete|done|checked|ticked"
+#   - "all (Confirmation|criteria) items <complete|green|done|ticked>"
+#   - "(a)-(<letter>) green|complete|all"  (the ADR-077 witness shape)
+#   - "Confirmation items (a)-(<letter>) all green at source"
+has_signal=0
+if echo "$combined" | grep -qiE '(all|every)[[:space:]]+[^.]{0,80}(green|complete|done|checked|ticked|landed)' ; then
+  has_signal=1
+fi
+if [ "$has_signal" -eq 0 ] && echo "$combined" | grep -qiE '\([a-z]\)[[:space:]]*[-–][[:space:]]*\([a-z]\)[[:space:]]+(green|complete|all|done|landed)' ; then
+  has_signal=1
+fi
+if [ "$has_signal" -eq 0 ] && echo "$combined" | grep -qiE '(green|complete|done|ticked|checked)[[:space:]]+at[[:space:]]+source' ; then
+  has_signal=1
+fi
+
+if [ "$has_signal" -eq 0 ]; then
+  exit 0
+fi
+
+# For each cited ADR, resolve the file path and inspect the Confirmation section.
+over_claim_lines=""
+while IFS= read -r adr_id; do
+  [ -z "$adr_id" ] && continue
+  # Extract the numeric portion (zero-padded to 3 digits where possible).
+  adr_num="${adr_id#ADR-}"
+  # Resolve to a file path; the ADR may use any status suffix.
+  adr_files="$(find "$repo_root/docs/decisions" -maxdepth 1 -type f \
+    \( -name "${adr_num}-*.md" -o -name "$(printf '%03d' "$adr_num" 2>/dev/null)-*.md" \) \
+    2>/dev/null | head -1)"
+
+  if [ -z "$adr_files" ]; then
+    # Cited ADR doesn't exist on disk; this is suspicious but not an
+    # over-claim per se. Skip silently — the architect/JTBD review surface
+    # catches missing-ADR-reference issues separately.
+    continue
+  fi
+
+  adr_file="$adr_files"
+
+  # Slice out the `## Confirmation` section (between `## Confirmation` and
+  # the next `^## ` heading, or EOF).
+  confirmation_section="$(awk '
+    /^## Confirmation/ { in_section = 1; next }
+    in_section && /^## / { in_section = 0 }
+    in_section { print }
+  ' "$adr_file")"
+
+  if [ -z "$confirmation_section" ]; then
+    continue
+  fi
+
+  # Count unchecked items: leading `- [ ]` markers.
+  unchecked_count="$(echo "$confirmation_section" | grep -cE '^- \[ \]' || true)"
+
+  if [ "$unchecked_count" -gt 0 ]; then
+    over_claim_lines="${over_claim_lines}OVER-CLAIM: $adr_id has $unchecked_count unchecked Confirmation item(s) at $adr_file but iter claim language signals completion
+"
+  fi
+done <<< "$adr_ids"
+
+if [ -n "$over_claim_lines" ]; then
+  printf '%s' "$over_claim_lines"
+  exit 1
+fi
+
+exit 0

package/skills/manage-problem/SKILL.md

@@ -687,11 +687,23 @@ Update the "Status" field in the file to "Known Error".
 
 **Known Error → Verification Pending** (fix released, per ADR-022):
 
-When the fix for a Known Error ships, transition the ticket in a single commit:
+When the fix for a Known Error ships, transition the ticket in a single commit.
+
+**Seed `Release vehicle` reference BEFORE the rename (P330).** BEFORE the `git mv` to `.verifying.md`, edit the `.known-error.md` ticket body to append a `**Release vehicle**: .changeset/<name>.md` paragraph at the END of the `## Fix Strategy` section (create the section if absent). The `<name>.md` is the kebab-case slug of the changeset file the fix commit authored under `.changeset/` (e.g. `wr-itil-p330-option-b.md`). The seed eliminates the `wr-itil-derive-release-vehicle <NNN>` helper's exit-2 routing on standalone K→V iters — the helper greps the ticket body for `.changeset/<name>.md` and exits 2 when absent; seeding the reference at fix-ship time (when the changeset name is fresh in scope, since the fix commit just created it) makes the helper exit 0 deterministically on first call. The exit-2 recovery routing documented in `/wr-itil:transition-problem` Step 6 remains as the legacy-ticket fallback. Matches the user's documented workaround pattern across 3 of 4 standalone K→V dogfoods in the 2026-05-30 session (P316 / P281 / P302 — see P330 § Symptoms).
+
+> **Two P057 staging-trap windows on K→V (seed + rename).** The seed Edit on `.known-error.md` is the FIRST P057 window; the Edit that updates Status / writes `## Fix Released` AFTER the `git mv` is the SECOND. Consolidate staging into a SINGLE `git add docs/problems/<NNN>-<title>.verifying.md` AFTER both Edits + the `git mv`. `git mv` operates on the index entry — the body content the index references at rename time is the post-seed content, so the seed Edit's content is carried across the rename automatically; the single final `git add` re-stages the post-rename file with the post-`Edit` Status + `## Fix Released` content. The seed step does NOT introduce a separate `git add` of the `.known-error.md` path — staging discipline stays single-call by riding the rename's index entry.
 
 ```bash
+# Step 1 — seed `**Release vehicle**: .changeset/<name>.md` in the Fix Strategy section
+# ... use the Edit tool to append the seed paragraph to docs/problems/<NNN>-<title>.known-error.md ...
+
+# Step 2 — rename
 git mv docs/problems/<NNN>-<title>.known-error.md docs/problems/<NNN>-<title>.verifying.md
-# ... use the Edit tool to update Status and add the `## Fix Released` section ...
+
+# Step 3 — update Status + add `## Fix Released` section
+# ... use the Edit tool on docs/problems/<NNN>-<title>.verifying.md ...
+
+# Step 4 — single re-stage covers both Edit windows
 git add docs/problems/<NNN>-<title>.verifying.md
 ```
 
@@ -699,7 +711,7 @@ Then edit the file:
 - Update the "Status" field to "Verification Pending"
 - Add a `## Fix Released` section with: release marker (version, commit SHA, or date), one-sentence fix summary, "Awaiting user verification" line, and any exercise evidence from the releasing session.
 
-Re-stage the `.verifying.md` file explicitly after the `Edit` tool runs (P057). The second `git add` above is NOT redundant — `git mv` alone stages only the rename, not the subsequent content edit.
+Re-stage the `.verifying.md` file explicitly after the `Edit` tool runs (P057). 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; P330 + P057).
 
 Both the `git mv` and the file edits belong in the same commit as the fix implementation per ADR-014 (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.
 

package/skills/manage-problem/test/manage-problem-release-vehicle-seed.bats

@@ -0,0 +1,83 @@
+#!/usr/bin/env bats
+# tdd-review: structural-permitted (justification: deferred-retrofit per P330 Investigation Task #3 — behavioural K→V-mock test deferred to follow-up commit; this structural backstop guards the SKILL prose carrying the Release-vehicle seed instruction in the meantime per ADR-052 § Surface 2 marker)
+#
+# Doc-lint guard: manage-problem SKILL.md Step 7 Known Error → Verification Pending block
+# must document the P330 Option B seed step that appends a `**Release vehicle**: .changeset/<name>.md`
+# paragraph to the ticket's Fix Strategy section BEFORE the `git mv` to `.verifying.md`.
+# The same instruction must be mirrored in `transition-problem` SKILL.md Step 6 per ADR-010 amended
+# (copy-not-move; P093 split-skill execution ownership).
+#
+# Cross-reference:
+#   P330: docs/problems/known-error/330-derive-release-vehicle-helper-requires-pre-edit-of-ticket-changeset-reference-three-touch-when-one-touch-would-suffice.md
+#   ADR-010: docs/decisions/010-rename-wr-problem-to-wr-itil.proposed.md (P093 amendment — copy-not-move)
+#   ADR-014: docs/decisions/014-governance-skills-commit-their-own-work.proposed.md (single-commit grain)
+#   ADR-022: docs/decisions/022-problem-lifecycle-verification-pending-status.proposed.md (Verifying status)
+#   ADR-052: docs/decisions/052-behavioural-tests-default-for-skill-testing.proposed.md (Surface 2 marker)
+#   @jtbd JTBD-002 (ship with confidence — audit trail self-documents the release vehicle)
+#   @jtbd JTBD-006 (progress backlog AFK — eliminates the 3-of-4-dogfoods exit-2 routing friction)
+
+setup() {
+  TEST_DIR="$(cd "$(dirname "$BATS_TEST_FILENAME")" && pwd)"
+  REPO_ROOT="$(cd "${TEST_DIR}/../../../../.." && pwd)"
+  MANAGE_PROBLEM_SKILL="${REPO_ROOT}/packages/itil/skills/manage-problem/SKILL.md"
+  TRANSITION_PROBLEM_SKILL="${REPO_ROOT}/packages/itil/skills/transition-problem/SKILL.md"
+}
+
+@test "manage-problem SKILL.md exists (P330 precondition)" {
+  [ -f "$MANAGE_PROBLEM_SKILL" ]
+}
+
+@test "transition-problem SKILL.md exists (P330 precondition)" {
+  [ -f "$TRANSITION_PROBLEM_SKILL" ]
+}
+
+@test "manage-problem SKILL.md Step 7 documents the Release vehicle seed step (P330)" {
+  # The K→V transition block must instruct authors to seed a `**Release vehicle**: .changeset/<name>.md`
+  # paragraph in the ticket's `## Fix Strategy` section BEFORE the `git mv` to `.verifying.md`.
+  run grep -inE 'Release vehicle.*\.changeset/' "$MANAGE_PROBLEM_SKILL"
+  [ "$status" -eq 0 ]
+}
+
+@test "manage-problem SKILL.md Step 7 seed instruction precedes the K→V git mv (P330)" {
+  # Verify ordering: the "Seed `Release vehicle`" instruction must appear BEFORE the
+  # `git mv ... .known-error.md ... .verifying.md` block in Step 7. If the seed instruction
+  # lands AFTER the rename in the prose, the agent reading top-to-bottom would do the
+  # rename first and the seed-on-known-error-path would target a non-existent file.
+  seed_line=$(grep -nE 'Seed `Release vehicle` reference BEFORE the rename' "$MANAGE_PROBLEM_SKILL" | head -1 | cut -d: -f1)
+  rename_line=$(grep -nE 'git mv docs/problems/<NNN>-<title>\.known-error\.md docs/problems/<NNN>-<title>\.verifying\.md' "$MANAGE_PROBLEM_SKILL" | head -1 | cut -d: -f1)
+  [ -n "$seed_line" ]
+  [ -n "$rename_line" ]
+  [ "$seed_line" -lt "$rename_line" ]
+}
+
+@test "manage-problem SKILL.md Step 7 cites P330 on the seed instruction (P330 traceability)" {
+  # The seed instruction must cite P330 so reviewers can chase the rationale.
+  run grep -nE 'P330' "$MANAGE_PROBLEM_SKILL"
+  [ "$status" -eq 0 ]
+}
+
+@test "manage-problem SKILL.md Step 7 documents the two P057 staging-trap windows (seed + rename)" {
+  # The amendment introduces a second Edit-tool window (seed Edit on .known-error.md).
+  # The SKILL prose must explicitly call out that the existing single-`git add` shape covers
+  # BOTH windows by riding the rename's index entry.
+  run grep -inE 'Two P057 staging-trap windows|two .* Edit windows|seed Edit.*FIRST.*P057' "$MANAGE_PROBLEM_SKILL"
+  [ "$status" -eq 0 ]
+}
+
+@test "transition-problem SKILL.md Step 6 mirrors the Release vehicle seed step (ADR-010 copy-not-move)" {
+  # Per ADR-010 amended (P093 split-skill execution ownership), the manage-problem Step 7
+  # block and the transition-problem Step 6 block must stay in sync. Both surfaces are user-
+  # initiated K→V entry points (manage-problem fold-fix path + transition-problem standalone path).
+  run grep -inE 'Release vehicle.*\.changeset/' "$TRANSITION_PROBLEM_SKILL"
+  [ "$status" -eq 0 ]
+}
+
+@test "transition-problem SKILL.md Step 6 cites P330 on the seed instruction (ADR-010 copy-not-move)" {
+  run grep -nE 'P330' "$TRANSITION_PROBLEM_SKILL"
+  [ "$status" -eq 0 ]
+}
+
+@test "transition-problem SKILL.md Step 6 documents the two P057 staging-trap windows (seed + rename)" {
+  run grep -inE 'Two P057 staging-trap windows|two .* Edit windows|seed Edit.*FIRST.*P057' "$TRANSITION_PROBLEM_SKILL"
+  [ "$status" -eq 0 ]
+}

package/skills/transition-problem/SKILL.md

@@ -147,9 +147,21 @@ git add docs/problems/<NNN>-<title>.known-error.md
 
 **Known Error → Verification Pending** (per ADR-022, on release):
 
+**Seed `Release vehicle` reference BEFORE the rename (P330).** BEFORE the `git mv` to `.verifying.md`, edit the `.known-error.md` ticket body to append a `**Release vehicle**: .changeset/<name>.md` paragraph at the END of the `## Fix Strategy` section (create the section if absent). The `<name>.md` is the kebab-case slug of the changeset file the fix commit authored under `.changeset/` (e.g. `wr-itil-p330-option-b.md`). The seed makes the `wr-itil-derive-release-vehicle <NNN>` helper invocation below exit 0 deterministically on first call (the helper greps the ticket body for `.changeset/<name>.md` and exits 2 when absent — Option B-codified per P330 closes that exit-2 routing on standalone K→V iters). The exit-2 fallback in the routing table below remains as the legacy-ticket recovery path for tickets shipped before P330's codification. Mirrors the `/wr-itil:manage-problem` Step 7 seed step (copy-not-move per ADR-010 amended / P093).
+
+> **Two P057 staging-trap windows on K→V (seed + rename).** The seed Edit on `.known-error.md` is the FIRST P057 window; the Edit that updates Status / writes `## Fix Released` AFTER the `git mv` is the SECOND. Consolidate staging into a SINGLE `git add docs/problems/<NNN>-<title>.verifying.md` AFTER both Edits + the `git mv`. `git mv` operates on the index entry — the body content the index references at rename time is the post-seed content, so the seed Edit's content is carried across the rename automatically; the single final `git add` re-stages the post-rename file with the post-`Edit` Status + `## Fix Released` content. The seed step does NOT introduce a separate `git add` of the `.known-error.md` path — staging discipline stays single-call by riding the rename's index entry.
+
 ```bash
+# Step 1 — seed `**Release vehicle**: .changeset/<name>.md` in the Fix Strategy section
+# ... use the Edit tool to append the seed paragraph to docs/problems/<NNN>-<title>.known-error.md ...
+
+# Step 2 — rename
 git mv docs/problems/<NNN>-<title>.known-error.md docs/problems/<NNN>-<title>.verifying.md
-# ... use the Edit tool to update Status to "Verification Pending" AND add the `## Fix Released` section ...
+
+# Step 3 — update Status to "Verification Pending" AND add the `## Fix Released` section
+# ... use the Edit tool on docs/problems/<NNN>-<title>.verifying.md ...
+
+# Step 4 — single re-stage covers both Edit windows (P057 + P330)
 git add docs/problems/<NNN>-<title>.verifying.md
 ```
 

package/skills/work-problems/SKILL.md

@@ -726,6 +726,19 @@ Before spawning the next iteration's subagent, verify the working tree state aga
 
 **Out of scope for this step**: attempting recovery from an unknown-reason dirty state. Per ADR-013 Rule 6, conflict resolution and ambiguous state require user input; non-interactive recovery would mask the bug this check is meant to surface.
 
+**Verify-iter-claims sub-step (P335).** The clean/dirty-known/dirty-unknown classification catches the *commit-didn't-land* failure class but not the *commit-landed-with-false-claim* class — both the commit message and the `ITERATION_SUMMARY.notes` field are written by the same iter subprocess from the same model state, so they can agree with each other while disagreeing with the on-disk artefacts the claim names (the P335 session 8 iter 1 witness: commit message stated "all (a)–(j) Confirmation items green at source" + notes restated it + the cited ADR's 10 boxes were all `[ ]`). When the classification above returns Clean AND the iter reported `committed: true`, run the verify-iter-claims check:
+
+1. Dump the iter's `ITERATION_SUMMARY.notes` field to a temp file (`/tmp/iter-notes-$$.txt`).
+2. Invoke `wr-itil-verify-iter-summary <commit_sha> <notes_file>` (the PATH shim per ADR-049; never invoke the repo-relative `packages/itil/scripts/verify-iter-summary.sh` path from SKILL prose — adopter installs resolve the shim, not the source-monorepo path).
+3. Read the exit code:
+   - **Exit 0** → no over-claim detected (no ADR referenced, OR no completion-claim signal, OR signal-and-all-Confirmation-items-checked). Proceed to Step 7.
+   - **Exit 1** → OVER-CLAIM detected (at least one cited ADR has unchecked `- [ ]` Confirmation items while the iter's commit message or notes contains completion-claim language like "all green at source", "all Confirmation items complete", "(a)-(j) green"). **Halt the loop** with `outcome: halted-iter-over-claim`. Include the verifier's stdout (the `OVER-CLAIM: ADR-NNN has N unchecked Confirmation item(s)...` lines) as the divergence detail in the halt summary. Route through Step 2.5b's surfacing routine before emitting the halt summary (`halt-paths-must-route-design-questions-through-Step-2.5b`); the over-claim halt itself remains a halt-with-bug-signal — the iter's self-contradicting output IS the bug, and the user must adjudicate on return (re-dispatch the work / accept partial state / amend the commit).
+   - **Exit 2** → verifier invocation error (missing args, unreadable notes file, bad sha). Halt the loop with `outcome: halted-iter-verifier-error` and the verifier's stderr. This shape is itself an orchestrator-side bug; surfacing it loudly is preferable to silently proceeding.
+
+**Detection class boundary.** Verify-iter-claims is the *emit-but-over-claim* class detector — distinct from the *stuck-before-emit* class (P147, exit 143 + 0-byte JSON) which is already covered by the Step 5 idle-timeout SIGTERM handling + this step's existing dirty/clean check (working tree dirty after a missing-summary iter halts the loop). The verifier is intentionally narrow (ADR `## Confirmation` checkboxes) — it catches the load-bearing recurring shape where an iter ships an invariant gate (CI drift, README pairing) in the same commit as the work the gate is meant to test. Other over-claim shapes (claimed commits with no diff hunks; claimed file edits not in `git show --stat`) can be added incrementally as further witnesses surface; option (d) iter-local drift-bats (running the verifier inside the iter subprocess before `ITERATION_SUMMARY` emission) is deferred pending evidence that orchestrator-side (a) is insufficient — evidence-based, not BUFD (same shape as P246/P247).
+
+**Auto-correction is out of scope.** The orchestrator cannot retroactively make a false claim true; halt-with-bug-signal is the correct stance per ADR-013 Rule 6.
+
 ### Step 7: Loop
 
 Go back to step 1. The backlog may have changed — new problems may have been created during fixes, priorities may have shifted, and the README.md cache will be stale.
@@ -758,6 +771,7 @@ When `AskUserQuestion` is unavailable or the user is AFK, the skill (and the del
 | Pre-`ALL_DONE` gate sequence at any loop end (every stop-condition + every halt-path that emits a final summary + quota-exhaustion natural end) | Run Step 2.4 sequence UNCONDITIONALLY before `ALL_DONE` emit: gate (a) outstanding-questions surface via Step 2.5b; gate (b) session-level retro via `/wr-retrospective:run-retro`; gate (c) emit `ALL_DONE` only after (a) AND (b) complete. Hard-fail mode: if either gate cannot complete cleanly, halt with directive instead of emit `ALL_DONE` — recovery is the user satisfying the gate and re-invoking the skill. Per ADR-044 framework-resolution boundary + ADR-013 + ADR-014 (retro commits its own work) + P086 (extends iter-level retro to orchestrator-level) + P341 (Step 2.4). |
 | Halt-path final summary with accumulated user-answerable skips (CI failure / Rule 5 above-appetite / dirty-unknown / session-continuity / fetch failure) | Run Step 2.5b's surfacing routine before emitting the halt path's final AFK summary. Step 2.5b is gated on ≥1 accumulated user-answerable skip — empty-skip halts skip the routine. Step 2.5b surfaces *prior-iter accumulated user-answerable skips only*; it does NOT ask the user how to remediate the halt cause itself (CI failure / above-appetite state / dirty-unknown state remain halt-with-bug-signal). Per ADR-013 Rule 1 + ADR-032 + P126 (`halt-paths-must-route-design-questions-through-Step-2.5b`). |
 | Unexpected dirty state between iterations | Halt the loop. Report the `git status --porcelain` output, the last iteration's reported outcome, and the divergence — per P036 (Step 6.75). Run Step 2.5b before emitting the halt summary if ≥1 accumulated user-answerable skip from prior iters (P126). Do NOT attempt non-interactive recovery of the dirty state itself. |
+| Iter committed cleanly + claim contradicts on-disk ADR Confirmation state (P335) | Halt the loop with `outcome: halted-iter-over-claim`. Include the `wr-itil-verify-iter-summary` stdout (the `OVER-CLAIM: ADR-NNN has N unchecked Confirmation item(s)...` lines) as the divergence detail. Run Step 2.5b before emitting the halt summary if ≥1 accumulated user-answerable skip from prior iters. Do NOT auto-correct the iter's claim — the orchestrator cannot retroactively make a false claim true; the user adjudicates on return (re-dispatch / accept partial / amend). Per ADR-013 Rule 6 + ADR-032 subprocess-boundary trust contract + P335 (Step 6.75 verify-iter-claims sub-step). |
 | External root cause detected at Open → Known Error, or at park with `upstream-blocked` reason | Append the stable `- **Upstream report pending** — external dependency identified; invoke /wr-itil:report-upstream when ready` marker to the ticket's `## Related` section; do NOT auto-invoke `/wr-itil:report-upstream` (Step 6 security-path branch is interactive — per ADR-024 Consequences). Use the already-noted grep check to avoid duplicate lines. Per P063 + ADR-013 Rule 6. |
 | Mid-loop ask between iters in the orchestrator's main turn | Forbidden except at framework-prescribed halt points (Step 0 session-continuity / fetch-failure halt; Step 2.5 / 2.5b loop-end emit; Step 6.5 above-appetite Rule 5 halt; Step 6.5 CI-failure / release:watch halt; Step 6.5 cohort-graduation halt-no-resolution halt; Step 6.75 dirty-for-unknown-reason halt). The loop's purpose is **progress + accumulation**; mechanical-stage transitions between iters are framework-resolved and MUST NOT prompt the user. Per ADR-044 framework-resolution boundary + ADR-013 Rule 1 (as amended by ADR-044) + P130. |
 
@@ -774,6 +788,7 @@ The orchestrator MUST NOT call `AskUserQuestion` between iterations except at th
 - **Step 6.5 CI-failure / `release:watch` failure halt** — push:watch or release:watch failed AND the failure is genuinely-unrecoverable (outside the fixable-in-iter allow-list, or 3-retry cap reached); halt-with-batched-questions per the Step 2.5b cross-reference. Failures inside the closed allow-list route to fix-and-continue per Step 6.5 Failure handling (P140), not this halt point.
 - **Step 6.5 cohort-graduation halt-no-resolution halt (P246)** — graduation evaluator returned `status=halt-no-resolution` for one or more held candidates (Rule 1a terminal: neither filename-convention join nor body-grep fallback resolved a problem ticket, OR the resolved ticket file is missing/unreadable). The orchestrator MUST NOT auto-graduate under ambiguity per ADR-061 Rule 1a; halt-with-batched-questions per the Step 2.5b cross-reference. The halt-causing ambiguity itself remains a halt-with-bug-signal (the held entry stays in `docs/changesets-holding/`; manual reinstate or ticket-file correction required); Step 2.5b surfaces *prior-iter accumulated user-answerable skips only* and does NOT ask the user to resolve the ambiguity itself.
 - **Step 6.75 dirty-for-unknown-reason halt** — `git status --porcelain` divergence; halt-with-batched-questions per the Step 2.5b cross-reference.
+- **Step 6.75 iter-over-claim halt (P335)** — `wr-itil-verify-iter-summary` detected the iter's commit message or `ITERATION_SUMMARY.notes` contains completion-claim language for an ADR whose `## Confirmation` section still has unchecked `- [ ]` items; halt-with-batched-questions per the Step 2.5b cross-reference. The over-claim itself remains a halt-with-bug-signal — Step 2.5b surfaces *prior-iter accumulated user-answerable skips only*; it does NOT ask the user how to remediate the false claim (re-dispatch / accept partial / amend the commit remains a user decision on return).
 
 **No mid-iter ask points.** Every other point in the orchestrator's main turn (between Step 5 dispatch completing and Step 6.5 release-cadence check; between Step 6.75 verification and Step 7 loop-back; between Step 7 and Step 1 next-iteration; between consecutive iters generally) is a mechanical-stage transition that the framework has already resolved. Do NOT introduce ad-hoc `AskUserQuestion` calls at those points to confirm "is it OK to proceed?" or "want me to start the next iter?" — proceeding IS the framework-resolved default. Continue iterating until quota or stop-condition #1/#2/#3 fires.