feat(lark): add human-confirmed Goal Channel operations

[cocolord]

摘要 / Summary

• 将原先的通用 frozen payload + User Todo 审批台账，重构为 RFC 定义的 canonical operation.execute envelope；Core 只拥有有界状态、摘要、唯一 claim、outcome 与 receipt，不解释金融语义。
• Refactor the former generic frozen-payload plus User Todo approval ledger into the RFC-aligned canonical operation.execute envelope. Core owns bounded state, digests, one claim, outcome, and receipts without interpreting finance.
• Lark Goal Channel 只投影同一 operation：非转发 Card 2.0、原 App/chat/message/card digest、操作者 allowlist 与 tenant membership 校验，并把结果写回原卡片。
• Lark Goal Channel projects the same operation as one non-forwardable Card 2.0, validates original App/chat/message/card digest plus operator allowlist and tenant membership, and writes the result back to that same card.
• 首个 finance consumer 是可选 M1 simulator；只接受 finance.operation.simulate、finance.order.simulate 和 account:simulation。
• The first finance consumer is an optional M1 simulator restricted to finance.operation.simulate, finance.order.simulate, and account:simulation.

动机 / Motivation

原 PR 已经把周期报告的 Goal Channel 发送/读回能力抽成共享 transport，但 frozen payload 又建立了第二套审批 authority。面向 capable-manager RFC，群消息只能是 canonical state 的投影和经认证的交互入口，不能成为另一份 Todo、审批台账或执行授权来源。本次重构保留贡献者已验证的共享 Goal Channel delivery，并删除平行 approval ledger。

The original PR usefully extracted periodic-report Goal Channel send/readback as shared transport, but its frozen-payload path created a second approval authority. Under the capable-manager RFC, a group message is a projection and authenticated interaction surface for canonical state, not another Todo, approval ledger, or execution-authority source. This revision retains the shared delivery work and removes the parallel authority.

端到端链路 / End-to-end flow

1. CLI goal-channel prepare-operation 通过 canonical Chat action service 校验并持久化 provider-neutral request；preview 使用临时 store，不产生 durable write。
2. goal-channel deliver-operation 解析当前 Goal Channel binding 和已启用 executor revision，发送一张安全投影卡片，并要求 native message readback 后才记录 delivery。
3. 独立 card.action.trigger consumer 校验 callback provenance；Core 原子完成 confirm/reject，confirm 同一事务生成唯一 claim。
4. 每 operation dispatch lock 防止并发 callback 重复执行；exact replay 复用现有 claim/outcome。
5. outcome 持久化后更新原卡，并对同一 App/chat/message/card digest 做 native readback；只有读回成功才记录 result_delivery。
6. 重启只可恢复明确无外部副作用的 M1 simulated claim；result-card patch 独立恢复且绝不重跑未来 live/effectful operation。
7. Dashboard 仅显示 public-safe projection、状态、expiry 与 result-delivery verification，不提供绕过群身份验证的本地 apply/reject/retry 控件。

用户入口 / User entry points

• CLI / managed Turn：prepare 和 deliver 使用同一个 source-runtime action store 与 Goal binding。
• Lark：同一消息内确认、拒绝、结果更新和准确 readback receipt；collector callback 与普通消息消费彼此独立。
• Dashboard：schema/readback 与安全 projection 已加入 source 和 packaged frontend。

安全边界 / Safety boundary

当前版本只能做 simulation。它没有 venue client、credential reader、signer、wallet、transfer、reservation 或 live-order permission；群内点击不会授予这些权限。真实交易必须在后续里程碑另行加入 reservation、ambiguous-outcome reconciliation、venue conformance 与显式 permission，不能复用 M1 restart retry。

This revision is simulation-only. It contains no venue client, credential reader, signer, wallet, transfer, reservation, or live-order permission, and a group click grants none of them. A future live milestone requires separate reservation, ambiguous-outcome reconciliation, venue conformance, and explicit permissions; it must not reuse M1 restart retry semantics.

验证 / Validation

• 563 passed at exact head 868fa9169：Core operation、finance simulator、Lark card/callback/replay/concurrency/restart recovery、collector routing/runtime、Goal Channel、periodic report、Miaoda、相邻控制面与 maintainability ratchet；其中包含 operation 不得借用未绑定 periodic target 的负向边界。
• Ruff format/check passed on all touched Python production and test files.
• Dashboard TypeScript check and both Vite builds passed; packaged frontend rebuilt.
• Development and packaged-browser acceptance passed for awaiting group confirmation, outcome recorded/result-card readback pending, and verified result states at 1512×982. Screenshots used synthetic data and were visually inspected; private payload/principal values and local mutation controls were absent.
• git diff --check passed.
• Repository static contract script still reports the pre-existing manager intent-phrase assertion at personal-workspace-contract.test.mjs:276; the same unrelated baseline issue is not counted as this feature passing.
• No live Lark message or real order was sent during validation. Real console callback delivery and one authenticated group click remain deployment qualification, not simulated evidence.

RFC / Scope

Aligned with the bilingual human-confirmed domain operations and capable-manager RFCs. Periodic reporting keeps its standing-subscription semantics while reusing the same delivery/readback transport. Domain-neutral Core, Lark provider logic, finance consumer logic, and Dashboard projection remain separate ownership layers.

[huangruiteng]

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

动机

该 PR 引入 Goal Channel frozen payload 的审批、冻结、路由、幂等和发送回读链路，并复用 periodic-report 的发送实现。

改动思路

整体边界清晰：调用方只提供经批准的 payload，LoopX 负责通用生命周期与 provider 目标约束，发送前冻结摘要并在回读时校验。

具体改动

关键代码讲解

• goal_channel_payload.py 承担冻结 payload、digest 和审批范围。
• goal_channel_message_delivery.py 承担 provider-neutral 的发送、幂等和回读。
• goal_channel_delivery_contract.py 固化生命周期结果。
• CLI 与 periodic-report 适配层复用同一发送路径。

对主干的风险

当前 required windows-powershell check 为 fail，而多个 stage2c/test-shard 仍在 pending；因此 Windows 兼容性和完整回归尚未形成可合并证据。请先定位该失败并在同一 head 上重跑，待 required checks 全部通过后再合并。

我的整体评价

REQUEST_CHANGES。该 PR 触及审批、权限边界、幂等和外部发送，不能以部分平台通过替代 required check。审阅 head：a8a67f5c773ab9679beaac4e1b93cafb9b42e808。

English verdict: REQUEST_CHANGES — head a8a67f5. Diagnose and rerun the failing windows-powershell check, then complete the pending required checks before merge.

[cocolord]

CI follow-up after the extension version bump:

• Fixed the affected Linux regression by making the periodic-report/Miaoda and Goal Channel activation fixtures read the bundled loopx-lark manifest version instead of duplicating a stale 1.6.0 literal.
• Focused suite: 87 passed.
• Standard premerge: passed (9 catalog canaries, 8 risk-profile smokes, compile/diff/public-boundary checks, 0 manual holds).
• The remaining native Windows failure is pre-existing on the exact PR base 18fda32f: upstream main run https://github.com/huangruiteng/loopx/actions/runs/34674379627 fails the same tests/test_windows_install.py::test_windows_installer_promotes_release_and_runs_doctor assertion because quota should-run returns status=skip / exit 1. This PR has no diff in the Windows installer, quota runtime, or that test. I am keeping that unrelated baseline repair out of this Goal Channel change.

