test(semantics): execute settlement and receipt source witnesses

[songoow]

Refs #4447 (Stage 2a); context #4738. #4789 remains an unapproved scope proposal.

The four settlement/receipt vocabularies had documented values but lacked a grouped executable account of their actual source boundaries. Add an architecture test and a thin witness that execute the shipped Turn reducer and file readback directly and through the Python bridge. Normal and terminal replay produce all four steps without invoking providers; identity/prefix rejection, provider refusal, unknown outcome and missing writeback exercise nine failure producers. Separate envelope tests cover external decoder admission/rejection. Monitor compatibility consumption and replay binding semantics remain explicit.

The paired RFC ledger records the limits: task-lease permission_denied production is not executed here; cancelled has decoder evidence but no identified producing branch; monitor settlement_pending is retained compatibility input. Synthetic receipt readback does not establish durable writer, full replan transaction, all-caller or F6 historical compatibility coverage. Source treatment does not enroll these entries in F1/F2: the production domain stays 7/26. No runtime, registry, source schema, global vocabulary or normative acceptance change.

Validation on baseline 36134771355f05c9bcc5657ce739bb86426383dc, Python 3.12.3 / Node 22.22.3:

• uv run --extra test python -m pytest tests/architecture/test_settlement_receipt_source_boundaries.py tests/architecture/test_semantic_settlement_binding_witness.py tests/control_plane/test_settlement_driver.py tests/control_plane/test_quota_settlement.py -q: 142 passed (62 in the new module), no skips.
• node --no-warnings --experimental-strip-types --test tests/control_plane_ts/turn_settlement.test.ts tests/control_plane_ts/quota_settlement_readback.test.ts: 58 passed, no skips.
• uv run --extra test python examples/docs-governance-smoke.py; focused Ruff lint/format and public-boundary scans: passed.
• uv run --extra test python examples/semantic-vocabulary-drift-smoke.py: passed, F1/F2 remain 7/26; initial run lacked local npm dependencies, repaired with npm ci --ignore-scripts.
• Strict standalone TypeScript check of the witness: passed after replacing its stdin reader with the standard Node API.

No frontend/Lark/CLI companion change is needed: only tests, the test witness and ledger entries are added. The related refactor pass found no production change appropriate to this evidence slice; the existing budget-text classifier remains characterized, not changed. Retained compatibility and the two missing producer obligations require owner review; this does not close the tracker. Maintainer merge only.

Current-head CI repair

Head 834d48758d5bce47b9e173647723f9a3c799ee37 includes the verified repair for date-dependent manager-context fixtures. Shared module-budget repair from #4793 is included as dependency ancestry, with current main incorporated; once #4793 lands its shared diff disappears from this PR. The PR-specific implementation is unchanged by this update.

Focused current-head validation: 130 passed, no skips or failures in that run. Diff checks pass. This is local evidence; the newly triggered remote CI remains authoritative for readiness. No PR was merged and no new unrelated feature PR was opened.

[songoow]

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

动机

#4447 Stage 2a 需要为 settlement/receipt 词表区分真实生产、外部输入和兼容消费，避免把“decoder 接受一个值”写成“产品会产生这个值”。exact head 834d48758d5bce47b9e173647723f9a3c799ee37 交付可复现来源证据和双语 ledger，不修改 registry、F1/F2 域或 runtime rule。

改动思路

三条证据互不替代：薄 Node witness 直接执行生产 reducer/readback；同一输入经 managed TS bridge 和 Python decoder/readback 复核；fabricated envelope 只用于 decoder admission/rejection，明确不计 producer witness。

具体改动

• committed replay 产生四类 receipt，且不再次 dispatch/checkpoint provider。
• 因果输入触发 identity、receipt、provider、terminal 和 unknown outcome failure，并比较 direct owner 与 bridge。
• 隔离文件事实驱动真实 readQuotaSettlement / read_heartbeat_settlement，覆盖 open/pending/settled、monitor commit 和 identity mismatch。
• unknown/null/numeric typed value 在 TS/Python decoder 均拒绝；settlement_pending 对 monitor 仅保留兼容消费。

对主干的风险

最大风险是把接纳、生产和兼容消费混成完成结论。ledger 明确保留：cancelled 无已识别 producer，permission_denied 的 task-lease producer 未执行，synthetic readback 不证明 durable writer、全 caller、完整 replan 或 F6；F1/F2 仍为 7/26。142 Python、58 TS、shared ancestry tests、docs governance、drift、lint 和最终 CI 通过。550 行 architecture test 较大，但覆盖 direct TS、managed runtime、Python adapter 与兼容消费者这一条不可拆散的来源链，具有持久价值。

我的整体评价

APPROVE。 真实 owner 被执行，decoder evidence 没有冒充 production，未证明边界保持具名；这是 Stage 2a 的合理增量，不代表 tracker 已关闭。

English verdict: APPROVE — exact head 834d487 executes real settlement/readback owners, keeps decoder admission separate from production, preserves unresolved gaps, and passes focused validation and CI.

[huangruiteng]

动机

我按 exact head 834d48758d5bce47b9e173647723f9a3c799ee37 重新从当前 origin/main 的实际差异审阅了这次 Stage 2a 证据增量。当前主干差异只有 4 个新增文件（两份双语 ledger、一个 19 行 Node witness、一个 550 行 architecture test），不包含 PR 历史里已经落入主干的 Lark/chat 文件。

