RFC 流程
RFC 会在实施之前记录一项长期有效的项目级决策。该流程旨在呈现设计权衡，让维护者和贡献者有机会尽早提出异议，并留下可检索的记录，说明做出该决策的 原因。
大多数工作不需要 RFC。RFC 触发条件被有意设得较为严格，以免确实需要项目级决策的提案被普通功能排在后面。
RFC 范围、讨论时间安排和批准规则最后由 #9496 设定，该提案于 2026-08-10 获接受，并采纳为 FND-003 Rev. 15。有关持久协议，请参阅 FND-003。
何时提交 RFC 与仅提交 PR
提交 RFC 的条件是：提案在实施前需要作出长期有效的项目级决策，即至少符合以下一项：
- 新的安全层，或对项目安全模型的重大变更；
- 治理、贡献流程或项目权限变更；
- 跨领域架构重构，改变既有边界之间的所有权或契约；或
- 一个新的子系统，或另一个项目级能力边界。
不要仅仅因为工作包含以下内容就提交 RFC：
- 普通的功能新增；
- 架构或数据迁移；
- 配置字段或默认值的更改；或
- 范围受限的实现重构。
这些都通过 issue 和 PR 进行。新增频道、新提供程序、新工具和 bug 修复都属于普通工作，无论 diff 有多大。只有当它们的实质性影响同时触及上述四个触发条件之一时，才需要 RFC。
判定依据取决于对项目的实质性影响，而不是 issue 标题、作者、草稿是否借助 AI，或仅仅因为包含迁移、功能或默认值变更。如果不确定，请创建普通 issue，并说明你认为它可能触发某项条件的原因。维护者可以将其升级；这远比一个搁置的 RFC 代价低。
安全漏洞会按照 SECURITY.md 私下报告，绝不会作为公开 RFC 提出。
当已提交的 RFC 不满足触发条件时，维护者可以将其重新标记为普通 issue、功能请求或实现后续事项，或者将其关闭。此类处理说明相关工作是否仍然有效，以及将在哪里继续推进；这是路由决策，而不是基于实质内容的拒绝。
提交 RFC
RFC 是标记为 type:rfc 的 GitHub Issue。标题格式：
RFC: <short description of the proposal>
正文结构：根据提案的篇幅进行调整：
- 问题：是什么用户痛点或系统缺陷促使了这一改动？
- 提案：你打算做什么？
- 设计：细节；代码草图、模式结构、迁移计划
- 考虑过的替代方案：你还评估了哪些方案，以及为什么没有采用？
- 非目标：本提案明确不尝试解决的内容
- 风险与缓解措施：可能出现的问题，以及回滚方案
- 发布：是否启用了功能开关？是否进行了模式版本管理？是否设置了破坏性变更窗口期？
已提交的 RFC 必须围绕一份公开的提案经过至少规定时长的讨论：普通 RFC 为 48 小时，请求特殊一致通过路径的 RFC 为 72 小时。任何人都可以发表评论。维护者会发表意见。作者会据此迭代正文。
讨论期间的常规修订和澄清不会重新计时。对拟议决定作出实质性更改的修订会形成一个新的稳定快照，并对其进行公开标识，同时重新开始计算适用的最短期限。只有在该期限届满且提案稳定后，才会开启投票。
批准
投票针对不可变的提案快照进行，持续 72 小时；该快照由不可变的构件或提交标识，或由已记录的问题正文摘要加简明的决策摘要标识。开启投票的评论会记录该快照、指定的选民、阈值及其适用原因，以及准确的 UTC 截止时间。
选民范围。 活跃的 Core 贡献者是指在此前 30 天内，于正式开启的 RFC 投票中明确投票的当前 Core Team 成员。任何不属于该集合的当前 Core Team 成员仍可投票；这样做会将其加入该次投票的选民范围，并使其在后续投票中重新处于活跃状态。
投票为 APPROVE、REVISE 或 REJECT。REVISE 表示不予批准，但不构成否决。REJECT 表示会阻止通过的反对意见，需要说明具体原因。在截止时间前提交的最新投票将取代你之前的投票。
阈值。 默认是最终活跃选民总数的三分之二，向上取整到整名选民。法定人数要求至少有两张明确选票；沉默永远不计入法定人数。达到法定人数后，在普通投票中，选民的沉默计为 APPROVE。一致通过仅适用于其成本或不可逆性使超多数不足以应对的决策，例如许可证或法律所有权变更；这要求每位被分配的选民都明确投出 APPROVE，且沉默无法构成一致通过。
结果，按此顺序应用：
- 延期：少于两张明确选票。结案记录会说明何时可以重新开放。未作更改的延期提案可以重新进入新的 72 小时投票，无需重复讨论。
- 已拒绝：已达到法定人数，且任何最终表决结果为
REJECT。问题已关闭，并记录了阻塞性异议，同时关联任何底层问题仍在持续的 issue。此操作拒绝的是提案，不一定是问题本身。 - 已接受：达到法定人数，不存在
REJECT，且至少三分之二明确批准或默许。Issue 带有status:accepted，结案记录逐一回应每项REVISE关切，而不是将其丢弃。该交接可见后，实现 PR 即可继续进行。 - 返回讨论：以上皆非。未解决的修订请求已记录。
- 已撤回：作者主动撤回。无偏见地关闭。
只有在最终活跃选民中的每位成员都明确表示赞成，且没有不活跃的 Core 贡献者要求使用完整时限时，投票才可以提前结束。结束记录必须说明提前结束的原因。
当前协议适用于批准后发起的 RFC 投票。它不会自动使此前已接受的 RFC 失效；历史流程的审计和纠正工作会单独跟踪。
实现已接受的 RFC
实现相关的 PR 应：
- 在实现开始之前，确认 RFC 问题已记录其最终接受的形态和持久性处置
- 参考 RFC 问题编号（
Implements #5574 phase 1） - 在已接受的设计范围内进行实现，如果在实现过程中某个细节发生变化，请更新 RFC 正文或提交一个后续的澄清问题（issue）。
- 如果 RFC 要求逐步推出，则通过功能标志来发布。
- 为受破坏性变更影响的用户提供迁移路径
大型 RFC 通常会跨越多个 PR 并在多个版本中发布。随着各个阶段的落地，RFC 的跟踪注释会进行更新。
当前开放的 RFC
开放 RFC 是了解 ZeroClaw 未来发展的最佳主要来源。浏览：
sh
gh issue list --repo zeroclaw-labs/zeroclaw --label type:rfc --state open
该查询是权威来源。本页面有意不镜像其快照，因为手动维护的列表会在不知不觉间迅速过时。
已批准的 foundational RFCs
这些内容会影响其他所有方面。在提出跨领域更改之前，请先阅读它们：
- #5574：微内核迁移：crate 拆分、功能标志分类法、v1.0 路线
- #5576：文档标准与知识架构
- #5577：项目治理：核心团队、本文件的权威性。其 RFC 范围和投票门槛已被 #9496（FND-003 Rev. 15）取代
- #5579：工程基础设施：CI 流水线、发布自动化
- #5615：贡献文化：人类/AI 共同署名规范
- #5653：零妥协：错误处理、死代码策略、发布就绪标准
AI 生成的 RFC
根据 RFC #5615 的规定，明确允许由 AI 助手（在人类赞助人的支持下）撰写 RFC。如果某个 RFC 是在 AI 的帮助下起草的：
- 在正文中明确标注（“由 Claude 起草，经 @maintainer 审阅”）
- 赞助人负责准确性并回应审查
- 只有现任核心团队成员可以投出具有约束力的选票。赞助由 AI 起草的 RFC 不会赋予投票权限，而由 AI 协助发起本身也不会改变提案是否符合 RFC 触发条件
到目前为止，这种做法效果良好。可以将 AI 生成的草稿视为一等公民，但请记住，最终责任由发起人承担。