The shared-mechanism boundary is intentional: periodic reports retain their subscription/two-announcement semantics, while periodic reports and approved frozen payloads now reuse one verified Goal Channel sender/readback implementation.

[huangruiteng]

更正：上一条评审发布时 PR head 在提交过程中从 a8a67f5c773ab9679beaac4e1b93cafb9b42e808 更新为当前 head 4638a1c71f1bf89001cacb3d7e8aca99e011f486；以下结论绑定当前 head。

当前 required windows-powershell check 为 fail，多个 stage2c/test-shard 仍 pending。请定位失败并在当前 head 上重跑，待 required checks 全部通过后再合并。

English verdict: REQUEST_CHANGES — corrected current head 4638a1c; diagnose the failing windows-powershell check and complete pending required checks.

[cocolord]

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

Reviewed exact head: 23448528e50c79f694379c0a8613a3a913ae248d

动机

这个 PR 解决的是跨 capability 的 Goal Channel 投递权限问题：内容生产方可以声明一张 public-safe 卡片，但不应自行选择聊天、Bot、解释用户批准或直接发送。此前 periodic report 已经有项目 Bot、历史去重和原生 readback 路径，其他 capability 却缺少一个可以冻结 exact payload、等待 exact user approval、再安全复用该传输路径的通用生命周期。新增能力的目标是把内容所有权、审批权和发送/核验权分开，并让中断后的重试保持可审计、fail-closed。

改动思路

实现以 owner-local frozen receipt 为核心：prepare-payload 先规范化 capability 提供的卡片，绑定 Goal、agent、payload digest 与当前 Goal Channel binding digest，然后创建 blocked delivery Todo 和精确的 user-gate Todo；deliver-payload 再回读 receipt 与两个 Todo，要求 approve outcome、scope、agent、successor 和当前 binding 全部一致。通过后才进入共享的 GoalChannelMessageDeliverySession，校验项目 Bot/chat，完整扫描历史寻找 exact card，必要时用稳定幂等键发送，并通过 provider-native message readback 校验 message/chat/sender/card 后完成 Todo。

复用边界处理得当：旧 periodic-report 私有 sender 被抽到共享模块，periodic subscription 的授权语义仍留在原 owner；generic payload 的用户审批生命周期独立存在，因为它不能从 standing subscription 推导。Finance 等 producer 仍负责领域语义、citation、redaction 和 public-safe attestation，LoopX 不重新判断内容。

具体改动

• 新增 frozen payload v0 协议、私有 receipt、prepare/deliver 两阶段 CLI 和文档。
• 新增 goal_channel_delivery_contract.py 统一验证 Goal、Lark chat、project Bot/profile，并生成 binding digest。
• 新增 goal_channel_message_delivery.py，集中实现 Bot/auth/chat/member 验证、完整历史 exact-card 去重、发送和 native readback。
• goal_channel_payload.py 将 receipt digest、approval Todo、delivery Todo、binding drift、执行/重试/完成串成一个 fail-closed 生命周期。
• periodic-report 改为复用共享 sender/readback，并在 hosted-report 卡片里加入经过 redact_public_text 的 typed next action；README 已披露这一内容变化。
• 扩充 Goal Channel、periodic report、Miaoda、CLI 和 target 测试。

关键代码讲解

1. goal_channel_payload.py:185 的 prepare_goal_channel_payload 把 normalized request、agent 和 binding digest 纳入 receipt identity；preview 不写入，execute 才写 0600 私有 receipt 并创建两个职责分离的 Todo。
2. goal_channel_payload.py:383 的 deliver_goal_channel_payload 在发送前重新验证 receipt 完整性、exact approval、successor、agent 和 binding digest，任一漂移都拒绝；只有 native readback 成功才结算 delivery。
3. goal_channel_message_delivery.py:290 的 send 复用 periodic transport owner，历史必须完整，且只有同 chat、同 project Bot、同 card 才算 dedupe；这使进程在 send 后中断的同版本重试不会重复写。
4. periodic_report_delivery.py:114 的 _next_action_guidance 只读取 primary typed next-action，并经 public redaction 后加入 hosted announcement；无 next action 时保留原正文。

对主干的风险

没有发现阻塞审批、冻结、路由、发送或 readback 的代码问题。负向测试覆盖错误 approval outcome/scope/agent/successor、receipt/card/binding drift、错误 Bot/chat、历史不完整、send 后中断、exact replay 和 native normalized readback；聚焦回归为 87 passed，compileall 与 git diff --check 通过。

有一项非阻塞 P2 兼容性建议：periodic hosted card 新增 next action 后，periodic_report_delivery.py:412 仍沿用旧的语义幂等键。如果旧版本已经发送、在 readback 前中断，随后升级重试，新卡片无法 exact-match 旧历史，而 provider 可能按同一 key 返回旧 message，导致新 readback 持续 unverified。该路径不会误判成功，也没有证据表明会重复或越权发送，影响只限跨版本在途报告；建议后续给 rendered announcement 语义版本化 key，或补明确迁移恢复路径及跨版本测试。

远端方面，exact head 有 25 项成功；windows-powershell 在 exact base 18fda32f... 的同一测试、同一断言已经失败，PR 未修改相关 installer/quota 路径，merge-gate 是其连带失败。因此这不是本 PR 引入的回归，但 required checks 仍为红色，当前 head 还不能合并，必须先修复/重跑基线检查至绿色。

我的整体评价

整体职责划分一致：producer 只提供内容，Todo 保存不可推导的用户意图，LoopX 冻结和校验授权，共享 sender 独占 provider 身份、去重和 readback。新增状态均有生产 caller，preview/disabled 路径无外部副作用，periodic 复用避免了第二套传输规则。对 exact head 的代码审查结论为 APPROVE；P2 的跨版本重试边界建议加固，但它是可观察、可恢复且 fail-closed 的残余风险。此 approval 不代表 merge-ready，合并仍须等待所有 required checks 通过。

English verdict: APPROVE exact head 23448528e50c79f694379c0a8613a3a913ae248d with one non-blocking P2 cross-version periodic retry hardening item. Focused validation passed (87 tests), and the Windows/merge-gate failure reproduces on exact base rather than this diff; nevertheless, the PR is not merge-ready until required checks are green.

[cocolord]

Addressed the non-blocking cross-version periodic retry finding in d5908c73a224424d3601eb6b3121466c081cb5d8:

• each periodic Goal Channel announcement now derives its provider idempotency identity from a versioned schema plus the delivery identity, announcement kind/title, rendered Markdown, and footer;
• an upgraded retry with changed rendered content no longer reuses the legacy provider key, while exact-message history dedupe still recovers unchanged companion announcements;
• tests cover content-bound keys, legacy-key collision recovery, exact interrupted-readback replay, and existing Bot/chat/readback boundaries;
• protocol and Lark extension docs disclose the new semantic identity; the commit now carries DCO sign-off.

