# 技术设计: Sopify 推广优化 program plan

## 技术方案
- 核心目标: 把“轻入口、按风险打断、可旁路恢复”的推广方向，收口成可分批实施的后续子 plan
- 本方案定位:
  - 这是总纲 plan，不是直接执行代码改造的 implementation plan
  - 这份文档负责锁定边界、依赖、优先级与待拍板项
  - 后续所有实现都应通过独立子 plan 承接

## 设计原则
1. 先治状态机，再放大全局控制面
   若 runtime 连“当前 checkpoint 到底是什么”都不能唯一收敛，那么全局 bundle、shared runtime、diagnostics 只会放大状态漂移。

2. 先减阻力，再加能力
   先处理最直接的推广阻力，再进入更深的路径与状态语义改造。

3. 先保 contract，再改 behavior
   能通过内部打分与策略层解决的问题，不先改共享机器契约。

4. Ghost 不是单个 feature
   `延迟物化`、`Ghost State`、`Ghost Knowledge` 不是一个量级，不能绑成同一轮。

5. Side task 必须有边界
   目标是 `suspend -> bounded side task -> resume`，不是自由漫游。

6. 文档只宣传已交付能力
   对外定位可以提前设计，但不能提前承诺未实现能力。

## 总拆分
后续路线拆为七个命名方案：

### Plan H | 状态机 Hotfix（B1 前置门禁）
状态: immediate prerequisite

目标:
- 修复 stale-state、ghost proposal、checkpoint 解析分裂与 handoff 对冲

范围:
- 统一 checkpoint resolver / immutable snapshot
- 收口 proposal / clarification / decision 的作用域与 provenance
- 收口 `state_conflict` 与 `~go abort` 脱困路径
- 补状态机专项回归测试

硬约束:
- Proposal 只允许 Session-only，不保留 global fallback
- Router / Engine / Handoff 只消费同一份 resolved snapshot
- `state_conflict` 必须可见且可恢复，不能在构建期直接 Fatal
- `current_plan / current_run` 不纳入 abort 清理范围

### Plan A | 风险自适应打断
状态: committed next

目标:
- 把“打断过多”从流程问题改成风险分级问题

范围:
- 调整 risk detection、risk scoring、interruption policy
- 引入 `conservative / balanced / aggressive` 三档策略
- 收口稳定 reason code

硬约束:
- `ExecutionGate` 的核心机器语义保持稳定
- `gate_status` 值集不在 v1 改动
- 核心字段名 `gate_status / blocking_reason / plan_completion / next_required_action` 不改名
- `blocking_reason` 如需扩展，必须验证未知值消费兼容性

承接边界（来自 Plan H 收口后的 carry-over）:
- Plan H 负责 checkpoint correctness hotfix：唯一 pending 收敛、cancel bridge 放行、execution-confirm 污染冲突、doctor/status 协商态解释
- Plan A 只承接 host-facing 语义召回增强，不重开 Plan H 已收口的状态机正确性修复

非目标:
- 不扩大全局语义理解；仅允许在局部 checkpoint 语境下增强召回
- 不在本计划中改 runtime state model / handoff contract / resolution contract
- 不把 polite prefix、同义词、更多 tail token 的扩展伪装成 Plan H 热修

启动条件:
- 仅在 `Plan H + Plan B1` 各自收口后，才进入 Plan A 子 plan
- 启动前必须先登记真实漏判样本或用户反馈阈值，避免长期欠债无限后延，也避免过早侵入 control-plane 迁移窗口

