diff --git a/docs/BUG_HISTORY.md b/docs/BUG_HISTORY.md
index 7a10ed2b..2c71261a 100644
--- a/docs/BUG_HISTORY.md
+++ b/docs/BUG_HISTORY.md
@@ -13298,7 +13298,7 @@
 
 ## BUG-1008 | 任务书写入真实个人出生资料并推到 staging
 
-- 状态：mitigated（HEAD 已清除；staging 历史仍含该资料，是否重写由产品负责人决定）
+- 状态：mitigated（staging 历史已重写，不再含该资料；旧提交在 Gitea 上仍可按 SHA 匿名访问，待服务器垃圾回收）
 - 首次发现：2026-09-23
 - 最近更新：2026-09-23
 - 影响面：`docs/tasks/TASK-report-density-20260922.md`，自 staging `baeec66f` 起；Gitea staging 历史。GitHub 只读镜像最后同步于 2026-08-14（`12414971`，落后 1,314 个提交），**尚未包含**这份资料。
@@ -13308,7 +13308,8 @@
 - 修复：两处改为不含资料的描述（`TASK-report-density-fix-20260923` 同一提交）。
 - 验证：修复后在 staging-docs 树上重跑同一扫描，只剩 1 处，为新 fixture 的数值碰撞（已独立重跑确认是虚构输入的引擎时间戳，见 BUG-1010）。
 - 防复发：凡是写入实测数字的文档，推送前必须跑 `python3 -m pytest tests/test_repo_privacy_markers.py -q`，结果写进提交说明。实测段落只写"真实个人资料"或虚构 / 公开名人输入，不写具体值。建议（需产品负责人决定，涉及 `.gitea/workflows/**`）：让纯文档推送也跑隐私扫描。
-- 未决：`baeec66f` 的 blob 仍在 staging 历史里。清除需要强推重写 staging，会连带改写 `f968cb21`。在决定之前 GitHub 镜像不得重新同步。
+- 历史清除：产品负责人 2026-09-23 决定清除。按原作者、日期与说明重建泄漏之后的三个提交，唯一改动是该任务书换成已清理版本：`baeec66f`→`a7f82dc2`、`f968cb21`→`bbd96d3b`、`fcca56fe`→`abf28321`，以 `--force-with-lease` 推送。核对：新旧 head 的树逐字节相同；泄漏 blob 在新历史中出现 0 次；此前没有其他分支建在该段历史上。
+- 未决：Gitea 仓库可匿名访问，旧 SHA 的 raw 地址重写后仍返回 200。须 Gitea 管理员执行服务器垃圾回收，之后以匿名请求确认返回 404 才可改 resolved。在此之前 GitHub 只读镜像不得重新同步。
 - 相关记录：BUG-999
 - 复发自：无（与 2026-09-20 的本仓个人案例清除属同一类资料）
-- 修复版本：`docs(tasks)` 验收提交（本条所在提交）
+- 修复版本：`abf28321`（HEAD 清除）；历史重写见上
diff --git a/docs/tasks/README.md b/docs/tasks/README.md
index b948dbb9..9b5e9a2d 100644
--- a/docs/tasks/README.md
+++ b/docs/tasks/README.md
@@ -169,7 +169,7 @@
 
 | 任务书 | 进度 | 主题 | 状态 | 落点 |
 | --- | --- | --- | --- | --- |
