docs(semantics): stage tracker acceptance around verified outcomes

[songoow]

The semantic tracker currently treats deleting a legacy field as necessary proof of useful progress. Discussion #4738 shows that protocol_action_packet still carries derived compatibility/signature meaning, so a low reader count is not evidence that deleting it is beneficial.

This bilingual RFC proposal makes M3 conditional on demonstrated maintenance/authority reduction and a versioned compatibility plan. It separates the long-range RFC from #4447's staged delivery acceptance: integrated guard/construction evidence, source closure for the registered set, then same-revision acceptance. The paired ledger records the current 7/26 evidence boundary and the remaining 19 cross-runtime entries. No budgets, runtime checks, formulas, source schema or protocol output change.

The issue remains open. This is the normative scope proposal; #4777 independently corrects implementation facts. Approval is required before the revised scope can justify tracker closure. Source classification does not become production verification, and missing evidence cannot be waived by labeling it documentation.

Validation: docs-governance smoke and diff/public-boundary checks pass. A local git merge-tree composition with #4777 at 95dad68e4 is conflict-free after separating the scope proposal from its factual readback insertion. Both language versions were checked for the same M3 gates and proof limits. No runtime/frontend tests are required for these architecture documents. The related simplification replaces the unconditional zero-field target instead of adding another runtime rule. Refs #4447 and discussion #4738; maintainer merge required.

[songoow]

Request changes conclusion (author-owned PR; GitHub blocks formal self-review)

动机

审阅对象是 exact head d8d93b1641d5af236eec3309cff8700ca1a1721f。旧 tracker 把删除首字段当作进展证明，混淆了机制与结果。此 PR 将 #4447 改成分阶段验收：先验证真实生产路径减负，再闭合登记词表的来源证据，最后在同一集成 revision 上复审；M3 只有在净收益和版本化兼容合同成立时才启动。这个方向与 issue、Discussion #4738 和当前 F1/F2 测量一致。

改动思路

规范 owner 仍是双语 RFC，issue #4447 继续拥有交付状态和排序，新 ledger 记录 proposal、baseline 与证据。提案没有增加 source schema、降低预算或把 classification 冒充 production proof。

正向路径是：维护者接受范围后，Stage 1 在集成树验证选定生产路径；Stage 2 对每个登记词表提供真实 producer、decoder、compatibility 或 local-only 证据；Stage 3 在同一 revision 记录 passed/failed/untested 后关闭。负向路径要求标签、未知项改名或单分支测试均不能获得证据信用。

具体改动

• M3 从“每字段必须归零删除”改为条件退役；入口要求净收益、目标版本、消费者、历史格式/签名和回滚窗口，退出要求真实删除与新旧格式验证。
• F1/F2 baseline 的 7/26 和剩余 19 个 cross-runtime 未验证项与 exact-head smoke 一致；提案正确禁止用 source classification 抬高 producer coverage。
• protocol_action_packet_fields() 被正确识别为 Envelope/signature 的兼容语义投影；保留它不等于继续在新 quota 输出写入 legacy field。
• 双语 staged ledger 的 proposal、baseline、三阶段流程和 fail-closed evidence 基本对应。

但有一个具体 blocker：英文 ledger 的 Stage 1 表仍要求 PR-04 “one final packet rendering”，中文镜像也固定为“一次最终渲染”。#4794 exact head 已删除 fresh quota/live/paused/recovery writers，真实 CLI/host 测试要求新输出及新 Envelope 都不含该字段，同时保留历史 v0 reader/signature。正确的零次渲染状态会被本提案判为未满足，甚至可能推动恢复已退休 writer；这也与本 PR 自己的条件 M3 条款冲突。

对主干的风险

P2 blocker：Stage 1 需要迁移状态感知。 最小修复是双语改为：不得重复构造 fresh packet；若 PR-05 获准，则新 quota 输出不再携带字段且历史 v0 reader/signature projection 保留；若未采用 PR-05，则现行字段最多完成一次最终渲染。同时把 #4794 写成“已实现、待合并”，不能写成 main 已交付。

修复后在 #4794 exact head 运行 tests/control_plane/test_protocol_packet_retirement_cli.py 与 test_protocol_packet_history.py；在 #4789 新 head 运行 docs governance、semantic drift smoke 和 git diff --check。其余风险较低：没有运行时代码、权限、默认行为或新 typed state；双语内容一致，分支落后于 main，更新后需按新 exact head 复审。

我的整体评价