实施切片（冻结口径）:
- Plan A V1: 采用 parser-first，仅覆盖局部 checkpoint / execution gate 语境下的高风险样本收口；当前实现门禁以 `A-1 / A-3 / A-4 / A-5 / A-6 / A-8` 为主，`A-7` 作为冻结回归基线持续保留。
- Plan A V1.x: 保留 parser robustness backlog，承接类似 `A-2` 这类稳健性增强，但不阻塞当前 v1 开工门禁。
- Plan A rollout: 在 v1 后先观察 `reason_code / ambiguous_rate / fail_close_rate / manual_resolution_rate`，用事实判定是否仍存在值得引入 classifier 的 residual ambiguity。
- Plan A V2: 仅在 v1 与 rollout 都稳定后，才评估 guarded hybrid classifier；classifier 只允许产出结构化候选信号，不得旁路 guard、三张表或直接写状态。
- locale / host adaptation 是跨切层，不是后置时间片；语言差异只允许落在 `Signal Extraction`，宿主差异只允许落在 `Handoff / Output Adapter`，三张表本身保持语言无关、宿主无关。

classifier(v2) 在总纲中的定位（冻结口径）:
- classifier(v2) 不是总纲独立执行分支，也不单独并入 `H / B1 / D / B2 / C / B3` 顺序。
- classifier(v2) 作为 Plan A 的后置 gate 能力，仅在 `Plan A V1 + rollout` 收敛后进入评估或灰度。
- 即便进入 v2，默认也只能作为 guarded side path，不作为主路由替换方案。

设计前置（A0，进入 Plan A 子计划前先冻结）:
- 背景:
  - 近期在 proposal pending 语境里，多次出现“补一个表述、漏一个表述”的 parser 修复循环。
  - 核心痛点不是实现复杂度，而是语义边界未一次定义清楚，导致同类句式不断返工。
- 本轮新增追溯样本（2026-03-31 / 2026-04-03）:
  - 样本组 1: `直接继续分析这个分支还剩什么需要你确认`、`分析下 为啥一件简单的事被网关卡成这样`、`说下怎么补case`
  - 样本组 2: `不要建包，只做确认项分析`、`取消这个 proposal checkpoint`
  - 样本组 3: `做 Plan A，但先不写方案包。先看总纲中 Plan A 的规划；...只分析，不改。`、`只做 Plan A 样本矩阵草案，不建包、不改代码`
  - 追溯结论: 这组样本共同暴露的是 pending checkpoint 语境下的 host-facing recall debt，而不是 `Plan H` 已收口的 state correctness 问题；后续应在 Plan A 统一覆盖 explain-only、existing plan referent、cancel checkpoint、mixed clause、explicit no-write + process semantic 五类语义，不在当前 `B1` 分支顺手落实现。
- 当前方案现状（已收口）:
  - referential retopic 基本句式（如“这个方案改成 ...”）已进入 retopic 识别路径。
  - constraint follow-up question（如“继续按这个方案会有什么风险”）已按 fail-closed 处理，不再误改 checkpoint。
  - question-like retopic 已按 `question signal + retopic signal + plan referent` 语义类完成 parser 侧收口；纯疑问 fail-close 到 inspect，mixed follow-up revision 保持 revise。
- 剩余风险分层（用于后续设计，不在总纲阶段改代码）:
  - 中优先: `plan_proposal_pending + command prefix` 当前是一刀切 inspect；该行为已被测试固化，是否调整属于产品决策，不作为 parser 修补顺手改动项。
- A0 设计原则（强制）:
  - 按“同一语义类一次收口”设计，不按单词/短语逐条补丁。
  - 本类问题仅允许在 parser 层收口；默认不改 engine/router 主流程与状态机 contract。
  - 对外行为以“结构判定 + 测试矩阵”冻结，不以新增 if-else 词表数量作为完成标准。
- A0 语义类定义（本轮焦点）:
  - 语义类: `question signal + retopic signal + plan referent`（用户在询问“能不能/是否要改题”，不是直接要求改题）。
  - 结构覆盖:
    1. 后缀疑问: `这个方案改成 X？`
    2. 前置疑问: `能不能/是否把这个方案改成 X`
    3. 中置疑问: `这个方案能不能改成 X`
  - 处理策略: 命中该语义类时优先 fail-close 到 inspect，保持 proposal identity 稳定。
