诚实的代码库运行按钮 — 有证据，而不是感觉。人工诊断。机器证明。一个引擎。 bootproof up https://github.com/dubinc/dub 远程源： https://github.com/dubinc/dub.git 克隆保留在： .bootproof/remotes/github.com/dubinc/dub-*/repo 基于推理（证据基础）应用程序：是的 包管理器：pnpm.15.9 选择的命令：pnpm dev ✗ 未验证 — 远程代码执行被阻止 BootProof 拒绝的原因：远程代码库是不可信的代码，并且需要明确的同意。 bootproof up . --provider local --unsafe-local --install ✓ 安装：依赖项已安装 ✓ 启动应用程序：应用程序进程已启动并被监督 ✓ 健康：在 http://localhost:3333 观察到 HTTP 200 ✓ 启动成功 — HTTP 200 在 http://localhost:3333 证据： .bootproof/attestation.json BootProof 检查本地代码库，构建基于证据的运行计划，仅执行它可以证明的内容，观察 HTTP 健康状态，并为成功或失败写入签名证明。它不会让每个代码库都变成绿色。这将失去意义。没有证据，就没有绿色勾选。一个引擎。两个接口。 人工运行： bootproof up . 他们得到一个诊断和一个运行手册。 机器运行： bootproof up . --ci --json 他们得到一个签名裁决和一个确定性的退出代码。 同一个引擎支持两者。 它给人类的是什么 失败的运行仍然是有用的：未验证 — package_manager_version_mismatch 发生了什么：该代码库需要 pnpm 10.24.0，但当前环境有 pnpm 9.15.4。 BootProof 拒绝的原因：无法信任不同包管理器版本的依赖项安装。 安全的下一步：运行 corepack enable && corepack prepare pnpm@10.24.0 --activate，然后重新运行 BootProof。 证据： .bootproof/attestation.json BootProof 区分诊断和证明。 检测 Python、Flask、React、Celery、Go 或单体仓库并不意味着 BootProof 声称对该技术栈提供全面的编排支持。 它给予机器的内容 --json 将精确发出一个 bootproof/result/v1 对象到 stdout：{ "schema" : " bootproof/result/v1 " , "booted" : false , "healthVerified" : false , "failureClass" : " dependency_install_skipped " , "attestationPath" : " .bootproof/attestation.json " , "inference" : {}, "plan" : {}, "observed" : [] } --ci 禁用颜色和互动输出。 退出代码是确定性的： 0 : booted === true 和 healthVerified === true 1 : 每次拒绝、模糊、安装失败、服务失败、应用程序失败或健康失败 快速开始 针对本地代码库运行： cd /path/to/repository npx bootproof up . 主机执行可以明确选择： npx bootproof up . --provider local --unsafe-local 仅在意图时运行依赖项安装： npx bootproof up . --install 解释并验证签名结果： npx bootproof explain .bootproof/attestation.json npx bootproof verify .bootproof/attestation.json 针对公共 GitHub 代码库运行： npx bootproof up https://github.com/user/repo BootProof 将无需凭证的 HTTPS GitHub URL 克隆到 .bootproof/remotes/ 并保留此克隆，以便其证据和任何生成的文件继续存在。它会检查克隆，但在主机执行明确被确认之前拒绝执行远程代码： npx bootproof up https://github.com/user/repo --provider local --unsafe-local 在使用该确认之前查看推断的命令。 仅在您也打算运行依赖项安装及其生命周期脚本时添加 --install。 远程 --dry-run 在克隆之前被拒绝，因为干运行承诺不写入任何内容。 从此源代码库工作的贡献者可以使用 npm ci、npm run build 和 npm link。这些步骤对 npm 用户来说不是必需的。 诚实合约 BootProof 有意受到限制：没有观察到健康信号就没有验证启动；跳过的步骤没有成功渲染；没有虚构的秘密；不写入 .env 、 .env.local 、 .env.development 或 .env.production；没有静默项目修补；当代码库模糊时没有猜测工作区；没有声称生成的脚手架存在，除非它是书面签名失败的证明；拒绝和执行失败的原始本地证据保留在证明中；没有遥测或隐藏证据上传。请参阅 docs/HONESTY_CONTRACT.md 。 当前能力 BootProof 当前提供： Node 包管理器和启动命令推断；Python/Flask 和 Go/Node 混合检测；单体仓库候选排名；Docker 服务依赖项检测和脚手架；根据代码库证据和应用日志从本地发现健康候选；分类失败；签署的 Ed25519 证明；严格的 JSON 和失败关闭的 CI 输出；已编辑的注册条目导出。 检测比编排更广泛。例如： 检测类似 Superset 的 Python/Flask/React/Celery 代码库，然后诚实拒绝，原因是 python_flask_setup_required 。 类似 Grafana 的 Go/Node 混合物被检测到，但不会假装前端监视器就是整个应用程序。 在选择特定工作区之前，拒绝并行单体根命令。 写入的文件