「这个仓库说能跑，我来试试。」——结果报错、缺依赖、版本不匹配，一肚子火。bootproof 想解决这个问题：不给「虚假的绿标」，只给「有证据的结论」。
它怎么工作的
bootproof 会先「诊断」本地仓库：识别包管理器、start 命令、可能的健康检查端点，再结合 Docker 服务依赖等因素生成一份证据化的执行计划。执行时，它只运行计划内能自证合理的步骤，然后观察 HTTP 健康状态，写入一份 Ed25519 签名的证明文件（attestation），记录运行了什么、看到了什么结果。
成功和失败都有证明。失败时工具不假装通过，而是给出分类失败原因和安全的后续操作建议。例如检测到版本不匹配，会提示「运行 corepack enable && corepack prepare pnpm@10.24.0 --activate」；检测到 Flask 项目但缺少 setup 步骤，会诚实拒绝并说明原因。
远程仓库：默认不信任
直接从 GitHub URL 拉取代码时，bootproof 会克隆到 .bootproof/remotes/ 但拒绝执行，直到用户明确确认本地运行并加上 --unsafe-local --install。它不承诺 dry-run，因为在克隆前 dry-run 就已违反「不写文件」的原则。
两种用法，同一个引擎
人类开发者运行 npx bootproof up . 得到诊断报告和可操作建议；CI 环境加上 --ci --json 获得结构化结果和确定性的退出码（0=健康验证通过，1=任何拒绝或失败）。--json 输出严格遵循 bootproof/result/v1 schema，保证机器可解析。
设计约束：不做什么
工具刻意限制了功能边界：不伪造成功、不写入 .env 类文件、不打补丁、不猜测 monorepo 结构、不上传遥测数据。所有证据保留在本地 attestation 文件中，公开仓库也能保持隐私。
当前支持 Node 包管理器推断与命令推断、Python/Flask 与 Go/Node 混合项目检测、单仓库候选排序、Docker 服务依赖发现、localhost 健康端点识别，以及十几种分类失败类型（如 python_flask_setup_required、postgres_auth_env_missing）。本地 Ed25519 签名的证明属于「开发者本机证据」，比企业 CI/OIDC 签名级别低，工具明确告知这个区别，不会混淆。
本质是一个「说清楚到底能不能跑」的验证器——没有证明，就没有绿勾。
编注：信源为 GitHub 项目 README 页面，bootproof 尚处早期阶段，功能边界和支持栈在实际使用中可能逐步扩展。