- A0 非目标:
  - 不在本轮扩成“所有自然语言疑问句”统一理解。
  - 不把 `~go plan` 在 proposal pending 下的命令前缀行为与 parser 语义修补混做一轮。
  - 不通过提升 generic question 优先级来覆盖 retopic 场景，避免误伤正常 revise。

Case（后续拆分 Plan A 子计划时必须覆盖）:
- Case A-1 | checkpoint 中 explain-only 咨询不应二次物化
  - 场景: 已存在 `confirm_plan_package / confirm_decision` 等 pending checkpoint 时，用户提出“只分析、不改文件”的追问。
  - 追溯样本: `直接继续分析这个分支还剩什么需要你确认`、`分析下 为啥一件简单的事被网关卡成这样`
  - 期望: 优先按 consult 回答并保持当前 checkpoint 身份稳定；除非用户明确提交 `继续 / 取消 / 1/2/...`，不得新建或重开 plan proposal，也不得仅因存在 pending decision 就自动重跑 execution gate。
  - 验收: 同一 session 连续 explain-only 问答后，不新增 proposal `checkpoint_id`，且 `plan/` 下无新建方案包目录。
  - 验收补充: 当消息显式锚定 existing plan（如 `plan_id / plan path / plan title / 当前方案`）且语义仍为“分析 / 解释 / 判断是否认可 / 还有什么需要确认”时，应继续返回 consult；`current_decision` 身份保持稳定，不得漂移为新的 decision/proposal checkpoint。
- Case A-2 | 决策编号确认携带补充文本应稳健消费
  - 场景: 用户以 `1/2` 开头确认决策，同时附带后续动作文本（如“并把 case 补进总纲”）。
  - 期望: 先稳定消费 decision selection，再把后续文本作为 follow-up 意图处理，避免回退到“无效选择”或重复 decision checkpoint。
- Case A-3 | 引用受保护 plan 资产的分析请求不应默认升级阻断
  - 场景: 用户消息包含 `.sopify-skills/plan/...` 路径引用，或显式引用 existing plan（如 `plan_id / plan title`），但意图是“只分析/不改文件/判断是否认可”。
  - 追溯样本: `还剩什么需要你确认`、`分析下 <plan_id> 可以执行了吗还有什么需要确认`
  - 期望: 优先按 consult 或非阻断路径处理；仅在命中明确执行动作（如 `继续/next/开始/选择`）时进入 checkpoint 约束，不得因为“显式 plan 引用 + pending checkpoint”组合而默认升级为阻断路径。
  - 验收: 在同一 session 下，连续分析问答不会新增 `plan_proposal_pending`；`required_host_action` 不因“只分析”从 consult 漂移到阻断 checkpoint。
  - 验收补充: `分析下 <plan_id> 可以执行了吗还有什么需要确认` 这类请求，在未命中明确确认动作时，应保持为 consult / inspect 类回答，不得直接消费或重开 `confirm_decision`。
- Case A-4 | “取消 checkpoint”应幂等收口，不得派生新 pending
  - 场景: 当前处于 `confirm_decision / confirm_plan_package` pending，用户输入“取消这个 checkpoint”。
  - 追溯样本: `取消这个 proposal checkpoint`、`取消这个 checkpoint`
  - 期望: 只取消当前 pending（或返回已取消状态），并恢复到稳定可继续态；不得创建新的 proposal 或切到其他 checkpoint 类型。
  - 验收: 取消后 `current_handoff.required_host_action` 不再是新的 pending checkpoint；不会出现“取消动作触发新 plan_proposal_pending”的链路漂移。
  - 验收补充: 当用户输入“取消这个 checkpoint”等含取消关键词的自由文本时，必须按 `cancel` 处理，并允许 `status=cancelled/resume_action=cancel` 在无 `selected_option_id` 的情况下生效，且不得派生新的 pending checkpoint。
