Two bugs surfaced when validating the v1.21 fix end-to-end:
1. PlanSkillObservation outcome detection ran 'asked' (any numbered
options list) BEFORE 'plan_ready'. Plan-mode's "Ready to execute?"
confirmation IS a numbered options list (1=auto, 2=manual, ...), so
any skill that successfully reached the native confirmation got
misclassified as 'asked'. Reorder: 'auto_decided' (most specific,
requires AUTO_DECIDE annotation) > 'plan_ready' (next, requires the
"ready to execute" stem) > 'asked' (any remaining numbered list).
2. isPlanReadyVisible and isAutoDecidedVisible regexes only matched
spaced forms ("ready to execute", "(your preference)"). stripAnsi
removes cursor-positioning escapes (`\x1b[40C`) entirely instead of
replacing them with spaces, so the same text can render as
"readytoexecute" or "(yourpreference)". Both detectors now test the
spaced form first, fall through to a whitespace-collapsed comparison.
Inline unit smoke confirms both forms match.
Updates to the 5 strict 'asked' regression test cases (plan-ceo,
plan-eng, plan-devex, autoplan, office-hours): with the detection order
corrected, the model's plan-file fallback flow legitimately lands at
'plan_ready' instead of 'asked'. Pass envelope expanded to ['asked',
'plan_ready'] (matching plan-design-review's existing pattern). Failure
signals tightened to include 'auto_decided' (catches AUTO_DECIDE without
opt-in) plus the standard silent_write/exited/timeout. plan-design was
already on this contract from v1.21's first commit, no change needed.
The expanded envelope is correct: under --disallowedTools AskUserQuestion
the Tool resolution preamble routes the question through plan-mode's
native "Ready to execute?" surface — the user still sees the decision,
just via the plan-file flow rather than a numbered prompt.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Garry Tan
78e4b770fa