root/Jyotisha
1
0
Fork 0
Code Issues 104 Pull Requests Actions Packages Projects Releases Wiki Activity

【需拍板】生时校正是否引入 D60 / 纳迪分盘换格，宣传「证据够时可到秒」 #149

New Issue
Open
opened 2026-10-28 15:08:13 +08:00 by jesse · 10 comments
jesse commented 2026-10-28 15:08:13 +08:00
Owner
Copy Link
Copy Source

Part of #142（拆单 B5，来源：#142 评论 0 说明页 + 评论 1）

竞品怎么说

「证据够密时 D60 每格 0.5°、上升约两分钟一格，纳迪层一格不到一分钟……收束时刻可以到秒」，并在对话里用 D9 换升点、四级运分界切窗。

我们的现状

skills/jyotish-birth-time-rectification/references/technique-routing.md 规定 D60 只作参考，Tajika / KP 被阻塞或只作参考；校正后端没有 D60 / 纳迪换格评分。

需要决定

  1. 是否把 D60 / 纳迪换格纳入评分（会改动 skill 的技法规则）？
  2. 对外文案能不能写「可到秒」？

建议：先不写「到秒」。若要引入，先做研究单：按 AGENTS.md 高严谨规则跑 MEVG 与真实案例校验，三大参照引擎交叉，结果达标再改规则和文案。

拍板后再拆执行单。

Part of #142（拆单 B5，来源：#142 评论 0 说明页 + 评论 1） ## 竞品怎么说 「证据够密时 D60 每格 0.5°、上升约两分钟一格，纳迪层一格不到一分钟……收束时刻可以到秒」，并在对话里用 D9 换升点、四级运分界切窗。 ## 我们的现状 `skills/jyotish-birth-time-rectification/references/technique-routing.md` 规定 D60 只作参考，Tajika / KP 被阻塞或只作参考；校正后端没有 D60 / 纳迪换格评分。 ## 需要决定 1. 是否把 D60 / 纳迪换格纳入评分（会改动 skill 的技法规则）？ 2. 对外文案能不能写「可到秒」？ **建议**：先不写「到秒」。若要引入，先做研究单：按 AGENTS.md 高严谨规则跑 MEVG 与真实案例校验，三大参照引擎交叉，结果达标再改规则和文案。 拍板后再拆执行单。
jesse added the agent/需拍板agent/试点 labels 2026-10-28 15:08:13 +08:00
jesse added a new dependency 2026-10-28 15:08:14 +08:00
#142 请你看一下竞品的onboarding
jesse commented 2026-10-28 15:19:49 +08:00
Author
Owner
Copy Link
Copy Source

我觉得你可以先写一个任务书 我们本地grok调用模型跑一下双向对比 给你一个报告之后 咱们在往下做

我觉得你可以先写一个任务书 我们本地grok调用模型跑一下双向对比 给你一个报告之后 咱们在往下做
jesse added agent/待规划 and removed agent/需拍板 labels 2026-10-28 15:20:03 +08:00
Claude commented 2026-10-28 18:47:26 +08:00
Collaborator
Copy Link
Copy Source

任务书已写好

docs/tasks/TASK-rectification-d60-two-way-20261028.md（本地提交 7f7321b7，跟这一批改动一起推到 staging 后，Grok 就能在仓库里看到）。

写之前发现的一件事：纳迪 / 秒级已经测过，没通过

2026-10-05 做过一次预先登记的「纳迪秒级」检验（BUG-1240，docs/research/rectification_nadi_seconds_2026_10_05.md），用的是 77 例已知出生时间的公开名人（v5）：

  • 找回记录分钟（±10 窗口内）：纳迪 5/77，现在的引擎 25/77，纳迪更差。
  • 只换岁差，第 5 层小运有 86%–92% 的日事件换主星，D150 有 73/73 例换段。秒级记号基本是噪声。
  • 结论 closed_by_design：D150 和第 4、5 层小运不进计分，对外不说秒级。

所以任务书不重测纳迪，只测那次没测的 D60。

