fix(chat): connect native steward provenance to context delivery

[loopx-agent]

Native steward private messages need immutable provider provenance before the existing context inbox can authorize delivery. Record the independently verified App owner and original request before Turn launch and prepared-request replay. Operator configuration accepts exact native App/source channels, rejecting partial identities and wildcards. Oversized context remains intact in ordinary Chat without gaining inbox delivery.

Keep provenance with the controller's resolved coordination runtime root when Chat storage is separate. Legacy controllers retain their existing Chat-parent layout. This composes with the coordination-root owner in #5683 without making that companion a prerequisite for standalone admission. Reuse the existing inbox and separate sender/read/recipient policy; add no queue, schema, authority, model runner or configuration resolver.

Validation at the latest head: 129 affected source tests passed. The new canonical-root/legacy pair also passed against a separately installed non-editable wheel, with every imported LoopX module verified to remain in that wheel, and passed against the composed local canary. The canonical-root oracle fails on the prior head while its legacy control passes. Tests cover provenance before enqueue, exact message delivery, replay, sibling-App isolation and revocation. Ruff, 281-site registry census and semantic advisory/full check passed. Whole-PR native premerge against pinned main ran five direct and fifteen selected checks: passed, with one inherited maintainability advisory and no blocking failure or manual hold. Focused Mypy retains the same 16 diagnostics as pinned prior head; the broader imported-tree check reports 4551 errors and is unqualified. Initial missing Node dependencies/frontend bundle were repaired and final wheel build passed. Remote CI and live Lark/model qualification are not asserted by these local checks.

Entry points are native Chat/Lark admission and existing operator configuration. Synthetic provider/model fixtures use the real Core and durable inbox. Receiver adoption, worker launch, automatic wake, original-route completion and the packaged operator settings journey remain with their existing R3/A24 owners. This closes the ingress/root-composition prerequisite; it does not certify full collaboration or Goal completion. Runtime/control-plane change: exact-head review and maintainer merge required.

[mergify]

This pull request has merge conflicts with main and cannot be merged
until they are resolved. Please rebase or merge the base branch, @loopx-agent.

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/main
# 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>/main 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]

Reviewer: model_agent; gpt-6.1-sol; OpenAI; runtime_reported; reasoning_effort=xhigh

Approval conclusion (author-owned PR; GitHub blocks formal self-approval)
Exact head: 5615@1074c5412fae8ae6487f5353a9a8ec35b11145ad; immutable base bd607db.

动机

使用本人已配置原生私聊管家的用户，交办时原消息能进入 Chat，却没有收件箱所需来源凭据，已有 Agent 因而不能收到上下文。 同一 App 的原消息在模型启动前持久保存来源，已有会话和请求重放保持原身份；独立读权限仍不能代替投递授权。 真实原生 admission、配置 CLI 预览/应用/撤销/恢复和精确收件读回通过；普通项目私聊 base/head 保持相同，基础版本缺来源且拒绝原生 channel。 保留旧行为会让本已授权的上下文交接持续失败，要求用户再次解释或手动找接收方。本 PR 只修复进入现有收件链的入口。完整目录责任选择、模型自主采用、任意新任务、完整停止/恢复与正式安装的 frontend/Lark 闭环仍未验收。 不认证付费模型、真实 Lark 网络返回、跨宿主、持续吞吐、完整管家目标或普通用户设置编辑器。

改动思路

使用现有管家上下文 capability 和 TypeScript 来源授权规则，原生适配器只记录 provider 已校验的 App/source 和不透明 owner 引用，不建立新队列或权限源。它先持久写来源，再交给 Chat 原有 Turn 准入；prepared 请求恢复再次保存相同来源，canonical store 验证原请求，而不是移到另一会话。来源、目录、读权限、投递和执行仍是不同事实。

原生 channel 格式交给同一个小 helper 校验，保留完整 legacy channel，明确拒绝前缀和 wildcard。未配置 sender/target 的管家仍无投递对象；超过 inbox 容量的消息保持完整普通 Chat 输入，但没有可交接来源。普通项目会话没有这条 provenance 写入。此范围不声称 source 收件就是模型采用或 delegation 已完成。

具体改动

判断依据是修复前 Accepted docs/architecture/rfcs/capable-manager-semantic-handoff-v0.md，固定修订 bd607db9c563b263111abdbc37167620e919feb7。RFC-5.3（§5.3） 来源及独立读/投递授权 implemented；RFC-5.4（§5.4） 原文与身份、容量边界 implemented；RFC-5.6（§5.6） 入口持久化与重放 implemented。§5.5/A24 完整责任发现、执行 readiness、接收方采用及原受众最终结果 deferred，仍由既有 R3 owner 接续；作者新增 checkpoint 没有把它们改成通过。

关键代码讲解

