docs(bugs): record the staging history rewrite for BUG-1008

The product owner chose to remove the leaked birth data from staging history.
The three commits after f77a1b5a were rebuilt with their original authors,
dates and messages, changing only the brief to its cleaned text: baeec66f,
f968cb21 and fcca56fe became a7f82dc2, bbd96d3b and abf28321. The new head's
tree is byte-identical to the old one and the leaked blob is absent from the
new history.

The old commits are still served anonymously by their SHA until the Gitea
server garbage-collects, so BUG-1008 stays mitigated rather than resolved.

Privacy scan on this tree before push: one finding, the fixture collision.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017eEAG8HD3mm8gsKXgk8uU8

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` |

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。
 
 ## 硬红线