creatixchu
89d30b0ef7
A question may now carry `intent`, a tagged declaration that it IS a decision
of a known shape, so a UI that recognises the tag can present it as such
instead of as a generic option list. The one member is
`{ kind: 'plan-review', approve }`, which plan-mode sets on the exit_plan_mode
review.
An intent shapes presentation only: a UI honouring it answers with the same
option labels a generic UI would send, so the tool reads one answer shape
either way, and a UI that does not know the tag renders the generic flow.
`approve` names the affirmative option rather than relying on option order;
since no type can tie that label to the question's own option list, `ask()`
rejects a mismatch as BAD_INTENT, and the wire schema rejects an unknown tag
outright rather than silently rendering generic.
plan-mode also stops reporting a dismissed review as "the user cancelled
ask_user_question" — a tool it never called. A dismissal now tells the model
the user took the turn back to speak, and to stay in plan mode and wait; every
other ask failure keeps its own message.
plan/ — plan collaboration state
English | 中文
Plan mode is one logged, per-agent collaboration state. It is a single product package, not a generic mode registry or a capability-seam trio.
| Package | Role | ctx key |
|---|---|---|
plan-mode/ |
plan/mode vocabulary + fold, boundary-applied state, the plan:policy guidance section, /plan [message] entry and /plan off exit, and the model-facing exit_plan_mode review tool |
ctx.planMode |
The active state is a pure function of the session log, so resume and fork restore it without extra machinery. The deployment supplies plan instructions through Cordis config, while exit_plan_mode stays registered when planning is inactive to keep the request tool catalog stable. Interactive adapters use the plugin-owned /plan command; sandbox mode and approval policy remain independent enforcement settings. Design: plan-specific collaboration state.