5 Commits

Author	SHA1	Message	Date
Jesse_Chen	927bdd7a21	fix(consult): compute the antardasha boundaries answers need, and stop billing an apology for an unwritten answer ... The model packet read chart.modules.dasha_boundaries, a key the engine never wrote, so no answer ever had sub-period boundaries while the receipt still reported precise timing as allowed. The server now cuts the running mahadasha into antardashas out of the periods the packet already shows, exposes them as their own evidence section, and precise timing requires that section. A run whose calculation succeeded and whose model then wrote nothing was answered with a fixed apology and billed as completed. It now asks once more against the cached calculation, and fails with empty_answer—no charge—if that attempt is silent too. Co-authored-by: Cursor <cursoragent@cursor.com>	2026-08-18 18:32:49 +08:00
Jesse_Chen	5caf47a413	fix(consult): require the evidence the product tells the user it will use ... 修完 BUG-267 后核对同一张表时发现，前端领域注册表早就为每个领域声明了 requiredLayers， 键名正确，并且这份列表驱动界面上的 evidencePreview——也就是产品明确告诉用户「这次会用 这些证据」。服务端的门是另写的一份，两份用不同词汇描述同一个合同，彼此没有任何链接， 对照下来门少查三处：marriage 声明 A7 而门只要求 UL，wealth 声明 Ashtakavarga 而门只 要求 D2，general 声明 D10 与 D2 而门只要求 D1/D9。三者实测在真实排盘中都是 used，补进 去不会把状态推成 degraded。失败方向仍是静默放宽，因此没有任何人报错。 新增一条测试解析前端注册表，断言其中每个指向真实 section 的条目都出现在服务端的门里。 只比对真实 section：注册表里还有人看的标签（7th house/lord、negative holdout gate）和 引擎压根不产出的 D11，机械全量对齐会把每条路由钉死在 degraded。该测试 fail-closed—— 先断言 10 条路由全部解析到且列表非空，否则一次正则失配就会让它无声通过。 另外把 tests/test_consultation_consumer_context.py 加进 CORE_PYTEST_TARGETS：该文件 不在任何 CI 档位里，BUG-267 的 8 条与本条的 1 条此前都只在本地手动跑过，staging 门用的 是 --profile quick，从不运行它们。防漂移的钉子本身没人跑，等于没钉。 Co-authored-by: Cursor <cursoragent@cursor.com>	2026-08-18 15:26:57 +08:00
Jesse_Chen	10ae149c58	fix(consult): check the evidence gate against the route the answer is on ... 七条路由的证据门都不是自己的：route_requirements 的键写成 relationship/finance，而 路由名是 marriage/wealth，另有 5 条路由压根没有条目，全部静默落到 general 的门。 missingLayers: [] 因此不表示证据齐备，只表示没检查过——婚姻的 UL 与财富的 D2 从未 进入检查。 同一函数另有两处判据也没接到权威来源。7 块正则用问题文本重猜领域，而领域早已由模型 声明并写进 route_packet，一句写作「情感」而非表里「感情」的提问在 marriage 路由上完全 拿不到性别解读边界。timing_layers_ready 读的是 missing_route_layers，该列表只装本路由 要求的层，于是对任何不要求 narayana_dasha 的路由恒为真，精确应期在该层根本没算出来时 也照样放行。三处的失败方向都是静默放宽，因此没有任何人报错。 三处都接回权威来源：10 条路由逐条显式列出必需层（层名限定为证据包真实构建的 section， 所以 wealth 不要求引擎不产出的 D11）、领域边界按 route 查表、出生时间边界从矫正闸门的 effective_accuracy 与 Lagna 敏感度派生、就绪判断直接读 section 状态。唯一保留文本探测 的是「用户有没有要一个具体日期」——服务端对此没有权威来源，改为 timing/annual 路由结构 性携带、文本仅作叠加，一次措辞漏判不再能把信号清零。 另外把 skillReferenceReadCount 暴露为回执的 skill.referenceReads（必填）与可观测日志的 skillReferenceReads。它此前数完即丢，而 skill_read 按设计不记成 runtime step，因此「模型 有没有真的翻开方法文档」在运行结束后无处可查。 Co-authored-by: Cursor <cursoragent@cursor.com>	2026-08-18 11:50:28 +08:00
Jesse_Chen	b637528f14	fix: propagate consultation evidence before audit	2026-08-10 19:40:11 +08:00
Jesse_Chen	4aa0105fa4	feat: add Railway-ready Jyotish chat product	2026-07-15 22:23:17 +08:00