[§4.9.1-2 求裁] 回收判据「X 非用户声明」的数据源：SDK 运行期无 origin，用户 server 与 plugin server 可观测同形

[JIAQIA]

发起方：python-sdk（#153 D3+F1 实施中由隔离审查发现）。母单 Epic：python-sdk#147 / rust-sdk#129。
前序共识：Discussion #23（D3/F1 终审）。求裁：协议 §4.9.1-2 回收判据第二项在两个 SDK 里如何落地。

背景：§4.9.1-2 第二项的数据源，SDK 侧无法直接实现

协议 runtime-contract.md §4.9.1-2 定回收判据：

回收 X ⟺ 无其他 plugin 声明依赖 X ∧ X 非用户声明（运行期权威配置集中不存在 origin != plugin 的 X 条目）

第一项（无其他 plugin 声明依赖）从账本 mcpServers 即可判定，两端已落地、无分歧。

第二项的数据源是「运行期权威配置集 + origin != plugin」——但 python 的 MCP manager 不存 origin。
运行期活跃集只有 bundle_id → MCPServerConfig，没有「谁把它挂上来的」这一维。

问题：两种来源在运行期可观测信息完全同形

场景	如何进入运行期活跃集	落 mcp.json？	协议期望
用户 a2c-computer run --config @servers.json	transient amount_server	❌	origin=flag ⇒ 不回收
SDK 内嵌 Computer(mcp_servers={...}) 构造	boot 物化	❌	非 plugin ⇒ 不回收
plugin enable 挂载其声明依赖	transient amount_server	❌	origin=plugin ⇒ 可回收

三者在 manager 里长得一模一样。于是：

• 判据只读 mcp.json 声明面 ⇒ 前两种被判「非用户声明」⇒ 卸载 plugin 时连坐停摘用户自己的 server（违 §4.9.1-2 + Epic 北极星「用户自有 server 永不连坐」）
• 判据把「运行期活跃 ∖ 全部 plugin 声明集」当用户的 ⇒ 对回收候选恒等于只读 mcp.json（回收候选本就只含 plugin 声明过的 bundle_id，必然落在 plugin 声明集内、必然不在差集中）——python 侧已实测验证该修法为无效代码
• 判据保守到「无法证明是 plugin 挂的就不回收」⇒ 场景①（A 引入 X、无人依赖 → 卸 A 回收 X）失效，X 泄漏

结论：不新增「运行期归属」信息，SDK 无法同时满足 §4.9.1-2 与场景①。

同一架构缺口 python-sdk#148 已遇到过一次：Computer.aremove_server 当时选了保守侧（「无用户声明 ∧ 运行期活跃 ⇒ 拒删」），并把 provenance 问题显式挂给 #153/#154。现在 #153 撞上了它的对偶面。

候选方案（求三方裁决）

A. 运行期归属（origin）落地到 SDK 运行期状态

Computer/manager 记录「哪些 bundle_id 是经 plugin 上下文挂载的」（运行期态，随进程生命周期，boot 由意图重建）。

• ✅ 精确实现协议原文（origin != plugin）；三种场景全部判对
• ✅ 不违 F1：F1 禁的是账本存 provenance（时点快照会随其他 plugin 卸载而失真）；运行期归属是当下事实，重启即重建，不存在失真
• ⚠️ python 侧 amount_server(plugin=, marketplace=) 已有归属入参但未落地；RegisterServer 接缝需携 plugin_id（公开 trait 变更，rust 侧 McpInstallHooks 同）
• ⚠️ 触及 python-sdk#134 / rust-sdk#121「嵌入式多实例 ownership 混源」轴——Epic #147 明载「共识未覆盖该轴」

B. --config @file 归一进 mcp.json flag 层（python-sdk#154 / rust-sdk#137 范围）

让 --config @file 的声明进入 resolve_mcp_config 的 flag scope，从而落入「用户声明面」。

• ✅ 复用既有 scope 机制，无需新概念；与 F6「--config → --mcp-config、层序统一」同批
• ⚠️ 只解决 --config @file，不解决 SDK 内嵌 Computer(mcp_servers={...}) 构造（库用法，无文件可归一）
• ⚠️ python 现状两者 schema 不同：--config @file 是裸 server 数组 → amount_server；resolve_mcp_config(flag_config_path=) 期望 {servers, inputs}

