Jyotisha/docs/tasks/TASK-consult-evidence-card-research-20260927.md

TASK · 普通对话「数据卡」调研：后台筛掉多余，只把能出数据的部分交给模型（2026-09-27）

调研单，不改任何线上行为。产出一份报告、一套可复跑的脚本和一张按领域的数据卡草案，交产品与懂印占的人拍板后，再另开实现单。

基线

• origin/staging 5f2e007f（开工时以 git fetch 后的最新 origin/staging 为准，写进 PROGRESS）。
• 分支 codex/consult-evidence-card-research-20260927，工作树 .worktrees/consult-evidence-card-research-20260927。
• 并行中的实现单 codex/consult-single-pass-answer-20260927（BUG-1053，去掉盲写第三步）改的是 frontend/src/app/api/consult/route.ts、frontend/src/lib/stream-agent-response.ts。本单不得修改这两个文件；调研脚本只读调用引擎与投影函数。

事故实证（行号按符号定位，会漂）

1. 2026-09-27 真机：「我和父母关系如何」跑了 10 步，回答却说「这次消息里没有父母主题的盘面证据」。诊断已确认：写答案那一步拿不到任何排盘结果（route.ts composeAnswer 只带 baseMessages + consultationComposePrompt()，判断依据恒空），由 BUG-1053 处理。本单研究的是修好之后该给模型什么。
2. 体量（诊断时用公开样例盘实测）：
   • Python /api/consultation_workflow（scripts/jyotish_api_server.py _compute_consultation_workflow，编排在 scripts/unified_consultation_orchestrator.py）原始输出约 478K 字符。
   • 投影后进模型的工具结果约 133–144K 字符（约 4 万 token）。
   • 单领域时 frontend/src/mastra/consultation-tools.ts toModelDomainPlanContext 返回 {...consultations[0], ...plan, consultations}，同一个包出现两次（consultations 约 71K 字符）。
   • 每份里 varga_spectrum 约 17K、western_spectrum 约 6K、技法审计表约 6.9K（43 行），在 natal 卡与 evidence_contract 里各出现一次。系统提示里的 Skill 方法块约 23K 字符。
3. 相关度：父母问题真正要用的宫位、行星、D12、大运与子运、功能吉凶合计约 5K / 144K ≈ 3.5%。
4. 领域路由缺口：
   • frontend/src/lib/consultation-domain-registry.ts 的 family 把父母与子女混在一起，别名没有「父母 / parents」。
   • frontend/src/lib/consultation-methodology.ts 里 family 的 strictRoute: null；frontend/src/mastra/consultation-workflow.ts DOMAIN_MUST_USE_LAYERS 没有 family 项。
   • Skill 只有一句「D12 for family/ancestral themes」（skills/jyotish-vedic-astrology/references/strict-workflow-router.md 约 163 行）。
   • Python 路由的 focus_techniques（如 D12/4/9 宫）没有投影给模型。
5. 43 项技法审计表（09-26 真机截图）粗分：核心数据约 12 项；状态说明约 8 项（VedAstro 云状态、MEVG、真实案例校准、盲技术模式、时间精度门、证据包等，只说「没做 / 受限」）；本轮不适用 4 项；研究用约 4 项（40 张研究型 D-N、D81/D108/D144、Ashtottari「参数敏感、未验证」）；西洋约 11 项。

根因（本单要证实或推翻）

咨询默认「全算全给」（BUG-287 起），没有一层按问题筛选：模型每轮读约 4 万 token，能用的只有几个百分点；领域到技法的对应关系散落在注册表、方法学、Skill 与 Python 路由四处，彼此不一致，还缺父母这一类。

决策记录（产品 2026-09-27）

• D1 方向已定：在计算引擎与写答案的模型之间加后台筛选。计算可以照旧算全，但只把能写进答案的数据按领域组成「数据卡」交给模型；状态说明、不适用、研究用、西洋层留在后台（报告与审计照用），不给写答案的模型。
• D2 之后按反馈迭代：记录用了哪张卡、答案引用了卡里哪些数据、点赞 / 点踩，据此增删卡内容。本单只设计埋点方案，不实现。
• D3 本单只调研、出草案；数据卡的最终内容由产品和懂印占的人拍板，再另开实现单。
• D4 「家庭」计划拆成「父母」与「子女」两类，本单给出建议映射与依据。
• 本单不推翻任何既有红线：AGENTS Part B 的高严谨要求（双轨大运、按领域分盘、功能吉凶、原始数据）是对输出占星解读的约束，数据卡必须能满足它；若某项红线与「只给相关数据」冲突，写进报告交产品决定，不自行取舍。

硬红线

