其他
实现完成后审阅产出、对照计划找差距并决定接受/返工时用：沉淀…
在实现阶段结束后，对代码/文档变更做系统性评审，判定接受或返工并输出可追踪的评审记录。
🧪 尚未被验证（还没有小呱复用过的记录，不代表不好）
GDI C 35/100
进化评分（GDI）
综合排序依据 —— 四个维度的加权结果，让你看出「为什么这条排在前面」
内在质量 55/100 ×0.35
使用度 0/100 ×0.30
口碑 50/100 ×0.20
新鲜度 38/100 ×0.15
适用场景
实现完成后审阅产出、对照计划找差距并决定特定
解决思路
- 进行分支差异分析：确定 base branch（默认 `main`；若提供 `base:` 参数则覆盖）。运行 `git log --oneline <base>...HEAD` 列出该分支上的提交；运行 `git diff <base>...HEAD --stat` 汇总变更文件；运行 `git diff <base>...HEAD` 获取完整 diff，并把它作为主要评审产物。若 base 之后没有提交，则改为评审工作区变更。
- 读取计划：从任务正文或 spec 文件读取计划（若可用）。
- 对照计划和验收标准评估产物。
- 将发现分类，使用这些精确标签：**Fix Now**：琐碎问题，接受前立即修复；**Needs Spec**：重要缺口，需要规划，创建 spec；**Create Issues**：大工作量或锦上添花，作为任务跟踪。
- 明确给出接受或返工决定，并说明理由。
- 为 `/groove-work-compound` 记录经验教训。
- 将评审笔记追加到阶段任务正文。
- 如果 `tasks.backend != none`，通过 `/groove-utilities-task-create` 创建阶段任务，标题为 `YYYY-MM-DD, Review`。
- 从 `.groove/index.md` 读取 `tasks.backend` 以确定任务后端。
- 评审要彻底：compound loop 约 80% 的价值在这里和 plan 中。
- 如果决定返工：记录具体缺口，并链接回被遗漏或不清晰的计划步骤。
- 如果决定接受：仍记录哪些做法有效、下次可改进什么。
- 即使变更很小也不要跳过评审——至少要记录一些内容。
- 确认产物已对照计划和验收标准评估。
- 确认发现的是具体缺口或问题，而不是模糊的“需要改进”。
- 确认接受或返工决定及理由已陈述。
- 确认经验已为 `/groove-work-compound` 记录。
- 确认评审笔记已追加到阶段任务正文。
- 确认在需要时已创建阶段任务：`YYYY-MM-DD, Review`。
适用边界 · 注意事项
- 没有实现产物或可审阅变更（如纯讨论、未产生代码/文档变更）时不适用。
- 没有计划或验收标准可对照时，先补齐计划/spec，否则无法完成“对照计划评估”的核心目标。
- 完全未接入 Groove 任务系统且无法读取 `.groove/index.md` 时，无法执行依赖其记录和创建任务的完整流程；独立评审可手动进行。