docs(tasks): 记录产品两项决定（分类用会话模型 / 年份采样不改）

产品 2026-09-15 对审计单里挂着的两个待拍板项给出结论，两项都是「不改」：

- 意图分类继续用会话选定的模型，不引入便宜快模型，模型目录不新增
  「工具模型」角色。failure-attribution 单 §4.6 立为决策记录，§10 从
  「待产品拍板后另开单」改为已决定不做；本单只改归因，不改用哪个模型。
- 只给年份的事件继续采满 12 个月，降采样不做、研究单也不立。
  engine-memoization 单 §4.2 / §11 同步，并写明后续不得以性能为由重提。

两条都加了「要重提必须先拿到产品新的授权」，避免下一轮被当成遗漏又提一次。

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

docs/tasks/README.md

@@ -234,8 +234,8 @@
 | `TASK-api-server-decomposition-20260916.md` | `PROGRESS-api-server-decomposition-20260916.md` | **重构单（串行在 qizheng 单之后）**：把业务逻辑搬出 `JyotishAPIHandler`。核心不是行数，是全仓 3 处靠 `JyotishAPIHandler.__new__` 伪造空壳 handler 借方法（`consultation_workflow_service` ×2、`capture_report_blocked_repairs_golden`、`local_accuracy_report`，MCP 也走这条），依赖方向反了、handler 没有 `headers`/`wfile` 随时可炸。四阶段：拆 `__new__` 后门 → 抽 ≥150 行业务方法 → `do_POST`/`do_GET` 改路由表 → 重新冻结行数 baseline（余量 300→50）。纯搬运不改行为，`test_api_server_security.py` 3841 行断言一条不许改。预计 11,314 → 约 9,230 行。BUG 段 710+ | 待领取 | — |
 | `TASK-chart-vedastro-decouple-20260915.md` | `PROGRESS-chart-vedastro-decouple-20260915.md` | **P0**：星盘页首屏那一发 `/api/chart` 没传 `skip_vedastro_main_entry_overview`，实测冷算 0.40–0.66 秒里约 0.36 秒是 VedAstro 空转（本机连 endpoint 都没配）；生产 env 开着 network + fanout，等于首屏同步等 24 个外部请求 + 3 次领域扫描，而 `chart-view-mapper.ts` / `chart-view-contract.ts` 根本不读这份证据。星历页同端点传了标志，两页策略相反。BUG-718，**复发自 BUG-161**（前台请求不得同步串联可选外部证据）。串行在 chart-page-blocking-open 之后 | 待验收 | `codex/chart-vedastro-decouple-20260915` |
 | `TASK-vedastro-runtime-ops-20260915.md` | `PROGRESS-vedastro-runtime-ops-20260915.md` | 运行期真相单（与上单并行，文件不重叠；**不得改 `jyotish_api_server.py`**）：官方 `vedastro==1.23.25` 其实是 REST 客户端（46 KB，全打 `api.vedastro.org`），且 import 时请求 pypi 并 `pip install --upgrade` 自升级——本机实测 pin 装完一 import 就变 1.23.26，`requirements.txt` 的锁在运行期是假的（BUG-719）；无 key 时免费层排队是同步 sleep + 全局锁，24 个请求 ≈ 4.8 分钟堵住前台线程（BUG-720，定级依赖生产 key 是否配置）。生产 env 核对清单在 `docs/testing/vedastro-runtime-20260915.md`，**只能由产品负责人执行**。台账 ERR-107 / ERR-108 | 待验收 | `codex/vedastro-runtime-ops-20260915` |
