fix(consult): attach transit windows and VedAstro minute snapshots
Consult only copied Sade Sati and never searched trigger dates; V9 score left official minute identity unevaluated. Search a 90-day slow-planet window and run two-candidate snapshots with timeout staying not_evaluated. Co-authored-by: Cursor <cursoragent@cursor.com>
This commit is contained in:
Jesse_Chen
+33
-1
@@ -4161,7 +4161,7 @@
|
||||
- 根因：一个名字指着两个对象。模型侧 `local_layers.dasha_boundaries` 读 `chart.modules.dasha_boundaries`，而这个键在整个仓库里从未被赋值过——`_attach_local_consultation_layers` 只挂 varga_full / arudha_padas / narayana_dasha / ashtakavarga / kp_cusps——所以该字段恒为 `undefined`，投影时整段消失，模型手上只剩 `chart.dasha.periods`，也就是 6 到 20 年一段的大运列表。证据门里同名的分节 `dasha_boundaries` 读的却是 `modules.dasha`（大运），它当然是 `used`，于是 `timing_layers_ready` 成立、`can_answer_precise_timing` 为真。回执因此签发了「能给到月份」的许可，而模型连一条副运边界都没有，只能在回答里如实说副运没算全。两侧各自自洽：读的一侧永远拿不到数据，判的一侧永远看得见数据，中间没有任何断言比较过这两个名字是不是同一个对象。BUG-268 让 `skillReferenceReads` 可见时曾怀疑是模型没翻方法文档，本条说明缺的是数据本身。
|
||||
- 修复：三处。其一，服务端真的算出副运并挂到 `modules.dasha_sub_periods`：从 `chart.dasha.periods` 里取出覆盖参考日的那一段大运，用 `dasha_analyzer.build_antardasha` 按比例细分为 9 段。刻意不复用现成的 `_compute_vimshottari_analysis_layer`（它从月亮黄经另建一条时间线）：两条线出自同一引擎、数值几乎一样，但「几乎」意味着模型手上会出现两套大运日期且无从判断该引用哪套；从包里已经展示给模型的 periods 上切，副运边界必然落在模型看得见的大运边界之内。其二，证据包新增独立分节 `dasha_sub_periods`（源路径写明 `modules.dasha_sub_periods`），精确应期改为同时要求 `dasha_boundaries` + `dasha_sub_periods` + `narayana_dasha`——大运列表只能定位十年，本就不该单独签发月份级许可。其三，模型侧字段随之改名为 `local_layers.dasha_sub_periods`，与服务端实际写入的键对齐；Agent 指令补一句：该层在场就用它的边界、不得再说副运没算，缺席则一句话说明。
|
||||
- 验证：真实排盘端到端跑通（1990-05-12 北京，参考日 2026-08-18）：`current.mahadasha` 与 `chart.dasha.periods` 里的 Sun 段逐字段相同（2024-07-03→2030-07-03），当前副运为 Jupiter 2026-07-21→2027-05-09，9 段副运首尾正好贴合大运首尾，`local_consultation_layers.diagnostics` 为空，分节 `used`，`can_answer_precise_timing` 为真。`tests/test_consultation_consumer_context.py` 21 项通过（新增 4 项：副运边界必须切自包里展示的 periods 且覆盖参考日；跨语言键名守卫；只缺副运时精确应期必须被拒；副运在场时放行）。测试基准盘原先只写了 `{'current_md': 'Sun'}`，已改为用 `compute_vimshottari_timeline` 派生真实 periods，否则新层在 fixture 上根本不会被执行。前端除数据库套件（本机无 Postgres）外 1633 项通过，`tsc --noEmit` 与 `eslint` 清洁。
|
||||
- 待跟进：Pratyantardasha（第三层）与行运触发仍未计算，层内 `summary` 已明说这条边界，所以「哪一周」这类问题仍只能答到副运级别。`_compute_vimshottari_analysis_layer` 那条从月亮黄经另建的时间线仍留在 dasha 接口路径上，未与本层合并。未做的验证：没有在 staging 上复看真实回答是否不再出现「副运没算全」。
|
||||
- 待跟进：Pratyantardasha（第三层）仍未计算，所以「哪一周」仍只能答到副运加 90 天慢行星触发窗，不能声称精确到日。`_compute_vimshottari_analysis_layer` 那条从月亮黄经另建的时间线仍留在 dasha 接口路径上，未与本层合并。行运触发窗已由 BUG-302 接入咨询包。未做的验证：没有在 staging 上复看真实回答是否不再出现「副运没算全」。
|
||||
- 防复发：跨语言的字段名不能靠人眼对齐。一端读 `modules.X` 而另一端从不写 `X`，两侧测试都不会失败——读的一侧只看到 `undefined` 被投影掉，写的一侧根本不知道有人在读。已加的守卫直接比较两端：把 `local_layers` 里所有 `modules.<key>` 读法抽出来（先剥注释，否则解释性注释里的旧键名会被算成读法），与服务端真实挂载后的 `chart['modules']` 键集合求差，非空即失败。另一条教训是分节名要说清自己是什么：`dasha_boundaries` 既能读成「大运边界」也能读成「所有周期边界」，正是这层歧义让门以为自己检查过副运。
|
||||
- 相关记录：BUG-267（同一段代码里另一处「判据没接到权威来源」，精确应期的空判是那轮修的）、BUG-270（同为两端声明不一致且缺跨端断言）、BUG-268（同一批可观测性问题，本条是它排除掉的另一种解释）
|
||||
- 复发自：无
|
||||
@@ -4522,3 +4522,35 @@
|
||||
- 相关记录：BUG-161、BUG-159、BUG-300
|
||||
- 复发自：BUG-161（超时防护把可选官方层整段关掉）
|
||||
- 修复版本：待提交
|
||||
|
||||
## BUG-302 | 咨询行运层只挂了 Sade Sati，触发窗从未搜索，模型只能说行运没算
|
||||
|
||||
- 状态：resolved
|
||||
- 首次发现：2026-08-19
|
||||
- 最近更新：2026-08-19
|
||||
- 影响面：普通咨询 `_attach_local_consultation_layers` 的 `modules.transits`、`toModelOutput` timing / western_spectrum、口头应期
|
||||
- 用户现象：skill 共同基础含行运，引擎也有 `transit_trigger.search_all_transit_triggers`，但网页咨询只能看到土星过月阶段，回答继续写「行运触发未在本轮完整计算」。西洋应期层已算完，发给模型的压缩包却只剩 status。
|
||||
- 触发条件：有出生分钟的个人盘咨询，尤其问未来数月或行运。
|
||||
- 根因：attach 只复用 `chart.transit_triggers`（咨询排盘从不写这个键），从不调用触发搜索。西洋压缩只保留 status/boundary，把 target_date、aspects、duration windows 裁掉。
|
||||
- 修复：咨询对参考日起 90 天、土星/木星/罗睺/计都对升一与月亮做有界触发搜索，最多 6 条日期窗进模型包；空列表表示该窗无精确接触，不是没算。西洋压缩补日期、aspects、扫描窗，去掉回盘钟点和经度。口头合同：`search_period` 在场就不得再说行运没搜。不提高 `AGENT_TIMEOUT_MS`，不发明水星逆行。
|
||||
- 验证：`tests/test_consultation_consumer_context.py` 锁定搜索窗与触发压缩、西洋窗保留且去掉钟点；`frontend/tests/consultation-context.test.ts`、`consultation-spectrum-parity.test.ts`、`consultation-voice-contract.test.ts`。
|
||||
- 防复发：`modules.transits` 必须带 `search_period`；模型包 timing 必须投影 `triggers`；西洋 techniques 不得只留 status。
|
||||
- 相关记录：BUG-279、BUG-300
|
||||
- 复发自：BUG-279（副运修好后，待跟进里的行运触发仍未接上）
|
||||
- 修复版本：待提交
|
||||
|
||||
## BUG-303 | 校正确认门的 VedAstro 分钟快照从未在 V9 评分路径执行，状态永远 not_evaluated
|
||||
|
||||
- 状态：resolved
|
||||
- 首次发现：2026-08-19
|
||||
- 最近更新：2026-08-19
|
||||
- 影响面：`/api/rectification/v5/score`、`/api/rectification/v5/diagnostics`、`confirmation_gate.vedastro_minute_sensitive`
|
||||
- 用户现象：确认门 VedAstro 一行长期 `not_evaluated`。独立的 `/api/rectification/v5/vedastro-validate` 存在，但 V9 评分从不调用分钟身份层；SearchEvents 也不是确认判据。
|
||||
- 触发条件：V9 `rectification-compare-candidates` / diagnostics 产生两名候选且本地 `acceptance_allowed`。
|
||||
- 根因：`build_decision_receipt` 把 `external_validation_status` 写死为 `not_evaluated`。评分 HTTP 层不附加官方分钟快照。超时若被标成 fail，会把「没跑完」说成「校验失败」。
|
||||
- 修复：本地接受门通过且有两个不同 HH:MM 时，并行跑官方分钟快照（升一/宫界、D9、D10、Dasha 指纹），不跑 SearchEvents。区分则 `passed`，完整比较后无法区分则 `failed`；超时、不完整或未就绪保持 `not_evaluated`。引擎 `confirmation_allowed` 仍为 false；公开 AA holdout 仍 `not_ready`，不得写唯一分钟。回执不带坐标或 fingerprint。
|
||||
- 验证：`tests/test_rectification_v5_vedastro_validation.py` 锁定通过/无法区分/超时/本地未就绪跳过，且不调用 range scan。
|
||||
- 防复发：V9 评分路径必须写 `gates.exact_confirmation.external_validation_status`；赶不上不得改成 fail；SearchEvents 不得单独放行确认。
|
||||
- 相关记录：BUG-301
|
||||
- 复发自：无
|
||||
- 修复版本：待提交
|
||||
|
||||
Reference in New Issue
Block a user