Validation on the pushed head: 83 focused tests passed; Ruff, compileall, diff hygiene, and public-boundary checks passed. Standard premerge passed 17/18 selected checks. The sole failure, cli-output-budget-regression-smoke.py, reproduces with identical rows and deltas on the previous PR head 23448528e; under system Python it also fails identically because Python 3.9 cannot import the repository's dataclass(slots=True). This four-file follow-up does not touch those CLI surfaces.

Please review the new exact head. No live Goal Channel message was sent.

[cocolord]

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

本轮结论：APPROVE，当前提交未发现剩余阻塞性代码问题；上轮 P2 跨版本周报重试问题已修复并经反例验证。代码接受不等于现在可以合并：分支仍为 BEHIND，更新主干后必须对新的 exact head 重新验证。

Reviewed exact head: d5908c73a224424d3601eb6b3121466c081cb5d8
Baseline: 18fda32fda59e1ed1101c723eb3bfbc981b74bfd
Previous review head: 23448528e50c79f694379c0a8613a3a913ae248d
Review policy revision: 3

动机

既有 periodic-report 流程已经能够通过 Goal 绑定的项目 Bot 发送周报，但这份订阅权限不能被其它 capability 当作逐条公开内容的人工同意。新增通用 frozen payload 流程的价值，是让领域 capability 提供公开文案，LoopX 冻结确切内容与目标，再由现有 user gate 批准，最后复用统一发送和原生回读，而不是让每个 provider 再实现路由、批准和消息去重。

最小可行方案不是把任意 payload 塞进周报订阅，也不是增加另一个审批数据库：前者扩大权限，后者复制已有 Todo 真相。该 PR 采用一份不可变私有 receipt 加现有 user/agent Todo，抽出原有 provider transport 供两条路径使用。本轮从这个原始需求重新检查整个 PR 的规模与职责，未因上轮已 APPROVE 就继承结论；最后四文件修复只补足真实存在的旧消息/新渲染重试边界。

改动思路

显式 goal-channel prepare-payload 从正确 source registry/runtime 读取已安装 extension、Goal/agent binding 和 target，规范化 capability 提供的 public-safe card。仅在 --execute 时冻结 card/binding digest，创建 blocked agent delivery Todo 与绑定 exact scope、agent、successor 的 user gate。现有 todo complete --role user 记录批准，不能从安装、Bot 可用或 public_safe=true 推导同意。

deliver-payload 重新核对 receipt、Todo 决定、agent/successor、内容摘要及当前 binding，调用共享 GoalChannelMessageDeliverySession 做身份、目标、完整历史、精确内容去重和 provider-native readback。只有这些通过，才完成 delivery Todo 并把 receipt 写成 satisfied；receipt 的存在或 Todo 已完成都不能替代外部回读。领域含义仍由产生内容的 capability 负责，Core 不引入 Finance 专属规则。

周报保留原有 subscription authority、publication cursor 和两张有序公告，只复用 transport。新的 next-action 属于已披露的周报文案变化；最新修复把 provider retry key 绑定到版本、语义 key、公告 kind/title、最终 Markdown/footer。确切旧卡片仍通过完整历史复用，内容改变才获得新 key，无需新增迁移账本或手工状态。

具体改动

全 PR 为 19 文件、+1963/-421：新增 527 行 payload lifecycle、397 行共享 sender 与 73 行 route/binding contract，原 periodic delivery 和 presentation 删除重复 transport/route 实现；CLI、Goal Channel facade、provider 和 extension manifest 接通真实入口。协议索引、frozen-payload/periodic 协议、Lark 与 capability README 明确授权和重试语义；五个测试模块覆盖通用 payload、绑定/来源 runtime、周报消息和展示。

上次审查至当前 head 仅四文件 +178/-19，生产变化集中在 rendered-announcement key；generic payload、共享 sender、binding contract、CLI/provider、Todo owner 与依赖未变，已用 immutable diff 检查后复用其代码阅读证据，并重新运行整体回归及真实入口验证。

关键代码讲解

• loopx/extensions/lark/goal_channel_payload.py:185 prepare_goal_channel_payload：receipt ID 由请求、Goal、agent 和 binding 共同导出；预览不落库，execute 使用现有 Todo API 和私有 atomic writer，重复请求复用 exact receipt。
• loopx/extensions/lark/goal_channel_payload.py:383 deliver_goal_channel_payload：_approval_verified 要求明确 approve、正确 scope/agent/successor 与已解除约束的 delivery Todo；重新校验绑定后才允许 sender 工作，回读不符保持未完成。
• loopx/extensions/lark/goal_channel_message_delivery.py:290 GoalChannelMessageDeliverySession.send：统一两类 caller 的真实 Bot/chat/card 匹配、完整历史去重和 provider key 发送。历史不完整不能当作“没有发过”，错误身份不能发送；成功还需独立 readback。
• loopx/extensions/lark/periodic_report_delivery.py:151 _announcement_idempotency_key：新 key 是最终渲染材料的版本化哈希。旧实现只按语义报告 key 标识，会在升级后拿到旧 provider message；此处修复的是缓存语义，不是放宽回读。
• loopx/cli_commands/goal_channel.py:695 prepare/deliver 分支：真实 request-file/receipt 参数经过 extension/source registry 路由进入 lifecycle，默认 dry-run；本轮不是仅 mock 新 helper 的转发测试，而是运行实际 CLI main 和持久化 backend。

对主干的风险

重点反例是：旧版本已发送 hosted card、尚未完成回读，升级后 next-action 让卡片内容改变，但 provider 缓存仍把旧 key 映射到旧 message。本轮用会真实保存所收 card、并按 key 缓存 message 的合成 provider，经真实 periodic entrypoint、registry/binding/target 文件、Lark sink 和共享 session 执行 27 次 baseline/head/mutant 验证。刻意把新实现的 key 换回旧规则时，确实得到 readback_unverified、intent_satisfied=false 和空 publication cursor；当前实现只补发改变的 hosted card，复用不变的 Lark document，再次重试发送次数为零。没有 mock 一个 verified=true 来证明自己。

同一基线周报 fixture 的预览、发送、重放、150 条无关消息加逆序历史、不完整历史、身份漂移、非法 route override 和重叠非法输入均作了完整结果对照。没有隐藏语义字段：不含 next-action 的同内容请求，差异仅是有意版本化的两条 message idempotency_key 与新增 boundary flag；错误类型、完整诊断及拒绝优先级一致。预览文件快照无变化，不完整历史不发送，显示顺序和无关数量不改变精确去重。

另完成 8 项实际 installed CLI/lifecycle 检查：prepare 预览不改 Todo，execute 生成 gate/receipt，未批准和撤回批准不发送，真实 user completion 后可预览，provider readback 后单独读取 Todo 为 done、私有 receipt 为 satisfied，已完成 Todo 重放不重复发，150 个无关 Todo 不遮蔽 exact lookup。通用投递没有提升 public_safe 声明的权限。全部五个修改相关模块共 89 passed，diff check 通过；远端为 23 SUCCESS、4 个按工作流跳过，Windows 和 merge-gate 当前均已成功，不再沿用上轮红色基线判断。

