Merge pull request #8 from sopify-ai/feature/plan-a-boundary-core

chore: Optimize planA && Feature/plan a boundary core

Author: Li-Sanze

.sopify-skills/plan/20260326_phase1-2-3-plan/design.md

@@ -77,14 +77,27 @@
 - 仅在 `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-03-31 / 2026-04-03）:
   - 样本组 1: `直接继续分析这个分支还剩什么需要你确认`、`分析下 为啥一件简单的事被网关卡成这样`、`说下怎么补case`
   - 样本组 2: `不要建包，只做确认项分析`、`取消这个 proposal checkpoint`
-  - 追溯结论: 这组样本共同暴露的是 pending checkpoint 语境下的 host-facing recall debt，而不是 `Plan H` 已收口的 state correctness 问题；后续应在 Plan A 统一覆盖 explain-only、existing plan referent、cancel checkpoint、mixed clause 四类语义，不在当前 `B1` 分支顺手落实现。
+  - 样本组 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。
@@ -168,6 +181,25 @@ Case（后续拆分 Plan A 子计划时必须覆盖）:
   - 约束:
     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

.sopify-skills/plan/20260326_phase1-2-3-plan/tasks.md

@@ -41,8 +41,8 @@ archive_ready: false
 - [x] 4.3 在 `20260327_hotfix` 中冻结 `snapshot-only resolver / proposal session-only / state_conflict + abort / unique handoff exit`
 - [x] 4.4 在升级版 Plan B1 中将 thin stub 校验、dual-host host-aware、payload index、ignore 默认值、legacy fallback reason code 作为硬门禁
   验收记录：上述硬门禁已在 B1 子 plan 中通过实现、回归与 smoke 验证收口；program plan 与 child plan 现已同步该验收结论，后续只保留 post-B1 polish，不再回流到 B1 主线。
-- [ ] 4.5 在 Plan A 子 plan 启动前登记 carry-over recall debt 与明确 non-goals，明确挂住 2026-03-31 这轮 `A-1 / A-3 / A-4 / A-5` 追溯样本（如“还剩什么需要你确认”“为啥被网关卡住”“不要建包，只做确认项分析”“取消这个 proposal checkpoint”），避免把 Plan H correctness hotfix 与后续语义召回增强混做一轮
-- [ ] 4.6 为 Plan A 子 plan 明确启动触发条件（真实漏判样本 / 用户反馈阈值），并要求先补齐 `A-1 / A-3 / A-4 / A-5` 的正反例矩阵与状态不变量断言（`required_host_action / checkpoint_id / current_plan_proposal / current_decision / plan/` 副作用），避免长期后延或提前侵入 B1 窗口
+- [ ] 4.5 在 Plan A 子 plan 启动前登记 carry-over recall debt 与明确 non-goals，明确挂住 `2026-03-31 / 2026-04-03` 这两轮 `A-1 / A-3 / A-4 / A-5 / A-8` 追溯样本（如“还剩什么需要你确认”“为啥被网关卡住”“不要建包，只做确认项分析”“取消这个 proposal checkpoint”“做 Plan A，但先不写方案包，只分析，不改”“只做 Plan A 样本矩阵草案，不建包、不改代码”），避免把 Plan H correctness hotfix 与后续语义召回增强混做一轮
+- [ ] 4.6 为 Plan A 子 plan 明确启动触发条件（真实漏判样本 / 用户反馈阈值），并要求先补齐 `A-1 / A-3 / A-4 / A-5 / A-6 / A-8` 的正反例矩阵与状态不变量断言（`required_host_action / checkpoint_id / current_plan_proposal / current_decision / plan/` 副作用）；`A-7` 作为冻结回归基线持续保留，`A-2` 归入 `V1.x parser robustness backlog`，避免长期后延或提前侵入 B1 窗口
 - [ ] 4.7 在 Plan A 中冻结 `ExecutionGate` 核心字段名与 `gate_status` 值集
 - [ ] 4.8 在 Plan B2 中明确“不改变 plan/blueprint/history contract”
 - [ ] 4.9 在 Plan C 中明确“bounded side task，不允许自由漫游”
@@ -52,6 +52,9 @@ archive_ready: false
 - [x] 4.13 在 Plan A 子 plan 中为 `question signal + retopic signal + plan referent` 建立结构化语义类矩阵（后缀/前置/中置疑问）
 - [x] 4.14 将 Case A-7 的验收矩阵固化为 parser 正反例与回归用例；通过标准必须包含“inspect fail-close + revise 保持 + mixed case 保持”
 - [ ] 4.15 将 `plan_proposal_pending + command prefix` 标记为“行为约束待产品确认”并与 parser 收口任务解耦，避免在同一轮混改
+- [x] 4.16 冻结 Plan A 实施切片边界：`V1 parser-first -> rollout/observability -> V2 guarded hybrid classifier`；其中 `A-2` 归入 `V1.x parser robustness backlog`，不阻塞当前 v1 开工门禁
+- [x] 4.17 冻结 Plan A 三张表的跨切层边界：表层保持语言无关、宿主无关；locale 只落在 `Signal Extraction`，宿主差异只落在 `Handoff / Output Adapter`
+- [x] 4.18 冻结总纲口径：classifier(v2) 仅作为 Plan A 的后置 gate 能力，不作为总纲独立执行分支，也不作为主路由替换方案
 
 ## 5. 明确延后方向
 - [ ] 5.1 若未来启动 B3，单独拍板 `plan_path` 新语义

.sopify-skills/plan/20260403_plan-a-risk-adaptive-interruption/background.md

@@ -0,0 +1,139 @@
+# 变更提案: 局部语义收口方案 | 风险自适应打断与局部语义分类收敛
+
+## 需求背景
+
+当前总纲已经把既有 control-plane 契约主线记录为主线收口，并明确下一步是在 `3.2` 的 control-plane contract 稳定后推进当前方案包。这意味着本方案现在已经进入可正式拆包的窗口，但还不适合直接进入代码实施。
+
+当前更合适的动作，是先把本方案从总纲中的“冻结边界 + 样本矩阵 + 零散探讨”收敛成一个独立的标准方案包，作为真正开工前持续迭代的设计工作台。
+
+本方案当前要解决的问题，不是再修一轮既有 correctness hotfix 主线那类状态机修补，而是把 pending checkpoint 语境下的 host-facing recall debt 系统化收口。近期真实样本已经稳定指向以下几类问题：
+
+1. explain-only / analysis-only 请求被重新物化成 proposal 或其他 pending checkpoint
+2. existing plan referent 被误判成新的阻断路径
+3. “取消 checkpoint”类表达在局部语境下不够稳健
+4. mixed clause 在逗号后从句里仍存在局部歧义
+5. `no-write / no-package / just-analyze` brake signal 会被 process semantic 覆盖
+6. `ready_for_execution + state_conflict(abort_conflict)` 仍需要作为本方案的设计门禁显式追踪
+7. 公开方案包中若残留显性来源锚点（第三方产品名/仓库名/专有函数名/源码路径），会带来版权/合规观感风险并削弱方案抽象独立性
+
+因此，本 plan 的目的不是“马上实现局部语义分类器”，而是把下面四类信息先写进一个可持续优化的正式方案包：
+
+1. 总纲中已经冻结的本方案边界与硬约束
+2. 外部参考实现中可借鉴的设计模式
+3. 当前已经定下来的候选方案、非目标、风险与实施前门禁
+4. 公开发布面的去显性来源化约束与验收口径
+
+## 研究输入
+
+本 plan 主要承接以下输入：
+
+1. program plan 中的本方案总纲与任务门禁
+   - `.sopify-skills/plan/20260326_phase1-2-3-plan/design.md`
+   - `.sopify-skills/plan/20260326_phase1-2-3-plan/tasks.md`
+2. 本轮已冻结的 A0 语义契约与 A-1 ~ A-8 样本矩阵
+3. 本地参考材料中与权限语义分类、工具权限门禁、局部上下文压缩相关的实现模式
+4. 当前公开口径评审结论：活动 plan 的目录名、`plan_id`、`feature_key` 保留为机器字段；Doc-1 只治理正文术语、图示标签、示例标识、分支名等展示层来源锚点
+
+## 当前已冻结约束
+
+以下内容已经在总纲层面冻结，本子 plan 只能承接，不能推翻：
+
+1. 本方案的职责是 host-facing 语义召回增强，不重开既有 correctness hotfix 主线已收口的状态机正确性修复
+2. 只允许在局部 checkpoint 语境下增强召回，不做全局自由语义理解
+3. 默认不改 runtime state model / handoff contract / resolution contract
+4. `ExecutionGate` 核心机器语义保持稳定
+5. `gate_status` 值集在 v1 不改
+6. `gate_status / blocking_reason / plan_completion / next_required_action` 不改名
+7. 不接受“单词/短语补丁式”修复，必须按同一语义类一次收口
+8. 默认与既有对外 contract 主线保持向后兼容
+
+## 为什么现在要起标准方案包
+
+当前适合起 `standard` 而不是 `light`，原因有三点：
+
+1. 它已经不是单点 parser 修补，而是要把背景、设计、任务门禁、候选方案和实施前 acceptance gate 分层写清楚
+2. 它需要同时承接总纲冻结内容、样本矩阵、参考实现经验，信息密度已经超过 `plan.md` 单文件能稳定承载的范围
+3. 真正实施前还会持续迭代，因此需要 `background.md + design.md + tasks.md` 三段结构来容纳“已定事实 / 候选方案 / 待决问题”
+
+## 当前方向判断
+
+基于这轮分析，本方案的推荐方向不是“先上一个全局自然语言分类器”，而是：
+
+1. 先用 deterministic guard 把 checkpoint machine facts 定死
+2. 再在局部语境里定义“当前可判动作面”
+3. 先收口 parser / structural semantics 能稳定覆盖的语义类
+4. 只把 residual ambiguity 留给后续可选的 semantic side classifier
+
+这个判断与本轮提炼出的参考实现经验一致：
+
+1. 不是词匹配优先，而是动作语义优先
+2. 不是全文自由理解，而是局部语境压缩后再判断
+3. 不是模型先判，而是 deterministic-first
+4. 不是分类失败继续猜，而是 fail-close 或降级人工确认
+
+## 影响范围
+
+本轮只创建并收敛方案包，不执行代码修改。后续 implementation candidate scope 预计会落在以下区域，但本 plan 暂不承诺全部实施：
+
+- `runtime/router.py`
+- `runtime/plan_proposal.py`
+- `runtime/checkpoint_cancel.py`
+- `runtime/output.py`
+- `runtime/context_snapshot.py`
+- `runtime/engine.py`
+- 相关 `tests/` 与回归样本
+- 当前方案包的公开命名与术语治理（标题、正文、图示标签、示例标识、分支命名）
+
+## 风险评估
+
+### 风险 1
+
+过早把外部参考实现中的侧路语义分类机制直接等同于 Sopify v1 实现，导致与当前已冻结的“parser 层优先收口”原则冲突。
+
+缓解：
+
+- 先把参考实现经验写成参考模式，而不是直接写成既定实现
+- 在 design 中显式区分“v1 推荐路径”和“vNext 候选方向”
+
+验证入口：见 tasks.md §C.4。
+
+### 风险 2
+
+把既有 correctness hotfix 主线问题、本方案 recall debt、以及产品行为拍板问题混成一轮。
+
+缓解：
+
+- 明确列出 non-goals
+- `plan_proposal_pending + command prefix` 已冻结为显式 fail-close，不视为自动继续信号
+- 把 A-6 的 state-conflict case 当成本方案的设计门禁，而不是顺手修补项
+
+验证入口：见 tasks.md §B.2.1/2.2。
+
+### 风险 3
+
+方案包起得太早，但内容仍停留在模板壳子，后续无法作为真正的设计工作台持续迭代。
+
+缓解：
+
+- 本轮就把总纲冻结内容、样本矩阵、参考实现经验与候选路线写全
+- tasks 只写设计收敛任务，不伪装成开发任务
+
+当前状态：已脱离模板壳，后续持续性收敛见 tasks.md。
+
+### 风险 4
+
+显性来源锚点在公开方案包中残留，导致对外读者形成“影射式搬运”观感，并引出版权/合规讨论风险。
+
+缓解：
+
+- 将“私有研究映射”与“公开抽象原则”分层管理：活动 plan 的机器身份保持不动，公开层只保留机制与约束，私有层保留具体映射笔记
+- 公开层只治理标题、正文、图示标签、示例标识、分支命名，不在文档侧直接改写目录名、`plan_id`、`feature_key`
+- 对展示层来源锚点执行一次性 denylist 扫描，要求零命中后再进入对外分享
+
+验证入口：见 tasks.md §F.8。
+
+## 评分
+
+- 方案质量: 9/10
+- 落地就绪: 7/10
+- 评分理由: 本方案的目标、边界、样本与兼容性约束已经足够清楚，适合正式拆成 standard 子 plan；但真正进入实施前，仍需先收口产品行为拍板项、状态不变量、以及“parser-first 还是 hybrid classifier”的阶段化策略。