From 64db4a1f2431906745e7ec1ac1b3df43b404b583 Mon Sep 17 00:00:00 2001 From: "sanze.li" <2522048902@qq.com> Date: Sun, 10 May 2026 13:08:17 +0800 Subject: [PATCH 1/4] chore: fix blueprint README archive pointer to P4b --- .sopify-skills/blueprint/README.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/.sopify-skills/blueprint/README.md b/.sopify-skills/blueprint/README.md index 2819634..8873b10 100644 --- a/.sopify-skills/blueprint/README.md +++ b/.sopify-skills/blueprint/README.md @@ -14,7 +14,7 @@ - 当前活动 plan：暂无。 -- history 归档：已可用；最近归档为 `../history/2026-05/20260509_host_capability_governance`。 +- history 归档：已可用；最近归档为 `../history/2026-05/20260509_p4b_runtime_surface_consolidation`。 ## 深入阅读入口 @@ -27,5 +27,5 @@ - [Sopify 最小协议规范 (Protocol v0)](./protocol.md) - [Skill 标准对齐蓝图](./skill-standards-refactor.md) - [变更历史](../history/index.md) -- 最近归档：`../history/2026-05/20260509_host_capability_governance` +- 最近归档：`../history/2026-05/20260509_p4b_runtime_surface_consolidation` From 5cd66890af21768bca038a62f826f64e4be4860a Mon Sep 17 00:00:00 2001 From: "sanze.li" <2522048902@qq.com> Date: Sun, 10 May 2026 14:36:57 +0800 Subject: [PATCH 2/4] plan: add P4b.5 runtime optionality audit plan package MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit P4b.5 审计方案包，定义 runtime optionality 的审计目标、 S1-S4 任务分解和交付物落点。 Scope: plan package only; blueprint 落文在后续 commit。 Context-Checkpoint: plan/p4b5 --- .../background.md | 46 ++++++ .../design.md | 146 ++++++++++++++++++ .../tasks.md | 62 ++++++++ 3 files changed, 254 insertions(+) create mode 100644 .sopify-skills/plan/20260510_p4b5_runtime_optionality_audit/background.md create mode 100644 .sopify-skills/plan/20260510_p4b5_runtime_optionality_audit/design.md create mode 100644 .sopify-skills/plan/20260510_p4b5_runtime_optionality_audit/tasks.md diff --git a/.sopify-skills/plan/20260510_p4b5_runtime_optionality_audit/background.md b/.sopify-skills/plan/20260510_p4b5_runtime_optionality_audit/background.md new file mode 100644 index 0000000..f0d59fa --- /dev/null +++ b/.sopify-skills/plan/20260510_p4b5_runtime_optionality_audit/background.md @@ -0,0 +1,46 @@ +# 背景: P4b.5 Runtime Optionality & Host Onboarding Audit + +## 前置里程碑 + +| 里程碑 | 核心产出 | 与本包关系 | +|--------|---------|-----------| +| P4a | Frozen External Surface keep-list（15 条） | 本包的 forbidden surface 从 keep-list 排除面正面化 | +| P4b | prove-kept-or-delete 全量扫描，结论：24,334 LOC 不可大幅瘦身 | 根因是大量 runtime 代码承载 distribution/installer contract，引出"runtime 何时可选"的问题 | +| Host Capability Governance bridge | 三级 ladder + checklist + quickstart 定义 + prompt 治理原则 | 已落地 `blueprint/design.md:402-456`；本包不重定义梯度，只在其上补审计 | + +## 问题陈述 + +P4b 证明了 runtime 删不动的根因，bridge 定义了三级宿主梯度——但两者之间缺少一层可操作的 **消费矩阵**： + +1. 每一级宿主**到底能消费哪些 state 文件和 contract 面**，至今只有 handoff 被显式提到（`design.md:414` "可选增强"），其余主链真相文件（clarification / decision）和可审计凭证（gate_receipt / ExecutionAuthorizationReceipt）的层级位置是空白 +2. **Forbidden surface 只有隐式表述**（`design.md:366` "未列入面默认可删"），新宿主无法从正面清单推导出"禁止触碰什么" +3. **接续锚点与授权凭证混在一起讲**——handoff 只回答"接下来做什么"，gate_receipt 回答"为什么被授权"，ExecutionAuthorizationReceipt 是协议级授权语义。三者消费层级不同，但现有文档没有分开归位 +4. P4c 多项验收条件（`tasks.md:76-80`）的执行边界取决于本包的审计结论 + +## 目标断言（待审计证明） + +> P4b.5 应证明：在 runtime-optional / runtime sunset 路线下，新宿主不接完整 runtime 也应能基于显式知识资产与冻结 session contract 继续知道该做什么并安全接班；但该能力不是 payload_capable 的默认最低准入，而是 payload_capable 内部若干 opt-in 增强组合的结果。具体增强档位、依赖链、必选项与禁止项，由 P4b.5 审计裁定。 + +背景要点： +- 蓝图大方向已明确往 runtime sunset 走（P4d 验证不接 runtime 的新宿主，P6 将 runtime 降为 reference implementation） +- 但 payload_capable 的现有 ladder 下限只到"payload 安装 + prompt asset 消费"，handoff 仍是 opt-in 增强（design.md:414, 417） +- 因此"新宿主能安全接续"不能直接等于"payload_capable 的最低准入能力"——它是同层内的可选能力组合 +- P4b.5 不预设哪些增强是必选，而是通过审计裁定 + +## 本包定位 + +**审计现有 bridge 的消费面归位，为 P4c 划定可执行边界。** + +- 不重定义三级梯度（已有） +- 不改代码 / schema / FeatureId 投影（属 P4c） +- 不新增 machine truth +- 产出物：consumption matrix + forbidden surface + blast radius 审计 + P4c boundary statement + +## 预算 + +| 维度 | 预算 | +|------|------| +| 新增代码 | 0 LOC | +| 新增 machine truth | 0 | +| 文档变更 | blueprint/design.md 补充审计结论；方案包 3 件套 | +| 测试影响 | 无（不改代码） | diff --git a/.sopify-skills/plan/20260510_p4b5_runtime_optionality_audit/design.md b/.sopify-skills/plan/20260510_p4b5_runtime_optionality_audit/design.md new file mode 100644 index 0000000..4a389fd --- /dev/null +++ b/.sopify-skills/plan/20260510_p4b5_runtime_optionality_audit/design.md @@ -0,0 +1,146 @@ +# 技术设计: P4b.5 Runtime Optionality & Host Onboarding Audit + +## 方案概述 + +1 个方案包，纯文档/审计变更。在 bridge 已定义的三级 ladder 之上，补充 **消费矩阵**（每级能碰什么）、**禁止面清单**（每级不能碰什么）、**blast radius 审计**（runtime 哪些模块在哪级可选），为 P4c 划定可执行边界。 + +## Scope 边界 + +### 在 scope 内 + +1. **Forbidden surface 正面化** — 将 `design.md:366` 的排除法隐式禁止转为每级宿主的显式禁止清单 +2. **Consumption matrix** — 对每个主链真相文件和可审计凭证，裁定在每级梯度的消费定位（required / optional / forbidden） +3. **接续锚点 vs 授权凭证拆面** — 将 handoff（接续）、gate_receipt（运行凭证）、ExecutionAuthorizationReceipt（协议授权）分开归位 +4. **Pending checkpoint 层级裁定** — 裁定 current_clarification / current_decision 在 payload_capable 是 required / optional / forbidden +5. **Blast radius 审计** — 评估 runtime 各主要模块（engine/router/gate/output/installer）在每级梯度的必需性 +6. **P4c boundary statement** — 基于审计结论，明确 P4c 的可执行范围和验收前提 + +### 不在 scope 内 + +- 不重定义三级梯度（design.md:409-415 已冻结） +- 不改代码 / schema / Python API +- 不做 FeatureId → 梯度的可执行投影矩阵（design.md:419 明确属 P4c） +- 不改 installer / adapter / output +- 不新增 machine truth / route / state file + +## 设计要点 + +### S1: Forbidden Surface 正面化 + +> 来源：design.md:340（运行态附属/可删派生）、design.md:366（未列入面默认可删） + +将隐式 forbidden 面转为显式三列表： + +| forbidden surface | 为什么禁止 | 来源 | +|-------------------|-----------|------| +| `state/sessions/*` | runtime 内部会话管理，非 contract 面 | design.md:340 | +| `state/last_route.json` | 可从 handoff/run 派生，derived surface | design.md:340, 328 | +| Route name 全集 / route taxonomy | runtime 内部路由枚举，不是宿主消费的 contract | design.md:366 | +| Output 渲染文案措辞（Next: / Status: 等 human hint） | derived 人类提示，不是 machine truth | design.md:374, 380, 393 | +| Runtime 内部模块边界（Python API 签名、class 结构） | 实现细节，不在 keep-list | design.md:366 | +| Gate 三元组直渲（gate_status / blocking_reason / plan_completion） | 内部 gate 状态机 leak | design.md:378 | +| Entry Guard Reason 内部守卫码 | runtime 内部守卫码 | design.md:388 | + +**适用范围**：所有三级梯度。此表是绝对禁止面，无论 convention_only / payload_capable / deep_verified 均不得将上述面作为稳定消费 contract。 + +> deep_verified 宿主的 runtime 内部可能事实上读取这些值（如 route_name 用于渲染），但这属于 runtime 实现细节，不是宿主的 contract 承诺。P4c 收敛 output 时需消除此类 leak。 + +### S2: Consumption Matrix + +> 来源：design.md:338（主链机器真相）、design.md:339（可审计凭证）、design.md:344-365（P4a keep-list） + +将接续锚点、运行凭证、协议授权三类面分开归位： + +**接续锚点（告诉下一步做什么）** + +| surface | 文件 | convention_only | payload_capable | deep_verified | 来源 | +|---------|------|-----------------|-----------------|---------------|------| +| Handoff contract | `state/current_handoff.json` | forbidden | **待裁定** | required | design.md:355, 414 | +| Run state | `state/current_run.json` | forbidden | **待裁定** | required | design.md:338 | +| Plan binding | `state/current_plan.json` | forbidden | **待裁定** | required | design.md:338 | + +> **注意**：handoff 在现有 ladder（design.md:414, 417）中是 payload_capable 的 opt-in 增强，不是准入条件。current_run 虽在 P4c 允许宿主消费的主链真相中（tasks.md:76），但现有 ladder 未将其列为中间层增强项。三者均作为待裁定对象，不预设并入"接续增强"。 + +**授权凭证（证明为什么被授权）** + +| surface | 文件/规范 | convention_only | payload_capable | deep_verified | 来源 | +|---------|----------|-----------------|-----------------|---------------|------| +| Gate receipt（运行级） | `state/current_gate_receipt.json` | forbidden | **待裁定** | **待裁定**¹ | design.md:354, 364 | +| ExecutionAuthorizationReceipt（协议级） | protocol.md §6 | **待裁定** | **待裁定** | **待裁定**¹ | design.md:351 | +| Archive receipt | `state/current_archive_receipt.json` | forbidden | **待裁定** | optional | design.md:364 | + +> ¹ deep_verified 按现状预期为 required，但不替代 S2 裁定。 + +> **EAR 层级说明**：ExecutionAuthorizationReceipt 是 protocol/doc contract（design.md:351），不是 runtime 专属产物。即便某梯度最终裁为 forbidden，理由应是"该梯度不承诺消费此协议面"，而非"无 runtime"。当前 gate_receipt 是一种常见运行态承载，不自动等同于 ExecutionAuthorizationReceipt 的唯一消费路径。避免把 runtime 耦合重新写回 contract 审计。 + +> **gate_receipt 消费者投影差异**：keep-list 表（design.md:354）将 gate_receipt 的 consumer 写为 `host / external_tool`，但 persistence red-line 表（design.md:364）写为 `external_tool`。此差异属本次审计范围——P4b.5 需裁定 payload_capable 宿主是否有合法消费 gate_receipt 的场景。 + +**Pending checkpoint（交互式等待）** + +| surface | 文件 | convention_only | payload_capable | deep_verified | 来源 | +|---------|------|-----------------|-----------------|---------------|------| +| Clarification | `state/current_clarification.json` | forbidden | **待裁定** | required | design.md:338 | +| Decision | `state/current_decision.json` | forbidden | **待裁定** | required | design.md:338 | + +> **裁定框架**：P4b.5 需在以下三档中为每个"待裁定"项选定位置： +> - **required**：进入该梯度的准入条件 +> - **optional**：可选增强，不阻断准入（与 handoff 在 payload_capable 的现有定位一致） +> - **forbidden**：该梯度不得消费 +> +> 裁定依据应基于真实接入场景分析（如"大模型规划 + 小模型编码 + 断点接续"），不做纯理论推导。 +> +> **payload_capable 内部分档预期**：payload_capable 是能力带宽，不是单点能力。审计可能产出若干 opt-in 增强组合（如接续增强、交互增强、审计增强），每个组合消费不同的冻结 contract 面、支持不同的用户场景。P4b.5 需审计这些组合的依赖链和互斥关系，但不预设哪些是必选。 + +**长期知识（所有梯度均可消费）** + +| surface | 物理对应 | 所有梯度 | 来源 | +|---------|---------|---------|------| +| Blueprint / Plan / History | `.sopify-skills/blueprint/`, `plan/`, `history/` | readable | design.md:336, 361 | +| Protocol | `blueprint/protocol.md` | readable | design.md:350-353 | +| Preferences / Feedback | `user/preferences.md`, `user/feedback.jsonl` | readable | design.md:337, 362 | + +### S3: Blast Radius 审计 + +评估 runtime 各主要模块在每级梯度的必需性： + +| runtime 模块 | convention_only | payload_capable | deep_verified | 备注 | +|-------------|-----------------|-----------------|---------------|------| +| `runtime/engine.py` | 不需要 | 不需要 | 需要 | 路由引擎，deep-only | +| `runtime/router.py` | 不需要 | 不需要 | 需要 | 路由决策 | +| `runtime/gate.py` | 不需要 | 不需要 | 需要 | gate 入口判定，deep-only 生产者 | +| `runtime/output.py` | 不需要 | 不需要 | 需要 | 渲染层 | +| `installer/` | 不需要 | 部分需要 | 需要 | payload 安装 | +| `runtime/context_snapshot.py` | 不需要 | 不需要 | 需要 | 会话上下文快照 | +| `runtime/failure_recovery.py` | 不需要 | 不需要 | 需要 | 容错恢复 | +| `runtime/message_templates.py` | 不需要 | 不需要 | 需要 | 消息模板 | +| `runtime/workspace_preflight.py` | 不需要 | 不需要 | 需要 | workspace 初始化 | + +> **生产者 vs 消费者区分**：上表评估的是"新宿主是否需要运行该 runtime 模块"，不是"新宿主是否消费该模块的持久化产物"。新宿主读 `current_gate_receipt.json`（消费冻结 contract 文件）不等于它在接入契约上依赖 `runtime/gate.py`（当前生产者恰好是 deep runtime）。持久化 contract 消费面的评估在 S2，不在 S3。 + +### S4: P4c Boundary Statement + +基于 S1-S3 审计结论，产出 P4c 的可执行前提声明： + +1. P4c 可以假设的 invariant（来自 P4b.5 审计结论） +2. P4c 需要做的实施项（来自消费矩阵的"待裁定"已裁定结果） +3. P4c 不能做的事（来自 forbidden surface 和 scope 红线） + +> 此声明落入 blueprint/tasks.md P4c 段或 blueprint/design.md 的 P4c 相关节。 + +## 产出物落点 + +| 产出 | 落入位置 | 说明 | +|------|---------|------| +| Forbidden surface 正面清单 | `blueprint/design.md` Host Capability Governance 节下新增 | 与现有 ladder 表同级 | +| Consumption matrix | `blueprint/design.md` Host Capability Governance 节下新增 | 含接续/授权/checkpoint 三个子表 | +| Blast radius 审计结论 | `blueprint/design.md` 新增审计节 或 方案包 design.md | 视篇幅决定 | +| P4c boundary statement | `blueprint/tasks.md` P4c 段更新 | 补充验收前提 | + +## 风险 + +| 风险 | 缓解 | +|------|------| +| "待裁定"项过多导致审计变成设计 | 严守裁定三档框架（required/optional/forbidden），基于场景分析，不做过度架构推导 | +| 审计结论和 P4c 验收条件冲突 | 审计先行，P4c 验收条件如有冲突则在 P4c 开包时修正 | +| gate_receipt 消费者投影差异导致讨论发散 | 限定为"payload_capable 是否有合法消费场景"的二元裁定，不重新定义 gate_receipt 的 keep-list 角色 | +| blast radius 审计面太广 | 只审计 runtime/ 顶层模块，不递归子函数级别 | diff --git a/.sopify-skills/plan/20260510_p4b5_runtime_optionality_audit/tasks.md b/.sopify-skills/plan/20260510_p4b5_runtime_optionality_audit/tasks.md new file mode 100644 index 0000000..973b5b2 --- /dev/null +++ b/.sopify-skills/plan/20260510_p4b5_runtime_optionality_audit/tasks.md @@ -0,0 +1,62 @@ +# 任务清单: P4b.5 Runtime Optionality & Host Onboarding Audit + +lifecycle_state: active +plan_status: drafting +蓝图命中: P4b.5（tasks.md:60-66） +前置里程碑: P4b（已完成）、Host Capability Governance bridge（已完成） + +## Plan Intake Checklist + +1. **主命中哪个蓝图里程碑？** → P4b.5 runtime_optionality_audit +2. **定义的是 contract acceptance boundary 还是 execution strategy？** → contract acceptance boundary（消费矩阵 + forbidden surface）→ 结论进 blueprint +3. **是否新增/删除/替代 machine truth？** → 否。只对现有 machine truth 做层级归位 +4. **若涉及 legacy surface，替代 contract 是否已稳定？** → N/A，不涉及替代 +5. **若影响 Core promotion rule / hard max / ownership / validator authority？** → 不影响 + +## 文档顺序（按依赖关系） + +S1 → S2 → S3 → S4 + +- S1 Forbidden surface 是 S2 consumption matrix 的前提（先知道"不能碰什么"才能定义"能碰什么"） +- S2 的接续/授权/checkpoint 三分类是 S3 blast radius 的输入 +- S3 的审计结论是 S4 P4c boundary 的依据 + +## 任务 + +### S1: Forbidden Surface 正面化 + +- [ ] 1.1 从 design.md:340, 366 收集所有隐式 forbidden 面 +- [ ] 1.2 从 design.md:368-393 Output Rendering Audit 收集已标记为 internal_taxonomy_leak 的面 +- [ ] 1.3 将收集结果整理为显式禁止清单（适用所有三级梯度） +- [ ] 1.4 写入 blueprint/design.md Host Capability Governance 节 + +### S2: Consumption Matrix + +- [ ] 2.1 对接续锚点三件套（handoff / run / plan）在每级梯度归位 +- [ ] 2.2 对授权凭证三件套（gate_receipt / ExecutionAuthorizationReceipt / archive_receipt）在每级梯度归位 + - 包括裁定 gate_receipt 消费者投影差异（design.md:354 vs 364） + - EAR 归位理由不得以"无 runtime"为由，须以"该梯度是否承诺消费此协议面"为判据 +- [ ] 2.3 对 pending checkpoint（clarification / decision）在 payload_capable 做 required / optional / forbidden 裁定 +- [ ] 2.4 对长期知识面（blueprint / plan / history / protocol / preferences）确认所有梯度 readable +- [ ] 2.5 物化 payload_capable 内部 opt-in 增强组合：产出一张组合表，至少覆盖接续增强 / 交互增强 / 审计增强 3 组 canonical 组合；每组定义消费哪些 contract、支持什么场景、组合间依赖链与互斥关系 +- [ ] 2.6 将完整矩阵 + 增强组合写入 blueprint/design.md + +### S3: Blast Radius 审计 + +- [ ] 3.1 列出 runtime/ 所有顶层模块 +- [ ] 3.2 对每个模块评估在每级梯度的必需性（需要 / 不需要） + - 严守"生产者 vs 消费者"区分：新宿主消费持久化 contract 文件不等于接入契约上依赖 runtime 模块 +- [ ] 3.3 写入审计结论 + +### S4: P4c Boundary Statement + +- [ ] 4.1 从 S1-S3 提取 P4c 可假设的 invariant +- [ ] 4.2 从 S2 的裁定结果推导 P4c 需做的实施项 +- [ ] 4.3 从 forbidden surface 推导 P4c 不能做的事 +- [ ] 4.4 更新 blueprint/tasks.md P4c 段，补充验收前提 + +### 收尾 + +- [ ] 5.1 自检：方案包内容是否与 design.md 现有 ladder 一致（不重定义） +- [ ] 5.2 自检：是否有任何"实现层变更"混入（不改代码/schema） +- [ ] 5.3 提交方案包 From 848069987c0167340c92a12a71809a883448dc3e Mon Sep 17 00:00:00 2001 From: "sanze.li" <2522048902@qq.com> Date: Sun, 10 May 2026 14:38:37 +0800 Subject: [PATCH 3/4] blueprint: add forbidden surface, consumption matrix, blast radius audit (P4b.5 S1-S3) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit S1: Forbidden surface 表（F1-F8），明确新宿主不得依赖的面。 S2: 消费矩阵（4 子表）+ opt-in 增强组合 + 官方接入画像 + 接入路径图。 S3: Blast radius 审计（15 功能区）+ 语义来源→落盘→contract 文件映射 + 5 条结论。 核心结论：payload_capable 对 runtime/ blast radius 为零； 消费冻结 contract 文件不等于依赖生产者模块。 Also: mark S1-S3 tasks as done in plan tasks.md. Context-Checkpoint: blueprint/host-capability-governance, plan/p4b5 --- .sopify-skills/blueprint/design.md | 160 ++++++++++++++++++ .../tasks.md | 26 +-- 2 files changed, 173 insertions(+), 13 deletions(-) diff --git a/.sopify-skills/blueprint/design.md b/.sopify-skills/blueprint/design.md index 22e1653..399a2a8 100644 --- a/.sopify-skills/blueprint/design.md +++ b/.sopify-skills/blueprint/design.md @@ -455,6 +455,166 @@ Deep 层（deep_verified 准入）： - 新宿主不进现有目录树结构；新宿主如需 prompt asset，走 payload 机制 - 讨论框架不是"要不要再开目录树"，而是"payload 机制是否满足需求" +**宿主禁止消费面（P4b.5 审计）** + +所有三级梯度（convention_only / payload_capable / deep_verified）均不得将以下面作为稳定消费 contract。违反此表意味着宿主与 runtime 实现细节产生耦合，P4c 治理时此类消费将被视为 leak。 + +| # | forbidden surface | 类型 | 为什么禁止 | 来源 | +|---|-------------------|------|-----------|------| +| F1 | `state/sessions/*` | 运行态附属 | runtime 内部会话管理，非 contract 面；超租约后可清理 | persistence 分层表 L340 | +| F2 | `state/last_route.json` | 可删派生 | 可从 handoff/run 派生，derived surface | persistence 分层表 L340, L328 | +| F3 | Route name 全集 / route taxonomy | 实现细节 | runtime 内部路由枚举，不是宿主消费的 contract；keep-list 不冻结 route 枚举 | L346, L366 | +| F4 | Gate 三元组直渲（`gate_status` / `blocking_reason` / `plan_completion`） | internal_taxonomy_leak | runtime 内部 gate 状态机，默认输出中不应前置 | Output Audit L378 | +| F5 | `Entry Guard Reason` 内部守卫码 | internal_taxonomy_leak | runtime 内部守卫码，非宿主需消费的 contract | Output Audit L388 | +| F6 | `Route: ` 直接暴露 | internal_taxonomy_leak | cancel_active / fallback 路径直接渲染 route_name | Output Audit L390 | +| F7 | Output 渲染文案措辞（`Next:` / `Status:` / `Decision Status:` 等 human hint） | derived 人类提示 | 由 route_name + gate_status + handoff 推导，不是 machine truth；宿主消费 handoff contract 而非 Next 文案 | Output Audit L374, L380, L385, L393; L366 | +| F8 | Runtime 内部模块边界（Python API 签名、class 结构、dataclass 名称） | 实现细节 | keep-list 不冻结 Python 内部 API；宿主消费的是持久化 contract 文件而非 Python 调用面 | L346, L366; keep-list non-goals 列 | + +> deep_verified 宿主的 runtime 内部可能事实上读取 F3-F7 中的值（如 route_name 用于渲染），但这属于 runtime 实现细节，不是宿主的 contract 承诺。P4c 收敛 output 时需消除此类 leak。 + +**消费矩阵（P4b.5 审计）** + +每个主链真相文件和可审计凭证在每级梯度的消费定位。接续锚点、授权凭证、交互 checkpoint 三类面分开归位。 + +_接续锚点（告诉下一步做什么）_ + +| surface | 文件 | convention_only | payload_capable | deep_verified | 来源 | +|---------|------|-----------------|-----------------|---------------|------| +| Handoff contract | `state/current_handoff.json` | forbidden | optional | 预期 required† | L355, L414 | +| Plan binding | `state/current_plan.json` | forbidden | optional | 预期 required† | L338 | +| Run state | `state/current_run.json` | forbidden | optional | 预期 required† | L338 | + +_授权凭证（证明为什么被授权）_ + +| surface | 文件/规范 | convention_only | payload_capable | deep_verified | 来源 | +|---------|----------|-----------------|-----------------|---------------|------| +| Gate receipt（运行级） | `state/current_gate_receipt.json` | forbidden | optional | 预期 required† | L354, L364 | +| ExecutionAuthorizationReceipt（协议级） | protocol.md §6 | forbidden | optional | 预期 required† | L351 | +| Archive receipt | `state/current_archive_receipt.json` | forbidden | optional | optional | L364 | + +_交互 checkpoint（AI 暂停等待）_ + +| surface | 文件 | convention_only | payload_capable | deep_verified | 来源 | +|---------|------|-----------------|-----------------|---------------|------| +| Clarification | `state/current_clarification.json` | forbidden | optional | 预期 required† | L338 | +| Decision | `state/current_decision.json` | forbidden | optional | 预期 required† | L338 | + +_长期知识（所有梯度均可消费）_ + +| surface | 物理对应 | 所有梯度 | 来源 | +|---------|---------|---------|------| +| Blueprint / Plan / History | `.sopify-skills/blueprint/`, `plan/`, `history/` | readable | L336, L361 | +| Protocol | `blueprint/protocol.md` | readable | L350-L353 | +| Preferences / Feedback | `user/preferences.md`, `user/feedback.jsonl` | readable | L337, L362 | + +> † "预期 required"表示按现状判断大概率为 required，但 P4b.5 是审计性质，此结论不替代后续里程碑的最终裁定。 + +> **convention_only forbidden 理由**：该梯度只承诺消费 protocol + 文件约定，不承诺消费运行态 state 文件或 receipt 实例面。 + +> **EAR 与 gate_receipt 的关系**：EAR 是 protocol/doc contract（L351），gate_receipt 是一种常见运行态承载（L354），两者不等同。EAR @ convention_only = forbidden 的理由是"该梯度不承诺消费协议级 receipt 实例语义"，不是"无 runtime"。 + +> **gate_receipt 消费者投影差异**：keep-list 表（L354）将 consumer 写为 `host / external_tool`，persistence red-line 表（L364）写为 `external_tool`。两者不矛盾：keep-list 说明有合法宿主消费场景（如 action_proposal_retry），red-line 表反映常态下的主要消费者。payload_capable 消费 gate_receipt 属于审计增强。 + +**Opt-in 增强组合（P4b.5 审计）** + +payload_capable 是能力带宽，不是单点能力。以下是 canonical 的三组 opt-in 增强： + +| 增强组合 | 消费的 contract 面 | 回答的问题 | 依赖 | +|---------|-------------------|-----------|------| +| **接续增强** | handoff + plan binding + run state | 上次停哪了？现在该干嘛？handoff 是核心前提，plan binding / run state 是补强接续上下文的常见配套面 | 无硬性前置依赖 | +| **交互增强** | clarification + decision | 当前是否卡在 clarification / decision checkpoint？即 AI 在等用户补事实或拍板 | 建议先有接续增强（否则缺执行上下文） | +| **审计增强** | gate_receipt + EAR + archive_receipt | 这次接续有没有授权？有没有证据链？gate_receipt + EAR 是核心授权证据；archive_receipt 是历史归档补强 | 无硬性前置依赖（可独立审计） | + +> 三组之间无互斥。交互增强对接续增强有弱依赖（建议而非必须）。 + +**官方新宿主接入画像（P4b.5 审计）** + +> 能力分层（ladder）定义"你属于哪级"，接入画像定义"官方新宿主至少该做到什么程度"。两者是不同的层，ladder 不因画像而改。 + +| 画像 | 能力层 | 增强要求 | 适用场景 | +|------|--------|---------|---------| +| **官方最低接入** | payload_capable + 接续增强 | 接续增强全组（核心：handoff；配套：plan binding + run state） | 所有官方新宿主的底线 | +| **对话式宿主** | payload_capable + 接续增强 + 交互增强 | 额外消费 clarification/decision checkpoint | 需要处理挂起的"AI 等人回答/拍板"状态的宿主 | +| **全审计宿主** | payload_capable + 接续增强 + 交互增强 + 审计增强 | 额外消费 gate_receipt/EAR/archive_receipt | 需要证明接续合法性和证据链的宿主 | + +> 此画像是 P4b.5 的审计建议，不改 ladder 定义。ladder 上 payload_capable 的准入仍为"payload 安装 + prompt asset 消费"（L414），但官方新宿主在此基础上应至少叠加接续增强。 + +**新宿主接入路径（P4b.5 审计）** + +``` +步骤 1: 读 protocol + 遵守文件约定 + ↓ + convention_only ✅ "算接入了" + 能读 plan、blueprint、protocol + 但不知道上次做到哪了 + ↓ +步骤 2: 装 prompt asset / payload + ↓ + payload_capable ✅ "拿到入场券" + 能装 prompt，消费 prompt asset + 但仍然不知道上次做到哪了 + ↓ +步骤 3: 叠加 opt-in 增强（官方新宿主至少到接续增强） + ↓ + + 接续增强：读 current_handoff（核心）+ plan binding + run state（配套）→ 知道上次停哪了、接下来该干嘛 + + 交互增强：读 clarification/decision → 知道是否卡在等人回答/拍板 + + 审计增强：读 gate_receipt/EAR（+ archive_receipt）→ 证明这次接续有授权、有证据链 + ↓ + 新宿主拿到 plan + handoff + 凭证 → 直接接着编码 ✅ +``` + +> 步骤 3 的每一项增强都是读冻结的 contract 文件（schema 被 P4a keep-list 保护），不是调 runtime API。不需要跑完整 runtime 也能接班。 + +**Blast Radius 审计（P4b.5 S3）** + +> 审计目标：评估 runtime/ 和 installer/ 各功能区在每级梯度的**模块运行必需性**。判定标准是"新宿主是否需要**运行**该模块"，不是"是否消费该模块的持久化产物"。持久化 contract 消费面的评估在 S2 消费矩阵，不在 S3。 + +> **模块计数口径**：runtime/ 59 个非 `__init__.py` 的 Python 模块（含 `_models/` 下 5 个），另有 `contracts/`、`builtin_skill_packages/` 两个资源目录（不计入模块数）。installer/ 11 个非 `__init__.py` 的 Python 模块（含 `hosts/` 下 3 个宿主适配器）。 + +| 功能区 | 包含模块 | conv | payload | deep | 备注 | +|--------|---------|:----:|:-------:|:----:|------| +| **核心管线** | engine, router, gate, execution\_gate, entry\_guard, gate\_output | ✗ | ✗ | ✓ | 路由/gate 决策循环，deep runtime 核心 | +| **状态持久化** | state, state\_invariants | ✗ | ✗ | ✓ | 所有 state/ contract 文件的统一落盘层（set\_current\_\* 方法族） | +| **上下文构建** | context\_snapshot, context\_recovery, context\_builder, context\_v1\_scope | ✗ | ✗ | ✓ | 会话上下文快照与恢复，deep runtime 的执行上下文供应链 | +| **Plan 编排** | plan\_orchestrator, plan\_registry, plan\_scaffold | ✗ | ✗ | ✓ | plan 生命周期由 runtime 驱动；payload\_capable 读 plan/ 目录（协议层面） | +| **Handoff / Checkpoint** | handoff, checkpoint\_materializer, checkpoint\_request, checkpoint\_cancel | ✗ | ✗ | ✓ | handoff.py 提供 handoff 语义；实际写盘经 state.py；接续增强消费 JSON 文件 | +| **Clarification / Decision** | clarification, clarification\_bridge, decision, decision\_bridge, decision\_policy, decision\_tables, decision\_templates | ✗ | ✗ | ✓ | 交互 checkpoint 语义来源；实际写盘经 state.py；交互增强消费 JSON | +| **Output / Templates** | output, message\_templates | ✗ | ✗ | ✓ | 渲染层，属 forbidden surface F5/F6 | +| **Skill 系统** | skill\_registry, skill\_resolver, skill\_runner, skill\_schema, builtin\_catalog | ✗ | ✗ | ✓ | deep runtime 技能调度 | +| **知识层** | kb, knowledge\_layout, knowledge\_sync | ✗ | ✗ | ✓ | KB 管理是 runtime feature | +| **校验 / Guard** | deterministic\_guard, action\_intent, action\_projection, develop\_callback, develop\_quality | ✗ | ✗ | ✓ | Validator 逻辑在 deep runtime 进程内运行 | +| **Archive** | archive\_lifecycle | ✗ | ✗ | ✓ | 归档语义来源；实际写盘经 state.py | +| **基础设施** | config, preferences, manifest, models, \_models/, \_yaml, contracts/, cli, cli\_interactive, resolution\_planner, sidecar\_classifier\_boundary, vnext\_phase\_boundary, failure\_recovery, workspace\_preflight | ✗ | ✗ | ✓ | runtime 内部基础设施；workspace\_preflight 是 deep 的启动检查 | +| **Installer: payload 安装** | installer/payload, hosts/, distribution, validate, models, outcome\_contract, inspection | ✗ | 工具† | ✓ | payload\_capable 通过 install.sh 调用，不直接依赖 Python API | +| **Installer: workspace 初始化** | installer/bootstrap\_workspace | ✗ | opt-in‡ | ✓ | workspace bootstrap 是 payload\_capable 的可选增强 | +| **Installer: runtime 打包** | installer/runtime\_bundle | ✗ | ✗ | ✓ | 只有 deep\_verified 需要完整 runtime bundle | + +> ✗ = 不需要运行；✓ = 需要运行；工具† = 通过 CLI 脚本间接调用（install.sh/install.ps1），不是 contract 级依赖；opt-in‡ = payload\_capable 可选增强，不是准入。 + +**语义来源 → 落盘路径 → contract 文件（S3 核心发现）** + +> 所有 state/ contract 文件的磁盘写入都经过 `state.py` 的 `set_current_*` 方法族统一落盘。下表的"语义来源"指提供业务语义和触发写入的模块，不是唯一写入者。 + +| 语义来源 | 落盘路径 | contract 文件 | S2 对应消费面 | +|---------|---------|--------------|--------------| +| handoff.py（+ engine.py 触发） | state.set\_current\_handoff | current\_handoff.json | 接续增强核心 | +| engine.py / state.py | state.set\_current\_run | current\_run.json | 接续增强配套（run state） | +| plan\_registry.py / plan\_orchestrator.py | state.set\_current\_plan | current\_plan.json | 接续增强配套（plan binding） | +| clarification.py（+ clarification\_bridge 触发） | state.set\_current\_clarification | current\_clarification.json | 交互增强 | +| decision.py（+ decision\_bridge 触发） | state.set\_current\_decision | current\_decision.json | 交互增强 | +| gate.py | state 直写 | current\_gate\_receipt.json | 审计增强 | +| archive\_lifecycle.py / engine.py | state.set\_current\_archive\_receipt | current\_archive\_receipt.json | 审计增强 | + +> 此映射是"当前事实"，不是"永久绑定"。P4c 及后续里程碑可以改变生产者实现，只要 contract 文件 schema 不变（P4a keep-list 保护）。 + +**S3 审计结论** + +1. **convention\_only 不需要任何 runtime/ 或 installer/ 模块**。全部能力来自读协议文档和遵守文件约定。 +2. **payload\_capable 不需要任何 runtime/ 模块**。其消费的机器真相文件都是冻结 JSON contract，由 P4a keep-list 保护 schema。消费文件 ≠ 依赖生产者模块。 +3. **payload\_capable 对 installer/ 的依赖是工具性的**，不是 contract 性的。宿主通过 install.sh 安装 payload，或按 protocol 手动放置文件。installer 的 Python 内部 API 不在接入契约范围内。 +4. **deep\_verified 对 runtime/ + installer/ 有完整能力覆盖依赖**。不是"每轮运行全部模块"——单次执行路径取决于具体 action/route，但能力层面需要完整 runtime 可用。这是设计预期，不是缺陷。 +5. **生产者 vs 消费者边界明确**：7 个 contract 文件的语义分别来自 ~7 个 runtime 模块，全部经 state.py 统一落盘。payload\_capable 消费产物（文件），不消费生产者（模块）。此边界由 forbidden surface F8 保护。 + ### 削减预算表 | 维度 | 当前 | Target | Hard Max | 计算口径 | diff --git a/.sopify-skills/plan/20260510_p4b5_runtime_optionality_audit/tasks.md b/.sopify-skills/plan/20260510_p4b5_runtime_optionality_audit/tasks.md index 973b5b2..b1bfa84 100644 --- a/.sopify-skills/plan/20260510_p4b5_runtime_optionality_audit/tasks.md +++ b/.sopify-skills/plan/20260510_p4b5_runtime_optionality_audit/tasks.md @@ -25,28 +25,28 @@ S1 → S2 → S3 → S4 ### S1: Forbidden Surface 正面化 -- [ ] 1.1 从 design.md:340, 366 收集所有隐式 forbidden 面 -- [ ] 1.2 从 design.md:368-393 Output Rendering Audit 收集已标记为 internal_taxonomy_leak 的面 -- [ ] 1.3 将收集结果整理为显式禁止清单（适用所有三级梯度） -- [ ] 1.4 写入 blueprint/design.md Host Capability Governance 节 +- [x] 1.1 从 design.md:340, 366 收集所有隐式 forbidden 面 +- [x] 1.2 从 design.md:368-393 Output Rendering Audit 收集已标记为 internal_taxonomy_leak 的面 +- [x] 1.3 将收集结果整理为显式禁止清单（适用所有三级梯度） +- [x] 1.4 写入 blueprint/design.md Host Capability Governance 节 ### S2: Consumption Matrix -- [ ] 2.1 对接续锚点三件套（handoff / run / plan）在每级梯度归位 -- [ ] 2.2 对授权凭证三件套（gate_receipt / ExecutionAuthorizationReceipt / archive_receipt）在每级梯度归位 +- [x] 2.1 对接续锚点三件套（handoff / run / plan）在每级梯度归位 +- [x] 2.2 对授权凭证三件套（gate_receipt / ExecutionAuthorizationReceipt / archive_receipt）在每级梯度归位 - 包括裁定 gate_receipt 消费者投影差异（design.md:354 vs 364） - EAR 归位理由不得以"无 runtime"为由，须以"该梯度是否承诺消费此协议面"为判据 -- [ ] 2.3 对 pending checkpoint（clarification / decision）在 payload_capable 做 required / optional / forbidden 裁定 -- [ ] 2.4 对长期知识面（blueprint / plan / history / protocol / preferences）确认所有梯度 readable -- [ ] 2.5 物化 payload_capable 内部 opt-in 增强组合：产出一张组合表，至少覆盖接续增强 / 交互增强 / 审计增强 3 组 canonical 组合；每组定义消费哪些 contract、支持什么场景、组合间依赖链与互斥关系 -- [ ] 2.6 将完整矩阵 + 增强组合写入 blueprint/design.md +- [x] 2.3 对 pending checkpoint（clarification / decision）在 payload_capable 做 required / optional / forbidden 裁定 +- [x] 2.4 对长期知识面（blueprint / plan / history / protocol / preferences）确认所有梯度 readable +- [x] 2.5 物化 payload_capable 内部 opt-in 增强组合：产出一张组合表，至少覆盖接续增强 / 交互增强 / 审计增强 3 组 canonical 组合；每组定义消费哪些 contract、支持什么场景、组合间依赖链与互斥关系 +- [x] 2.6 将完整矩阵 + 增强组合写入 blueprint/design.md ### S3: Blast Radius 审计 -- [ ] 3.1 列出 runtime/ 所有顶层模块 -- [ ] 3.2 对每个模块评估在每级梯度的必需性（需要 / 不需要） +- [x] 3.1 列出 runtime/ 所有顶层模块 +- [x] 3.2 对每个模块评估在每级梯度的必需性（需要 / 不需要） - 严守"生产者 vs 消费者"区分：新宿主消费持久化 contract 文件不等于接入契约上依赖 runtime 模块 -- [ ] 3.3 写入审计结论 +- [x] 3.3 写入审计结论 ### S4: P4c Boundary Statement From 5970f1d6105926fabdc5566d6e6d020e1d7f9055 Mon Sep 17 00:00:00 2001 From: "sanze.li" <2522048902@qq.com> Date: Sun, 10 May 2026 16:16:05 +0800 Subject: [PATCH 4/4] blueprint: add S4 comprehensive verdict and P4c boundary statement (P4b.5 closing) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit S4 综合裁定：5 段结构（总结、已证明结论、官方接入判定、 不裁死的边界、后续里程碑交接）写入 design.md。 P4c 前提声明：invariant 7 条 + 实施项 5 条 + 红线 6 条 写入 tasks.md P4c 段，P4c 开包时直接消费。 收尾：S1-S4 + 自检全部完成，tasks.md deep_verified 表述张力修复，P4c 收口附带结构整理任务补入。 Context-Checkpoint: blueprint/host-capability-governance, plan/p4b5 --- .sopify-skills/blueprint/design.md | 33 +++++++++++++++++ .sopify-skills/blueprint/tasks.md | 37 ++++++++++++++++++- .../tasks.md | 12 +++--- 3 files changed, 75 insertions(+), 7 deletions(-) diff --git a/.sopify-skills/blueprint/design.md b/.sopify-skills/blueprint/design.md index 399a2a8..4ada6f5 100644 --- a/.sopify-skills/blueprint/design.md +++ b/.sopify-skills/blueprint/design.md @@ -615,6 +615,39 @@ payload_capable 是能力带宽，不是单点能力。以下是 canonical 的 4. **deep\_verified 对 runtime/ + installer/ 有完整能力覆盖依赖**。不是"每轮运行全部模块"——单次执行路径取决于具体 action/route，但能力层面需要完整 runtime 可用。这是设计预期，不是缺陷。 5. **生产者 vs 消费者边界明确**：7 个 contract 文件的语义分别来自 ~7 个 runtime 模块，全部经 state.py 统一落盘。payload\_capable 消费产物（文件），不消费生产者（模块）。此边界由 forbidden surface F8 保护。 +**综合裁定（P4b.5 S4）** + +P4b.5 的审计结论不是"runtime 已可删除"，而是"新宿主接班所需能力已可用 contract 显式表达，并与 runtime 内部实现解耦"。新宿主要实现安全接班，不需要接入完整 runtime，但不能绕过显式 contract。官方最低接入画像应为 payload\_capable + 接续增强；runtime 在该路径中是 contract 生产者与 deep hardening 层，不是新宿主的接入前提。 + +**已证明结论** + +1. convention\_only 仍保留为定义层最低边界，负责界定"什么算进入 Sopify 生态"，但不是官方新宿主的真实落点。 +2. payload\_capable 是能力带宽，不等于完整接续；官方新宿主至少还应叠加接续增强。 +3. 新宿主接续依赖的是冻结的 state/ contract 文件与长期知识资产，不是 runtime 内部模块或 API。 +4. Forbidden surface 已显式列出（F1-F8），宿主不得依赖 sessions/\*、last\_route、输出文案、runtime 模块边界等未冻结面。 +5. payload\_capable 对 runtime/ 的 blast radius 为零；对 installer/ 仅有工具性依赖。 + +**官方接入判定** + +- **官方新宿主最低接入**：payload\_capable + 接续增强（handoff 为核心；plan binding + run state 为配套）。 +- **需要处理用户补事实/拍板**：再加交互增强（消费 clarification / decision checkpoint）。 +- **需要证明授权链**：再加审计增强（gate\_receipt + EAR 为核心授权证据；archive\_receipt 为历史归档补强）。 +- **deep\_verified**：仍保留为完整 runtime / installer / smoke 的高保证层，不作为新宿主默认前提。 + +**P4b.5 不裁死的边界** + +1. 不在 P4b.5 裁定 deep\_verified 的每个面是否最终全部 required，只保留"预期 required†"判断。 +2. 不在 P4b.5 重写 ladder 定义，只审计消费边界与 blast radius。 +3. 不在 P4b.5 变更 schema、代码实现或 installer/runtime 结构。 +4. 审计增强内部的长期最小组合（gate\_receipt / EAR / archive\_receipt 哪些是核心、哪些是补强）仍以后续试点 evidence 为准。官方最低接入不含审计增强这一点已在 S2 和 S4 官方接入判定中定下，此条不开放该结论。 +5. 若未来长期验证 convention\_only 只承担只读参与者角色，可在后续里程碑考虑降格或改名，但不在本次处理。 + +**对后续里程碑的交接** + +- **P4c**：负责把本次审计结论投影到实现层和 host adapter / installer / validator 消费面。详见 tasks.md P4c 段"P4c 前提声明"。 +- **P4d**：负责选非 deep 宿主做试点，验证 payload\_capable + 接续增强是否足以支撑真实接班。 +- **P5/P6**：再依据试点 evidence 逐步收缩 deep-runtime-only surface，并推动 runtime 向 reference implementation 退位。 + ### 削减预算表 | 维度 | 当前 | Target | Hard Max | 计算口径 | diff --git a/.sopify-skills/blueprint/tasks.md b/.sopify-skills/blueprint/tasks.md index bf28a45..2d57461 100644 --- a/.sopify-skills/blueprint/tasks.md +++ b/.sopify-skills/blueprint/tasks.md @@ -57,7 +57,7 @@ ✅ 已完成。prove-kept-or-delete 全量扫描证明 runtime 在当前 contract 约束下已接近最小可行体积（24,334 LOC）。<20K 目标在不改 distribution/installer contract 的约束下不可达。交付物：Phase 0 test re-audit（653 hard / 31 soft gate）、Phase 1 CI/preflight 真实降载、Phase 2 全量死代码扫描（15 LOC 删除）。归档：`history/2026-05/20260509_p4b_runtime_surface_consolidation/` -### P4b.5: Runtime Optionality & Host Onboarding Audit（待开） +### P4b.5: Runtime Optionality & Host Onboarding Audit（进行中） 设计/审计型，不大改代码。P4b 证明 runtime 不能靠内部删代码大幅瘦身，根因是大量 runtime 代码实际承载 distribution/installer contract。下一步需定义宿主接入层级，明确"runtime 可选"的规则边界。 @@ -79,6 +79,41 @@ - **Output contract convergence**：基于 P4a 审计分类，收敛 `runtime/output.py` 渲染层——① 状态符语义：定义 canonical route family → 符号映射（当前 consult=`!` 无明确约束）；② Next 降级：明确为 human hint，不再混合 `required_host_action` + `route_name` 推导，宿主消费 handoff 不依赖 Next；③ Changes 重定义：`loaded_files`（恢复上下文）从 Changed（实际写入）中拆出，或重命名为 Touched/Files；④ Gate 行简化：默认输出不暴露 `gate_status`/`blocking_reason`/`plan_completion` 三元组，详细诊断留给 doctor/status - **Builtin skill capability disclosure**：宿主文案稳定表达 builtin skill 的当前能力边界与可消费方式；AGENTS.md 只做消费投影，builtin_catalog 为唯一 truth source。当前 analyze/design/develop 是 phase-bound workflow skill（entry_kind=null, triggers=[]），不宣称 standalone invocation。若后续要支持 builtin skill 显式单独调用，必须先 formalize 独立的 invocation metadata contract / invocation syntax；在该 contract 明确前，本项只做披露，不预设其进入 P2 或单列里程碑。边界：只覆盖 builtin skill，不扩展到外部 skill discovery/routing/distribution（background.md 明确排除） +**P4c 前提声明（来自 P4b.5 S4 审计）** + +> 以下三部分基于 P4b.5 S1-S3 审计结论提取。P4c 开包时消费此声明，不重新证明已审计项。 + +**P4c 可以假设的 invariant** + +1. **Forbidden surface 已定义**（design.md F1-F8）：state/sessions/\*、last\_route、route taxonomy、Next:/输出文案、渲染层实现、runtime 内部模块边界均为 forbidden surface，适用所有三级梯度。P4c 的任何实施项不得引入对这些面的新宿主依赖。 +2. **消费矩阵已裁定**（design.md S2 四子表）：convention\_only 和 payload\_capable 的每项 contract 文件归位（required/optional/forbidden）已确定。deep\_verified 列部分项标为"预期 required†"，待 P4c 最终裁定。P4c 直接消费此矩阵，不重新审计层级归位。 +3. **三级 ladder 不变**（design.md L409-419）：convention\_only / payload\_capable / deep\_verified 的准入定义不因 P4c 改变。payload\_capable 准入仍为"payload 安装 + prompt asset 消费"。 +4. **payload\_capable 对 runtime/ 的 blast radius 为零**（design.md S3 结论 2）：payload\_capable 不需要运行任何 runtime/ 模块。消费冻结 contract 文件不等于依赖生产者模块。 +5. **生产者 vs 消费者边界明确**（design.md S3 语义来源表）：7 个 contract 文件的语义来源已映射，全部经 state.py 统一落盘。P4c 可以改变生产者实现，不能改变 contract 文件 schema（P4a keep-list 保护）。 +6. **官方接入画像已定义**（design.md S2）：官方最低接入 = payload\_capable + 接续增强全组；对话式/全审计宿主在此基础上叠加。此画像是独立于 ladder 的接入策略层。 +7. **EAR @ convention\_only = forbidden 已闭合**（design.md S2 消费矩阵）：convention\_only 不承诺消费协议级 receipt 实例语义。此裁定不在 P4c 重新开放。 + +**P4c 需做的实施项（由 P4b.5 推导）** + +1. **机器可检查投影矩阵**：将消费矩阵中的层级归位翻译为可执行的 FeatureId → 梯度映射规则（design.md L419 已预告此项属 P4c）。 +2. **增强检测机制**：P4c 需定义宿主如何声明/检测已激活的 opt-in 增强组合（接续/交互/审计）。当前无此机制，ladder 只定义准入面。 +3. **Output 渲染层收敛**：消除 forbidden surface F5（Next: 输出文案推导逻辑）和 F6（渲染层实现细节）中被新宿主事实上依赖的泄露。对应 P4c 已有的 Output contract convergence 项。 +4. **deep\_verified "预期 required†" 最终裁定**：消费矩阵中 deep\_verified 列的"预期 required†"项需在 P4c 做最终 required/optional 裁定。P4b.5 只做审计判断，不替代最终裁定。 +5. **Forbidden surface 执行保障**：P4c 需确保 F1-F8 中的每一项在实现层有对应的防泄露措施（如移除 prompt 中的 route\_name 直接暴露、收敛 Next: 推导逻辑等）。 + +**P4c 不能做的事（红线）** + +1. **不改 ladder 定义**：不修改三级梯度的准入条件，不新增/删除梯度。 +2. **不新增 machine truth**：不新增 state 文件、不新增 checkpoint 类型、不新增 contract 文件。若确需新增，须走 ADR 路径并对照削减预算表。 +3. **不改 P4a keep-list schema**：contract 文件的 schema 由 P4a 冻结面保护。P4c 可以改变生产者实现，不能改变 contract 文件结构。 +4. **不让 payload\_capable 依赖 runtime/ 模块**：这是 S3 的核心审计结论。任何 P4c 实施项如果引入 payload\_capable 对 runtime 模块的运行依赖，视为违反 P4b.5 审计边界。 +5. **不消费 forbidden surface**：P4c 实施项不得引入对 F1-F8 中任何面的新宿主依赖。消除已有泄露是 P4c 的目标，不是引入新泄露。 +6. **不解决 P4d/P5/P6 范围**：P4c 不预设新宿主试点（P4d）、不预执行 contract surface 删减（P5）、不预判 runtime 降级路径（P6）。 + +**P4c 收口附带：design.md 结构整理** + +> P4c 收口时，将 design.md Host Capability Governance 节中 P4b.5 的增量段（S1-S4）内化为稳定章节结构（Forbidden Surface / Consumption Matrix / Official Onboarding Profile / Blast Radius / Comprehensive Verdict）。此整理不改变观点，只优化文档结构，避免后续里程碑继续无限追加 S 段。 + ## 未完成长期项 ### P4b 后续路线（P4c 后视评估） diff --git a/.sopify-skills/plan/20260510_p4b5_runtime_optionality_audit/tasks.md b/.sopify-skills/plan/20260510_p4b5_runtime_optionality_audit/tasks.md index b1bfa84..092ec83 100644 --- a/.sopify-skills/plan/20260510_p4b5_runtime_optionality_audit/tasks.md +++ b/.sopify-skills/plan/20260510_p4b5_runtime_optionality_audit/tasks.md @@ -50,13 +50,13 @@ S1 → S2 → S3 → S4 ### S4: P4c Boundary Statement -- [ ] 4.1 从 S1-S3 提取 P4c 可假设的 invariant -- [ ] 4.2 从 S2 的裁定结果推导 P4c 需做的实施项 -- [ ] 4.3 从 forbidden surface 推导 P4c 不能做的事 -- [ ] 4.4 更新 blueprint/tasks.md P4c 段，补充验收前提 +- [x] 4.1 从 S1-S3 提取 P4c 可假设的 invariant +- [x] 4.2 从 S2 的裁定结果推导 P4c 需做的实施项 +- [x] 4.3 从 forbidden surface 推导 P4c 不能做的事 +- [x] 4.4 更新 blueprint/tasks.md P4c 段，补充验收前提 ### 收尾 -- [ ] 5.1 自检：方案包内容是否与 design.md 现有 ladder 一致（不重定义） -- [ ] 5.2 自检：是否有任何"实现层变更"混入（不改代码/schema） +- [x] 5.1 自检：方案包内容是否与 design.md 现有 ladder 一致（不重定义） +- [x] 5.2 自检：是否有任何"实现层变更"混入（不改代码/schema） - [ ] 5.3 提交方案包