- Case A-5 | 逗号混合句的局部语境歧义应单独细化
  - 场景: 当前为保留 `"取消这个 checkpoint，不要取消全部"` 这类混合句的可执行语义，`, / ，` 仍作为 cancel 成功边界。
  - 已知残余风险: `"取消这个 checkpoint，为什么还会回到 pending"` 这类分析/追问句仍可能误命中 cancel。
  - 追溯样本: `不要建包，只做确认项分析`、`取消这个 checkpoint，为什么还会回到 pending`
  - 期望: 在 Plan A 中统一细化逗号后从句的局部语境，区分否定补充、解释性补充与疑问补充；该项不回流到 Plan H。
  - 验收: 保留 `"取消这个 checkpoint，不要取消全部"` 的 cancel 语义，同时降低 `"取消这个 checkpoint，为什么..."` 类问句的误触发率。
- Case A-6 | execution confirm 与 state_conflict abort 必须单次收敛
  - 场景: `current_run.stage=ready_for_execution` 且 `execution_gate.next_required_action=confirm_execute`，但 `current_handoff.required_host_action` 漂移为 `review_or_execute_plan` 或 `continue_host_workflow`。
  - 堵塞路径（可复现）:
    1. 用户输入“开始执行 ...”时命中 `state_conflict(resolve_state_conflict)`。
    2. 用户输入“取消”命中 `state_conflict(abort_conflict)`，handoff 被写成 `continue_host_workflow`。
    3. 用户再次输入“开始执行 ...”后再次命中 `state_conflict(resolve_state_conflict)`，形成循环卡死。
  - 根因链路（用于追溯）:
    1. `context_snapshot` 对 `ready_for_execution -> confirm_execute` 存在强约束（`run_stage_handoff_mismatch`）。
    2. `engine` 的 abort 清理只清理 conflict carrier / abortable negotiation 状态，未覆盖 `ready_for_execution` run stage 的归一。
    3. `handoff` 在 `state_conflict + abort_conflict` 下会输出 `required_host_action=continue_host_workflow`。
  - 期望:
    1. `abort_conflict` 后必须收敛到单一合法配对事实源。
    2. 允许的收敛终态仅两类：`ready_for_execution + confirm_execute`，或 `plan_generated + review_or_execute_plan`。
    3. 明确禁止出现 `ready_for_execution + continue_host_workflow` 这类二次 mismatch。
  - 验收:
    1. 同一 session 下执行“开始执行 -> 取消 -> 开始执行”序列时，不得再次回到同一 `state_conflict` 原因码。
    2. gate 回执不再反复给出 `run_stage_handoff_mismatch`。
    3. 必须能从以下证据文件复盘整条链路：`.sopify-skills/state/current_gate_receipt.json`、`.sopify-skills/state/sessions/<session_id>/current_run.json`、`.sopify-skills/state/sessions/<session_id>/current_handoff.json`、`.sopify-skills/state/sessions/<session_id>/last_route.json`。
- Case A-7 | question-like retopic 必须按语义类一次收口
  - 状态: 已在本轮 parser/test 收口，后续保留为回归基线，不再按“补一个词”方式继续修补。
  - 场景: proposal pending 下，用户表达“是否要把方案改成 X”，而不是直接要求改题。
  - 结构族（至少覆盖）:
    1. `这个方案改成 X？`
    2. `能不能把这个方案改成 X`
    3. `是否把这个方案改成 X`
    4. `这个方案能不能改成 X`
  - 期望:
    1. 以上结构统一按 inspect fail-close，不改变 `checkpoint_id / reserved_plan_id / proposed_path / request_text`。
    2. 声明式 retopic（如 `这个方案改成 X`、`change the plan to X`）仍走 revise。
    3. mixed case（如 `为什么先做这个？按这个最小范围直接进 3.1 -> 3.6`）仍保持 revise。
  - 约束:
    1. 仅允许改 parser，不改 engine/router 主流程。
    2. 不接受“补一个词”式修复；必须以语义类矩阵验证收口。
