Repository navigation
fix(chat): retain steward identity across executor changes - #7846
Conversation
Signed-off-by: LoopX Agent <337587101+loopx-agent@users.noreply.github.com>
loopx-agent
left a comment
There was a problem hiding this comment.
Reviewer: model_agent; model=gpt-6.1-sol; provider=OpenAI; runtime_reported; reasoning_effort=max.
Approval conclusion (author-owned PR; GitHub blocks formal self-approval).
未发现阻塞性问题。评审针对 b2ce2aea4e986a8617c4c6dad4ff4d4ac215423f,结论是一个可独立验收的恢复增量,不是父级协作路线全部完成。
动机 / Motivation
使用多个已绑定助手会话的用户,在管家切换执行器后会遇到这个问题。例如管家保留已准备的身份并选择另一执行器时,旧校验会连带拒绝同一配置集内的项目助手,已保存的新消息因此停在接收阶段;修复后,项目助手沿原恢复流程执行并回到原会话答复。
已保存的项目请求可恢复为一个原生请求、一次模型执行和一条核验过的原会话回复,同时保留管家原身份与所选执行器。本次不增加非 Codex 的原生执行能力,不新建队列或消费者,也不宣称历史业务已经全部完成。安装后的真实消息补办需要另行验收;完整的跨执行器原生任务支持仍由其既有实现负责。
改动思路 / Approach
身份记录的存储有效性与当前执行器的运行资格应由各自现有边界判断;把 Codex 限制放在整个绑定集的解码阶段,会错误阻止独立会话。本 PR 只修复共享 TypeScript 绑定解码,并沿既有 Core、原 worker 和 provider 回执验证恢复,不增加状态字段或第二套执行规则。保持旧条件会继续发生确定性拒绝;删除管家身份会丢掉已接受的原生归属;分别修改每个读取者又会复制相同规则。因此直接收回存储解码阶段多余的执行器限制,同时保留真正执行时的原有检查,是范围最小且可回滚的改法。
原请求已经有来源、受众和授权,恢复不增加用户填写、导航或确认轮次。已有 worker 读取保存的消息,经过原 Core admission、模型执行和 provider 读回才结算答复;扫描函数的返回整数本身不是业务完成证据。
具体改动 / Changes
规格依据为 docs/architecture/rfcs/capable-manager-semantic-handoff-v0.md,不可变版本 035f7ac666cef390676c00b6fb0537ede3c9cf44。A12 映射到本次执行器变化时保留身份、约束与待办的切片;A8 的完整完成时重启场景继续由既有回传恢复工作验收;本用例只覆盖接收后、Core admission 前中断,不把它冒称为完整 A8 资格。完整的模型/工具升级兼容、跨 Host 行为和全部历史积压不在这次合并资格中。
关键代码讲解
binding():state()会解码整个绑定集,原有 endpoint 条件因此会阻止无关项目会话。现在仅解除存储时的当前执行器限制,保留私有 steward 角色和normalizeStewardManagedActor的完整形状检查;返回的原身份、所选执行器和受众没有被改写。stewardManagedBasis():这个未改动的运行边界仍要求 Codex、原 Session/Goal/Agent 和经核验的来源。TypeScript 反例直接调用它;真实 Core 用例还验证不支持的准备操作不会调用模型或改动 registry。test_retained_actor_on_another_executor_does_not_block_captured_project_work():使用真实 File/SQLite 原生创建和原 worker,只有 provider/model 是合成的;确认 captured 请求变为 accepted/completed、同一原消息只进入一次、模型只调用一次、最终答复经过原聊天读回,重复对账不会重跑。
对主干的风险 / Risks
最强反例是把身份可读误当作非 Codex 原生执行授权,或顺带允许项目/群聊挂上管家身份。对应反例仍拒绝,原生准备失败也保留模型与 registry 的无效果证据。没有新增队列、字段、schema 版本、持久回执或权限;现有原始来源、撤销、原 Session 和 native basis 继续负责准入。
验证 PASS:384 项 Python、49 项 TypeScript、control-plane typecheck、Ruff、双语 diff、standard premerge;3 个变更文件的 public-boundary 扫描干净。同一最终回归 harness 换回基线生产条件时,2 项 TypeScript 和 2 项 File/SQLite 用例按预期失败,恢复最终源码后与提交字节一致。CI 按当前策略未查询,也不以 CI 元数据替代本地证据。
语义与 CI 对齐
复用既有身份和绑定词汇,没有新造状态。诊断从“private native steward”改为“private steward”,对应的是存储有效性;native 执行条件及其拒绝仍在原执行边界。该默认行为变化已在 PR 和用例名中明确披露,不属于 default-off 功能,也没有隐含激活策略。
我的整体评价 / Verdict
justified_increment:long_horizon=improved,原保存消息可以继续推进并保留归属;user_experience=improved,用户保留执行器与原会话且无需补充确认。身份记录的存储有效性与当前执行器的运行资格应由各自现有边界判断;把 Codex 限制放在整个绑定集的解码阶段,会错误阻止独立会话。本 PR 只修复共享 TypeScript 绑定解码,并沿既有 Core、原 worker 和 provider 回执验证恢复,不增加状态字段或第二套执行规则。
检查了既有 private_conversation_api.py、private-conversation-panel.tsx 与绑定调用链;本次没有修改渲染、布局、控件或导航。未验证范围:完整安装后的真实模型业务结果和全历史积压完成情况,不由合成 provider/model 回归证明。兼容性选择是保留现有持久身份,复用单一 TypeScript owner;无需迁移或增加框架。后续安装与原服务真实补办由既有交付流程独立验收。
English verdict: APPROVE b2ce2ae. The existing shared binding decoder now preserves retained steward identity across executor changes, while native execution remains fenced. Native recovery, negative cases, typecheck and premerge passed.
A prepared steward can retain its managed actor when the owner selects another executor. The binding decoder rejected that persisted state, which also blocked unrelated project conversations because it validates the complete binding set.
Keep the original actor readable on private steward bindings across executor changes. Native execution still requires its existing Codex admission checks; project/group actor grants and malformed identities remain rejected. The existing capture worker can then admit saved project input and return its answer once to the original audience. This covers the retained-identity boundary of semantic handoff A12. The existing original-return path is exercised; full A8 restart qualification is outside this repair.
Validation:
No frontend layout changes. The existing App/Lark conversation and pending-work readback remain the product entrypoints. Installed-runtime adoption will be verified separately after the reviewed change is merged.