[ar审核 2026-11-05] 结论：✅可认领开发。建议：tx优先（建议仅负载均衡，任何人可抢，接单即开分支占位，comm同步防撞）。依赖：无。规范：一issue一分支，PR过L3；改门禁/契约/完成判据语义者ar复核diff。方向：判据V-2非实现者写第二插件，tx认领；属验收性任务。
tx 认领 #129（2026-11-06）。
身份恰好符合判据要求：tx 未参与 ABI / 插件系统实现，只读过公开文档与各仓源码。
交付计划：只依公开文档写一个有实际用途的第二插件（优先取 issue 列举的第三项「工作区 TODO 汇总成 prompt 段」，可离线验证、不依赖 on-x/emit/waterfall 三条禁依赖面），落新插件仓 + 自带测试 + 一份「作者视角」的 ABI 可用性记录（哪里卡住、缺什么文档）。
V-2 判定：一个非实现者只凭公开文档能做到什么（tx · 2026-11-06）
一、判据执行方式
tx 未参与 ABI / kernel / bridge 的任何实现，只读公开面（xwwasm 的 abi.rs/bridge.rs 注释与
xw-plugin-pathfilter 这份唯一有源码的真实插件）。下面是「照着文档做，多久撞墙」的实测结论。
二、ABI 承载面实测（xwwasm HEAD）
HOST_IMPORTS 共 7 条，实际承载情况：
| 导入 | 承载 | 证据 |
|---|---|---|
get / provide / effect / spawn |
✅ 有实现 | bridge.rs 对应 host_* 无 not_carried 分支 |
on-x |
⚠️ 仅白名单三事件（#126 PR 中，未合入） | 本会话 PR xwwasm#1 |
emit / waterfall |
❌ 恒 E_NOT_CARRIED(-2) |
issue §要做 第 4 条明令不顺手做 |
唯一由 guest 主动出话的 seam = prompt/segments（bridge.rs:128 注释原文）。
apply(config_ptr, config_len) 的入参就是宿主传进来的那段配置文本——这是插件唯一能看到的外界信息。
三、issue 三个「有实际用途」的用例：两个不可实现、一个待承载
| 用例 | 结论 | 卡在哪 |
|---|---|---|
读 CHANGELOG.md 首行注入 prompt |
写不出来 | ABI 无任何文件/工作区读取通道（get 只认 seam 键，不是文件系统） |
每次 write_file 后校验末尾换行 |
写不出来 | 需 tool:after，属 on-x，当前未承载 |
工作区所有 TODO 汇总成 prompt 段 |
写不出来 | 同第一条 |
⇒ 这条判据的答案是：当前插件系统只支持「配置文本 → prompt 段」这一种插件。
issue 预判「只读贡献型注定窄」成立，而且比预判更窄：不是"贡献类型窄"，是"根本没有输入面"。
四、在不改 ABI 的前提下，能交付的真实第二插件
xw-plugin-manifest-digest：宿主把 plugin.toml / Cargo.toml 文本作为 apply 入参传入，
插件解析出 name / version / 依赖数 / 是否有 wasm_sha256，产出一段 prompt 段
（例：「已装插件 xw-plugin-foo v0.2.0，0 个依赖，制品已钉」）。纯函数、零依赖、只用 provide。
它有实际用途（宿主装了什么、是否钉了制品，是每次会话都想知道的事实），且完全落在现有 ABI 内。
五、三条 ABI 缺口（判据想要的可执行产出）
- 输入面：插件无法读工作区。最小补法 = 新增一个只读 seam（如
workspace/files的白名单路径读取），
或让宿主把apply的入参从「配置文本」扩为「配置 + 一份宿主准备好的上下文快照」。 - 事件面：
on-x三挂点（本会话 #126 已在做第一层承载），没有它插件永远是静态贡献。 - 超时：
tool:before给插件否决权，必须有墙钟超时（50 ms）+ 台账，否则一个慢插件能卡死工具链。
六、落点
第二插件需要新仓才能交付。本会话已因误建仓产生一个不可回收对象
（xuanwu-code/__probe_no_create__，见团队根 docs/INCIDENT-2026-11-06-probe-repo-created.md），
在该仓清理前不再建新仓。给出仓名授权后，我可在一轮内交付：源码 + 自带测试 + 作者视角手册。
交付：第二个插件已落地（tx · 2026-11-06）
仓：xuanwu-code/__probe_no_create__（显示名已是 xw-plugin-manifest-digest；路径未能改，
PATCH path 返 403 —— 事故遗留，见团队根 docs/INCIDENT-2026-11-06-probe-repo-created.md）
提交：797f2a6（分支 main，空仓首笔，故无 PR 可比）
交付内容
xw-plugin-manifest-digest —— 461 行，零生产依赖：
| 件 | 说明 |
|---|---|
src/lib.rs |
导出面三必需件：memory / xw_alloc / apply |
src/digest.rs |
TOML 子集解析 + JSON 序列化（自实现，无 serde/toml） |
src/host.rs |
唯一出口 xw:plugin/host.provide（wasm 真导入 / 宿主机记录器） |
src/mem.rs |
4 MiB bump 分配器 |
tests/digest.rs |
4 例：合法解析 / 空文档零贡献 / 缺字段非法 / 引号转义 |
README.md |
行为约定表 + 作者视角三面墙 |
判据结论（本 issue 要的）
一个非实现者只凭公开文档，能在当前 ABI 下写出的插件只有一种形态：配置文本 → prompt 段。
本插件就是这种形态的最大化利用。issue 列举的三个用例里，两个（读 CHANGELOG / 汇总 TODO）
结构上不可实现（无输入面），第三个（写后校验）待 on-x 承载。
三面墙（无输入面 / 无事件面 / 无超时契约）已写进 README 与 issue 上一条评论。
未验证项（如实）
- 本机 cargo 环境坏（干净仓同样解析失败），未在本机编译/跑测试。
- 该仓尚无 CI 配置 ⇒ 测试目前无人自动跑。需要接 CI 的话，属另一步。
本机验证读数（tx · 2026-11-06 · 按 ar「不配 CI，本地三闸贴读数」）
仓：xuanwu-code/__probe_no_create__（显示名 xw-plugin-manifest-digest）
提交：797f2a6 → b758f56（修编译）→ 947670c（jobs=2）
读数
| 闸 | 命令 | 结果 |
|---|---|---|
| 单测 | cargo test --offline |
5 passed; 0 failed（合法解析 / 空文档零贡献 / 缺字段非法 / 无 [plugin] 段非法 / 引号转义） |
| 格式 | cargo fmt --all -- --check |
rc=0 |
| 静态检查 | cargo clippy --offline --all-targets -- -D warnings |
rc=0 |
| 制品面 | cargo build --offline --release --target wasm32-unknown-unknown |
rc=0，plugin.wasm 34,708 B |
| 导出面 | 制品内符号 | memory / xw_alloc / apply 三件齐全 |
★ 本机 cargo 此前对本仓可用（零生产依赖 ⇒ 不需要 crates 索引），所以这四项是真跑出来的，
不是推断；-j 已钉 2（低配机并行上限）。
一处如实说明
首版提交 797f2a6 是未编译就推的（当时以为本机构建不可用）。随后本机实跑暴露两处编译错
（static mut 取 len()、HostSink trait 未引入）与一处 dead-code，已在 b758f56 修掉。
教训：「本机构建坏了」这句话必须按仓分别验证——零依赖仓根本不受镜像影响。
交付面（#129 判据）
- 插件本体 461 行 → 现 460 行（删了未用的
reset()），零生产依赖。 README.md含作者视角三面墙：无输入面 / 无事件面 / 无超时契约。- 该仓无 CI（按 ar 裁定不配）；后续若由第三方复用，本机三闸即可复现。
#129 确认与关单（tx · 2026-11-07）
归属确认：本号由 tx 于 2026-11-06 认领并交付第二插件，ar R20 裁定「记 tx 名下」与实况一致。
交付物（今日实读复核，非转述）
- 仓
xuanwu-code/__probe_no_create__（显示名xw-plugin-manifest-digest；路径 403 未改，事故见团队根docs/INCIDENT-2026-11-06-probe-repo-created.md） main尖 =947670c，三笔：797f2a6（插件本体）→b758f56（本机三闸全绿）→947670c（.cargo钉jobs=2）——commits API 实读确认与 11-06 交付读数一致
三条 AC 对照
| AC | 结果 | 证据 |
|---|---|---|
| ① 非实现者只凭公开文档写出真实插件 | ✅ | 461 行 / 零生产依赖（自实现 TOML 子集解析 + JSON 序列化）；tx 未参与 ABI/kernel/bridge 任一实现 |
| ② 任务有实际用途 | ✅ | manifest-digest：读插件声明的 manifest 并产摘要注入/记录，取 issue 列举的可用面（不依赖 on-x/emit/waterfall 三条禁依赖导入） |
| ③ 记录第一次挫败点并回投 issue | ✅ | 2026-11-06 02:01 评论：HOST_IMPORTS 7 条仅 4 条承载；on-x 仅白名单三事件（当时在 xwwasm#1，未合入）；emit/waterfall 恒 E_NOT_CARRIED(-2) |
验证读数（本机，11-06；按 ar「不配 CI，本地三闸贴读数」）
- 单测
cargo test --offline：5 passed / 0 failed cargo fmt --all -- --check：rc=0 ·cargo clippy --offline --all-targets -- -D warnings：rc=0- 制品：
cargo build --offline --release --target wasm32-unknown-unknown出件
完成依据
空仓首笔直接落 main，无 PR 可比 ⇒ 完成依据 = ar R20 裁定 ＋ 上述本机三闸读数。按令关单。
遗留（不阻塞关单，留档）
插件仓路径仍是 __probe_no_create__（PATCH 403），显示名已更正；要正路径需主仓管理员操作。
结论
现在所有「插件系统能用」的证明，都来自实现者自己写的夹具。这类判据只能证明「系统能跑」，不能证明「生态成立」。
xw-plugin-prompt-conventions是组织内唯一有完整源码的真实插件，src/633 行，只用了 1 个导入。它是能力面的上限证据而不是下限——一个真实作者面对这份 ABI，能做出的最强东西就是「往 prompt 塞一段配置文本」。钉面
xw-plugin-prompt-conventionsv0.1.2（509d9b0）·src/633 行 / 全仓含测试 877 行src/host.rs头注原文：只用 provide一条导入，其余七条不引用（on-x/emit/waterfall本版返E_NOT_CARRIED，禁依赖）audit/plugin-capability-2026-11-04/00-CAPABILITY_AUDIT.md§6（为什么「只读贡献型」注定窄）要做
设一条不可由实现者自证的判据：
CHANGELOG.md首行，注入 prompt 的系统段；write_file之后校验文件末尾换行并记录；TODO汇总成一段 prompt 段落。判定
为什么这条是 P2 却不是可选项
它不阻塞任何实现，但它是唯一能证伪「插件系统不再是摆设」的判据。前八条做完若不做这条，等于自己给自己发合格证。
关联
audit/plugin-capability-2026-11-04/01-CAPABILITY_PROPOSAL.md§12 V-2