星盘页和报告的大运统一从真实出生时刻算 #137

Open
opened 2026-10-28 06:03:15 +08:00 by Claude · 2 comments
Collaborator

来自 #118 代码体检(体检第 19 条),清单第 18 单。由 Claude 直接实现,不交 Grok。

问题

Vimshottari 两套起算口径:/api/chart(domain_calculation_service.compute_vimshottari_timeline → dasha_analyzer.build_dasha_timeline)和校正探针从出生当天 0 点起算;报告与完整解读(jyotish_engine.cmd_dasha)从真实出生时刻起算。两边边界最多差 1 天。

改法

build_dasha_timeline 接收真实出生时刻;年数表改读 dasha_common。产品 10-28 同意(用户可见日期会变,最多一天)。属引擎改值:按规矩跑全量 pytest 与基线逐条比,校正 11 个场景按研究协议重新冻结(ERR-110)。

验收标准

golden 盘上 /api/chart 与 cmd_dasha 的 MD/AD 边界逐项相等;全量 pytest 只有预期的值变化,逐条写原值 / 新值 / 原因。

规矩

  • 基于 origin/staging,独立工作树 codex/*;只改这一件事。
  • BUG 号开工时按 docs/BUG_HISTORY.md 全文件取最大号 +1。
  • 同时改 frontend/src/app/(app)/page.tsx 的单按清单顺序串行。
  • 体检报告:docs/research/code_health_audit_2026_10_28.md(staging a31b6dda3)
来自 #118 代码体检(体检第 19 条),清单第 18 单。**由 Claude 直接实现,不交 Grok。** ## 问题 Vimshottari 两套起算口径:`/api/chart`(`domain_calculation_service.compute_vimshottari_timeline` → `dasha_analyzer.build_dasha_timeline`)和校正探针从出生当天 0 点起算;报告与完整解读(`jyotish_engine.cmd_dasha`)从真实出生时刻起算。两边边界最多差 1 天。 ## 改法 `build_dasha_timeline` 接收真实出生时刻;年数表改读 `dasha_common`。**产品 10-28 同意**(用户可见日期会变,最多一天)。属引擎改值:按规矩跑全量 pytest 与基线逐条比,校正 11 个场景按研究协议重新冻结(ERR-110)。 ## 验收标准 golden 盘上 `/api/chart` 与 `cmd_dasha` 的 MD/AD 边界逐项相等;全量 pytest 只有预期的值变化,逐条写原值 / 新值 / 原因。 ## 规矩 - 基于 origin/staging,独立工作树 `codex/*`;只改这一件事。 - BUG 号开工时按 `docs/BUG_HISTORY.md` 全文件取最大号 +1。 - 同时改 `frontend/src/app/(app)/page.tsx` 的单按清单顺序串行。 - 体检报告:`docs/research/code_health_audit_2026_10_28.md`(staging `a31b6dda3`)
Claude added the agent/试点agent/排队 labels 2026-10-28 06:03:19 +08:00
Author
Collaborator

@jesse 星盘页这一半改完了,推上 staging(5fd79a56,同一批),正在部署。另一半(生时校正内部)需要你定。

已改:星盘页、对话旁星盘、今日星语、KP 月度报告的大运和小运,改为和长报告一样从真实出生时刻起算。

60 张标准测试盘 和长报告逐项一致
改前(星盘页) 9 张
改后 大运 60/60,小运 60/60
  • 有 51 张盘的边界日期会挪,每个最多一天(你 10-28 同意过);大运顺序、年数、出生时的余额都不变。
  • 检查:Python 快速门全部通过(包括校正冻结文件的完整性检查);新增 12 条测试。记为 BUG-1492。

没改、需要你定:生时校正内部的计算。 校正打分用的两个文件也是从出生当天 0 点起算,但它们在校正研究的「冻结清单」里:改了会让校正的打分结果变化(不是结果不变的那种),按研究规矩要把封存的 20 个案例和 900 个偏移案例全部重跑、你确认新结果后才能用。所以这次没动,校正和星盘页之间仍可能差一天。

你选:

  • A(推荐):先这样。星盘页、报告、今日星语已经一致;校正内部的口径另开一单,按研究规矩重跑、出对比给你看,再决定换不换。
  • B:校正这一半也现在做(要跑完整的重冻结流程,耗时较长,结果会变)。
  • C:维持现状,不再动校正。

真机清单:第 27、28 条。

<!-- agent:claude escalate review sha=5fd79a56 verdict=pass staging=12eb7018ecfb35c3bec0c25bd74efd6ba9a65816 checklist=docs/testing/code-health-118-20261028.md --> @jesse 星盘页这一半改完了,推上 staging(`5fd79a56`,同一批),正在部署。**另一半(生时校正内部)需要你定。** **已改**:星盘页、对话旁星盘、今日星语、KP 月度报告的大运和小运,改为和长报告一样从真实出生时刻起算。 | 60 张标准测试盘 | 和长报告逐项一致 | | --- | --- | | 改前(星盘页) | 9 张 | | 改后 | 大运 60/60,小运 60/60 | - 有 51 张盘的边界日期会挪,每个最多一天(你 10-28 同意过);大运顺序、年数、出生时的余额都不变。 - 检查:Python 快速门全部通过(包括校正冻结文件的完整性检查);新增 12 条测试。记为 BUG-1492。 **没改、需要你定:生时校正内部的计算。** 校正打分用的两个文件也是从出生当天 0 点起算,但它们在校正研究的「冻结清单」里:改了会让校正的打分结果变化(不是结果不变的那种),按研究规矩要把封存的 20 个案例和 900 个偏移案例全部重跑、你确认新结果后才能用。所以这次没动,校正和星盘页之间仍可能差一天。 你选: - **A(推荐)**:先这样。星盘页、报告、今日星语已经一致;校正内部的口径另开一单,按研究规矩重跑、出对比给你看,再决定换不换。 - **B**:校正这一半也现在做(要跑完整的重冻结流程,耗时较长,结果会变)。 - **C**:维持现状,不再动校正。 真机清单:第 27、28 条。
Claude added agent/部署中 and removed agent/排队 labels 2026-10-28 14:29:32 +08:00
Author
Collaborator

已部署到 staging(12eb7018,现在线上是包含它的 537beb29),@jesse 可以真机验收了。 门禁、迁移、部署全部成功;登录页正常,未登录访问账户接口被拒绝(401)。

真机清单:docs/testing/code-health-118-20261028.md 第 27–28 条:出生时间不在 0 点的盘,星盘页大运 / 小运日期和完整报告逐个一样;今日星语和星盘页一致。

上面那个选择还等你回:生时校正内部的大运起算要不要也改(A 先这样、另开单出对比;B 现在就做;C 不再动)。回一个字母就行。

<!-- agent:claude deployed sha=12eb7018ecfb35c3bec0c25bd74efd6ba9a65816 --> **已部署到 staging(`12eb7018`,现在线上是包含它的 `537beb29`),@jesse 可以真机验收了。** 门禁、迁移、部署全部成功;登录页正常,未登录访问账户接口被拒绝(401)。 真机清单:`docs/testing/code-health-118-20261028.md` 第 27–28 条:出生时间不在 0 点的盘,星盘页大运 / 小运日期和完整报告逐个一样;今日星语和星盘页一致。 **上面那个选择还等你回**:生时校正内部的大运起算要不要也改(A 先这样、另开单出对比;B 现在就做;C 不再动)。回一个字母就行。
Claude added agent/待真机 and removed agent/部署中 labels 2026-10-29 10:15:12 +08:00
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: root/Jyotisha#137