剩余边界：Lark API 为合成 transport，未向真实群发送，也未在真实客户端做卡片视觉验收；权限/回读与重试行为已在 backend 验证。主干最近合并的 #4263 增加 periodic calendar handoff，尚不在该 PR head 内，与周报协议/测试有交集，所以当前 BEHIND 不能仅凭现有绿灯直接忽略；同步后的组合回归仍是合并前必需工作。

我的整体评价

当前 exact head 的完整设计、权限归属、复用和变更规模可以接受，原 P2 重试问题已经解除，未发现新阻塞性代码问题。通用入口默认不执行、没有确切批准就没有副作用；周报 next-action/key 是独立披露的既有路径变化，不把它误称为随 generic payload 一起关闭。

18 项结构化证据、35 次入口/后端执行回执已通过 revision-3 result consistency check，且发布前再次核对 head 不变。结论仅覆盖这里注明的 base/head，不覆盖尚未合入的主干变更，也不是 live Lark acceptance。当前账号是 PR 作者，因此发布 COMMENTED approval conclusion；合并前仍需 exact-head merge-readiness 为 true，并满足 GitHub 的保护要求，不能通过管理员操作绕过 BEHIND 或新提交复审。

English verdict: APPROVE at exact head d5908c7. The previous cross-version retry issue is fixed by rendered-content-bound idempotency; restoring the old key reproduces failed native readback, while the fix sends only the changed card and deduplicates replay. Validation: 89 focused tests, 27 baseline/head/mutation periodic executions, 8 real CLI/persistent-lifecycle cases, clean diff, and current CI including Windows and merge-gate passed (23 success, 4 intentional skips). No live Lark delivery claim. The branch is BEHIND upstream; update it and review/test the new exact head before merge.

[huangruiteng]

Request changes conclusion

动机

本 PR 新增 capability-owned frozen payload 的 Goal Channel 投递：producer 提供已声明 public-safe 的 Markdown，LoopX 冻结 card 与 binding digest，创建精确 user gate 和 delivery Todo，批准后才使用项目 Bot 发送，并要求完整历史去重、provider-native sender/chat/content readback。它还把既有 periodic-report sender/readback 抽成共享实现，同时保持 periodic subscription 的独立 authority。

改动思路

prepare-payload 将 request、Goal、agent 和当前 Goal Channel binding 绑定进 owner-local receipt；deliver-payload 重新读取 receipt、两个 Todo、decision scope 和 binding，再调用 GoalChannelMessageDeliverySession 做 Bot/chat 验证、历史扫描、幂等发送和 native readback。preview、未批准、receipt/card drift、binding drift、历史不完整和 readback 不一致都 fail-closed。共享 transport 减少了 generic payload 与 periodic report 的重复 provider 规则，producer 仍负责领域语义、引用、redaction 和 public_safe=true attestation。

具体改动

• 新增 goal_channel_payload.py（527 行），串联 request schema、私有 receipt、精确审批 gate、delivery Todo、binding digest、重试和完成状态。
• 新增 goal_channel_delivery_contract.py 与 goal_channel_message_delivery.py，统一 Goal-bound project Bot route、完整历史 exact-card dedupe、provider idempotency 和 readback。
• CLI 增加 prepare-payload/deliver-payload，extension manifest 升级至 1.7.0；协议、Lark README 和测试披露 approval、authority、版本化 retry key 与无 live-send 的边界。
• periodic_report_delivery.py 改为复用共享 sender/readback，保留原订阅、双公告和 publication cursor 语义；共 17 个文件，+1963/-421。

关键代码讲解

1. goal_channel_payload.py:183 的 prepare_goal_channel_payload 规范化 card，生成覆盖 payload/binding/agent 的 receipt identity，并只在 execute 时写私有 receipt/Todos。
2. goal_channel_payload.py:323 的 _approval_verified 要求 exact approve、scope、agent、successor、delivery 状态和 capability binding ref 全部一致，任何不符都在 provider 调用前拒绝。
3. goal_channel_message_delivery.py:290 的 GoalChannelMessageDeliverySession.send 先核对当前 binding，再扫描完整 Bot-visible history，必要时使用稳定 provider idempotency key 发送。
4. periodic_report_delivery.py:392 通过同一 session 发送 periodic announcements，但 subscription authority 仍由 periodic owner 校验。

对主干的风险

当前精确 head d5908c73a224424d3601eb6b3121466c081cb5d8 的 89 个 focused extension tests 全部通过，compileall、Ruff、git diff --check 与 git merge-tree --write-tree origin/main HEAD 通过；远端 23 项检查成功、4 项按工作流跳过，0 failed/0 pending。未执行 live Lark 写入，provider 行为使用确定性 transport 验证。

发现一个 P1 authority/TOCTOU blocker：GoalChannelMessageDeliverySession.send 在第 293-294 行只执行一次 resolve_current_binding()，随后 _existing_message() 进行网络历史读取，最后第 303 行直接执行 +messages-send。如果 binding 在历史读取期间被 rebind/revoke，发送仍会使用旧的 route，因此违反协议“binding drift after preparation invalidates approval”以及“provider write 前 fail-closed”的承诺。这个问题可由合成 runner 复现：在 +chat-messages-list 回调中修改当前 binding，当前实现仍调用 +messages-send。现有 drift 测试只覆盖 send 入口前的变更，不能证明并发窗口安全。

请把 binding writer lock 与最终检查/写入串行化，或提供等价的不可被并发更新穿透的 compare-and-send 机制；在 +chat-messages-list 后发生 binding 变更时，必须断言 +messages-send 未被调用。另有一项输入一致性建议：prepare_goal_channel_payload 直接把原始 agent_id 写入 receipt，而 Todo API 会把大小写/空格归一化；例如 CODEX-PUBLIC-DELIVERY 会成功 prepare，但批准后 _approval_verified 比较 raw receipt 与 normalized Todo，最终永远报 lacks exact approval。应在计算 receipt 与创建 Todos 前统一 normalize 或明确拒绝非规范 id，并补充回归。

我的整体评价

整体生命周期和 provider 边界设计合理，shared sender 的提取也避免了 periodic 与 generic payload 的规则分叉；但 binding 竞态能够在撤销/重绑后仍产生旧路由的外部写入，属于权限边界而非普通重试瑕疵。当前 exact head 结论为 REQUEST_CHANGES。修复并发 binding 检查与 agent-id 归一化后，重新执行两条 delivery 路径的完整测试和远端检查，再复审。

English verdict: REQUEST_CHANGES — exact head d5908c7 has a P1 binding TOCTOU race: a rebind during history dedupe can still send through the stale route. Serialize the final check with the provider write, add a mutation-during-list regression, and normalize or reject non-canonical agent ids before approval state is persisted.

[cocolord]

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

Reviewed exact head: 7daa48eac5c54243f6c315283aef862f0cda0cb1
Baseline: 58dbaeaec9bfad537f5b8ad2b1def9b2dcbd5197
Review policy revision: 3

动机

