用途：评估第三方 pi 扩展，帮助用户为它选择合适的所有权模型，并给出与自身控制、维护和安全目标相符的具体接入方案。默认倾向：若扩展体积小、维护薄弱、很可能被定制或存在信任顾虑，优先把源码 vendoring 进用户仓库，而不是给已发布包打补丁。
主要能力：识别真实依赖与信任边界；在直接依赖、patch-package、内部 fork、vendored 副本之间给出建议；用户决定采用时产出可执行的导入与加固计划。核心观点：复制一层包装不等于拥有真实行为——若扩展通过 shell 调用其他 CLI、下载二进制、自动安装 npm 包或在运行时拉取代码，下游工具也属于真实信任边界，必须显式分析。
工作流：先弄清用户更看重安全审查、本地控制、低维护、易于跟进上游，还是组织级复用，并确认只要建议还是要把扩展导入仓库。随后检查包清单与扩展入口、pi 如何加载该扩展，识别运行时依赖、shell 调用、进程创建路径、安装或生命周期脚本、下载、自动安装提示、浏览器/二进制引导步骤及远程网络行为，区分可见包与真实依赖链。
选择模型：代码小、维护弱、很可能定制、或可审计性优先时选择 vendoring；多仓库或多人共用同一扩展且仍想有结构化上游同步路径时选择内部 fork；仍想保留上游包、改动小、补丁大概率为临时时选择 patch-package；仅当上游健康、可信、易更新且无需深度控制时选择直接依赖。patch-package 不适合作为安全方案，尤其当用户目标是移除对上游的信任、包维护差、需要持续产品化改动，或真实运行时行为位于另一个补丁无法消除的 CLI/二进制中。
pi 检查清单：pi.exec(...) 等进程创建路径（child_process、spawn、execFile、execa、Bun 进程辅助、包装脚本）；安装 npm 包、全局工具或运行时依赖的提示、生命周期钩子或安装脚本；浏览器或二进制下载；动态网络抓取；假定外部工具存在的清理钩子；暴露大量外部 CLI 面的宽泛透传命令；暴露 pi/TUI/typebox 耦合的 peer 依赖。若扩展包装了独立 CLI，要明确指出：包装层或许易于 vendoring，但被包装的 CLI 仍是真实运行依赖。
vendoring 导入清单：只复制确实需要的源文件（入口点及其引用的本地资源），不导入无关文档或工具；保留来源信息（上游仓库 URL、commit 或 release、导入日期、原始许可证、本地修改摘要）；删除或禁用自动安装流程，用显式人工步骤替代静默下载，要求已知本地二进制或单独审查过的内部包；重新评估剩余依赖边界，对仍存在的外部 CLI 或浏览器栈选择显式固定、一并 fork/vendor 或替换；适配本地约定（重命名、目录结构、日志、错误处理、文档）并保持实现简单；做最小验证，确认 pi 能加载本地扩展、跑通主路径冒烟测试，残留外部依赖时记录手动设置步骤。
限制与护栏：不得暗示 vendoring 一层薄包装就消除了被包装工具的风险；不要在用户要所有权与可审计性时把 patch-package 当安全方案；移除有意功能时须说明被丢弃的行为；复制代码不得忽略许可证；不要为小扩展过度引入重流程。许可证、具体价格、平台支持与官方安装命令等资料暂未提供。