plan

Plan

把“要不要改、改什么、改到哪里”为止先说清楚，再允许后续动作。

读取

1. 读取 AGENTS.md、.spec-agents/doctrine/docs/WORKFLOW.md、CONTEXT.md、.spec-agents/state/STATUS.md； 项目有 .spec-agents/state/KERNEL.md 时一并读取。
2. 只有当前判断需要历史依据、风险分类或回归对比时，才读取 .spec-agents/state/EVIDENCE.md 或 .spec-agents/archive/。
3. 查代码、调用方、测试和配置来回答事实；不要把可以查到的事实丢给用户回答。

质询

按设计树分轮工作：

• 先确认需求、未改变的基线和“不改会怎样”。
• 只问当前前置条件已经确定的问题；每轮完整询问当前 frontier，再等待用户回答。
• 区分事实与决定：事实由 agent 查，取舍由用户确认。
• 继续到没有未决分支，不因一个看似合理的解释提前结束。
• .spec-agents/state/STATUS.md 已有活跃 SPEC 时，检查新工作的 scope 是否与它们相交。相交就在 这一轮重新划分边界，不要留到执行时用隔离工作副本掩盖。
• 确认工作要写的文件各归哪个动作。被管项目中安装进来的 doctrine 不属于任何 动作，需要改它说明这项工作属于上游仓库，不属于本项目。

保持一份候选记录：

kind: add | refine | rename | split | merge | retire | plan-only
need:
unchanged_baseline:
old_definition:
new_definition:
knowledge_class: semantic | decision | protocol | runbook | lesson | state
scope:
applies_when:
identity_and_relations:
lifecycle_and_invariants:
action_contracts:
kernel_status: absent | K1-bootstrap | enacted | stale | contradicted
kernel_promotion: bootstrap | revise | supersede | none
compatibility: no-change | compatible | breaking | unresolved
mapping_and_migration:
verification:
decision: no-change | revise | approve | reject | unresolved

路由

用户确认共享理解后，只选择一个结果：

• no-change：停止，不创建 SPEC、不改代码。
• plan-only：输出边界明确的计划，等待执行授权。获得授权后：单上下文可完成的 交给 do（do 的短路径接受已授权的 plan-only），跨上下文的交给 capture。
• approve：语义不变且当前上下文内可完成，交给 do。两个条件都要满足； 语义不变但一个上下文完不成的工作走 capture——它需要的是可交接的契约， 不是语义门。大小不是判据：Change Boundary 已经写明一个很小的 diff 也可能是语义变化。这条路径不产生 SPEC 也不产生 Slice。
• compatible revise：明确一个兼容替代方案，保留旧不变量和数据契约。跨上下文的 交给 capture，单上下文可完成的交给 do（do 的短路径接受它）。
• breaking：必须确定迁移方案，由 capture 写进 SPEC，不能伪装成兼容修改。 ADR 由 learn 在收尾时写，和其它长期记录一样——此刻还没有任何东西被 验证过，learn 的触发条件尚未满足（见 docs/adr/0004）。
• reject / unresolved：停止；只有用户需要长期记忆时才交给 learn 留痕。

approve 必须交出什么

短路径不产生 SPEC 也不产生 Slice，所以 plan 必须在路由时口头交出两样东西， 否则 do 无从开始、check 无从比对：

• 保持不变的契约 —— do 不得扰动的不变量、接口或数据契约；
• 怎么算完 —— 一句可验证的验收，check 就对着它比。