- Case A-8 | explicit no-write 分析请求不应被 process semantic 重新物化
  - 场景: 用户显式要求“只分析 / 不建包 / 不改代码 / 先学习”，但消息同时包含 `Plan A / proposal / 样本 / 整理` 等过程语义词，当前实现会重新落入 `plan_proposal_pending + confirm_plan_package`。
  - 追溯样本: `做 Plan A，但先不写方案包。先看总纲中 Plan A 的规划；...只分析，不改。`、`只做 Plan A 样本矩阵草案，不建包、不改代码`
  - 期望: `no-write / analysis-only` brake signal 优先级高于 process semantic，优先回到 consult / inspect，不得因为带有流程语义就重新生成 proposal。
  - 验收: 同一 session 在取消 proposal 后继续追问“为什么误起 proposal / 怎么整理样本矩阵”时，不得再次写出 `confirm_plan_package`；若仅作分析，不得新建 plan 包目录。
  - 验收补充: 只有当用户显式提交 `继续 / next / 生成方案包 / 建包` 一类物化动作时，才允许从该类请求回到 proposal materialization。

Plan A 样本矩阵 v0.2（用于后续拆分子计划时统一评审）:

| Case | 正例 | 反例 | 边界例 | 禁止副作用 |
| --- | --- | --- | --- | --- |
| A-1 | `直接继续分析这个分支还剩什么需要你确认` | `继续 / next 生成方案包` | `分析下当前方案还差什么，如果没问题再继续` | 新建 proposal checkpoint；新建 `plan/` 目录；`current_decision` / `current_handoff` 身份漂移 |
| A-2 | `1，并把 case 补进总纲` | `我倾向 1，但先分析 tradeoff` | `1，先别执行` | decision 选择未稳定消费；后续文本被吞掉；重复拉起 decision checkpoint |
| A-3 | `分析下 <plan_id> 可以执行了吗还有什么需要确认` | `继续执行 <plan_id>` | `看下当前方案是否认可，不改文件` | 因 plan 引用直接升级为新的 `confirm_*`；误建 proposal；无显式确认却消费 existing checkpoint |
| A-4 | `取消这个 checkpoint` | `不要取消这个 checkpoint` | `取消这个 checkpoint，不要取消全部` | 派生新的 pending checkpoint；切到其他 checkpoint 类型；残留 `current_plan_proposal/current_decision/current_clarification` |
| A-5 | `不要建包，只做确认项分析` | `继续，这次直接建包` | `取消这个 checkpoint，为什么还会回到 pending` | 误命中 cancel；误建 proposal；忽略否定补充、解释补充与疑问补充的局部差异 |
| A-6 | `开始执行 -> 取消 -> 再次开始执行` | `开始执行（无冲突单次通过）` | `abort_conflict 后立即再次开始执行` | 再次回到同一 `state_conflict`；`run_stage_handoff_mismatch` 循环；`ready_for_execution + continue_host_workflow` 非法配对 |
| A-7 | `这个方案能不能改成 X` | `这个方案改成 X` | `为什么先做这个？按这个最小范围直接进 3.1 -> 3.6` | 改写 `checkpoint_id / reserved_plan_id / proposed_path / request_text`；把疑问式 retopic 错走 revise 或重新物化 |
| A-8 | `做 Plan A，但先不写方案包，只分析，不改` | `继续生成 Plan A 方案包` | `只做 Plan A 样本矩阵草案，不建包、不改代码` | 命中 `plan_proposal_pending + confirm_plan_package`；`analysis-only` 请求被重新物化；写入新 plan 包目录 |

### Plan D | 对外定位与文档
状态: committed after Plan A scope is stable

目标:
- 把对外叙事从“重管控工作流”收口为“轻入口，复杂时再结构化”

范围:
- 更新 `README.md`
- 更新 `README.zh-CN.md`
- 更新 `docs/how-sopify-works.en.md`

硬约束:
- 只宣传已交付能力
- 不预售 Ghost / Suspend / Side Task 的未实现行为

### Plan B1 | 延迟物化
状态: current control-plane child plan, but state-chain-sensitive slices are blocked by Plan H

