已完成提交的信息冗长过时时，重写为可独立交接的干净提交信息

用户已决定提交且提交已存在，但提交信息冗长、陈旧或充满琐事，希望仅凭 `git log` 就能交接时使用。

适用场景

解决思路

1. 仅在用户主动调用后运行，并且只在已经决定提交之后运行；不要让代理因为拥有清理工具而偏向于本不该提交的提交。
2. 把已完成提交的信息重写成干净、可交接的版本，让新会话仅凭 `git log` 就能继续，无需读 diff；只精炼作者已有的写法。
3. 只移动提交信息，以及按日期规则移动时间戳；目录树永不改变。
4. 确定目标范围：通常是 `HEAD`，有时是一个短的未推送提交范围。
5. 读取改动：使用 `git show --stat`、`git diff`，并读取任何已记录的提交规则。
6. 采样目标提交附近非目标的提交信息：先从 10 条开始，如果约定明显就提前停止，或者只在约定不清楚时继续扩展，直到约定清楚。
7. 遇到混杂日志时按顺序解决：已记录的项目规则，然后是涉及同一区域的附近提交，再然后是在该约定内的同作者提交；不要平均不兼容的风格，也不要让某个作者的习惯覆盖仓库约定。
8. 按 commit-economy 重写信息：只保留对交接有长期价值的事实，把支撑性改动折进它们所服务的改动中，删掉 diff 或 tag 已经证明的内容，琐碎内容不单独给 bullet。
9. commit-economy 的具体标准：每个真实且持久的改动一个 bullet，支撑性编辑折入；不写 diff 或版本已证明的内容；不加 co-author tags；匹配本地日志的形状（按前述采样）。
10. 如果采样未发现固定形状，则回退为：subject line、空行、每个改动一个 `-` bullet，且每个 bullet 保持单行不换行；不要用散文段落，因为日志适合列点而不是解释。
11. 对于文档化清单已强制要求、适用于该形态任何改动的步骤（例如注册新 skill、源文件编辑后同步翻译文档），把它视为流程已运行的证明，而不是本次改动的事实：可折成所服务 bullet 的末尾从句；如果该 bullet 已暗示它，则删除；只有当执行方式本身不显然时，才给它单独的 bullet。
12. 同样的标准也适用于第一版草稿；re0-git 只会在信息已经偏离该标准时执行清理。
13. 重新提交并签名，日期按位置规则：对 tip（`HEAD`）使用 `git commit --amend -S --date=now`；`--date=now` 会把作者日期移到当前时间；裸 `--amend` 只重置提交者日期，会让作者日期过期。
14. 对更早的提交，要保留其日期：用 `GIT_AUTHOR_DATE`/`GIT_COMMITTER_DATE git commit-tree <tree> -p <parent> -S -m "<new message>"` 重建它，然后把每个后代重放到重建后的提交上（非 tip 重写是 rebase，不是移动 ref），否则会让后代变成孤儿。
15. 只处理提交信息：目录树必须保持逐字节一致（`git diff <old> <new>` 为空）；不要在 re0-git 流程中编辑内容。
16. 日期按位置处理，并始终 gpg-signed：正在收尾的 `HEAD` 的作者日期和提交者日期都设为 now，因为重新清理最新提交本身就是继续工作；每个更早的提交（`HEAD~1` 及更早）保留原始作者日期 + 提交者日期，绝不重设过去的时间。
17. 不要创建或建议提交；re0-git 只重写已存在提交的信息。
18. 未经明确确认，不要重写已推送或共享的历史，因为这会强制 force-push。
19. 验证并报告。
20. 验证：`git diff <old-tip> <new-tip>` 为空，确认内容未变。
21. 验证：每个被重写的提交都已 gpg 签名（`%G?` = `G`），并且日期符合预期。
22. 验证：只看 `git log`（隐藏 diff）再读一遍；如果被删掉的某行对于跟随改动仍然是必要的，就恢复它。

适用边界 · 注意事项

• 不要用于尚未提交的改动，或把它作为创建/建议新提交的理由；它只重写已经存在的提交信息。
• 不要用于修改文件内容；一次 re0-git 流程中目录树必须保持不变。
• 未经明确确认，不要用于已推送或共享历史，否则会要求 force-push。