这批改动解决的是一个真实而细微的证据边界：“decoder 接受某个 typed value”不等于“产品存在会产生该 value 的 branch”。如果这两类证据混在一起，cancelled、permission_denied 等值会被过早判定为 production-complete，后续语义收敛和兼容决策都会建立在错误前提上。PR 把这个边界做成了可执行证据，同时明确不改变 runtime、registry 或 F1/F2 enrollment，目标和边界一致。

改动思路

实现没有复制 settlement 规则，而是让一个极薄的跨进程 witness 直接调用现有 TypeScript owner：reduceTurnSettlementTransaction 与 readQuotaSettlement。Python architecture test 再用同一输入对照 direct TS、managed effect bridge 和 Python decoder/readback consumer，从而区分三类事实：

1. 真实 owner 在因果输入下实际产出的 receipt/failure/phase；
2. 外部 envelope 能否被 TS/Python decoder 接纳或拒绝；
3. 历史兼容 consumer 仍能消费、但当前 builder 不再生产的状态。

这个分层是对的：TypeScript 继续拥有 reducer/readback 决策权，Python 只适配和消费；测试没有在 Python 中重建第二套状态机。ledger 也保留了未证明边界：synthetic receipt files 不是 durable writer 证据，cancelled 仍没有已识别 producer，permission_denied 的 task-lease producer 没有在本批执行，F1/F2 仍是 7/26。

具体改动

关键代码讲解

• scripts/settlement_receipt_source_witness.mts:9 的 operation switch 只允许 turn 和 readback，分别调用既有 TS owner；未知 operation 直接失败。它只做 stdin/stdout transport，没有新增状态、fallback 或 provider side effect。
• tests/architecture/test_settlement_receipt_source_boundaries.py:146 用 invalid identity、缺 receipt、effect mismatch、provider/budget/terminal refusal 等因果输入驱动真实 reducer，并要求 direct TS 与 managed bridge 完全一致、失败时没有 provider effects、Python decoder 保留 exact typed failure。
• tests/architecture/test_settlement_receipt_source_boundaries.py:183 对已提交 transaction 安装 fail-fast provider/checkpoint callbacks，证明 replay 只重建 validation/writeback/spend/terminal receipts，不会重复执行 durable effect。
• tests/architecture/test_settlement_receipt_source_boundaries.py:392 用隔离的临时 receipt 文件驱动真实 TS/Python readback，覆盖 open -> settlement_pending -> settled、重复读、exact monitor commit、legacy effect id 与 identity mismatch；wrong effect 时不会先投影 phase。

文件职责也清楚：Node 文件只跨 runtime 调 owner；Python 文件覆盖 direct/bridge/consumer 的一条完整来源链；双语 ledger 记录已证明事实、未证明事实和下一步，未把测试输出升级成新的 production contract。

正向路径上，完整 transaction 产生同一 effect id 的 typed receipts，completion + durable writeback + spend 投影为 settled，exact monitor commit 投影为 monitor settled；direct TS、managed bridge 和 Python consumer 一致。负向路径上，unknown/null/numeric typed values 被两端拒绝，prepared+unknown outcome 不能误判成 retry/success，identity mismatch 不投影 phase，provider refusal 保留对应 failure kind。

对主干的风险

本 PR 不改 production module，因此运行时回归面较低；主要风险是测试本身给出过强结论，或大体量 smoke 与已有 owner 单测重复。这里的控制是充分的：

• ledger 明确把 admission、production、compatibility 分开，并逐项写出未覆盖的 durable writer、全部 caller、完整 replan、live CLI/backend 与 F6 历史兼容；
• 550 行虽然大，但它覆盖的是无法由单一 owner 单测替代的 TS owner → managed bridge → Python adapter/consumer 跨 runtime 链，且没有抽出新的语义 helper 或复制 business rule；
• typed values 仍来自现有 enum/schema，identity 与 phase 判断使用 exact typed/effect-id 规则，没有 substring denylist、prose-only classification、默认行为变更或新 authority surface；
• future-facing refactor 检查后，我没有建议再抽象一层：继续保持 19 行 witness 只做 transport，比引入通用 test framework 更容易定位、审阅和删除。

我实际执行并读回了以下验证：

• 相关 Python 组：142 passed in 7.53s；
• native TS settlement/readback：58 passed，无 skip；
• focused Ruff、npm run typecheck:control-plane、git diff --check、docs governance、semantic drift smoke 全部通过；
• semantic drift 仍报告 F1/F2 7/26 与 19 个未验证 cross-runtime entries，没有被本 PR 偷偷“结案”；
• exact head 的 DCO、dependency review、build、兼容性、分片测试、correctness、pytest 和 merge-gate 均成功，只有预期的 deploy/publish/presentation job 跳过。

剩余合并风险不是代码 blocker，而是该分支当前 BEHIND：如果 rebase/update 产生新 head，需要对新 exact head 重新确认差异和结论。

我的整体评价

APPROVE。 这不是用更多 fixture 假装拥有 producer，而是执行现有 owner、明确 decoder admission 的证据等级、保留未证明事项，并用跨 runtime 的失败闭合路径防止未来再次混淆。范围对 Stage 2a 是完整且可回滚的 evidence increment；未发现需要阻塞当前 exact head 的问题。

English verdict: APPROVE - Exact head 834d487 executes the existing settlement and readback owners, keeps decoder admission distinct from production evidence, preserves unresolved source gaps, and passes focused Python/TypeScript, static, semantic-drift, documentation, and required CI validation.

The merge-base changed after approval.

[huangruiteng]

动机

