合并 origin/staging，继续完整数据版第三单的第 1 次打回。

Co-Authored-By: Grok (agent loop)

docs/tasks/README.md

@@ -524,9 +524,11 @@
 | `TASK-chart-dasha-yogini-20261021.md` | — | #88 星盘页大运右栏切换 Chara / Yogini，Yogini 补小运（按比例，内部核对，页面注明未经外部软件核对）；Ashtottari 另立单（起运表与 PyJHora 8/12 宿不一致） | 已合入 staging | `codex/chart-dasha-yogini-20261021` |
 | `TASK-full-data-parity-1-20261021.md` | `PROGRESS-full-data-parity-1-b-20261023.md` | #91 完整数据版补齐（一）：K1–K3 已做；K4 把年运新字段放到原键之后，Yogini 缺完整年数时不再整段失败（BUG-1425、BUG-1426） | 已合入 staging | `codex/full-data-parity-1-20261021` |
 | `TASK-full-data-parity-2-20261021.md` | — | #92 完整数据版补齐（二）：研究型推运附录（Tithi Ashtottari、Yoga / Nakshatra Pravesha、Karana 等，口径换成我方真恒星）、四种星座大运第三层、Kalachakra 第三层（简化模型）、Niryaana Shoola 子运只在有书面出处时做、D81 / D108 / D144 研究型分盘；全部标研究口径，不进对话卡与校正；不设大小上限 | 待执行 | `codex/full-data-parity-2-20261021` |
+| `TASK-full-data-parity-2-fix-20261023.md` | `PROGRESS-full-data-parity-2-20261021.md` | **#92 第 1 次打回**：其余全过（Linux 生成约 18 秒、英文汉字 0）；T5 PyJHora 离线对照一张没做（下限 5 张），报告无法标出不一致的体系 | 待执行 | `codex/full-data-parity-2-20261021` |
 | `TASK-goel-jaimini-strength-20261022.md` | `PROGRESS-goel-jaimini-strength-20261022.md` | #94 搬上游公开的 Goel Jaimini 强度与 Brahma / Maheshwara / Rudra（4 个上游原样文件，按 #81 决策 A 先例根目录预算 448→452；来源串改书目引用）；只做计算、不改报告；冻结身份不变 | 已合入 staging | `codex/goel-jaimini-strength-20261022` |
 | `TASK-chart-subject-table-fix-20261022.md` | `PROGRESS-chart-subject-table-fix-20261022.md` | **#86 第 1 次打回**：报告所有表被强制单行（打印跑出纸面）；保存他人复制了档案页代码且已分叉；点编辑框内边距会丢修改 | 已合入 staging | `codex/chart-subject-table-20261021` |
-| `TASK-full-data-parity-3-20261022.md` | `PROGRESS-full-data-parity-3-20261022.md` | #93 完整数据版补齐（三）：「独立年度方法参考」正式环境调 PyJHora（子进程隔离；装上后其余输出逐字节不变，7 个换路径开关钉死）；输入默认用本地时间与正确年份（D6 默认，未收到「照上游原样」） | 待验收 | `codex/full-data-parity-3-20261022` |
+| `TASK-full-data-parity-3-20261022.md` | `PROGRESS-full-data-parity-3-20261022.md` | #93 完整数据版补齐（三）：「独立年度方法参考」正式环境调 PyJHora（子进程隔离；装上后其余输出逐字节不变，7 个换路径开关钉死）；输入默认用本地时间与正确年份（D6 默认，未收到「照上游原样」） | 第 1 次打回，见修复单 | `codex/full-data-parity-3-20261022` |
+| `TASK-full-data-parity-3-fix-20261023.md` | `PROGRESS-full-data-parity-3-20261022.md` | **#93 第 1 次打回**：功能、隔离、速度都过（Linux 约 20 秒，worker 约 60 MB）；结果指纹排除本章致重算对不上（违反 D2）、源码合同测试没跟改、自己的新测试与 deploy README 打架 | 执行中 | `codex/full-data-parity-3-20261022` |
 | `TASK-synastry-staging-fix-fix-20261022.md` | `PROGRESS-synastry-staging-fix-fix-20261022.md` | **#85 第 1 次打回**（T7～T11 主体通过）：新地址没登记进路由清单致快速门红；CHANGELOG 与 T11 矛盾；侧栏点亮测试是空断言 | 已合入 staging | `codex/synastry-staging-fix-20261021` |
 | `TASK-report-english-han-leak-fix-20261022.md` | `PROGRESS-report-english-han-leak-fix-20261022.md` | **#89 第 1 次打回**：改了冻结的校正打分文件 `jaimini.py`；测试的 PyJHora 屏蔽没传到子进程（测的不是生产那份报告，也是慢的原因）；缺英文时留空藏住漏洞 | 已合入 staging | `codex/report-english-han-leak-20261021` |
 | `TASK-full-data-parity-1-fix-20261022.md` | `PROGRESS-full-data-parity-1-fix-20261022.md` | **#91 A 段第 1 次打回**：新六章 69 节里 16 节在三张虚构盘上整节「未判定」，其中 12 节数据在资料包里、是读错了字段；测试抓不到整节未判定；新六章绕过了报告口径替换；中文附录悄悄丢列和瑜伽条目要量出来 | 已合入 staging | `codex/full-data-parity-1-20261021` |

