docs: BUG-1060 resolved pending deploy, BUG-1061 recorded

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

CHANGELOG.md

@@ -1,5 +1,12 @@
 # 印度占星 Skill 更新日志
 
+## 2026-09-27 — 双重过运的九分盘目标改为检查标签所写的九分盘星座（待验收）
+
+- 双重过运（木星、土星同时激活某宫）的九分盘层以前把「九分盘第 N 宫」算成了九分盘上升，把「九分盘第 N 宫的宫主」算成了这颗星在本命盘的度数。现在两者都按九分盘上的星座判断（BUG-1060）。本命盘层与月亮上升层的结果一个字不变。
+- 影响：报告的「双重过运」一节、普通对话数据卡的双重过运结论，九分盘那几行的命中情况会变，有的盘会多出本命 + 九分盘跨层的条目；48 个核对样本里摘要句都没有变。部署后最多 15 分钟内同一张盘可能仍看到旧结果（chart 缓存）。
+- 同时查出跨层配对按名字里的数字比对、会误配也会漏配（BUG-1061），本轮未修。
+- Skill 版本不 bump（Skill 文本未改）。不改数据库。
+
 ## 2026-09-27 — 普通对话数据卡 v2：年运看年盘、婚恋分三层、每张卡都带九分盘确认（待验收）
 
 - 按懂印度占星的顾问意见调整各张数据卡。每张卡的基础段多了九分盘摘要：九分盘上升、每颗星在九分盘的星座与强弱、是否「同宫」（Vargottama）、本命与九分盘强弱是否反转。

docs/BUG_HISTORY.md

@@ -14281,15 +14281,45 @@
 
 ## BUG-1060 | 双重过运的九分盘「第 N 宫」目标实际检查的是九分盘上升
 
-- 状态：investigating（本单不修：红线不许改既有计算结果；需产品决定是否另开单）
+- 状态：resolved（待部署；分支 `codex/bug-1060-d9-double-transit-20260927`，本机回归通过，staging 未部署）
 - 首次发现 / 最近更新：2026-09-27 / 2026-09-27
-- 影响面：`scripts/jyotish_engine.py` `cmd_double_transit_pac` 的 D9 层；凡调用它的路径（全读 / 报告的 `double_transit_pac`，以及本单起普通对话数据卡的时运、婚恋双重过运结论）。
+- 影响面：`scripts/jyotish_engine.py` `cmd_double_transit_pac` 的 D9 层；凡调用它的路径（全读 / 报告的 `double_transit_pac`，以及普通对话数据卡的时运、婚恋双重过运结论，经 `scripts/consultation_native_layers.py`）。D1 层与月亮上升（CL）层不受影响。
 - 现象：数据卡 v2 接入双重过运（TASK-consult-evidence-card-v2-20260927 T1）时核对 PAC 结果发现：目标名写「D9_7宫(<D9 第 7 宫星座>)」，但用来判定同宫 / 相位 / 合相的经度是 D9 上升星座的中点。用一张公开 AA 盘复现：土星对「D9_7宫」判为「10 宫相位」，按标签所写的 D9 第 7 宫算应无相位，按 D9 上升算才是 10 宫相位。
 - 触发条件：`house` ≠ 1 时的任意一次调用；`house = 1` 时两者恰好相同。
