fix(operations): allow admitted prepare with a registered source audience

[huangruiteng]

Motivation / 动机

Separate admitted preparation from execution, and freeze the registered return audience without confusing it with the original executor. Managed ambiguity used to silently persist a null audience; a prior repair also narrowed registry-accepted @/+ source tokens to the executor-ID grammar.

区分受管准备与执行，固定已登记的回传受众，不把来源会话误作执行者。修复多受众静默写入 null，以及有效来源 token 被执行者 ID 语法过滤的问题。

Implementation / 实现

• Existing TypeScript resolveOperationSourceRoute owns distinct candidate selection and ambiguity. Reuse original registry collect_accepted_bindings and resolve_thread_agent_binding facts; preserve accepted source tokens.
• Existing --codex-operation-tools owned native host carries one optional --codex-operation-source-route-json selector. Zero/one sources need no repeated operator decision; ambiguity requires explicit registered intent. The model cannot retarget it, change the native executor/profile, or manufacture approval.
• The actual opt-in native prompt permits admitted prepare before confirmation/consume. Prepare returns execution_allowed=false; domain effects still require the first approved atomic consumption.
• Ordinary simulator/attached/Codex CLI paths keep their previous contract, with no managed source-resolution RPC or new field requirement.
• EN/ZH RFC explicitly records this partial backend boundary and the existing continuation/source-return successor.
• Main integration includes already merged fix(turn): observe process-group termination before Host return #5382 actual process-group termination and Qualify explicit registry routing in Turn output budgets #5374 output-budget contract. Adopt already merged fix(control-plane): remove duplicate lease digest import #5391 duplicate-import correction; no new supervisor or budget relaxation here.

TS 保持单一操作决策 owner；Python 仅适配既有登记、CLI、原生进程及存储 IO。无新审批存储、身份凭证、平行 Python 决策源或交易权限。

Exact-head validation / 精确头验证

Head: e25f691e859f89c8e22a6ce2385ff2af0b4bf003; integrated main snapshot: 638d0e39cff09948df1816a4a5c5ccce70262c57.

• Final main sync only adopts fix(control-plane): remove duplicate lease digest import #5391's identical one-line import repair. Entire Git tree227d21abe0277093fd7ac606f09cbadd83a55be5 is identical to qualification head c7cfb57; the current complete review was restarted. The9native cases,18canonical-case oracle and typecheck were rerun at the final head. Reuse full same-source validation below, not a claim of a new full-suite run.
• Full TS: 3581 passed, 0 failed, 31 PostgreSQL environment skips; total3612.
• Focused source/host/process-group: 26 passed, including deliberately delayed KILL. Typecheck, Ruff and diff hygiene passed.
• Python operation/native/CLI: 99 passed, 2 explicit live-host skips. Original registry-owner tests: 37 passed.
• Nine formal registry-writer → owned native stdio → canonical File store separate readbacks passed. Deliberately restore the wrong audience grammar in an isolated same-head checkout: 6 fail, 3 controls pass; correct same9 tests all pass.
• Same synthetic public-entrypoint harness at immutable pre-change base 3156771e and final head: 18 cases, 8 ordinary observations exactly equal,256unrelated bindings and reordered sources do not widen authority. Selected recovery creates one replayable proposal with the original executor/profile; ambiguity and model retarget write nothing; unapproved consume rejects.
• Same-source c7 fixed-source risk premerge: 5/5 direct and19/19 selected passed, manual holds0. Final risk plan retains17same non-boundary checks and adds quota-plan (fresh pass);11file public boundary and directcompile/diff checks freshlypass. No priorunrun check is counted. Earlier14557>14500 result is retained as old-contract/provenance discrepancy, not relabeled passing. Immutable oldbase independently reproduces it; current main#5374 owner is14600 and finalhead module/source readback plus the original workload pass. No budget or fixture population changed in5378.
• Goal policy wait_for_ci=false: no remoteCI query/poll/wait.

Fixture/native transport is synthetic; actual TS and canonical File persistence/readback are real. These are not live model obedience, actual human callback, source sending or trade qualification.

以上验收固定最终源码和解释器；保留旧失败，不删诊断、不缩负载。2项live与31项PG跳过不冒充对应发布资格。

Product boundary / 产品边界

Affected entrypoints: CLI / managed native operation transport. This PR does not ship frontend or change the Lark transport. Companion frontend is separately scoped in #5394; confirmation continuation/recovery is in #5383. Original-audience verified return and the actual human-confirmed domain loop remain partial. Backend tests are not full product acceptance, no real card/operation was sent, and no global installation is claimed.

本 PR 只交付 CLI/受管原生准备和共享来源归一化。前端/Lark、自动续接、原受众真实回传及交易闭环按各自原 owner 验收，不用本次通过宣称父目标已完成。

Merge authority and rollback / 合并权限与回滚

The user's current request explicitly authorizes repair and self-merge of 5378 only, after exact-head review, local validation and ready=true. It does not authorize admin bypass, other Core PR merges, global adoption or financial effects. Omit the selector for the existing zero/single-source behavior; ambiguous preparation intentionally refuses. Revert this bounded slice if necessary; never rewrite existing immutable proposals/approvals.

用户本次授权仅覆盖5378。合并、安装、实际可用分别报告；没有admin bypass、自动交易或私人材料外发。回滚不修改历史卡片及批准。

[huangruiteng]

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

Reviewed head: 603a97645e27b41cf5cf3618c20159bcc61d5232; immutable base: 3156771e47268433c4b4b233bd37bdd3f2b37726.