我按 exact head 834d48758d5bce47b9e173647723f9a3c799ee37 重新从当前 origin/main 的实际差异审阅了这次 Stage 2a 证据增量。当前主干差异只有 4 个新增文件（两份双语 ledger、一个 19 行 Node witness、一个 550 行 architecture test），不包含 PR 历史里已经落入主干的 Lark/chat 文件。

这批改动解决的是一个真实而细微的证据边界：“decoder 接受某个 typed value”不等于“产品存在会产生该 value 的 branch”。如果这两类证据混在一起，cancelled、permission_denied 等值会被过早判定为 production-complete，后续语义收敛和兼容决策都会建立在错误前提上。PR 把这个边界做成了可执行证据，同时明确不改变 runtime、registry 或 F1/F2 enrollment，目标和边界一致。

改动思路

实现没有复制 settlement 规则，而是让一个极薄的跨进程 witness 直接调用现有 TypeScript owner：reduceTurnSettlementTransaction 与 readQuotaSettlement。Python architecture test 再用同一输入对照 direct TS、managed effect bridge 和 Python decoder/readback consumer，从而区分三类事实：

1. 真实 owner 在因果输入下实际产出的 receipt/failure/phase；
2. 外部 envelope 能否被 TS/Python decoder 接纳或拒绝；
3. 历史兼容 consumer 仍能消费、但当前 builder 不再生产的状态。

这个分层是对的：TypeScript 继续拥有 reducer/readback 决策权，Python 只适配和消费；测试没有在 Python 中重建第二套状态机。ledger 也保留了未证明边界：synthetic receipt files 不是 durable writer 证据，cancelled 仍没有已识别 producer，permission_denied 的 task-lease producer 没有在本批执行，F1/F2 仍是 7/26。

具体改动

关键代码讲解

• scripts/settlement_receipt_source_witness.mts:9 的 operation switch 只允许 turn 和 readback，分别调用既有 TS owner；未知 operation 直接失败。它只做 stdin/stdout transport，没有新增状态、fallback 或 provider side effect。
• tests/architecture/test_settlement_receipt_source_boundaries.py:146 用 invalid identity、缺 receipt、effect mismatch、provider/budget/terminal refusal 等因果输入驱动真实 reducer，并要求 direct TS 与 managed bridge 完全一致、失败时没有 provider effects、Python decoder 保留 exact typed failure。
• tests/architecture/test_settlement_receipt_source_boundaries.py:183 对已提交 transaction 安装 fail-fast provider/checkpoint callbacks，证明 replay 只重建 validation/writeback/spend/terminal receipts，不会重复执行 durable effect。
• tests/architecture/test_settlement_receipt_source_boundaries.py:392 用隔离的临时 receipt 文件驱动真实 TS/Python readback，覆盖 open -> settlement_pending -> settled、重复读、exact monitor commit、legacy effect id 与 identity mismatch；wrong effect 时不会先投影 phase。

文件职责也清楚：Node 文件只跨 runtime 调 owner；Python 文件覆盖 direct/bridge/consumer 的一条完整来源链；双语 ledger 记录已证明事实、未证明事实和下一步，未把测试输出升级成新的 production contract。

正向路径上，完整 transaction 产生同一 effect id 的 typed receipts，completion + durable writeback + spend 投影为 settled，exact monitor commit 投影为 monitor settled；direct TS、managed bridge 和 Python consumer 一致。负向路径上，unknown/null/numeric typed values 被两端拒绝，prepared+unknown outcome 不能误判成 retry/success，identity mismatch 不投影 phase，provider refusal 保留对应 failure kind。

对主干的风险

本 PR 不改 production module，因此运行时回归面较低；主要风险是测试本身给出过强结论，或大体量 smoke 与已有 owner 单测重复。这里的控制是充分的：

• ledger 明确把 admission、production、compatibility 分开，并逐项写出未覆盖的 durable writer、全部 caller、完整 replan、live CLI/backend 与 F6 历史兼容；
• 550 行虽然大，但它覆盖的是无法由单一 owner 单测替代的 TS owner → managed bridge → Python adapter/consumer 跨 runtime 链，且没有抽出新的语义 helper 或复制 business rule；
• typed values 仍来自现有 enum/schema，identity 与 phase 判断使用 exact typed/effect-id 规则，没有 substring denylist、prose-only classification、默认行为变更或新 authority surface；
• future-facing refactor 检查后，我没有建议再抽象一层：继续保持 19 行 witness 只做 transport，比引入通用 test framework 更容易定位、审阅和删除。

我实际执行并读回了以下验证：

• 相关 Python 组：142 passed in 7.53s；
• native TS settlement/readback：58 passed，无 skip；
• focused Ruff、npm run typecheck:control-plane、git diff --check、docs governance、semantic drift smoke 全部通过；
• semantic drift 仍报告 F1/F2 7/26 与 19 个未验证 cross-runtime entries，没有被本 PR 偷偷“结案”；
• exact head 的 DCO、dependency review、build、兼容性、分片测试、correctness、pytest 和 merge-gate 均成功，只有预期的 deploy/publish/presentation job 跳过。

剩余合并风险不是代码 blocker，而是该分支当前 BEHIND：如果 rebase/update 产生新 head，需要对新 exact head 重新确认差异和结论。

我的整体评价

APPROVE。 这不是用更多 fixture 假装拥有 producer，而是执行现有 owner、明确 decoder admission 的证据等级、保留未证明事项，并用跨 runtime 的失败闭合路径防止未来再次混淆。范围对 Stage 2a 是完整且可回滚的 evidence increment；未发现需要阻塞当前 exact head 的问题。