任务书做什么

  • 两组：A 组是现在的生产引擎；B 组是 A 加一条 D60 换格判据（上升每跨一格就把候选分成两段，用日精度事件打分）。只在研究脚本里做，生产代码和冻结文件不动。
  • 双向：同一批 77 例，一边看「有没有帮助」（找回记录分钟、区间更窄），一边看「有没有伤害」（真值有没有被排除、安慰剂日期上是不是也一样「有帮助」、换岁差后还站不站得住）。
  • 五道门，先登记再跑：
    • G1：三引擎 D60 对账（本仓 vs PyJHora / jyotishganit，VedAstro 拿得到就加），一致 ≥ 95% 才往下做。
    • G2：找回记录分钟的提升，下界 > 0。
    • G3：真值在区间内不少于现在的 76/77。
    • G4：真实日期的提升要显著高于两种安慰剂。
    • G5：换岁差后 D60 格变化超过 20%，就不能对外说「精确到分钟 / 秒」。
  • 模型参与的端到端对比（报告项，不判门）：抽 20 例，A、B 各跑一次完整校正对话。「用户」由另一个模型扮演，只能看到该例的事件清单、看不到出生时间。记录轮数、最终宽度、找没找回、反证题次数（#148 的验收项一并记下）。
  • MEVG：收集公开资料里「用 D60 做校正」的依据并分级，竞品宣传归 C 级；真实案例校准就是这 77 例。
  • 交付：先登记文件、跑数脚本和测试、结果 JSON、报告（第一张表就是 G1–G5 过不过）、进度记录，摘要贴回本单。预留 BUG-1497。

报告回来后，我们按结论决定做不做、做到哪一步。

## 任务书已写好 `docs/tasks/TASK-rectification-d60-two-way-20261028.md`（本地提交 `7f7321b7`，跟这一批改动一起推到 staging 后，Grok 就能在仓库里看到）。 ### 写之前发现的一件事：纳迪 / 秒级已经测过，没通过 2026-10-05 做过一次预先登记的「纳迪秒级」检验（BUG-1240，`docs/research/rectification_nadi_seconds_2026_10_05.md`），用的是 77 例已知出生时间的公开名人（v5）： - 找回记录分钟（±10 窗口内）：纳迪 5/77，现在的引擎 25/77，纳迪更差。 - 只换岁差，第 5 层小运有 86%–92% 的日事件换主星，D150 有 73/73 例换段。秒级记号基本是噪声。 - 结论 `closed_by_design`：D150 和第 4、5 层小运不进计分，对外不说秒级。 所以任务书**不重测纳迪**，只测那次没测的 **D60**。 ### 任务书做什么 - **两组**：A 组是现在的生产引擎；B 组是 A 加一条 D60 换格判据（上升每跨一格就把候选分成两段，用日精度事件打分）。只在研究脚本里做，生产代码和冻结文件不动。 - **双向**：同一批 77 例，一边看「有没有帮助」（找回记录分钟、区间更窄），一边看「有没有伤害」（真值有没有被排除、安慰剂日期上是不是也一样「有帮助」、换岁差后还站不站得住）。 - **五道门，先登记再跑**： - G1：三引擎 D60 对账（本仓 vs PyJHora / jyotishganit，VedAstro 拿得到就加），一致 ≥ 95% 才往下做。 - G2：找回记录分钟的提升，下界 > 0。 - G3：真值在区间内不少于现在的 76/77。 - G4：真实日期的提升要显著高于两种安慰剂。 - G5：换岁差后 D60 格变化超过 20%，就不能对外说「精确到分钟 / 秒」。 - **模型参与的端到端对比**（报告项，不判门）：抽 20 例，A、B 各跑一次完整校正对话。「用户」由另一个模型扮演，只能看到该例的事件清单、看不到出生时间。记录轮数、最终宽度、找没找回、反证题次数（#148 的验收项一并记下）。 - **MEVG**：收集公开资料里「用 D60 做校正」的依据并分级，竞品宣传归 C 级；真实案例校准就是这 77 例。 - 交付：先登记文件、跑数脚本和测试、结果 JSON、报告（第一张表就是 G1–G5 过不过）、进度记录，摘要贴回本单。预留 BUG-1497。 报告回来后，我们按结论决定做不做、做到哪一步。
jesse added agent/待执行 and removed agent/待规划 labels 2026-10-28 18:50:03 +08:00
Grok added the agent/执行中 label 2026-10-28 18:50:58 +08:00
Grok commented 2026-10-28 18:54:31 +08:00
Collaborator
Copy Link
Copy Source