-| `TASK-report-density-20260922.md` | `PROGRESS-report-density-20260922.md` | **报告信息密度与原始附录（BUG-1003～1007）**：与源头仓 PL9 全量报告同资料实测：对照 847,632 字符 / 8,044 表格行，我方 309,357 / 1,478。缺口不在引擎——20 张分盘全表、KP 四表、Ashtakavarga 四类、Shadbala 六分量、Avastha、Sahams、年度都已算得出，但 `personal-report-contract.ts` 的 `REPORT_SECTION_KINDS` **没有表格类型**、`CHART_IDS` 只有 9 种，这些表在产品页报告里没有落脚字段。另测出对外原始附录泄漏 925 种 / 3,797 处工程标识符（`parameter_sensitive` 697、`cmd_full_reading` 68、`PyJHora`/`JHora` 35、`PL9` 页码 59），对照物同项为 0。**产品 2026-09-22 三点拍板**：层 1 按 8 组表 + 分盘扩到 16 张；层 2 原始附录直接给 C 端且先全显示；B 类大运族要显示。**决策记录已写明推翻 BUG-999 的两条红线**（专业参考不得作普通下载 fallback；`parameter_sensitive`/「参数敏感」命中整行剔除）——**仅限附录通道**，普通正文投影不动。硬红线：表格层服务端装配、writer 不得写表；对照物的替代大运族日期与 Shadbala 分量在源头仍未闭环（506 行 date mismatch、`production_tuning_allowed=false`），不得照搬升级。让步顺序与串行依赖（任务 3 → 任务 4 同改契约）见任务书 | **验收未通过**（2026-09-23）：任务 1/2/4/5 通过；任务 3 事实表在普通报告里显示 447 个引擎键路径（P1）；隐私门新增失败（任务书自身写入真实出生资料 BUG-1008 已清 HEAD，fixture 数值碰撞待登记）；BUG-1003～1007、PROGRESS、testing 清单缺失。Node 22 前端 0 新增失败、`/` Static、gzip +0.007% | 实现 `f968cb21`（已在 staging，门禁 run 2854 红，未部署）；修复单 `TASK-report-density-fix-20260923.md` |
+| `TASK-report-density-20260922.md` | `PROGRESS-report-density-20260922.md` | **报告信息密度与原始附录（BUG-1003～1007）**：与源头仓 PL9 全量报告同资料实测：对照 847,632 字符 / 8,044 表格行，我方 309,357 / 1,478。缺口不在引擎——20 张分盘全表、KP 四表、Ashtakavarga 四类、Shadbala 六分量、Avastha、Sahams、年度都已算得出，但 `personal-report-contract.ts` 的 `REPORT_SECTION_KINDS` **没有表格类型**、`CHART_IDS` 只有 9 种，这些表在产品页报告里没有落脚字段。另测出对外原始附录泄漏 925 种 / 3,797 处工程标识符（`parameter_sensitive` 697、`cmd_full_reading` 68、`PyJHora`/`JHora` 35、`PL9` 页码 59），对照物同项为 0。**产品 2026-09-22 三点拍板**：层 1 按 8 组表 + 分盘扩到 16 张；层 2 原始附录直接给 C 端且先全显示；B 类大运族要显示。**决策记录已写明推翻 BUG-999 的两条红线**（专业参考不得作普通下载 fallback；`parameter_sensitive`/「参数敏感」命中整行剔除）——**仅限附录通道**，普通正文投影不动。硬红线：表格层服务端装配、writer 不得写表；对照物的替代大运族日期与 Shadbala 分量在源头仍未闭环（506 行 date mismatch、`production_tuning_allowed=false`），不得照搬升级。让步顺序与串行依赖（任务 3 → 任务 4 同改契约）见任务书 | **验收未通过**（2026-09-23）：任务 1/2/4/5 通过；任务 3 事实表在普通报告里显示 447 个引擎键路径（P1）；隐私门新增失败（任务书自身写入真实出生资料 BUG-1008 已清 HEAD，fixture 数值碰撞待登记）；BUG-1003～1007、PROGRESS、testing 清单缺失。Node 22 前端 0 新增失败、`/` Static、gzip +0.007% | 实现 `bbd96d3b`（原 `f968cb21`，09-23 为清除 BUG-1008 重写历史；已在 staging，未部署）；修复单 `TASK-report-density-fix-20260923.md` |
 | `TASK-report-density-fix-20260923.md` | — | **报告密度验收修复单（BUG-1009/1010 + 补写 1003～1007）**：F1 事实表改成真正的表（逐组规定列，普通报告可见格 0 个引擎键 / 0 个下标 / 最多 2 位小数，`sourcePath` 保留供回查；主运年数不得填出生剩余年数）；F2 按既有机制登记 fixture 的数值碰撞（已独立重跑确认是虚构输入）；F3 补 Bug 历史 / PROGRESS / 真人清单并更正「未提交推送」；F4 两份清洗规则只留一份（Python 版漏第三方页码）；F5 writer 写表拦截补测试与提示；F6 事实表可打印。硬红线：不得弱化隐私扫描、不得强推或重写 staging（历史清除由产品负责人决定）；Sade Sati 三轮日期是原任务书错误、不在本单 | **待领取** | — |
 | `TASK-report-sectioned-generation-20260830.md` | `PROGRESS-report-sectioned-20260830.md` | 分章节生成 | 已合入 | 见 PROGRESS |
 | `TASK-report-skill-parity-20260901.md` | `PROGRESS-report-skill-parity-20260901.md` | 内容对齐 skill 解读深度 | 已验收 | `90bad10d`、`ef1bd6df` |