-- 根因：`d9_event_house_lon = (d9_asc_idx * 30) + 15` 用了 D9 上升索引，应为 D9 第 N 宫的星座索引 `d9_event_si`（同函数 D1 层用的是 `event_si`）。已核对代码与一次复现；未核对该函数其余 D9 目标的取法是否合 KN Rao 原意。
-- 修复：未修。数据卡照原生输出复制该函数的结论（不在卡上另行换算）。
-- 验证：—（修复时需加「house ≠ 1 时 D9 第 N 宫目标用 D9 第 N 宫星座」的回归，并按冻结计分清单确认不涉及 ERR-110 的文件）。
-- 防复发：接入原生函数时逐个核对目标名与实际参与计算的值是否一致。
-- 相关记录：无
+- 根因：`d9_event_house_lon = (d9_asc_idx * 30) + 15` 用了 D9 上升索引，应为 D9 第 N 宫的星座索引 `d9_event_si`（同函数 D1 层用的是 `event_si`）。审计同函数其余 D9 目标时另查出一处同类错配：「D9_<宫主>(宫主)」（D9 第 N 宫的宫主）取的是该星的 **D1 度数**，而 D9 层把过境星按 D1 星座叠到 D9 盘、宫位从 D9 上升数，D1 度数放进这个坐标系里既不是 D1 宫也不是 D9 宫。
+- D9 目标逐条决定（依据 `references/marriage-timing-comprehensive-techniques.md` 的 KN Rao 规则「木星 / 土星关联事件宫 / 宫主 / 宫主 D9 星座」与 `strict-workflow-router.md` 的 Double Transit 行）：
+
+  | 目标名 | 修复前参与计算的值 | 决定 | 理由 |
+  | --- | --- | --- | --- |
+  | `D9_{N}宫(<星座>)` | D9 上升星座中点 | **改**为 D9 第 N 宫星座中点 | 标签写的就是 D9 第 N 宫；D1 层同名目标用的是第 N 宫星座 |
+  | `D9_{宫主}(宫主)` | 该星 D1 黄经 | **改**为该星 D9 星座中点 | D9 层所有目标都在 D9 盘的星座上；与同层 `{星}_D9` 目标取法一致 |
+  | `{D1 第 N 宫主}_D9(<星座>)` | 该星 D9 星座中点 | 保留 | 正是 KN Rao「宫主 D9 星座」，标签与值一致 |
+  | `{上升主}_D9(<星座>)` | 该星 D9 星座中点 | 保留 | 标签与值一致 |
+
+  目标名（字典键）一个不改，下游按名字取值的地方不受影响。
+- 修复：D9 目标的构造抽成 `_double_transit_d9_targets(asc_deg, natal, event_house, event_lord, ll_name)`（返回 D9 上升索引与目标表），`cmd_double_transit_pac` 调用它；只改上表两行的取值，D1 / CL 层与跨层判定代码未动。
+- 验证：
+  - 新增 `tests/test_double_transit_d9_targets.py`（7 条，已进快速门 `CORE_PYTEST_TARGETS`），三张公开 AA 盘真实引擎运行：`house` 2–12 时 D9 第 N 宫目标 = D9 第 N 宫星座中点且 ≠ D9 上升中点；`house = 1` 仍等于 D9 上升中点；D9 宫主目标 = 该星 D9 星座中点；命令实际按目标表逐个做 PAC；复现盘 7 宫的土星「10 宫相位」消失、木星「同宫(7宫)」出现。在基线代码上跑这份测试，6 条失败、只有 D1/CL golden 通过。
+  - D1 / CL 层逐字节不变：`tests/fixtures/double_transit_d1_cl_golden.json` 在基线 `5671039a` 上用 `PYTHONHASHSEED=0` 生成，修复后重生成与之逐字节相同（3 盘 × 12 宫）。另用 4 组输入（3 张公开盘 + 报告 golden 的虚构输入）× 12 宫共 48 次直接比对：`d1`、`cl`、`summary` 48/48 不变；`d9` 47/48 变化；`double_transit` 条目 2/48 变化（均为新增 D1+D9 跨层条目）。
+  - 数据卡 golden `frontend/tests/fixtures/consult-evidence-card-golden.json` 用采集脚本重生成：与原文件忽略键序后唯一差异是一张盘双重过运结论 9 → 10 条（家庭 / 年运 / 时运三路相同，新增 10 宫 `Saturn(D1)Venus(宫主) + Jupiter(D9)D9_Venus(宫主)`）。
+- 对报告的影响：报告里「双重过运」一节的 D9 行会变（目标命中与否、D1+D9 跨层条目数）；报告摘要句本轮 48 个样本中无一变化。`frontend/tests/fixtures/report-density-fictional-reader.json` 是 09-23 的冻结快照、没有采集脚本、测试不拿它与现引擎比对，本轮未重生成；按现引擎它的「双重触发条目=2」会变成 4。
+- 部署注意：API 的 chart 缓存（`scratch/local/api_chart_cache`，15 分钟 TTL，键不含代码版本）在部署后最多 15 分钟内可能仍返回旧的 D9 结果。
+- 防复发：接入原生函数时逐个核对目标名与实际参与计算的值是否一致；D9 目标集中在一个可单测的函数里。采集数据卡 golden 用 `JYOTISH_API_CHART_CACHE_TTL_SECONDS=0 PYTHONHASHSEED=0`：chart 缓存按排序后的键存盘，热缓存会改变字典与列表顺序（值不变），09-27 的 golden 正是冷热混合顺序，已写进采集脚本说明。
+- 相关记录：BUG-1061（同函数跨层 D1+D9 判定按数字拼接比对，本轮未修）
+- 复发自：无
+- 修复版本：`codex/bug-1060-d9-double-transit-20260927`（待合入 staging）
+
+## BUG-1061 | 双重过运跨层（D1+D9）判定按目标名里的数字比对，D9 前缀的「9」会误配也会漏配
+
+- 状态：investigating（BUG-1060 审计时发现，本轮不修）
+- 首次发现 / 最近更新：2026-09-27 / 2026-09-27
+- 影响面：`scripts/jyotish_engine.py` `cmd_double_transit_pac` 「跨层 Double Transit」段；报告与数据卡的 D1+D9 结论。
+- 现象：跨层配对用 `''.join(c for c in name if c.isdigit())` 比较 D1 与 D9 目标名。D9 目标名都带「D9」，数字串总含「9」：`D9_7宫(...)` → 「97」，永远配不上 D1 的「7宫」（本意的同宫号跨层配对从不发生）；而 `house = 9` 时 D1 的「9宫(...)」→「9」会与任何 `{星}_D9(...)` / `D9_{星}(宫主)` 配上。实证：数据卡 golden 里一张公开盘 9 宫有一条 `Jupiter(D1)9宫(Cancer) + Saturn(D9)Mars_D9(Capricorn)`，这里的 `Mars_D9` 是上升主的 D9 星座目标，与 D1 第 9 宫不是同一目标，配上只因两边数字都是「9」。
+- 触发条件：任意调用都漏配同宫号；`house = 9` 时误配。
+- 根因：按目标名字符串抽数字判断「同一目标」，未排除层前缀。已核对代码与 golden 一条实例；未评估改法对报告结论数量的影响。
+- 修复：未修。改法需产品决定（例如按目标类型 + 宫号结构化比对），会改变报告和数据卡的跨层条目。
+- 验证：—
+- 防复发：跨层配对不要解析展示用的名字。
+- 相关记录：BUG-1060
 - 复发自：无
 - 修复版本：待定

