Replies: 16 comments
补充：论证与实测记录上面的大纲说了「做什么」，这条补充说明为什么是这个顺序，并把结论建立在可复现的命令上。 一、交接材料的证据基线：7/7 核对通过总方案引用了 7 个 blob SHA 作为出处，逐个核对： git rev-parse 3d5fc5b46:docs/architecture/rfcs/semantic-vocabulary-convergence-v0.md
git rev-parse 3d5fc5b46:loopx/control_plane/quota/settlement_precedence.py
# …共 7 个全部精确匹配， 二、两个影响排期、但材料没回答的问题问题一：那些漏报是活的还是潜伏的？ 两个漏报今天都是潜伏的。 这不降低修复价值（守卫防的是未来改动），但把优先级从「有线上风险」降为「补一个已知漏洞」。 问题二：修好假确定性会不会撞棘轮？ PR-01 会让更多站点从「确定值集」变成 没有棘轮。 合并两点：PR-01 是本批风险最低的切片之一 —— 无活跃站点、无棘轮、反例可执行、单文件。 三、#4447 当前处于可干净关闭的状态在
没有残骸。 未完成的部分全是「没开始」，不是「做坏了」，且每条在 tracker 和 四、为什么建议先做一个十几行的切片，而不是并行 10 个约束不是方案质量，是管道。 实测 PR 队列： 路线图第 84 行是项目自己的规则：
交接材料自己的任务图也不支持高并发（ 叠加审批门禁后，既无冲突又无门禁的只有三条：PR-01 / PR-02 / PR-09，正好三个不同文件。 五、新增 PR-00：删除失效的
|
| 阶段 | 内容 | 依据 |
|---|---|---|
| 第 0 步 | PR-00 删失效的 REPAIR_ACTIONS |
零门禁；量管道 |
| 第 1 步 | PR-01 / PR-02 并行 | 不同文件、无门禁、无棘轮风险 |
| 第 2 步 | PR-09 | 依赖 PR-00 |
| 并行 | 推动三项维护者决定 | 不阻塞上面任何一步 |
| 第 3 步 | PR-03 / 05 / 06 | 决定到位后 |
| 第 4 步 | PR-04 / 07 / 08 | 串行，不并行 |
并建议给三项决定设降级路径：N 天无响应则先推进不依赖该决定的部分，并在 PR 描述中记录「等待哪项决定、影响哪个范围」，而不是整条线停等。
七、本次验证的边界
已执行：上述命令均在活的 checkout 上运行；架构套件、漂移守卫、blob 核对、AST 扫描、F5 注入实验为本轮实测。
未执行：完整 premerge、TypeScript 全集、性能基准、任何补丁应用。
不构成：维护者批准、CI 通过证明，也不是对交接包中历史微基准的重新测量。
PR-00：删除失效的
|
PR-01：修复生产扫描器的错误确定性建议标题
改哪里主要修改：
测试优先复用已有生产扫描测试；需要独立文件时，建议新增：
前期审计已记录 match 捕获、同名绑定、嵌套改写、容器逃逸和 应该如何实现先提交反例，再修判断。 对不属于普通赋值的绑定，撤销已经不成立的旧局部事实；容器被未建模的路径修改时，不能继续拿 initializer 当作完整结果。
测试应约束真正重要的性质：
不要要求所有反例永远只能返回 unknown，否则会阻止未来正确的精度改善。 明确不做不扩展词表、不改业务 action、route 或 receipt；不降低覆盖、不放宽预算；不把所有 unknown 变成全局失败；不顺手重写缓存、ranking 或整个静态分析框架。 前期 F5 明细错误如仍存在，可作为独立的小纠错提交处理，但不借此扩大投影验证范围。 验收与删除目标反例修前失败、修后通过；已有合法形式没有未解释退化；全树 unknown 的变化逐项说明。删除的是错误的确定性规则，不是新增另一套扫描器。 |
PR-02：保持结果一致地优化 consumer ranking建议标题
改哪里只修改：
以及必要的私有索引函数和排行差分测试。不要改 前期审计定位的热点是“每个 carrier 都重新搜索全部源码文本”。 应该如何实现先把原函数作为测试 oracle，再把生产实现改为：每份源码分词一次，按符号统计来源记录，扣除定义模块的记录。 必须保留原有口径：注释和字符串仍计数；同一文本内重复出现不多计；重复 最后比较整个返回对象和排序，而不只是比较总数。 明确不做不改变 consumer 定义、不缩扫描范围、不改 AST 生产分析、不改 registry 或预算，也不把词法提及升级为数据流证据。 验收与停止条件真实 这是独立可选 PR，不应该阻塞 M3 或运行路径收敛。 |
PR-03：定向修订原语义 RFC建议标题
改哪里仅以这两份现有规范为主体： 前面的双语修订草案可作为编辑起点，但仍是未批准、未应用的候选内容。 应该如何实现建议分成两个可独立评审的提交。 事实校正提交：区分 M0 和当前实现，修正 M1/Q6、M2、报告入口的时态；逐项写清已经实现的选择、批准证据和真正未决的问题。 规范修订提交：明确“减少独立维护”的目标、允许有证据的真实退役、F1/F2 的证据强度、最终决策与只读投影的边界，以及字段迁移、回滚和行为验收要求。 明确不做不把 Draft 自动改为 Accepted；不提前降低 anchor；不写“字段已退役”或“cross-runtime 已验证”；不新增 registry 状态体系、通用 DSL 或新的 required CI job。 验收双语一致、文档治理通过、历史测量保留原 SHA。文档批准方向，不等于 PR-05 的具体发布迁移已经批准，也不等于 PR-06 的检查已经实现。 |
PR-04：合并 live decision 内冗余的旧 packet 渲染建议标题
改哪里主改 这里有一个必须修正的实现方向：仓库已经有统一的 fields、summary renderer 和 packet builder，不应该再包一层函数，然后宣称完成统一来源。 应该如何实现先冻结基本 quota、paused、live 无变化、required reads、pending intent、两者同时存在以及 host 恢复路径的输出。 然后检查两个 helper 之间有没有读取中间 packet 的消费者。只合并已经证明没有必要观察者的区段。 推荐实现是：两个 helper 保留原有处理顺序，只返回一个内部“packet 依赖是否变化”的结果；live 入口收集后，在该区段出口调用已有 builder 一次。这个结果不写入 payload，不增加 CLI flag，也不缓存可变 payload。 出口不能随意搬到整个 live 函数末尾。现有流程后面还有 unsettled-host recovery、上下文和路由绑定，它们可能属于不同阶段。 明确不做不删除旧字段、不改变 notification、scheduler、pending intent 或恢复优先级；不为了“全链路只计算一次”增加公开的 unfinalized API。 基础 quota 对外返回一次完整 packet、live 变更后再生成一次，可以都是必要的。 验收与删除目标删除实际冗余的中间 packet 计算，完整 payload、summary 顺序、签名和命令保持契约一致。 若没有可删除的冗余，就取消这个 PR，把调用证据交给 PR-05；不要提交一个空 wrapper。 |
PR-05：退役
|
| 部分 | 主要位置 |
|---|---|
| 现行 writer | quota/should_run.py、should_run_packet.py、live_decision.py |
| 旧 packet 构建 | work_items/interaction_contract.py |
| Envelope 与签名 | quota/turn_envelope.py、turn_envelope.ts |
| Effect 观察 | effect_program.ts::interpretQuotaShouldRunPacket() |
| 测试与文档 | 现有 Envelope 测试、packet smoke 和对应协议 |
应该如何实现
先确定迁移合同，再 reader-first、writer-second。
PR 描述中必须写明目标发布边界、停止写入的输出范围、支持的旧格式和消费者、升级顺序及回滚区间。未决定时可以做 draft 和兼容测试，但不能删除默认字段后宣布完成。
先验证 reader 在字段缺失时的行为。当前 Effect reader 已按可空 summary 处理旧 packet，应优先利用它，不再新增一个同义 summary 字段。
再处理 Envelope 的新 payload、旧 packet、opaque fallback、residue 和签名分支。最后停止目标 writer，迁移当前消费者，删除确实没有调用的旧 builder/import。
protocol_action_packet_fields() 不能按名字一起删除：当前签名和 Envelope 仍使用它提供语义字段。
明确不做
不退役另外五个字段，不重写历史记录，不切换运行时 owner，不改三套 Turn 词表；不把保留的历史 reader 隐藏起来，以获得“预算归零”。
验收与完成标准
新格式的目标路径确实不再输出该字段；当前消费者已迁移；合法旧格式仍按批准范围读取；非法签名仍拒绝；真实 TS、CLI/host 和包资源测试通过。
集中生成、移到冷路径或降低计数，都不等于这个 PR 完成。
PR-06：只验证
|
todo_id |
replan_obligation_id |
真实 builder 应有的结果 |
|---|---|---|
| 非空 | 无或空 | todo |
| 无或空 | 非空 | autonomous_replan |
| 无或空 | 无或空 | unbound |
| 非空 | 非空 | 拒绝 |
当前 builder 和序列化代码已明确体现这四类情况。还要注意：todo/unbound 的旧 payload 并不都显式输出 binding_kind；不能为凑测试覆盖改变 wire 格式。
使用独立给定的输入和预期调用真实 TS，再通过现有 Python→TS 路径复核。复用固定 witness 机制，不能让 registry 字符串任意加载函数。
同步修改实际检查集合、域选择器、anchor、报告和测试。移除适配器、交换分支或产生越域值后，测试必须失败，报告也不能继续给验证信用。
明确不做
不一次扩展剩余全部词表；不把 unbound 变成允许执行或花费；不把三个案例通过包装成所有 producer 的完整闭合性证明。
完成标准
一个具名 builder 边界的真实证据交付完成。 原始 builder 与更严格入口的接受域分别说明，一个 pilot 不能自行关闭 #4447 的全部生产验证义务。
PR-07：收敛已结算重放的结果构建建议标题
改哪里主体位于： 重点包括 route precedence、 可以采用私有的 settled outcome 和专用 payload builder，但应优先放在现有模块，不因此新建全局“最终决策框架”。 应该如何实现先从真实 settlement readback 到 quota 输出建立特征测试，确定必要身份、receipt、绑定和当前资格已经验证完成的边界。 保留针对具体 Todo 的 guard 与必要重算。然后在一个位置形成 settled 结果，由专用 builder 构造该状态允许存在的输出，而不是先添加 replan、selected work 和 settlement 表达，再逐个删除。 迁移消费者后，再删除失去职责的旧覆盖逻辑；仍供其他路径使用的通用清理函数不能整文件删除。 一个关键范围限制这只处理目标 quota 阶段，不能把它变成整个 live 系统的 blanket early return。 现有 live 后面还有显式的 pending capability intent 和 unsettled-host recovery。应保护的是已经结算的同一工作身份不被重复选择、交付或花费，不能一概要求所有最终 live 输出都 验收同一已结算身份不选择新 successor、不重复花费；错误身份和缺失/冲突 receipt 仍拒绝；paused、monitor、pending intent、unsettled-host 的组合行为保持。 如果 producer site 随重构移动，registry 和相关 anchor 同 diff 更新，不能留下假 site 凑覆盖。 完成标志是旧多层修补被实际取代，而不是新 helper 又调用了一遍旧函数。 |
PR-08：收敛未准入选择的恢复构建建议标题
改哪里不能只改 recovery helper。应同时覆盖： 以及目标路径中确实提前生成 settlement/replan 表达的 interaction/packet 构建点。 应该如何实现先将 preflight 的事实判定与 payload 改写分离，复用一次判定结果。然后把可执行 settlement/replan 表达放到准入判断之后：已知 deferred/rejected 时，直接构建原契约要求的恢复响应。 恢复响应一次性形成 root、agent、CLI 和 execution obligation 的一致表达，使用已有错误码、 保留完整 argv 的 registry、runtime root、goal、agent、turn、scheduler 和 capability 绑定。 必须保留的正例“已准入但需要 workspace repair”不是 rejected。 当前 preflight 明确承认这条合法路径，同时区分 deferred/rejected 和已绑定身份冲突。不能用 验收与不做事项覆盖合法精确选择、workspace repair、抢占延期、一般拒绝、auxiliary monitor、身份冲突、首次拒绝和 identity-less receipt 重放。 首次拒绝继续不写持久化 receipt；已有绑定不被恢复代码偷偷升级。删除被取代的多处覆盖和清理，但不重新排序候选、不改 TS qualifier 的接受域、不改 receipt schema。 |
PR-09：显式化已登记动作的路由分类建议标题
改哪里只围绕：
以及附近的 应该如何实现先冻结真实路由矩阵，再显式列出每个已登记动作的分类。 映射要覆盖根字段实际支持的联合域，而不只是 保留 schema/signature、delivery/must-attempt、capability intent 和 no-run 分支的原顺序。当前 明确不做不把以前接受的未知值突然改成拒绝。 对于未知/旧值，本 PR 保持现行行为并隔离到明确的兼容分类函数。必要时仍保留旧 suffix/default 规则；彻底移除它，需要另一个获批的接受域迁移。 验收与完成标准登记域显式、穷尽、可评审；合法域差分一致；拒绝顺序与 capability 检查保持；legacy/unknown 单独验证。 仍有兼容 suffix 时，如实记录，不能宣称全项目已经不再按后缀分发。 实测补充（与本规格的一处差异）本规格写「必要时仍保留旧 suffix/default 规则」，把后缀当作显式集合的补充。实测：显式 因此本 PR 的性质是：不是在现有映射旁边加显式分类，而是那个映射根本不存在、需要写出来。范围是可枚举的 9 个 repair 值 + 22 个隐式落到 建议先完成 PR-00（删除失效集合），再开始本 PR。 |
PR-10：两类 inbox 来源的共同构造收敛试点建议标题
改哪里只选： 主要修改：
当前两种分支重复设置同类运行标志，但保留不同的 action 和 reason。 应该如何实现先固定 reply、material、terminal 和 automation-upgrade 等组合的实际优先级。 然后把共同的运行开关构造合并一次，来源选择只提供差异数据。可以使用现有模块内一个很小的私有 helper，也可以直接用清晰的局部表达式；不必为两个来源增加 package 或全局 保留同时 due 时 reply 的原优先级、两种 action/reason、各自工作对象，以及 task orchestration 只对原来对应动作生效的边界。 明确不做不重命名两个 wire 值，不合并渠道采集、派送、权限和结算，不一次改全部 32 个动作。 验收和收益声明这个 PR 的最低收益是：
它不等于“核心已完全不认识 inbox 来源”。只有下游独立解释实际移除后，才能宣称跨模块语义下沉。 如果提取后只是增加间接调用，反而更难阅读，应取消抽象，保留有价值的测试。这个试点允许失败，不应为了凑完成率强行合并。 二、建议的执行顺序第一批：PR-03、04、05、06。 第二批：PR-07、08。 第三批：PR-09、10。 三、每个 PR 最终都要交付的说明任务包中已经包含可直接用于 PR 描述的模板。最关键的是下面这组内容： 分派时每个实现者领取一份任务书，评审时按它的范围和验收判断；不要把整个任务包合成一个“大型语义重构 PR”。 这样才能让每一次改动都可归因、可回退，并看得见它究竟删除了哪一份维护负担。 |
补充二：实施纪律 —— 每一条都对应一种具体的误改方式下面不是原则口号，是已经识别出的具体出错方式。动手前逐条对照。 一、三个不同对象，不能一起删
按名字搜索删除会误伤签名 —— 二、显式路由分类不得顺手改变接受域把登记域显式化是行为保持重构；把原来可接受的未知/旧值改为拒绝是输入契约变更。 两者必须拆开：后者需要单独审查并明确版本，不能用字典默认值静默扩大或缩小接受域。纯重构 PR 里出现 三、registry 是治理声明，不是运行时权威源码 owner 与获准的生成契约才定义值域。不要让 registry 通过字符串动态加载运行函数，也不要把「已登记」当作「已验证」。 四、几个不能互推的结论
五、制造通过的几种方式，都不允许不降预算 · 不缩扫描范围 · 不隐藏 reader 来报零 · 不恢复陈旧 anchor · 不把测试期望全量重生成。 新 helper 或新类型只有真实替代旧路径才算减法；找不到净收益的 PR 应当取消，而不是为了凑计划保留。 六、关于候选补丁的一条技术判断历史审计留下的拆分补丁是串联的：正确性修复那一份依赖前一份「无锚点快速路径」改变的上下文，单独应用会失败。 而那个快速路径不属于现行任何一个 PR 的必做项。所以为了让正确性补丁应用而先打它，等于在 PR-01 里夹带一个未获批的优化。 结论：PR-01 应从反例重新实现，不是移植补丁。 反例本身（match capture 重绑定、同名 import/def/class/except、嵌套 nonlocal、容器逃逸、 七、一点保留：投放节奏十一个切片进入一个当前 29 个 open PR、24 个三天未动、0 个已批准在等的队列，前几个大概率会卡在同一处。 建议先走一个零门禁、零决定的切片（PR-00）量一量实际吞吐，再决定并行度 —— 如果十几行、不动协议的改动都推不动，问题在队列而不在切片。 |
补充三：边界判断 —— 哪些早期说法会把人带偏前两条是结论和核验。这条是动手前的判断依据：讨论过程中有若干宽泛表述后来被收窄过，按早期说法直接做会做错。 先更正我自己补充二第五节我写「没有给降级路径，建议补一条」。这是错的 —— 下面第二张表每一项待决事项都带「不具备决定时可做什么」。 一、十四条容易误读的说法与其真实边界
二、六项待决事项，以及没有决定时仍可推进什么
所以三项门禁不阻塞全部工作 —— 每项都有可先做的准备部分，条件是如实标注状态、不越界切换默认行为。 三、不同改动需要不同证据
四、明确不做不重做全仓状态模型 · 不切换权威语言 · 不引入超级
|
补充四：把 F1/F2 的验收改成「来源闭合」—— 一个可完成的目标#4447 剩余两项生产目标之一是「扩大 F1/F2 生产证据」。当前口径是给每个注册词表找到代码 producer。 这个口径不可完成：20 个 一、当前状态的精确分界（实测
|
| 数量 | 特征 | |
|---|---|---|
| 已闭合 | 6 | 5 个 runtime_producer + 1 个 compatibility_only |
| 未分类 | 20 | 全部 cross_runtime，且全部连 producers 键都没有 |
已闭合（全部 kernel 层）
agent_scope_frontier_action runtime_producer
effective_action runtime_producer
loop_disposition runtime_producer
turn_result_kind runtime_producer
turn_route runtime_producer
lease_action compatibility_only
分界线正好是 tier —— 6 个 kernel 全闭合，20 个 cross_runtime 全未分类。这与 formal_domain_bounds 报的 cross_runtime_unverified=20/20 一致。
二、建议的口径：来源分类，而不是「都找到 producer」
| 来源类型 | 必须具备 |
|---|---|
runtime_producer |
producer evidence |
external_input |
输入边界证据（decoder 的合法/非法输入测试） |
compatibility_only |
原因、保留范围、退出计划 |
local_only |
明确不跨边界 |
unknown |
不允许新增；现有项必须逐步消除或显式豁免 |
完成标准从「26/26 都找到代码 producer」改为：
26 个词表的来源都不再是隐式 unknown。
这把一个开放式目标换成了可验收的目标。
三、这不是新机制，lease_action 已经是它的雏形
"lease_action": {
"producers": [],
"compatibility_only": {
"acquire": {
"reason": "Retained by the legacy typed LeaseModeGateCommand input interface;
current runtime callers use separate command classes…
No persisted use is asserted.",
"retirement": "M4: retire the legacy Python lease-mode input interface…"
}
}
}schema 形状已存在、过过评审、smoke 已在校验。 所以这是把一个词表上验证过的模式推广到 26 个，不是发明新东西。
顺带：formal_model.candidate_decisions 的七个值里已经有四个正是这套来源分类（external_input / compatibility_only / local_only / unknown），另外三个（reuse_existing / extend_vocabulary / create_vocabulary）是造词决定。一个 enum 在做两件事，建议拆成 source_class(4) 与 coinage_decision(3)，unknown 作为共同未决态。
四、强制执行的成本：约 25 行，且糊弄不过去
原型验证（双向）：
当前状态 未闭合 20 个
只贴标签 未闭合 20 个 ← settlement_step_kind: source_class=external_input 但缺 source_evidence
标签 + 证据 未闭合 19 个 ← 已闭合 ✓
只填一个标签不算闭合，必须带 source_evidence。同时对已闭合的 6 个自动识别、零改动：producers 非空 → runtime_producer；producers=[] + compatibility_only 块 → compatibility_only。
五、真正的成本不在机制，在证据
检查本身是小时级的。实际工作是写 20 条 source_evidence —— 每条都要真的追出那些值从哪来，而且不能自动化（正是因为扫描器证明不了才需要人写）。
可加速的地方：20 条里有明显成组 —— delivery_workspace_* 3 个、settlement_* 3 个、goal_amendment_* 3 个、todo_completion_* 2 个、todo_decision_scope_* 2 个、receipt_bound_* 2 个、scheduler_* 2 个。七组覆盖 17 个，同组来源边界大概率相同，可共用一次追踪。
六、这条与现有 PR 的关系
PR-06 的 settlement_binding_kind 是这 20 个中的一个，作为首个真实边界的 pilot 是合适的。但 pilot 完成不等于这一项完成 —— 建议把「来源闭合」作为 #4447 的收尾判据之一，而 pilot 只证明证据形式可行。
补充五：PR-07 / PR-08 的实测依据 —— 一条事实被表达了三遍这两个切片的理由不是「代码不够优雅」，是可以数出来的维护负担。实测 一、「这个 heartbeat 已结算」这一条事实，要写 20 + 22 个字段
route.normal_delivery_allowed = False route.recovery_allowed = False
route.self_repair_allowed = False route.capability_repair_allowed = False
route.workspace_repair_allowed = False route.should_run = False
route.effective_action = EffectiveAction.HEARTBEAT_SETTLED_SKIP.value
route.replan_decision_allowed = False route.receipt_bound_replan_decision = False
route.heartbeat_recommendation = {...}
route.external_evidence_observation = None …共 8 个置 None然后 一条事实，三处表达。 二、而且两套表示的名字已经漂了这正是「必须同步维护的派生表达」的实例：加一个新字段时，要记得在两处都关掉它，而且两处叫法不同。 三、未准入选择：先构建，再拆除
payload["spend_allowed_now"] = False
payload["spend_after_validation"] = False
payload.pop("replan_action_packet", None)
agent.update(must_attempt=False, delivery_allowed=False, primary_action=command)
for field in ("settlement_plan","replan_settlement_contract","selection_command","selection_policy_ref"):
cli.pop(field, None)代码自己的注释就是那份负担的证据： # The current replan has not been admitted for this turn. Keeping its
# action packet would replace recovery in the compact TurnEnvelope.
payload.pop("replan_action_packet", None)有人必须注意到「先前构建的 packet 会挤掉恢复指令」，并记得删它。下一个加字段的人也得记得。 四、目标形态不是删掉这些防线，是改变生成顺序： 未准入同理：由未准入结果直接产生允许的 guard 恢复信息，而不是先持有可执行/可结算字段再逐项删。 五、两条必须守住的边界① 只有在现有 receipt、身份、绑定和兼容校验完成之后，才能走已结算的专用路径。不能为了提前返回而跳过校验。 ② 不能新建一个 wrapper 调用全部旧清理逻辑，然后宣称收敛完成。 完成判据是被取代的多处维护点实际删除，不是多一层封装。 六、验收应观察什么
七、一个容易出现的假优化把 32 个 action 改成 8 个 kind + 32 个 reason，但所有下游仍去 switch 那 32 个 reason —— 那只是搬家，没有收敛。 真正的完成标准是：新增一个局部原因，不需要修改无关的核心消费者。 |
Uh oh!
There was an error while loading. Please reload this page.
本帖只记录打算做什么、依据是什么、什么被卡住，不是已批准的方案。代码变更仍走各自 PR 评审。
一、已核实的基线
在
3d5fc5b46/da6d79778上实测：enforcement=unprovedprotocol_action_packet5py/2ts ·external_evidence_observation7/1 ·heartbeat_recommendation13/1 ·execution_obligation15/1 ·goal_boundary16/1 ·work_lane_contract29/3二、三处已复现的缺陷
① 扫描器报假确定性（P1）
真实行为：
emit("drop")→"drop"。扫描器报告：values={'run'}, unresolved=False。同类：
str(None)真实产出"None"，扫描器报values=set(), unresolved=False；而str(42)正确报 unresolved —— 处理不一致。现状：两者在产品代码里都是潜伏的（含 kernel 字段名的模块中 match-capture 0 处、写入 kernel 字段的单参数
str()0 处）。②
REPAIR_ACTIONS已失效（driver.py:43）5 个值（
capability_repair/projection_repair/self_repair/state_projection_repair/workspace_repair）不在任何注册词表、无任何生产者，其中 2 个在整个仓库只出现在driver.py自己里。→ 9 个真实 repair 值 100% 靠
endswith(("_repair","_repair_required"))后缀路由；另有 22 个值靠隐式默认落到READY_FOR_HOST。③ F5 明细分子分母同源（
semantic-vocabulary-drift-smoke.py:683,690）主体检查已 fail-closed（注入假 owner 验证过），明细路径未修 —— 是报告缺陷，不是门禁旁路。
三、切片与真实可并行性
REPAIR_ACTIONS/ 修正REPLAN_ACTIONSstr()假确定性consumer_rankingK×B → 一次索引protocol_action_packet停写settlement_binding_kind生产边界四、
protocol_action_packet的特别说明它不是普通旧字段，而是
execution_obligation/work_lane_contract/automation_liveness/scheduler_hint四个字段的摘要见证：有三份专属协议文档、一条写着 "Keep it" 的 v0 决策、TS 侧的重新推导校验（turn_envelope.ts:547-575）、以及effect-interpreter-packet.md:149记录的公开契约字段。且
protocol_action_packet_fields()仍承担签名与 Envelope 投影 —— 按名字搜索删除会误伤签名。它应当最后退役，不是最先。五、待维护者决定（阻塞三个切片）
protocol_action_packet停写的目标版本与外部消费者范围六、不做
不扩大扫描器至全程序分析 · 不新建规则引擎/知识图谱/第二套状态机 · 不为降低数字放宽预算或缩小扫描范围 · 不把 F6 持久兼容塞回 #4447
All reactions