动机

这是一段有价值的后台前置修复：已准入任务需要先生成不可变提案，才能获得针对该提案的确认；把准备也解释为“先消费再执行”会让流程停在入口。多个历史来源也需要表达宿主的返回受众选择。按现有 RFC 第十三节，本 PR 是可独立回滚的准备切片，不关闭确认、自动续接和原受众返回的完整交付。当前一个真实的登记契约回归阻止批准。

改动思路

CLI 将宿主选择传给已拥有的原生工具连接；Python 提供当前登记事实和存储，既有 TypeScript handoff owner 决定 managed 受众。返回受众只用于路由，执行主体仍是原 Todo、session、model 和 profile。提案准备保持 execution_allowed=false，领域副作用继续要求首次成功消费。最终版本把普通 prepare 排除在 managed resolver 外，删除过渡的 legacy 模式，这个收敛合理。提示修改与路由选择属于同一准备边界，无需新增审批库、执行者或唤醒框架。

具体改动

关键代码讲解

• resolveOperationSourceRoute 去重登记受众，自动选择唯一项，多项要求宿主选择，并校验选择归属。然而第 40–41 行把执行者的紧凑 ID 语法用于已登记来源，丢掉了登记 owner 合法接受的值；第 52 行也不能接受同一合法选择。
• ChatActionNormalizationMixin._normalize 只在 managed executor 上调用新 RPC；普通请求即使传入空 source selector 也拒绝。源选择进入既有 normalized parameters，随后进入原确认摘要，不改写已有提案。
• operation_tool_handler 固定宿主受众和执行身份，拒绝模型改投；歧义错误给出 CLI 修复入口。inspect、consume、report 仍交给原 canonical handoff owner。
• run_codex_operation_host 在实际发送的提示中区分读取、准备和领域执行，明确准备或等待不完成任务。CLI 注册、参数传递、effect handler、三组测试以及中英文 RFC 都属于本次完整审查；没有前端文件或 Lark transport 改动。

对主干的风险

[P2] 在计算受众数量前，应复用已登记来源的合法身份契约。 现有 bind_thread_agent_in_registry / normalize_thread_id 接受公开安全的 source@current，登记后 resolver 也返回 bound。在同一合成输入下，父版本原生 prepare 保存该唯一来源；本 head 却成功生成 source 为 null 的提案。再登记一条普通历史来源后，本 head 静默选择后者，没有报多来源歧义；显式选择已登记的 source@current 也返回 operation_admission_rejected。这不是未登记输入：探针通过实际登记 owner、原生 stdio 工具连接及规范存储独立读回，fake provider 只提交工具请求，不提供存储结果。尚未进行真实投递，因此结论是不可变返回元数据丢失或选择错误，并非已发生外部误投。

最小修复是让来源候选与显式 selector 复用 canonical 登记 token 契约，保留紧凑执行者 ID 的独立边界；不要过滤合法登记项后把“不完整候选集”当作零项或唯一项。补齐“唯一合法特殊字符来源、混合多来源、显式选中该来源”的 registry→native prepare→store readback 回归，并保留未登记、模型改投、profile 漂移和重复消费的负例。

语义与 CI 对齐

本变更应复用既有登记 vocabulary，没有理由创建更窄的返回身份契约。开发 advisory 未发现其支持语法中的新 vocabulary，完整语义 smoke 通过；这些静态结果不能证明登记与路由语义一致。49 项 Python、11 项聚焦 TS、类型检查、ruff 和 diff 检查通过，24 组同夹具 base/head 存储比较及原生探针已完成；普通合法请求保持原行为，ASCII 宿主选择、未批准拒绝、同提案重放和一次消费均成立。

全套 TS 为 3563 passed / 2 failed / 31 skipped：digest matcher census 在父版本有同一失败签名；另一个 descendant timeout 失败后，父版本与本 head 的独立 process suite 都是 9 passed，但失败原因仍未归清，不能称全套通过。Premerge 19 项中 18 项通过，crowded JSON 预算失败在父版本与本 head 均为 14557 > 14500，不要求本 PR 修改无关预算。31 项 PostgreSQL integration/conformance 因未配置独立数据库而跳过；本次未改 authority-store，不能声称这些路径已验收。两个 live-host release qualification 用例未启用；原生探针使用 fake provider，不证明真实模型愿意 prepare 或真实用户已确认。未查询、等待或轮询远端 CI。

我的整体评价

REQUEST_CHANGES。 整体切片、typed owner 与代码规模合理，普通路径隔离和一次消费边界有实测支持；后台前置修复不需要等待首屏展示，但也不代表完整产品已交付。合法登记来源被过滤会破坏后续持续推进与返回体验，宿主目前也无法用显式选择恢复，须先修复这个同域身份边界。边界收敛已应用，剩余最有价值的伴随整理是复用登记身份契约。确认后自动启动原 session、原 source 实际结果读回以及已安装消费者验收继续由同一 RFC 计划负责；PR #5304 的内部 Goal Chat 唤醒只是可复用候选。修复后需在新 exact head 重跑上述路由回归并清楚处理仍红的验证；合并由维护者决定。

English verdict: REQUEST_CHANGES — head 603a976 filters registry-valid source identities, losing a sole audience or silently selecting another under ambiguity; explicit selection also rejects that registered source. Reproduced through canonical registration, owned native stdio prepare and independent store readback. Focused Python 49 / TS 11, typecheck and lint pass; full-suite/premerge failures and live-provider limitations are disclosed. This is a backend prerequisite, not completed automatic wake or source delivery.