本 PR 解决的是一个真实的 authority 空缺：capability 可以生成并声明 public-safe 的内容，但它不应因此自行选择群聊、Bot，或把“内容可公开”解释成“用户已同意发送”。主干原有 periodic-report 已具备项目 Bot 校验、完整历史去重、稳定 provider key 与原生 readback，但其 standing subscription 只授权周期报告，不能外推为任意 capability payload 的逐条同意。此前如果其他 producer 要投递，只能复制审批状态和 Lark transport，或者错误复用周报权限。

当前方案把三类权责分开：producer 负责领域事实、引用、脱敏和 public-safe 声明；用户 Todo 负责不可推导的 exact approval；Goal Channel binding/target 与共享 sender 负责目标、Bot、幂等和回读。最小替代方案——直接给现有 periodic sender 增加任意 payload 参数——会扩大订阅权限；另建一套 approval 数据库又会复制 Todo 真相。因此，一份 owner-local frozen receipt 加现有 Todo lifecycle，并抽取既有 sender，是能同时满足权限和崩溃恢复的最小边界。

改动思路

prepare-payload 先规范化 request 与 agent，解析当前 Goal-bound binding/target，把 Goal、capability、payload/card digest、decision scope、binding digest 和 agent 写入稳定 receipt identity。preview 只验证；execute 创建一个 blocked delivery Todo、一个只覆盖该 receipt/digest/scope 的 user gate，再原子写入私有 receipt。用户明确以 approve 完成 gate 后，deliver-payload 重新读取 receipt 和两个 Todo，验证 scope、agent、successor、delivery 状态及当前 binding 均未漂移，才进入 provider effect。

发送侧没有复制 periodic 规则，而是把原私有 sender 抽成 GoalChannelMessageDeliverySession。它校验项目 Bot、app、chat 与 membership，要求 provider 历史分页完整，只把同 chat、同 app、同 card 的消息视为 exact dedupe；不存在时才用稳定 key 发送，并通过独立的 native message readback 校验 message/chat/sender/card。最终只有 readback 成功才完成 delivery Todo 并把 receipt 置为 satisfied。periodic-report 保留自己的 subscription、pending intent 和 publication cursor，只复用 transport；generic approval 与 periodic authority 没有混合。

上轮发现的 P1 竞态也按 authority owner 修复：发送侧按 binding→target 的固定顺序持有与 writer 相同的锁，在远端历史扫描后、任何 dedupe 接受或发送前再次解析当前 binding。所有生产 binding 变更入口都由 serialize_goal_binding_mutation 包住，goal_topic_edit 的恢复写发生在外层连接事务锁内；target 只有一个加锁 mutation 入口。这样 revoke/rebind 不会穿过 provider round trip 继续使用旧 route。

具体改动

全 PR 的 exact base..head diff 为 20 个文件、+2145/-444：其中生产 Python 约 +1217/-430，测试 +814/-9，文档 +111/-2，manifest +3/-3。生产删除主要来自移除 periodic 私有 sender/presentation 重复实现，不是额外叠加第二套 transport。新模块都有真实调用路径：CLI/provider/extension manifest 接入 generic lifecycle，existing periodic caller 接入共享 sender。

关键代码讲解

1. loopx/extensions/lark/goal_channel_payload.py:188 的 prepare_goal_channel_payload：用 canonical agent、normalized request 与 binding digest 生成稳定 receipt id；preview 无持久化，execute 复用现有 Todo API 和私有 atomic JSON writer。Todo 文本和 receipt identity 稳定，所以中途失败可幂等补齐，而不会生成第二组 authority。
2. loopx/extensions/lark/goal_channel_payload.py:389 的 deliver_goal_channel_payload：_read_receipt 与 _approval_verified 校验 schema、card digest、approve outcome、scope、agent、successor 与 capability binding ref；随后重新验证 binding，调用共享 sender。provider readback 不通过时不完成 Todo，也不把 receipt 误写成 satisfied。
3. loopx/extensions/lark/goal_channel_message_delivery.py:296 的 GoalChannelMessageDeliverySession.send：binding/target 锁覆盖 current-binding check、完整历史扫描、扫描后重验和 provider send。上轮反例在 history callback 中修改 binding 时旧实现仍会发送；当前 head 在 +messages-send 前失败，target mutation 同样被拦截。
4. loopx/extensions/lark/periodic_report_delivery.py:367 的 deliver_periodic_report_to_goal_channel：保留原周期报告 authority 和两条公告顺序，改用共享 session。hosted card 新增经过 public redaction 的 typed next action；_announcement_idempotency_key 绑定最终渲染内容版本，避免升级后用旧 key 命中旧 message 并持续 readback unverified。
5. loopx/extensions/lark/goal_channel_delivery_contract.py:16 的 goal_channel_delivery_route：集中限定 enabled Lark binding、chat、project_bot identity、profile/app/name/CLI 等路由字段，使 generic 与 periodic sender 使用同一 provider authority contract。

状态模型保持单一来源：用户 consent 是 Todo 的 irreducible intent；receipt 是 exact request/binding 的 authoritative frozen fact；delivery satisfied 是 native readback 派生的 projection。安装 extension、发现 CLI、Bot 可用或 public_safe=true 都不会激活发送。协议命名也与实际 actor lifecycle 对齐：registered agent 请求、用户批准一项 public-claim action、project Bot 执行 effect，没有把它描述成 peer-agent 或更宽的协调权限。

对主干的风险

最强风险仍是“批准后 authority 在远端历史查询期间被撤销，却向旧群发送”。本轮不仅阅读锁结构，还追踪了所有 production binding/target writer；binding writer 与 sender 的锁顺序一致，target mutation 使用同一文件锁。回归在真实 session 和持久 binding/target 文件上，从 +chat-messages-list 回调注入 mutation，确认当前 head 抛错且没有 +messages-send。这比只在 send 入口前改 binding 的旧测试更能区分缺陷。

另检查了 prepare 的多步持久化窗口。第二个 Todo 创建失败时可能暂时留下 blocked delivery Todo；两个 Todo 完成后 receipt 写入失败时可能暂时留下一对不可投递 Todo。但 delivery 必须先成功读取 exact receipt，故这些状态不能越权发送。用真实 Todo backend 分别注入 gate persistence failure 与 receipt persistence failure，再以同一请求重试，两种情况均复用同一个 receipt id、delivery Todo id 和 approval Todo id，最终只有一组 Todo 并进入 approval_pending。因此这是可恢复、fail-closed 的窗口，不是隐式批准或不可恢复 orphan。

验证结果：Goal Channel/periodic 聚焦测试 93 passed；最新主干 Todo/heartbeat/config 交集 179 passed；quota 新增交集 44 passed；此前完整仓库为 8144 passed、33 skipped、1 warning、106 subtests passed。exact-diff premerge 选择并执行 18/18 项，0 failure、0 warning、0 hold；compile、CI Ruff 范围、changed-file Ruff、git diff --check 与 public/private boundary 均通过。跨版本 periodic mutant 可复现旧 key 的 readback_unverified，当前实现只发送变化的 hosted card且 replay 零发送。

残余边界是没有向真实 Lark 群发送，也没有真实客户端视觉验收；transport 测试覆盖真实命令形状、持久状态、调用顺序、sender/chat/card 与 readback，但不把合成 provider 当 live acceptance。发布本评审时，exact head 的 DCO、dependency review、Windows、dashboard、静态检查、兼容性、release/build 和 Stage 2C mutants/installed 已绿，测试分片与部分 Stage 2C 仍在运行。因此本结论只表示代码可接受，不代表当前已 merge-ready。

