ZeroClaw 决策机制深度解析RFC 流程、Foundation 治理与已接受的决策如何落地【免费下载链接】zeroclawFast, small, and fully autonomous AI personal assistant infrastructure, any OS, any platform — deploy anywhere, swap anything 项目地址: https://gitcode.com/gh_mirrors/ze/zeroclawZeroClaw 是一个追求快速、小巧、完全自主的 AI 个人助理基础设施Fast, small, and fully autonomous AI personal assistant infrastructure, any OS, any platform其仓库内所有实质性的架构与治理变更都不是在 PR 评论区顺手拍板的而是走一套可追溯、可投票、可审计的RFCRequest for Comments决策流程。本文围绕 docs/book/src/philosophy/how-decisions-get-made.md 展开完整讲解 ZeroClaw 的决策分层模型哪些变更必须走 RFC、RFC 从提出到表决到落地的完整生命周期、status:accepted标签的效力边界以及经表决批准的 FoundationsFND文档如何与代码一起版本化、成为整个项目的常青权威。读完本文你将掌握 ZeroClaw 决策体系的全部规则细节并能准确判断一个提案应该在哪个阶段、以什么姿势进入决策管道。决策总原则实质性变更必须走 RFC 流程ZeroClaw 的项目哲学docs/book/src/philosophy/index.md建立在四条按优先级排列的观点之上You own it本地优先、你拥有它是基础约束Security-first, with escape hatches安全优先、留逃生通道紧随其后Minimal最小化控制二进制体积与依赖面Provider-agnostic模型无关保持模型可插拔。而 如何做出决策 正是这四条哲学之外的第五条支柱——它回答的不是我们要建什么而是我们怎么决定要建什么。该文档给出的决策总原则只有一条却极其明确实质性变更Substantive changes必须走 RFC 流程。一个被标记为status:accepted的 RFC 即使实现尚未完成也是**已批准且具有约束力ratified and binding**的讨论线程会一直保持活记录living record状态直到对应工作真正落地。这句话包含三个关键事实RFC 是决策先于实现的载体它记录的是项目级的持久决策durable project-level decision而不是某次代码评审的意见status:accepted是决策生效的正式信号一旦表决通过并打上该标签无论实现 PR 是否合入决策本身已经生效讨论线程是活记录从提案、讨论、修订到表决的完整过程都留在 issue 线程里作为事后追溯为什么当初这么定的第一手资料。何时必须发起 RFC何时只需要一个 PRRFC 流程的触发条件被刻意设计得很窄deliberately narrow目的是让真正需要项目级决策的提案不必排队在普通功能后面。RFC 流程文档 给出了明确的判据满足以下任一条件就必须在实现前发起 RFC新增一个安全层或对项目安全模型做出实质性修改治理、贡献流程或项目权威的变更跨越既有边界的横切架构重构改变所有权或契约新增子系统或其他项目级能力边界。以下情况不需要 RFC走 issue PR 即可普通功能新增schema 或数据迁移配置字段或默认值变更有边界的实现重构。文档特别强调新渠道channel、新 provider、新工具、bug 修复都属于普通工作无论 diff 有多大只有当其实质性影响同时跨越上面四条触发器之一时才需要 RFC。判据看的是实质项目影响substantive project effect而不是 issue 标题、作者身份、是否由 AI 起草、或是否伴随迁移/功能/默认值变更。拿不准时正确做法是开一个普通 issue 并说明我认为它可能触及触发器由 maintainer 决定是否升级——这比挂起一个不该存在的 RFC 成本低得多。仓库中的.github/ISSUE_TEMPLATE/rfc_design.yml就是这一判据的操作化该模板的第一组字段即要求提案人勾选Which RFC trigger does this meet?满足哪条 RFC 触发器并内嵌了若仅含上述普通工作则无需 RFC、可被 maintainer 重新归类为普通 issue的说明文案。而 治理基座文档 FND-003 第 8 节用完全一致的措辞再次确认了这四条触发器并补充安全漏洞走私有报告private reporting绝不作为公开 RFC 提交。RFC 提案的提交规范与模板结构RFC 以 GitHub Issue 形式提交标签为type:rfc标题格式固定为RFC: 对提案的简短描述正文结构随提案规模调整但建议按以下七段组织这正是.github/ISSUE_TEMPLATE/rfc_design.yml表单的字段来源Problem什么用户痛点或系统缺陷促使了这个提案Proposal你提议做什么Design细节——代码草图、schema 形状、迁移计划Alternatives considered你还评估过哪些方案为什么不用Non-goals这个提案明确不打算解决什么Risks and mitigations可能出什么问题回滚方案是什么Rollout是否功能开关feature flagschema 是否版本化破坏性变更窗口在仓库的.github/ISSUE_TEMPLATE/目录中可以看到这条 intake 管道的完整形态FND-003 第 7 节 定义了各模板的职责边界模板用途采集的关键信号bug_report.yml可复现缺陷组件、严重性、复现步骤、预期行为、环境、隐私检查support_config.yml配置与使用求助目标、观察到的行为、脱敏后的配置或命令feature_request.yml普通功能想法用户问题、提案方案、非目标、架构/风险线索、预期路由rfc_design.yml跨越 RFC 触发器的提案命中的触发器、问题、提案、风险、破坏性变更评估、决策/复审面roadmap_tracker.yml发布/路线图/RFC 跟踪目的、范围、关联工作、路由证据、关闭标准、stale 豁免申请docs_issue.yml文档缺陷位置、问题、期望文档、相关事实来源contributor_task.yml面向外部贡献者的任务上下文、验收标准、涉及文件、适合度、导师/评审联系人值得注意的是config.yml不提供公开的安全漏洞模板——它把私有安全策略、Discord、Discussions、贡献指南、RFC 流程和 maintainer PR 工作流链接在一起让贡献者在创建 tracked issue 之前先选对表面。从讨论到表决最低讨论期与稳定快照RFC 一旦提交即进入针对可见提案的最低讨论期minimum discussion period普通 RFC48 小时申请例外一致通过路径exceptional unanimous path的 RFC72 小时。讨论期内任何人都可以评论maintainer 实质性参与。作者根据反馈迭代正文。关于讨论期有两个精确的时钟规则普通的修订和澄清不会重置计时器ordinary revisions and clarifications do not restart the clock但实质性改变拟议决策的修订会建立一个新的稳定快照stable snapshot需要公开标识并重置适用的最低讨论期。投票只在讨论期已过 提案稳定两个条件同时满足后才开启。FND-003 第 8.1 节给出了完整生命周期图其核心链路为1. 作者用 RFC 模板开 issue声明所跨越的触发器 ↓ 2. 讨论期普通 48h / 例外一致 72h任何人都可评论 ↓ 3. 投票开启投票开启评论必须记录 - 不可变提案快照artifact / commit / issue-body digest - 指定的活跃选民active electorate - 阈值及适用理由 - 法定人数需两张明确选票 - 精确的 UTC 截止时间开启后 72 小时 ↓ 4. 核心团队成员投票APPROVE / REVISE / REJECT ↓ 5. 按优先级顺序判定结果投票机制选民、选票、法定人数与阈值这是 ZeroClaw RFC 流程最精细的部分全部定义在 FND-003 Rev. 15由 #9496 于 2026-08-10 通过及其后续修订中。活跃选民Active Electorate一个活跃核心贡献者active Core contributor是指当前 Core Team 成员且在过去 30 天内于某次正式开启的 RFC 投票中投过明确选票APPROVE/REVISE/REJECT且未公开退出或登记当期不可用。任何不在此集合中的现任 Core 成员仍可投票——投票即加入该次投票的选民集合并为自己激活后续投票资格。投票开启时检查活跃状态之后其他并发投票中的活动不会改变已开启投票的选民集合。选票语义APPROVE按快照原样接受REVISE请求修改、暂不批准但不构成否决REJECT阻断性反对必须给出具体理由。在当前投票周期的记录截止时间之前成员投出的最新选票覆盖其此前选票。法定人数与阈值法定人数Quorum至少2 张明确选票。沉默永远不计入法定人数默认阈值最终活跃选民final active electorate的三分之二向上取整到整数选民沉默即赞成一旦达到法定人数沉默选民按 APPROVE 计仅限普通投票一致通过Unanimity保留给昂贵或不可逆的决策如许可证或法律所有权变更要求每位被指派的选民明确 APPROVE沉默不能构成一致通过。FND-003 给了一个具体算例最终活跃选民 4 人1 张明确 APPROVE、1 张明确 REVISE、2 人沉默 → 按沉默即赞成计得 4 票中 3 票赞成满足三分之二阈值。结果判定按优先级顺序优先级条件结果a提案正文实质性变更或作者要求修改退回讨论Returned to discussionb明确选票少于 2 张推迟Deferredc达到法定人数且存在 REJECT拒绝Rejectedd达到法定人数、无 REJECT但阈值/明确批准仍不足推迟Deferrede达到法定人数、无 REJECT、阈值满足接受AcceptedDeferred推迟的细节值得特别注意FND-003 Rev. 17由 #10288 于 2026-08-23 定义当投票截止时明确选票不足 2 张、或无 REJECT 但阈值/明确批准仍未满足提案可在同一不可变快照上进入另一个有记录的 72 小时周期。这不是对新提案的新投票而是对同一快照的同一投票已有明确选票计入新一轮的法定人数与结果且持续有效直到被后续选票替换因此选民无需重投未变的选票。推迟周期的关闭/状态记录必须说明缺失条件并链接新一轮的开盘记录。Rejected拒绝与提案本身分离关闭 issue 时记录阻断性反对理由并链接任何承载底层问题的 issue——拒绝的是当前提案不一定是问题本身。Accepted接受issue 打上status:accepted关闭记录必须逐一回应每条 REVISE 关切而非丢弃。一旦这一交接handoff可见实现 PR 即可开始。此外投票只有在最终活跃选民中每位成员都明确批准、且没有不活跃的核心贡献者要求完整窗口时才可提前关闭且关闭记录必须说明提前关闭的理由。对于要求一致通过的投票只有每位被指派选民明确 APPROVE 才可提前关闭。status:accepted 的效力已批准即约束实现可分期回到关联文档的核心论断An RFC labelledstatus:acceptedis ratified and binding even while its implementation is still open——被标记为status:accepted的 RFC 即使实现仍开放也已批准且有约束力。这意味着决策与实现是两个独立轨道决策轨道status:accepted一旦打上提案的最终定型形状与持久去向final shape and durable disposition必须从 RFC issue 可见之后才允许进入实现实现轨道大型 RFC 往往跨多个 PR、跨多个 release 分期落地。实现 PR 应当确认 RFC issue 在实现开始前已记录最终被接受形态与持久去向引用 RFC issue 编号如Implements #5574 phase 1保持在已接受设计范围内若实现中细节变化更新 RFC 正文或提交后续澄清 issue若 RFC 要求渐进式发布则放在 feature flag 之后为受破坏性变更影响的用户提供迁移路径。RFC 的跟踪评论tracking comment会随着各阶段落地持续更新——这就是关联文档所说讨论线程是活记录直到工作落地的具体形态。持久去向Durable DispositionADR 的连接FND-003 第 8.3 节还规定了已接受 RFC 的四类持久去向回答了决策批准之后它最终沉淀在哪里ADR当决策实质约束未来架构时必须写标志包括令人意外的系统边界、非显而易见的权衡、实质限制未来架构选项的选择Standing-document update当持久结果是操作性/参考/工作流/安全/用户契约而非新架构决策时Implementation or tracker follow-up当已有 ADR/FND/常青文档已承载决策、仅剩交付工作时链接交付跟踪器No separate artifact当既有 FND/ADR/常青文档/已完成实现/后继决策已保存结果且无需额外跟踪时issue 须记录该理由并链接持久表面。RFC 是讨论与接受表面ADR 是重大架构决策的永久记录——不是每个已接受 RFC 都必须写 ADR只有达到架构阈值的才需要。Foundations已批准的基础 RFC 与代码一起版本化关联文档的第二个要点是已批准的奠基性 RFCratified foundational RFCs构成了项目赖以建立的成熟度框架maturity framework以 Foundations 一节的形式与代码一起在书中版本化。文档明确建议从那里开始获取规范的、始终最新的集合而不是在此处重复一份清单。查看仓库的 docs/book/src/foundations/ 目录可以看到这六份已批准的基座文档及其对应的 RFC 讨论线程#FND 文档回答的问题来源 RFC1fnd-001-intentional-architecture.md我们在构建什么应该是什么形态#5574微内核转型2fnd-002-documentation-standards.md我们如何记录和传递知识#55763fnd-003-governance.md我们如何协同、如何共同决策#5577其 RFC 范围与投票阈值已被 #9496 以 FND-003 Rev. 15 取代4fnd-004-engineering-infrastructure.md我们如何可靠地构建、测试、发布#5579CI 管道、发布自动化5fnd-005-contribution-culture.md我们如何一起工作、一起成长#5615人机协同署名规范6fnd-006-zero-compromise-in-practice.md我们如何写出经得起时间考验的代码#5653错误处理、dead-code 策略、发布就绪标准Foundations 的 README 以一封致后来者的信说明了这套机制的哲学ZeroClaw 是从既有代码库 bootstrap 出来的、由 AI 工具加速成形的项目功能强大但架构上未经过规划architecturally unplanned。团队没有推倒重来而是围绕既有工作生长出意图growing intention around it——这些 FND 文档就是那次选择的记录。它们不是要遵守的规则而是要内化的思维模型会跟随你进入每一门语言、每一个工具、每一支团队。版本化的关键含义FND 文档随代码一起提交、一起走 PR 评审与 CI因此读者、AI 助手、新贡献者都能从代码回溯到塑造它的推理trace a line from the code back to the reasoning that shaped it。每份 FND 都带 revision history——例如 FND-003 目前已到 Rev. 17从 2026-04-09 的初稿一路修订每次修订都记录对应的 GitHub issue/PR 编号形成完整的决策演进档案。基座文档为什么只活在这里关联文档说foundational RFCs 的规范集合活在 Foundations 一节而不是在此处重复——这与 RFC 流程文档中的另一条纪律互为印证RFC 流程页面上当前开放的 RFCCurrent open RFCs一节同样刻意不做快照镜像而是给出权威查询命令gh issue list --repo zeroclaw-labs/zeroclaw --label type:rfc --state open理由在文档中写得非常直白手工维护的列表过期速度比任何人察觉的都快。 同样FND-003 规定不要把 RFC issue 当作与 FND 竞争治理文档的第二个权威政策切片提升promote到 FND 之后持久规则只住在基座文档里。单一事实来源single source of truth是这套治理体系的一条主线操作细节住在最贴近工作流的地方maintainer 文档持久决策住在 FNDRFC issue 只保留讨论记录。RFC 流程与项目治理的其余联动关联文档虽短但它指向的 RFC 流程是整个 FND-003 治理体系的中枢。以下几点是理解决策如何做出不可缺少的上下文表决权与贡献者分层RFC 表决权与 FND-003 第 5 节 的三层贡献者模型严格挂钩Tier 1 Community任何人可开 issue、评论、投票支持想法但不能投有约束力的 RFC 票Tier 2 Contributor至少两个 PR 合入master的社区成员可被指派 issue、可请求非强制评审仍不能投约束票Tier 3 Core Team被现有 Core 成员公开邀请加入是唯一拥有 RFC 约束投票权的层级。只有现任 Core Team 成员能投出有约束力的选票。赞助一份 AI 起草的 RFC 不产生投票权详见下文。例行决策懒惰共识Lazy Consensus并非所有决策都需要投票。对于加标签、关闭 stale issue、更新文档等例行决策Core Team 遵循懒惰共识在相关 issue 中宣布意图48 小时内无人反对即可推进。以下事项不适用懒惰共识一律需要显式 Core 投票RFC 的接受/拒绝、发布、CODEOWNERS 或分支保护变更、治理文档本身变更、Core Team 成员增补。AI 起草 RFC允许但需人类赞助RFC #5615贡献文化明确允许 AI 助手起草 RFC但有三条硬性规则RFC 流程文档正文必须明确标注如 drafted with Claude, reviewed by maintainer赞助的人类对准确性负责并负责回应评审只有现任 Core Team 成员能投约束票赞助 AI 起草的 RFC 不创造投票权AI 协助的出身本身也不改变提案是否满足 RFC 触发器。治理决策的 GitHub 桥接记录FND-003 第 8.2a 节处理了会议决策 vs 公开记录的关系GitHub 是提案文本、讨论、投票开启、选票、截止时间与结果的唯一事实来源Discord 可以宣布或讨论 RFC但不建立治理状态。任何基于内部会议记录、改变公开项目状态的操作都必须在受影响的 issue/PR/tracker/RFC 上留下GitHub bridge record写明会议日期或决策记录、所应用的决策摘要、采取的公开行动以及是一次性例外还是持久规则变更。持久治理变更只有在反映到相关 GitHub 与文档表面后才成为政策。决策如何落到代码与 CI约束边界的佐证RFC 决策不是纸面文章。从仓库根目录即可看到治理决策如何被执行.github/CODEOWNERS自动评审路由。安全面src/security/**、src/gateway/**等、治理面.github/**、CODEOWNERS、Cargo.toml、deny.toml、架构文档面docs/book/src/foundations/**都被路由到核心评审人。FND-003 第 6.2 节进一步规定master分支保护至少 1 个 GitHub 批准risk:high或domain:security的 PR 需要 2 个独立 Core Team 批准强制通过cargo fmt、cargo clippy、cargo test禁止绕过设置包括管理员、禁止 force push 与删除.github/ISSUE_TEMPLATE/rfc_design.ymlRFC intake 表单强制提案人声明命中的触发器.github/label-policy.json 与 .github/labeler.yml标签治理的操作化——type:rfc用于标记 RFC issuestatus:accepted是决策生效的正式信号路径标签器按改动文件自动打 scope 标签大小标签器按 PR 元数据重算size:*根 AGENTS.mdFND-001 Rev. 8 将其定位为紧凑的项目契约其中第 31 行明确要求按变更的风险级别验证报告实际运行的命令并记录行为、风险、副作用与回滚——这正是risk:*标签体系与 FND-006 Zero Compromise 决策在开发纪律层面的回声。特别值得强调的是 FND-003 第 6.4 节对架构合规的决策是否应该加一道自动检查 PR 是否遵循 RFC 架构的 CI 门禁答案是不。该节区分了两种质量执行结构合规structural compliance导入方向、依赖图、lint、格式——由编译器、cargo deny、cargo clippy --workspace自动强制机器权威且不可协商架构意图architectural intent这个抽象放在哪一层、这个权衡是否符合愿景——需要判断力与上下文自动门禁要么放行微妙违规制造虚假信心要么误报导致开发者学会无视它。因此架构意图由 CODEOWNERS 路由到 Core 评审人AI 工具只协助开发与评审绝不单独把关合并。这一决策本身就是决策如何做出的绝佳案例它是一份被团队讨论、批准并写入基座文档的明确立场防止同一个问题在每个 PR 上反复争论。想了解接下来会发生什么看开放 RFC关联文档指向的 RFC 流程页面还给出了一个实践建议开放中的 RFC 是了解 ZeroClaw下一步做什么的最佳一手来源。用下面的命令即可随时查看当前所有开放 RFCgh issue list --repo zeroclaw-labs/zeroclaw --label type:rfc --state open已被批准的基座 RFC上述六份塑造了其余一切建议在提出横切变更之前先阅读它们。对打算贡献的读者完整的贡献入口在 How to contribute 与 Communication判断一个变更该走哪条路的导览在 Architecture and contribution map而决策机制本身的全量规范则在 FND-003: Team Organization, Project Governance, and Contribution Pipeline 与 RFC Process。小结一条从提案到约束的完整链路把关联文档的两句话展开ZeroClaw 的决策体系可以浓缩为一条可验证的链路触发实质性变更安全模型、治理、横切重构、新子系统→ 用 rfc_design.yml 开type:rfcissue讨论48h普通/ 72h例外一致路径最低讨论期作者迭代实质性修订重置计时器并建立新快照表决72 小时窗口对不可变快照投票2 张明确选票达成法定人数三分之二默认阈值沉默在达到法定人数后计为 APPROVEREJECT 必须给出理由生效status:accepted打上即已批准且有约束力关闭记录逐一回应 REVISE 关切持久去向ADR / 常青文档 / 实现跟踪 / 无独立工件必须可见沉淀基础性决策经批准后成为 Foundations 中与代码一起版本化的 FND 文档FND-001006并通过 CODEOWNERS、分支保护、标签体系与 AGENTS.md 落到日常开发约束里落地实现 PR 引用 RFC 编号、遵守已接受设计、按需走 feature flag 与迁移路径分阶段合入跟踪评论持续更新直到工作完成。这条链路把为什么做这个决定沉淀为可搜索、可追溯、可推翻重来的活记录——这正是讨论线程是活记录直到工作落地这句话的全部含义。【免费下载链接】zeroclawFast, small, and fully autonomous AI personal assistant infrastructure, any OS, any platform — deploy anywhere, swap anything 项目地址: https://gitcode.com/gh_mirrors/ze/zeroclaw创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 ZeroClaw 决策机制深度解析：RFC 流程、Foundation 治理与“已接受的决策“如何落地
ZeroClaw 决策机制深度解析RFC 流程、Foundation 治理与已接受的决策如何落地【免费下载链接】zeroclawFast, small, and fully autonomous AI personal assistant infrastructure, any OS, any platform — deploy anywhere, swap anything 项目地址: https://gitcode.com/gh_mirrors/ze/zeroclawZeroClaw 是一个追求快速、小巧、完全自主的 AI 个人助理基础设施Fast, small, and fully autonomous AI personal assistant infrastructure, any OS, any platform其仓库内所有实质性的架构与治理变更都不是在 PR 评论区顺手拍板的而是走一套可追溯、可投票、可审计的RFCRequest for Comments决策流程。本文围绕 docs/book/src/philosophy/how-decisions-get-made.md 展开完整讲解 ZeroClaw 的决策分层模型哪些变更必须走 RFC、RFC 从提出到表决到落地的完整生命周期、status:accepted标签的效力边界以及经表决批准的 FoundationsFND文档如何与代码一起版本化、成为整个项目的常青权威。读完本文你将掌握 ZeroClaw 决策体系的全部规则细节并能准确判断一个提案应该在哪个阶段、以什么姿势进入决策管道。决策总原则实质性变更必须走 RFC 流程ZeroClaw 的项目哲学docs/book/src/philosophy/index.md建立在四条按优先级排列的观点之上You own it本地优先、你拥有它是基础约束Security-first, with escape hatches安全优先、留逃生通道紧随其后Minimal最小化控制二进制体积与依赖面Provider-agnostic模型无关保持模型可插拔。而 如何做出决策 正是这四条哲学之外的第五条支柱——它回答的不是我们要建什么而是我们怎么决定要建什么。该文档给出的决策总原则只有一条却极其明确实质性变更Substantive changes必须走 RFC 流程。一个被标记为status:accepted的 RFC 即使实现尚未完成也是**已批准且具有约束力ratified and binding**的讨论线程会一直保持活记录living record状态直到对应工作真正落地。这句话包含三个关键事实RFC 是决策先于实现的载体它记录的是项目级的持久决策durable project-level decision而不是某次代码评审的意见status:accepted是决策生效的正式信号一旦表决通过并打上该标签无论实现 PR 是否合入决策本身已经生效讨论线程是活记录从提案、讨论、修订到表决的完整过程都留在 issue 线程里作为事后追溯为什么当初这么定的第一手资料。何时必须发起 RFC何时只需要一个 PRRFC 流程的触发条件被刻意设计得很窄deliberately narrow目的是让真正需要项目级决策的提案不必排队在普通功能后面。RFC 流程文档 给出了明确的判据满足以下任一条件就必须在实现前发起 RFC新增一个安全层或对项目安全模型做出实质性修改治理、贡献流程或项目权威的变更跨越既有边界的横切架构重构改变所有权或契约新增子系统或其他项目级能力边界。以下情况不需要 RFC走 issue PR 即可普通功能新增schema 或数据迁移配置字段或默认值变更有边界的实现重构。文档特别强调新渠道channel、新 provider、新工具、bug 修复都属于普通工作无论 diff 有多大只有当其实质性影响同时跨越上面四条触发器之一时才需要 RFC。判据看的是实质项目影响substantive project effect而不是 issue 标题、作者身份、是否由 AI 起草、或是否伴随迁移/功能/默认值变更。拿不准时正确做法是开一个普通 issue 并说明我认为它可能触及触发器由 maintainer 决定是否升级——这比挂起一个不该存在的 RFC 成本低得多。仓库中的.github/ISSUE_TEMPLATE/rfc_design.yml就是这一判据的操作化该模板的第一组字段即要求提案人勾选Which RFC trigger does this meet?满足哪条 RFC 触发器并内嵌了若仅含上述普通工作则无需 RFC、可被 maintainer 重新归类为普通 issue的说明文案。而 治理基座文档 FND-003 第 8 节用完全一致的措辞再次确认了这四条触发器并补充安全漏洞走私有报告private reporting绝不作为公开 RFC 提交。RFC 提案的提交规范与模板结构RFC 以 GitHub Issue 形式提交标签为type:rfc标题格式固定为RFC: 对提案的简短描述正文结构随提案规模调整但建议按以下七段组织这正是.github/ISSUE_TEMPLATE/rfc_design.yml表单的字段来源Problem什么用户痛点或系统缺陷促使了这个提案Proposal你提议做什么Design细节——代码草图、schema 形状、迁移计划Alternatives considered你还评估过哪些方案为什么不用Non-goals这个提案明确不打算解决什么Risks and mitigations可能出什么问题回滚方案是什么Rollout是否功能开关feature flagschema 是否版本化破坏性变更窗口在仓库的.github/ISSUE_TEMPLATE/目录中可以看到这条 intake 管道的完整形态FND-003 第 7 节 定义了各模板的职责边界模板用途采集的关键信号bug_report.yml可复现缺陷组件、严重性、复现步骤、预期行为、环境、隐私检查support_config.yml配置与使用求助目标、观察到的行为、脱敏后的配置或命令feature_request.yml普通功能想法用户问题、提案方案、非目标、架构/风险线索、预期路由rfc_design.yml跨越 RFC 触发器的提案命中的触发器、问题、提案、风险、破坏性变更评估、决策/复审面roadmap_tracker.yml发布/路线图/RFC 跟踪目的、范围、关联工作、路由证据、关闭标准、stale 豁免申请docs_issue.yml文档缺陷位置、问题、期望文档、相关事实来源contributor_task.yml面向外部贡献者的任务上下文、验收标准、涉及文件、适合度、导师/评审联系人值得注意的是config.yml不提供公开的安全漏洞模板——它把私有安全策略、Discord、Discussions、贡献指南、RFC 流程和 maintainer PR 工作流链接在一起让贡献者在创建 tracked issue 之前先选对表面。从讨论到表决最低讨论期与稳定快照RFC 一旦提交即进入针对可见提案的最低讨论期minimum discussion period普通 RFC48 小时申请例外一致通过路径exceptional unanimous path的 RFC72 小时。讨论期内任何人都可以评论maintainer 实质性参与。作者根据反馈迭代正文。关于讨论期有两个精确的时钟规则普通的修订和澄清不会重置计时器ordinary revisions and clarifications do not restart the clock但实质性改变拟议决策的修订会建立一个新的稳定快照stable snapshot需要公开标识并重置适用的最低讨论期。投票只在讨论期已过 提案稳定两个条件同时满足后才开启。FND-003 第 8.1 节给出了完整生命周期图其核心链路为1. 作者用 RFC 模板开 issue声明所跨越的触发器 ↓ 2. 讨论期普通 48h / 例外一致 72h任何人都可评论 ↓ 3. 投票开启投票开启评论必须记录 - 不可变提案快照artifact / commit / issue-body digest - 指定的活跃选民active electorate - 阈值及适用理由 - 法定人数需两张明确选票 - 精确的 UTC 截止时间开启后 72 小时 ↓ 4. 核心团队成员投票APPROVE / REVISE / REJECT ↓ 5. 按优先级顺序判定结果投票机制选民、选票、法定人数与阈值这是 ZeroClaw RFC 流程最精细的部分全部定义在 FND-003 Rev. 15由 #9496 于 2026-08-10 通过及其后续修订中。活跃选民Active Electorate一个活跃核心贡献者active Core contributor是指当前 Core Team 成员且在过去 30 天内于某次正式开启的 RFC 投票中投过明确选票APPROVE/REVISE/REJECT且未公开退出或登记当期不可用。任何不在此集合中的现任 Core 成员仍可投票——投票即加入该次投票的选民集合并为自己激活后续投票资格。投票开启时检查活跃状态之后其他并发投票中的活动不会改变已开启投票的选民集合。选票语义APPROVE按快照原样接受REVISE请求修改、暂不批准但不构成否决REJECT阻断性反对必须给出具体理由。在当前投票周期的记录截止时间之前成员投出的最新选票覆盖其此前选票。法定人数与阈值法定人数Quorum至少2 张明确选票。沉默永远不计入法定人数默认阈值最终活跃选民final active electorate的三分之二向上取整到整数选民沉默即赞成一旦达到法定人数沉默选民按 APPROVE 计仅限普通投票一致通过Unanimity保留给昂贵或不可逆的决策如许可证或法律所有权变更要求每位被指派的选民明确 APPROVE沉默不能构成一致通过。FND-003 给了一个具体算例最终活跃选民 4 人1 张明确 APPROVE、1 张明确 REVISE、2 人沉默 → 按沉默即赞成计得 4 票中 3 票赞成满足三分之二阈值。结果判定按优先级顺序优先级条件结果a提案正文实质性变更或作者要求修改退回讨论Returned to discussionb明确选票少于 2 张推迟Deferredc达到法定人数且存在 REJECT拒绝Rejectedd达到法定人数、无 REJECT但阈值/明确批准仍不足推迟Deferrede达到法定人数、无 REJECT、阈值满足接受AcceptedDeferred推迟的细节值得特别注意FND-003 Rev. 17由 #10288 于 2026-08-23 定义当投票截止时明确选票不足 2 张、或无 REJECT 但阈值/明确批准仍未满足提案可在同一不可变快照上进入另一个有记录的 72 小时周期。这不是对新提案的新投票而是对同一快照的同一投票已有明确选票计入新一轮的法定人数与结果且持续有效直到被后续选票替换因此选民无需重投未变的选票。推迟周期的关闭/状态记录必须说明缺失条件并链接新一轮的开盘记录。Rejected拒绝与提案本身分离关闭 issue 时记录阻断性反对理由并链接任何承载底层问题的 issue——拒绝的是当前提案不一定是问题本身。Accepted接受issue 打上status:accepted关闭记录必须逐一回应每条 REVISE 关切而非丢弃。一旦这一交接handoff可见实现 PR 即可开始。此外投票只有在最终活跃选民中每位成员都明确批准、且没有不活跃的核心贡献者要求完整窗口时才可提前关闭且关闭记录必须说明提前关闭的理由。对于要求一致通过的投票只有每位被指派选民明确 APPROVE 才可提前关闭。status:accepted 的效力已批准即约束实现可分期回到关联文档的核心论断An RFC labelledstatus:acceptedis ratified and binding even while its implementation is still open——被标记为status:accepted的 RFC 即使实现仍开放也已批准且有约束力。这意味着决策与实现是两个独立轨道决策轨道status:accepted一旦打上提案的最终定型形状与持久去向final shape and durable disposition必须从 RFC issue 可见之后才允许进入实现实现轨道大型 RFC 往往跨多个 PR、跨多个 release 分期落地。实现 PR 应当确认 RFC issue 在实现开始前已记录最终被接受形态与持久去向引用 RFC issue 编号如Implements #5574 phase 1保持在已接受设计范围内若实现中细节变化更新 RFC 正文或提交后续澄清 issue若 RFC 要求渐进式发布则放在 feature flag 之后为受破坏性变更影响的用户提供迁移路径。RFC 的跟踪评论tracking comment会随着各阶段落地持续更新——这就是关联文档所说讨论线程是活记录直到工作落地的具体形态。持久去向Durable DispositionADR 的连接FND-003 第 8.3 节还规定了已接受 RFC 的四类持久去向回答了决策批准之后它最终沉淀在哪里ADR当决策实质约束未来架构时必须写标志包括令人意外的系统边界、非显而易见的权衡、实质限制未来架构选项的选择Standing-document update当持久结果是操作性/参考/工作流/安全/用户契约而非新架构决策时Implementation or tracker follow-up当已有 ADR/FND/常青文档已承载决策、仅剩交付工作时链接交付跟踪器No separate artifact当既有 FND/ADR/常青文档/已完成实现/后继决策已保存结果且无需额外跟踪时issue 须记录该理由并链接持久表面。RFC 是讨论与接受表面ADR 是重大架构决策的永久记录——不是每个已接受 RFC 都必须写 ADR只有达到架构阈值的才需要。Foundations已批准的基础 RFC 与代码一起版本化关联文档的第二个要点是已批准的奠基性 RFCratified foundational RFCs构成了项目赖以建立的成熟度框架maturity framework以 Foundations 一节的形式与代码一起在书中版本化。文档明确建议从那里开始获取规范的、始终最新的集合而不是在此处重复一份清单。查看仓库的 docs/book/src/foundations/ 目录可以看到这六份已批准的基座文档及其对应的 RFC 讨论线程#FND 文档回答的问题来源 RFC1fnd-001-intentional-architecture.md我们在构建什么应该是什么形态#5574微内核转型2fnd-002-documentation-standards.md我们如何记录和传递知识#55763fnd-003-governance.md我们如何协同、如何共同决策#5577其 RFC 范围与投票阈值已被 #9496 以 FND-003 Rev. 15 取代4fnd-004-engineering-infrastructure.md我们如何可靠地构建、测试、发布#5579CI 管道、发布自动化5fnd-005-contribution-culture.md我们如何一起工作、一起成长#5615人机协同署名规范6fnd-006-zero-compromise-in-practice.md我们如何写出经得起时间考验的代码#5653错误处理、dead-code 策略、发布就绪标准Foundations 的 README 以一封致后来者的信说明了这套机制的哲学ZeroClaw 是从既有代码库 bootstrap 出来的、由 AI 工具加速成形的项目功能强大但架构上未经过规划architecturally unplanned。团队没有推倒重来而是围绕既有工作生长出意图growing intention around it——这些 FND 文档就是那次选择的记录。它们不是要遵守的规则而是要内化的思维模型会跟随你进入每一门语言、每一个工具、每一支团队。版本化的关键含义FND 文档随代码一起提交、一起走 PR 评审与 CI因此读者、AI 助手、新贡献者都能从代码回溯到塑造它的推理trace a line from the code back to the reasoning that shaped it。每份 FND 都带 revision history——例如 FND-003 目前已到 Rev. 17从 2026-04-09 的初稿一路修订每次修订都记录对应的 GitHub issue/PR 编号形成完整的决策演进档案。基座文档为什么只活在这里关联文档说foundational RFCs 的规范集合活在 Foundations 一节而不是在此处重复——这与 RFC 流程文档中的另一条纪律互为印证RFC 流程页面上当前开放的 RFCCurrent open RFCs一节同样刻意不做快照镜像而是给出权威查询命令gh issue list --repo zeroclaw-labs/zeroclaw --label type:rfc --state open理由在文档中写得非常直白手工维护的列表过期速度比任何人察觉的都快。 同样FND-003 规定不要把 RFC issue 当作与 FND 竞争治理文档的第二个权威政策切片提升promote到 FND 之后持久规则只住在基座文档里。单一事实来源single source of truth是这套治理体系的一条主线操作细节住在最贴近工作流的地方maintainer 文档持久决策住在 FNDRFC issue 只保留讨论记录。RFC 流程与项目治理的其余联动关联文档虽短但它指向的 RFC 流程是整个 FND-003 治理体系的中枢。以下几点是理解决策如何做出不可缺少的上下文表决权与贡献者分层RFC 表决权与 FND-003 第 5 节 的三层贡献者模型严格挂钩Tier 1 Community任何人可开 issue、评论、投票支持想法但不能投有约束力的 RFC 票Tier 2 Contributor至少两个 PR 合入master的社区成员可被指派 issue、可请求非强制评审仍不能投约束票Tier 3 Core Team被现有 Core 成员公开邀请加入是唯一拥有 RFC 约束投票权的层级。只有现任 Core Team 成员能投出有约束力的选票。赞助一份 AI 起草的 RFC 不产生投票权详见下文。例行决策懒惰共识Lazy Consensus并非所有决策都需要投票。对于加标签、关闭 stale issue、更新文档等例行决策Core Team 遵循懒惰共识在相关 issue 中宣布意图48 小时内无人反对即可推进。以下事项不适用懒惰共识一律需要显式 Core 投票RFC 的接受/拒绝、发布、CODEOWNERS 或分支保护变更、治理文档本身变更、Core Team 成员增补。AI 起草 RFC允许但需人类赞助RFC #5615贡献文化明确允许 AI 助手起草 RFC但有三条硬性规则RFC 流程文档正文必须明确标注如 drafted with Claude, reviewed by maintainer赞助的人类对准确性负责并负责回应评审只有现任 Core Team 成员能投约束票赞助 AI 起草的 RFC 不创造投票权AI 协助的出身本身也不改变提案是否满足 RFC 触发器。治理决策的 GitHub 桥接记录FND-003 第 8.2a 节处理了会议决策 vs 公开记录的关系GitHub 是提案文本、讨论、投票开启、选票、截止时间与结果的唯一事实来源Discord 可以宣布或讨论 RFC但不建立治理状态。任何基于内部会议记录、改变公开项目状态的操作都必须在受影响的 issue/PR/tracker/RFC 上留下GitHub bridge record写明会议日期或决策记录、所应用的决策摘要、采取的公开行动以及是一次性例外还是持久规则变更。持久治理变更只有在反映到相关 GitHub 与文档表面后才成为政策。决策如何落到代码与 CI约束边界的佐证RFC 决策不是纸面文章。从仓库根目录即可看到治理决策如何被执行.github/CODEOWNERS自动评审路由。安全面src/security/**、src/gateway/**等、治理面.github/**、CODEOWNERS、Cargo.toml、deny.toml、架构文档面docs/book/src/foundations/**都被路由到核心评审人。FND-003 第 6.2 节进一步规定master分支保护至少 1 个 GitHub 批准risk:high或domain:security的 PR 需要 2 个独立 Core Team 批准强制通过cargo fmt、cargo clippy、cargo test禁止绕过设置包括管理员、禁止 force push 与删除.github/ISSUE_TEMPLATE/rfc_design.ymlRFC intake 表单强制提案人声明命中的触发器.github/label-policy.json 与 .github/labeler.yml标签治理的操作化——type:rfc用于标记 RFC issuestatus:accepted是决策生效的正式信号路径标签器按改动文件自动打 scope 标签大小标签器按 PR 元数据重算size:*根 AGENTS.mdFND-001 Rev. 8 将其定位为紧凑的项目契约其中第 31 行明确要求按变更的风险级别验证报告实际运行的命令并记录行为、风险、副作用与回滚——这正是risk:*标签体系与 FND-006 Zero Compromise 决策在开发纪律层面的回声。特别值得强调的是 FND-003 第 6.4 节对架构合规的决策是否应该加一道自动检查 PR 是否遵循 RFC 架构的 CI 门禁答案是不。该节区分了两种质量执行结构合规structural compliance导入方向、依赖图、lint、格式——由编译器、cargo deny、cargo clippy --workspace自动强制机器权威且不可协商架构意图architectural intent这个抽象放在哪一层、这个权衡是否符合愿景——需要判断力与上下文自动门禁要么放行微妙违规制造虚假信心要么误报导致开发者学会无视它。因此架构意图由 CODEOWNERS 路由到 Core 评审人AI 工具只协助开发与评审绝不单独把关合并。这一决策本身就是决策如何做出的绝佳案例它是一份被团队讨论、批准并写入基座文档的明确立场防止同一个问题在每个 PR 上反复争论。想了解接下来会发生什么看开放 RFC关联文档指向的 RFC 流程页面还给出了一个实践建议开放中的 RFC 是了解 ZeroClaw下一步做什么的最佳一手来源。用下面的命令即可随时查看当前所有开放 RFCgh issue list --repo zeroclaw-labs/zeroclaw --label type:rfc --state open已被批准的基座 RFC上述六份塑造了其余一切建议在提出横切变更之前先阅读它们。对打算贡献的读者完整的贡献入口在 How to contribute 与 Communication判断一个变更该走哪条路的导览在 Architecture and contribution map而决策机制本身的全量规范则在 FND-003: Team Organization, Project Governance, and Contribution Pipeline 与 RFC Process。小结一条从提案到约束的完整链路把关联文档的两句话展开ZeroClaw 的决策体系可以浓缩为一条可验证的链路触发实质性变更安全模型、治理、横切重构、新子系统→ 用 rfc_design.yml 开type:rfcissue讨论48h普通/ 72h例外一致路径最低讨论期作者迭代实质性修订重置计时器并建立新快照表决72 小时窗口对不可变快照投票2 张明确选票达成法定人数三分之二默认阈值沉默在达到法定人数后计为 APPROVEREJECT 必须给出理由生效status:accepted打上即已批准且有约束力关闭记录逐一回应 REVISE 关切持久去向ADR / 常青文档 / 实现跟踪 / 无独立工件必须可见沉淀基础性决策经批准后成为 Foundations 中与代码一起版本化的 FND 文档FND-001006并通过 CODEOWNERS、分支保护、标签体系与 AGENTS.md 落到日常开发约束里落地实现 PR 引用 RFC 编号、遵守已接受设计、按需走 feature flag 与迁移路径分阶段合入跟踪评论持续更新直到工作完成。这条链路把为什么做这个决定沉淀为可搜索、可追溯、可推翻重来的活记录——这正是讨论线程是活记录直到工作落地这句话的全部含义。【免费下载链接】zeroclawFast, small, and fully autonomous AI personal assistant infrastructure, any OS, any platform — deploy anywhere, swap anything 项目地址: https://gitcode.com/gh_mirrors/ze/zeroclaw创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考