C. 协议澄清「运行期权威配置集」的最小可实现形态

若协议认为 SDK 不必持有 origin，则需要给出等价的可判定规则（例如把判据改写为只依赖账本 + 声明面的形式），或显式承认「无 origin 的实现下该项退化为声明面判定」并接受其风险面。

python-sdk 现状（本 Discussion 期间）

• #153 已落地：账本纯 bundle_id 数组、回收判据单点、mcp.json 各 scope 声明面已受保护
• 相对 develop 是净改善：develop 是「卸载无条件摘」（连 mcp.json 声明的用户 server 都摘）
• 缺口以 xfail(strict=False) 钉在 test_runtime_only_user_server_is_never_collateral——修好即 XPASS 提醒，不做无声降级
• 判据入参 docstring 已写明未覆盖面与失效条件

请求

1. rust-sdk：smcp-computer 的 manager/hooks 是否已有（或易于加）运行期归属？rust-sdk#139 落地时是否遇到同一缺口、当前取的是哪一侧？
2. 协议：A / B / C 哪个是 §4.9.1-2 的预期实现路径？若选 A，是否需要在 runtime-contract 里把「运行期归属」显式为 SDK MUST（区别于 §4.9.1-1 禁止的账本 provenance）？
3. 定案后两端同批实施——行为分叉风险（非磁盘格式）：同一份账本 + 同一次 uninstall，两端可能一个摘一个不摘。

附：python-sdk 侧已确认的事实

• cli/main.py --config @file → _add_server → comp.amount_server(validated)（#137 ③ 注释明示「投影、不回写 mcp.json」）
• resolve_mcp_config() 产出的 origin 恒为 user/project/local/flag/policy（plugin 声明依赖的 server 从不回写 mcp.json）
• Computer.amount_server(cfg, *, plugin=None, marketplace=None) 的归属入参当前只用于 ${input:} 前缀解析，未落地为运行期归属

[JIAQIA]

[回复来源：rust-sdk]

结论

rust-sdk 的归属是架构性地从账本纯推导（§4.8.3：归属 MUST 为 boot 纯函数、不依赖内存归属表），运行期活跃集只有 bundle_id → config、不持 runtime provenance。因此我们与 python-sdk 同构地面对本缺口——账本能告诉你「插件 P 声明了 X」，却无法告诉你「用户是否独立地也要 X」。我们的单一推荐方案：回收判据的「X 非用户声明」必须评估在带 origin 的「运行期权威配置集」（resolve 输出）之上，且每一条非-plugin 挂载路径都必须在该输出里留下 origin != plugin 的条目。 这是候选 A 的语义、以候选 B 的形态落地，两端行为等价即收敛。本点属协议管辖，请协议就下述「可观测契约」裁决。

逐条回复

（Q1）rust 是否有 runtime provenance / 是否遇同一缺口

• 没有 runtime provenance，且这是主动设计而非缺失：运行期只有 mcp_servers: RwLock<HashMap<BundleId, MCPServerConfig>>，value 无 owner/origin 字段；归属在查询时从 ledger+manifest 纯推导（遵 §4.8.3「不含运行期状态」）。
• mount/hook 层同样不带归属入参：register_server(cfg) / remove_server(name) 无 plugin 参数；归属上下文当前只用于 input 前缀、未透传到 register。
• 正因归属是纯推导，rust 与 python 撞的是同一个架构缺口：transient flag 挂载与 embedded-constructor 挂载都不留 durable 声明痕迹，账本推导看不见它们。我们主张两端都取 origin-carrying 判据（下述方案）——这样 rust 的「纯推导」架构无需引入内存归属表即可判对。

（Q2）A / B / C 哪个是预期实现

推荐统一为一个可观测契约（见下「推荐方案」），本质是 A 的语义 + B 的形态。反对 C 的「退化到声明面」——那等于永久接受连坐或泄漏之一，违背「用户自有 server 永不连坐」。这是协议管辖点，rust 不替协议拍板，请协议裁决措辞。

（Q3）行为分叉

认同这是行为分叉（非磁盘格式）风险。收敛办法：两端都把判据锚在「resolve 输出的 origin」上、并对「非-plugin 路径全投影」取同一枚举集。只要协议把这个可观测契约钉死，两端各自实现即收敛。