docs/tasks/PROGRESS-bug-1060-d9-double-transit-20260927.md

@@ -0,0 +1,55 @@
+# PROGRESS · BUG-1060 双重过运 D9 目标错配（2026-09-27）
+
+- 执行方式：直接执行（产品负责人授权子代理修复证据卡工作中发现的引擎 Bug），无单独任务书。
+- 基线：`origin/staging` = `5671039a`；分支 `codex/bug-1060-d9-double-transit-20260927`，工作树 `.worktrees/bug-1060-d9-double-transit-20260927`；未推送。
+- 开工预检：`python3 scripts/pre_work_check.py --remote-timeout 8 --command-timeout 45` 退出 0，六项检查全部 ok（remote_visibility verified）。
+- 冻结计分清单（ERR-110）：`scripts/jyotish_engine.py` 不在 `sealed_holdout_rerun.py` `PRODUCTION_FILES` 与 holdout v2/v3 `frozen_scoring.files` 里；本轮未动任何冻结文件，未动 `scripts/jyotish_api_server.py`。
+
+## 改了什么
+
+| 文件 | 改动 |
+| --- | --- |
+| `scripts/jyotish_engine.py` | D9 目标构造抽成 `_double_transit_d9_targets`；`D9_{N}宫` 改用 D9 第 N 宫星座中点，`D9_{宫主}(宫主)` 改用该星 D9 星座中点；`{宫主}_D9` / `{上升主}_D9` 保留；目标名不变；D1 / CL / 跨层代码未动 |
+| `tests/test_double_transit_d9_targets.py` + `tests/fixtures/double_transit_d1_cl_golden.json` | 新增 7 条回归；D1/CL golden 在基线上生成 |
+| `scripts/run_quality_gate.py` | 新测试进 `CORE_PYTEST_TARGETS` |
+| `frontend/tests/fixtures/consult-evidence-card-golden.json` | 用采集脚本重生成（未手改） |
+| `scripts/research/capture_consult_evidence_card_golden.py` | 只改说明：采集命令加 `JYOTISH_API_CHART_CACHE_TTL_SECONDS=0`（原因见下） |
+
+D9 目标逐条决定与理由见 `docs/BUG_HISTORY.md` BUG-1060。
+
+## 前后对照（公开 AA 盘，研究参考日，raman，mean node）
+
+复现盘 7 宫（D9 上升摩羯、D9 第 7 宫巨蟹）：
+
+| 目标 | 修复前 | 修复后 |
+| --- | --- | --- |
+| `D9_7宫(Cancer)` | 土星「10 宫相位」（实为对 D9 上升的相位）；木星无 | 木星「同宫(7宫)」；土星无 |
+| `D9_Moon(宫主)` | 土星「同宫(3宫)」+「合相 3.08°」（月亮 D1 度数） | 无命中 |
+| `Mercury_D9(Cancer)` / `Jupiter_D9(Gemini)` | 木星同宫(7宫) / 土星 3 宫相位 | 不变 |
+| 摘要句 | 跨层间接 Double Transit | 不变 |
+
+48 次直接比对（3 张公开盘 + 报告 golden 虚构输入，各 12 宫）：`d1`、`cl`、`summary` 48/48 不变；`d9` 47/48 变化；`double_transit` 条目 2/48 变化，都是新增跨层条目——一张公开盘 10 宫新增 `Saturn(D1)Venus(宫主) + Jupiter(D9)D9_Venus(宫主)`；虚构输入 7 宫 2 → 4 条（D9 7 宫主与 D1 7 宫主是同一颗星，两个目标落在同一 D9 星座）。
+
+## Golden
+
+- 数据卡 golden：`JYOTISH_API_CHART_CACHE_TTL_SECONDS=0 PYTHONHASHSEED=0 python scripts/research/capture_consult_evidence_card_golden.py`，两次运行逐字节相同。与原文件忽略键序后唯一差异：一张公开盘双重过运结论 9 → 10 条（family / annual / timing 三路）。
+- 采集可复现性：基线代码连跑采集得到 3 种不同字节（值相同、字典键序与列表顺序不同）。原因是 chart 缓存按 `sort_keys` 存盘，热缓存返回排序后的顺序；原 golden 是冷热混合顺序。TTL 0 让每次都冷算，已写进脚本说明。
+- `report-density-fictional-reader.json`：内含双重过运摘要（「双重触发条目=2」），没有采集脚本、测试不与现引擎比对，本轮未重生成；按现引擎会是 4。
+- 新增 D1/CL golden：在基线工作树（`5671039a`）上 `PYTHONHASHSEED=0 python tests/test_double_transit_d9_targets.py --capture` 生成，修复后重生成逐字节相同。
+
+## 测试
+
+| 项 | 基线 `5671039a` | 修复后 |
+| --- | --- | --- |
+| Python 门禁集（gate-pytest-args）+ `test_consultation_native_layers` + `test_report_reader_main` + `test_report_density_facts` | 971 passed / 1 skipped | 978 passed / 1 skipped（+7 新增；同一条 skip：shadbala 私有 oracle 不随公开版分发；含 growth contract、privacy markers） |
+| `tests/test_double_transit_d9_targets.py` | 6 failed / 1 passed（仅 D1/CL golden 通过） | 7 passed |
+| 前端受影响 4 个文件（evidence-card v1/v2、projection native/timing） | — | 30/30 pass |
+| 前端全量（Node 22.14，`tsx --test tests/*.test.ts tests/*.test.tsx`） | 4174 / pass 4122 / fail 24 / skipped 28 / cancelled 0 | 4174 / pass 4122 / fail 24 / skipped 28 / cancelled 0 |
+
+前端 24 条失败两边按名字逐条相同（全部是需要 Docker / PostgreSQL 的数据库与部署套件），新增失败 0。本轮没有修改任何既有断言。
+
+## 未做 / 另记
+
+- BUG-1061（investigating）：跨层 D1+D9 配对按目标名里的数字比对，同宫号永远配不上、9 宫会误配；改法会改变报告与数据卡条目数，需产品决定。
+- 部署后 chart 缓存（15 分钟 TTL，键不含代码版本）可能短暂返回旧 D9 结果。
+- 环境缺口：无 Docker，数据库 / 部署套件以与基线逐条一致的失败清单代替。