docs/tasks/TASK-full-data-parity-2-fix-20261023.md

@@ -0,0 +1,37 @@
+# 修复单：完整数据版补齐（二）（issue #92，第 1 次打回，2026-10-23）
+
+- 被验提交：`d45e65a9e`（分支 `codex/full-data-parity-2-20261021`）
+- 原任务书：`TASK-full-data-parity-2-20261021.md`
+- 执行方：Grok。同一分支继续，开工前 `git merge origin/staging`（不 rebase）。
+
+## 验收结论（Claude，Linux，屏蔽 PyJHora）
+
+做对了的：三章（补充推运、辅助次小运、研究型分盘）都在六章之后，每节带研究口径句；位置走我方 `SiderealFrame`（我方 `_sidereal_calculation_profile`，岁差逐时刻重算），没有视位置、Moshier、真位置开关；四种星座大运次小运照上游等分规则只加在副本上，主运、子运不变；Kalachakra 只加第三层；Niryaana Shoola 按产品 10-23 的决定不列子运并写明原因；D81 / D108 / D144 只出现在研究章；不进资料包、不进对话卡和校正打分。
+
+| 项 | 结果 |
+| --- | --- |
+| 生成时长（Linux，0 / 1 / 9 号盘，排盘 + 先英文后中文） | 18.5 / 17.3 / 17.5 秒，远低于 180 秒 |
+| 体量 | 英文约 249～264 万字符、汉字 0；中文约 192～206 万字符、2.7～2.9 MB |
+| 全量 pytest | 与 staging 基线相比多 4 条，单独重跑都通过（本机负载：其中 200 张英文扫描在 `-n 3` 下进程池被挤掉，单独跑 913 秒通过，最低剩余内存 2.9 GB） |
+| 前端全量、类型检查、构建 | 与 staging 一致 |
+
+**未通过：T5 PyJHora 离线对照一张都没做**（`research-timing-pyjhora-20261023.json` 是 `not_compared`、0 张）。任务书第 7 节写明 T5 只能让「覆盖盘数」，下限 5 张；产品在 issue #92 要求「已知与 PyJHora 不一致的体系逐个标出」（决策 E2）。
+
+## M1 · 做 T5 离线对照（必修）
+
+- 脚本 `scripts/research/research_timing_pyjhora_compare.py`（已有空壳）在执行方本机跑，**至少 5 张、最好 10 张**固定种子虚构盘，逐体系逐层比对：Tithi Ashtottari（本命顺 / 逆）、Yoga Vimshottari、Buddhi Gati、Kaala、Sudasa、Varnada、Karana 三种、四种星座大运（主运、子运、次小运）、Kalachakra。PyJHora 没有对应函数的体系写「PyJHora 无此方法」，不算不一致。
+- 每处差异分类：起点 / 方向 / 年数 / 子运划分 / 回归时刻；回归时刻差在 1 分钟内不算不一致（两边岁差与星历文件不同），写进 JSON 说明。
+- 结果存成 JSON 提交（`charts`、每体系 `status`：一致 / 不一致 / 无此方法，不一致附差在哪一类和一个例子）；pytest 只读 JSON，不导入 `jhora`（红线 3）。
+- 报告该体系标题下按 JSON 标注：中文「与 PyJHora 不一致：差在 {类别}」，英文「Differs from PyJHora: {category}」。
+
+验收：JSON 里 `charts ≥ 5`；加一条测试：JSON 里标为不一致的体系，在 0 号虚构盘中英两版标题下都出现对应标注；其余体系不出现。
+
+## M2 · 英文标注别被清理器删掉（必修，小）
+
+PROGRESS 说「英文不写 PyJHora，避免整份英文被卫生门丢掉」。实际情况是：`pl9_full_data_export.py` 与 `pl9_reader_english.py` 的清理器按**行**丢掉含 `PyJHora` 的行，不会丢整份英文。研究章现在是在 `_append_parity_chapters` 里拼接、在清理器之后，标注应能保留；但要用 M1 的测试证明英文标注确实出现在最终 `markdown_en` 里。若被删，改成在清理器之后拼接，不要改清理器本身。
+
+## 交回前必跑
+
+- `tests/test_research_timing.py` 与原任务书第 6 节列出的文件；M1 新测试。
+- 200 张英文扫描（屏蔽 PyJHora；Windows 上进程数可调低）。
+- 全量 pytest、快速门、前端由 Claude 复验。

docs/tasks/TASK-full-data-parity-3-fix-20261023.md