-| `TASK-rectification-engine-memoization-20260915.md` | — | **性能单（纯 Python，独占引擎三文件，可并行）**：一次重算 45% 的 CPU 是重复算同一份 Shadbala——`build_candidate_static_context` 每个候选分钟已算过一次却只留哈希、丢掉结果，`_candidate_row` 在「候选 × 事件 × 采样日期」最内层再算 36 遍（实测 2196 次 vs 应 61 次）。过境盘只依赖事件日期却按候选算 2196 次（应 36）；鉴别探针一次请求算两遍；`_cached_rows` 是死代码。本机等价实验 3358 → 1604 ms（**快 53%**），`candidate_scores` 与 `decision_receipt` 逐字相同（唯一差异是计时字段）。**只做记忆化，不改算法**；year 精度采样 12 个月不在范围。BUG 段 721 | 待领取 | — |
-| `TASK-rectification-failure-attribution-20260915.md` | — | **三处把系统故障说成别的东西（独占 `route.ts`）**：意图分类器两次异常返回的 `null` 与用户真的「说不清」共用一条分支，回一句「我不太确定这句是不是在回答上面的问题」，**用户这句里的经历直接丢弃且不写证据**（BUG-722，采集题分支早已改对、点选题分支没跟上）；引擎 429（`ERR_COMPUTE_BUSY` + `Retry-After`）被压成 `engine_request_failed`，不重试不打日志，证据记下了但范围不动、模型照说「记下了」（BUG-723，**复发自 BUG-715**）；attempt 210s × 2 = 420s > 路由 `maxDuration` 240s，重试必超预算（BUG-724，**复发自 BUG-059**，BUG-388 的防复发只写了单次尝试）。超时改成整轮一个预算，不砍 attempt 也不提 240 | 待领取 | — |
+| `TASK-rectification-engine-memoization-20260915.md` | — | **性能单（纯 Python，独占引擎三文件，可并行）**：一次重算 45% 的 CPU 是重复算同一份 Shadbala——`build_candidate_static_context` 每个候选分钟已算过一次却只留哈希、丢掉结果，`_candidate_row` 在「候选 × 事件 × 采样日期」最内层再算 36 遍（实测 2196 次 vs 应 61 次）。过境盘只依赖事件日期却按候选算 2196 次（应 36）；鉴别探针一次请求算两遍；`_cached_rows` 是死代码。本机等价实验 3358 → 1604 ms（**快 53%**），`candidate_scores` 与 `decision_receipt` 逐字相同（唯一差异是计时字段）。**只做记忆化，不改算法**；year 精度采满 12 个月**产品 2026-09-15 决定不改、研究单也不立**。BUG 段 721 | 待领取 | — |
+| `TASK-rectification-failure-attribution-20260915.md` | — | **三处把系统故障说成别的东西（独占 `route.ts`）**：意图分类器两次异常返回的 `null` 与用户真的「说不清」共用一条分支，回一句「我不太确定这句是不是在回答上面的问题」，**用户这句里的经历直接丢弃且不写证据**（BUG-722，采集题分支早已改对、点选题分支没跟上）；引擎 429（`ERR_COMPUTE_BUSY` + `Retry-After`）被压成 `engine_request_failed`，不重试不打日志，证据记下了但范围不动、模型照说「记下了」（BUG-723，**复发自 BUG-715**）；attempt 210s × 2 = 420s > 路由 `maxDuration` 240s，重试必超预算（BUG-724，**复发自 BUG-059**，BUG-388 的防复发只写了单次尝试）。超时改成整轮一个预算，不砍 attempt 也不提 240。**产品 2026-09-15 决定：意图分类继续用会话选定的贵模型，不新增「工具模型」角色** | 待领取 | — |
 | `TASK-rectification-settled-render-split-20260915.md` | — | **前端性能单（独占校正会话组件，可并行）**：`rectification-agentic-chat.tsx` 1973 行、`useMemo` 0 个、`memo` 0 个，`messages.map` 内联在组件体里且逐条新建时间轴数组与 choice card，`ChatMessageRow` 无 memo、结算态 Markdown 走没有缓存的 `renderProse`。流式每帧（~60/s）重渲整条会话并重跑每条已结算消息的 Markdown。BUG-473 在本文件只落地了 `stream-frame-buffer`，咨询面的 `SettledMessageList` + `HistoryMessageEntry` 拆分没有跟过来。**零行为变化**；验收必须有按帧驱动的渲染计数断言（照 `home-streaming-render-split.test.ts`）。BUG 段 725 | 待领取 | — |
 | `TASK-rectification-request-dossier-cache-20260915.md` | — | **低风险单，串行在 failure-attribution 之后（同改 `route.ts`）**：一轮 Agent 对话实测取 3.44 次整份 Case 档案（点选题 2.07 次），全仓约 40 个调用点、请求内零缓存；档案是「最近 50 轮 turns + 全部 evidence + 合成收据」的大 jsonb。做法是包装 `accounting` 客户端做**写即失效**的请求作用域缓存（两个只读投影命中缓存，其余任何 RPC 先清空再转发），**零调用点改动**。不得做成「请求内只读一次」——档案在请求内会变。BUG 段 726 | 待领取 | — |
 

docs/tasks/TASK-rectification-engine-memoization-20260915.md