• _record_steward_ingress：只处理 steward binding，核对原 Session 的 Goal/channel；以 provider 核实的 operator_ref 和 request_ref 写既有 ingress。正文、Session 和 request 不由模型选择，另一 App 不能复用该来源。
• _require_external_channel：完整 legacy 24 位引用或 native 的两个 24 位引用才通过，两个现有配置命令共享这个 owner。配置预览没有改政策，应用有实际 readback。
• admission 的两处 call site 覆盖新入队及 prepared/已准入重放；register_ingress 的不可变字段冲突判断、现有 sender/recipient policy 和 inbox digest 保持原 owner。manifest 两处行号随 helper 移动更新。其余 README、roadmap 明确阶段缺口；新增七个入口回归，完整 diff 为六文件 +184/-6。

对主干的风险

当前无阻塞发现。独立 43 项 Python、8 项 typed policy、一个追加的真实来源/配置 CLI 场景通过。追加场景同时证明：已授 operations 能收到原文；同 Goal 未授 decoy 和新注册 Agent 拒绝；正文伪造拒绝；撤销后原请求不能重放，恢复授权只重放原 receipt，不新建任务/打断执行。第二 App 与普通项目会话保持隔离，政策文件是 0600。基础版本相同七个 oracle 两项失败，分别是模型启动前来源不存在、合法原生 channel 被配置入口拒绝；另外五项通过。额外 paired 真实入口观察确认普通项目的消息、状态、Goal=None 和无 ingress 一致。

Ruff、diff hygiene、changed advisory 后全树 semantic、原生 CQ 和 premerge 通过；premerge 五个 direct、十五个 selected、零 blocking/manual hold。架构 ratchet 的 goal_topic_runtime.py module metric 仍在 immutable base/head 同样失败、magnitude_regressions=0，原生明确列为 inherited advisory；未修复也不冒称该 check 通过。全树还保留 44 个未证明 producer，扫描不是完全语义证明。没有查询、轮询或等待 CI。初次测试命令写错不存在路径没有收集，已用正确 source 路径重跑；第一次 canary 遇旧 CQ scope，清理本次生成的临时 lock 并对精确 scope 重资格核验后通过。

语义与 CI 对齐

复用既有来源/收件 vocabulary 和 TS grant owner，没有新增 actor lifecycle 或执行权。启用的原生管家来源写入是明确修复，普通项目入口 base/head parity 独立执行。收件上下文容量不等于普通 Chat 容量，超限不能静默截断或扩大投递。live provider、付费模型、正式安装和设置 UI 未被 synthetic 源替代。最新 GitHub 报与 main 冲突，代码评审通过不代表可直接合并；运行时变更由维护者处理。

我的整体评价

APPROVE，交付判断 justified_increment：long_horizon preserved，身份、原义和重放不丢；user_experience improved，已配置来源终于能使用既有交接链。这个入口修复有完整正反例，不以目录可见或收件回执关闭 A24。Future-facing pass 已采用同一 exact-channel helper 和既有 provenance/grant owner；更大的设置/执行旅程留原 R3 范围，不加新权限或并行队列。当前精确 head 有效，同账户 GitHub 正式 self-approval 不可用，此 COMMENTED 结论不是平台 aggregate APPROVED。冲突与维护者合并 gate 保留。

English verdict: APPROVE - 1074c54; native verified ingress, exact configuration CLI, replay and five scope counterfactuals independently validated; 43 Python/8 TS plus actual-source checks pass. Inherited architecture advisory, merge conflicts and full installed steward journey remain open.

[loopx-agent]

Reviewer: model_agent; model=gpt-6.1-sol; provider=OpenAI; declaration_source=runtime_reported; reasoning_effort=xhigh

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

动机

已配置并独立核实原生私聊来源的用户，把原消息交给管家时，Chat 虽然受理，却没有现有收件链所需的来源凭据；现有配置 CLI 还拒绝原生 App/source channel。因此本已授权的上下文不能送给接收方。这个修复在模型启动前保存原文、原 Session/request 和独立 operator 引用，并让现有配置入口接受完整原生 channel。真实 Core、独立 wheel 和配置 CLI 已验证恢复、拒绝与重放。它只交付接收前置：worker 启动、接收方采用、原路线最终答复和完整 R3/A24 仍待既有 owner 验收。

改动思路

复用现有不可变 ingress、共享 inbox bounds 和 TypeScript source-recipient rule。Python 保留实际 provider 核验、文件 IO 和来源持久化职责，没有第二个授权或状态机。原生来源不是投递许可，portfolio 读取也不是投递或执行许可。普通项目路径没有新增 steward 来源记录，超出 inbox inline 容量的消息完整保留在 Chat，不静默截断或扩大交接权限。