REQUEST CHANGES conclusion。 条件式 M3 和来源闭合方向合理，绝大多数事实、范围与 guidance/obligation 边界已有证据；但 Stage 1 当前定义无法接受已实现且正确的 PR-05 状态，因此不能批准。修复这一双语条款后可聚焦复审。

English verdict: REQUEST CHANGES — exact head d8d93b1 has one P2 blocker: Stage 1 requires one final packet render even though the implemented PR-05 path correctly produces zero fresh packets while retaining historical readers; the bilingual acceptance contract must become migration-state aware.

[songoow]

Approval conclusion (author-owned PR; GitHub blocks formal self-approval)

动机

本次复审绑定 exact head 06ad97808ecda606d9a9f07f464ec210d6e237fa。该 PR 为 #4447/#4738 建立有限的分阶段验收：生产路径减负、登记词表来源证据闭合、同一集成 revision 的最终复核分别计证，不再用字段删除、标签填写或 PR 数量替代真实交付。

上一轮指出 Stage 1 固定要求“一次最终 packet 渲染”，会与 #4794 已实现的零 fresh writer 状态冲突。新 head 已修复该问题。

改动思路

RFC 继续拥有规范提案，#4447 继续拥有交付状态，ledger 只记录 proposal、baseline 和可复核证据。Stage 1 现在按迁移状态验收：采用 PR-05 时，新 quota 输出为零 fresh packet，同时保留历史 v0 reader/signature projection；未采用时，现行字段最多只有一次最终渲染。Stage 2 仍要求真实 producer、decoder、compatibility 或 local-only 边界证据，分类标签本身不获得 F1/F2 证明信用。

具体改动

关键内容讲解

• 英文和中文 staged ledger 同步改为迁移状态感知，并明确 #4794 是“已实现、待合并”，没有把 PR 状态写成主干事实。
• M3 仍是条件式退役：需要维护负担或权威减少、版本/消费者/历史签名/回滚边界和真实停写证据。
• 7/26 已验证与剩余 19 项未闭合的边界保持不变；source classification 不被包装成 executable proof。
• 最终验收继续要求在同一集成 revision 区分 passed、failed、untested。

对主干的风险

该 PR 只改四份公共文档，不改变运行时、权限、持久化、默认输出或 CI 门禁。上一轮 P2 已闭合：正确的零 writer 状态不会再被规范误判，也不会推动恢复已经退休的字段。

验证包括 docs governance、semantic vocabulary drift smoke、git diff --check，以及 #4794 的 packet retirement/history 聚焦测试；exact head CI 为 18 项成功，无 pending 或 failure。剩余风险是该分支落后于 main，若 head 变化必须重新复审；维护者是否接受此收尾口径仍属于现有 RFC/issue 决策。

我的整体评价

APPROVE conclusion。 新 head 修复了唯一 blocker，双语内容一致，验收规则现在同时容纳获准停写和未采用停写两种合法状态，并继续拒绝把来源标签冒充 F1/F2 证明。该 PR 可以进入维护者评审，但文档本身不代表 #4447 范围已获批，也不代表剩余 19 个词表已闭合。

English verdict: APPROVE — exact head 06ad97808ecda606d9a9f07f464ec210d6e237fa fixes the prior migration-state contradiction, keeps classification separate from executable F1/F2 evidence, and passes the relevant docs, semantic and exact-head CI checks.

[huangruiteng]

动机

本次审阅对象是 exact head 06ad97808ecda606d9a9f07f464ec210d6e237fa。#4447 与 discussion #4738 暴露的核心问题是：旧 tracker 把“字段归零”当成有用进展本身，可能奖励删除仍有价值的 compatibility/signature projection，也可能把词法计数或来源标签误当成生产证据。

本 PR 把 M3 改成结果导向的条件式退役：只有在确实减少重复权威或不必要消费者维护，并给出版本、消费者、历史格式/签名、回滚与正反向证据时，才进入字段停写；有价值的派生兼容投影可以保留。与此同时，#4447 的有限交付按“集成路径减负 → 登记词表来源闭合 → 同一 revision 最终验收”分阶段，不再要求一个 tracker 完成整份长期 RFC。

改动思路

权威边界没有被重排：双语 RFC 继续拥有长期规范，#4447 继续拥有当前交付状态和有序计划，paired ledger 只保存带日期的 proposal/baseline/evidence。文档明确标为 proposal，合并本 PR 不会自动宣告 #4447 完成，也不会把 #4794 的未合并实现写成主干事实。

