docs(tasks): fold product decisions into audit briefs (BUG-1344..1346)

- dasha-unify: fix Ashtottari birth balance (BUG-1344)
- rect-scoring-perf: server-side candidate cap 241 (BUG-1345)
- node-runtime-resources: enable user-side session cookie cache, 300 s (BUG-1346)
- consult-prep-parallel: classifier/reserve concurrency declined
- answer-effort-ab: model key supplied by product at acceptance
- drop stricter-than-test line-count red lines (AGENTS.md section 6)

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014Ad9rqAB8pXXvyzh7f4X8v

docs/tasks/README.md

@@ -463,8 +463,8 @@
 
 | 任务书 | 进度 | 主题 | 状态 | 落点 |
 | --- | --- | --- | --- | --- |
-| `TASK-rect-scoring-perf-20261013.md` | — | 校正打分提速：引导窗口平方扫描、候选不变量重复算、响应带无读取点字段（BUG-1323～1325） | 待领取 | `codex/rect-scoring-perf-20261013` |
-| `TASK-node-runtime-resources-20261013.md` | — | 报告 worker abort 监听泄漏、本地 PG 适配层往返与元数据缓存、无上限内存表（BUG-1326～1328，PG 部分 A/B） | 待领取 | `codex/node-runtime-resources-20261013` |
+| `TASK-rect-scoring-perf-20261013.md` | — | 校正打分提速：引导窗口平方扫描、候选不变量重复算、响应带无读取点字段、候选数上限 241（BUG-1323～1325、1345） | 待领取 | `codex/rect-scoring-perf-20261013` |
+| `TASK-node-runtime-resources-20261013.md` | — | 报告 worker abort 监听泄漏、本地 PG 适配层往返与元数据缓存、无上限内存表、用户端会话读缓存（BUG-1326～1328、1346，PG 与缓存部分 A/B） | 待领取 | `codex/node-runtime-resources-20261013` |
 | `TASK-home-sidebar-rerender-20261013.md` | — | 流式回答时侧栏每帧整栏重渲染（BUG-1329，A/B） | 待领取 | `codex/home-sidebar-rerender-20261013` |
 | `TASK-api-disk-cache-retention-20261013.md` | — | API 磁盘缓存只进不出、VedAstro 审计文件留存出生资料、失败快照久缓存、缓存键规范化（BUG-1330～1332，A/B） | 待领取 | `codex/api-disk-cache-retention-20261013` |
 | `TASK-report-reference-perf-20261013.md` | — | 长报告出稿提速：术语替换命中预检、哈希单次遍历、同盘复用（BUG-1335～1336，A/B） | 待领取 | `codex/report-reference-perf-20261013` |
@@ -475,7 +475,7 @@
 | `TASK-consult-route-split-20261013.md` | — | consult POST 拆分第一阶段：开流前加载 + 计费结算 | 待领取（排队：consult-prep-parallel、answer-effort-ab） | `codex/consult-route-split-20261013` |
 | `TASK-pl9-render-split-20261013.md` | — | render_pl9_markdown 第一阶段：搬出无依赖内部函数 | 待领取（排队：api-chart-subprocess-gate） | `codex/pl9-render-split-20261013` |
 | `TASK-python-hygiene-20261013.md` | — | 免费层排队开关报反、静默吞异常、功能吉凶兜底合一、测试专用脚本归位（BUG-1340） | 待领取（排队：pl9-render-split） | `codex/python-hygiene-20261013` |
-| `TASK-dasha-unify-20261013.md` | — | /api/dasha 改走引擎同一套实现、删占位注册表（BUG-1341） | 待领取（排队：python-hygiene） | `codex/dasha-unify-20261013` |
+| `TASK-dasha-unify-20261013.md` | — | /api/dasha 改走引擎同一套实现、删占位注册表、Ashtottari 出生余额（BUG-1341、1344） | 待领取（排队：python-hygiene） | `codex/dasha-unify-20261013` |
 | `TASK-api-server-service-extract-20261013.md` | — | API 单体第一阶段：拆出不带 HTTP 的计算类，生产伪造 handler 归零 | 待领取（排队：dasha-unify） | `codex/api-server-service-extract-20261013` |
 | `TASK-data-layer-types-20261013.md` | — | 数据访问层改用自己的 DataClient 类型第一阶段（BUG-1343） | 待领取（排队：node-runtime-resources） | `codex/data-layer-types-20261013` |
 | `TASK-contracts-helpers-dedupe-20261013.md` | — | 前后端契约与小工具去重第一阶段 | 待领取（排队：frontend-dead-code、consult-route-split） | `codex/contracts-helpers-dedupe-20261013` |

docs/tasks/TASK-answer-effort-ab-20261013.md

@@ -48,6 +48,7 @@
 
 ## 4. 决策记录
 
+- **产品负责人 2026-10-14：模型 key 在本单交付验收时由产品临时提供给 Claude**。Grok 无 key 时只交付开关、请求体拦截测试与 A/B 脚本，T0 第 2 步与 T2 的真实运行由 Claude 验收时执行；回报里写「A/B 未跑：等产品提供 key」，不得写通过。
 - 产品授权：2026-10-13 产品负责人同意按排查结论全部立单交 Grok 执行，并**已同意做答题步推理强度 A/B**；默认值等 A/B 结论交产品拍板。
 - 本单默认行为**不变**：开关不设时，请求体与 `77057a819` 逐字节相同。
 - `consultationSliceGenerationSettings` 的嵌套形状与它的两条断言**本单不改**（没有调用方，改它不影响线上；是否删除或修正交产品，写进 PROGRESS「需拍板」）。

docs/tasks/TASK-api-chart-subprocess-gate-20261013.md

@@ -96,7 +96,7 @@ sys.meta_path.insert(0, _Block())
 
 ## 5. 硬红线
 
-1. `scripts/jyotish_api_server.py` **净行数不得增长**（`tests/test_api_server_growth_contract.py`）；不新增 `JyotishAPIHandler` 类方法。闸门的判定逻辑（含 BUG-1302 的 `consult_card_warm_only` 判断）可以搬进 `scripts/api_heavy_compute_gate.py`，主文件调用点保持一行。
+1. `scripts/jyotish_api_server.py`：行数只按 `tests/test_api_server_growth_contract.py` 的粗护栏（AGENTS.md §6：不另加比测试更严的行数红线，也不得压行凑数），类方法数与 `JyotishAPIHandler.__new__` 伪造点不得增长。闸门的判定逻辑（含 BUG-1302 的 `consult_card_warm_only` 判断）可以搬进 `scripts/api_heavy_compute_gate.py`，主文件调用点保持一行。
 2. `frontend/src/app/(app)/page.tsx` 不碰；不写第二套请求封装。
 3. 不改 `deploy/**`、`.gitea/workflows/**`、数据库结构与迁移；不升级依赖。
 4. 不改引擎数值。所有改动在「模拟生产依赖」与「装了 PyJHora」两种环境下，报告 Markdown（中英）与 `fact_table_packet` **逐字节一致**（去掉生成时间戳等已知易变字段，易变字段清单写进差分脚本并在 PROGRESS 列出）。
