fix: session-close drops DONE when the anchor is still in progress

CHANGELOG.md

@@ -8,6 +8,10 @@ Please choose versions by [Semantic Versioning](http://semver.org/).
 * MINOR version when you add functionality in a backwards-compatible manner, and
 * PATCH version when you make backwards-compatible bug fixes.
 
+## Unreleased
+
+- fix: `/vault-cli:session-close` no longer emits `⚪ DONE` on a carried-forward `in_progress` anchor. The mode gate deliberately lets a task the operator already resolved this session reach the clean verdicts, but every clean-verdict block in § Closer panel prescribed `⚪ DONE` — which `~/.claude/CLAUDE.md` names an anti-pattern while the anchored task still reads `in_progress`, requiring 🔵 READY / 🟡 WAITING / 🔴 BLOCKED in its place. The two rules are not reconcilable by wording: the command's own § Closer panel says *"verbatim, no rewording"*, so a session reaching mode 1 or 2 with a carried-forward anchor had no legal closer to emit. Closing a session is not the same claim as the task being finished, so the rule now keeps the block's body unchanged and swaps its `⚪ DONE` line for the panel the anchor's own state calls for — 🟡 WAITING with `later (on <trigger>):` when every open item is clock-bound, 🔵 READY when the next step is the operator's. Only the anchor's own status licenses `⚪ DONE`. Measured 2026-10-14 and 2026-10-15: two consecutive runs reached a clean verdict with a carried-forward anchor and had to improvise the panel against this section's verbatim rule, because no block offered one.
+
 ## v0.169.3
 
 - fix: `/vault-cli:sync-progress` § Phase 2 reaches its `already synced — no writes this run` short-circuit for an `in_progress` anchor, instead of reporting failure for a record it can verify as present. The short-circuit added in `v0.168.6` was gated *"When a completion was established above"*, so the state the command is most often run in — an anchor that is still open — fell past it to `No task completion or PR detected. Use /update instead for in-progress work.` and STOP. Measured 2026-10-15: the operator ran the command **four times in one session** against an `in_progress` anchor whose daily-note entry already existed; all four stopped at the same line, each costing a full Phase 1–2 sweep (vault config read, session-transcript scan, git probes) and producing an identical report. The gate now reads *"whenever a completion was established above **or** the anchor is `in_progress`"*, and an explicit `in_progress` arm precedes the STOP bullet so the representation check runs first. Still keyed on the representation check rather than on the status alone: an `in_progress` anchor with **no** daily-note entry falls through to the STOP line unchanged. Out of scope: the Phase 1–2 sweep itself (the short-circuit still runs after the completion analysis, so the sweep is not removed — the false failure report and the operator's reason to re-run are) and the close-family loop in `/vault-cli:session-close`.

commands/session-close.md

@@ -708,6 +708,8 @@ Never auto-close, never auto-commit, never auto-kill, never auto-reflect, never
 
 Append below the verdict. This command is terminal; without a fixed closer the trailing "name a concrete next action" convention gets improvised, and improvisation reliably produces a next-task recommendation — the exact thing the one-task-per-session contract forbids.
 
+⚠️ **A carried-forward `in_progress` anchor keeps the clean verdict but not the `⚪ DONE`.** The mode gate above deliberately lets a task the operator already resolved this session reach modes 1 and 2 — but `~/.claude/CLAUDE.md` names `⚪ DONE` while the anchored task is still `in_progress` an anti-pattern, and requires 🔵 READY / 🟡 WAITING / 🔴 BLOCKED in its place. So in every clean-verdict block below, when the anchor task still reads `in_progress` on disk this run, emit the block's body unchanged and replace its `⚪ DONE` line with the panel the anchor's own state calls for — 🟡 WAITING with `later (on <trigger>):` when every open item is clock-bound, 🔵 READY when the next step is the operator's. Closing a session is not the same claim as the task being finished, and only the anchor's own status licenses `⚪ DONE`. Observed 2026-10-14 and 2026-10-15: two consecutive runs reached a clean verdict with a carried-forward anchor and had to improvise the panel against this section's own verbatim rule, because no block below offered one.
+
 **Clean verdict, mode 1 (no follow-up signals fired — matching mode 1's header above):**
 
 ```