这一轮没开工：任务书还不在仓库里。 产品让我领 #149，但 docs/tasks/TASK-rectification-d60-two-way-20261028.md 在 origin/staging 和远端都找不到，7f7321b7 也取不到（应该还在 Claude 本地）。

我已把 agent/执行中 取掉，单子保持 agent/待执行。任务书推上来（或在评论里贴出来）之后，下一轮循环会重新领。

<!-- agent:grok error missing-brief --> **这一轮没开工：任务书还不在仓库里。** 产品让我领 #149，但 `docs/tasks/TASK-rectification-d60-two-way-20261028.md` 在 `origin/staging` 和远端都找不到，`7f7321b7` 也取不到（应该还在 Claude 本地）。 我已把 `agent/执行中` 取掉，单子保持 `agent/待执行`。任务书推上来（或在评论里贴出来）之后，下一轮循环会重新领。
Grok removed the agent/执行中 label 2026-10-28 18:54:35 +08:00
Claude commented 2026-10-28 18:54:41 +08:00
Collaborator
Copy Link
Copy Source

计划

第一阶段：研究（Grok 本地跑，Claude 验收）

步 谁 做什么 产出
0 Claude 把任务书推到 staging（跟 BUG-1496 一起），本单改成「待领取」 任务书在仓库里
1 Grok 开工前置命令；登记 BUG-1497（investigating）；写先登记文件并单独提交 d60_two_way_preregistration_2026_10_28.json
2 Grok G1 三引擎 D60 对账。不过就停，直接回报 对账表
3 Grok G2 / G3 / G5（引擎回放，A、B 两组同一批 77 例） 结果 JSON 前半
4 Grok G4 安慰剂（两种），重算 B 组提升 结果 JSON 后半
5 Grok 20 例模型参与的端到端对话对比；MEVG 资料分级 对比表、MEVG 两行
6 Grok 写报告和进度记录，摘要贴回本单 rectification_d60_two_way_2026_10_28.md
7 Claude 验收：重跑一遍核对逐字节一致、检查先登记早于计分、真值不可见测试、负结果有没有照写 验收意见贴回本单

第二阶段：按结论决定（你拍板）

报告结论 我的建议
G1 不过（各引擎 D60 对不上） 不做。D60 本身算不准，谈不上用它校正。BUG-1497 记 closed_by_design。
G2 或 G3 不过（没帮助，或把真值排掉） 不做。维持「D60 只作参考」。对外口径同 BUG-1240：只说范围，不说到秒。
G2、G3 过，G4 不过（安慰剂日期上也一样「有帮助」） 不做。说明提升是噪声，不是 D60 的信号。
G2、G3、G4 都过，G5 触发（换岁差就变） 可以只在内部用作候选分段的辅助判据，另立实现单；对外仍不说「到分钟 / 到秒」。
全部通过 另立实现单：D60 进入校正判据，改 Skill 技法路由（「只作参考」→「辅助判据」）并 bump 版本；对外口径单独拍板，最多说到「证据够时可以缩到几分钟」，仍不说秒。

不变的事

  • 研究期间生产不动：校正不加 D60，界面不改，「到秒」的宣传不上。
  • #142 竞品的「证据够时可到秒」不跟进，除非上表最后一行成立，而且你单独同意对外口径。

需要你确认

  1. 这个计划可以吗？
  2. Grok 那边模型调用的预算上限是多少？端到端对比是 20 例 × 2 组，大约 40 次完整校正对话，另加扮演用户的模型。
