release

发布

请严格按顺序通过各项关卡，以准备并完成发布。为以下每个步骤创建一个待办事项，并按顺序处理。

**停止规则：**任何步骤失败都必须立即停止——准确报告失败内容和剩余事项，并保持仓库未发布。不得进行部分发布：构建未通过不得创建标签，不得为不存在的构件编写说明，也不得“打完标签再修复”。

终止拒绝与停止规则：停止规则触发失败后，只询问一次用户是否发出明确的终止拒绝。若是 → 必须使用 record-decision 子技能，判定结果为 release-reject，Boundary-Type: release，并在行内提供持久证据；保持仓库未发布。若否、沉默或表示“之后再修复” → 不得创建决策记录（仅因机械性停止并不构成终止判定）。如果用户在版本或标签审批阶段拒绝，同样适用 release-reject 移交。停止规则不变：不得进行部分发布。

从 docs/agents/project.md 读取仓库的命令（验证命令、发布步骤、冒烟测试命令）。如果该文件不存在，请说明这一点，建议使用 setup-repo，并在继续之前向用户索取这些命令。

a. 验证关卡

按顺序运行所有验证命令——类型检查、lint、单元测试、端到端测试——以及追踪检查（必须使用 trace 子技能）。所有检查现在都必须重新运行并通过；之前通过的运行不算数。追踪检查必须干净：已实现的需求若没有覆盖它的测试，就属于未追踪需求；未追踪需求会阻止发布。

**完成条件：**每条命令都有一次刚刚运行且通过的记录，并且你已阅读其输出。

b. 整理变更日志

查找上一个发布标签（git describe --tags --abbrev=0），并收集 git log <last-tag>..HEAD 的结果。按需求 ID trailer 分组提交（Implements: CODE-N.M、Guards: CODE-N.M）：对于每个引用的 ID，查阅 docs/specs/ 中的需求文本，使条目描述已交付的行为（例如“模块选择会在多次启动之间保留 — SHELL-1.2”），而非提交说明。Guards 归入“受保护行为”分组。没有 trailer 的提交按原样放在 Misc 部分。

如果没有先前的标签，范围就是整个历史记录；请说明这一点。

**完成条件：**已有按需求组织的变更日志草稿，并已展示给用户。

c. 提议版本升级

根据变更日志，按照语义化版本规则进行判断：移除或更改公开行为 → 主版本；交付新需求 → 次版本；仅有修复和保护项 → 修订版本。说明理由并提出建议版本。版本号由用户批准——用户未明确回复时不得继续。

**完成条件：**用户已批准一个确切的版本字符串。

d. 更新版本文件和变更日志

将已批准的版本写入项目的版本文件（清单、锁文件〔若该生态系统要求〕、任何硬编码的版本常量），并将变更日志条目添加到变更日志文件开头（如果仓库中没有该文件，则创建 CHANGELOG.md）。将这些内容一并提交。

**完成条件：**发布提交已创建，且 git status 显示工作区干净。

e. 构建

严格按 docs/agents/project.md 中的顺序执行发布步骤。不得自行修改标志或替换命令；步骤含糊不清即视为停止规则下的失败。

**完成条件：**所有发布步骤均已成功执行，且构件已存在。

f. 对构件进行冒烟测试

测试已构建的构件，而不是源代码树：如果项目配置了冒烟测试命令，就运行该命令；否则，与用户一起执行简短的手动检查清单（安装并启动构件、验证核心流程），并取得用户的明确确认。

**完成条件：**冒烟测试命令已通过，或用户已确认检查清单。

g. 创建标签并推送

仅在用户明确批准后执行（此批准即发布的成功终端判定）：

1. 必须使用 record-decision，并提供 verdict release-approve、Boundary-Type: release、Accountable 深度输入，以及汇总版本／构建／冒烟测试／标签批准的证据行（整个发布只记录一次——绝不为每项中间批准分别创建记录）。必须先发布，再创建标签。
2. 如果发布失败：不要创建或推送标签；报告该 verdict 未执行。
3. 成功后：创建标签（git tag <version>），推送发布提交和标签，然后在记录信封中追加： Execution-Outcome: tag <ref-name>@<object-id> pushed <UTC>。

**完成条件：**标签已存在于远程，且发布决策记录引用了该标签（或者已明确拒绝／停止发布，且未创建标签）。

h. 起草发布说明

将变更日志条目转换为跟踪器的格式的发布说明（例如 gh release create --draft，或用于手动发布的说明文件）。保留按需求分组的结构。除非用户要求发布，否则将发布保持为草稿。

**完成条件：**草稿说明已创建，并已向用户说明其 URL 或路径。

i. 更新规格状态

必须使用 sync-spec，将已交付功能的需求状态改为 Status: Shipped，并更新 docs/specs/INDEX.md。

完成条件：sync-spec 的结束跟踪报告无问题。