a test plan for plan mode, for a day that is not today

the owner has no time to test any of it, so the checklist has to work for
someone with none of today's context: eleven ordered tests, what each should
show, and what its failure looks like.

test 4 is called out as the one most likely to be wrong - approving
ExitPlanMode drops the harness into default rather than back into
bypassPermissions, which is the finding that changed the design and therefore
the thing the implementation is most likely to have got wrong.

also separates what was verified from what was not: the probe runs against a
real claude, the turn-stream unit tests, and then everything end to end, which
is nothing.

the inline 'what to watch' list in chat-plan-mode.md is replaced by a pointer
so there is one source of truth, and TODO.md now says live-but-unexercised
rather than built-not-run - the restarts are done.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
2026-08-17 23:43:27 +00:00
co-authored by Claude Opus 5
parent 004f702747
commit 43fb2952fa
3 changed files with 247 additions and 41 deletions
+11 -15
View File
@@ -3,8 +3,9 @@
Agreed with the owner on 2026-08-17, immediately before a context compaction. Written so the build can start
from here with nothing re-derived.
**Status: built in `1b811dfa`, not yet run.** Needs `pm2 restart officer` and `pm2 restart officer-claude-code`
before it does anything — see "Sequence" at the end for what to watch on the first plan.
**Status: built in `1b811dfa`, live since 2026-08-17, and never once exercised.** The restarts are done, so
the code is running. Nothing has been tested — work through `docs/chat-plan-mode-test-plan.md` before
believing any of it.
---
@@ -150,21 +151,16 @@ exactly this class of thing; a `session.permissionMode` beside it keeps `applyMo
and sends it as the denial message, which the harness turns into a revision request.
5. ~~Return to `bypassPermissions` on approval~~ — fired from inside `planGate`, not at turn end.
**Not yet run.** Everything above is on disk and typechecks; none of it has executed on this machine. It
needs `pm2 restart officer` AND `pm2 restart officer-claude-code` — the sidecar holds all of the interesting
half, and restarting only the server would leave the old one running with no `canUseTool` at all.
**Not yet run.** Everything above is on disk, typechecks and is unit tested at the translation layer; none
of it has executed inside Officer. The processes were restarted on 2026-08-17 (`officer`,
`officer-claude-code`, `officer-anthropic-proxy`) so the code IS live — it has simply never been exercised.
Worth watching on the first real plan, in this order:
**The test plan is `docs/chat-plan-mode-test-plan.md`**, written the same day for an owner who had no time
to run it. Eleven ordered tests, what each should show, and what its failure looks like. Test 4 (approve) is
the one most likely to be wrong, because it is the case that changed the design.
- the composer's clipboard icon lights, and `[claude:plan:<key>] plan mode on` appears in
`pm2 logs officer-claude-code`
- the agent researches and refuses to edit — a `Write` in plan mode should reach neither disk nor the gate
- the plan card renders with Approve / Reject, and **the turn is genuinely parked** while it sits there
- approving continues the same turn, and `plan mode off` follows immediately rather than at turn end
- refreshing mid-plan replays the card with its decision, rather than a conversation that stops dead
The one failure mode to watch for is a turn that never ends after a plan is answered: that would mean a
`canUseTool` promise was left unresolved, and `settleAllPlans` is what is meant to make it impossible.
Do not treat this feature as working until that document has been worked through. It is opt-in and off by
default, so nothing is at risk in the meantime.
---