本轮在原分支正常合入固定 main c46f397c0f8b6115ed6efa0b06ab9bb6ca9e73dc，只解决生成清单的行号冲突，保留 main 当前 portfolio 规则及显式 selected audience 的全部拒绝。没有复制其他 PR 的实现、force push 或新增替代 PR。原审查 head 的批准没有继承到新版本；下面是整个新版本的独立判断。

具体改动

精确 head：684fcb73dc330d2e5b7b6c49b80514f2eda08440。依据当前 Accepted manager RFC RFC-5.3（§5.3）、RFC-5.4（§5.4）、RFC-5.6（§5.6）均为上述有界前置 implemented；R3/A24 的完整协作结果不由这项前置关闭。

• _record_steward_ingress（external_conversations.py:194）在新 enqueue 及 prepared/已准入重放前，核对 steward binding 与原 Goal/channel，以已核实的 opaque operator_ref 和 request_ref 保存来源。共享校验函数直接从 inbox owner 导入，移除不必要的隐式 manager facade 依赖。
• _require_external_channel（manager_context/__init__.py:327）让两个既有配置 API 共用完整 legacy/native 语法校验；partial、prefix、wildcard 拒绝，实际政策仍由既有 typed owner 决定。
• 七个 ingress 回归覆盖启动前来源、canonical 崩溃重放、独立 sender/target、scope 和普通项目隔离、超限原文。README 与 roadmap 保留 staged 验收；生成器重建281个 I/O sites，零 unclassified。整个当前 PR 六路径185+/6-，没有私有运行状态或新 schema。

对主干的风险

没有当前阻塞发现。最强反例是“函数测试通过，安装入口仍拒绝原生 channel，或新 portfolio 默认使显式 selected audience 越权”。固定 main 上，同一 ingress oracle 两项失败（启动前来源不存在、原生 channel 拒绝），另外五项控制通过；当前源码144项、共享 TS25项和独立 wheel99项通过。安装包验证加载路径与生产字节；额外真实安装 CLI 场景通过 preview/read/grant/revoke、范围外 Goal、同 Goal decoy、新注册未授 Agent、恢复后原 receipt replay，政策0600且 registry 未被配置操作改写。普通项目私聊、other App、stop 和 verified reply 的同一 base/head 对照通过。

Ruff、TS typecheck、changed advisory 后全树 semantic、严格原生 CQ 和 premerge 已通过；premerge 五个 direct、十五个 selected，零 blocking/manual hold，保留原生归因为 inherited 的 maintainability advisory。没有放宽 budget 或免除检查。focused Mypy 在修复前新增一项隐式 re-export 错误，本轮直接引用共享 owner 后，base/head 剩余16项完整诊断经行号归一化相同；这些是未修复的主干债务，不能称类型检查全绿。最初 transitive Mypy、安装测试受 source conftest 路径污染、CLI/CQ 参数与 schema 写错的尝试不作为资格证明；独立 fixture、实际安装字节和当前合法回执形成有效证据。未查询、轮询或等待远端 CI。

当前未做真实账户、手机/Lark 网络或付费模型操作；这些 fixture 使用 synthetic provider/model，真实 Core 和磁盘/backend/安装 CLI。完整设置编辑器、worker adoption/execution、自动唤醒、最终回到原会话的产品闭环不由测试数字认证。回滚是代码 revert，保留现有 ingress/receipt 恢复能力，运行时变更交维护者合并。

语义与 CI 对齐

复用既有 native audience 和 source-grant vocabulary，没有新 actor lifecycle、quota、lease 或执行权限。selected 的显式范围、sender 和 read grant 分开；main 的 portfolio 默认不是本 PR 新增行为。机器拒绝就是强制边界，说明文本不能绕过它。未启用的普通项目路径 base/head 相同；原生来源超限不等于 Chat 拒绝。词汇扫描空结果也不证明动态语义完全覆盖，实际负例与 full semantic 分别保留其边界。

我的整体评价

APPROVE，属于完整可逆的 justified_increment：long_horizon preserved，原身份与重放不丢；user_experience improved，已经授权的原生来源可使用现有交接入口，不再重复解释。Future-facing pass 已直接复用共享校验 owner；有价值的 Python provider/IO/recovery 没有因语言被误删。批准这个精确版本的前置修复，不代表 R3/A24、SQLite 默认迁移或整个 Goal 完成。作者账户只能发表 COMMENTED 结论，它不是 GitHub 正式 self-approval 或合并授权。

English verdict: APPROVE - 684fcb7; verified native provenance, exact installed configuration CLI, immutable replay and explicit sender/audience/revocation/future-recipient controls independently pass. 144 source,25 typed,99 installed plus native CLI and pinned base counterfactuals cover this slice; inherited typing/maintainability debt and full worker/settings/return acceptance remain explicit.