English verdict: APPROVE - Exact head 834d487 executes the existing settlement and readback owners, keeps decoder admission distinct from production evidence, preserves unresolved source gaps, and passes focused Python/TypeScript, static, semantic-drift, documentation, and required CI validation.

The merge-base changed after approval.

[huangruiteng]

动机

我按 exact head 834d48758d5bce47b9e173647723f9a3c799ee37 重新从当前 origin/main 的实际差异审阅了这次 Stage 2a 证据增量。当前主干差异只有 4 个新增文件（两份双语 ledger、一个 19 行 Node witness、一个 550 行 architecture test），不包含 PR 历史里已经落入主干的 Lark/chat 文件。

这批改动解决的是一个真实而细微的证据边界：“decoder 接受某个 typed value”不等于“产品存在会产生该 value 的 branch”。如果这两类证据混在一起，cancelled、permission_denied 等值会被过早判定为 production-complete，后续语义收敛和兼容决策都会建立在错误前提上。PR 把这个边界做成了可执行证据，同时明确不改变 runtime、registry 或 F1/F2 enrollment，目标和边界一致。

改动思路

实现没有复制 settlement 规则，而是让一个极薄的跨进程 witness 直接调用现有 TypeScript owner：reduceTurnSettlementTransaction 与 readQuotaSettlement。Python architecture test 再用同一输入对照 direct TS、managed effect bridge 和 Python decoder/readback consumer，从而区分三类事实：

1. 真实 owner 在因果输入下实际产出的 receipt/failure/phase；
2. 外部 envelope 能否被 TS/Python decoder 接纳或拒绝；
3. 历史兼容 consumer 仍能消费、但当前 builder 不再生产的状态。

这个分层是对的：TypeScript 继续拥有 reducer/readback 决策权，Python 只适配和消费；测试没有在 Python 中重建第二套状态机。ledger 也保留了未证明边界：synthetic receipt files 不是 durable writer 证据，cancelled 仍没有已识别 producer，permission_denied 的 task-lease producer 没有在本批执行，F1/F2 仍是 7/26。

具体改动

关键代码讲解

• scripts/settlement_receipt_source_witness.mts:9 的 operation switch 只允许 turn 和 readback，分别调用既有 TS owner；未知 operation 直接失败。它只做 stdin/stdout transport，没有新增状态、fallback 或 provider side effect。
• tests/architecture/test_settlement_receipt_source_boundaries.py:146 用 invalid identity、缺 receipt、effect mismatch、provider/budget/terminal refusal 等因果输入驱动真实 reducer，并要求 direct TS 与 managed bridge 完全一致、失败时没有 provider effects、Python decoder 保留 exact typed failure。
• tests/architecture/test_settlement_receipt_source_boundaries.py:183 对已提交 transaction 安装 fail-fast provider/checkpoint callbacks，证明 replay 只重建 validation/writeback/spend/terminal receipts，不会重复执行 durable effect。
• tests/architecture/test_settlement_receipt_source_boundaries.py:392 用隔离的临时 receipt 文件驱动真实 TS/Python readback，覆盖 open -> settlement_pending -> settled、重复读、exact monitor commit、legacy effect id 与 identity mismatch；wrong effect 时不会先投影 phase。

文件职责也清楚：Node 文件只跨 runtime 调 owner；Python 文件覆盖 direct/bridge/consumer 的一条完整来源链；双语 ledger 记录已证明事实、未证明事实和下一步，未把测试输出升级成新的 production contract。

正向路径上，完整 transaction 产生同一 effect id 的 typed receipts，completion + durable writeback + spend 投影为 settled，exact monitor commit 投影为 monitor settled；direct TS、managed bridge 和 Python consumer 一致。负向路径上，unknown/null/numeric typed values 被两端拒绝，prepared+unknown outcome 不能误判成 retry/success，identity mismatch 不投影 phase，provider refusal 保留对应 failure kind。

对主干的风险

本 PR 不改 production module，因此运行时回归面较低；主要风险是测试本身给出过强结论，或大体量 smoke 与已有 owner 单测重复。这里的控制是充分的：

• ledger 明确把 admission、production、compatibility 分开，并逐项写出未覆盖的 durable writer、全部 caller、完整 replan、live CLI/backend 与 F6 历史兼容；
• 550 行虽然大，但它覆盖的是无法由单一 owner 单测替代的 TS owner → managed bridge → Python adapter/consumer 跨 runtime 链，且没有抽出新的语义 helper 或复制 business rule；
• typed values 仍来自现有 enum/schema，identity 与 phase 判断使用 exact typed/effect-id 规则，没有 substring denylist、prose-only classification、默认行为变更或新 authority surface；
• future-facing refactor 检查后，我没有建议再抽象一层：继续保持 19 行 witness 只做 transport，比引入通用 test framework 更容易定位、审阅和删除。

我实际执行并读回了以下验证：

• 相关 Python 组：142 passed in 7.53s；
• native TS settlement/readback：58 passed，无 skip；
• focused Ruff、npm run typecheck:control-plane、git diff --check、docs governance、semantic drift smoke 全部通过；
• semantic drift 仍报告 F1/F2 7/26 与 19 个未验证 cross-runtime entries，没有被本 PR 偷偷“结案”；
• exact head 的 DCO、dependency review、build、兼容性、分片测试、correctness、pytest 和 merge-gate 均成功，只有预期的 deploy/publish/presentation job 跳过。