[huangruiteng]

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

Reviewed head: ecc62f3f28cbab18b8833d703375026dbee73f5e; immutable base: 3156771e47268433c4b4b233bd37bdd3f2b37726. Previous review: 603a97645e27b41cf5cf3618c20159bcc61d5232.

旧来源 P2 已修复；本轮 REQUEST_CHANGES 仅因新的完整本地验证未获归因，不能继承旧头结论，也不能称当前已全绿。

动机

受管操作必须先准备不可变提案，才能获得对该提案的确认；准备不应等待尚不存在的消费回执。多个历史来源也需要表达宿主当前希望返回的受众。本 PR 是既有 RFC 第十三节中的有用后台前置切片，可独立验证和回滚。它不关闭真实点击、原 session 自动唤醒、源会话实际结果返回或配套 UI 交付。

改动思路

本轮正确复用既有登记 owner 的身份语义：Python 提供已接受的绑定和规范化 selector，TypeScript 继续决定当前 Goal/Agent 的受众集合、歧义和选择归属。来源是被动返回地址，严格的 executor 身份仍是原 Todo、session、model 和 profile；准备只写规范提案，领域副作用仍需首次成功消费。普通 prepare 完全绕过 managed resolver。与仅改提示相比，宿主选择解决了不可推断的历史来源歧义；与新增审批库、认证令牌或唤醒框架相比，当前边界更小且职责清楚。

具体改动

关键代码讲解

• resolveOperationSourceRoute 不再用 executor 的窄 ID 正则过滤来源，而是消费登记 owner 已规范化的 token；零项保持 null，一项自动选择，多项必须显式选择，选择须属于同一 Goal/Agent。原执行者 id() 校验保持严格。
• ChatActionNormalizationMixin._normalize 复用 collect_accepted_bindings 与 resolve_thread_agent_binding，消除平行来源语法；不在 Python 重新决定受众数量或成员归属。普通请求，包括空 source selector，仍拒绝新增选择且不生成提案。
• operation_tool_handler 固定宿主受众，拒绝模型改投，并从原生连接绑定执行身份；未批准、重复消费和 profile 漂移继续拒绝。来源写入原确认摘要，不修改历史已确认提案。
• run_codex_operation_host 的实际提示区分读取、准备与领域执行，准备或等待不代表任务完成。完整差异也覆盖 CLI 参数传递、effect method、三组测试及中英文 RFC；没有前端或 Lark transport 文件。本轮 4 文件的修复和整个 11 文件 PR 分别审查，529 additions / 25 deletions 主要是可复用原生回归与双语边界说明。

对主干的风险

旧头“合法来源被过滤”的 P2 已独立验证修复：通过正式登记 writer、实际 owned native stdio prepare 和规范存储读回，唯一 source@current 被保留，混合来源明确报歧义，宿主显式选择成功。仓库的 @、+、: 九种组合全部通过。自己的同夹具 base/head 24 组比较、实际 managed host 三种路径以及 14 组补充检查验证了 128 字符来源、宿主 token、规范化 selector、绑定顺序/说明字段、100 条外部 Agent 来源、拒绝陌生来源/模型改投/额外 authority 字段，以及特殊来源上的一次消费和原结果报告；executor 的 @ model、Todo、session 仍拒绝且不落提案。六组普通旧请求观察与父版本一致。

[P2 / 验证缺口] 当前完整 TS 检查的 closed_pipes descendant cleanup 失败尚不能归为既有失败。 npm run test:control-plane 在本 head 得到 3564 passed / 2 failed / 31 skipped；进程已经返回后，host_process.test.ts:71 读到 counter 从 17 变为 18。这段监督实现和测试与父版本逐字相同，故这里不声称本 PR 引入了进程清理代码缺陷。父版本完整检查未出现同一 closed_pipes 失败；逐版本固定 12 次串行、16 个并发原测试及 64 次该模式检查的结果全部保留：父版本并发中复现了 timeout/abort 的相同清理断言，但触发模式不同，定向 closed_pipes 均通过。不能用其他模式或通过的重跑证明这一次 required failure 已获归因。

最小补齐是取得相同 closed_pipes 失败身份与细节的不可变父版本对照，或查清/修复其因果路径后重新验证 exact head 的所需检查。单独记录清理 owner 的问题，避免要求来源修复去修改无关控制面或靠调整阈值获得通过；当前缺口解决前保留审批。

语义与 CI 对齐

来源 vocabulary 复用已登记身份，未创建更宽执行者权限或新的共享 lifecycle。开发 advisory 未发现其支持语法中的新 vocabulary，完整 semantic smoke 通过，登记—准备—存储的真实边界比较也一致。95 项 Python、12 项聚焦 TS、类型检查、ruff 和 diff 检查通过。两个 live-host release 用例未启用，31 项 PostgreSQL 集成/一致性用例缺少独立服务而跳过；本次未改 authority-store，不声称它们已验收。Fake provider 提交实际工具请求，不伪造存储结果，但也不证明真实模型愿意 prepare 或真实用户已确认。

Premerge 5 项 direct 检查通过，18/19 项选中检查通过；唯一 crowded JSON 失败在父版本与本 head 都是 14557 > 14500。另一个 TS digest census 失败在两者均指向未登记的 task_lease_workspace.ts:26 matcher。两项已逐条归为无关既有失败，不要求本 PR修理它们。检查最新 main 时，#5374 已独立修正输出路由资格，#5372 清理 lease 旧参数，均未改本 PR 的来源/执行身份 owner。未查询、轮询或等待远端 CI。