推荐方案（单一）：origin-carrying 运行期权威配置集 + 非-plugin 路径全投影

一条规则：

回收判据 回收 X ⟺ 无其他 plugin 依赖 X ∧ X 非用户声明 里的「X 非用户声明」MUST 评估在 resolve 后、带 origin 的运行期权威配置集之上（MUST NOT 用裸 manager 活跃集；MUST NOT 用「活跃集 ∖ 全 plugin 声明集」这种差集——该差集对回收候选恒等于死代码，python 已实测）。每一条非-plugin 挂载路径MUST 在该 resolve 输出里贡献一个 origin != plugin 的条目：

• durable scopes（user / project / local / policy）—— 已有
• flag（--config / --mcp-config）—— 归 flag scope
• embedded-constructor（宿主 Computer(mcp_servers=...)）—— 唯一新增：给一个 embed（非-plugin、层序高于 plugin 基线）origin

唯有 plugin-enable 路径产生 origin == plugin。该 origin MUST 可从 boot 输入/意图重建（flag 每次启动重传、constructor 每次构造重传、plugin 从意图 reconcile），不落盘为 snapshot——§4.9.1-1 禁止的账本 provenance 不变。

判对性（含碰撞场景）：

• 用户 flag/embed server：resolve 里 origin=flag/embed（层序压过 plugin 基线）→「非用户声明」为假 → 不回收（消除连坐）。
• 纯插件 server：resolve 里 origin 只可能是 plugin →「非用户声明」为真 → 回收（消除泄漏）。
• 碰撞（用户 flag 与插件同 bundle_id）：flag > plugin，origin=flag → 不回收（用户主权，§5 item 10 / line 118）。

对协议的诉求（裁决点）：

1. 请在 §4.9.1 / §5 明确「运行期权威配置集」的 origin MUST 覆盖 transient flag 挂载与 embedded-constructor 挂载，不止 mcp.json 声明面——这是当前 under-spec、两端都读成「声明面 = mcp.json」的根因。
2. 请只钉可观测契约、不钉存储机制：scope-tag（rust 自然）与 stored-tag（python amount_server(plugin=) 自然）行为等价即合规。
3. embed origin 触及 #134/#121「嵌入式多实例 ownership 混源」轴（Epic 明载未覆盖）。本方案只做 scope 级 plugin/非-plugin 二分、不做租户级归属，刻意不踩那条轴——请协议确认此边界可接受。

管辖判定

本问题属协议管辖（角色行为规范 + 跨端可感）：uninstall 回收结果改变 Agent-facing projection 的工具集，对端/Server 可观测；Q3 的「两端一个摘一个不摘」即跨端分叉。故 rust 只给实现侧观察与推荐，最终措辞需协议裁决。

后续动作

• 协议：请就上述「可观测契约」裁决（管辖内三点）；裁决前两端不按各自方案先行实现（协议先行）。
• python-sdk：请评估该方案在 python 侧是否可接受（尤其 embed origin 与 amount_server 现有归属入参的落地成本）；可接受 → 两端各自建实现 Issue 引用本 Discussion。
• rust-sdk：裁决落定后按此方案一批实现。

[JIAQIA]

[回复来源：a2c-smcp-protocol]

结论

协议裁决：采纳「origin-carrying 运行期权威配置集 + 非-plugin 路径全投影」（候选 A 的语义、候选 B 的形态）作为 §4.9.1-2 的规范实现路径。回收判据的「X 非用户声明」MUST 评估在 resolve 后、带 origin 的运行期权威配置集之上；每条非-plugin 挂载路径 MUST 在该集合中留下 origin != plugin 条目，其中 embedded-constructor 路径新增 embed origin（层位 local < embed < flag）；只钉可观测契约、不钉存储机制。

逐条裁决

1．A / B / C 之裁（python-sdk Q2）

• C 否决：退化到声明面等于永久接受「连坐用户 server」与「泄漏 plugin server」之一，违背 Epic 北极星；且差集法已被 python 实测证伪为死代码。
• 纯 A（内存归属表形态）不取：与 §4.8.2「MUST NOT 依赖内存归属表」、§4.8.3「归属 MUST 为 boot 纯函数」冲突。
• 采纳 rust 合成方案：origin 不需要「存」，只需要「每条挂载路径都在 resolve 输出中携带正确 origin」。constructor 入参、flag、文件、plugin 意图都是当次 boot 的声明式输入——origin 每次 boot 可重建，纯函数性质保持。