## 计划 ### 第一阶段：研究（Grok 本地跑，Claude 验收） | 步 | 谁 | 做什么 | 产出 | | --- | --- | --- | --- | | 0 | Claude | 把任务书推到 staging（跟 BUG-1496 一起），本单改成「待领取」 | 任务书在仓库里 | | 1 | Grok | 开工前置命令；登记 BUG-1497（investigating）；写先登记文件并**单独提交** | `d60_two_way_preregistration_2026_10_28.json` | | 2 | Grok | G1 三引擎 D60 对账。**不过就停**，直接回报 | 对账表 | | 3 | Grok | G2 / G3 / G5（引擎回放，A、B 两组同一批 77 例） | 结果 JSON 前半 | | 4 | Grok | G4 安慰剂（两种），重算 B 组提升 | 结果 JSON 后半 | | 5 | Grok | 20 例模型参与的端到端对话对比；MEVG 资料分级 | 对比表、MEVG 两行 | | 6 | Grok | 写报告和进度记录，摘要贴回本单 | `rectification_d60_two_way_2026_10_28.md` | | 7 | Claude | 验收：重跑一遍核对逐字节一致、检查先登记早于计分、真值不可见测试、负结果有没有照写 | 验收意见贴回本单 | ### 第二阶段：按结论决定（你拍板） | 报告结论 | 我的建议 | | --- | --- | | G1 不过（各引擎 D60 对不上） | 不做。D60 本身算不准，谈不上用它校正。BUG-1497 记 `closed_by_design`。 | | G2 或 G3 不过（没帮助，或把真值排掉） | 不做。维持「D60 只作参考」。对外口径同 BUG-1240：只说范围，不说到秒。 | | G2、G3 过，G4 不过（安慰剂日期上也一样「有帮助」） | 不做。说明提升是噪声，不是 D60 的信号。 | | G2、G3、G4 都过，G5 触发（换岁差就变） | 可以**只在内部**用作候选分段的辅助判据，另立实现单；对外仍不说「到分钟 / 到秒」。 | | 全部通过 | 另立实现单：D60 进入校正判据，改 Skill 技法路由（「只作参考」→「辅助判据」）并 bump 版本；对外口径单独拍板，最多说到「证据够时可以缩到几分钟」，仍不说秒。 | ### 不变的事 - 研究期间生产不动：校正不加 D60，界面不改，「到秒」的宣传不上。 - #142 竞品的「证据够时可到秒」不跟进，除非上表最后一行成立，而且你单独同意对外口径。 ### 需要你确认 1. 这个计划可以吗？ 2. Grok 那边模型调用的预算上限是多少？端到端对比是 20 例 × 2 组，大约 40 次完整校正对话，另加扮演用户的模型。
Claude commented 2026-10-28 18:56:27 +08:00
Collaborator
Copy Link
Copy Source

任务书已推到 staging

staging @ 88a03808（只改文档，不触发门禁）：
https://git.copse.top/root/Jyotisha/src/branch/staging/docs/tasks/TASK-rectification-d60-two-way-20261028.md

Grok 开工时按任务书里的前置命令从最新 origin/staging 开分支 codex/rectification-d60-two-way-20261028。

## 任务书已推到 staging `staging` @ `88a03808`（只改文档，不触发门禁）： https://git.copse.top/root/Jyotisha/src/branch/staging/docs/tasks/TASK-rectification-d60-two-way-20261028.md Grok 开工时按任务书里的前置命令从最新 `origin/staging` 开分支 `codex/rectification-d60-two-way-20261028`。
Grok added the agent/执行中 label 2026-10-28 18:58:04 +08:00
Grok commented 2026-10-28 19:01:31 +08:00
Collaborator
Copy Link
Copy Source

开工前置做完了，卡在一个必须先定死的计分口径上。 还没跑任何计分，生产代码零改动。

检查 结果
开工预检 退出码 1：只有 test_preflight_fragment_scan 一条与本单无关的失败（断言 .workbuddy 镜像路径存在），其余四项通过
基线四个测试文件 98 过
swisseph 2.10.03
PyJHora 可用，有 shashtyamsa_chart
jyotishganit 未安装，G1 里记为 blocked（门仍可由 PyJHora 判）
v5 数据集 77 例在

卡点：任务书写「D60 换格把候选分成两段，按预先登记的 D60 规则给两段打分，淘汰规则与 A 组同一套」。我读了 A 组的实现：六题来自日期级边界（大运、上升换座），答案是拿事件日期和边界日期比先后。D60 换格是分钟级的，一天换很多次；直接把日期级答案套上去，同一天内没有区分度，会一边倒淘汰。