正向流程是：M3 候选先证明净收益及版本化兼容边界；Stage 1 在集成树验证真实 guard 与 production-path simplification；Stage 2 为登记的 26 个词表分别提供 producer、decoder、compatibility 或 local-only 证据；Stage 3 在同一最终 revision 记录 passed/failed/untested，再由维护者接受范围。负向流程明确拒绝“降低计数、贴标签、改 unknown 名字、单分支本地测试”获得证据信用。

上一轮指出 Stage 1 固定要求“一次最终 packet 渲染”，会与 #4794 的零 fresh writer 目标矛盾；当前 head 已修成迁移状态感知：采用 PR-05 时 fresh quota/live/paused/recovery 输出无 packet，但历史 v0 reader/signature projection 保留；未采用时才要求保留字段最多在最终 live stage 渲染一次。

具体改动

1. 英文/中文 RFC 的 M3 行从“逐字段归零删除”改为条件式退休，并补齐 entry gate、exit evidence 与 rollback：净收益、目标版本、消费者、历史格式/签名、dynamic-key/unresolved 证据、新输出与历史拒绝测试、实际替代代码删除。
2. 长期 target 表不再要求 legacy field names 全部归零，改为“获准迁移面不保留无必要独立权威；有用派生/兼容字段可见”。
3. RFC 增加 #4447 staged acceptance proposal，明确它不是运行时证明或 tracker 完成记录。
4. 新增成对 ledger，记录 baseline 36134771355f05c9bcc5657ce739bb86426383dc、当前 F1/F2 7/26、剩余 19 个 cross-runtime 未验证项、三阶段证据与边界。

关键内容讲解

• M3 的新进入门把“想删字段”提升为“证明删它减少重复权威/维护成本且迁移可控”，避免低 reader count 自证删除价值。
• M3 的退出证据要求同时覆盖 fresh new-output 与 historical read/rejection；因此保留 protocol_action_packet_fields() 这样的历史签名投影不再被错误判成迁移失败。
• #4447 staged acceptance 把 long-range RFC 与有限 tracker 解耦，但 final closure 仍要求同一 integration revision、passed/failed/untested 区分和 maintainer acceptance。
• paired ledger 对 PR-05 采用/未采用两种合法状态分别给出 Stage 1 条件，不会再推动恢复已经退休的 fresh writer。

对主干的风险

这是 docs-only 规范变更，直接 runtime 风险低，主要风险是把 gate 写松：未来有人可能引用“兼容投影可以保留”，却不证明 writer 删除、净收益和历史安全；或者把 source classification 当成 F1/F2 production proof。当前文本对这两个风险都有明确防线：M3 要求实际替代代码删除和版本化兼容证据，Stage 2 明示 labels/renaming 无证据信用，Stage 3 仍由维护者验收。

验证结果：

• examples/docs-governance-smoke.py 通过；paired ledger 命名、镜像与链接约束正常。
• examples/semantic-vocabulary-drift-smoke.py 通过；当前事实仍为 F1/F2 7/26，cross-runtime unverified 19/20，没有预算、公式或 enforcement domain 改动。
• git diff --check origin/main...HEAD 通过。
• 与当前 main 的 git merge-tree 无冲突，生成 tree 3c6bca8ef1d165032a5dd54ca222f1a31acdac15；因此已合入的 RFC factual reconciliation 能与本 proposal 同时保留。

我也逐段比对了双语 M3、staged acceptance 和 ledger：规范性条件、数值边界与“不做”范围一致。远端 CI 按 capability 配置没有作为本轮证据。

我的整体评价

APPROVE。 这个 head 修复了上一轮的 migration-state 矛盾，并把 tracker 从“字段名归零”收敛为“可验证的权威/维护成本减少 + 兼容迁移 + 来源证据闭合”。它复用现有 RFC、issue 与 ledger owner，没有新增第二套 registry、runtime rule 或批准工作流；118/7 的文档体量与被澄清的协议/收尾边界相称。

这条批准接受的是 staged acceptance contract，不表示 #4447 已完成、不表示 #4794 已可合并，也不表示剩余 19 个 cross-runtime 词表已经获得生产证据。head 若变化，需要重新做 exact-head review。

English verdict: APPROVE - exact head 06ad97808ecda606d9a9f07f464ec210d6e237fa makes M3 and #4447 acceptance outcome-based and migration-state-aware; docs governance, semantic drift, diff hygiene, bilingual comparison, and a conflict-free current-main merge tree passed.