剩余合并风险不是代码 blocker，而是该分支当前 BEHIND：如果 rebase/update 产生新 head，需要对新 exact head 重新确认差异和结论。

我的整体评价

APPROVE。 这不是用更多 fixture 假装拥有 producer，而是执行现有 owner、明确 decoder admission 的证据等级、保留未证明事项，并用跨 runtime 的失败闭合路径防止未来再次混淆。范围对 Stage 2a 是完整且可回滚的 evidence increment；未发现需要阻塞当前 exact head 的问题。

此前的 approval 因 main 推进而被仓库规则自动撤销。本次重新 fetch 到 09f10c4e37b89c6ed25f2f2354f89d641662e83c 后，我重新做了证据失效检查：精确 head 与 merge-base b28af169f271eb9997b07730c1f034d58cccb827 未变；主干自原证据基线以来只改动 tests/test_steward_team_plan_apply.py，没有触及 settlement/readback owner、bridge、decoder、ledger 或本 PR 的四个独有文件；当前三方 merge tree 3530e9162448c05d9e1df7139ee087e65c2b3303 无冲突，git diff --check 通过。因此复用的 142 Python、58 TypeScript 与静态证据仍有相同前提，本条 review 是当前基线上的重新确认。

English verdict: APPROVE - Exact head 834d487 executes the existing settlement and readback owners, keeps decoder admission distinct from production evidence, preserves unresolved source gaps, and passes focused Python/TypeScript, static, semantic-drift, documentation, and required CI validation.

The merge-base changed after approval.

[huangruiteng]

动机

我按 exact head 834d48758d5bce47b9e173647723f9a3c799ee37 重新从当前 origin/main 的实际差异审阅了这次 Stage 2a 证据增量。当前主干差异只有 4 个新增文件（两份双语 ledger、一个 19 行 Node witness、一个 550 行 architecture test），不包含 PR 历史里已经落入主干的 Lark/chat 文件。

这批改动解决的是一个真实而细微的证据边界：“decoder 接受某个 typed value”不等于“产品存在会产生该 value 的 branch”。如果这两类证据混在一起，cancelled、permission_denied 等值会被过早判定为 production-complete，后续语义收敛和兼容决策都会建立在错误前提上。PR 把这个边界做成了可执行证据，同时明确不改变 runtime、registry 或 F1/F2 enrollment，目标和边界一致。

改动思路

实现没有复制 settlement 规则，而是让一个极薄的跨进程 witness 直接调用现有 TypeScript owner：reduceTurnSettlementTransaction 与 readQuotaSettlement。Python architecture test 再用同一输入对照 direct TS、managed effect bridge 和 Python decoder/readback consumer，从而区分三类事实：

1. 真实 owner 在因果输入下实际产出的 receipt/failure/phase；
2. 外部 envelope 能否被 TS/Python decoder 接纳或拒绝；
3. 历史兼容 consumer 仍能消费、但当前 builder 不再生产的状态。

这个分层是对的：TypeScript 继续拥有 reducer/readback 决策权，Python 只适配和消费；测试没有在 Python 中重建第二套状态机。ledger 也保留了未证明边界：synthetic receipt files 不是 durable writer 证据，cancelled 仍没有已识别 producer，permission_denied 的 task-lease producer 没有在本批执行，F1/F2 仍是 7/26。

具体改动

关键代码讲解

• scripts/settlement_receipt_source_witness.mts:9 的 operation switch 只允许 turn 和 readback，分别调用既有 TS owner；未知 operation 直接失败。它只做 stdin/stdout transport，没有新增状态、fallback 或 provider side effect。
• tests/architecture/test_settlement_receipt_source_boundaries.py:146 用 invalid identity、缺 receipt、effect mismatch、provider/budget/terminal refusal 等因果输入驱动真实 reducer，并要求 direct TS 与 managed bridge 完全一致、失败时没有 provider effects、Python decoder 保留 exact typed failure。
• tests/architecture/test_settlement_receipt_source_boundaries.py:183 对已提交 transaction 安装 fail-fast provider/checkpoint callbacks，证明 replay 只重建 validation/writeback/spend/terminal receipts，不会重复执行 durable effect。
• tests/architecture/test_settlement_receipt_source_boundaries.py:392 用隔离的临时 receipt 文件驱动真实 TS/Python readback，覆盖 open -> settlement_pending -> settled、重复读、exact monitor commit、legacy effect id 与 identity mismatch；wrong effect 时不会先投影 phase。

文件职责也清楚：Node 文件只跨 runtime 调 owner；Python 文件覆盖 direct/bridge/consumer 的一条完整来源链；双语 ledger 记录已证明事实、未证明事实和下一步，未把测试输出升级成新的 production contract。

正向路径上，完整 transaction 产生同一 effect id 的 typed receipts，completion + durable writeback + spend 投影为 settled，exact monitor commit 投影为 monitor settled；direct TS、managed bridge 和 Python consumer 一致。负向路径上，unknown/null/numeric typed values 被两端拒绝，prepared+unknown outcome 不能误判成 retry/success，identity mismatch 不投影 phase，provider refusal 保留对应 failure kind。

对主干的风险

本 PR 不改 production module，因此运行时回归面较低；主要风险是测试本身给出过强结论，或大体量 smoke 与已有 owner 单测重复。这里的控制是充分的：

