bootproof/bootproof
GitHub: bootproof/bootproof
BootProof 是一个零信任的仓库启动监督器，通过观察真实健康状态并生成签名证明来解决代码「能不能真正跑起来」的可验证性问题。
Stars: 6 | Forks: 0
# BootProof
[](https://github.com/bootproof/bootproof/actions/workflows/ci.yml)
[](https://github.com/bootproof/bootproof/actions/workflows/receipt-gate.yml)
BootProof 只回答一个问题：**这个仓库真的启动了吗？** 不是“有没有执行过某条命令？”不是“Docker 是否显示容器已启动？”也不是“AI agent 是否声称成功了？” BootProof 会检查仓库，构建一个基于证据的运行计划，只执行它能够证明合理性的操作，观察真实的健康状态，并为成功或失败写入已签名的证明。没有证明，就没有绿勾。
--receipt` 生成你自己的回执。
--provider local --unsafe-local --install --receipt
# 或使用 standalone MVP engine（用于开发/测试）
node scripts/bootproof_up.mjs fixtures/real-booting-app --label "real-booting-app"
# 从 MVP captures 重新生成 Living Receipt HTML
node scripts/build_living_receipt.mjs \
scripts/records/real-booting-app.json \
scripts/records/real-slop-app.json \
--out assets/living-receipt.html
# 运行 smoke test（验证 native 和 fallback paths）
node scripts/verify_living_receipt.mjs
```
活回执内置了 PLG 钩子：首次访问者横幅、“复制 Markdown 徽章”按钮、“下载此文件”按钮以及页面级别的 CTA。请查看 [`assets/bootproof-badge-template.md`](assets/bootproof-badge-template.md) 获取徽章代码片段，以及 [`docs/LAUNCH_PLAYBOOK.md`](docs/LAUNCH_PLAYBOOK.md) 了解分发流程。
## 为什么需要 BootProof
每位开发者都熟悉这个循环：
```
git clone some/repo
npm install
npm run dev
```
然后现实给你沉重一击。
Node 版本不对。pnpm 版本不对。缺少 Java。缺少 Clojure。Docker 在运行，但服务状态并不健康。Postgres 存在，但角色不存在。缺少 Redis。迁移失败。应用启动了，但没有任何响应。容器“已启动”，但产品完全无法使用。AI agent 自信地宣称“完成”，仅仅因为某个进程启动了。
那不是证明。
BootProof 之所以存在，是因为仓库的引导过程不应依赖于期望、终端考古学或虚假的绿勾。
## 问题所在
现代仓库已不再简单。
一个仓库可能包含：
- 多个工作区
- Docker Compose 服务
- 前端和后端应用
- 隐藏的 runtime 需求
- 包管理器版本限制
- 生成的资产
- 数据库迁移
- 健康检查 endpoint
- 未公开的本地环境假设
README 可能很有用，但它不是证明。
终端命令可能很有用，但它不是证明。
模型回复可能很有用，但它不是证明。
BootProof 将仓库启动转化为一条证据链。
## 核心理念
BootProof 将**活动**与**证据**区分开来。
| 弱信号 | BootProof 期望的替代方案 |
|---|---|
| 命令已退出 | 观察到的健康状况 |
| 进程已启动 | 可访问的 endpoint |
| 容器正在运行 | 服务真正做出响应 |
| README 声称其有效 | 仓库证据 + runtime 证明 |
| AI 声称已完成 | 签名的证明 |
| 某个工作区做出了响应 | 选定应用/工作区的证明 |
如果一次失败的运行能告诉你真相，那它依然是有用的。
```
✗ NOT VERIFIED — package_manager_version_mismatch
What happened:
The repository requires pnpm 10.24.0, but this environment has pnpm 9.15.4.
Why BootProof refused:
The dependency install cannot be trusted with the wrong package manager version.
Safe next step:
Run corepack enable && corepack prepare pnpm@10.24.0 --activate, then rerun BootProof.
Evidence:
.bootproof/attestation.json
```
可预见的失败也是一种特性。
## 在公开 Git 仓库上尝试
BootProof 可以检查来自 GitHub、GitLab、Bitbucket 和 Codeberg 的公开 HTTPS 仓库。
```
npx bootproof up https://github.com/dubinc/dub
```
远程仓库是不受信任的代码，因此 BootProof 会先进行检查，并在你明确选择加入之前拒绝执行。
```
Remote source: https://github.com/dubinc/dub.git
Clone retained at: .bootproof/remotes/github.com/dubinc/dub-*/repo
Inference
application: yes
package manager: pnpm
selected command: pnpm dev
✗ NOT VERIFIED — remote_code_execution_blocked
Why BootProof refused:
Remote repositories are untrusted code and require explicit consent.
```
要在本地运行远程代码，你必须显式声明：
```
npx bootproof up https://github.com/dubinc/dub --provider local --unsafe-local --install
```
BootProof 绝不静默执行远程代码。
## 成功运行时的表现
```
✓ install: dependencies installed
✓ start-app: app process started and was supervised
✓ health: observed HTTP 200 at http://localhost:3333
✓ BOOTED — HTTP 200 at http://localhost:3333
Evidence:
.bootproof/attestation.json
```
只有当 BootProof 观察到健康证据时，仓库才会被标记为 `BOOTED`。
仅仅进程启动是不够的。
成功安装是不够的。
启动 Docker 容器是不够的。
命令执行完毕也是不够的。
## BootProof 为人类提供什么
人类可以获得可读的诊断结果：
```
NOT VERIFIED — workspace_ambiguous
BootProof detected a root command that starts multiple workspaces in parallel.
Choose a specific application with --workspace ; one responding workspace
is not proof that the whole repository booted.
```
示例：
```
npx bootproof up . --workspace apps/studio
```
BootProof 旨在让失败变得清晰易读。
它应该告诉你问题是否是：
- 包管理器版本不匹配
- 跳过了安装
- 缺少 runtime
- 模糊的工作区
- 不支持的编排
- 端口被占用
- 服务失败
- 应用启动失败
- endpoint 不健康
- 健康检查超时
## BootProof 为机器提供什么
`--json` 仅输出一个 `bootproof/result/v1` 对象：
```
{
"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` | 拒绝执行、存在歧义、安装失败、应用失败、服务失败或健康检查失败 |
这使得 BootProof 非常适用于 CI、agent 工作流和仓库质量门控。
## 真实仓库证据
BootProof 已经在各种真实仓库中进行了测试，包括小型应用、monorepo、大型平台和多服务技术栈。
重点不在于让每个仓库都变绿，而在于得出正确的判定。
| 仓库 | 结果 | 证明了什么 |
|---|---|---|
| `dubinc/dub` | `NOT VERIFIED — remote_code_execution_blocked` | BootProof 检查了仓库，但未经明确同意拒绝执行远程代码。 |
| `makeplane/plane` | 有用的 monorepo 路径 | BootProof 处理了一个更复杂的工作区风格仓库，并产生了可操作的证据。 |
| `airbytehq/airbyte` | 拒绝直接编排，随后进行外部验证 | Airbyte 需要 `abctl`、Kind、Helm 和明确的本地路径。BootProof 拒绝假装普通的命令就足够了，随后验证了外部的健康 endpoint。 |
| `gitlabhq/gitlabhq` | 手动启动循环暴露了隐藏的环境假设 | GitLab 展示了为什么大型仓库需要证据链，而不是对 README 的盲目乐观。 |
| `metabase/metabase` | 后端健康检查通过，前端缺失 | Metabase 展示了“后端存活”与“完整 UI 启动”之间的区别。 |
| `supabase/supabase` | `workspace_ambiguous`；手动 Compose 平台启动 | BootProof 正确地拒绝了虚假的全 monorepo 绿勾。官方的 Docker Compose 路径成功启动了核心服务，证明了显式全平台 compose 模式的必要性。 |
失败不会被隐藏，也不会被重新标记为受支持。
证据依然是证据。
请查看 [docs/REAL_REPO_EVIDENCE.md](docs/REAL_REPO_EVIDENCE.md)。
## Supabase 示例：为什么诚实的失败很重要
一次全新的针对 `supabase/supabase` 的 BootProof 运行检测到了：
```
stack: make-driven, node-frontend, docker-compose
repo compose: docker/docker-compose.yml
workspaces: apps/studio, apps/www, apps/docs, packages/*
selected command: make dev
```
BootProof 拒绝执行：
```
✗ NOT VERIFIED — workspace_ambiguous
The root command starts multiple workspaces in parallel.
One responding workspace would not prove that the whole repository booted.
```
这种拒绝是正确的。
通过 Supabase 官方的 Docker 路径进行的手动跟进证明了该平台路径：
```
cd docker
cp .env.example .env
docker compose up -d
```
诸如 Kong、Studio、DB、Auth、REST 和 Pooler 等核心服务报告为健康/正在运行，并且 `localhost:8000` 返回了 Kong/API 响应。
教训在于：
## Airbyte 示例：外部验证
Airbyte 正确地超出了 BootProof 的直接编排边界。
BootProof 拒绝执行，而不是假装普通的 Gradle、Make 或 Compose 命令就足够了。文档记录的本地路径需要 `abctl`、Kind 和 Helm。人类按照该运行手册启动了应用程序。
随后 BootProof 能够在不声称自己启动了 Airbyte 的情况下，验证外部的健康 endpoint。
```
bootproof verify-url http://localhost:8001/api/v1/health
```
外部验证意味着：
```
This endpoint responded.
BootProof did not orchestrate the startup.
```
这种区别至关重要。
## 验证证明：签名者层级
签名验证会报告三种本地签名者层级之一：
- `this machine`：制品由 `~/.bootproof/signer.json` 签名；
- `known`：签名者已明确固定在 `~/.bootproof/known_signers.json` 中；
- `UNKNOWN`：签名完整，但这仅能证明完整性，且签名者不受信任。
未知的外部签名者永远不会被自动固定。要故意信任一个签名完整的外部签名者，请检查打印出的 SHA-256 SPKI 指纹并运行：
```
npx bootproof verify proof.json --trust-signer
```
在 CI 门控中使用 `--require-known-signer`。当验证目标为仓库目录时，BootProof 还会将证明的 commit 与仓库当前的 `HEAD` 进行比较；`--strict` 会在遇到未知签名者或 commit 不匹配时失败。有效的签名能证明制品在签名后未被篡改。但它本身并不能证明是谁生成了它。
## agent 在环模型
BootProof 是为人类和 AI agent 都会接触仓库的世界而构建的。
预期的循环是：
```
Diagnose
→ Classify
→ Plan
→ Risk-classify
→ Approve
→ Execute one step
→ Verify
→ Receipt
→ Repeat
```
AI 可以建议。
人类可以批准。
BootProof 负责证明。
完全自动化的循环尚未实现。如今，BootProof 提供了四种诚实的模式。
### 1. 直接编排
```
bootproof up .
```
BootProof 推断出一个受支持的本地运行路径，在选定的安全边界内执行它，观察健康状况，并写入证明。
不受支持或存在歧义的编排将被拒绝。
### 2. 外部验证
```
bootproof verify-url http://localhost:8001/api/v1/health
```
BootProof 观察到由 BootProof 外部启动的服务。成功的证据会被归类为外部验证，且绝不会声称是 BootProof 启动了该应用。
### 3. Agent 规划
```
bootproof plan-agent .
```
Boot 会编写一份确定性的、经过风险分类的计划和一份经过脱敏处理的本地回执链。它不会执行候选操作，且规划绝不会被计入成功。
### 4. 确定性修复
```
bootproof fix .
```
BootProof 将确切的已知失败映射到确定性的修复操作。修改类命令和补丁需要明确的批准。验证将决定故障是否取得了进展或应用程序是否已成功启动。
请查看：
- [docs/AGENT_IN_THE_LOOP.md](docs/AGENT_IN_THE_LOOP.md)
- [docs/AGENT_RUN_RECEIPTS.md](docs/AGENT_RUN_RECEIPTS.md)
- [docs/DETERMINISTIC_REPAIR_SAFETY_MODEL.md](docs/DETERMINISTIC_REPAIR_SAFETY_MODEL.md)
## 确定性修复
`bootproof fix` 会读取最新的签名有效且已分类的失败，并将确切的已知失败映射到确定性的操作。
```
bootproof fix .
```
主机和服务命令会显示确切的命令、作用域和风险。它们只会在用户明确批准时运行。JSON 和 CI 模式绝不会批准命令。
修复回执区分了：
- 已拒绝
- 已失败
- 已取得进展
- 已验证
机器模式：
```
bootproof fix . --json
```
它输出一个 `bootproof/repair-result/v1` 对象，并且只有在存在已验证的回执时才会退出并返回 `0`。
`fix` 绝不会直接应用文件补丁。要将签名有效的文件修复显式应用到本地工作树：
```
bootproof apply-repair .
```
应用程序在写入前会检查回执签名、允许的文件范围、签名的内容哈希以及确切的当前原像。
请查看 [docs/REPAIR_RECEIPT.md](docs/REPAIR_RECEIPT.md)。
## 可选的 BYOK AI
AI 建议是可选的，只有在未知的确定性修复不存在时才可用。
```
OPENAI_API_KEY=... bootproof fix . --ai
```
或者：
```
ANTHROPIC_API_KEY=... BOOTPROOF_AI_PROVIDER=anthropic bootproof fix . --ai
```
BootProof 在联系提供商之前会先询问，仅发送经过脱敏的结构化失败证据，通过共享的安全模型验证严格的 `bootproof/ai-repair-suggestion/v1` 响应，并在测试任何命令或补丁之前再次询问。
AI 建议会被记录为 `ai_suggested`。
它们永远不会自动进入确定性注册表。
## 静态基础设施差异对比
```
bootproof diff --base main --head feature-branch
bootproof diff --base main --head HEAD --json
```
`diff` 读取已提交的 Git 对象，并仅执行静态分析。
它不会：
- 签出任何一个 ref
- 执行仓库代码
- 安装依赖项
- 读取受保护的 `.env` 内容
- 上传数据
它报告在以下方面检测到的受支持的偏差：
- 依赖清单和锁文件
- Compose 服务和端口
- 环境变量名
- 启动命令
- 包管理器
- runtime 标记
- 可检测的健康路由
差异对比可能需要新的证明，但它绝不会声称 head 版本可以启动。针对目标版本运行 `bootproof up` 即可通过观察到的健康证据来确证这一点。
## 诚实契约
BootProof 是有意受到限制的。
它不会：
- 在没有观察到健康状况的情况下将仓库标记为 `BOOTED`
- 未经明确同意执行远程代码
- 从 Docker 静默回退到主机执行
- 将跳过的步骤呈现为成功
- 凭空捏造密钥
- 写入受保护的 `.env` 文件
- 静默修补项目代码
- 在仓库存在歧义时猜测工作区
- 声称存在生成的脚手架（除非它确实已被写入）
- 上传遥测数据或隐藏证据
它会：
- 对成功的证明进行签名
- 对失败的证明进行签名
- 保留本地证据
- 对已知的失败进行分类
- 清晰地拒绝不受支持的路径
请查看 [docs/HONESTY_CONTRACT.md](docs/HONESTY_CONTRACT.md)。
## 安全模型
### 执行隔离（在不信任的仓库上运行前请阅读本文）
BootProof 的执行模型是**默认诚实，而非默认隔离**。当前版本中没有通用的容器沙箱。以下是你运行 `bootproof up` 时具体会发生的情况：
- **默认 (`--provider docker`)**：BootProof 只会对**基于源码构建的 Compose 应用程序**（包含 `docker-compose.yml` 且应用服务是从源码构建的仓库）在 Docker 内部执行。对于其他所有仓库——普通的 Node、Python、Rust、Go——Docker provider 会以 `orchestration_not_supported` 拒绝运行，而不是静默回退到主机。这是有意为之的：默认是关闭失败 (fail-closed)，而不是静默的主机执行。
- **`--provider local --unsafe-local`**：使用 `spawn(command, { shell: true })` **直接在你的主机上**运行安装和启动命令。没有容器，没有网络限制，也没有只读文件系统。`--unsafe-local` 标志就是明确的同意门控——你承认你已经检查了推断出的命令，并接受仓库的代码（包括 `postinstall` 脚本、`prestart` 钩子以及启动命令执行的任何操作）将以你的权限在你的机器上运行。
- **远程仓库** (`bootproof up https://github.com/...`)：BootProof 会进行克隆以供检查，但如果没有 `--provider local --unsafe-local`，它会**拒绝执行**。检查是安全的；执行需要同意。
**在你没有编写过的仓库上运行 `bootproof up --provider local --unsafe-local` 之前：**
1. 首先运行 `bootproof up --dry-run` 查看推断的命令而不实际执行它们。
2. 阅读计划。安装命令和启动命令将在你的主机上运行。
3. 只有在那之后，才添加 `--unsafe-local --install` 来实际执行。
这是目前的现实情况。针对非 Compose 仓库的通用 Docker 隔离已在路线图上，但未包含在此版本中。如果这阻碍了你的用例，请暂且不要在不受信任的仓库上使用 BootProof。
### 修复安全
BootProof 将修复操作视为可执行的风险。
修复安全模型会在危险命令运行前阻止或升级它们。
被阻止的示例包括：
- `sudo`
- shell 解释器
- 管道传输至 shell 的下载，例如 `curl | sh`
- 内联的任意执行，例如 `node -e`, `python -c`, `ruby -e`
- 递归的 world-writable chmod
- 原始磁盘写入
- 破坏性的数据库删除
- 受保护的 `.env` 写入
- 密钥泄露模式
高风险操作需要明确批准，且绝不能被 AI 提供的风险标签降级。
请查看 [docs/DETERMINISTIC_REPAIR_SAFETY_MODEL.md](docs/DETERMINISTIC_REPAIR_SAFETY_MODEL.md)。
## 当前功能
BootProof 目前提供：
- Node 包管理器和启动命令推断
- monorepo 候选排名
- Docker 服务依赖检测
- 仓库 Compose 检测
- 保守的 Go 主包执行
- Rails `bin/rails` 入口点检测
- 显式的 Make 运行目标执行
- Python/Flask 和 Go/Node 混合检测
- 从仓库证据和应用日志中发现 localhost 健康候选者
- 分类失败
- 签名的 Ed25519 证明
- 严格的 JSON 和 fail-closed 的 CI 输出
- 脱敏的注册表条目导出
- 针对已注册失败类别的确定性沙箱修复
- 带有签名、作用域和陈旧原像检查的显式修复应用
- 静态基础设施差异对比
检测范围比编排更广。如果证明的边界不安全或不明确，BootProof 可能会检测到某个技术栈，但仍然拒绝运行它。
## 支持的入口点
受支持的执行路径是有意收窄的。
| 类型 | 支持的路径 |
|---|---|
| Node | 包管理器 + 选定的 start/dev 脚本 |
| Go | 确切的某个 `main.go` 或 `cmd/*/main.go` |
| Ruby/Rails | `Gemfile` 加上 `bin/rails` |
| Make | 显式的 `run`、`serve`、`server`、`start` 或 `dev` 目标 |
| Compose | 带有已发布 HTTP 端口的仓库本地构建上下文 |
每条路径仍然需要观察到的健康状况。
成功的 `docker compose up -d`、进程派生或命令退出本身并不能构成绿色的结果。
## 失败分类
常见的失败类别包括：
- `not_an_application`
- `workspace_ambiguous`
- `dependency_install_skipped`
- `package_manager_version_mismatch`
- `python_flask_setup_required`
- `service_port_allocated`
- `postgres_auth_env_missing`
- `health_http_error`
- `health_check_timeout`
- `remote_code_execution_blocked`
- `unknown_failure`
未知的失败将保持未知，并为下一个检测器保留证据。
请查看 [docs/FAILURE_TAXONOMY.md](docs/FAILURE_TAXONOMY.md)。
## BootProof 可能写入的文件
根据命令和观察到的计划，BootProof 可能会写入：
```
.bootproof/attestation.json
.bootproof/registry-entry.json
.bootproof/registry/-.json
.bootproof/runtime/
docker-compose.bootproof.yml
.env.bootproof.example
```
注册表制品仅通过显式的导出命令进行写入。
受保护的应用程序 env 文件将保持不被触碰。
## 证明信任
本地证明（默认）包含：
```
{
"trust": {
"level": "local_developer_signed",
"signer": "local_ed25519",
"oidc": null
}
}
```
嵌入的信任值是一个被证明的声明，而不是外部身份证明。本地验证会单独将签名者分类为本机、显式已知或未知的外部签名者。修复回执和注册表条目使用相同的签名者层级。
本地证明是有用的证据。CI/OIDC 证明是更强的供应链证明。
通过无密钥/OIDC 进行的加密作者身份绑定有意被推迟到 CI/Action 工作中。BootProof 并不假装本地笔记本电脑的证明就等同于企业 CI 的证明。
### CI OIDC 签名
在具有 `permissions: id-token: write` 的 GitHub Actions 中，传递 `--ci-oidc` 以获取 runner 的 OIDC token 并将其声明嵌入到证明中：
```
bootproof up . --provider local --unsafe-local --ci-oidc
```
然后，该证明将带有 `ci_oidc_signed` 信任级别以及 OIDC 声明：
```
{
"trust": {
"level": "ci_oidc_signed",
"signer": "local_ed25519",
"oidc": {
"iss": "https://token.actions.githubusercontent.com",
"sub": "repo:bootproof/bootproof:ref:refs/heads/main",
"repository": "bootproof/bootproof",
"run_id": "123456",
"workflow": "CI",
"job_workflow_ref": "bootproof/bootproof/.github/workflows/ci.yml@refs/heads/main"
}
}
}
```
ed25519 签名仍然提供完整性；OIDC 证据提供 CI 出处。验证者可以独立验证签名和 OIDC 声明。`neutral_runner_signed` 和 `transparency_logged` 级别仍留在路线图中。
### 密钥轮换
本地签名密钥可以在不使现有证明失效的情况下进行轮换（每个证明都内联携带其公钥并独立验证）：
```
bootproof rotate-keys # generate new key, back up old
bootproof rotate-keys --repo . --resign # also re-sign the latest attestation
```
旧密钥会被归档到 `~/.bootproof/archived-keys/`，以便现有的证明仍然可被验证。
### 本地密钥保护与不保护的范围
本地签名密钥位于 `~/.bootproof/signer.json`（0600 权限；`~/.bootproof/` 目录的权限为 0700）。固定的外部签名者存储在 `~/.bootproof/known_signers.json` 中（同为 0600）。轮换归档的密钥存储在 `~/.bootproof/archived-keys/` 中（0600）。
该密钥保护的是**完整性**：有效的 ed25519 签名能证明该证明在签名后未被篡改。它不保护**作者身份**：任何获取此密钥文件的人都可以签署证明，并且会被验证为“this machine”。如果密钥被泄露，`bootproof rotate-keys` 会生成一个新的密钥对并将旧密钥归档——但是由泄露密钥签署的现有证明仍然会验证为完好（它们内联携带了旧的公钥）。轮换可以防止未来的泄露；它不能撤销过去的签名。
`local_developer_signed` **没有撤销机制**。没有密钥撤销服务器，没有 CRL，也没有 OCSP 响应器。信任阶梯（`local_developer_signed` → `ci_oidc_signed` → `neutral_runner_signed` → `transparency_logged`）是一种缓解措施，而不是隐藏的功能：更高的阶梯将签名绑定到外部身份（OIDC、中立 runner、透明度日志），这比本地密钥文件更难伪造。要求 `--require-known-signer` 的验证者会拒绝任何未显式固定的签名者，这将泄露密钥的影响范围限制在了已固定的密钥集合内。
## CI 和注册表
BootProof 不会上传证明。
项目可以有意导出脱敏的本地注册表条目或联合公共候选回执，并在提交前对其进行审查。
```
bootproof registry export .
bootproof attest export .
bootproof registry export . --federated
```
公共爬虫、私有云上传以及由 OIDC 支持的信任是未来的集成方向，而不是此仓库中已部署的服务。
请查看：
- [docs/CI_ACTION.md](docs/CI_ACTION.md)
- [docs/REGISTRY.md](docs/REGISTRY.md)
## 开源边界
此仓库包含本地信任层：
- 本地诊断
- 本地规划
- 本地回执
- 本地批准
- 可选的 BYOK AI 建议
- 确定性修复安全
- 无遥测
- 无自动上传
OSS 引擎可离线工作，且不需要 BootProof Cloud。
## 云边界
BootProof Cloud 属于一个单独的私有仓库。
其边界包括未来的托管能力，例如：
- 托管 AI
- 共享注册表
- 团队审批工作流
- GitHub App
- SSO/RB
- 策略
- 舰队仪表板
- 审计留存
这些是产品边界，而不是声称这些服务已在此公开仓库中实现。
此处不包含任何 Cloud/SaaS 代码。
## 发布打包
npm 包包含已编译的 CLI、许可证、README 和文档。
`dist/` 是 runtime 必需的，由 `prepack` 期间的 `npm run build` 生成，并且是有意不被提交的。
运行：
```
npm run pack:check
```
这会打包 BootProof，将 tarball 安装在一个隔离的临时目录中，并测试已安装的 CLI。
请查看 [docs/RELEASE_CHECKLIST.md](docs/RELEASE_CHECKLIST.md)。
## 开发
对于从源码工作的贡献者：
```
git clone https://github.com/bootproof/bootproof.git
cd bootproof
npm ci
npm run build
npm test
npm link
```
然后从另一个仓库：
```
bootproof up .
```
诸如 `dist/`、`node_modules/` 和 `.DS_Store` 之类的生成文件将被忽略且不会被提交。
## BootProof 不是什么
BootProof 不是：
- 部署平台
- 通用的 CI 替代品
- 神奇的环境修复器
- AI 编码 agent
- 保证每个仓库都能自动运行的保证
- 隐藏在 OSS 仓库中的云产品
- 沙箱或容器 runtime —— `--provider local` 会在你的主机上运行代码；`--provider docker` 仅隔离基于源码构建的 Compose 应用
BootProof 是仓库诚实的运行按钮。
它运行它能运行的内容，拒绝它无法证明的内容，对成功和失败都进行签名，并为人类和机器提供相同的证据。
## 状态
BootProof 处于早期 alpha 阶段。
近期的工作包括：
- 显式的全平台 Compose 模式
- 更强大的多服务健康建模
- 更广泛的确定性修复覆盖范围
- 更多的 Python、Go、Ruby 和 Make 入口点
- 由 CI/OIDC 支持的签名
- 与证明关联的徽章
- 已验证的公开证据索引
不受支持的路径应该清晰地失败，而不是神奇地化解。
## 许可证
Apache-2.0
.html → double-click to open)
标签：JSONLines, MITM代理, 威胁情报, 完整性校验, 密码学签名, 开发者工具, 自动化攻击, 自动化运维, 请求拦截, 零信任