我的整体评价

REQUEST_CHANGES，原因是尚未归因的完整本地检查失败；来源修复本身通过。 这段有界增量改善了持续推进和返回元数据的可用性，没有增加普通操作的确认步骤，保留原执行身份、一次消费与不可变历史。未来整理已在本轮完成：复用登记 owner、退掉窄来源语法和 legacy 分支，不新增框架；测试规模虽增长，但围绕实际登记与原生工具边界。后台切片不必等待首屏展示，也不能被提升为整个点击—唤醒—返回链路完成。补齐上述验证缺口后可在新的 exact-head 评审中决定批准；合并和后续 pinned 原消费者验收仍由维护者/既有实现 owner 负责，本轮不合并、不安装、不投递或执行真实操作。

English verdict: REQUEST_CHANGES — head ecc62f3 fixes the prior registered-source P2; canonical registry/native/store, ordinary-path and strict executor boundaries pass. Approval is held solely because the full TS closed_pipes post-return descendant-write failure has no matching immutable-base attribution; passing retries and failures under other modes are not that evidence. Python 95 / focused TS 12, typecheck and lint pass; unchanged digest/budget failures and optional live/PG limits are separately disclosed. No merge, installation or completed automatic wake/source delivery is claimed.

[huangruiteng]

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

评审对象：5378@c7cfb57eebe3f62061930d54b5475ad779d36972。结论：当前准备/来源选择这一交付片段无阻塞发现；这是可独立采用的后端增量，不是投研确认、执行和原渠道返回的完整闭环。用户本次明确授权修复和自合并本 PR；授权不涵盖 admin bypass 或其他 Core PR。

动机

依据 Human-confirmed operations RFC §13 判断：普通用户应先得到精确、可确认的请求，确认后由原执行者继续，结果再回原受众。旧准备提示把 consume 的先后条件写得像 prepare 的前置授权；多条历史来源会静默固化为 null。此前修复又误用执行者 ID 的紧凑语法，过滤原 registry 合法的 @/+ 来源 token。这些问题会制造重复询问或丢失返回受众，不能靠“已有一个 serializer”判定目标完成。

改动思路

复用原操作 store、确认 digest、原生 session/profile 和登记 owner，不新建身份、审批或消息权威。准备只创建不可变提案，execution_allowed=false 是正常回执；外部效果仍须真人确认后的第一次消费成功。Python 负责现有 registry/native/storage 适配，TS 的既有 work-item owner 负责候选去重、成员校验和歧义判断。零个来源保持历史 null 语义，一个来源自动选择，多个来源才让 operator 在受管 host 启动参数里选择已登记受众；这一步补充不可推导的意图，不让用户重填已知执行身份。模型不得改写 host 的选择，来源会话也不是执行者。

具体改动

关键代码讲解

1. operation_agent_handoff.ts:33 resolveOperationSourceRoute 接收原 owner 归一化的完整 Goal/Agent 绑定及可选两字段 selector。仅保留同一 Agent 候选并按完整受众去重；显式选择必须命中登记事实，多候选而缺选择抛 typed operation_source_route_ambiguous，不写入半成品。返回值由 normalization 固化进原提案。关键不是更严的正则，而是保留 registry 接受的词汇；执行者 ID 自身的规则不放宽。
2. chat_action_normalization.py:237–269 是生产入口：先检查已验证 executor 的 kind，普通 simulator/attached 路径仍拒绝 source_route 字段，包括 null，且不调用受管 resolver。受管路径通过 collect_accepted_bindings 和 resolve_thread_agent_binding 获取原 owner 的事实，再调用既有 effect runtime；不存在一套 Python 选择决策。存储、重复请求冲突和确认 digest 继续由原 service/store 管理。
3. codex_operation_host.py:156 operation_tool_handler 的 private closure 固定原 Goal、Agent、Todo、session 和 profile。真实 native thread/turn 先校验；prepare 注入 host-selected 来源，模型提供不同 selector/执行者即拒绝。之后调用 ChatActionService.preview 并返回 false，不提交、确认或消费订单。歧义只返回固定 operator 修复动作，其他拒绝不外泄原 payload。
4. codex_operation_host.py:361 run_codex_operation_host 在实际已 opt-in 的原生提示中区分准备与执行；CLI registration/turn dispatch 将唯一新可选参数送入同一 owned transport。没有 tools 选项时拒绝 selector，普通 Codex CLI 提示和启动路径不变。effect handler 只注册原 TS owner，不因注册或发现而激活能力。

其余改动是上述边界的 TS/真实 native stdio 回归和中英 RFC（明确 partial 及后续），以及同步主干后删除重复 BARE_SHA256_PATTERN import。完整差异为 12 文件 +529/-26；131 行文档、测试 +299/-3、生产 +99/-23。没有新 store、调度器、协议版本、包或 UI 事实源。兼容的是已有不可变卡片及普通/附着会话，不保留另一套旧请求决策；回滚不重写历史批准。

正向路径：两受众→operator 选择原登记来源→owned native prepare→当前 binding 校验→TS 成员判定→真实 File store→独立 load→重复准备同 ID/仅一提案。反向路径：缺选择→固定歧义与修复动作/零写入；模型 retarget→零写入；未经批准 consume→拒绝。相同输入在不可变基线 3156771e 与最终头执行，普通八种场景输出/错误完全相同；受管重复来源从 null 改为去重后的原来源，多来源从静默 null 改为可恢复拒绝。额外超展示上限的无关绑定和顺序变化也不授予其他 Agent 权限。