• ledger 明确把 admission、production、compatibility 分开，并逐项写出未覆盖的 durable writer、全部 caller、完整 replan、live CLI/backend 与 F6 历史兼容；
• 550 行虽然大，但它覆盖的是无法由单一 owner 单测替代的 TS owner → managed bridge → Python adapter/consumer 跨 runtime 链，且没有抽出新的语义 helper 或复制 business rule；
• typed values 仍来自现有 enum/schema，identity 与 phase 判断使用 exact typed/effect-id 规则，没有 substring denylist、prose-only classification、默认行为变更或新 authority surface；
• future-facing refactor 检查后，我没有建议再抽象一层：继续保持 19 行 witness 只做 transport，比引入通用 test framework 更容易定位、审阅和删除。

我实际执行并读回了以下验证；其中 architecture suite、Ruff、control-plane typecheck 与 diff check 在本次 exact-head 复核中重新运行，其余既有证据经未变 head/main/merge-tree 的失效检查后继续有效：

• architecture suite 当前复跑：62 passed in 3.74s；同一 head 的相关 Python 组既有结果为 142 passed in 7.53s；
• native TS settlement/readback：58 passed，无 skip；
• focused Ruff、npm run typecheck:control-plane、git diff --check、docs governance、semantic drift smoke 全部通过；
• semantic drift 仍报告 F1/F2 7/26 与 19 个未验证 cross-runtime entries，没有被本 PR 偷偷“结案”；
• exact head 的 DCO、dependency review、build、兼容性、分片测试、correctness、pytest 和 merge-gate 均成功，只有预期的 deploy/publish/presentation job 跳过。

剩余合并风险不是代码 blocker，而是该分支当前 BEHIND：如果 rebase/update 产生新 head，需要对新 exact head 重新确认差异和结论。

我的整体评价

APPROVE。 这不是用更多 fixture 假装拥有 producer，而是执行现有 owner、明确 decoder admission 的证据等级、保留未证明事项，并用跨 runtime 的失败闭合路径防止未来再次混淆。范围对 Stage 2a 是完整且可回滚的 evidence increment；未发现需要阻塞当前 exact head 的问题。

此前的 approval 因 main 推进而被仓库规则自动撤销。本次重新 fetch 到 09f10c4e37b89c6ed25f2f2354f89d641662e83c 后，我重新做了证据失效检查：精确 head 与 merge-base b28af169f271eb9997b07730c1f034d58cccb827 未变；主干自原证据基线以来只改动 tests/test_steward_team_plan_apply.py，没有触及 settlement/readback owner、bridge、decoder、ledger 或本 PR 的四个独有文件；当前三方 merge tree 3530e9162448c05d9e1df7139ee087e65c2b3303 无冲突，git diff --check 通过。因此复用的 142 Python、58 TypeScript 与静态证据仍有相同前提，本条 review 是当前基线上的重新确认。

English verdict: APPROVE - Exact head 834d487 executes the existing settlement and readback owners, keeps decoder admission distinct from production evidence, preserves unresolved source gaps, and passes focused Python/TypeScript, static, semantic-drift, documentation, and required CI validation.

The merge-base changed after approval.

[huangruiteng]

动机

我按 exact head 834d48758d5bce47b9e173647723f9a3c799ee37 重新从当前 origin/main 的实际差异审阅了这次 Stage 2a 证据增量。当前主干差异只有 4 个新增文件（两份双语 ledger、一个 19 行 Node witness、一个 550 行 architecture test），不包含 PR 历史里已经落入主干的 Lark/chat 文件。

这批改动解决的是一个真实而细微的证据边界：“decoder 接受某个 typed value”不等于“产品存在会产生该 value 的 branch”。如果这两类证据混在一起，cancelled、permission_denied 等值会被过早判定为 production-complete，后续语义收敛和兼容决策都会建立在错误前提上。PR 把这个边界做成了可执行证据，同时明确不改变 runtime、registry 或 F1/F2 enrollment，目标和边界一致。

改动思路

实现没有复制 settlement 规则，而是让一个极薄的跨进程 witness 直接调用现有 TypeScript owner：reduceTurnSettlementTransaction 与 readQuotaSettlement。Python architecture test 再用同一输入对照 direct TS、managed effect bridge 和 Python decoder/readback consumer，从而区分三类事实：

1. 真实 owner 在因果输入下实际产出的 receipt/failure/phase；
2. 外部 envelope 能否被 TS/Python decoder 接纳或拒绝；
3. 历史兼容 consumer 仍能消费、但当前 builder 不再生产的状态。

这个分层是对的：TypeScript 继续拥有 reducer/readback 决策权，Python 只适配和消费；测试没有在 Python 中重建第二套状态机。ledger 也保留了未证明边界：synthetic receipt files 不是 durable writer 证据，cancelled 仍没有已识别 producer，permission_denied 的 task-lease producer 没有在本批执行，F1/F2 仍是 7/26。

具体改动

关键代码讲解

• scripts/settlement_receipt_source_witness.mts:9 的 operation switch 只允许 turn 和 readback，分别调用既有 TS owner；未知 operation 直接失败。它只做 stdin/stdout transport，没有新增状态、fallback 或 provider side effect。
• tests/architecture/test_settlement_receipt_source_boundaries.py:146 用 invalid identity、缺 receipt、effect mismatch、provider/budget/terminal refusal 等因果输入驱动真实 reducer，并要求 direct TS 与 managed bridge 完全一致、失败时没有 provider effects、Python decoder 保留 exact typed failure。
• tests/architecture/test_settlement_receipt_source_boundaries.py:183 对已提交 transaction 安装 fail-fast provider/checkpoint callbacks，证明 replay 只重建 validation/writeback/spend/terminal receipts，不会重复执行 durable effect。
• tests/architecture/test_settlement_receipt_source_boundaries.py:392 用隔离的临时 receipt 文件驱动真实 TS/Python readback，覆盖 open -> settlement_pending -> settled、重复读、exact monitor commit、legacy effect id 与 identity mismatch；wrong effect 时不会先投影 phase。