@@ -128,7 +128,7 @@ sys.meta_path.insert(0, _Block())
 ### T3 · `/api/chart` 不带 skip 时占重计算名额（开关，默认关）（BUG-1333）
 
 - `scripts/api_heavy_compute_gate.py` 新增 `acquire_heavy_compute_slot_for_request(path, body)`（或同义名）：现有按路径的逻辑原样保留；另加：`path == "/api/chart"` 且 body 不带真值 `skip_vedastro_main_entry_overview` 且 body 不带 `async`/`enqueue` 且开关 `JYOTISH_GATE_CHART_OVERVIEW=1` 时，占一个名额。BUG-1302 的 `consult_card_warm_only` 判断一并搬进来。
-- `jyotish_api_server.py` 调用点改成这一个函数，**净行数 ≤ 0**。
+- `jyotish_api_server.py` 调用点改成这一个函数（新逻辑放新模块，主文件只留调用）。
 - `HEAVY_COMPUTE_PATHS` 不加 `/api/chart`。
 - 验收：新测试——开关关时任何 `/api/chart` 都不占名额；开关开时只有不带 skip 的同步请求占名额，带 skip 的、`async` 的不占；`test_warm_consultation_does_not_consume_the_user_slot` 等既有测试不改仍绿。
 - 分工：Grok 自跑；Claude 复验。

docs/tasks/TASK-api-disk-cache-retention-20261013.md

@@ -101,7 +101,7 @@ sys.meta_path.insert(0, _Block())
 
 ## 5. 硬红线
 
-1. `scripts/jyotish_api_server.py` **净行数不得增长**（`tests/test_api_server_growth_contract.py`，当前 10,970 行）。新逻辑全部进新模块（建议 `scripts/api_scratch_retention.py`），主文件只做薄调用；`prune_expired_async_jobs` 的函数体可以整体搬进新模块，主文件留同名薄包装以保住 `tests/test_api_async_job_contract.py` 的调用入口。
+1. `scripts/jyotish_api_server.py`：行数只按 `tests/test_api_server_growth_contract.py` 的粗护栏（AGENTS.md §6：不另加比测试更严的行数红线，也不得压行凑数），类方法数与 `JyotishAPIHandler.__new__` 伪造点不得增长。新逻辑全部进新模块（建议 `scripts/api_scratch_retention.py`），主文件只做薄调用；`prune_expired_async_jobs` 的函数体可以整体搬进新模块，主文件留同名薄包装以保住 `tests/test_api_async_job_contract.py` 的调用入口。
 2. 不新增 `JyotishAPIHandler` 类方法；不新增端点。
 3. 不改 `deploy/**`、`.gitea/workflows/**`、数据库结构与迁移。
 4. 不改任何引擎数值、盘面结果、证据取舍；chart 接口在规范化前后**响应逐字节一致**（`runtime_cache` 字段除外）。
@@ -118,7 +118,7 @@ sys.meta_path.insert(0, _Block())
   - 一张登记表，每项 = 目录 + 判定「可删」的规则 + 是否含出生资料。至少登记：`api_chart_cache`（`created_at + chart TTL` 已过）、`high_rigor_jobs` 与 `api_chart_response_jobs`（`expires_at_unix` 已过，即现有逻辑）、T2/T4 的各目录。
   - `prune_all(now=None) -> dict`：逐目录返回 `scanned / removed / errors / elapsed_ms`，只计数不打印文件名。
   - 节流的周期清理：`start_periodic_prune(interval_s)`，后台守护线程，默认间隔 `JYOTISH_SCRATCH_PRUNE_INTERVAL_SECONDS=1800`，`0` 关闭周期清理（启动清理仍跑）。
-- `jyotish_api_server.py`：`start_server` 里把 `prune_expired_async_jobs()` 换成新模块的启动清理 + 启动周期线程（保持打印一行汇总的行为）；`prune_expired_async_jobs` 函数体搬走，留薄包装。**净行数 ≤ 0**。
+- `jyotish_api_server.py`：`start_server` 里把 `prune_expired_async_jobs()` 换成新模块的启动清理 + 启动周期线程（保持打印一行汇总的行为）；`prune_expired_async_jobs` 函数体搬走，留薄包装。新逻辑放新模块，主文件只留调用。
 - chart 缓存新写入的文件改 0600、改为临时文件 + `os.replace` 原子写（与 `_write_async_job_record` 一致）。
 - 不改：TTL 默认值、读缓存逻辑、`runtime_cache` 字段。
 - 验收标准：

docs/tasks/TASK-api-server-service-extract-20261013.md

@@ -94,7 +94,7 @@
 
 1. **纯移动**：方法体逐字不改；只允许把 15 个 HTTP 侧方法与 `server_version` 从原类剪到新 HTTP 子类、改类声明、调整两个调用方的构造语句。用 `git diff --color-moved=dimmed-zebra` 与 AST 方法体对比（第 6 节 T2）证明。
 2. `tests/test_api_server_security.py` 一个字节不改且全绿。
-3. `scripts/jyotish_api_server.py` 净行数不得增长：拆类新增约 3 行（新类声明 + PEP 8 空行），**用同文件真实死代码抵消**——写作时全仓按名零引用的模块级函数有 `_strict_adjudication_bundle_from_contract`（16 行）与 `_high_rigor_job_path`（2 行），开工重核（含 `skills/*/versions/**` 以外的全部 `.py` / `.ts`、字符串引用、`getattr`），确认无引用才删；不得用合并语句、删注释凑行数。
+3. `scripts/jyotish_api_server.py`：行数只按 `tests/test_api_server_growth_contract.py` 的粗护栏（AGENTS.md §6，开工实测基线 + 300）；拆类新增的类声明与空行不需要抵消，**不得**为凑行数删代码、合并语句或删注释。顺带发现的零引用函数（写作时 `_strict_adjudication_bundle_from_contract`、`_high_rigor_job_path`）只记进 PROGRESS，不在本单删。
 4. 类方法数（合同口径）不得增长；`JyotishAPIHandler.__new__` 计数只许降。
 5. 不新增端点、不改任何端点请求 / 响应合同；HTTP 路由、安全检查、限流 429、异常映射行为不变。
 6. 新计算类不得继承 `BaseHTTPRequestHandler`，其方法不得引用 HTTP 成员（加 AST 测试钉住）。

docs/tasks/TASK-consult-prep-parallel-20261013.md

@@ -99,7 +99,7 @@
 2. 输入审核：**仍在任何模型调用和预留之前生效**，但不再挡首帧——开流后与资料读取并行，在 `reserve` 之前等它的结论；被拦时仍不扣点、不进模型；报错优先级与今天一致（见 T2）。不推翻 BUG-1074 的开流前清单（审核本来就不在那张清单里）。
 3. `readVersion` 缓存：做，TTL 与目录缓存相同（15 s），不缓存失败和 `null`，管理端模型/供应商变更时清除。不延长 TTL。
 4. **报告章节并发：本单不做**。目标函数已退役（§2.4），改了不会让任何用户的报告变快；排查报告里这一条作废。若产品以后重新启用 writer 管线，另立单。
