RFC 流程
RFC 会在实施之前记录一项长期有效的项目级决策。该流程旨在呈现设计权衡，让维护者和贡献者有机会尽早提出异议，并留下可检索的记录，说明做出该决策的 原因。
大多数工作不需要 RFC。RFC 触发条件被有意设得较为严格，以免确实需要项目级决策的提案被普通功能排在后面。
RFC 的范围和批准规则由 FND-003 定义。当前协议经 #9496 收窄，经 #10288 针对延期投票作出澄清，并经 #10549 简化。
何时提交 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>
正文结构：根据提案的篇幅进行调整：
- 问题：是什么用户痛点或系统缺陷促使了这一改动？
- 提案：你打算做什么？
- 设计：细节；代码草图、模式结构、迁移计划
- 考虑过的替代方案：你还评估了哪些方案，以及为什么没有采用？
- 非目标：本提案明确不尝试解决的内容
- 风险与缓解措施：可能出现的问题，以及回滚方案
- 发布：是否启用了功能开关？是否进行了模式版本管理？是否设置了破坏性变更窗口期？
Filed RFC 会经过快照准备和讨论阶段，但没有强制性的最短讨论时限。任何人都可以发表评论。维护者会参与讨论。作者根据反馈迭代修改正文。
Core 投票可以在以下条件满足后开启：提案具有可见且稳定的快照，发起投票者标明 RFC 触发条件，并且有一位 Core 贡献者愿意将该快照提交表决。投票前对正文的编辑不会重新开始自动等待期；投票开启后对正文的编辑，要么作为实质性替换终止当前投票，要么不纳入投票快照，直至下一次修订。
批准
投票周期通常在 72 小时 内保持开放，基于不可变的提案快照。该快照由不可变的构件或提交标识，或由已记录的 issue 正文摘要加上简明的决议摘要标识。开启投票的评论需记录快照、指定的投票人群体、阈值及其适用原因、法定人数需要两张明确选票，以及精确的 UTC 截止时间。不得在本协议之外添加临时的关闭条件。
选民范围。 活跃的 Core 贡献者是指在此前 30 天内，于正式开启的 RFC 投票中明确投票的当前 Core Team 成员。任何不属于该集合的当前 Core Team 成员仍可投票；这样做会将其加入该次投票的选民范围，并使其在后续投票中重新处于活跃状态。
Ballots（投票选项）为 APPROVE、REVISE 或 REJECT。APPROVE 表示接受当前快照（snapshot）的原文，可附带实现边界说明。REVISE 会终止当前快照，其中需要说明受影响的契约或正文术语、所需的具体正文修改或决策，以及该歧义为何妨碍批准。REJECT 是一项阻断性异议，必须附上具体理由。在投票仍开放期间，你在记录的截止时间之前提交的最新一次 APPROVE 或 REJECT 将取代之前的投票；有效的 REVISE 对该快照而言是终局性的。
阈值。 默认是最终活跃选民总数的三分之二，向上取整到整名选民。法定人数要求至少有两张明确选票；沉默永远不计入法定人数。达到法定人数后，在普通投票中，选民的沉默计为 APPROVE。一致通过仅适用于其成本或不可逆性使超多数不足以应对的决策，例如许可证或法律所有权变更；这要求每位被分配的选民都明确投出 APPROVE，且沉默无法构成一致通过。
结果，按此顺序应用：
- 退回修订：在截止日期前提交的有效且符合条件的
REVISE会暂停当前快照。退回记录会注明阻塞的正文变更或需要做出的决定。 - 暂缓：投票无法结束，原因是明确选票少于两张；或者法定人数已满足但没有有效的
REVISE或REJECT，且适用的阈值或所需的明确批准尚未达到。该提案可以基于同一份不可变快照进入新的 72 小时周期。续期或重新开启的记录应写明未变更的快照、已保留的选票、目前的选民范围、阈值、未满足的条件以及确切的 UTC 截止时间。已有的明确选票计入新周期的法定人数和结果，并一直有效，直至被撤回或被后续选票取代。提案发生实质性变更时，将创建新的快照。 - 已拒绝：已达到法定人数，且任何最终表决结果为
REJECT。问题已关闭，并记录了阻塞性异议，同时关联任何底层问题仍在持续的 issue。此操作拒绝的是提案，不一定是问题本身。 - Accepted：达到法定人数，没有有效的
REVISE或REJECT，且适用的阈值已满足。默认情况下，这意味着至少三分之二的投票人明确批准或默示批准；例外的全体一致投票则要求每位指定投票人都明确投出APPROVE。Issue 带有status:accepted，当提出非阻塞性的实现边界时，结案记录或实现交接记录会注明这些边界。实现 PR 可在该交接内容可见后继续推进。 - 退回讨论：提案正文发生实质性变更，或作者在决定前请求修改。退回记录需注明下一个稳定的提案目标或所需的修改内容。
- 已撤回：作者主动撤回。无偏见地关闭。
含糊不清、未指明具体阻碍事项的 REVISE 在被修正之前，既不会阻止投票，也不计入法定人数。投票发起人可以要求澄清，但不得单独搁置表面上有效的 REVISE；如果对其有效性存在争议，则须由另一位 Core 贡献者同意该投票无效，否则该投票仍然有效。
在截止时间对仍处于开放状态、且没有有效 REVISE 或 REJECT 的投票进行评估时，才适用“沉默即同意”。沉默绝不会覆盖已停止的快照。
只有在最终活跃选民中的每位成员都明确表示赞成，且没有不活跃的 Core 贡献者要求使用完整时限时，投票才可以提前结束。结束记录必须说明提前结束的原因。
当前协议适用于在批准该修订版本的文档 PR 合并之后发起的 RFC 投票，除非 Core 明确在某个特定 issue 上记录了更早的使用情况。它不会自动使早先已通过的 RFC 失效；历史流程审计与更正工作由单独的渠道跟踪。
投票记录
请以本指南中的散文要求为准，作为投票开启、延续和关闭评论的规范格式。不存在单独的必填投票记录模板；RFC 议题表单收集的是初始提案，而不是投票记录。FND-003 规定了投票有效性、截止时间和结果优先级。
开启记录包含 RFC 触发条件以及快照已就绪的原因，并与上文的批准字段并列。未变更快照的延续记录会列出尚未撤回或替换的已结转选票，并设定新的精确 UTC 截止时间；它不会让投票无限期挂起。关闭或退回记录需标明快照、有资格的选票、结果及原因，以及所需的修订、实施边界或延续安排。有效且有资格的 REVISE 会终止该快照，而不是在关闭时作为一项待计入的顾虑被忽略。
实现已接受的 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 生成的草稿视为一等公民，但请记住，最终责任由发起人承担。