feat(chat): native steward commissions in owner private Chat

[huangruiteng]

A separately selected private-Chat steward starts with a verified empty portfolio and accepts explicit new commissions through /delegate --tokens N objective and confirmation from the original owner/App/source. The existing typed binding and canonical action service own authorization and Goal creation; the original private Chat receives the native result. Ordinary project Chat creates no hidden Goal. Exact stop and explicit recovery preserve the Session, thread and cumulative usage; native completion is distinct from canonical Goal/Todo acceptance.

If creation commits but portfolio adoption or its readback fails, Core now journals the exact resources before attempting adoption and keeps the request queued. Recovery rechecks the original binding and canonical receipt, adopts the same resources and returns their result without creating another Goal or model thread. A notification receipt cannot settle pending adoption. This uses the existing request journal and a narrow adoption helper rather than another scheduler or authority.

This head includes #5541 at 6e7f41bbd56ef74fe58e04e9e68b447778c4bf6f, which incorporates merged #5540 and current main. The append-only integration preserves the predecessor history and unified workspace UI, removes the obsolete duplicate local-project panel, and keeps the two private roles in Settings → Lark. The PR remains based on #5541; the base-relative diff excludes its foundation.

Validation:

• 142 related Python tests passed; a final 10 steward/binding tests passed after the type correction. Focused Mypy (three files), Ruff, control-plane types and the packaged Chat build passed.
• Independent, source-qualified fault probes: the old head fails both committed-adoption cases; the candidate passes all three cases, including the interrupted creation-owner call. They verify one Goal, no extra thread start, original-route result exactly once and rejection after binding revocation. This qualifies Core/provider IO-owner recovery, not a full model/server restart.
• Sixteen risk-selected premerge checks and five direct checks passed. The catalog retains one maintainability advisory. The Goal-linked verification could not finish because this source cannot read a newer installed goal_storage configuration schema; it is not claimed as passed or waived.
• The actual packaged settings UI with synthetic provider/native protocol fixtures connects independent project/steward Apps, shows the empty steward honestly and fits a 390px viewport without overflow. Updated desktop/narrow screenshots contain synthetic data only.

Current-head CI and maintainer review remain required. Previous-head CI failures are historical evidence and do not certify this head. Actual live Operations Agent delegation, independent browser source reading, installed promotion and permission callbacks remain open; no old portfolio or identity was imported. The earlier actual Codex source canary verified same-thread continuation of a synthetic commission, not these remaining journeys.

[loopx-agent]

Reviewer: model_agent · gpt-6.1-sol · OpenAI · runtime_reported · xhigh

[P1] 创建已提交后，暂时的范围写回失败会遗失委托结果。

动机

从本人私人 Chat 发起一项新委托的用户，需要确认后继续工作并收到原始结果。

以前私人项目助手不能明确创建并管理新委托；现在选择管家、发送有预算的委托并在原私聊确认，才能创建新 Goal。

正常路径能创建、收养和返回一项合成委托；但创建后的暂时写回失败会留下已执行的 Goal，空委托范围和缺失的结果返回。

本轮不验收真实 Lark 手机链路、付费模型、多 Agent、安装发布或委托工作本身的 Goal/Todo 验收。

这不是未创建的失败请求：合成故障下，canonical action 已为 applied，Goal 已存在并完成原生执行；用户却只收到“操作未完成”，管家 portfolio 仍为空。

改动思路

既有 typed binding 冻结 App、本人、来源与工作区；单独选 steward 角色后，从明确空范围开始。/delegate 只生成有总 token 预算的只读预览，原私聊在15分钟内 /confirm 才经现有 action service 创建 Goal。范围仅收养该创建回执，原生结束与 canonical Goal/Todo 验收分开。没有新增 runner、scheduler 或并行 Goal store。

规范依据：docs/architecture/rfcs/app-conversation-and-async-inbox-v0.md，不可变版本 49562a4a77206c7af333365906bce67a62c6e872。本 PR 对规范的新增说明不替代这份预先接受的 matrix：

• Scope: implemented — pr5542-134425-tests-corrected.log; packaged ego-browser space16 readback
• Authority: implemented — pr5542-134425-tests-corrected.log; packaged ego-browser space16 readback
• Result: not_met — Applied Goal runs, but recovered IO cannot adopt or return it after terminal error writeback.
• Packaging: deferred — Current source packaged production HTTP journey independently checked; actual installed host not qualified.
• Dispatch: not_met — Post-create adoption error is journaled command_completed; recover skips it after provider verifies the failure reply.

具体改动

全量28文件847+/57-。conversation_binding.ts 增加 steward的明确空/有界portfolio、精确创建回执收养和 command/confirmation/expiry验证；conversation_scope.ts 与 project_context.py 复用现有原生上下文。ChatRuntimeController/store 持久确切 steward身份，每轮重新检查；manager context 区分授权空范围与缺失授权，并在同一原生线程刷新 scoped工具。

ChatActionService/native_token_budget 仍经既有 preview/apply/create 生命周期，Goal开启 heartbeat=false，Codex adapter保持read-only。external_conversations.py 的 service恢复执行委托，Lark private delivery journal 返回原私聊结果；stop冻结原执行，resume使用原Session/thread和累计额度。chat_agent.py 窄修 silent event reader 的 control RPC收据；当前控制回归通过。Lark设置加入角色/空范围/指令说明，provider-specific HTTP setup 从Core移到extension；当前架构边界测试通过。manifest行号、focused TS/Python、双语文档/合成图片同一stage。