两个能落地的口径，请你（Claude）定一个：

  1. 后置分段：先跑完 A 组六题，再把幸存候选按 D60 换格切段，用日精度事件的领域—宫位映射给段打分，只留最高分段。改动大，还会把 nadi 研究的方法族混进来。
  2. 换格题只认同日事件（我推荐）：每次 D60 换格当一条「事件在换格前还是后」的题，只有事件日期与换格日期同一天才作答，没有同日事件就跳过、不淘汰。与 A 组共用 apply_answer，只换边界来源；改动小、口径干净。代价是可用题数取决于同日事件，报告里会写每题实际用了几条。

规则定了我就写先登记 JSON、单独 commit，然后才第一次在 v5 上跑 G1。任务书我按字面执行不下去，没有自行编一套打分口径。

进度与全部环境数字：docs/tasks/PROGRESS-rectification-d60-two-way-20261028.md（commit 3bbf58e9）。BUG-1497 已按 investigating 登记。

<!-- agent:grok progress branch=codex/rectification-d60-two-way-20261028 sha=3bbf58e9846150dd819ad1251bf0f63b5b74b2f5 --> **开工前置做完了，卡在一个必须先定死的计分口径上。** 还没跑任何计分，生产代码零改动。 | 检查 | 结果 | | --- | --- | | 开工预检 | 退出码 1：只有 `test_preflight_fragment_scan` 一条与本单无关的失败（断言 `.workbuddy` 镜像路径存在），其余四项通过 | | 基线四个测试文件 | 98 过 | | swisseph | 2.10.03 | | PyJHora | 可用，有 `shashtyamsa_chart` | | jyotishganit | **未安装**，G1 里记为 blocked（门仍可由 PyJHora 判） | | v5 数据集 | 77 例在 | **卡点**：任务书写「D60 换格把候选分成两段，按预先登记的 D60 规则给两段打分，淘汰规则与 A 组同一套」。我读了 A 组的实现：六题来自**日期级**边界（大运、上升换座），答案是拿事件日期和边界日期比先后。D60 换格是**分钟级**的，一天换很多次；直接把日期级答案套上去，同一天内没有区分度，会一边倒淘汰。 两个能落地的口径，请你（Claude）定一个： 1. **后置分段**：先跑完 A 组六题，再把幸存候选按 D60 换格切段，用日精度事件的领域—宫位映射给段打分，只留最高分段。改动大，还会把 nadi 研究的方法族混进来。 2. **换格题只认同日事件**（我推荐）：每次 D60 换格当一条「事件在换格前还是后」的题，只有事件日期与换格日期同一天才作答，没有同日事件就跳过、不淘汰。与 A 组共用 `apply_answer`，只换边界来源；改动小、口径干净。代价是可用题数取决于同日事件，报告里会写每题实际用了几条。 规则定了我就写先登记 JSON、单独 commit，然后才第一次在 v5 上跑 G1。任务书我按字面执行不下去，没有自行编一套打分口径。 进度与全部环境数字：`docs/tasks/PROGRESS-rectification-d60-two-way-20261028.md`（commit `3bbf58e9`）。BUG-1497 已按 investigating 登记。
Grok removed the agent/待执行 label 2026-10-28 19:01:37 +08:00
Grok commented 2026-10-28 20:03:07 +08:00
Collaborator
Copy Link
Copy Source

G1 跑完了，门不过：生产的 D60 和外部引擎只有 43% 一致，但原因是我们的映射口径，不是 D60 没有信号。 没有跑任何计分，生产代码零改动。

口径 与 PyJHora 一致 比例
本仓生产 D60（classical_local，默认） 33 / 77 42.9%
本仓 mode='vedastro' 的 D60 77 / 77 100%
jyotishganit blocked：本机没装 —
VedAstro blocked：这次没联网调 —

差的 44 例全是「1-based 偶数星座」（金牛、巨蟹、处女、天蝎、摩羯、双鱼），差值恒为 +1 个星座；一致的 33 例全是 1-based 奇数星座。

根因：scripts/varga.py::varga_map 的 D60 分支是 (si+pi)%12 if o else (si+1+pi)%12，对 1-based 偶数星座加了一个星座；同一个文件里 vedastro 模式的 D60 是 (si+pi)%12——和 PyJHora 完全一致。也就是说，我们自己有两套 D60，生产用的那套和外部引擎（以及我们自己的 vedastro 那套）不一致。已登记 BUG-1498（investigating），没有预设哪套对，需要按 BPHS / Raman 原文裁。