语义与 CI 对齐

复用 loopx_operation_request_v0、managed-turn-handoff-v0 及 registry 来源词汇，不新建平行语义。受管 prepare 的边界说明在 EN/ZH RFC、真实提示、CLI help 和固定拒绝动作中一致。提示是 guidance，当前绑定/成员/批准/一次消费是机器约束；注册、provider 可用或 CLI 参数存在均不是授权。规则对领域中立，不解释价格、账户或投资方向。本 Goal 的 wait_for_ci=false，没有查询、轮询或等待远端 CI。

对主干的风险

最高风险是有效来源被静默丢弃、来源误作执行身份、普通路径被附加受管准入，或进程未停止就返回。最终头的 9 个 formal registry writer→owned native stdio→独立 canonical store 读回回归全部通过，覆盖 @/+/: 各自 sole/mixed/explicit。对 isolated 同头仅将来源语法改回 executor-ID grammar，6 个 @/+ 反例失败、3 个冒号控制通过；因此不是只测新 helper 的自证。18 场景 canonical base/head 比较保留完整诊断和修复动作，不将错误文本或来源差异归一化掉。

全量 TS：3612 项，3581 通过、0 失败、31 PostgreSQL 环境条件跳过；typecheck 通过。source/host/process-group 聚焦 26 项全通过，含故意延迟 KILL 的真实进程组反例；主干 #5382 修复了“发信号不等于已停止”，本 PR 没有放宽 deadline。Python 操作/CLI 99 项通过、2 项显式 live-host 未启用；registry 37 项通过。Ruff、diff hygiene 与 public/private 边界通过。两项真人/付费模型和 31 项 PG 测试的跳过不证明对应发布资格；这里未改变存储 provider 的实现。

固定最终源码（PYTHONPATH 指向本 checkout）的风险预合并：5/5 direct、19/19 selected 全通过，manual holds=0，公共边界 12 文件零泄漏。保留首次旧口径的 14557>14500 失败：不可变旧基线315也明确重现，当前主干 #5374 的 budget owner 已为14600，最终头读回一致并通过原场景。首次结果的来源口径不一致不算同头验收；固定解释器、模块路径和源码后才使用当前整套回执。本 PR 没有修改预算、缩小 workload 或取消权威字段。

真实 TS/File store 与 synthetic owned stdio 已验证适配和权威边界，但 fake provider 不证明真人确认、live 模型遵循、自动同会话继续或实际原受众发送。要恢复该片段，用已有 CLI 来源选择重试准备；不得重发已发生/未知的领域效果。旧卡片仍只走自己的不可变条款、批准与消费回执。

我的整体评价

设计符合最小、有用、可回滚的边界：修复准备和来源语义，没有引入 Desktop impersonation 或第二审批系统；原 registry owner 复用比独立 ID 过滤更便宜也更正确。端到端产品状态仍为 partial：本 PR 变动的用户入口是 CLI/managed native transport；没有提交或打包前端/Lark companion，也没有本机全局安装回执。确认 wake/recovery 的 #5383 及原渠道返回、grant UI 应按各自原 owner 验收，不把这一 PR 的绿色测试算作金融最小闭环已完成。合并前还须检查远端 exact head、已处理评论和 capability 的 ready=true；不做 admin bypass。

English verdict: APPROVE - exact head c7cfb57. Original registry tokens are preserved, managed preparation freezes only a registered host-selected audience, and no execution authority is added. Full TS 3581 pass/31 PostgreSQL skips; focused native/storage and deliberate grammar mutation validate the boundary. This is a partial backend prerequisite, not live confirmation, source delivery or installation qualification.

[huangruiteng]

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

评审对象：5378@e25f691e859f89c8e22a6ce2385ff2af0b4bf003。结论：当前准备/来源选择这一交付片段无阻塞发现；这是可独立采用的后端增量，不是投研确认、执行和原渠道返回的完整闭环。用户本次明确授权修复和自合并本 PR；授权不涵盖 admin bypass 或其他 Core PR。

动机

依据 Human-confirmed operations RFC §13 判断：普通用户应先得到精确、可确认的请求，确认后由原执行者继续，结果再回原受众。旧准备提示把 consume 的先后条件写得像 prepare 的前置授权；多条历史来源会静默固化为 null。此前修复又误用执行者 ID 的紧凑语法，过滤原 registry 合法的 @/+ 来源 token。这些问题会制造重复询问或丢失返回受众，不能靠“已有一个 serializer”判定目标完成。

改动思路

复用原操作 store、确认 digest、原生 session/profile 和登记 owner，不新建身份、审批或消息权威。准备只创建不可变提案，execution_allowed=false 是正常回执；外部效果仍须真人确认后的第一次消费成功。Python 负责现有 registry/native/storage 适配，TS 的既有 work-item owner 负责候选去重、成员校验和歧义判断。零个来源保持历史 null 语义，一个来源自动选择，多个来源才让 operator 在受管 host 启动参数里选择已登记受众；这一步补充不可推导的意图，不让用户重填已知执行身份。模型不得改写 host 的选择，来源会话也不是执行者。

具体改动

关键代码讲解