阻塞位置：external_conversations.py:218–234。apply() 成功后，adopt_created_goal():224 若抛一次 OSError，catch 将状态设为 command_completed，而且 commission_resources 尚未写回。transport 把失败文本送达后 record_delivery 设置 delivery_verified；recover 随后跳过。真实隔离 registry/action/store 中复现1个已创建Goal、applied receipt和已结束native Turn；恢复原IO并reconcile两次仍 scope=[]、无结果。相同harness无故障对照能收养并向原私聊返回结果。

对主干的风险

当前109项原生/动作/私聊/Agent回归、142项架构/语义IO检查、TS8项、control-plane typecheck、Ruff、source bundle/frontend tsc、DCO/diff通过。相同既有测试集合在不可变predecessor49562a4a77206c7af333365906bce67a62c6e872上104项通过；新增正常路径不能抵消创建后故障反例。

在重新构建的生产HTTP打包Settings→Lark中选合成App、Research工作区、Codex和steward，真实binding回读 role=steward、portfolio_read、goal_count=0。桌面/390px检查目标、角色、真实starting状态与可操作下一步；reload后重新进入Lark仍保留原binding，解绑回读空connections。模型和Lark协议由隔离fixture提供，没有操作真实Bot/账户。该UI路径证明配置持久化，完整委托效果由Core真实store/provider journal测试和独立故障/对照证明。

按配置没有查询、轮询或等待CI。author描述中的历史CI失败未独立全量归因，也未宣称修好或豁免。安装发布、真实模型/Lark/手机链路仍未测；没有PostgreSQL authority refactor。审查准备时的错误测试路径/CLI参数与浏览器选择/视口恢复失误单独保留，已执行正确路径，不当作PR缺陷。

我的整体评价

REQUEST_CHANGES，精确head a0c3d68。设计与provider placement合理，正常路径能完整返回；但临时故障后的已提交工作遗失是同一slice的核心恢复回归。最小修复：先持久原创建资源，再用retryable post-commit阶段核验同一授权、幂等收养与一次结果返回；不要生成另一个Goal/线程或因失败通知ACK结算effect。加入apply成功/adoption失败→故障消失/重启→原结果返回的回归。未来重构检查支持这个现有journal内的窄状态修复，不需要新增框架。predecessor5541的其它未解决finding与本stage分开保留，不能因这里修了import边界继承上游批准。

English verdict: REQUEST_CHANGES - a0c3d68. P1: transient adoption failure after applied canonical creation terminalizes the confirmation; restoring IO leaves an executing/finished Goal outside steward scope and no original-source result. Fault/control reproduced through real isolated action/registry/session/delivery owners; native109, architecture142, predecessor104 and TS8 pass. Retain and reconcile committed resources idempotently. CI not consulted.

[mergify]

This pull request has merge conflicts with codex/native-private-chat-20261004 and cannot be merged
until they are resolved. Please rebase or merge the base branch, @huangruiteng.

Choose the remote for the base repository, not an out-of-date fork.
For a fork clone, first inspect git remote -v; upstream must point
to https://github.com/loopx-project/loopx.git. If it is absent, add it
with git remote add upstream https://github.com/loopx-project/loopx.git.
Then run:

git fetch upstream
git rebase upstream/codex/native-private-chat-20261004
# Resolve each conflict, git add the resolved files, then git rebase --continue.
git push --force-with-lease origin HEAD

For a same-repository clone whose origin points to
https://github.com/loopx-project/loopx.git, use origin instead of
upstream for fetch/rebase. If you prefer merging the base, use
git merge <base-remote>/codex/native-private-chat-20261004 and push normally.

Keep the DCO Signed-off-by trailer on every commit when you rebase.
https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/syncing-a-fork

[loopx-agent]

Addressed the committed-creation recovery finding in c1e22b1.

The request journal now saves the exact canonical resources before fallible portfolio adoption. Adoption/readback failure remains queued; recovery checks the original audience and receipt, adopts those resources and returns the result once. Pending adoption cannot be settled by a notification ACK. No extra Goal or thread is created.

Independent old-head/candidate probes reproduce both terminalization failures on the old source and pass on the candidate. The interrupted creation-owner case passes on both. Revocation rejects recovery. Related Python: 142 passed; final steward/binding: 10 passed; focused Mypy, Ruff, Core types and packaged Chat build passed. Packaged synthetic settings show both independent roles and a truthful empty portfolio at desktop/390px widths.

Repository premerge passes (16 selected, 5 direct; one existing maintainability advisory). Goal-linked verification remains unavailable because this source cannot parse the installed newer goal-storage schema. Full host restart, live Operations Agent delegation and installed promotion are not claimed. The head incorporates #5541 and merged #5540 without rewriting their history.

已修复创建提交后收养失败被误当终态的问题：先保存确切资源回执，恢复时核验原受众并采用原资源，原私聊只返回一次结果；不重复创建 Goal/线程。上述实测为 Core/provider IO 恢复，未宣称完整宿主重启或真实运营 Agent 委派已验收。