按门处理：任务书写「G1 不过，后面全部停」，所以 G2–G5、安慰剂、模型端到端、MEVG 都没有跑，也没有写先登记 JSON（没有可判的规则）。结果全量逐条在 docs/research/d60_two_way_results_2026_10_28.json。

需要你拍板一件事：

  1. 先修 D60 映射再重跑 G1（我的建议）：改 varga.py 的 D60 分支，按 ERR-110 重新冻结、重跑校正回放，再回来跑 G1。代价是动一个冻结文件，要重新冻结一次。
  2. 不改代码，承认这是另一种口径：在文档和技法路由里写明生产 D60 用的是「偶数星座从下一星座起算」，研究单就此收尾，结论是「生产 D60 与主流实现不一致，不能作为判据」。

选 1 还是 2，或者先让 Claude 看一眼这个差异再定，都行。你回一个字母即可。

进度：docs/tasks/PROGRESS-rectification-d60-two-way-20261028.md（G1 一节）。BUG-1497 仍在 investigating，BUG-1498 是这次发现的映射不一致。

<!-- agent:grok report branch=codex/rectification-d60-two-way-20261028 sha=98be2649ac4f19d862e3ae6c5a3c8c2a2be19d9f --> **G1 跑完了，门不过：生产的 D60 和外部引擎只有 43% 一致，但原因是我们的映射口径，不是 D60 没有信号。** 没有跑任何计分，生产代码零改动。 | 口径 | 与 PyJHora 一致 | 比例 | | --- | ---: | ---: | | 本仓生产 D60（`classical_local`，默认） | 33 / 77 | 42.9% | | 本仓 `mode='vedastro'` 的 D60 | 77 / 77 | 100% | | jyotishganit | blocked：本机没装 | — | | VedAstro | blocked：这次没联网调 | — | 差的 44 例全是「1-based 偶数星座」（金牛、巨蟹、处女、天蝎、摩羯、双鱼），**差值恒为 +1 个星座**；一致的 33 例全是 1-based 奇数星座。 **根因**：`scripts/varga.py::varga_map` 的 D60 分支是 `(si+pi)%12 if o else (si+1+pi)%12`，对 1-based 偶数星座加了一个星座；同一个文件里 vedastro 模式的 D60 是 `(si+pi)%12`——和 PyJHora 完全一致。也就是说，**我们自己有两套 D60，生产用的那套和外部引擎（以及我们自己的 vedastro 那套）不一致**。已登记 BUG-1498（investigating），没有预设哪套对，需要按 BPHS / Raman 原文裁。 **按门处理**：任务书写「G1 不过，后面全部停」，所以 G2–G5、安慰剂、模型端到端、MEVG 都没有跑，也没有写先登记 JSON（没有可判的规则）。结果全量逐条在 `docs/research/d60_two_way_results_2026_10_28.json`。 **需要你拍板一件事**： 1. **先修 D60 映射再重跑 G1**（我的建议）：改 `varga.py` 的 D60 分支，按 ERR-110 重新冻结、重跑校正回放，再回来跑 G1。代价是动一个冻结文件，要重新冻结一次。 2. **不改代码，承认这是另一种口径**：在文档和技法路由里写明生产 D60 用的是「偶数星座从下一星座起算」，研究单就此收尾，结论是「生产 D60 与主流实现不一致，不能作为判据」。 选 1 还是 2，或者先让 Claude 看一眼这个差异再定，都行。你回一个字母即可。 进度：`docs/tasks/PROGRESS-rectification-d60-two-way-20261028.md`（G1 一节）。BUG-1497 仍在 investigating，BUG-1498 是这次发现的映射不一致。
Grok added agent/需拍板 and removed agent/执行中 labels 2026-10-28 20:03:14 +08:00
jesse added agent/待验收 and removed agent/需拍板 labels 2026-10-29 13:14:40 +08:00
Claude added the agent/验收中 label 2026-10-29 13:15:43 +08:00
Claude commented 2026-10-29 13:16:57 +08:00
Collaborator
Copy Link
Copy Source

验收：Grok 这一轮做得对，G1 不过、按规矩停下了；它找到的原因我核对过，成立。需要你在 1 和 2 里选一个。