1. operation_agent_handoff.ts:33 resolveOperationSourceRoute 接收原 owner 归一化的完整 Goal/Agent 绑定及可选两字段 selector。仅保留同一 Agent 候选并按完整受众去重；显式选择必须命中登记事实，多候选而缺选择抛 typed operation_source_route_ambiguous，不写入半成品。返回值由 normalization 固化进原提案。关键不是更严的正则，而是保留 registry 接受的词汇；执行者 ID 自身的规则不放宽。
2. chat_action_normalization.py:237–269 是生产入口：先检查已验证 executor 的 kind，普通 simulator/attached 路径仍拒绝 source_route 字段，包括 null，且不调用受管 resolver。受管路径通过 collect_accepted_bindings 和 resolve_thread_agent_binding 获取原 owner 的事实，再调用既有 effect runtime；不存在一套 Python 选择决策。存储、重复请求冲突和确认 digest 继续由原 service/store 管理。
3. codex_operation_host.py:156 operation_tool_handler 的 private closure 固定原 Goal、Agent、Todo、session 和 profile。真实 native thread/turn 先校验；prepare 注入 host-selected 来源，模型提供不同 selector/执行者即拒绝。之后调用 ChatActionService.preview 并返回 false，不提交、确认或消费订单。歧义只返回固定 operator 修复动作，其他拒绝不外泄原 payload。
4. codex_operation_host.py:361 run_codex_operation_host 在实际已 opt-in 的原生提示中区分准备与执行；CLI registration/turn dispatch 将唯一新可选参数送入同一 owned transport。没有 tools 选项时拒绝 selector，普通 Codex CLI 提示和启动路径不变。effect handler 只注册原 TS owner，不因注册或发现而激活能力。

其余改动是上述边界的 TS/真实 native stdio 回归和中英 RFC（明确 partial 及后续），以及采用主干已独立合并 #5391 的重复 BARE_SHA256_PATTERN import。完整差异为 11 文件 +529/-25；131 行文档、测试 +299/-3、生产 +99/-22。没有新 store、调度器、协议版本、包或 UI 事实源。兼容的是已有不可变卡片及普通/附着会话，不保留另一套旧请求决策；回滚不重写历史批准。

正向路径：两受众→operator 选择原登记来源→owned native prepare→当前 binding 校验→TS 成员判定→真实 File store→独立 load→重复准备同 ID/仅一提案。反向路径：缺选择→固定歧义与修复动作/零写入；模型 retarget→零写入；未经批准 consume→拒绝。相同输入在不可变基线 3156771e 与最终头执行，普通八种场景输出/错误完全相同；受管重复来源从 null 改为去重后的原来源，多来源从静默 null 改为可恢复拒绝。额外超展示上限的无关绑定和顺序变化也不授予其他 Agent 权限。

语义与 CI 对齐

复用 loopx_operation_request_v0、managed-turn-handoff-v0 及 registry 来源词汇，不新建平行语义。受管 prepare 的边界说明在 EN/ZH RFC、真实提示、CLI help 和固定拒绝动作中一致。提示是 guidance，当前绑定/成员/批准/一次消费是机器约束；注册、provider 可用或 CLI 参数存在均不是授权。规则对领域中立，不解释价格、账户或投资方向。本 Goal 的 wait_for_ci=false，没有查询、轮询或等待远端 CI。

对主干的风险

最高风险是有效来源被静默丢弃、来源误作执行身份、普通路径被附加受管准入，或进程未停止就返回。最终头的 9 个 formal registry writer→owned native stdio→独立 canonical store 读回回归全部通过，覆盖 @/+/: 各自 sole/mixed/explicit。对 isolated 同头仅将来源语法改回 executor-ID grammar，6 个 @/+ 反例失败、3 个冒号控制通过；因此不是只测新 helper 的自证。18 场景 canonical base/head 比较保留完整诊断和修复动作，不将错误文本或来源差异归一化掉。

最终 main 同步后的完整 Git 源码树为 227d21abe0277093fd7ac606f09cbadd83a55be5，与原资格头 c7cfb57 逐文件一致。重启新头评审并读取全差异，重新跑 9 项 native 回归（16.39 秒）、18 场景 canonical oracle 及 typecheck，通过后复用同源码、同 runtime/config 的完整测试和风险 premerge 回执；未把新 SHA 冒充全量重跑。新头计划保留原 17 项非 boundary 工作负载；移出已由 main 覆盖的 task-lease sample，新增 quota-plan smoke 已实际通过，11 文件 boundary scan 也重新通过。direct compile/diff hygiene 重跑通过，剩余共享脚本和依赖未变。

全量 TS：3612 项，3581 通过、0 失败、31 PostgreSQL 环境条件跳过；typecheck 通过。source/host/process-group 聚焦 26 项全通过，含故意延迟 KILL 的真实进程组反例；主干 #5382 修复了“发信号不等于已停止”，本 PR 没有放宽 deadline。Python 操作/CLI 99 项通过、2 项显式 live-host 未启用；registry 37 项通过。Ruff、diff hygiene 与 public/private 边界通过。两项真人/付费模型和 31 项 PG 测试的跳过不证明对应发布资格；这里未改变存储 provider 的实现。

固定最终源码（PYTHONPATH 指向本 checkout）的风险预合并：5/5 direct、19/19 selected 全通过，manual holds=0，公共边界原 12 文件零泄漏，最终差异为其 11 文件子集。保留首次旧口径的 14557>14500 失败：不可变旧基线315也明确重现，当前主干 #5374 的 budget owner 已为14600，最终头读回一致并通过原场景。首次结果的来源口径不一致不算同头验收；固定解释器、模块路径和源码后才使用当前整套回执。本 PR 没有修改预算、缩小 workload 或取消权威字段。