文件职责也清楚：Node 文件只跨 runtime 调 owner；Python 文件覆盖 direct/bridge/consumer 的一条完整来源链；双语 ledger 记录已证明事实、未证明事实和下一步，未把测试输出升级成新的 production contract。

正向路径上，完整 transaction 产生同一 effect id 的 typed receipts，completion + durable writeback + spend 投影为 settled，exact monitor commit 投影为 monitor settled；direct TS、managed bridge 和 Python consumer 一致。负向路径上，unknown/null/numeric typed values 被两端拒绝，prepared+unknown outcome 不能误判成 retry/success，identity mismatch 不投影 phase，provider refusal 保留对应 failure kind。

对主干的风险

本 PR 不改 production module，因此运行时回归面较低；主要风险是测试本身给出过强结论，或大体量 smoke 与已有 owner 单测重复。这里的控制是充分的：

• ledger 明确把 admission、production、compatibility 分开，并逐项写出未覆盖的 durable writer、全部 caller、完整 replan、live CLI/backend 与 F6 历史兼容；
• 550 行虽然大，但它覆盖的是无法由单一 owner 单测替代的 TS owner → managed bridge → Python adapter/consumer 跨 runtime 链，且没有抽出新的语义 helper 或复制 business rule；
• typed values 仍来自现有 enum/schema，identity 与 phase 判断使用 exact typed/effect-id 规则，没有 substring denylist、prose-only classification、默认行为变更或新 authority surface；
• future-facing refactor 检查后，我没有建议再抽象一层：继续保持 19 行 witness 只做 transport，比引入通用 test framework 更容易定位、审阅和删除。

我实际执行并读回了以下验证；本轮不读取、轮询或等待远端 CI，结论只依赖 repository-native local evidence：

• settlement/readback 相关 Python 组当前复跑：142 passed in 7.83s；
• native TS settlement/readback 的同一 exact-head 既有结果为 58 passed，且 head 与相关 owner/bridge/decoder 均未变化；
• focused Ruff、npm run typecheck:control-plane、git diff --check、docs governance、semantic drift smoke 全部通过；
• semantic drift 仍报告 F1/F2 7/26 与 19 个未验证 cross-runtime entries，没有被本 PR 偷偷“结案”；
• 基于最新 origin/main 的 merge tree a7b4ff2bbd54de53008cabc28a9bcf076fe055ce 无冲突；主干自上次审阅以来没有修改 settlement/readback owner、bridge、decoder 或本 PR 的四个独有文件。

剩余合并风险不是代码 blocker，而是该分支当前 BEHIND：如果 rebase/update 产生新 head，需要对新 exact head 重新确认差异和结论。

我的整体评价

APPROVE。 这不是用更多 fixture 假装拥有 producer，而是执行现有 owner、明确 decoder admission 的证据等级、保留未证明事项，并用跨 runtime 的失败闭合路径防止未来再次混淆。范围对 Stage 2a 是完整且可回滚的 evidence increment；未发现需要阻塞当前 exact head 的问题。

此前的 approval 因基线推进而被仓库规则撤销。本次重新 fetch 到 6c2976f8c3447a4bd1d3af79e251c2f78c9ed733 后，我重新做了证据失效检查：精确 head 与 merge-base b28af169f271eb9997b07730c1f034d58cccb827 未变；主干新增改动与本 PR 文件无交集，当前 merge tree 无冲突，git diff --check 通过。因此同一 head 的 58 项 native TS 证据仍有相同前提，而 142 项 Python 与静态/治理检查已经在本轮重新执行。

English verdict: APPROVE - Exact head 834d487 executes the existing settlement and readback owners, keeps decoder admission distinct from production evidence, preserves unresolved source gaps, and passes focused Python/TypeScript, static, semantic-drift, documentation, and current-main merge validation.

The merge-base changed after approval.

[huangruiteng]

Exact head: 834d48758d5bce47b9e173647723f9a3c799ee37

动机

这个 PR 为 #4447 Stage 2a 提供可执行的 source-boundary 证据：此前 settlement step/failure 与 receipt replay/monitor 的值虽有文档，但“生产分支实际产生”“外部 envelope 仅能被 decoder 接受”“历史兼容输入”容易被混为一谈。该增量的价值是把当前真相做成可复验的证据，而不是宣称整条链路已经完备。

改动思路

19 行 Node witness 只把 JSON 转发给现有 TypeScript 权威 owner：reduceTurnSettlementTransaction 或 readQuotaSettlement。Python 架构测试用同一输入比较 direct TS 结果与既有 bridge/readback，另用临时事件/运行文件验证 phase 投影。生产规则没有复制到 witness；producer、decoder-only admission、compatibility consumer 分开验证。

正向路径覆盖 committed replay 构造 receipts 且不再次 dispatch provider；负向路径覆盖 identity/receipt mismatch、provider refusal、budget refusal、prepared unknown、未知 enum 与错误 effect，确保“能 decode”不会被误写成“有真实 producer”。

具体改动

相对当前 main 的真实合并增量是 4 个文件、664 additions：双语 ledger 95 行、witness 19 行、架构测试 550 行；没有生产 runtime 代码变化。

