docs: align plan A consult cases and B1 merge strategy

Author: Li-Sanze

.sopify-skills/plan/20260326_5-plan-20260326-phase1-2-3-plan-plan-20260326-ph/design.md

@@ -282,6 +282,26 @@ workspace-local `.sopify-runtime/manifest.json` 只保留最小控制面字段
 5. legacy vendored workspace 仍可运行，但 fallback 状态在 bootstrap / doctor / status 中可见
 6. `plan/blueprint/history` 与 `plan_path / finalize / knowledge_layout` 的语义保持不变
 
+## 分支拆分、分批合并与单次 Stable 发布策略
+- 默认遵循 `main + topic branches + release tags`；`main` 是唯一长期主分支，stable release 只从 `main` 切
+- 本节的 4 个分支是“可独立验收的集成闭环”，不是 4 个对等的 stable 发布单元；分支级验收通过不等于应立即对外发 stable
+- 推荐按以下顺序分批合并，保持 `main` 持续可集成；默认只在后续完整 release preflight 与 stable smoke 通过后发一次 stable
+
+| 顺序 | 建议分支 | 承载主题 | 对应任务 |
+| --- | --- | --- | --- |
+| 1 | `feature/plan-b1-resolution-core` | 先收口 resolution core：thin stub、host-aware preflight、payload index 的主解析链 | `2.1-2.7`、`3.1-3.6`、`4.1-4.2`、`4.6-4.7` |
+| 2 | `feature/plan-b1-bootstrap-policy` | 再收口首次写入许可模型、ignore/commit-lock、root 选择与 bootstrap observability | `0.B.1-0.B.10`、`1.1-1.7` |
+| 3 | `feature/plan-b1-diagnostics-surface` | 在前两层稳定后补 diagnostics / CLI surface / hint contract / migration visibility | `4.3-4.5`、`4.A.1-4.A.5`、`5.1-5.2`、`5.5-5.6` |
+| 4 | `feature/plan-b1-regression-smoke` | 最后做回归矩阵、集成 smoke 与总验收门收口 | `5.3-5.4`、`5.A.1-5.A.3`、`6.1-6.8` |
+
+### 合并与发布约束
+1. 每个 topic branch 都必须先完成与自身直接相关的最小验证，再合入 `main`
+2. `branch-local pass` 只表示该主题可并入主线，不表示已经满足 stable release 条件
+3. `feature/plan-b1-resolution-core` 与 `feature/plan-b1-bootstrap-policy` 默认不单独发 stable；它们更适合作为后续分支的基础集成面
+4. `feature/plan-b1-diagnostics-surface` 是最早可能形成 release candidate 感知的节点，但默认仍不建议单独切 stable
+5. `feature/plan-b1-regression-smoke` 主要承担 closure / hardening；默认目标是补齐最终发布信心，而不是单独作为一个 stable 版本主题
+6. 默认 stable 切点是 4 个分支都已合入 `main`，且通过完整 release preflight、版本一致性检查与 stable smoke 之后
+
 ## 与 Program Plan 的关系
 - 本 plan 视为 `20260326_phase1-2-3-plan` 中 `Plan B1` 的升级实现窗口
 - 它在 control-plane 主线优先级上高于 `Plan A / Plan D`，但执行顺序上需先经过 `20260327_hotfix` 的状态机门禁

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

@@ -80,15 +80,17 @@
 Case（后续拆分 Plan A 子计划时必须覆盖）:
 - Case A-1 | checkpoint 中 explain-only 咨询不应二次物化
   - 场景: 已存在 `confirm_plan_package / confirm_decision` 等 pending checkpoint 时，用户提出“只分析、不改文件”的追问。
-  - 期望: 优先按 consult 回答并保持当前 checkpoint 身份稳定；除非用户明确提交 `继续 / 取消 / 1/2/...`，不得新建或重开 plan proposal。
+  - 期望: 优先按 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/...` 引用，但意图是“只分析/不改文件/判断是否认可”。
-  - 期望: 优先按 consult 或非阻断路径处理；仅在命中明确执行动作（如 `继续/next/开始/选择`）时进入 checkpoint 约束。
+  - 场景: 用户消息包含 `.sopify-skills/plan/...` 路径引用，或显式引用 existing plan（如 `plan_id / plan title`），但意图是“只分析/不改文件/判断是否认可”。
+  - 期望: 优先按 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”。
   - 期望: 只取消当前 pending（或返回已取消状态），并恢复到稳定可继续态；不得创建新的 proposal 或切到其他 checkpoint 类型。