主题: 应用部分 3. 项目宪法：第一次规则公投
难度等级: 中等
预计学习时间: 2-3 小时
前置要求: 熟悉第一卷的材料：mission.md、tech-stack.md、roadmap.md 文件（第 6 部分）。
了解 SDD 流程安全的基础知识（第一卷的第 18 部分）。
具备使用 YAML 和 Markdown 格式的基本技能。
学习目标: 学会清晰地区分产品契约（mission/tech-stack/roadmap）和自动化安全宪法（constitution.md）。
能够将不可变原则（immutable_principles）表述为严格的禁令，而不是建议。
掌握创建可变规则（mutable_rules）的方法，并必须填写全部 6 个关键字段（incident_type、pipeline_phase、permitted_actions、max_scope、ttl、rollback_condition）。
理解并能够描述基础的管理协议（governance_protocol），包括代理角色、投票规则和否决条件。
获得将规则从一个事件（node_not_ready）迁移到另一个事件（high_memory_usage）的实践技能，避免盲目复制。
概述: 本节专门介绍如何创建「项目宪法」——一套版本化的规则和限制集合，用于安全自动化（自动修复）以及 AI 代理的工作。虽然第一卷的文件（mission.md、tech-stack.md、roadmap.md）回答了「我们构建什么」的问题，但新文件 constitution.md 回答的是「即使代理非常想这样做，它也不能对这个做什么」的问题。宪法由两个主要层次组成：immutable_principles（不可变的禁令，保护数据库、备份和审计）以及 mutable_rules（具有严格限制的作用范围、生命周期和回滚条件的可变规则）。本节还研究了通过代理公投批准修正案的程序，使规则变更透明且可追溯。
关键概念: Constitution.md: 版本化的不变式和可变规则集合，描述安全自动化的边界。在代理执行任何危险操作之前进行校验。
Immutable principles: 不可变原则——规则禁令，永远不能被自动关闭（例如，禁止删除备份或在无备份的情况下重启数据库）。在压力下限制代理以降低 MTTR。
Mutable rules: 具有精确作用范围的可变规范，可以通过正式程序撤销或重写。必须包含 6 个字段：incident_type、pipeline_phase、permitted_actions、max_scope、ttl、rollback_condition。
Governance protocol: 管理协议，描述对宪法进行变更的投票（公投）程序。包括角色（Verifier、Implementor、Safety）、投票权重、法定人数和打破平局的规则（tie-breaker）。
Ttl (time to live): 可变规则的生命周期。超过此期限后，规则必须被重新审查或延期，以防止出现无期限和被遗忘的授权。
Max scope: 可变规则的最大影响半径（爆炸半径）（例如 single_node 或 single_pod）。防止大规模级联故障。
Rollback condition: 可变规则的自动回滚条件（例如，事件重复发生或 Safety 角色行使否决权）。
Proposal.md: 提交公投的修正案形式。必须包含产生原因、事件上下文、投票和激活条件。
练习题: 名称: 可变规则（mutable_rule）审计
问题: 下面是由开发人员编写的可变规则片段。找出其中导致规则无法被纳入 constitution.md 的关键错误，并解释它们对系统安全性的影响。
- id: db_write_lag_restart
incident_type: "DBWriteLag"
permitted_actions: ["restart_database"]解决方案: 1. 缺少 pipeline_phase：不清楚在哪个阶段（triage、recovery）允许执行该操作。
- 缺少 max_scope：没有影响半径限制。该操作可能应用于整个集群。
- 缺少 ttl：规则变成无期限的。半年后没有人会记得创建它的原因。
- 缺少 rollback_condition：在情况恶化时没有自动回滚机制。
总结：这样的规则过于宽泛，会带来数据丢失风险。
难度: intermediate
名称: 制定 immutable_principles
问题: 为事件自动化项目制定两条不可变原则（immutable_principles）。它们应该是严格的禁令，而不是良好愿望。
解决方案: 正确表述示例：
- 「禁止为释放磁盘空间而自动删除备份」。
- 「禁止在未从监控系统获得两次连续稳定确认（OK）的情况下将事件状态转为 resolved」。
错误示例（建议）：「建议不要在不需要时删除备份」。
难度: beginner
名称: 将规则迁移到新事件（high_memory_usage）
问题: 您需要将处理 node_not_ready 的经验迁移到 high_memory_usage 事件。以 YAML 格式编写一条可变规则（mutable_rule）。允许在 recovery 阶段重启 pod（restart_pod），有效期 14 天，当 5xx 错误增加或内存使用率 >= 90% 时回滚。
解决方案: ```yaml
- incident_type: high_memory_usage
pipeline_phase: recovery permitted_actions: ["restart_pod"] max_scope: "single_pod" ttl: "14d" rollback_condition: "memory_percent>=90% after 2 windows or 5xx increases"
难度: advanced
案例研究:
名称: NodeNotReady 事件的自动修复
场景: 在生产环境中经常出现 NodeNotReady 事件。AI 代理为最大限度缩短停机时间（MTTR），建议在无人参与的情况下自动重启节点和代理。
挑战: 在响应速度与安全性之间取得平衡。如果代理重启了错误的节点，或在没有备份的情况下干预了有状态工作负载，停机时间将会延长，数据可能会丢失。需要一个正式的关卡。
解决方案: 团队引入 constitution.md。在 immutable_principles 中写入禁止在无备份的情况下触碰有状态工作负载的禁令。在 mutable_rules 中添加 'soft_restart_agent'，严格设置 max_scope: 'single_node'、ttl: '30d'，并在重复故障时设置回滚条件。创建一个具有法定人数（2 票 approve）和 Safety 角色否决权的 governance_protocol。
结果: 代理获得了快速响应已知问题（软重启）的能力，但如果它试图执行危险操作（硬重启数据库）或超出影响区域，系统会自动阻止它。
经验教训:
恢复速度（MTTR）不应以绕过审计和备份为代价。
每项自动修复的授权都必须具有有效期（ttl）和有限的影响半径（max_scope）。
没有回滚条件的可变规则会变成无期限且危险的后门。
相关概念:
immutable_principles
mutable_rules
max_scope
名称: 宪法关卡：proposal.md 校验
场景: 监控系统在过去 48 小时内记录了 3 个具有相同 pattern_id 的未知事件。已启动代理公投流程以创建新规则。
挑战: 确保提交给宪法的修正案（proposal.md）不违反基本安全不变式，并包含可追溯性（provenance）所需的所有必要信息。
解决方案: 使用可执行类比（check.py 脚本）。Coordinator 代理准备带有证据的 proposal.md。然后该脚本读取宪法和提案，检查新规则是否包含所有 6 个字段。Verifier 角色检查形式逻辑，Safety 评估扩大影响半径的风险。
结果: 脚本输出 verdict：PASS 或 BLOCK。如果规则被通过，则在 change_log 中记录 version、parent_version、投票结果（votes）、decision_hash 和 activation_time。创建了可追溯的决策谱系。
经验教训:
没有来源（未记录原因和上下文）的修正案不属于安全流程的一部分。
使用脚本自动检查规则比在压力下人工审查更可靠。
修订的谱系必须包含加密哈希（decision_hash），以防止未经授权的历史篡改。
相关概念:
governance_protocol
change_log
decision_hash
学习建议:
首次阅读时，请停留在「核心概念」部分，然后进入实践。完整轨道（公投、哈希、仲裁）建议在巩固基础后再学习。
在制定不变式时，应使「即使能降低 MTTR，代理也无法执行什么操作？」这个问题的答案存在于文件正文中，而不是在与开发人员的聊天中。
请在早期阶段使用校验脚本（check.py）。如果脚本阻止了您的提案（verdict: BLOCK），它会立即指出缺失的字段（ttl、max_scope）。
当将规则从一个域迁移到另一个域时（例如，从 node_not_ready 到 high_memory_usage），应调整回滚条件（rollback_condition），而不是盲目复制它们。
附加资源:
提案模板（proposal.md）：book2/examples/templates/proposal.md——使用此模板来起草您提交给宪法的首批提案。
宪法校验脚本：book2/examples/constitution/scripts/check.py——用于检查 YAML 文件是否符合 6 个必需字段的可执行类比。
第一卷第 6 部分：关于创建产品规格说明（mission.md、tech-stack.md、roadmap.md）的参考，这些说明不会被 constitution.md 取代。
第一卷第 18 部分：SDD 流程安全的基础，解释为什么危险操作必须通过正式的关卡。
摘要: 项目宪法（constitution.md）是一个关键的安全边界，将 AI 代理可以适应的内容与它无权禁用的内容区分开来。它由保护数据和审计的不可变不变式（immutable_principles），以及必须具有严格边界（max_scope）、生命周期（ttl）和回滚条件的可变规范（mutable_rules）组成。要通过本主题的考核，只需创建一个最少包含两条禁令、一条覆盖 6 个字段的可变规则和简短管理协议的最小文件，确保代理权限的任何扩展都是可追溯且有依据的。