目标:
- 将原“延迟物化”升级为完整的 control-plane decoupling：
  - 重型 runtime bundle 留在宿主全局 payload
  - workspace 只保留本地 thin stub / pin
  - bootstrap 同时补 ignore、host-aware preflight 与 legacy compatibility

范围:
- 调整 bootstrap 与首次物化时机
- 调整 workspace-local `.sopify-runtime/manifest.json` 契约
- 调整 host-aware payload 解析与 dual-host 同仓库选择
- 调整 payload index、installer diagnostics、doctor/status/smoke
- 调整 legacy vendored fallback 的可观测性

硬约束:
- thin stub 不能只改字段，不改 bootstrap / validate / inspection 判定器
- dual-host 解析必须显式 host-aware
- payload 索引化必须同步升级 `validate / inspection / doctor / status / smoke`
- ignore 默认优先 `.git/info/exclude`，仅“提交版本锁”模式才写 `.gitignore`
- `stub 优先 / legacy vendored fallback 次之 / no_silent_downgrade` 必须有可见 reason code
- 不吸收 `runtime/state / router / engine / handoff` 的协商态一致性修复；该部分由 `Plan H` 单独承接
- 与 `Plan H` 并行时，只允许纯 filesystem / manifest / payload index / thin stub / ignore 脚手架，且不得 `import runtime.state` 或读取 `.sopify-skills/state/*.json`

非目标:
- 不改变 `plan/blueprint/history` 路径 contract
- 不引入 Ghost 全局缓存语义
- 不触碰 `B2 / B3` 的路径合约改造

### Plan B2 | Ghost State
状态: deferred but named

目标:
- 将 `state/`、`replay/` 等纯运行态数据从 workspace 移出

范围:
- 路由 `config.state_dir`
- 路由 replay session 存储
- 视实现需要决定是否增加 bundle cache

硬约束:
- 不改 `plan_path` 语义
- 不改 `knowledge_layout`
- 不改 `finalize`
- 不改 `plan/blueprint/history` 的 workspace-relative contract

### Plan C | Suspend / Side Task / Resume
状态: deferred but named

目标:
- 允许在 active plan 中做低风险旁路任务，再安全回到主线

范围:
- 先定义 suspend/resume contract
- 后实现 bounded side task flow

硬约束:
- side task 只允许 low-risk
- 不允许借 side task 绕开正式 planning / decision checkpoint
- contract design 可先做，full implementation 依赖前序方案稳定

### Plan B3 | Ghost Knowledge
状态: explicitly deferred

目标:
- 重新定义 `plan/blueprint/history` 的 materialization 与 path contract

说明:
- 这不是 B2 的附带工作
- 这是重量级路径合约改造，需要单独立项

影响面:
- `plan_path`
- `knowledge_layout`
- `finalize/history`
- `router` path protection
- mixed-mode collaboration

## 依赖与顺序
推荐顺序如下：

1. Plan H
2. Plan B1
3. Plan A
4. Plan D 在 B1 与 A 收口后推进
5. Plan B2
6. Plan C
7. Plan B3

补充说明:
- `Plan H` 是 `B1` 的前置门禁，因为它解决的是“runtime 当前到底在等哪个 checkpoint”这一层唯一事实源问题
- `B1` 仍是当前主 control-plane child plan，但其涉及 runtime 状态链路与协商恢复的切片必须等待 `Plan H` 解锁
- `B1` 在 `Plan H` 执行期间只允许推进纯 filesystem / manifest / payload index / thin stub / ignore 脚手架
- `A` 可继续保留分析结论，但 host-facing implementation 不应与 `B1` 的 control-plane contract 迁移交叉推进
- `D` 必须等 `B1` 与 `A` 两侧对外语义都稳定后再更新对外文档
- `B2` 不依赖 `A`，但应在 `B1` 之后，避免同时处理 control-plane bundle 迁移与运行态目录迁移
- `C` 的 contract design 可早于 `B2`，但 full implementation 建议在 `A` 与 `B1/B2` 稳定后进行
- `B3` 必须单独决策后再开工

