fix(collaboration): default trusted sources to local registered Agents

[huangruiteng]

A configured steward source could discover a suitable local Agent but fail to deliver the original request because delivery required per-recipient enrollment. Sender-bound sources now default to every active registered local Agent, across Goals and future registrations, using the existing shared TypeScript source-grant owner.

This deliberately changes the default for existing source policies: set local_delivery_scope: "selected" with targets to retain enrollment. Exact Agent and whole-Goal revocations override the default on direct delivery, replay and peer forwarding. Restoring a Goal preserves its Agent exceptions, including an Agent revoked while that Goal was disabled; both selected and default scope retain explicit revocation intent. Missing/wrong source provenance, stopped/unreadable Goals and remote bindings gain no authority; evidence reads, task acceptance and execution remain separate.

Updates the existing R3/RFC checkpoint and GQ03/GQ07/GQ09 acceptance. The existing conversation journey consumes the shared rule; the source-grant settings editor and native receiver adoption remain separate, unqualified boundaries.

Validation: 132 focused Python cases qualified across the affected suite and final handoff rerun (2 Win32-only skips). The refinement run had one stale metadata-only fixture failure; restoring its recipient through the operator API fixed the precondition, and the final changed handoff file passed 28/28. Initial full TS suite passed 3968 (31 environment skips); final owner tests passed 8/8; control-plane typecheck and semantic drift passed. Packaged Chat/real TS, File Inbox and HTTP/store readback covered cross-Goal return to the original request, revocation, reload and narrow screen. Workspace/channel selection, receiver outcome and provider transport were synthetic; no model run or live Goal writes.

All 19 risk-selected premerge checks passed; final exact-scope quality receipt recorded. The full legacy Goal-instance suite has an existing lifecycle-only fixture incompatibility; a representative failure was independently reproduced on unchanged base 99839aeb8, and that file is untouched. This PR does not claim to close that separate validation debt or a remote-host continuation.

One bounded refactor names the owner-local delivery scope and replaces superseded RFC guidance. Diagnostic logs, policy files and private incident context are excluded.

[huangruiteng]

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

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

评审 head：a04fc20f4131b0aa5d84acae976dafe05a32a998。没有遗留阻塞项；旧头撤销顺序缺陷已由独立反例和修复后验证确认解决。

动机

配置了可信来源的用户，通过管家把原始问题交给本机已注册的 Agent；他们不应在每次找到合适接收者后再次登记投递名单。

例如用户要求另一个 Goal 的工程 Agent 处理问题：以前能发现该 Agent，却因未逐个登记接收者而投递失败；现在已认证来源可把原问题投到其 inbox，后来注册的本机 Agent 也适用。

独立执行确认：默认跨 Goal 投递、显式限定接收者、撤销后拒绝、明确恢复后继续，以及原请求重放不重复创建 inbox 项均符合预期。

这个 PR 只扩展上下文投递准入，不增加证据读取、任务采纳、执行、远端主机或受保护操作权限。

来源授权设置编辑器、原生 worker 实际采纳及完整 M1–M3/A24 闭环仍未验收；本次是已有对话入口上可独立使用和撤回的投递增量。

改动思路

复用同一 TypeScript source-grant owner：已认证入口绑定的 sender + 来源策略 + 新鲜本机注册/激活状态 → resolveSourceRecipients → 直接投递/重放或 peer 转交 → File Inbox 和既有回传回执。Python 保留锁、IO、来源观察及 provider 适配；没有增加另一份投递决策源。

默认缺省 local_delivery_scope 现在是 all_registered；需要保留逐个登记的来源须显式选择 selected 并提供 targets。blocked_targets 表达不可从“当前可投递集合”推导的撤销意图，优先于 Goal 授权。投递回执仍明确不改 Todo、优先级或执行中断状态。

独立评审基准为 docs/architecture/rfcs/capable-manager-semantic-handoff-v0.md，固定于本 PR 前的 99839aeb8fed5fae38a5d319391cd050672a6508：

• §5.3：复用持续来源授权，保留明确收窄/撤销；直接、重放和 peer 使用同一 owner。本 PR 有意把已配置来源的本机上下文默认范围扩展到所有当前/未来注册 Agent；这是已披露的行为变更，不能把更新后的 RFC 当作独立正确性证明。两种 scope 的撤销、恢复与来源反例已实际验证。
• §5.5：发现、投递资格和实际执行能力分别判断。53 个注册接收者及 registry 顺序变化不丢失目标；stopped/unreadable 激活状态使原请求重放被拒绝，恢复合法激活后继续。
• A24：完整原生接收方评估、执行和实际 provider 回传仍是既有 RFC 的后续验收边界。复用的 packaged Chat 证据证明既有显示/HTTP/store/TS/File Inbox 路径；workspace/channel 选择、接收方结果和 provider 传输为模拟，不据此宣称完整委托已完成。

具体改动

全 PR 为 13 个文件：1 个生产 owner、7 个测试文件、5 个文档文件，合计 +271/-91。生产变化集中在 source_grants.ts；manager/peer/roundtrip/tracking 与两项 Lark 测试把需要限定名单的 fixture 显式设为 selected。README、既有 RFC/roadmap 检查点及 GQ03/GQ07/GQ09 说明新默认和未完成边界，没有新模块、CLI、自动加载指令或推测性 provider。

关键代码讲解

