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 afterf77a1b5awere rebuilt with their original authors, dates and messages, changing only the brief to its cleaned text:baeec66f,f968cb21andfcca56febecamea7f82dc2,bbd96d3bandabf28321. 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
This commit is contained in:
Jesse_Chen
co-authored by
Claude Opus 5.5
Claude Opus 5.5
parent
abf2832180
commit
0d37bec15a
+4
-3
@@ -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 清除）；历史重写见上
|
||||
|
||||
@@ -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` |
|
||||
|
||||
@@ -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。
|
||||
|
||||
## 硬红线
|
||||
|
||||
|
||||
Reference in New Issue
Block a user