推广与兼容边界（冻结）:
- `B1` 收口后允许先做一波灰度推广，不要求等待 `Plan A / Plan D` 全部完成
- `Plan A / Plan D` 必须按增量增强方式推进：默认向后兼容 `B1` 已发布 contract，不得破坏既有字段名、值集与升级路径
- 若后续方案确需破坏性改动，必须单独立项拍板，并附带显式迁移/回滚方案；不得作为 `A / D` 常规迭代隐式带入

## 当前执行窗口
当前总纲下的即时执行窗口分成两个层次：

- `.sopify-skills/plan/20260327_hotfix`
- `.sopify-skills/plan/20260326_5-plan-20260326-phase1-2-3-plan-plan-20260326-ph`

它与总纲的关系如下：

1. `20260327_hotfix` 是即时门禁窗口，负责修复 stale-state / ghost checkpoint / contradictory handoff
2. `20260326_5-plan-20260326-phase1-2-3-plan-plan-20260326-ph` 仍是当前 `Plan B1` 的升级落地窗口，但只保留可并行的 control-plane 脚手架
3. 任何触碰 runtime 状态链路、checkpoint 恢复、handoff 唯一出口、`doctor/status/smoke` 协商态解释的 B1 子任务，必须等待 `20260327_hotfix` 的 H5 解锁
4. `Plan A` 只有在 `Plan H + B1` 各自收口后才进入真正下一优先级执行窗口
5. `Plan D` 必须等 `B1 + A` 稳定后再跟进，以免外部叙事与真实能力错位
6. `B2 / C / B3` 继续保持后移，不并入当前窗口

## 待拍板的产品决策
以下事项必须先拍板，不能留到实现 plan 中边做边定：

1. 默认策略档位
   建议: `balanced`

2. Ghost 是否 `opt-in`
   建议: 是

3. Ghost v1 是否止步于 `B2`
   建议: 是，`B3` 只作为后续路线图

4. Side task 是否强约束为 `low-risk only`
   建议: 是

5. 若未来开启 `B3`，`plan_path` 的新语义是什么
   说明: 该项只在 B3 立项前拍板，不是当前主线阻塞项

6. 若未来开启 `B3`，Ghost 下是否保留 `finalize/history`
   说明: 该项只在 B3 立项前拍板

7. 若未来开启 `B3`，mixed-mode 协作如何定义
   说明: 该项只在 B3 立项前拍板

## 验收门
每个后续子 plan 都必须显式写出 acceptance gate，最低要求如下：

1. Plan H
   - Proposal 不再以 global fallback 参与当前会话路由
   - `state_conflict` 与 `~go abort` 构成完整脱困闭环
   - `current_handoff` 与 `current_run.stage` 不再对冲输出不同 checkpoint

2. Plan A
   - 覆盖既有 blocking_reason 的正例 / 反例 / 边界例
   - 验证 `gate_status` 语义不变

3. Plan D
   - 文档不提前承诺未实现功能
   - 文案与当前支持面一致

4. Plan B1
   - 验证首次需要时才发生物化
   - 验证不影响现有 workspace-relative plan contract
   - 验证与 `Plan H` 并行时不触碰 runtime checkpoint 状态系统

5. Plan B2
   - 验证 state/replay 移出 workspace
   - 验证 `plan/blueprint/history` 行为不变

6. Plan C
   - 验证 `suspend -> side task -> resume` 一进一出完整可回
   - 验证 resume 后 plan truth 不漂移

7. Plan B3
   - 需要独立定义更高等级的 contract migration gate

## 安全与性能
- 安全:
  - 不以“减少打断”为理由绕过高风险确认
  - 不以 Ghost 为理由破坏 plan truth
- 性能:
  - 优先通过策略层与路径路由层收口，不做全量重写
  - 总 plan 只作为协调文档，不加载超出当前决策所需的额外复杂度
