社区包风险收据：只读评估应由独立插件、Skill 还是 OpenPI 承担？

[tt-a1i]

Pi 社区包的价值很大，但“看过 README”“源码来自 GitHub”“扫描没有命中”“装上的就是审过的版本”是四件不同的事。这次阅读 pi-vetter 后，值得讨论的方向是：让用户拿到一份绑定具体包产物的只读风险收据，继续由 Pi 原生命令拥有安装、更新和卸载。

目前 OpenPI 没有通用社区包安装器，本帖不提议新增安装工具，也不恢复已经移除的包推荐逻辑。

可以学到什么

固定来源：pi-vetter@7e620ca，源码 manifest 为 0.4.1、MIT；Pi peer 声明为 *。本轮没有安装或运行这个包，声明范围不等于实际兼容证明。

• 引擎 把候选与基线产物摘要一起放入缓存身份，记录逐文件摘要，避免“新安装评估”与“从旧版本更新”的结论混用。
• 规则聚合 保留扫描器未完成的事实；证据不完整不能得到 ALLOW。对 OpenPI 来说，更适合直接呈现 unknown/incomplete，避免把 ALLOW 当成安全担保。
• 安装收据 绑定精确版本，执行前核对 registry 与 integrity，安装后区分缺失、变化和额外文件。后验对比只能发现漂移，不能阻止已经执行的生命周期脚本。
• 来源扫描 尝试验证 attestation；无签名、无法验证、验证失败与声明仓库不一致是不同结果。仓库字段或发布者名称一致本身不是签名证明，也不证明代码行为安全。

需要决定的产品边界

最小实验可以只接收用户明确指定的 npm:name@version，输出：

• 固定来源、版本、registry、integrity、许可证证据、Pi manifest 与 peer 范围；
• 相对已知基线变化的依赖、生命周期脚本、extension/tool/skill 入口；
• 每项检查的 observed / not checked / unavailable / conflict；
• 执行身份范围：会加载到 parent、in-process child，还是仍无法确认；
• 收据对哪个摘要有效，包升级后哪些结论失效。

不读取用户 Session、凭据或私人配置来“增强评分”，不运行候选代码，不自动安装或 reload，不给包一个笼统的安全分数。第三方扫描服务会带来请求、费用和包名披露，应在接入前单独决定。

最小可证伪实验

先用合成包与公开包快照验证：同一名称换版本、基线变化、registry 不同、缺签名、签名无法验证、扫描超时、tarball 上限、许可证未知、manifest 入口缺失、Pi peer 不覆盖当前版本。上述情况必须留下具体证据状态，不能显示“安全兼容”。确认有足够决策价值后，再决定是否只保留一份 Skill/维护者研究流程，还是增加现有诊断面的只读入口。

希望讨论的问题

1. 哪几项证据会实际改变我们采用一个社区包的判断？许可证、入口/工具变化、生命周期脚本和 child 兼容是否已经足够？
2. 这些工作由独立的 pi-vetter、一个 Skill，还是 OpenPI 现有诊断面承担更合适？
3. 是否需要保存收据？若保存，哪些内容可以公开，保留多久，如何明确结论已随版本失效？

#169 已定义外部能力兼容边界；本帖讨论其之前的具体产物评估，不重建 provider registry。过去 社区包审计 中的发布卫生问题不能直接当作当前缺陷；这轮新增的是版本绑定、证据不完整与安装产物漂移的可观察性。

研究记录：Pi 社区能力研究与候选清单（2026-09-08）。源码证据、运行验证与采用决策分别记录。

[tt-a1i]

2026-09-09 源码复读（/tmp clone，未 pi install、未运行）。本地记录：docs/research/EXPERIMENT_VETTER_PROVENANCE_2026-09-09.md。

冻结：jesset/pi-vetter@7e620ca（manifest 0.4.1，MIT，peer *）。对照 OpenPI a9b40f0。

安装所有权仍在 Pi，不在评估器。 /vet 只读。/vet-install 批准后走的是 exec("pi", ["install", "npm:<name>@<version>"])（src/install/gated-installer.ts），再按 ADR-0003 默认把 settings 还原成未 pin 的 npm:<name>。这不是第二套 installer。

源码对得上正文里的收据形状：

• 缓存身份 = name@version + baseline + candidateIntegrity|baselineIntegrity（src/core/engine.ts cacheKey），避免「新装」和「从旧版本更新」串台。
• 规则驱动 ALLOW/ASK/DENY；已启用 scanner 未完成 → 封顶 ASK，DENY 不降级（src/core/rules.ts，ADR-0001/0002）。ALLOW 只表示没找到信号。
• provenance 区分无 attestation / unverifiable（npm publish key 不在公钥根）/ 验签失败 / 声明仓库与证书不一致 / verified（src/scanners/provenance.ts）。仓库字段字符串相等不是签名。
• 安装前 registry 必须等于 vetting registry，integrity 必须未变；安装后逐文件 sha256 对比是 detection, not prevention（lifecycle scripts 已经跑过）。
• 报告 appendEntry，不进 LLM context。git/local 跳过并披露。

OpenPI 本 checkout 唯一会写包 settings 的助手是 /openpi-setup 的固定身份 npm:pi-intercom。不提议通用安装器，不新增第二条配置入口。第三方 VT/Socket 默认关（费用 + 包名披露），接入前单独决定。