docs/tasks/README.md

@@ -35,6 +35,7 @@
 
 | 任务书 | 进度 | 主题 | 状态 | 落点 |
 | --- | --- | --- | --- | --- |
+| —（子代理直接执行，无任务书） | `PROGRESS-bug-1060-d9-double-transit-20260927.md` | **双重过运 D9 目标错配（BUG-1060）**：D9 第 N 宫目标误用 D9 上升、D9 宫主目标误用 D1 度数，改为标签所写的 D9 星座；D1 / CL 层逐字节不变；数据卡 golden 重采集（一张盘跨层结论 9→10）；另记 BUG-1061 跨层数字比对（未修） | 待验收 | `codex/bug-1060-d9-double-transit-20260927`（未推送） |
 | `TASK-rectification-fewer-probes-card-20260926.md` | [PROGRESS](PROGRESS-rectification-fewer-probes-card-20260926.md) | **减少无效追问 + 卡片区间为主**：引导补件离线新增达标 0 → 上限 6→2、定向题问完门槛未达直接出卡；卡片区间为主标题、代表分钟副标题，第一二名差距 ≥5 个百分点才显示百分比，否则写「目前区分不开」。不放宽任何置信度。先做 | 已验收（真机清单欠） | `4e6e8d87` + 验收补改 `7203d94e`（区分不开时隐藏「最可能」），deploy-staging run 2933 已部署；回放真值 ±30/±60 19→20、宽度中位 ±1 分钟、提问 11.4→7.8；Skill 10.0.30；真机清单 `docs/testing/rectification-fewer-probes-card-20260926.md` 未走 |
 | `TASK-rectification-grounding-20260927.md` | `PROGRESS-rectification-grounding-20260927.md` | **生时校正旁白事实有据 + 去重试 + 资料瘦身**：服务端范围句被裁句裁掉（BUG-1055，复发自 588）；重试按钮盲写不校验→校正里下线（1056）；read-case 超限先删对话记忆（1057）；点选题带经历时范围变化无人说（1058）；offer/compare 剥离推断前数据、报告去重；Skill 按轮次切片、关 skills 注入 | 已验收（真机欠） | `0e0baaa7`…`2efe2258`；BUG-1055～1058；固定开销 12.0K→6.5K token、offer 100K→28.8K 字节；Skill 未 bump |
 | `TASK-rectification-telemetry-20260926.md` | [PROGRESS](PROGRESS-rectification-telemetry-20260926.md) | **匿名聚合统计**：每会话一行只存数字 / 枚举（题数分类、宽度、差距、停止原因、门槛达标、耗时、版本），管理后台只看汇总、保留 180 天；动表须 test:db。排在 fewer-probes 后 | 已验收（后台登录走查欠） | `d0bfc1fc`，门禁 run 2938 含真实 PG 测试通过、migrate 2940、deploy 2941（`e801fcf5`）；只存数字/枚举、不存用户 id；后台「校正统计」页 |