我的整体评价

APPROVE。当前 exact head 未发现剩余阻塞性代码问题。设计在 repository owner 上保持一致：Todo 保存用户意图，binding/target 保存路由 authority，producer 保存领域语义，共享 sender 独占 provider 校验、dedupe、effect 和 readback；periodic 与 generic 共享 transport 但不共享 consent。上轮 P1 stale-route 竞态和 agent-id 不一致已修复，新增锁没有引入 writer 顺序分叉；partial prepare 也经失败注入证明为幂等可恢复且 fail-closed。

revision-3 的 18 项结构化证据已通过 pr-review --check-result，approval_consistent=true，发布前重新读取远端 head 仍为 7daa48eac5c54243f6c315283aef862f0cda0cb1。由于当前账号是 PR 作者，GitHub 不允许 formal self-approval，所以用 COMMENTED review 记录同等 approval conclusion。最终合并仍必须等所有 required checks 完成，并对这个不变 head 运行 merge-readiness；不使用 admin bypass。

English verdict: APPROVE exact head 7daa48eac5c54243f6c315283aef862f0cda0cb1. The stale-route TOCTOU and agent-id consistency blockers are fixed: delivery now shares writer locks, revalidates authority after remote history, and mutation regressions prove no send occurs. Focused validation is 93 passed, main-intersection suites are 179 + 44 passed, prior full suite is 8144 passed, and exact-diff premerge is 18/18 with zero failures, warnings, or holds. Mid-prepare failure injection also proves idempotent fail-closed recovery. No live Lark acceptance is claimed; merge must wait for all required checks and exact-head merge-readiness.

[cocolord]

@huangruiteng 上轮 P1（history scan 期间 rebind/revoke 仍可能走旧 route）及 agent-id 归一化问题已在 exact head 7daa48eac5c54243f6c315283aef862f0cda0cb1 修复，并补了 mutation-during-history 回归。revision-3 全量评审结论为 APPROVE：#4275 (review) 。当前远端 27/27 checks 成功，loopx pr-review --check-merge-readiness 4275@7daa48eac... 返回 ready=true。现在唯一阻塞是旧 head 上的 formal CHANGES_REQUESTED；当前账号无权 dismiss、发起 reviewer request 或启用 auto-merge。请复审/解除旧 review 后按普通保护规则合并；未使用 admin bypass。

[huangruiteng]

动机

本 PR 解决的是“由能力提交一份最终的公共内容，并在真正发往 Goal Channel 前让 owner 审批精确版本”的完整链路问题。此前，Goal Channel 发送、周期报告发送、重复发送防护、Bot 身份验证和 provider-native readback 分散在不同路径中，重试时容易出现语义漂移或重复卡片。当前实现把冻结 payload、私有 receipt、审批 Todo、发送 Todo 和 provider 侧幂等/readback 串成一个可观察流程，目标是让外部写入只有在 owner 批准且读回证明成功时才算完成。这个问题的影响面包括 payload producer、周期报告自动投递以及审批这些动作的 owner；若只增加一个 send helper 而不统一状态和 authority 边界，仍会留下第二套规则。

改动思路

入口是 Goal Channel payload 的 prepare/deliver CLI，以及周期报告的 deliver_periodic_report_to_goal_channel。payload 侧先规范化 capability id、payload ref、Markdown、footer 和 public_claim:action scope，计算 canonical card/binding digest，在 owner-local 的私有 receipt 中保存最终内容，并创建一个 blocked agent delivery Todo 与一个 user approval Todo。只有精确 scope 被批准、delivery Todo 可执行、receipt 未漂移时，provider session 才会继续。新的 GoalChannelMessageDeliverySession 复用了现有 Goal Channel target/binding、文件锁、完整历史扫描、幂等发送和 sender/chat/card readback；周期报告 adapter 只保留报告生成、announcement 渲染和 publication cursor 责任。正向路径的边界很清楚：owner 决定 exact receipt，Lark extension 决定 provider identity/effect/readback，公共状态只暴露 opaque ids/digests/status。需要解决的是周期报告解析器的一个反向路径：它在没有 durable Goal Channel binding 时合成 binding 并从 machine route 继续发送，这与本 PR 同时新增的 binding-only/fail-closed 协议文字不一致。

具体改动

关键代码讲解

• loopx/extensions/lark/goal_channel_payload.py:188 的 prepare_goal_channel_payload 负责冻结规范化 payload，写入私有 receipt，并建立审批/执行 Todo；重复调用通过 receipt identity 复用，不重新创建外部效果。
• loopx/extensions/lark/goal_channel_message_delivery.py:186-365 的 GoalChannelMessageDeliverySession 统一了 route verification、锁内完整 history scan、provider idempotency、发送和 native readback，既被 payload path 使用，也被周期报告 adapter 使用。
• loopx/extensions/lark/periodic_report_delivery.py:367 的 deliver_periodic_report_to_goal_channel 将两个有序 announcement 独立幂等发送，并只有在两个消息均完成 readback 后才推进 publication cursor。
• 同文件 _resolved_goal_channel_binding（约 189-254 行）在 binding_for_goal(...) is None 时创建 raw binding，使用 machine subscription 的 route_ref 和 target registry 继续解析；返回 boundary 又明确写出 goal_channel_binding_required=false 和 machine_default_route_allowed_when_unbound=true。这正是需要修正或重新定义的 authority 分支。
• CLI、extension activation 校验、private receipt schema、periodic-report idempotency key 以及对应协议/README/test 文件共同补齐了可操作性和回归覆盖；改动不是只改文档或 serializer。

对主干的风险

主要 blocker 是一个可达的权限/路由语义漂移。触发条件是：periodic_report 已启用且有 route_ref，target registry 中存在该 route，但 goal-channel.json 没有该 Goal 的 durable binding。此时 _resolved_goal_channel_binding 会把 machine target 组装成临时 binding，后续 session 仍可用 project Bot 发送。可是 docs/reference/protocols/goal-channel-frozen-payload-v0.md 第 24-26 行写的是“only from the durable Goal Channel binding”，docs/reference/protocols/periodic-report-v0.md 第 247-258 行也声明缺失 binding 必须 fail closed、没有 environment-default fallback。这样会让 operator 以为“未绑定不会发布”，而实际 route authority 来自 machine default；provider target 与 Goal-local approval/binding 的边界因此被绕开。

请二选一并保持代码、返回 boundary、测试和协议一致：默认修复是删除 synthetic binding、在缺失 binding 时返回 typed missing-binding blocker，并把 goal_channel_binding_required 设为 true、machine_default_route_allowed_when_unbound 设为 false；如果产品确实需要 machine route 作为周期报告的 standing subscription，则必须在 v0 协议中明确这是独立 authority、说明它如何替代 Goal binding，并把测试名称/结果从“binding-only”改成该新契约。现有测试全部通过并不能消除这个问题，因为 test_unbound_goal_uses_live_machine_default_shared_target 恰好把实现的宽松行为当成了 oracle。另一个剩余证据边界是本轮使用 deterministic runner，尚未做真实 Lark provider write/readback；这不是本次 request-changes 的根因，但合并前应保留为验证说明。