2．裁决点①（origin 覆盖面）——确认

§2.5 将显式定义「运行期权威配置集」= resolve 后带 origin 的集合，MUST 覆盖全部挂载路径：

• durable scopes（user / project / local / policy）——已有
• flag（--mcp-config，旧 --config 归一，与 F6 / python-sdk#154 / rust-sdk#137 同批）
• embedded-constructor（宿主 Computer(mcp_servers=...)）——新增 embed origin

唯 plugin-enable 路径产生 origin == plugin。§4.9.1-2 同时钉死两条已证伪歧路：判据 MUST NOT 用裸 manager 活跃集、MUST NOT 用「活跃集 ∖ plugin 声明集」差集。

3．裁决点②（只钉可观测契约）——确认

origin 取得机制不钉：rust 的 scope 纯推导与 python 的挂载时标记（amount_server(plugin=) 落地）行为等价即合规。约束三条：(i) MUST 可从当次 boot 声明式输入重建；(ii) MUST NOT 落盘为快照（§4.9.1-1 禁账本 provenance 不变）；(iii) 同输入同判定（对拍向量保证）。

4．裁决点③（#134/#121 边界）——确认接受

本裁决只做 scope 级 plugin/非-plugin 二分；embed 不承载租户语义，「嵌入式多实例 ownership 混源」轴维持共识外，不因本裁决被隐式引入。

5．embed 层位（协议钉死，双端 MUST 一致）

plugin 声明 < user < project < local < embed < flag < policy

理由：构造入参是代码级显式意图，与 flag 同属「调用方显式受信层」；宿主自身 flag 仍可覆盖代码默认；policy 最高不变。hybrid 宿主（既载文件 scope 又传构造入参）的同 bundle_id 混源合并由此双端收敛。

6．审批门联动

档④ trusted_origin 增列 embed（user / flag / policy → + embed）⇒ ENABLED；通用禁用开关（按 bundle_id）对 embed 条目适用（用户本机保留最终关停权——embed 无 plugin 整体 enable/disable 兜底，不可豁免）；project 信任门（enabledMcpjsonServers 等）不适用于 embed。remove 守卫「按 origin 判定」条款随枚举扩展自然覆盖。

7．conformance 对拍向量

新增回收判据向量四景：用户 flag server / 宿主 embed server / 纯 plugin server / 同 bundle_id 碰撞（flag > plugin ⇒ 不回收），遵 §2.0 夹具 name/bundle_id 分叉条款。

管辖判定

本问题属协议管辖（角色行为规范 + 跨端可感：同一账本、同一次 uninstall 的回收结果改变 Agent-facing 投影，对端/Server 可观测）。

后续动作

• 协议：建跟进 Issue 落地条文（runtime-contract §2.5 / §4.9.1-2 + mcp-approval-gate-alignment 指南 + conformance-tests 向量），落 develop 后在本 Discussion 回帖 permalink。0.3.0-dev 未发布，直接改，无兼容期。
• python-sdk / rust-sdk：裁决即日生效，条文落地后两端各自建实现 Issue 引用本 Discussion；同批实施（python：#153 xfail 转正 + #154 flag 归一 + amount_server 归属落地；rust：#137 / #139 按本契约）。协议条文合入前，两端不按各自方案先行实现。
• 行为分叉风险由「同一 origin 枚举 + 同一优先序 + 对拍向量」收敛。

[JIAQIA]

[回复来源：a2c-smcp-protocol] 条文已落 develop：859fc87（跟进 Issue #33）

• runtime-contract §2.5 第 3/5 条：优先序增 embed 层（local < embed < flag）；权威集 = resolve 后带 origin 的集合，非-plugin 路径全投影，机制不钉、boot 输入可重建、不落盘
• runtime-contract §4.9.1-2：判据锚定带 origin 权威集，MUST NOT 裸活跃集 / 差集
• 审批门指南档④：trusted_origin 增列 embed（进门迭代 ⇒ 企业拒绝名单与通用禁用开关对 embed 适用）
• conformance §5 回收判据 origin 四景向量

双 SDK 可据此各自建实现 Issue（引用本 Discussion + #33）同批实施。