@@ -0,0 +1,44 @@
+# 修复单：完整数据版补齐（三）独立年度方法参考（issue #93，第 1 次打回，2026-10-23）
+
+- 被验提交：`c644881a3`（分支 `codex/full-data-parity-3-20261022`）
+- 原任务书：`TASK-full-data-parity-3-20261022.md`
+- 执行方：Grok。同一分支继续，开工前 `git merge origin/staging`（不 rebase）。BUG 编号开工时核对最大号 +1。
+
+## 验收结论（Claude，Linux，PyJHora 4.8.7 已装，不屏蔽）
+
+做对了的：PyJHora 只在子进程 worker 里导入，三张虚构盘生成后父进程 `sys.modules` 里没有 `jhora`；S1～S3 开关保持「未装」时的老结果；没碰冻结打分文件；中英各有「来源：PyJHora / Source: PyJHora」；英文汉字 0；输入是当地时间与正确年份（D6 默认）。
+
+| 项 | 结果 |
+| --- | --- |
+| 生成时长（Linux，0 / 1 / 9 号盘，排盘 + 资料包 + 先英文后中文，PyJHora 真跑） | 22.0 / 19.8 / 19.7 秒 |
+| worker 峰值内存（0.5 秒采样） | 约 60 MB |
+| 本章内容（9 号盘中文） | 3 年 × 4 张表，717 行；「未获得结果」6 处 |
+| 前端全量、类型检查、构建 | 与 staging 一致 |
+| 全量 pytest | 比 staging 基线多 5 条；2 条单独重跑通过（本机负载），**3 条单独跑仍失败**，见下 |
+
+## P1 · 结果指纹：别把本章排除在外（必修）
+
+`jyotish_engine._bind_result_without_annual_method_reference` 在绑定前把 `pyjhora_annual_method_reference` 摘掉、绑定后再放回。结果是：交付出去的资料包**里有**这一章，`result_hash` 却**没算**它；任何人按 `hash_bound_result` 重算都对不上——`tests/test_report_reference_perf.py::test_fast_hash_matches_the_legacy_algorithm_on_a_real_packet` 因此失败（BUG-693 / 694 的出处绑定就是靠「重算能对上」）。`calculation_profile_contract.py` 的 D2 也写明只有三类可以排除，本单没有授权加第四类。
+
+修法：删掉 `_bind_result_without_annual_method_reference`，恢复原来的 `bind_result_to_profile(delivered, profile)`；本章照常算进指纹。原任务书「切掉本章后与 T1 完成时的输出逐字节相同」那条对照，比较前把**报告引用号 / 结果指纹那一行**按正则抹成同一个占位符，再逐字节比较（引用号本来就该随结果变）；在 PROGRESS 写明抹掉的是哪一行。
+
+验收：上面那条测试通过；`tests/test_calculation_profile_contract.py` 全过；「切掉本章逐字节相同」的对照仍通过（抹掉引用号行之后）。
+
+## P2 · 源码文本合同测试没跟着改（必修，P1 修完多半自动消失）
+
+`tests/test_calculation_profile_contract.py::test_professional_reference_packet_rebinds_sanitized_delivery` 在 `build_professional_report_reference_packet` 源码里找 `bind_result_to_profile(delivered, profile)`，被包进新函数后找不到（`ValueError: substring not found`）。按 P1 恢复原调用即可；若仍要改这个函数，按 AGENTS §7.8 同轮改测试并写三栏。
+
+## P3 · 自己的新测试和自己写的部署说明打架（必修，小）
+
+`tests/test_pyjhora_annual_method_reference.py::test_deploy_does_not_set_year_lord_pyjhora_reference` 扫 `deploy/` 下所有文件不得出现 `JYOTISH_YEAR_LORD_PYJHORA_REFERENCE`，而本单在 `deploy/README.md` 写了「Do not set `JYOTISH_YEAR_LORD_PYJHORA_REFERENCE`」。二选一：README 改成不点名（例如「不要打开年主的 PyJHora 对照开关」），或测试只扫 compose / env / workflow 这类配置文件、跳过 `*.md`。推荐前者。
+
+## 顺手（小，不阻塞）
+
+- `build_professional_report_reference_packet` 对标准版和 JSON 输出也会起一次 PyJHora 子进程（本章只在完整数据版渲染）。线上目前只请求完整数据版，影响不大；顺手改成只在 `edition == full_data` 时调用（放在 `professional_report_reference._assemble_professional_report_reference` 判定版本之后），并加一条测试：标准版不启动 worker。
+- 进度里写「超时放宽到 120 秒」。Linux 上整份约 20 秒，120 秒只是上限，保留可以；但请在 PROGRESS 写明：前端总等待是 180 秒，worker 超时 + 其余生成时间不得超过它。
+
+## 交回前必跑
+
+- `tests/test_pyjhora_annual_method_reference.py`、`tests/test_calculation_profile_contract.py`、`tests/test_report_reference_perf.py` 与原任务书第 7 节列出的文件。
+- 200 张英文扫描（屏蔽 PyJHora）。
+- 全量 pytest、快速门、前端由 Claude 复验。