-5. **分类器与预留并发：本单不做，需拍板。** 它会让零点用户的问题在预留失败前先送进模型（违反 BUG-976 边界「reserve 仍在分类前」），且分类调用产生供应商成本。可选折中「预留成功后，分类与 `append_consultation_question` 并行；append 失败则丢弃分类结果并取消」也涉及计费顺序，同样留待拍板。
+5. **分类器与预留并发：产品负责人 2026-10-14 决定不做。** 它会让零点用户的问题在预留失败前先送进模型（违反 BUG-976 边界「reserve 仍在分类前」），且分类调用产生供应商成本。可选折中「预留成功后，分类与 `append_consultation_question` 并行；append 失败则丢弃分类结果并取消」也涉及计费顺序，同样留待拍板。
 6. 多领域并发：做成开关，**默认关**（串行），A/B 达标才改默认。不改领域上限、不改时钟。
 7. 不推翻任何既有红线。
 
@@ -110,7 +110,7 @@
 3. 删号冻结（423）必须在任何扣点、写库之前判定（`account-deletion.test.tsx` 的 `if (frozen) return frozen;`）。
 4. `readVersion` 缓存：只缓存成功解析的结果；TTL ≤ 15 s；`invalidateLanguageModelCatalog()` 同时清它；不缓存 DNS 失败或非公网地址的结果；不改 `assertAllowedModelProviderUrl` 与 `requestAllowedModelProvider`。
 5. 多领域并发开关打开时：`executions` 顺序必须等于计划顺序（不得按完成先后）；任一领域失败的处理与串行一致（整次计算失败、错误码不变）；429 不得被吞或改码；`MAX_CONSULTATION_DOMAINS`、`domainFitsRunBudget` 的公式与常量不变。