1. 不改线上行为：不改 frontend/src/app/api/consult/**、frontend/src/lib/stream-agent-response.ts、frontend/src/mastra/** 的运行逻辑、Python 引擎、Skill 文本、数据库。新增文件只放在 scripts/research/、tests/（只测研究脚本的纯函数）、docs/research/、docs/tasks/。
2. 数据只用公开名人样例（仓库 references/real_case_calibration/ 下的公开 AA 开放集）或明确虚构的出生资料；不得出现任何真实用户资料（AGENTS §8）。
3. 每个数字都要附复跑命令；同机 A/B，不跨机器比较浮点哈希（BUG-985）。
4. 不下占星结论。本单是数据工程调研，报告里不写「某人父母关系如何」之类的解读。
5. 禁止 git stash；提交只 git add <具体路径>，提交前看 git diff --cached --stat（ERR-112）。不推送，完成后本地提交交验收。

任务分解（每条带验收标准）

R1 盘点：引擎输出逐项分类与计量

• 用 3 个公开样例盘 × 8 个领域（事业、婚恋、财富、健康、学习、迁居、家庭、综合；另加「父母」「子女」两种问法，走现有 family 路由）真跑 _compute_consultation_workflow，再经 toModelOutput / toModelDomainPlanContext 投影，得到模型实际看到的文本。
• 把投影后的字段逐项归入五类：核心数据 / 状态说明 / 不适用 / 研究用 / 西洋。给出每项的字符数与 token 估算（写明估算方法），以及重复出现的字段与次数。
• 验收：一张「字段 → 类别 → 大小 → 是否重复」总表（JSON + 报告里的汇总表）；五类合计与总大小对得上（误差 < 1%）。

R2 领域 → 技法对照表草案

• 汇总四处现有来源：consultation-domain-registry.ts 的 requiredLayers、consultation-methodology.ts、consultation-workflow.ts DOMAIN_MUST_USE_LAYERS、Skill strict-workflow-router.md 与 jyotish-vedic-astrology 其余 references，外加 Python 路由的 focus_techniques，列出每个领域在四处的差异。
• 起草每个领域的数据卡：
  • 基础段（每张卡都带）：上升、12 宫落星与宫主、功能吉凶星、当前 Vimshottari MD/AD/PD 及起止日期、Narayana 当前段。
  • 领域段：该领域专属的宫位、宫主、分盘、自然星、格局、行运窗口。
  • 「父母」「子女」两张新卡给出依据（引用仓库内 Skill 文字或公开经典出处）。
• 标出每张卡里有没有满足 AGENTS Part B（双轨大运、领域分盘、功能吉凶、原始数据）的字段；不满足的写明缺口。
• 验收：一张可给非程序员看的对照表（领域 × 基础段 / 领域段 / 数据来源 / Part B 覆盖），外加机器可读的 JSON 草案。

R3 数据卡原型与体量对比

• 写一个研究用的纯函数（scripts/research/ 下，Python 或 TS 皆可），输入 R1 的投影结果，按 R2 草案裁出数据卡文本。
• 对 3 盘 × 10 种问法输出数据卡，给出每张卡的大小，与现状（约 4 万 token）对比；并核对卡里关键事实与引擎原始值逐字一致（上升星座、月亮星座与宫位、当前大运起止日期、D12 相关落点）。
• 验收：体量对比表；逐字一致性检查 100% 通过（不一致即报告为缺陷，不得在卡里改值）；样例卡片附在报告附录里（公开名人盘）。

R4 提速空间（只量不改）

• 统计每个领域的数据卡实际依赖哪些计算模块，估算「只算卡里需要的」能省多少引擎耗时（用本机同机计时，不跑外部 VedAstro；外部取证单独列出不计入）。
• 验收：模块 → 被哪些卡依赖 → 本机耗时的表；给出「全算 vs 按卡算」的耗时估计与方法说明。

R5 反馈迭代的埋点方案（只设计）

• 设计每轮要记的字段：领域、卡版本、卡大小、答案引用了卡里哪些字段（如何判定引用，需写清楚方法与误判风险）、点赞 / 点踩。只存数字、枚举与字段名，不存用户文本（AGENTS §8、参照 TASK-rectification-telemetry-20260926 的做法）。
• 设计后台汇总：哪些字段长期不被引用、哪类问题点踩率高。
• 验收：字段表 + 汇总视图草图（文字描述即可）+ 隐私核对清单。

R6 报告

• docs/research/consult_evidence_card_research_2026_09_27.md：结论先行，五节对应 R1–R5；每节一句话结论、复跑命令、是否建议立实现单。
• 结果 JSON 放 docs/research/；docs/tasks/PROGRESS-consult-evidence-card-research-20260927.md 记开工基线、做了什么、没做什么、环境缺口；docs/tasks/README.md 本单一行改为「待验收」。
• 验收：报告里给产品的决策清单（需要拍板的每一项，附推荐与理由），不超过一页。

让步顺序（时间不够时）

1. R1、R2、R3 必须完成（这是拍板的依据）。
2. R4 可以只做 3 个领域。
3. R5 可以只给字段表，汇总视图留待实现单。

开工前置命令

cd /workspace/Jyotisha && git fetch origin --prune
git worktree add -b codex/consult-evidence-card-research-20260927 .worktrees/consult-evidence-card-research-20260927 origin/staging
ln -s /workspace/Jyotisha/frontend/node_modules .worktrees/consult-evidence-card-research-20260927/frontend/node_modules
cd .worktrees/consult-evidence-card-research-20260927
git status -sb
python3 scripts/pre_work_check.py --remote-timeout 8 --command-timeout 45   # 涉及引擎输出，按 AGENTS §9 先跑预检
export PATH=/exec-daemon:$PATH   # 需要跑 TS 投影函数时用 Node 22

先读：AGENTS.md（§5、§8、§9、Part B）、docs/research/pre_work_error_ledger.md（ERR-110 冻结计分文件、ERR-111 PYTHONHASHSEED、ERR-112）、docs/BUG_HISTORY.md 中 BUG-287、BUG-298、BUG-943、BUG-1053（开工时若已合入）。

验收口径

• 新增的研究测试：python3 -m pytest tests/test_consult_evidence_card_research.py（如有）通过；tests/test_repo_privacy_markers.py、tests/test_bug_history_workflow.py 通过。
• 本单提交里不出现 frontend/src/**、scripts/*.py（scripts/research/ 除外）、skills/**、迁移文件的改动。
• 所有表格数字可由报告里的命令复跑得到。

BUG 编号

本单是调研，默认不开 BUG。若发现缺陷（例如投影丢字段、卡里事实与引擎不一致），开工时核对 docs/BUG_HISTORY.md 最大号（staging 上当前为 BUG-1051；BUG-1052、BUG-1053 已被并行实现单占用），从 BUG-1054 起，记为 investigating，不修代码。