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>
opusplan is in the picker and does nothing on this install: it is a per-MODE model switch (Opus while in
plan mode, Sonnet at rest — the CLI's own strings call them the upgrade and resting models), and
claude-manager hardcodes permissionMode: 'bypassPermissions', so plan mode is never entered. Not
orchestration, which is what the name suggests and what we both assumed.
Making the mode reachable is the fix. setPermissionMode is a control request on the live query, same channel
as the setModel that landed in 4c24df93, so the mechanism is proven. The hard part is ExitPlanMode: it is a
permission decision, and bypassPermissions auto-approves it, so a naive toggle produces a planner that
instantly approves its own plan. canUseTool is the hook, and whether it can be supplied after session
creation is the one thing to verify before designing any UI.
Records the landmines too — bypassPermissions is deliberate per CLAUDE.md and must be restored on exit, and
a canUseTool promise that never resolves wedges the turn.
pastilhasandClaude Opus 5