-6. 不动表结构、不加迁移；不改 `scripts/jyotish_api_server.py`（净行数不得增长，`tests/test_api_server_growth_contract.py`）；不碰 `frontend/src/app/(app)/page.tsx`；不改 `.gitea/workflows/**`；不升级依赖；不顺手修 warning。
+6. 不动表结构、不加迁移；不改 `scripts/jyotish_api_server.py`；不碰 `frontend/src/app/(app)/page.tsx`；不改 `.gitea/workflows/**`；不升级依赖；不顺手修 warning。
 7. 改既有断言写「原值 / 新值 / 原因」三栏；不得为让测试过而弱化断言。开工先 grep（AGENTS.md §7.8）：
    ```bash
    grep -rn "await moderate(visibleQuestion\|await resolveSessionLanguageModel\|return await readVersion\|refuseWhenAccountDeletionPending\|const runTurn = async\|for (let index = 0; index < domains.length" frontend/tests tests

docs/tasks/TASK-dasha-unify-20261013.md

@@ -4,7 +4,7 @@
 - 来源：2026-10-13 全仓屎山与性能排查 ·「大运多套实现」条目（`scripts/*dasha*.py` 28 个、两套条件大运、`_birth_lord_and_balance` 多份、Vimshottari 年数表多处硬编码）
 - 执行方：**Grok（Windows + Docker）**，分支 `codex/dasha-unify-20261013`，只推这个分支
 - 验收：Claude（Linux）
-- BUG 编号：**BUG-1341**（开工时核对 `docs/BUG_HISTORY.md` 最大号；写作时最大号 BUG-1317；号段由主会话统一分配）（另：`TASK-upstream-sync7-20261014` 占 BUG-1318～1322，本批号段整体从 BUG-1323 起）
+- BUG 编号：**BUG-1341、BUG-1344**（开工时核对 `docs/BUG_HISTORY.md` 最大号；写作时最大号 BUG-1317；号段由主会话统一分配）（另：`TASK-upstream-sync7-20261014` 占 BUG-1318～1322，本批号段整体从 BUG-1323 起）
 - **开工前置**：`api-chart-subprocess-gate` 已合入 `origin/staging`（它改 `jyotish_api_server.py` 与排盘路径）。与 `python-hygiene`（BUG-1340）同为第二批，两单都改 `scripts/jyotish_api_server.py` 与 `scripts/jyotish_engine.py`：**本单在 `python-hygiene` 合入后开工**，若主会话决定并行，则本单只碰第 6 节列出的函数，合入时由后合的一方 rebase。
 - **主会话补充的串行链（2026-10-14）**：引擎/API 文件链按此顺序逐单合入后开工（`upstream-sync7` 也改 `jyotish_engine.py` / `jyotish_api_server.py`，若在途，后合一方 rebase）：`api-disk-cache-retention` + `report-reference-perf` → `api-chart-subprocess-gate` → `pl9-render-split` → `python-hygiene` → `dasha-unify` → `api-server-service-extract`。本单的前置以这条链为准（与上一行不一致时以本行为准）。
 - **后继**：`api-server-service-extract` 依赖本单合入。
@@ -80,7 +80,7 @@
 
 其中 **`dasha_analyzer.py`、`divisional_charts_extended.py`、`narayana_dasha.py` 在校正冻结身份里**（`references/real_case_calibration/minute_rectification_holdout_v3.json` `frozen_scoring.files`；`tests/test_sealed_holdout_contract_freshness.py` 与 `tests/test_rectification_validation_integrity_gate.py` 按字节哈希核对，ERR-110 / ERR-114）。改一个字节就要按研究协议重新冻结。
 
-### 2.6 附带发现：全量解读的 Ashtottari 没有出生余额（**本单不修，需拍板**）
+### 2.6 附带发现：全量解读的 Ashtottari 没有出生余额（**产品 10-14 决定：修，见 T6，BUG-1344**）
 
 同一虚构盘：
 
@@ -90,7 +90,7 @@
 | PyJHora `get_ashtottari_dhasa_bhukthi` | Jupiter 1983-10-07 起（出生时已走约 6.2 年）、Rahu **2002-10-07** |
 | `nakshatra_dasha.calc_ashtottari_dasha`（全量解读 `modules.nakshatra_dasha` 内） | 起运星 **Mars**（与前两者都不同） |
 
-原因（代码可见）：`ashtottari_dasha.py` 只有在拿到 `moon_longitude` 且适用规则族是「Rahu 从命主」时才算出生余额；`cmd_full_reading` 传的是 `birth_info_for_alt_dasha`（没有 `moon_longitude`），所以第一段从出生满额起算，后续每段都差约 6 年。改它会改报告里 Ashtottari 表的全部日期，且 Ashtottari 规则族的选择牵涉占星口径，**本单只把实证写进 BUG-1341 的「附带发现」并在回报里列为需拍板**，不改。
+原因（代码可见）：`ashtottari_dasha.py` 只有在拿到 `moon_longitude` 且适用规则族是「Rahu 从命主」时才算出生余额；`cmd_full_reading` 传的是 `birth_info_for_alt_dasha`（没有 `moon_longitude`），所以第一段从出生满额起算，后续每段都差约 6 年。改它会改报告里 Ashtottari 表的全部日期。主会话补充核实（`77057a819`）：即便拿到 `moon_longitude`，`_build_major_periods(start_lord_idx, birth_dt)` 仍从出生时刻按满额排第一段，`_calc_candidate_balance_and_birth_chain` 的结果只作附加字段、不平移时间线；默认规则族（月宿 + 月相）路径根本不算余额；「当前大运」也按「第一段从出生开始」推算。**产品 10-14 决定修复**（T6）。
 
 ## 3. 根因
 
@@ -107,15 +107,15 @@
 - **`/api/chart` 的 `available_dashas` / `dasha_count` 本单保持逐字节不变**（元数据搬到新注册表，内容不改），避免牵动排盘 golden 与排盘缓存；与 `/api/dasha` 能力不一致的问题列入「后续阶段」，需拍板是否裁剪。
 - `conditional_dashas.py`、`extended_dashas.py` 删除。`tests/run_all.py`（release 门）里对应断言按三栏改。
 - 冻结身份内文件（`dasha_analyzer.py`、`divisional_charts_extended.py`、`narayana_dasha.py`、`domain_calculation_service.py` 等）**本单一个字节不改**；它们的年数表留到下次有理由重新冻结时一起收。
-- 2.6 Ashtottari 余额：本单不修，需拍板。
-- 推翻的既有约束：BUG-1284「本单不得改 `jyotish_api_server.py` 的方法体」只是那一单的范围限制，不是长期红线；本单授权改 `_compute_dasha_system` / `_fallback_dasha_periods` / `_compute_chart_sync` 里读注册表的三行，净行数不增。
+- **2.6 Ashtottari 出生余额：产品负责人 2026-10-14 决定修复**（T6，BUG-1344）。这是本单唯一允许改变引擎全量解读输出的项：只许 `modules.ashtottari_dasha`（及 T6 列出的同源 Ashtottari 输出）变化，其余逐字节不变。适用性规则（哪些盘适用 Ashtottari、两种规则族的判定）**不改**，只修「已判定适用时的时间线」。
+- 推翻的既有约束：BUG-1284「本单不得改 `jyotish_api_server.py` 的方法体」只是那一单的范围限制，不是长期红线；本单授权改 `_compute_dasha_system` / `_fallback_dasha_periods` / `_compute_chart_sync` 里读注册表的三行；行数按增长合同粗护栏。
 
 ## 5. 硬红线
 
-1. **引擎全量解读输出逐字节不变**（`modules.*_dasha` 全部）。本单只改接口路径与去重；若 T3 / T4 去重让任何数值或字段顺序变化，即为搬错，改代码不改断言。
+1. **引擎全量解读输出逐字节不变**（`modules.*_dasha` 全部；唯一例外是 T6 的 Ashtottari 时间线）。本单只改接口路径与去重；若 T3 / T4 去重让任何数值或字段顺序变化，即为搬错，改代码不改断言。
 2. 冻结身份两份清单内的文件一个字节不改（开工打印清单，第 9 节）。
 3. 不改 `narayana_dasha.py`、`narayana_rath.py`、`narayana_legacy_label.py`；不改 BUG-1215 / 1218 的展示与打分口径。
-4. `scripts/jyotish_api_server.py` 净行数不得增长；类方法数不得增长（删 `_fallback_dasha_periods` 后应下降 1，合同测试基线同步下调并写三栏）；`JyotishAPIHandler.__new__` 计数不得增长。
+4. `scripts/jyotish_api_server.py`：行数只按 `tests/test_api_server_growth_contract.py` 的粗护栏（AGENTS.md §6：不另加比测试更严的行数红线，也不得压行凑数），类方法数与 `JyotishAPIHandler.__new__` 伪造点不得增长；类方法数（删 `_fallback_dasha_periods` 后应下降 1，合同测试基线同步下调并写三栏）；`JyotishAPIHandler.__new__` 计数不得增长。
 5. `/api/chart` 响应逐字节不变（`available_dashas` 内容与顺序不变）。
 6. 新注册模块不得 import `jyotish_api_server`；不得在运行时 import `jhora`（PyJHora 只在测试里作对照，且测试需在缺 PyJHora 时 skip，镜像不装它——见记忆「验收要屏蔽 PyJHora 模拟生产」）。
 7. 不改 `.gitea/workflows/**`、不动表结构与迁移、不升级依赖。
@@ -179,16 +179,27 @@
   - 新测试（只许降）：`scripts/` 根目录非冻结文件里 Vimshottari 年数字面量计数 == 本单收尾值（冻结文件列白名单）。
   - **全量解读逐字节不变**：基线工作树与本分支各跑一次虚构盘 `python scripts/jyotish_engine.py full-reading …`（参数见 `--help`），`PYTHONHASHSEED=0`，去掉墙钟字段后 `cmp`。
 
+### T6 · Ashtottari 出生余额（BUG-1344，必做，产品 10-14 决定）
+
+- 改 `scripts/ashtottari_dasha.py::calculate_ashtottari_dasha`：已判定适用时，按月亮在起运星所辖星宿组内已走过的比例算出生余额，**第一段主运起点 = 出生时刻 − 已走过部分**，后续各段与次级周期、`current` 推算都随之平移。两种规则族都要算余额（默认规则族现在完全不算）。
+- `scripts/jyotish_engine.py::cmd_full_reading` 调用 `calculate_ashtottari_dasha` 时补传 `moon_longitude`（`conditional_birth_info` 已有该值，照它传；不得改 `birth_info_for_alt_dasha` 本身，那会牵动 Yogini / Kalachakra）。`scripts/orchestrator_bridge.py` 等其余调用方开工 grep 全，同样补传。
+- 余额算法以 PyJHora `get_ashtottari_dhasa_bhukthi` 的语义为对照（只对照结果，不复制其代码，注意许可证边界，AGENTS.md §B1）。
+- 全量解读里第二套 `nakshatra_dasha.calc_ashtottari_dasha`（起运星 Mars，与前两者都不同）：开工查清它在报告 / 咨询 / 前端哪里被展示。若用户可见，改为直接复用 `ashtottari_dasha.py` 的结果；若无人读取，只在 PROGRESS 记录，留后续阶段。
+- 验收：
+  - 新测试：至少 3 张盘（第 1 节虚构盘 + 2 张公开名人盘，覆盖两种规则族各至少 1 张；PyJHora 缺失时 skip 对照部分，但保留与固化 golden 的比对）主运起止日期与 PyJHora 相差 ≤ 1 天，起运星一致；出生时刻落在第一段内；`current` 与按日期查表一致。
+  - golden：受影响的报告 / 全量解读 golden 只能用真实引擎重新采集，PROGRESS 列出每个变化文件与变化只限 Ashtottari 段（其余段 diff 为空）。
+  - Claude 验收跑全量 pytest 与基线逐名比对（引擎数值改动，见验收分工）。
+
 ### T5 · 记录（必做）
 
-- `docs/BUG_HISTORY.md` 新增 **BUG-1341**：`/api/dasha` 非 Vimshottari 体系是占位实现（不读盘、年数自编、标成 `calculator`）；修复为走引擎同一套模块；关联 BUG-1262、BUG-1284（把 1284 状态从 mitigated 更新为 resolved 并注明本单）、BUG-1215 / 1218（Narayana 未裁定）。「附带发现」写 2.6 Ashtottari 余额（状态 `investigating`，需拍板）。
+- `docs/BUG_HISTORY.md` 新增 **BUG-1341**：`/api/dasha` 非 Vimshottari 体系是占位实现（不读盘、年数自编、标成 `calculator`）；修复为走引擎同一套模块；关联 BUG-1262、BUG-1284（把 1284 状态从 mitigated 更新为 resolved 并注明本单）、BUG-1215 / 1218（Narayana 未裁定）。另新增 **BUG-1344**：全量解读 Ashtottari 无出生余额、时间线整体偏移（修复 T6，状态按验收证据写）。
 - `docs/tasks/PROGRESS-dasha-unify-20261013.md`：T1 基线红 / 修后绿输出、映射表最终版、`/api/chart` 与全量解读两次逐字节对照、T4 每处替换清单。
-- `CHANGELOG.md`：一条（`/api/dasha` 合同变化：未实现体系 400、`precision` 取值变化）。Skill 版本不 bump。
+- `CHANGELOG.md`：两条（`/api/dasha` 合同变化：未实现体系 400、`precision` 取值变化；报告里 Ashtottari 大运日期修正为含出生余额）。Skill 版本不 bump。
 - `frontend/DESIGN.md`：不改。
 
 ## 7. 让步顺序
 
-时间不够按此顺序砍：**T4 年数表部分 → T4 余额函数部分**。T1、T2、T3、T5 不可砍（T2 是 BUG-1341 本体）。
+时间不够按此顺序砍：**T4 年数表部分 → T4 余额函数部分**。T1、T2、T3、T5、T6 不可砍（T2 是 BUG-1341 本体，T6 是产品 10-14 决定）。
 
 ## 8. 验收命令分工
 
@@ -233,8 +244,7 @@ BUG-1341（写作时最大号 BUG-1317）。开工核对，被占用则顺延并
 
 ## 后续阶段（本单不做）
 
-1. **2.6 Ashtottari 出生余额与两套 Ashtottari 起运星不一致**（需拍板：改报告 Ashtottari 表全部日期）。
-2. `available_dashas` 裁剪到真实可算的体系（改 `/api/chart` 合同与 golden，需拍板）。
-3. 冻结身份内 `dasha_analyzer.py` / `divisional_charts_extended.py` 的年数表，在下次因其他理由重新冻结时一起收。
-4. Narayana 旧算法 vs Rath 版（BUG-1215 / 1218，等产品看 T5 试算）。
-5. `dasha_calculator.py`、`dasha_calculator_enhanced.py`、`nakshatra_dasha.calc_ashtottari_dasha` 等其余重复实现的归并。
+1. `available_dashas` 裁剪到真实可算的体系（改 `/api/chart` 合同与 golden，需拍板）。
+2. 冻结身份内 `dasha_analyzer.py` / `divisional_charts_extended.py` 的年数表，在下次因其他理由重新冻结时一起收。
+3. Narayana 旧算法 vs Rath 版（BUG-1215 / 1218，等产品看 T5 试算）。
+4. `dasha_calculator.py`、`dasha_calculator_enhanced.py`、`nakshatra_dasha.calc_ashtottari_dasha` 等其余重复实现的归并。

docs/tasks/TASK-node-runtime-resources-20261013.md

@@ -4,10 +4,11 @@
 - 来源：「2026-10-13 全仓屎山与性能排查」——P0「报告 worker 空转泄漏」、P1「数据库适配层往返」、小项「服务端无上限 Map」
 - 执行方：**Grok（Windows + Docker）**，分支 `codex/node-runtime-resources-20261013`，只推这个分支
 - 验收：Claude（Linux）
-- BUG 编号：**BUG-1326～1328**（开工时核对 `docs/BUG_HISTORY.md` 最大号；写作时最大号 BUG-1317；号段由主会话分配）（另：`TASK-upstream-sync7-20261014` 占 BUG-1318～1322，本批号段整体从 BUG-1323 起）
+- BUG 编号：**BUG-1326～1328、BUG-1346**（开工时核对 `docs/BUG_HISTORY.md` 最大号；写作时最大号 BUG-1317；号段由主会话分配）（另：`TASK-upstream-sync7-20261014` 占 BUG-1318～1322，本批号段整体从 BUG-1323 起）
   - BUG-1326：报告 worker 空转每 2 秒挂一个 abort 监听，永不释放（P0）
   - BUG-1327：本地 Postgres 适配层每条查询 6 次往返、元数据每次现查（P1，需 A/B）
   - BUG-1328：三张服务端内存表只增不减（小）
+  - BUG-1346：用户端开启 Better Auth 会话读缓存（产品 10-14 决定，maxAge 300 s，敏感操作绕过）
 - 开工前置：**无**（第一批立即派发）
 
 ## 1. 基线
@@ -91,7 +92,7 @@ node --expose-gc leak-fixed.mjs fixed   # 到点即摘监听
 - 2026-10-13 产品负责人同意按排查结论全部立单交 Grok 执行（本单含 P0 + P1 + 小项）。
 - 产品追加要求：P1 改动必须 A/B 并做成开关，默认值按 A/B 结论定——本单 T2 照做；T1、T3 是缺陷修复且行为等价（只回收已无作用的条目 / 监听），不做开关。
 - **只读无身份调用省掉事务：评估结论为不做**（理由见 T2「评估」），不是让步项。
-- **Better Auth `cookieCache`（会话读缓存）：本单不做，需拍板。** 它会改变「改密码 / 注销 / 封号后旧会话多久失效」的登录行为，属于产品与安全决策，不是性能改动；排查报告的数字留作拍板依据。
+- **Better Auth `cookieCache`（会话读缓存）：产品负责人 2026-10-14 决定开启**（T6，BUG-1346）。代价已向产品说明：改密码 / 封号后，其它设备上的旧登录最多再有效 `maxAge` 这么久。主会话评估取 **`maxAge` = 300 秒**（Better Auth 默认值，与本仓 `twoFactorCookieMaxAge: 300` 同量级），且敏感操作强制绕过缓存（见 T6）。
 - 不推翻任何既有红线。
 
 ## 5. 硬红线
@@ -183,16 +184,32 @@ node --expose-gc leak-fixed.mjs fixed   # 到点即摘监听
 - 记录写 `docs/testing/node-runtime-resources-ab-20261013.md`：环境（Windows + Docker Desktop 版本、Node 版本）、三组原始数字、中位数表、差分结果、默认值结论。
 - Claude 验收：读 A/B 记录、复跑不需 Docker 的往返计数单测；真库数字以 Grok 为准（本机无 Docker，记环境缺口）。
 
+### T6 · 用户端开启会话读缓存（BUG-1346，产品 10-14 决定，开关 + A/B）
+
+- 现状：`frontend/src/modules/identity/auth-factory.ts` 用户端配置没有 `session.cookieCache`，每个带登录的请求 `getSession` 都查一次库（`readIdentitySession` / `createServerSupabaseClient` 路径）。
+- 改法：
+  - 只对**用户端**（`cookiePrefix: "jyotisha-user"` 那份配置）加 `session.cookieCache = { enabled, maxAge: 300 }`；**后台（admin 端）配置不加**。
+  - 开关：服务端环境变量（例如 `IDENTITY_SESSION_COOKIE_CACHE`，名字执行方定，登记进 deploy 示例），A/B 后定默认值。
+  - **敏感操作必须绕过缓存**（每次真查库）：改密码、注销账户 / 撤销注销、改邮箱、两步验证设置、任何后台接口、`account-deletion` 相关路由。开工 grep `getSession(`、`readIdentitySession`、`requireIdentityServerSession` 的全部调用点，列表进 PROGRESS；敏感点用 Better Auth 的 `disableCookieCache` 查询参数（以当前锁定版本的文档 / 类型为准，先确认参数名）。
+  - 账户删除检查（consult 等路由里的注销 RPC）与后台 `banned` 授权检查（`auth.ts` 查 `banned` / `ban_expires`）保持现状，不得因缓存跳过。
+- 不改：会话有效期、`revokeSessionsOnPasswordReset`、Cookie 属性（`secure` / `httpOnly` / `sameSite`）、表结构。
+- 验收：
+  - 新测试：开关开时，同一会话连续 3 次普通请求只查库 1 次；敏感路由每次都查库；开关关时与现在完全一致。
+  - 新测试：撤销会话（模拟改密码）后，敏感路由立刻 401；普通路由在 `maxAge` 内仍可用、超过后 401（用假时钟）。
+  - A/B 并入 T4：同一组带登录的请求序列，比较「每请求查库次数」与耗时中位数；门槛：查库次数下降且耗时不升 → 默认开；否则默认关并在 PROGRESS 写原因。
+  - Grok 跑 `test:db` 两种开关各一次，按已知失败清单比对。
+  - `docs/testing/node-runtime-resources-20261013.md` 写真机步骤：两台设备登录 → 一台改密码 → 另一台 5 分钟内仍可浏览、5 分钟后被要求重新登录、期间无法执行改密码 / 注销等敏感操作。
+
 ### T5 · 记录
 
-- `docs/BUG_HISTORY.md` 新增 BUG-1326、1327、1328（1327 状态按 A/B 结论写；部署后的内存曲线未观测前 1326 写 `resolved（代码+回归测试），生产内存曲线待部署后观察`）。
+- `docs/BUG_HISTORY.md` 新增 BUG-1326、1327、1328、1346（1346 写明产品 10-14 决定与「最多 300 秒」的取舍；1327 状态按 A/B 结论写；部署后的内存曲线未观测前 1326 写 `resolved（代码+回归测试），生产内存曲线待部署后观察`）。
 - `docs/tasks/PROGRESS-node-runtime-resources-20261013.md`：含 T2c 评估、T3 语义变化说明、基线跑新测试的失败输出、A/B 结论。
 - `deploy/README.md` 或 `.env` 示例里登记两个开关（只写名字与默认值，不写任何密钥）；若 compose 文件需要透传环境变量，改 `deploy/docker-compose.server.yml` 前先在回报里说明（不改 workflow）。
 - `CHANGELOG.md`：一句「服务器长期运行不再逐日涨内存；数据库访问少走几趟」。Skill 版本不 bump。`frontend/DESIGN.md` 不改。
 
 ## 7. 让步顺序
 
-T1（P0，必须交）→ T3 → T2a → T2b → T4。时间不够时：先砍 T2b（保留开关骨架与单测也可以不交），再砍 T2a；T2 一旦交付就必须带 T4 的 A/B 与 test:db 比对，否则开关默认 `off`。T1 不得因任何原因延后。
+T1（P0，必须交）→ T3 → T6 → T2a → T2b → T4。T6 是产品决定，不得砍。时间不够时：先砍 T2b（保留开关骨架与单测也可以不交），再砍 T2a；T2 一旦交付就必须带 T4 的 A/B 与 test:db 比对，否则开关默认 `off`。T1 不得因任何原因延后。
 
 ## 8. 验收命令分工
 
@@ -223,10 +240,9 @@ cat tools/agent-loop/windows-known-failures.txt
 
 ## 11. 本单不做
 
-- Better Auth `cookieCache`（登录行为改动，需产品拍板）。
 - 只读无身份调用省事务（T2c 已论证不安全）。
 - 把 `begin` 拼进多语句简单查询（需要手工转义字面量，收益一次往返，不值得冒注入风险）。
-- `createServerSupabaseClient` 每次调用都读一次身份会话（`readIdentitySession`）的往返——与 cookieCache 同属登录链，一起拍板。
+- `createServerSupabaseClient` 每次调用都读一次身份会话的往返：T6 开缓存后自然减少，不另做。
 
 ## 附录 · 2.1 复现脚本（`leak-fixed.mjs`，与源码同形，可放任意临时目录）
 

docs/tasks/TASK-python-hygiene-20261013.md

@@ -131,7 +131,7 @@ EOF
 
 ## 5. 硬红线
 
-1. `scripts/jyotish_api_server.py` 净行数不得增长；`tests/test_api_server_growth_contract.py` 的类方法数、`JyotishAPIHandler.__new__` 计数不得增长（本单 T2 预期方法数不变、行数下降）。
+1. `scripts/jyotish_api_server.py`：行数只按增长合同的粗护栏（AGENTS.md §6），`tests/test_api_server_growth_contract.py` 的类方法数、`JyotishAPIHandler.__new__` 计数不得增长（本单 T2 预期方法数不变、行数下降）。
 2. **校正冻结身份内的文件一个字节都不许改、不许搬**（ERR-110 / ERR-114）：开工先打印两份清单（第 9 节命令），本单任何改动命中清单即停下回报。
 3. 不改 `.gitea/workflows/**`、`deploy/gated-paths.txt`、`pyproject.toml` 的打包配置、`deploy/*.Dockerfile`。
 4. 日志**不得包含出生资料、坐标、姓名、请求体、异常消息原文**：异常消息可能带输入值（例如 `strptime` 报错会带出生日期字符串）。WARNING 级只写「模块.函数 + 异常类名」；完整 `exc_info` 只允许在 DEBUG 级。

docs/tasks/TASK-rect-scoring-perf-20261013.md

@@ -4,7 +4,7 @@
 - 来源：「2026-10-13 全仓屎山与性能排查」· 校正打分 `POST /api/rectification/v5/score` 慢与响应过大（P0，确定性计算提速）
 - 执行方：**Grok（Windows + Docker）**，分支 `codex/rect-scoring-perf-20261013`，只推这个分支
 - 验收：Claude（Linux）
-- BUG 编号：**BUG-1323～BUG-1325**（开工时核对 `docs/BUG_HISTORY.md` 最大号，写作时最大号 BUG-1317）（另：`TASK-upstream-sync7-20261014` 占 BUG-1318～1322，本批号段整体从 BUG-1323 起）
+- BUG 编号：**BUG-1323～BUG-1325、BUG-1345**（开工时核对 `docs/BUG_HISTORY.md` 最大号，写作时最大号 BUG-1317）（另：`TASK-upstream-sync7-20261014` 占 BUG-1318～1322，本批号段整体从 BUG-1323 起）
 - 开工前置：无（第一批立即派发）
 - 性质：**输出逐字节不变**的性能改动。算法身份保持 `rectification-v5-matrix-scoring-12`、策略 `rectification-candidate-policy-v4`，不升版本、不写新 golden。
 
@@ -100,6 +100,7 @@ EVENTS = [  # id 依次 00000000-0000-4000-8000-00000000000{1..8}，summary 统
   - BUG-721：记忆化只用请求内显式传递的 context 或局部字典，**禁止模块级 `lru_cache` / 全局 dict**（即使键只是上升星座也不行）。本单照此执行。
   - BUG-733 / BUG-747：不得对浮点整体 `==` 比较 golden，不得调用 `write_golden()`。记忆化 golden v5 文件一个字节都不改。
   - ERR-110 / BUG-1047：`event_probes.py`、`dasha_transition_proximity.py`、`scoring_service.py`、`api_service.py`、`refinement_packet.py`、`functional_benefics.py` 在 `scripts/research/sealed_holdout_rerun.py::PRODUCTION_FILES` 里；`active_rectification_event_engine.py`、`narayana_dasha.py` 在 dataset `frozen_scoring.files`（12 个遗留文件）里。**输出不变也必须按研究协议重新冻结**（§6 T6），否则不得合入。BUG-1047 当时就是因为没做这一步，同类优化半途放弃。
+- **产品 2026-10-14 决定：打分接口设候选数上限**，数值由 Claude 评估定为 241（T4b 表格）。
 - T4 默认不返回两个字段，是执行 BUG-728 的既有规则，不是新决定。Python 内部调用方要拿矩阵就显式传参。HTTP 接口不加开关（前台没有读取点）。
 
 ## 5. 硬红线
@@ -109,7 +110,7 @@ EVENTS = [  # id 依次 00000000-0000-4000-8000-00000000000{1..8}，summary 统
 3. 新的缓存只放进请求内的静态上下文**顶层**（与 `narayana_periods` 同级），**不得**放进 `feature` 负载（会改 `fingerprints` 与 `feature_hash`）。禁止模块级缓存（BUG-721）。
 4. 不修改 `narayana_dasha.py`、`functional_benefics.py`、`dasha_analyzer.py` 的任何函数（共享模块，报告和咨询也在用）。
 5. `scripts/jyotish_api_server.py` 不改（`_attach_vedastro_minute_sensitive_to_score` 已对缺键容错）；`tests/test_api_server_growth_contract.py` 必须绿。
-6. 不碰前端业务代码与 `frontend/src/app/(app)/page.tsx`；不改 `.gitea/workflows/**`；不动表结构和迁移；不升级依赖；不顺手修别的 warning。
+6. 不碰前端业务代码（唯一例外：T4b 在 `engine-client.ts` 错误映射里认出 `too_many_candidates`）与 `frontend/src/app/(app)/page.tsx`；不改 `.gitea/workflows/**`；不动表结构和迁移；不升级依赖；不顺手修别的 warning。
 7. 改既有断言按 AGENTS §7.3 写「原值 / 新值 / 原因」三栏；开工先 grep：`grep -rn "event_contribution_matrix\|candidate_decision_receipt" tests scripts frontend/tests frontend/src`。
 8. 冻结重跑只能**另存**新记录，不得覆盖 `ephemeris_nutation_2026_10_08` 的四份文件，也不得改历史归档（`test_historical_artifacts_are_byte_preserved_not_refreshed`）。
 9. 跨进程比较一律固定 `PYTHONHASHSEED=0`（ERR-111：Shadbala 指纹随哈希种子变）；同进程比较不受影响。
@@ -177,6 +178,26 @@ EVENTS = [  # id 依次 00000000-0000-4000-8000-00000000000{1..8}，summary 统
   - 响应大小（紧凑 JSON）记进 PROGRESS，目标 ≤ 基线的 50%（实测预期 1.91 MB → 0.91 MB）。
   - `frontend/tests/rectification-v9-engine-contract.test.ts`、`rectification-v9-status-security.test.ts` 不受影响（Claude 复验）。
 
+### T4b · 服务端候选数上限（BUG-1345，产品 10-14 决定）
+
+**上限定为每次请求 241 个候选**（主会话评估，产品已授权设上限）：
+
+| 依据 | 数字 |
+| --- | --- |
+| 产品流程单次打分最多 | 分钟阶段 121（跨度 ≤120 分钟、步长 1）；`block_scan` 全天步长 10 = 144，其余档位（2/5 步长）≤ 91 |
+| 上限 241 的来历 | 等于前端已有常量 `search-window.ts::WIDEN_MAX_INCLUSIVE_MINUTES`（4 小时、每分钟一个），是产品最大用量的约 1.7 倍，留给以后放宽窗口的余量 |
+| 上限下的最坏耗时 | 基线 241 候选 10.5 s；T1–T3 后预计约 4 s，不超过现在一次正常 121 候选打分 |
+| 现在不设上限的最坏情况 | 直接调接口传全天步长 1 = 1,440 个候选，占重计算槽数分钟 |
+
+- 实现：在 `scripts/rectification/api_service.py` 的 HTTP 入口路径（`score_candidates`、`block_scan`、`diagnostics`）按 `start_time` / `end_time` / 生效步长先算候选数，超过 241 直接拒绝，返回 **400**，错误码 `too_many_candidates`，消息里带上限值和本次候选数。**在开始排盘之前拒绝**，不得算到一半。
+- 上限用模块常量 `MAX_CANDIDATES_PER_REQUEST = 241`；**不得**加成请求字段（会进 `fingerprint` / `result_id`）。研究脚本若需要超过上限，显式传关键字参数关闭；开工 grep 全部 Python 调用方（`scripts/research/**`、`tests/**`），确认 T6 冻结重跑的所有试验都在上限内、结果不变，逐一写进 PROGRESS。
+- 前端：`engine-client.ts` 已有的错误映射里，把 400 `too_many_candidates` 归入「请求参数错」类（不重试、不当成忙）；正常流程碰不到，只需保证不会被当成 429 去重试。若需改前端文件，只改错误映射这一处。
+- 验收：
+  - 新测试：240 / 241 候选放行，242 候选 400；全天步长 1（1,440）400，且耗时 < 50 ms（证明没开始排盘）；全天步长 10（144）放行；步长 2/5 的产品档位全部放行。
+  - `tests/test_api_server_security.py` 若有对打分接口状态码的断言，按三栏补。
+  - Grok 自跑；Claude 复验。
+- T4b 必须在 T6 之前完成（`api_service.py` 在冻结身份清单里）。
+
 ### T5 · 差分与耗时脚本（交付物，T1–T4 都要用）
 
 - 新增 `scripts/research/rect_scoring_perf_20261013.py`，内置 §2 夹具，两个子命令：
@@ -230,7 +251,7 @@ EVENTS = [  # id 依次 00000000-0000-4000-8000-00000000000{1..8}，summary 统
 
 ### T7 · 记录
 
-- `docs/BUG_HISTORY.md` 新增 **BUG-1323**（引导窗口平方扫描）、**BUG-1324**（候选不变量仍在事件循环：功能吉凶 / 那罗延 AD / 过渡邻近；关联 BUG-721，写明旧条款为何没拦住：新代码没照做、测试只用 3～5 个候选）、**BUG-1325**（打分响应带无读取点的内部矩阵与重复回执；关联 BUG-728）。防复发写进「计数断言随候选数线性」与「新响应字段先找读取点」。
+- `docs/BUG_HISTORY.md` 新增 **BUG-1323**（引导窗口平方扫描）、**BUG-1324**（候选不变量仍在事件循环：功能吉凶 / 那罗延 AD / 过渡邻近；关联 BUG-721，写明旧条款为何没拦住：新代码没照做、测试只用 3～5 个候选）、**BUG-1325**（打分响应带无读取点的内部矩阵与重复回执；关联 BUG-728）。防复发写进「计数断言随候选数线性」与「新响应字段先找读取点」。另新增 **BUG-1345**（打分接口无候选数上限，直接调用可占重计算槽数分钟；修复为 241 上限、超限 400 且不排盘）。
 - `docs/research/pre_work_error_ledger.md`：在 ERR-110 下追加本次另存标签。
 - `docs/tasks/PROGRESS-rect-scoring-perf-20261013.md`：改前 / 改后耗时表（5 次中位数，注明机器与负载）、11 场景 sha256 对照、计数表、三栏清单、冻结核对结果。
 - `CHANGELOG.md`：一句「校正每轮重算更快（2 小时窗口约快一倍以上），结果不变」。Skill 版本不 bump。
@@ -258,7 +279,7 @@ EVENTS = [  # id 依次 00000000-0000-4000-8000-00000000000{1..8}，summary 统
 2. T3 的功能吉凶；
 3. T4。
 
-**T1、T2、T5、T6、T7 不可砍。** T6 必须在最终代码上做：砍掉任何一项后要重做 T6。
+**T1、T2、T4b、T5、T6、T7 不可砍。** T6 必须在最终代码上做：砍掉任何一项后要重做 T6。
 
 ## 9. 验收命令分工
 
@@ -266,11 +287,11 @@ EVENTS = [  # id 依次 00000000-0000-4000-8000-00000000000{1..8}，summary 统
 | --- | --- |
 | Grok 自跑（工作树 `.venv`） | `python -m pytest tests/test_rect_scoring_perf_20261013.py tests/test_rectification_engine_memoization.py tests/test_event_probes_guided_windows.py tests/test_dasha_transition_proximity_cross_midnight.py tests/test_rectification_v5_services.py tests/test_rectification_v5_vedastro_validation.py tests/test_rectification_validation_integrity_gate.py tests/test_sealed_holdout_contract_freshness.py tests/test_reported_offset_research.py tests/test_rectification_confirmation_and.py tests/test_api_server_growth_contract.py -q`；`python -m pytest tests/test_rectification_*.py -q`（BUG-747：改回执路径必须跑全量校正测试）；T5 `bench` 与跨版本 `dump` 比较；T6 冻结与逐字节核对；前端单文件 `rectification-confirmation-gate.test.ts`。前端全量、Python 快速门**不跑**，以 Claude 为准 |
 | Claude 验收 | 上述全部 + `.venv/bin/python scripts/run_quality_gate.py --profile quick` + Python 全量 pytest 与基线逐名比对（feedback：引擎路径改动不能只看快速门）+ 前端全量 `npm test`（看 fail 与 cancelled）+ 独立跑 T5 跨版本 11 场景 sha256 + 复核 T6 trials 逐字节 + `tests/test_repo_privacy_markers.py` |
-| 不需要 | `npm run test:db`（不动数据库）；`next build` 首屏口径（不动前端源码） |
+| 前端（仅当 T4b 改了 `engine-client.ts`） | Grok：`tsc --noEmit`、`npm run lint`、`rectification-v9-engine-contract.test.ts` 单文件；Claude：前端全量 `npm test` |
+| 不需要 | `npm run test:db`（不动数据库） |
 
 ## 10. 本单不做（另议）
 
-- 服务端打分候选数上限：直接调接口可以传 00:00–23:59、步长 1，算出 1440 个候选，占重计算槽数分钟。要不要设上限需要拍板。
 - 探针路径 `_active_vimshottari(birth_date, …)` 用请求日期而不是候选日期，与打分路径口径不同；本单不碰，只记录。
 - `candidate_feature_snapshot` 417 KB 只读 `features[*]` 里三个字段，瘦身要动前端契约，另开单。
 - `guided_collect_windows` 与 `merge_transition_proximity` 共用每候选的大运起点表（还能省约 0.3–0.5 s）。
@@ -291,7 +312,7 @@ grep -rn "event_contribution_matrix\|candidate_decision_receipt" tests scripts f
 
 ## 12. BUG 编号起点
 
-BUG-1323（引导窗口）、BUG-1324（不变量）、BUG-1325（响应）。开工核对最大号；若已被占用，顺延并在 PROGRESS 写明。
+BUG-1323（引导窗口）、BUG-1324（不变量）、BUG-1325（响应）、BUG-1345（候选数上限，产品 10-14 决定）。开工核对最大号；若已被占用，顺延并在 PROGRESS 写明。
 
 ## 13. 交付物清单
 

docs/tasks/TASK-report-reference-perf-20261013.md

@@ -116,7 +116,7 @@ EOF
 4. **不减少擦洗遍数**，除非能在 PROGRESS 里给出逐条等价论证且 A/B 全语料逐字节一致——默认不做（见让步顺序）。
 5. 缓存只覆盖 `edition=full_data` + `format=markdown` 路径；其他组合（含 `format=json`，其包内有 `generated_at` 墙钟）一律不缓存。缓存命中返回的响应字节必须与未命中时相同。
 6. 缓存键必须包含影响输出的**全部**输入：`_high_rigor_birth_payload` 规范化后的整份 `birth`（含 `today`、`transit_date`、`candidate_range` 等全部字段）、`format`、`edition`、`packs`、`languages`、`include_fact_tables`、`REPORT_VERSION_FULL`、代码版本（`GITHUB_SHA`）。`GITHUB_SHA` 缺失或为 `unknown` 时缓存默认关闭。文件名只用哈希；缓存文件放 `scratch/local/` 下（容器内即 `api_scratch` 卷），与 `consult_full_data_cache` 同样两天清理；日志与 BUG 历史不得写入出生资料或缓存键原文。
-7. `scripts/jyotish_api_server.py` 净行数不增长、类方法数不增长、`JyotishAPIHandler.__new__` 伪造点不增长（`tests/test_api_server_growth_contract.py`）；本单预期对该文件**零改动**（缓存放在 `professional_report_reference.py` 内）。
+7. `scripts/jyotish_api_server.py`：行数只按 `tests/test_api_server_growth_contract.py` 的粗护栏（AGENTS.md §6：不另加比测试更严的行数红线，也不得压行凑数），类方法数与 `JyotishAPIHandler.__new__` 伪造点不得增长（`tests/test_api_server_growth_contract.py`）；本单预期对该文件**零改动**（缓存放在 `professional_report_reference.py` 内）。
 8. 不改重计算名额逻辑（`scripts/api_heavy_compute_gate.py`）、不改 `.gitea/workflows/**`、不动表结构与迁移、不升级依赖、不顺手修 warning；`frontend/src/app/(app)/page.tsx` 不碰（本单无前端改动）。
 9. 改既有断言按「原值 / 新值 / 原因」三栏写进 PROGRESS；测试总数不得低于开工时。
 10. 新测试的输入包必须由真实引擎现算（虚构盘，沿用 `tests/test_report_english_edition.py::CASES` / `_packet`），不得手造包形状。