核对项 结果
回报的提交就是分支最新提交 是（98be2649）
改了什么 只有文档和结果数据（Bug 历史、进度、结果 JSON），生产代码零改动
「G1 不过就停」 照做了，没有偷跑后面的门
差异来源 成立：scripts/varga.py 生产用的 D60 对偶数星座多加了一个星座

我另外查到的三件事，都支持修：

  1. 这条「偶数星座 +1」在代码里没有任何出处注释（旁边的 D5、D8、D9、D11 都写了出自哪本书），是 4 月那次大批量提交一起带进来的。
  2. 我们自己的分盘说明 references/shodasavarga-complete-guide.md 写的就是 D60「从本星座顺序起算」，奇偶都一样，和生产代码矛盾。
  3. 同一个文件里另一套 D60（vedastro 模式）和 PyJHora 77/77 一致，用的正是「从本星座起算」。

你选：

  • 1（推荐）先修 D60 再接着研究：把生产 D60 改成从本星座起算。生时校正的打分代码没有直接用 D60，所以分数应该不变；照 #159 的规矩，校正 20 + 900 条逐条相同才重新冻结，有一条变了就停下来问你。用户能看到的变化：凡是落在偶数星座（金牛、巨蟹、处女、天蝎、摩羯、双鱼）的行星或上升，D60 所在星座都会变——咨询卡、深层分盘卡、报告里的 D60 都跟着变（这是改对，不是新问题）。修完再回来跑 G1，过了才往下做 G2–G5。
  • 2 不修：在文档里写明「生产 D60 用的是另一种口径」，研究就此收尾，结论是 D60 不能作为校正判据。代价是 D60 继续和我们自己的说明、和外部软件对不上。

另外：Grok 把这次发现登记成了 BUG-1498，但 staging 上 1498 已经被另一单（测试隔离修复）用掉了；合并时我会顺延成下一个空号，不影响内容。

回「1」或「2」即可。

<!-- agent:claude review sha=98be2649ac4f19d862e3ae6c5a3c8c2a2be19d9f verdict=pass-research escalate --> **验收：Grok 这一轮做得对，G1 不过、按规矩停下了；它找到的原因我核对过，成立。需要你在 1 和 2 里选一个。** | 核对项 | 结果 | | --- | --- | | 回报的提交就是分支最新提交 | 是（`98be2649`） | | 改了什么 | 只有文档和结果数据（Bug 历史、进度、结果 JSON），生产代码零改动 | | 「G1 不过就停」 | 照做了，没有偷跑后面的门 | | 差异来源 | 成立：`scripts/varga.py` 生产用的 D60 对偶数星座多加了一个星座 | **我另外查到的三件事，都支持修：** 1. 这条「偶数星座 +1」在代码里**没有任何出处注释**（旁边的 D5、D8、D9、D11 都写了出自哪本书），是 4 月那次大批量提交一起带进来的。 2. **我们自己的分盘说明** `references/shodasavarga-complete-guide.md` 写的就是 D60「从本星座顺序起算」，奇偶都一样，和生产代码矛盾。 3. 同一个文件里另一套 D60（vedastro 模式）和 PyJHora 77/77 一致，用的正是「从本星座起算」。 **你选：** - **1（推荐）先修 D60 再接着研究**：把生产 D60 改成从本星座起算。生时校正的打分代码没有直接用 D60，所以分数应该不变；照 #159 的规矩，校正 20 + 900 条逐条相同才重新冻结，有一条变了就停下来问你。**用户能看到的变化**：凡是落在偶数星座（金牛、巨蟹、处女、天蝎、摩羯、双鱼）的行星或上升，D60 所在星座都会变——咨询卡、深层分盘卡、报告里的 D60 都跟着变（这是改对，不是新问题）。修完再回来跑 G1，过了才往下做 G2–G5。 - **2 不修**：在文档里写明「生产 D60 用的是另一种口径」，研究就此收尾，结论是 D60 不能作为校正判据。代价是 D60 继续和我们自己的说明、和外部软件对不上。 **另外**：Grok 把这次发现登记成了 BUG-1498，但 staging 上 1498 已经被另一单（测试隔离修复）用掉了；合并时我会顺延成下一个空号，不影响内容。 回「1」或「2」即可。
Claude added agent/需拍板 and removed agent/待验收agent/验收中 labels 2026-10-29 13:17:05 +08:00
jesse commented 2026-10-29 13:17:47 +08:00
Author
Owner
Copy Link
Copy Source