关键代码讲解

• scripts/settlement_receipt_source_witness.mts:1：只接受 turn / readback 两个操作并调用 shipped owners；未知操作 fail fast，不定义 vocabulary 或分类规则。
• tests/architecture/test_settlement_receipt_source_boundaries.py:55：用因果 transaction 输入驱动真实 reducer，逐一验证 failure producer，并与 Python bridge 对齐。
• tests/architecture/test_settlement_receipt_source_boundaries.py:237：从 synthetic durable facts 运行真实 readback；exact effect mismatch 在 phase 投影前失败，monitor/replay compatibility 维持显式边界。

对主干的风险

最大风险不是 runtime 回归，而是证据过度外推：临时文件通过不等于 durable writer 已证明，decoder 接受 permission_denied / cancelled 也不等于生产分支会产生它们。代码注释、测试命名和双语 ledger 均明确保留这些缺口；F1/F2 仍为 7/26。

我在 exact head 与当前 origin/main 的无冲突 merge tree 上执行：

• 新架构模块：62 passed
• 六组相邻 settlement/effect/readback suites：147 passed
• Ruff: passed
• git diff --check: passed

未轮询远端 CI（capability 的 wait_for_ci=false）。未验证 durable writer、live CLI/backend、完整 replan transaction、all callers 或 F6；这些是明确的后续边界，不是本 evidence slice 的虚假完成声明。

语义与 CI 对齐

该 PR 复用现有 typed vocabulary，没有创建或扩展 production semantic registry；external input 与 compatibility-only 项保持分类，不通过测试文件存在就自动 enrollment。

我的整体评价

没有 blocking finding。550 行测试不算小，但它围绕四组相互关联 vocabulary 的一个可执行证据矩阵，production mechanism 成本为零，且 witness 保持极薄；比复制 reducer 或仅写文档更符合权威边界。残余风险和未完成 producer/writer 证据均已清楚披露。

English verdict: APPROVE

The merge-base changed after approval.

[huangruiteng]

Exact head: 834d48758d5bce47b9e173647723f9a3c799ee37

Approval conclusion (independent maintainer review; the formal APPROVE on this exact head was immediately auto-dismissed because its merge-base changed, so this COMMENTED record preserves the reviewed conclusion without pretending merge readiness).

动机

这个 PR 为 #4447 Stage 2a 提供可执行的 source-boundary 证据：此前 settlement step/failure 与 receipt replay/monitor 的值虽有文档，但“生产分支实际产生”“外部 envelope 仅能被 decoder 接受”“历史兼容输入”容易被混为一谈。该增量的价值是把当前真相做成可复验的证据，而不是宣称整条链路已经完备。

改动思路

19 行 Node witness 只把 JSON 转发给现有 TypeScript 权威 owner：reduceTurnSettlementTransaction 或 readQuotaSettlement。Python 架构测试用同一输入比较 direct TS 结果与既有 bridge/readback，另用临时事件/运行文件验证 phase 投影。生产规则没有复制到 witness；producer、decoder-only admission、compatibility consumer 分开验证。

正向路径覆盖 committed replay 构造 receipts 且不再次 dispatch provider；负向路径覆盖 identity/receipt mismatch、provider refusal、budget refusal、prepared unknown、未知 enum 与错误 effect，确保“能 decode”不会被误写成“有真实 producer”。

具体改动

相对当前 main 的真实合并增量是 4 个文件、664 additions：双语 ledger 95 行、witness 19 行、架构测试 550 行；没有生产 runtime 代码变化。

关键代码讲解

• scripts/settlement_receipt_source_witness.mts:1：只接受 turn / readback 两个操作并调用 shipped owners；未知操作 fail fast，不定义 vocabulary 或分类规则。
• tests/architecture/test_settlement_receipt_source_boundaries.py:55：用因果 transaction 输入驱动真实 reducer，逐一验证 failure producer，并与 Python bridge 对齐。
• tests/architecture/test_settlement_receipt_source_boundaries.py:237：从 synthetic durable facts 运行真实 readback；exact effect mismatch 在 phase 投影前失败，monitor/replay compatibility 维持显式边界。

对主干的风险

最大风险不是 runtime 回归，而是证据过度外推：临时文件通过不等于 durable writer 已证明，decoder 接受 permission_denied / cancelled 也不等于生产分支会产生它们。代码注释、测试命名和双语 ledger 均明确保留这些缺口；F1/F2 仍为 7/26。

我在 exact head 与当前 origin/main 的无冲突 merge tree 上执行：

• 新架构模块：62 passed
• 六组相邻 settlement/effect/readback suites：147 passed
• Ruff: passed
• git diff --check: passed

未轮询远端 CI（capability 的 wait_for_ci=false）。未验证 durable writer、live CLI/backend、完整 replan transaction、all callers 或 F6；这些是明确的后续边界，不是本 evidence slice 的虚假完成声明。

语义与 CI 对齐

该 PR 复用现有 typed vocabulary，没有创建或扩展 production semantic registry；external input 与 compatibility-only 项保持分类，不通过测试文件存在就自动 enrollment。

我的整体评价

没有 blocking finding。550 行测试不算小，但它围绕四组相互关联 vocabulary 的一个可执行证据矩阵，production mechanism 成本为零，且 witness 保持极薄；比复制 reducer 或仅写文档更符合权威边界。残余风险和未完成 producer/writer 证据均已清楚披露。

English verdict: APPROVE