constitution

用户输入

$ARGUMENTS

在继续之前，你必须考虑用户输入（如果不为空）。

语言要求

• 章程内容、同步影响报告、变更理由和最终摘要都必须使用简体中文。
• 版本号、占位符、文件路径和其他机器可读标识在需要时保持不变。

概述

你正在更新项目宪章文件 .specify/memory/constitution.md。该文件是一个模板，包含方括号占位符（例如 [PROJECT_NAME]、[PRINCIPLE_1_NAME]）。你的任务是：(a) 收集或推导具体值，(b) 精确填充模板，(c) 将修订同步到受影响的相关制品。

说明：如果 .specify/memory/constitution.md 尚不存在，它应已在项目初始化时由 .specify/templates/constitution-template.md 创建。如果缺失，请先复制模板。

请遵循以下执行流程：

第 1 步：加载现有章程

读取 .specify/memory/constitution.md，识别所有形如 [ALL_CAPS_IDENTIFIER] 的占位符 token。

重要：用户可能需要比模板中更多或更少的原则。若用户明确指定了数量，请按其要求调整，不要强制遵循模板原则数量。

第 2 步：收集或推导占位符的值

• 如果用户输入（对话内容）已提供了具体值，优先使用。
• 否则从现有仓库上下文（README、docs、历史章程版本等）中推断。
• 治理日期处理：RATIFICATION_DATE 为原始批准日期（若不知则询问或标记 TODO），LAST_AMENDED_DATE 如有改动则为今日，否则保留原值。
• CONSTITUTION_VERSION 必须按语义化版本规则递增：
  • MAJOR：向后不兼容的治理变更，如删除或重定义已有原则。
  • MINOR：新增原则/章节，或对现有指导内容做实质性扩展。
  • PATCH：措辞澄清、错字修复、非语义性细化。
• 若版本升级类型不明确，请先向用户说明推断理由再最终确定。

第 3 步：起草更新后的章程内容

• 用具体文本替换所有占位符（不得留有括号 token，除非项目明确选择暂不定义某项——此时须在报告中注明原因）。
• 保持标题层级与模板一致；注释若已被替换可移除，除非仍有指导意义。
• 每个原则章节须包含：简明原则名称行、捕捉不可妥协规则的段落或列表、显式理由说明（若显而易见则可省略）。
• 治理章节须列出修订程序、版本策略和合规审查预期。

第 4 步：一致性传播检查

• 读取 .specify/templates/plan-template.md，确保其中"章程检查"或规则与更新后的原则保持一致。
• 读取 .specify/templates/spec-template.md，检查范围/需求对齐——若章程新增或移除了必填章节或约束，则更新之。
• 读取 .specify/templates/tasks-template.md，确保任务分类反映了新增或移除的原则驱动任务类型（如可观测性、版本管理、测试纪律）。
• 读取 .specify/templates/commands/*.md 中每个命令文件（含本文件），验证在需要通用指导时没有遗留特定 Agent 的陈旧引用（如仅限 CLAUDE 的内容）。
• 读取运行时指导文档（如 README.md、docs/quickstart.md 或 Agent 特定指导文件），更新对已变更原则的引用。

第 5 步：生成同步影响报告

更新完成后，在章程文件顶部以 HTML 注释形式前置同步影响报告，内容包括：

• 版本变化：旧版本 → 新版本
• 已修改原则列表（旧标题 → 新标题，如有重命名）
• 新增章节
• 删除章节
• 需要同步更新的模板（✅ 已更新 / ⚠ 待处理），附文件路径
• 若有故意延后的占位项，列出后续 TODO

第 6 步：最终输出前验证

• 不得残留未说明的括号 token。
• 版本行与报告保持一致。
• 日期格式为 ISO 8601（YYYY-MM-DD）。
• 原则表述须为陈述式、可测试，且不含模糊语言（"should" → 替换为 MUST/SHOULD 并附理由）。

第 7 步：写回章程文件

将完成后的章程内容覆盖写回 .specify/memory/constitution.md。