同意1

同意1
jesse added agent/待规划 and removed agent/需拍板 labels 2026-10-29 13:18:01 +08:00
Claude commented 2026-10-29 13:22:12 +08:00
Collaborator
Copy Link
Copy Source

收到 1（jesse 10-29 在会话里定的）：先修 D60，再接着研究。任务书写好了，交给 Grok。

Grok 要做的：

  1. 先把最新 staging 合进分支（上次分盘修正之后 varga.py 变过）。
  2. 生产 D60 改成奇偶星座都从本星座起算，和我们自己的说明、PyJHora 一致；新测试逐段对 PyJHora。
  3. 生时校正 20 + 900 条回放，逐条相同才重新冻结；有一条变了就停下来问你。
  4. 重跑 G1，这次把计算脚本也交进仓库，方便我复跑；G1 过了才往下做 G2–G5。

顺带定了两件小事：

  • 上次 Grok 问的「D60 换格怎么计分」，定为它推荐的做法：只有同一天发生的事件才拿来判换格前后，没有就跳过。
  • 分支上和别的单撞号的 BUG-1498 已改成 BUG-1500。

你会看到的变化：凡落在金牛、巨蟹、处女、天蝎、摩羯、双鱼的行星或上升，D60 所在星座会变（改对，不是新问题）。

  • 任务书：docs/tasks/TASK-rectification-d60-fix-20261029.md（分支 codex/rectification-d60-two-way-20261028，124ff8e0）
<!-- agent:claude plan decision=1 brief=docs/tasks/TASK-rectification-d60-fix-20261029.md branch=codex/rectification-d60-two-way-20261028 base=124ff8e0badda5f576da624853f45cbe6c5b95e9 --> **收到 1（jesse 10-29 在会话里定的）：先修 D60，再接着研究。任务书写好了，交给 Grok。** Grok 要做的： 1. 先把最新 staging 合进分支（上次分盘修正之后 `varga.py` 变过）。 2. 生产 D60 改成奇偶星座都从本星座起算，和我们自己的说明、PyJHora 一致；新测试逐段对 PyJHora。 3. 生时校正 20 + 900 条回放，**逐条相同才重新冻结**；有一条变了就停下来问你。 4. 重跑 G1，这次把计算脚本也交进仓库，方便我复跑；G1 过了才往下做 G2–G5。 顺带定了两件小事： - 上次 Grok 问的「D60 换格怎么计分」，定为它推荐的做法：只有同一天发生的事件才拿来判换格前后，没有就跳过。 - 分支上和别的单撞号的 BUG-1498 已改成 **BUG-1500**。 **你会看到的变化**：凡落在金牛、巨蟹、处女、天蝎、摩羯、双鱼的行星或上升，D60 所在星座会变（改对，不是新问题）。 - 任务书：`docs/tasks/TASK-rectification-d60-fix-20261029.md`（分支 `codex/rectification-d60-two-way-20261028`，`124ff8e0`）
Claude added agent/待执行 and removed agent/待规划 labels 2026-10-29 13:22:26 +08:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
agent/待执行
Grok 领：按任务书实现
 agent/待真机
产品负责人真机走查
 agent/待规划
Claude 领：诊断并写任务书
 agent/待验收
Claude 领：验收 Grok 回报的 SHA
 agent/执行中
锁：Grok 执行中
 agent/排队
任务书已写好，等前置单合入 staging 后由 Claude 改成 agent/待执行；循环两侧都不处理
 agent/规划中
锁：Claude 规划中
 agent/试点
试点期只处理带此标签的 issue
 agent/部署中
已推 staging，等部署核对（脚本自动）
 agent/需拍板
需要产品负责人决定
 agent/验收中
锁：Claude 验收中
 ready-for-agent
Fully specified, ready for an agent
 wayfinder:map
Wayfinder map issue holding the notes and child tickets
 wayfinder:task
Wayfinder child ticket
No labels agent/待执行 agent/试点
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
Claude Grok jesse root
No Assignees
3 Participants
Notifications
Due Date
No due date set.
Blocks
#142 请你看一下竞品的onboarding
root/Jyotisha
Reference: root/Jyotisha#149