checkpoint-commit

/checkpoint-commit

创建治理检查点提交，以保留进行中的工作状态。分析仓库中的所有更改，验证 .gitignore，并创建与变更请求关联且格式正确的提交。

用法： /checkpoint-commit [CR-XXXX] [summary]

两个参数均为可选项。如果未提供，命令会自动检测 CR ID 并生成摘要。

工作流

按顺序执行以下步骤。

步骤 1：上下文检测

确定 CR 标识符：

• 如果 $ARGUMENTS 中提供了 CR-ID： 使用提供的 CR-ID。
• 如果未提供 CR-ID：
  1. 检查当前 Git 分支名称是否符合 dev/CR-XXXX 之类的模式，或是否包含 CR- 后跟数字。
  2. 如果分支名称中未找到，则使用 git log --diff-filter=M -1 --name-only -- docs/cr/ 检查 docs/cr/ 中最近修改的文件。
  3. 如果 CR-ID 不明确或无法确定，必须提示用户确认。未经确认的 CR-ID，不得继续操作。

步骤 2：分析更改

检查仓库中的所有更改：

# Staged changes
git diff --staged

# Unstaged changes
git diff

# Untracked files
git ls-files --others --exclude-standard

• 必须识别所有已暂存、未暂存和未跟踪的文件。
• 如果没有更改（没有已暂存、未暂存或未跟踪的文件），则报告“没有需要提交检查点的更改”并停止。不得创建提交。

步骤 3：更新 .gitignore

在暂存之前，检查未跟踪的文件并更新 .gitignore，排除以下内容：

• 临时文件（.tmp、.bak、*.log）
• 构建产物（dist/、build/、node_modules/）
• 生成的内容（编译文件、缓存目录）
• 尚未覆盖的 IDE 专属文件

此步骤为必需步骤，用于防止仓库膨胀。如果检测到的未跟踪文件超过 50 个，必须在继续之前征求用户确认。

步骤 4：编写摘要

• 如果 $ARGUMENTS 中提供了摘要： 使用提供的摘要。
• 如果未提供摘要： 分析差异输出并生成“黄金摘要”——用简洁的一句话描述更改。

编写完整的提交消息：

• 主题行： checkpoint(CR-xxxx): {summary}
• 正文： 用项目符号详细说明更改内容及原因。

步骤 5：暂存所有更改

git add -A

步骤 6：创建检查点提交

git commit -m "checkpoint(CR-xxxx): {summary}

{detailed body with bullet points}"

步骤 7：报告

向用户提供结果：

• 提交哈希（通过 git log -1 --format="%H" 获取）
• 已执行操作的摘要
• 提交中包含的文件列表

安全规则

• 不得执行破坏性 Git 操作：git reset、git rebase、git commit --amend、git push --force
• 必须保留所有工作，避免数据丢失
• 必须确保操作具备幂等性，可安全地多次运行
• 必须在暂存之前验证 .gitignore