ISSUE-0079：批量删 untracked 文件误删刚 Write 的新 ISSUE 文档¶

现象¶

v0.10.117 用户审计沉淀质量时发现：

ls docs/issues/ | grep "^007"
0070-shared-window-orphan-storage-race-sw-kill.md
0071-spec006-where-taskid-issue-0008-regression.md
0072-cleanuporphan-kills-user-newtabs.md
0073-export-json-version-hardcode-settings-leak.md
# ↓ 缺 0074 ↓
0075-row-vs-url-dimension-status-mismatch.md
0076-page-vs-site-signal-pollution-in-domain-state.md

但 v0.10.112 commit message 明确写着「ISSUE-0074」， git log 也搜不到 0074 文件的 add 历史：

git log --all --diff-filter=A --name-only -- 'docs/issues/0074*'
(empty result)

结论：ISSUE-0074 文件被 Write 了，但从未进入过 git 索引。

根因 — v0.10.112 commit 流程时序¶

1. Write docs/issues/0074-data-counts-50k-window-truncation-recurrence.md
   状态: untracked（还未 git add）

2. 发现 v0.10.110 git mv 留下的 130 个 untracked 中文文件副本（macOS Unicode 规范化遗留）

3. 执行清理脚本:
   git -c core.quotepath=false ls-files --others --exclude-standard docs/ | \
     while IFS= read -r fn; do rm "$fn"; done

   该脚本删 ALL untracked files in docs/
   ↑ 同时把刚 Write 还没 git add 的 ISSUE-0074 一起删了 ❌

4. git add -A 时 0074 已经不在文件系统上 → 没进 commit
5. commit message 写 "ISSUE-0074" 但文件实际不存在

复盘 — 多个守护机制都没拦截¶

守护	应该拦截但没拦的原因
`docs:check` IDX-1 校验	文件已被 rm，扫不到 → 不会报"INDEX 漏"
pre-commit hook	同上，没有"commit message 引用了 ISSUE-X 但文件不存在"检查
用户最终发现	凭审计「沉淀完整性」的眼力发现，纯人工

修复（v0.10.117）¶

#1 补建 ISSUE-0074（已做）¶

凭 v0.10.112 commit message 和开发日志重写 docs/issues/0074-data-counts-50k-window-truncation-recurrence.md。

#2 新 rule `docs/rules/cleanup-untracked-safety.md`¶

批量 rm untracked 文件前的安全检查（见此 rule）。

#3 强化清理脚本模板¶

未来需要清 untracked 时模板：

# ❌ 危险：盲删所有 untracked
git ls-files --others --exclude-standard | xargs rm

# ✅ 安全：先 git add 已知要保留的，再 git clean -fdn 看清单确认
git add docs/                          # 把刚 Write 的新文档先 add
git clean -fdn                          # dry-run 看要删什么
git clean -fd <specific-pattern>        # 只删指定模式

教训¶

新建文档时先 git add：任何后续的 git clean / rm untracked 不会误删
批量 untracked 操作前必跑 dry-run：git clean -fdn 列出要删的，肉眼审一遍
commit message 与文件状态对账：commit 写 ISSUE-XXXX，对应文件必须真存在
用户审计是最后防线：但代价是用户感知质量问题，不该依赖

这是个元 bug（meta-bug）¶

修复其他 bug 的工作流本身有 bug，会让"修复痕迹"丢失。比 product bug 更严重： - product bug：用户能看见，反馈机制健全 - meta bug：工作流不一致，难以发现，破坏可信度（"commit message 是真的吗？"）

加入 meta-rule 强制规范工作流。