真实 TS/File store 与 synthetic owned stdio 已验证适配和权威边界，但 fake provider 不证明真人确认、live 模型遵循、自动同会话继续或实际原受众发送。要恢复该片段，用已有 CLI 来源选择重试准备；不得重发已发生/未知的领域效果。旧卡片仍只走自己的不可变条款、批准与消费回执。

我的整体评价

设计符合最小、有用、可回滚的边界：修复准备和来源语义，没有引入 Desktop impersonation 或第二审批系统；原 registry owner 复用比独立 ID 过滤更便宜也更正确。端到端产品状态仍为 partial：本 PR 变动的用户入口是 CLI/managed native transport；没有提交或打包前端/Lark companion，也没有本机全局安装回执。确认 wake/recovery 的 #5383 及原渠道返回、grant UI 应按各自原 owner 验收，不把这一 PR 的绿色测试算作金融最小闭环已完成。合并前还须检查远端 exact head、已处理评论和 capability 的 ready=true；不做 admin bypass。

English verdict: APPROVE - exact head e25f691. Original registry tokens are preserved, managed preparation freezes only a registered host-selected audience, and no execution authority is added. Full TS 3581 pass/31 PostgreSQL skips; focused native/storage and deliberate grammar mutation validate the boundary. This is a partial backend prerequisite, not live confirmation, source delivery or installation qualification.

[huangruiteng]

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

评审对象：5378@cf957678fcc2f2a3fb81def831f22a333a60e4ea。结论：当前准备/来源选择这一交付片段无阻塞发现；这是可独立采用的后端增量，不是投研确认、执行和原渠道返回的完整闭环。用户本次明确授权修复和自合并本 PR；授权不涵盖 admin bypass 或其他 Core PR。

动机

依据 Human-confirmed operations RFC §13 判断：普通用户应先得到精确、可确认的请求，确认后由原执行者继续，结果再回原受众。旧准备提示把 consume 的先后条件写得像 prepare 的前置授权；多条历史来源会静默固化为 null。此前修复又误用执行者 ID 的紧凑语法，过滤原 registry 合法的 @/+ 来源 token。这些问题会制造重复询问或丢失返回受众，不能靠“已有一个 serializer”判定目标完成。

改动思路

复用原操作 store、确认 digest、原生 session/profile 和登记 owner，不新建身份、审批或消息权威。准备只创建不可变提案，execution_allowed=false 是正常回执；外部效果仍须真人确认后的第一次消费成功。Python 负责现有 registry/native/storage 适配，TS 的既有 work-item owner 负责候选去重、成员校验和歧义判断。零个来源保持历史 null 语义，一个来源自动选择，多个来源才让 operator 在受管 host 启动参数里选择已登记受众；这一步补充不可推导的意图，不让用户重填已知执行身份。模型不得改写 host 的选择，来源会话也不是执行者。

具体改动

关键代码讲解

1. operation_agent_handoff.ts:33 resolveOperationSourceRoute 接收原 owner 归一化的完整 Goal/Agent 绑定及可选两字段 selector。仅保留同一 Agent 候选并按完整受众去重；显式选择必须命中登记事实，多候选而缺选择抛 typed operation_source_route_ambiguous，不写入半成品。返回值由 normalization 固化进原提案。关键不是更严的正则，而是保留 registry 接受的词汇；执行者 ID 自身的规则不放宽。
2. chat_action_normalization.py:237–269 是生产入口：先检查已验证 executor 的 kind，普通 simulator/attached 路径仍拒绝 source_route 字段，包括 null，且不调用受管 resolver。受管路径通过 collect_accepted_bindings 和 resolve_thread_agent_binding 获取原 owner 的事实，再调用既有 effect runtime；不存在一套 Python 选择决策。存储、重复请求冲突和确认 digest 继续由原 service/store 管理。
3. codex_operation_host.py:156 operation_tool_handler 的 private closure 固定原 Goal、Agent、Todo、session 和 profile。真实 native thread/turn 先校验；prepare 注入 host-selected 来源，模型提供不同 selector/执行者即拒绝。之后调用 ChatActionService.preview 并返回 false，不提交、确认或消费订单。歧义只返回固定 operator 修复动作，其他拒绝不外泄原 payload。
4. codex_operation_host.py:361 run_codex_operation_host 在实际已 opt-in 的原生提示中区分准备与执行；CLI registration/turn dispatch 将唯一新可选参数送入同一 owned transport。没有 tools 选项时拒绝 selector，普通 Codex CLI 提示和启动路径不变。effect handler 只注册原 TS owner，不因注册或发现而激活能力。

其余改动是上述边界的 TS/真实 native stdio 回归和中英 RFC（明确 partial 及后续）；主干已独立合并 #5391 的重复 BARE_SHA256_PATTERN import 修复也已采用，但不再属于本 PR 净差异。完整差异为 11 文件 +529/-25；131 行文档、测试 +299/-3、生产 +99/-22。没有新 store、调度器、协议版本、包或 UI 事实源。兼容的是已有不可变卡片及普通/附着会话，不保留另一套旧请求决策；回滚不重写历史批准。

