Jyotisha/docs/tasks/TASK-consult-card-full-source-fix2-20261009.md

TASK · 对话数据卡同源第二轮修复：事业不按星性猜职业、预热不占重计算名额（2026-10-09）

• 分支：继续在 codex/consult-card-full-source-20261007（远端 e47c161a）上做。开工先确认已含最新 origin/staging。
• 前序：TASK-consult-card-full-source-20261007.md、TASK-consult-card-full-source-fix-20261009.md 仍有效。
• BUG 编号：本分支已用到 BUG-1300，本单从 1301 起，开工时核对。

1. 验收实证（Claude，2026-10-09，Linux）

通过：Python 全量 62 条失败与基线逐名相同；快速门通过；npm test 4997 / 失败 24 与基线相同；tsc 0。F1（缓存按参照日期，两天清理）、F2（卡最大 18,193 字符，无内部路径）、F3（星照有出处）、F4（真实金样）、F5（保存后预热）均已做到。

未通过：

#	问题	证据
G1	生平回测严重冲突 1 → 3（红线 6 不允许升高）	新增 2 条都是齐达内事业题（两次都把公开的球星写成「靠专业判断、说得清、写得明、算得出」，压低「外面认不认你」）。Claude 用引擎生成齐达内事业事实（Raman、平均交点、参照日 2026-09-27）核对：水星同时是事业自然代表星（event_judgment_career.md §2）、当前 PD 主星、入庙、功能吉星，并与太阳、金星同在 2 宫。判断表把它反复点出，模型按水星的本性（说、写、算）推出职业类型，违反产品 2026-10-03 定的「不猜行业、问用户」（CAREER_FIELD_ASK_RULE）
G2	预热可能挤占重计算名额	frontend/src/lib/consult-packet-warm.ts 在保存后调用完整的 /api/consultation_workflow。API 重计算并发上限是 JYOTISH_HEAVY_COMPUTE_CONCURRENCY（默认 2），饱和返回 429。用户保存后立刻提问，可能撞上预热

2. 决策记录（产品 2026-10-09）

1. 事业清单加一条规则后重跑回测：判断表里的代表星（自然代表星、Jaimini 代表星、大运主星）只用来看力量与受冲，不按星的本性推断职业类型、做事方式或台前 / 幕后；职业类型仍按既有规则问用户。严重冲突回到 ≤ 1 才合入。
2. 回测用的临时 key 仍只放执行方会话的环境变量，不进任何文件。

3. 硬红线

1. 规则写进事业领域清单（frontend/src/lib/consultation-condensed-checklist.ts），不进系统提示；系统提示仍 ≤ 26.6K。不改首轮形状与口吻。
2. 不删判断表里的行；不改卡片取值。
3. 预热不得让用户自己的请求因名额被占而收到 429；预热失败不影响保存。
4. 前序全部红线继续有效。

4. 任务分解

#	内容	验收标准
G1	事业清单加决策 1 的规则；若其他领域清单也有按星性推断性格 / 职业的漏洞，一并列出（只列，不改）	新测试锁住这句；系统提示长度不变
G2	预热改为只生成当天的资料包（例如复用现有入口加一个只预热的参数，或在 Python 侧低优先级执行），并且不占用户请求的重计算名额；保持不新增 API 类方法	测试或实测：预热进行中时，用户请求不因并发上限返回 429；tests/test_api_server_growth_contract.py 通过
G3	生平回测重跑：9 位人物 × 父母 / 婚恋 / 健康 / 事业 × 2 次，改前（staging 现状）与改后	严重冲突 ≤ 1，对照组误报 0；齐达内事业两次都不再按星性写职业类型；数字写进进度记录
G4	Linux 或门禁同等环境：快速门、Python 全量 ⊆ 基线、npm test 失败名单与基线相同、tsc 0、lint 0 error、next build / Static	全部满足
G5	记录	docs/BUG_HISTORY.md（1301 起）、CHANGELOG.md、进度记录、状态板

5. 让步顺序

无。G1、G2、G3 都是合入前提。