1. localScope，第 27 行：只有字段缺省采用新默认；null/未知值被拒绝，避免非法输入扩大权限。
2. resolveSourceRecipients，第 49 行：先验证 sender，再用当前注册接收者与 scope/显式禁用相交，按精确身份去重排序；外部证据来源、错误 sender 或伪造原消息不能激活投递。
3. configureSourceRecipient，第 66 行：预览不写策略，adapter 锁内 apply 并读回。恢复 Goal 只删除该 Goal 的禁用，保留 Agent 例外；恢复个别 Agent 时要求其 Goal 已恢复。
4. source_context_authority，第 36 行：未改动的入口观察验证不可变 ingress 的 session/turn/channel/message 绑定，再调用共享 TS 规则。deliver 在返回已有请求前再次检查权限，peer 路径也重新验证原来源与链上的接收者。

最强反例及修复。 在旧头 9f2b710010be89b404d5d9d74c59779fcebc3bd1，先撤销 Goal，再撤销 Agent，第二步因“已经禁用”返回不变而丢失独立例外；恢复 Goal 后，fresh、replay 和 peer 均误放行。旧头现有 130 Python/7 TS 测试通过仍能复现这个反例。新头第 113–116 行只按精确 (goal_id, agent_id) 判定重复撤销，保存独立意图。以同一个私有、合成 fixture 程序在旧/新头运行，两种 scope 下新头三个入口均拒绝，其他 Agent 继续；明确恢复 Agent 后原请求恢复同一 ID，inbox 仍只有一项。相反撤销顺序也保持正确。这是当前 PR 内有界的共享规则修复。

对主干的风险

兼容与默认。 现有仅有 sender_ids 或旧 targets 的策略将采用更广的本机默认；需要旧名单语义的用户须设置 selected。PR 正文、manager-context/collaboration README 和 RFC 已披露这点。缺省、显式 selected、未来注册、错误来源和 malformed scope 的基线/新头比较体现了有意变更与保持的拒绝边界。证据 Goal 白名单仍是读权限，不能误当作新默认的投递名单。

语义一致性

检查了完整差异及 direct/peer/配置 callers。scope 是既有 TS owner 内的明确联合类型；错误使用精确 ID 和输入解码，没有字符串 denylist、产品专属控制面义务或声称已接管执行的协议名称。注册/激活状态来自当前事实；scope/显式例外是独立操作者意图。修复将两者分开，避免使用可投递集合代替撤销意图。完整语义 smoke 通过；advisory 没找到其支持的新增载体，但不覆盖 TypeScript 联合类型，不能独立证明语义正确。

验证。 独立旧头受影响 Python 六模块 130 passed、2 个 Win32-only skip；复核新头新增/修改用例 3 passed、TS owner 8/8；新头 typecheck、semantic drift 通过。18 组相同程序的 base/head 观察与 23 组旧缺陷头/修复头观察支持默认、来源、撤销、恢复、peer、重放和显示顺序反例，另由 32 条独立不变量检查确认。未查询或等待 CI。

已有失败及证据限制。 RFC index check 在基线和最终头均因未改动的两份 external-evidence RFC 的 dated-log headings 失败。test_recreated_goal_cannot_observe_or_mutate_prior_instance_requests 在同一基线/最终头命令下均于 fixture 的首次 deliver 抛出 context recipient is not authorized or registered；测试、source observation 和该 Python 调用路径字节一致。它们是既有验证债，不是本 PR 的新增阻塞项；总体检查不能称为全绿，合并就绪由对应 owner 处理。未复跑整个旧 Goal-instance 套件，不能将代表性失败推导为全部失败的归因。

复用作者 packaged UI/store 读回并检查 desktop/mobile 整个视口：原问题、worker 回执、证据链接和送达状态可辨识；UI/HTTP/观察调用文件相对该证据未变。它是支持证据，独立验证使用真实 TS、文件 inbox 和 disposable registry，没有实际模型、原生 worker 采纳、远端续接或真实 provider 发送。

我的整体评价

APPROVE，作为可信本机来源投递的有用增量。 在已有 owner 中修复准入，并把持久撤销意图与当前覆盖分开，规模与实际摩擦相称；没有用重复框架、平行配置或更多确认步骤弥补投递断点。未来改动更容易集中在该 TS 边界；本次相关重构已经包含在 PR 中，不需要另造任务。

非阻塞文档建议：同步中文版 RFC §5.3/已交付检查点的新本机默认、selected 与恢复例外说明，避免英文已更新而语言镜像仍只描述较早 managed-Goal 阶段。完整规划/执行继承和 A24 继续沿既有验收边界推进。本评审不授予合并权限。

English verdict: APPROVE - a04fc20. The Goal-first revocation defect is fixed and independently reproduced/verified across both scopes and direct, replay and peer paths; 8 TS tests, 3 refreshed Python cases, typecheck and semantic validation pass. Baseline-only RFC-index and legacy-fixture failures are separately attributed; native adoption and live transport remain unqualified.

[huangruiteng]

Merged with explicit maintainer authorization for steward-related admin bypass, after the independently published APPROVE on unchanged head a04fc20f4131b0aa5d84acae976dafe05a32a998 and capability merge-readiness ready=true.

Changed surfaces: shared TypeScript source grants, manager/peer/Lark contract fixtures, and existing roadmap/RFC/golden-query acceptance. Final risk validation selected 19 checks; all passed, with no manual holds or quality-receipt failures. Focused Python coverage totals 132 passes across runs with 2 Win32 skips; the changed final handoff file passed 28 tests after repairing a stale fixture. Final source-owner tests passed 8/8. The unchanged legacy provenance/RFC-index failures are recorded separately in the independent review. CI was intentionally not consulted under the configured review policy.

Installed CLI, packaged App runtime and Chat backend now report the merged source revision. Readback of the original verified ingress confirms the wider local recipient set without changing source configuration; existing sessions were retained. This establishes installed admission behavior, not native receiver adoption or remote continuation. Those remain open acceptance boundaries. The bounded refactor preserves exact revocation intent independently of current effective delivery; no second decision owner or speculative module was added.