Astrid贡献者等级制度：4级权限体系如何平衡开放参与与安全边界-二趣网

Astrid贡献者等级制度：4级权限体系如何平衡开放参与与安全边界

【免费下载链接】handbookContributor handbook for Astrid: the polyrepo, public contracts, contribution process, and release workflow.项目地址: https://gitcode.com/gh_mirrors/handbook76/handbook

Astrid 是一个安全关键的智能体运行时（AI Agent Runtime），其贡献者手册定义了4 级贡献者等级制度（New / Astrinaut / Core / Maintainer），并通过 CI 权限门禁自动强制执行——让新手能快速上手，同时让加密与授权边界始终受控。本文带你一文看懂这套 4 级权限体系的运作方式与晋升路径。

为什么安全项目需要 4 级贡献者等级

Astrid 采用多仓（polyrepo）架构：内核、SDK、每个胶囊（capsule）都是独立的 Git 仓库。由于它运行着 WASM 沙箱、能力令牌（capability token）和审计链，每一个落入core/仓库的变更都要对照威胁模型审查，而不仅仅是看代码写得对不对。

这套等级制度的核心设计哲学是：大门敞开，边界清晰。

等级名单的唯一权威来源是core/.github/contributors.yml，未列入名单的贡献者一律默认为New（新手）。
CI 在每一个 PR 上直接读取这份文件判定权限，不依赖人工记忆。
权限与具体代码路径绑定：改哪个文件需要什么等级，全部机械化、可审计。

完整定义见贡献者手册：src/handbook/contribution-tiers.md。

4 级贡献者等级详解：从 New 到 Maintainer 的晋升路线

等级	入门条件	权限范围
New（新手）	所有未列入名单者的默认等级	必须先开 issue 并等待维护者认领，由维护者添加`newcomer-approved`标签后 CI 才会放行
Astrinaut	首次贡献成功合并后晋升	可自主认领 issue，向非核心模块提交 PR：CLI、SDK、胶囊、文档、测试
Core（核心贡献者）	持续高质量贡献后晋升	可修改核心 crate（kernel、events、hooks、config），但安全关键路径仍需维护者共同审查
Maintainer（维护者）	项目负责人	完全访问：安全路径、重构、发布、版本号升级

三个值得记住的要点：

晋升无需申请。没有申请流程，你合并的 PR 的质量与一致性就是唯一信号，由维护者酌情晋升。
人人都是新手起步。贡献不需要预审批，但第一个 PR 必须走 "issue-first" 流程。
权限跟着代码路径走，不跟着人走。机器把关，不靠 reviewer 眼力。

CI 权限门禁：contributor-gate 如何强制执行

等级制度靠.github/workflows/pr-checks.yml中的contributor-gate作业落地，它对每个指向main的 PR 执行三步：

解析contributors.yml，确定 PR 作者的等级；
拉取本次 PR 的变更文件列表；
将每个变更路径与两组保护路径集逐一比对：

🔐 两组保护路径

路径集	包含的 crate	定位
`SECURITY_PATHS`	`astrid-crypto`、`astrid-capabilities`、`astrid-audit`、`astrid-approval`、`astrid-vfs`、`astrid-storage`、`astrid-sys`、`astrid-core`	加密与授权边界（签名、能力令牌、防篡改审计链、虚拟文件系统）
`CORE_PATHS`	`astrid-kernel`、`astrid-events`、`astrid-hooks`、`astrid-config`、`astrid-mcp`	重要但不在加密边界上（事件路由、沙箱宿主、配置解析）

各级别的门禁结果：

等级	CI 行为
New	没有维护者的`newcomer-approved`标签 → CI 直接失败
Astrinaut	触碰`SECURITY_PATHS`或`CORE_PATHS`→ CI 直接失败
Core	CI 通过，但修改安全路径会发出警告，提示合并前必须有维护者共同审查
Maintainer	所有检查无条件通过

这套设计的高明之处在于：边界由机器强制，而非靠人自觉。新手即使误改加密代码，也不是"被 reviewer 拦下"，而是 CI 根本不允许它通过。

每个 PR 还要通过的 5 项 CI 检查

除等级门禁外，PR 必须同时通过：

template：PR 模板四节（Linked Issue、Summary、Changes、Test Plan）必须全部填写；
linked-issue：PR 必须含Closes #N引用或侧边栏关联 issue；
file-size：任何被 PR 推过 1000 行的文件直接拒绝；
account-age：对注册不足 30 天、无公开仓库也无关注者的新账号发出风险警告；
changelog：改动.rs或Cargo.toml的 PR 必须附CHANGELOG.md条目。

新手贡献快速上手：5 步走通第一个 PR

想参与 Astrid 的贡献？按下面的顺序来（完整 Git 工作流见src/handbook/polyrepo-and-workflow.md）：

先读手册：克隆本手册仓库，本地用 mdBook 渲染阅读：

git clone https://gitcode.com/gh_mirrors/handbook76/handbook cd handbook && mdbook serve --open

先开 issue，再写代码。没有关联 issue 且无事前讨论的 PR 会被直接关闭，这是硬性规则；
等待认领：由维护者指派任务并添加newcomer-approved标签，CI 才会放行你的 PR；
规范分支与提交：从origin/main拉分支（命名如feat/xxx、fix/xxx），所有提交必须 GPG 签名；
首个 PR 合并后，你即晋升为 Astrinaut，可自主认领 CLI、SDK、胶囊等模块的 issue，正式进入贡献循环。🚀

⚠️ 对抗式自审：对任何非平凡变更，请求 review 前请先用攻击者视角过一遍——这段代码凌晨 3 点在生产环境会怎么失败？它可能破坏哪些不变量？如果你的改动新增了 host 函数、能力检查、IPC topic 或审计动作，属于"边界穿越"，必须在 PR 摘要中显式声明。

硬性红线：哪些 PR 永远不会被接受

手册明确列出以下"硬停止项"（不是建议，是红线）：

无关联 issue、无事前讨论的 PR；
看不出理解受影响 crate 的 AI 批量提交；
维护者以下等级提交的重构 PR（发现需要重构？开 issue）；
非 Core 等级修改安全关键 crate；
无书面理由与负责人批准的unsafe代码（安全关键 crate 均声明#![deny(unsafe_code)]）；
与功能/修复混在同一个 PR 里的版本号升级——版本升级永远是独立 PR。

安全漏洞报告：48 小时确认机制

发现安全漏洞？不要开公开 issue，走项目的私有漏洞报告渠道。项目承诺 48 小时内确认、7 天内给出修复时间表。纳入范围的漏洞类型包括：沙箱逃逸、能力令牌伪造、ed25519/BLAKE3 加密弱点、host 函数注入，以及审计日志篡改。

总结

Astrid 的 4 级贡献者等级制度，用机器可读的等级名单 + CI 路径门禁，让"开源开放"与"安全边界"同时成立：

对新手：零门槛进入（New），晋升路径清晰可见（Astrinaut → Core），全程有 CI 反馈；
对项目：加密与授权边界永远锁在 Core / Maintainer 权限之后，不依赖任何人的自觉。

一句话记忆：先开 issue，稳定合并第一个 PR，剩下的水到渠成。

创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考

企业官网建设流程全解析