我的整体评价

共享 delivery session、冻结 receipt、精确审批和双 announcement 幂等化的方向是合理的，代码复用边界也比维护两套 provider effect 逻辑更好；我执行了相关 extension tests，结果为 76 passed，并执行 interaction-pattern-catalog smoke，结果为 ok。exact head 是 7daa48eac5c54243f6c315283aef862f0cda0cb1。不过，当前 head 同时发布了“绑定缺失即 fail closed”的公共契约和“无绑定时允许 machine default route”的真实路径，这属于 P1 authority/behavior drift，而不是可忽略的文档措辞。请先统一该语义并增加无 binding + 有 machine route 的 public-caller regression，再请求复审。

English verdict: REQUEST_CHANGES for 4275@7daa48eac5c54243f6c315283aef862f0cda0cb1. Periodic delivery synthesizes an unbound Goal Channel binding from the machine route while the new protocols promise durable-binding-only, fail-closed behavior. Focused tests pass (76), but this authority drift is a P1 blocker; align code, boundary flags, tests, and docs before merge.

[huangruiteng]

作者侧 exact-head 交付证据（非独立 APPROVE）

精确 head：59a90fffe0925a9bc6268df58a0668e43830564f

动机

这次不是给原来的 frozen payload 再补一层审批，而是把 #4275 收敛到 capable-manager RFC 的唯一 authority：Core 中的 canonical operation.execute。群卡只是这一状态的安全投影与经认证入口；点击不能创造另一份 Todo、审批台账或交易权限。首个 finance consumer 只做 M1 simulation，目的是先打通“Agent 准备精确请求 → 群内 owner 点击 → 唯一 claim → 结果回写原卡”的完整产品链路。

改动思路

ChatActionStore 持久化 provider-neutral operation envelope；CLI prepare/deliver 复用当前 Goal binding；GoalChannelMessageDeliverySession 统一 Bot/chat/card digest、幂等发送和 native readback；独立 card.action.trigger consumer 校验原 App/chat/message/card、tenant membership 与 operator allowlist，再原子生成唯一 claim。executor 与 Lark/Core 分层，当前可选 finance extension 只声明 finance.operation.simulate。Dashboard 只展示 public-safe projection，并明确区分“等待群确认 / outcome 已记录但结果卡待回读 / 结果已核验”。

具体改动

• deliver_goal_channel_operation_card：发送同一份不可转发 Card 2.0，并在持久化 delivery 前要求 exact native readback。
• handle_goal_channel_operation_callback：验证 callback provenance、expiry 与 principal，串行 dispatch；重复 callback 复用同一 claim/outcome。
• recover_goal_channel_simulation_claims 与 recover_goal_channel_operation_results：只恢复明确无外部副作用的 M1 simulation；结果卡 patch 独立恢复，未来 live/effectful operation 不自动重跑。
• _resolved_goal_channel_binding：周期报告保留独立 standing-subscription authority；无 Goal binding 时只能使用显式 periodic_report.route_ref 的 project-Bot target，且不创建 durable binding、不授权 operation。
• Personal Workspace：重启后恢复 terminal operation receipts，隐藏本地 apply/reject/regenerate，显示精确 result-delivery readback 状态；source 与 packaged frontend 同步。

对主干的风险

改动面较大（49 files，+5851/-840），主要剩余风险是尚未进行真实 Lark console callback + owner 点击的部署资格验证。当前实现没有 venue client、credential reader、signer、wallet、transfer、reservation 或 live-order permission，因此不能把模拟闭环解释为真实交易能力。

此前两个 REQUEST_CHANGES 已在当前架构中闭环：

1. d5908c7 的 binding TOCTOU 位于已删除的 frozen-payload 路径；共享 delivery session 现在使用 binding/target lock 与 provider write 前最终一致性检查，并有 mutation-during-history 回归。
2. 7daa48e 指出的 periodic authority 矛盾已在中英契约中明确：周期报告的显式 subscription 是独立 standing authority；operation 仍强制 durable Goal binding。新增负向测试证明“只有 registered target、没有 binding”时 operation 在任何 provider 调用前失败。

本地证据：497 条相关 Python 回归通过，Ruff、TypeScript/Vite、action-review parity、git diff --check 通过；开发版与 packaged browser 都覆盖三种 operation 状态，截图经目检，private payload/principal 与本地变更按钮均未出现。仓库静态契约脚本仍只命中最新 main 已有的 manager intent 文案断言，不计为本 PR 通过。当前远端 CI 正在完成最终批次。

我的整体评价

当前 head 已把原贡献中的共享 Lark transport 保留下来，同时删除了第二套 approval authority，并把 Core/Lark/finance/Dashboard 的责任边界按 RFC 分开。作者侧没有发现新的 blocking finding，但这是 public Core + Lark + optional finance 的大改动，不以自审替代独立结论；请基于该 exact head 重新 review，待 required checks 全绿后再决定合并。

[huangruiteng]

CI blocker fix on exact head 868fa91692cdbb026ad727812f6106456a2f60d7:

• The prior run's only direct failure was tests/canary/test_maintainability_ratchet.py::test_current_repository_debt_is_reviewed_without_line_count_pins: loopx/chat_actions.py had grown to 1,971 lines.
• The fix does not add or raise a debt exception. It moves the existing typed-action normalization method unchanged into ChatActionNormalizationMixin; semantic AST equality against the prior implementation was verified.
• Current module metrics: chat_actions.py 1,375 lines; chat_action_normalization.py 626 lines; maintainability ratchet is green.
• Local evidence after the refactor: changed PR tests + canary 119 passed; adjacent Chat/Goal activation coverage 49 passed; focused post-format regression 71 passed; Ruff check/format and git diff --check pass.
• Author and committer metadata remain the verified GitHub noreply identity.

A new CI run is in progress. This is author-side handoff evidence, not an independent approval; please bind rereview to this exact head after required checks complete.

[huangruiteng]

动机

本 PR 要解决的是一个明确的用户链路：赚钱 Agent 生成一份不可变的受保护操作请求，owner 在绑定的管家群里确认或拒绝，LoopX 只执行这一份请求一次，并把结果写回原卡与 Dashboard。原有 Goal Channel 已有周期报告发送与读回，但此前 revision 的 frozen payload + User Todo 又建立了一套审批 authority；它会让 consent、路由、重试和 receipt 在 Core 与 Lark 之间分叉。

我重新按原问题比较了三种方案：只增加 send helper 无法证明 callback provenance、唯一 claim 和结果读回；继续使用 User Todo 会保留第二份 consent 状态；把 finance 规则放进 Core 会污染通用能力。当前实现选择一份 canonical operation.execute 状态、复用 Goal Channel transport、把 Lark 认证和 finance payload 校验留在各自 adapter，是更小且能真正闭环的职责集合。

审阅精确 head：868fa91692cdbb026ad727812f6106456a2f60d7；base：201da973c603de7eb4d84b167bd5706819827fdf。