正向路径：两受众→operator 选择原登记来源→owned native prepare→当前 binding 校验→TS 成员判定→真实 File store→独立 load→重复准备同 ID/仅一提案。反向路径：缺选择→固定歧义与修复动作/零写入；模型 retarget→零写入；未经批准 consume→拒绝。相同输入在不可变基线 3156771e 与最终头执行，普通八种场景输出/错误完全相同；受管重复来源从 null 改为去重后的原来源，多来源从静默 null 改为可恢复拒绝。额外超展示上限的无关绑定和顺序变化也不授予其他 Agent 权限。

语义与 CI 对齐

复用 loopx_operation_request_v0、managed-turn-handoff-v0 及 registry 来源词汇，不新建平行语义。受管 prepare 的边界说明在 EN/ZH RFC、真实提示、CLI help 和固定拒绝动作中一致。提示是 guidance，当前绑定/成员/批准/一次消费是机器约束；注册、provider 可用或 CLI 参数存在均不是授权。规则对领域中立，不解释价格、账户或投资方向。本 Goal 的 wait_for_ci=false，没有查询、轮询或等待远端 CI。

对主干的风险

最高风险是有效来源被静默丢弃、来源误作执行身份、普通路径被附加受管准入，或进程未停止就返回。最终头的 9 个 formal registry writer→owned native stdio→独立 canonical store 读回回归全部通过，覆盖 @/+/: 各自 sole/mixed/explicit。对 isolated 同头仅将来源语法改回 executor-ID grammar，6 个 @/+ 反例失败、3 个冒号控制通过；因此不是只测新 helper 的自证。18 场景 canonical base/head 比较保留完整诊断和修复动作，不将错误文本或来源差异归一化掉。

上一资格头 e25 在 main 同步后的完整 Git 源码树为 227d21abe0277093fd7ac606f09cbadd83a55be5，与原资格头 c7cfb57 逐文件一致。重启新头评审并读取全差异，重新跑 9 项 native 回归（16.39 秒）、18 场景 canonical oracle 及 typecheck，通过后复用同源码、同 runtime/config 的完整测试和风险 premerge 回执；未把新 SHA 冒充全量重跑。新头计划保留原 17 项非 boundary 工作负载；移出已由 main 覆盖的 task-lease sample，新增 quota-plan smoke 已实际通过，11 文件 boundary scan 也重新通过。direct compile/diff hygiene 重跑通过，剩余共享脚本和依赖未变。

本轮最终头 cf95767 同步主干 #5235/#5247 后，新增的 9 个路径仅是验收状态文档及 reliability diagnostics 的离线 retention 演练。已读取新增内容；本 PR 对 main 的 11 文件净差异与 e25 对旧 main 的差异逐字节一致，运行代码、测试、package/lock/TS 配置、相关 runner 和 AGENTS 均未变。新头重新跑 9 项 native 回归（5.61 秒）、18 场景 canonical oracle（结果 hash 与旧头一致）、control-plane typecheck、6 文件 compile 和 diff hygiene，全部通过。新风险计划的 19 个命令与上一头完全一致，没有用 preview 代替实际执行；复用上述未失效的实际整套回执。没有声称新头再次跑了全量 suite。

全量 TS：3612 项，3581 通过、0 失败、31 PostgreSQL 环境条件跳过；typecheck 通过。source/host/process-group 聚焦 26 项全通过，含故意延迟 KILL 的真实进程组反例；主干 #5382 修复了“发信号不等于已停止”，本 PR 没有放宽 deadline。Python 操作/CLI 99 项通过、2 项显式 live-host 未启用；registry 37 项通过。Ruff、diff hygiene 与 public/private 边界通过。两项真人/付费模型和 31 项 PG 测试的跳过不证明对应发布资格；这里未改变存储 provider 的实现。

固定最终源码（PYTHONPATH 指向本 checkout）的风险预合并：5/5 direct、19/19 selected 全通过，manual holds=0，公共边界原 12 文件零泄漏，最终差异为其 11 文件子集。保留首次旧口径的 14557>14500 失败：不可变旧基线315也明确重现，当前主干 #5374 的 budget owner 已为14600，最终头读回一致并通过原场景。首次结果的来源口径不一致不算同头验收；固定解释器、模块路径和源码后才使用当前整套回执。本 PR 没有修改预算、缩小 workload 或取消权威字段。

真实 TS/File store 与 synthetic owned stdio 已验证适配和权威边界，但 fake provider 不证明真人确认、live 模型遵循、自动同会话继续或实际原受众发送。要恢复该片段，用已有 CLI 来源选择重试准备；不得重发已发生/未知的领域效果。旧卡片仍只走自己的不可变条款、批准与消费回执。

我的整体评价

设计符合最小、有用、可回滚的边界：修复准备和来源语义，没有引入 Desktop impersonation 或第二审批系统；原 registry owner 复用比独立 ID 过滤更便宜也更正确。端到端产品状态仍为 partial：本 PR 变动的用户入口是 CLI/managed native transport；没有提交或打包前端/Lark companion，也没有本机全局安装回执。确认 wake/recovery 的 #5383 及另行提交的 UI #5394、原渠道返回、grant UI 应按各自原 owner 验收，不把这一 PR 的绿色测试算作金融最小闭环已完成。合并前还须检查远端 exact head、已处理评论和 capability 的 ready=true；不做 admin bypass。

English verdict: APPROVE - exact head cf95767. Original registry tokens are preserved, managed preparation freezes only a registered host-selected audience, and no execution authority is added. Full TS 3581 pass/31 PostgreSQL skips; focused native/storage and deliberate grammar mutation validate the boundary. This is a partial backend prerequisite, not live confirmation, source delivery or installation qualification.