clarify scenario 005's no-approval-turn assertion

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: scenario 005's "no approval turn" assertion could not distinguish a real failure from two unrelated causes, and two walks on 2026-08-16 duly contradicted each other. A prompt between resume and invocation has three sources: the classification bug (what the scenario tests), the trust-folder gate (a precondition the walk never proved), and — new since v0.110.0/v0.111.1 — the Phase 5.5 permission-mode precheck, which now runs for *every* task. The assertion now names all three and tells the walker to identify which before recording FAIL, plus a dedicated `🔐 Permission mode:` assertion: the fixture's only command is `/vault-cli:next-task`, so Phase 5.5's own rule ("emit nothing … do not warn on read-only or docs-only tasks") means seeing it is a Phase 5.5 trigger defect to file separately, not a classification failure. Also hardened two things the contradicting walks got wrong: the trust precondition must be *proven in the environment the walk runs in* (a fresh tmux / isolated HOME / sub-agent shell does not inherit it), and `claude_session_id` is now marked necessary-but-not-sufficient — one walk reported PASS from it alone after losing the scrollback. `PLUGIN_VER` is now required in the result, since this flow's behavior moved twice in a single day.
+
 ## v0.111.1
 
 - fix: the permission-mode precheck added in v0.110.0 never fired for ops tasks. It sat inside Phase 5, which is gated on the code-task heuristic (`fix|implement|refactor|add|bug|deploy|build`), so a task whose entire body is `kubectl delete` skipped Phase 5 wholesale and the precheck with it — every `decommission` / `renew` / `rebuild` / `migrate` task was silently excluded, which is exactly the ops work that needs the switch. Moved to its own Phase 5.5 that runs for all tasks and keys on the task's own commands. Caught by exercising v0.110.0 on "Decommission MinIO on Hell" the same day it shipped.

scenarios/005-work-on-resume-auto-invokes-subtask.md

@@ -57,7 +57,8 @@ echo "FIXTURE=$FIXTURE"   # note this path; you need it after the session exits
 - [ ] `command -v claude` resolves — otherwise `NewClaudeSessionStarter` returns nil, `work-on` downgrades to a warning and exits 0 with no session at all
 - [ ] `grep -c 'claude_session_id' "$FIXTURE"` returns `0`
 - [ ] `grep -c '^### Subtask classification' ~/.claude/plugins/cache/vault-cli/vault-cli/$PLUGIN_VER/commands/execute-task.md` returns `1` — resolve the path from the **installed** version, never from the latest git tag. `autoRelease` tags on every merge, so the tag routinely runs ahead of what is installed while `commands/execute-task.md` is unchanged; keying on the tag fails a walk that would have passed. Note the path is doubly nested (`cache/vault-cli/vault-cli/`) — a singly-nested guess silently returns 0 and reads as a stale plugin
-- [ ] The vault directory is already trusted by Claude Code — otherwise the first-run "Do you trust the files in this folder?" gate is itself an approval turn and breaks the assertion below
+- [ ] The vault directory is already trusted by Claude Code — otherwise the first-run "Do you trust the files in this folder?" gate is itself an approval turn and breaks the assertion below. **Prove it, don't assume it**: launch `claude` once in `$VAULT` and confirm no trust prompt appears, *in the same environment the walk will run in*. A walk driven from a fresh tmux session, an isolated `HOME`, or a sub-agent shell does not inherit the trust decision made in your normal terminal — it will hit the gate and report a FAIL that looks exactly like the classification bug. This is the single most likely cause of a false FAIL on this scenario (2026-08-16: two sub-agent walks disagreed, and the failing one had never established this precondition)
+- [ ] `PLUGIN_VER` recorded in the result. Behavior in this flow ships on the plugin channel and moved **twice in one day** (v0.110.0 → v0.111.1, see Phase 5.5 below), so a result without the plugin version cannot be compared against another walk
 
 ## Action
 
@@ -73,8 +74,9 @@ Scoped to post-continuation output only:
 - [ ] Contains `📋 Today's Tasks:` — next-task's own worker-mode header, proving the command actually ran rather than just being announced
 - [ ] Does **not** contain `🎯 Start with:` — negative evidence; its presence means classification fell through to print
 - [ ] Does **not** contain a fresh `✅ Oriented:` / `Next: →` block — negative evidence; that is the original bug reproducing
-- [ ] No `AskUserQuestion` option list and no permission prompt appears between the resume and the `🚀 Running:` line
-- [ ] `grep -c 'claude_session_id' "$FIXTURE"` now returns `1` — durable on-disk proof the bootstrap ran, and the one assertion that survives losing the scrollback
+- [ ] No `AskUserQuestion` option list and no permission prompt appears between the resume and the `🚀 Running:` line. **A prompt here has three distinct causes — identify which before recording FAIL:** (a) the classification bug reproducing, the only one this scenario is testing for; (b) the trust-folder gate, i.e. the precondition above was never established in this environment; (c) the Phase 5.5 permission-mode precheck, covered by its own assertion below
+- [ ] Does **not** contain the `🔐 Permission mode:` line. `work-on-task-assistant` Phase 5.5 (v0.111.1) runs for **every** task and appends that line when the task body names operator-run mutations (`make apply`, `make buca`, `kubectl` writes, `helm install/upgrade`, ssh deploys, prod runbook steps). This fixture's only command is `/vault-cli:next-task`, so Phase 5.5 must emit **nothing** — its own rule says "If none are present, emit nothing — do not warn on read-only or docs-only tasks." Seeing it here is a real defect, but in Phase 5.5's trigger, **not** in subtask classification: file it separately rather than failing this scenario
+- [ ] `grep -c 'claude_session_id' "$FIXTURE"` now returns `1` — durable on-disk proof the bootstrap ran, and the one assertion that survives losing the scrollback. **Necessary but not sufficient**: it proves the bootstrap ran, not that the subtask was invoked rather than printed. Never record PASS on this assertion alone — if the scrollback is lost, the walk is inconclusive and must be re-run (2026-08-16: a walk did exactly this and reported PASS, contradicting a run that had direct evidence of failure)
 
 ## Cleanup