批量 rm untracked 文件 — 安全清单¶
背景：v0.10.112 时 Write 新 ISSUE-0074 文件后，跑「清理 130 个 untracked 中文副本」脚本时 一并删掉了刚 Write 还没 git add 的 ISSUE-0074。commit message 写「ISSUE-0074」但文件实际不存在。 直到 5 个版本后 v0.10.117 才被用户审计发现（ISSUE-0079）。
反模式（红信号）¶
# ❌ 危险：盲删所有 untracked
git ls-files --others --exclude-standard | xargs rm
git clean -fd
# ❌ 同样危险的变体
find . -name '*.tmp' -delete # 如果当前会话有 Write 但未 add 的同模式文件
为什么危险：
- 同会话内 Write 工具创建的新文档（rule / issue / spec）此时是 untracked
- 你想删的"旧 untracked"（编辑器临时文件 / 误生成）和"新 untracked"（刚 Write 的文档）git 视角无法区分
- 一刀切删 → 工作成果丢失，且 commit message 的 ISSUE-XXX 引用变假
正模式（绿信号）¶
步骤 1：先 git add 本会话所有刚 Write 的文档¶
git add docs/issues/ docs/rules/ docs/specs/ # 把新文档先入 index
git status --short | grep "^A " # 确认新文档已 add
步骤 2：dry-run 看要删的清单¶
git clean -fdn # n = dry-run，列出会删的清单
# 或者
git ls-files --others --exclude-standard docs/ # 看 untracked 列表
人肉审一遍：清单里是否有你想保留的文件？
步骤 3：用具体 pattern，不要盲删¶
# ✅ 只删特定模式（如 v0.10.110 的中文 untracked 副本）
git ls-files --others --exclude-standard docs/ | grep -E '中文|Chinese-pattern' | xargs rm
# ✅ 用 git clean 的精确 pathspec
git clean -fd docs/changelog/ -e '*.md'
步骤 4：commit 后用 git log 反向校验¶
# 看 commit message 提到的 ISSUE 是否真在 commit 里
git show HEAD -- 'docs/issues/' | head -20
git log --all --diff-filter=A --name-only -- 'docs/issues/0074*'
决策表¶
| 你要做什么 | 命令 | 风险 |
|---|---|---|
| 删特定 git mv 残留 | find ... -name 'specific' -delete |
低（pattern 精确） |
| 清编辑器临时文件 | .gitignore + git clean -fdX（X = ignored only） |
低 |
| 删本次脚本误生成的 untracked | 必须先 add 真文档，再 git clean -fd |
高 |
| 重置工作区 | git stash -u 比 git clean 安全（可恢复） |
中 |
必问清单¶
跑任何 rm <untracked> / git clean -fd / xargs rm 之前：
[ ] 本会话有用 Write 工具新建文档吗？ → 先 git add
[ ] 我打算用什么 pattern？这个 pattern 是否过宽？
[ ] 跑了 dry-run（-n / ls-files）确认清单了吗？
[ ] commit message 里要引用的 ISSUE-XXX 文件是否真存在？
与已有 rule 的关联¶
version-release-flow.md：发版流程 — 加 "commit message 与 git tree 对账" 步骤per-version-sinking-checklist.md：每版本沉淀检查表 — 加 "本版 commit message 引用的 ISSUE / SPEC 文件是否真存在"
教训¶
- "新建文档先 git add"是最便宜的保护 — 即使后续误操作也能 stash/checkout 找回
- commit message 是契约，文件存在是兑现 — 二者必须一致
- 元 bug（meta-bug）比 product bug 难发现 — 工作流不一致没人会主动看，要靠制度
- 用户审计沉淀质量的眼力是最后防线 — 但不该常态依赖