@@ -55,7 +55,7 @@
 产品 2026-09-15 授权本单，范围严格限定为：
 
 1. **只做记忆化，不改任何算法、权重、阈值、采样规则。** 本单交付后，任何一个存量 Case 重算出来的 `candidate_scores`、`decision_receipt`、`candidate_feature_snapshot` 必须与改前逐字相同。不需要重新校准，不影响任何已有结论。
-2. **不碰 `sample_event_dates`。** 表里「只给年份 4 908 ms vs 给到月 1 891 ms」的 2.6 倍差来自 year 精度采满 12 个月。降采样会改变打分，必须先离线量测命中率，属于另一张研究单，本单不得顺手改。
+2. **不碰 `sample_event_dates`。产品 2026-09-15 明确决定：只给年份的事件采样方式不改，也不立研究单。** 表里「只给年份 4 908 ms vs 给到月 1 891 ms」的 2.6 倍差来自 year 精度采满 12 个月；降采样会改变打分，产品选择保留现状。本单不得顺手改，后续轮次也不得以「性能」为由重提——要重提必须先拿到产品新的授权。
 3. **不修 `build_candidate_static_context` 里 Shadbala 的 `birth_hour` / `birth_minute` 双算。** 该处传 `birth_hour = hour + minute/60` 的同时又传 `birth_minute = minute`，`calc_kala_bala` 因此把分钟算了两次。它只流进 `fingerprints.shadbala` → `fingerprints.static`，改了会让所有候选特征指纹变化。本单按现状照搬，记为观察项，不修。
 4. **不动 `_SWISSEPH_LOCK`、不动并发闸门、不引入多进程。** 那是另一个量级的改动，先把浪费去掉再谈。
 
@@ -164,7 +164,7 @@ git status -sb | head -1        # 确认分支
 
 ## 11. 不在本单范围
 
-- year 精度采样 12 → N 的降采样（要先离线量测命中率，另开研究单）
+- year 精度采样 12 → N 的降采样（**产品 2026-09-15 已决定不改，研究单也不立**，见 §4.2）
 - `_SWISSEPH_LOCK`、并发闸门、多进程、加机器
 - 前端侧的等待体验（另有三单）
 - `build_candidate_static_context` 的 `birth_minute` 双算（§4.3 记为观察项）

docs/tasks/TASK-rectification-failure-attribution-20260915.md

@@ -94,6 +94,7 @@ if (!response.ok) {
 3. **超时按「整轮一个预算」重构，不是简单调数字。** 不接受把 attempt 砍到 110 s——那会把 BUG-388 重新打开（带引擎重算的轮次实测就要超过 105 s）。也不接受把 `maxDuration` 提到 430 s——让用户等七分钟不是产品。
 4. **并发闸门（默认 2）、`_SWISSEPH_LOCK`、fail-fast 不排队三项一律不动。** 那是主机只有 2 vCPU 的保护，不是 bug。吞吐问题由 `TASK-rectification-engine-memoization-20260915` 解决。
 5. **不改计费口径。** 现在这三条失败路径都发生在 `billing.reserve()` 之前或走 release，用户不扣点；改完必须仍然不扣点。
+6. **意图分类继续用会话选定的模型，不引入便宜快模型。** 产品 2026-09-15 明确决定：分类用贵的。因此模型目录**不新增**「工具模型」角色，`classifyRectificationTurnIntent` / `classifyTurnIntentWithRetry` 继续走 `resolveSessionLanguageModel` 的返回值。本单不得以「省钱 / 提速」为由改模型选择；后续轮次要重提必须先拿到产品新的授权。本单只改**归因**，不改**用哪个模型**。
 
 ## 5. 硬红线
 
@@ -193,7 +194,7 @@ npm run build                      # `/` 仍须 ○ Static，首屏 gzip ±2%
 
 ## 10. 不在本单范围
 
-- 分类是否改用便宜快模型（现在三次分类都走会话选的贵模型）：需要在模型目录里新增「工具模型」角色，涉及计费口径，**待产品拍板后另开单**。
+- 分类改用便宜快模型：**产品 2026-09-15 已决定不改，分类继续用会话选定的贵模型**，不另开单（见 §4.6）。
 - 并发闸门、`_SWISSEPH_LOCK`、加机器。
 - 引擎本身的耗时（见 `TASK-rectification-engine-memoization-20260915`）。
 - 请求内 Case 档案缓存（见 `TASK-rectification-request-dossier-cache-20260915`，串行在本单之后）。