[V1110-PLUGIN] [P0·总纲] 1.11 首要任务：插件机制完善——十条拆解、依赖顺序与出口判据-xwcode-AtomGit

Open

[V1110-PLUGIN] [P0·总纲] 1.11 首要任务：插件机制完善——十条拆解、依赖顺序与出口判据 #131

kemengAdd on 4 days ago

kemengCollaborators

4 days ago Create

这一批解决什么

1.11 把「完善插件机制」列为首要任务。本 issue 是十条子任务的入口，只讲顺序与出口，不重复细节。

事实基线：audit/plugin-capability-2026-11-04/（主仓 master 已入库）。

一句话：插件目前拿到的全部能力 = 一张公告板＋一条网线＋一次性的配置纸条；八原语 3 真 / 2 空壳 / 3 未承载 / 6 类从未定义。

判断依据

只有 WASM 插件有能力提供各种服务，才会有人愿意开发。

反过来用：现在组织内唯一有完整源码的真实插件（xw-plugin-prompt-conventions，src/ 633 行）只用了 1 个导入，做的事是「往 prompt 塞一段配置文本」。这不是作者水平问题，是能力面决定的必然结果。九项能力对比（vs Skill / Hook / MCP server / 子代理）输九赢二，赢的两项里沙箱「有笼子无家具」、热路径「完全未兑现」。

十条

序	issue	级别	一句话
1	#122	P0	`permissions.filesystem` / `process` 零消费：兑现或移除＋ CI 判据
2	#121	P0	`spawn` / `effect` 空壳：实装或降级为响亮失败
3	#123	P0	新增 `xw:plugin/fs`（read/list/stat）
4	#124	P0	新增 `tools.call`（五约束，C-4 权限不继承为命门）
5	#125	P1	`config.get` ＋ `workspace.info`
6	#126	P1	`on-x` 三个挂点（绕开 kernel）
7	#127	P1	上游裁决：单工具执行口 `pub(super)`
8	#128	P1	MCP client 插件立为验收靶
9	#129	P2	判据 V-2：非实现者写出第二个插件
10	#130	P2	作者体验：脚手架＋人话错误

依赖顺序

第一批（止血＋能看，约 8 天）
  #122 ──► #123 ──► #125        三件套：声明不空转、能读工作区、能取配置
            │
  #121 ─────┘（定性先做，否则 #128 的会话保活无解）
  #126 独立并行（不依赖以上任何一条）

第二批（能用＋能管，约 4 天）
  #127（裁决）──► #124

出口
  #128 靶：MCP client 插件跑通 ⇒ 反证插件系统成立
  #129 / #130 收口

#122 必须先于 #123：否则 fs 落地后 permissions 仍是两套真源（声明面与实际放行不一致），等于把「声明空转」升级成「声明说谎」。

#124 不阻塞于 #127：C-1~C-5 的接口设计与实现可先做，只是「是否复用宿主完整管线」等裁决。若裁决为丙案（外部路径不走完整管线），必须在 #124 的台账里显式记录「hooks 未触发」。

出口判据（不做这三条，等于自己给自己发合格证）

#	判据	为什么不可省
E-1	非实现者写出第二个真实插件（`#129`）	只能证明「系统能跑」的判据都不算判据
E-2	MCP client 插件跑通，模型真能调起来（`#128`）	「注册成功」不等于「能用」，AC-5 不可省
E-3	删除 `net` 权限消费点 ⇒ CI 变红（`#122` V-5）	证明防退化判据本身有效

明确不在本批范围

把 xwcode 做成 MCP server 的 WASM 插件 —— 形态不成立：导出面固定 memory / xw_alloc / apply / tool_call，全仓 listen / bind / accept 零命中，apply 一返回上下文即消失，没有原语能让外部请求唤醒 guest。该方向由独立二进制 xuanwu-code/xwmcps 承载。
emit / waterfall 实装 —— waterfall 是 L3 性能边界，emit 缺消费者。#126 只做 on-x。
kv 持久化 —— L4，索引类插件的需求出现后再做。

关联

主仓 audit/plugin-capability-2026-11-04/README.md（§5 有同一张表）· 00-CAPABILITY_AUDIT.md（17 条事实）· 01-CAPABILITY_PROPOSAL.md（L0–L4 分档与 WIT 签名）

kemengCollaborators

3 days ago Comments：

[ar审核 2026-11-05] 结论：✅可认领开发。建议：km优先（建议仅负载均衡，任何人可抢，接单即开分支占位，comm同步防撞）。依赖：无。规范：一issue一分支，PR过L3；改门禁/契约/完成判据语义者ar复核diff。方向：插件总纲十条拆解依赖顺序，km认领；先读再动手，接口冻结后并行。