diff --git a/docs/tasks/TASK-report-density-fix-20260923.md b/docs/tasks/TASK-report-density-fix-20260923.md
index be4cf30a..b804f4dc 100644
--- a/docs/tasks/TASK-report-density-fix-20260923.md
+++ b/docs/tasks/TASK-report-density-fix-20260923.md
@@ -2,7 +2,7 @@
 
 ## 基线 commit
 
-- 被验收实现：`f968cb21`（`feat(report): add dense personal report appendix`，已在 `origin/staging`，**未部署**：staging 门禁 run 2854 红，`/api/health` 仍为 `1bc6a954`）
+- 被验收实现：`bbd96d3b`，原 SHA `f968cb21`（2026-09-23 为清除 BUG-1008 重写 staging 历史：原 `baeec66f`→`a7f82dc2`、`f968cb21`→`bbd96d3b`、`fcca56fe`→`abf28321`，代码逐字节不变）（`feat(report): add dense personal report appendix`，已在 `origin/staging`，**未部署**：staging 门禁 run 2854 红，`/api/health` 仍为 `1bc6a954`）
 - 原任务书：`docs/tasks/TASK-report-density-20260922.md`
 - 修复分支：`codex/report-density-fix-20260923`，从 `origin/staging` 起
 - 验收基线：`f77a1b5a`（实现的父提交）
@@ -44,7 +44,7 @@
 
 ### P1-B · 隐私门新增失败
 
-扫描在 `f968cb21` 上命中 3 处：
+扫描在该实现（原 `f968cb21`）上命中 3 处：
 
 | 规则 | 文件 | 行 | 定性 |
 |---|---|---:|---|
@@ -93,7 +93,7 @@
 - 本修复单不推翻任何既有决策。原任务书的三条产品拍板与对 BUG-999 的两处推翻（仅限附录通道）继续有效。
 - P1-A 明确：**事实表属于普通报告，普通报告的可见文字不得出现引擎键名、数组下标或内部路径**。可追溯性保留在每行的 `sourcePath` 字段里（机器可读、不渲染）。
 - Sade Sati 三轮日期：原任务书写"已逐项确认 packet 中存在"是**撰写者的错误**。packet 里只有阶段框架（上升 / 高峰 / 下降星座），`scripts/sade_sati.py` 也没有计算三轮起止日期的函数。三轮日期需要新计算，**不在本修复单范围**，维持执行方在 `BLOCKED.md` 的如实记录。
-- 历史清除：真实出生资料仍在 staging 历史的 `baeec66f` 里。清除需要重写 staging（强推），会连带改写 `f968cb21`。**这件事只由产品负责人决定，执行方不得强推、不得 rebase staging。** 在决定之前，GitHub 只读镜像不得重新同步（当前停在 2026-08-14 的 `12414971`，落后 1,314 个提交，尚未包含这份资料）。
+- 历史清除：产品负责人 2026-09-23 已决定清除。staging 历史已重写（见基线段 SHA 对照），新历史中不再含该资料。**旧提交在 Gitea 上仍可按 SHA 匿名访问，须管理员执行服务器垃圾回收**；在确认旧 SHA 返回 404 之前，GitHub 只读镜像不得重新同步。执行方不得再次强推或 rebase staging。
 
 ## 硬红线