改动思路

权威状态只在 ChatActionStore：prepare 写入 provider-neutral request、payload/projection digest、expiry、authorized principals 与 executor revision；arm_operation 派生 awaiting-confirmation envelope。Lark delivery 只能从 durable Goal binding 解析 App/chat/route，复用共享 GoalChannelMessageDeliverySession 完整 history、dedupe、send 和 native readback。callback consumer 再核对原 App、chat、message、card digest、operator allowlist 与 tenant membership，随后由 Core 在同一锁事务中 confirm-and-claim。

dispatch 使用 per-operation lock；exact replay 复用已有 claim/outcome。结果先持久化到 Core，再 patch 原卡并做同 App/chat/message/card digest 读回；读回不确定时只恢复 result-card patch，不重跑 domain operation。唯一允许 restart 自动恢复的 claim 是同时满足 bundled M1 permission、finance simulation operation 和 account:simulation 的无外部副作用 consumer。未来 live/effectful adapter 明确需要 reservation、ambiguous-outcome reconciliation、venue conformance 和新 permission。

周期报告保留独立的 standing-subscription authority，只共享 transport，不向 operation.execute 外溢授权。Dashboard 读取同一 proposal，只显示 public-safe projection、expiry、lifecycle 与 result-delivery，隐藏本地 apply/reject/regenerate，避免把本机 API 调用伪装成人类群确认。

具体改动

• loopx/chat_action_store.py 新增 operation envelope、exact delivery、authenticated decision、single claim、outcome 和 result-delivery transition；状态、幂等与锁都在一个 owner。
• loopx/extensions/lark/goal_channel_operation.py 负责非转发 Card 2.0、durable binding、callback provenance、tenant membership、dispatch/recovery 和原卡结果读回。
• loopx/extensions/lark/goal_channel_message_delivery.py 抽取 periodic 与 operation 共用的 App/chat/route 校验、完整历史 dedupe、发送和 native readback；未绑定 operation 即使 registry 有 periodic target 也在任何 provider call 前失败。
• loopx/extensions/lark/event_collector*.py 在 operation_callbacks.enabled=true 时启动独立 card.action.trigger consumer，并把 listener health、callback evidence、simulation recovery 与 result-patch recovery 分开记录。
• packages/loopx-finance-execution 是可选 M1 consumer，只接受 finance.operation.simulate、finance.order.simulate、limit order 和 account:simulation；没有 venue、credential、signer、wallet、transfer 或 live-order path。
• CLI 增加 prepare-operation / deliver-operation；Dashboard source 与 packaged assets 增加 awaiting group confirmation、result delivery pending、result verified 三态。
• 删除旧 frozen-payload approval ledger 与对应协议/测试；周期报告文档明确 standing subscription 与 operation binding 的 authority 差异。
• CI 首轮暴露 chat_actions.py 1,971 行的 maintainability blocker。最终 head 没有提高阈值或加 exception，而是把原 595 行 normalization 原样迁到 ChatActionNormalizationMixin；AST 语义对比一致，模块降到 1,375 / 626 行。

正向 walkthrough 是：prepare → arm → deliver/readback → authenticated click → atomic claim → M1 simulation → outcome → original-card patch/readback → Dashboard reload。负向 walkthrough 覆盖 wrong/forwarded card、wrong App/chat/message/principal/tenant、expiry、executor drift、unbound Goal、concurrent/replayed callback、result readback failure 与 effectful restart；这些路径都在 provider send、claim 或 dispatch 前 fail closed，或者只恢复 presentation。

对主干的风险

最强风险是 broad diff：50 files，+6236/-1195，且 goal_channel_operation.py 本身较大。它同时触及 Core state、权限、Lark 外部写、collector、CLI、Dashboard 与可选 extension，拆成多个 PR 会更易审；但这里的 product rule 要求三个入口同源验收，拆开会留下不可部署的半链路或临时第二 authority。当前 diff 已把旧 approval path 删除，并用 default-off callback/extension 把 rollout 半径限制在显式配置的私有 owner 场景。

没有发现剩余 P0/P1 代码 finding。此前两个 authority blocker 已关闭：history scan 期间 rebind/revoke 会在共享锁内复核并阻止 send；periodic unbound route 被明确限定为其独立 standing subscription，operation 仍要求 durable binding，且有 zero-provider-call regression。最新 CI blocker（oversized chat_actions.py）也已用职责拆分修复而非豁免。

验证：exact head 的相关矩阵 563 passed；Ruff check/format、diff check、maintainability ratchet、两套 Dashboard build、Dashboard acceptance、Windows/macOS、四个 Python shards、Stage2C、pytest 和 merge-gate 全绿。浏览器三态证据来自上一 UI head；最终 commit 只移动两份 Python normalization 文件，当前 packaged build 重新通过，因此该 UI 证据的失效检查成立。

残余风险是尚未在合并后的 packaged runtime 收到一条真实 Lark card.action.trigger 并完成用户点击、simulator outcome、原卡 readback 与 Dashboard reload。它是部署验收，不是被 mock 冒充为已完成的代码证据；也绝不能被描述为 live trading authority。

我的整体评价

APPROVE。当前实现把 canonical state、Lark transport/authentication、finance semantics 和 Dashboard projection 分在正确 owner 下，删除了并行审批 authority；核心权限、typed state、default-off 与 retry 边界都有可达负例。虽然改动较大，但它对应一个必须跨入口原子交付的 M1 垂直切片，且生产 caller、安装路径、状态读回和维护性均有证据。

这是 owner exact-head review，不声称第三方独立评审，也不等于允许 admin bypass。合并仍应遵守仓库 merge policy；合并后必须升级本机并完成一次真实群卡点击闭环，才能关闭当前 P0 产品验收。

English verdict: APPROVE exact head 868fa91692cdbb026ad727812f6106456a2f60d7. The PR replaces the parallel frozen-payload/User-Todo approval path with one canonical operation lifecycle, reuses Goal Channel transport, keeps Lark authentication and finance simulation in bounded adapters, and closes the stale-route, unbound-periodic-authority, result-readback, and maintainability blockers. All required checks and a 563-test exact-head matrix pass. This owner review is not third-party independent approval; live Lark callback/click/readback remains post-merge deployment qualification and grants no live trading authority.

[huangruiteng]

@steven-kid @maxliux5 麻烦复审 #4275 的 exact head 868fa91692cdbb026ad727812f6106456a2f60d7。

当前状态：30/30 checks 全绿，相关矩阵 563 passed；owner exact-head review 已 APPROVE，但明确不替代第三方独立评审。此前 maintainability blocker 已通过拆分 typed-action normalization 解决，没有提高阈值或增加例外。

本 PR 是 Core operation envelope → Lark Card 2.0 authenticated callback/readback → 可选 finance simulation executor → Dashboard projection 的 M1 垂直切片。当前仅具备 account:simulation，无 venue、signer、wallet、transfer 或 live-order 权限。若 head 变化，我会重新跑 review/merge gate。

English: please review exact head 868fa91692cdbb026ad727812f6106456a2f60d7. All 30 checks and the 563-test related matrix pass. The owner review is intentionally not presented as independent approval; no admin bypass is requested.