Compare commits
| Author | SHA1 | Date | |
|---|---|---|---|
 jesse-uxandGrok (agent loop)
|
6dd1ff7d0c | ||
|
jesse-uxandGrok (agent loop)
|
aae3fea011 | ||
|
jesse-uxandGrok (agent loop)
|
4cdb997800 | ||
|
jesse-uxandGrok (agent loop)
|
2748e43871 | ||
|
jesse-uxandGrok (agent loop)
|
d32ad7b7b1 | ||
|
Jesse_ChenandClaude Opus 5.5
|
99ef1bbd12 | ||
|
Claude
|
77057a819b | ||
|
Claude
|
9fca54eacb | ||
|
jesse-uxandGrok (agent loop)
|
bccceff91f | ||
|
Jesse_ChenandClaude Opus 5.5
|
0c04755560 |
@@ -1,5 +1,18 @@
|
||||
# 印度占星 Skill 更新日志
|
||||
|
||||
## 2026-10-14 — 婚恋评级改成证据档位，KP 判宫和大运年长对齐（待合入 staging）
|
||||
|
||||
- 婚恋结构指数不再写成婚姻稳定、离婚、再婚或建议婚前咨询。中文报告用中文档位，英文报告用英文档位。配偶星分数按 0 到 1 显示，不再写成百分制。
|
||||
- KP 按宫头到下一宫头判宫，报告写明口径。本命宫位表的判宫不变。
|
||||
- 接口里兜底大运的一年改成和推运脚本一样的 365.25 天。
|
||||
- 星历路径只核查，没改。Skill 版本不变（BUG-1318～1321；BUG-1322 仍在核查）。
|
||||
|
||||
## 2026-10-13 — 明说要做生时校正时，第一步就能打开（待合入 staging）
|
||||
|
||||
- 新对话第一句就说「帮我做生时校正 / 生时纠正 / 核对出生时间」，会直接打开校正，只留一句过渡，不先写一段解读。
|
||||
- 问事业、感情这类普通问题，仍是先排盘再回答。只是觉得解读不准，仍是认下来改着读，不会被拉去做校正。
|
||||
- Skill 版本不变（BUG-1317，是 BUG-1306 的复发）。
|
||||
|
||||
## 2026-10-13 — 报告开头的「重点」改成一张摘要卡（待合入 staging）
|
||||
|
||||
- 新生成的个人报告，标题比正文大，下面一行小字是名字和生成日期。没有名字只写日期；标题里已经有名字就不重复。
|
||||
|
||||
@@ -17556,6 +17556,7 @@
|
||||
- 防复发：`frontend/tests/rectification-explicit-entry-20261012.test.ts` 锁住直达、同一轮不重复开案、无 caseId 的 opened 绑定与找回、四种拒绝说明、两条路径不重试、普通咨询仍重试一次、规则只定义一处、申报时段「在哪一段附近」、结算调用 `complete_consultation_free`。F3 另锁：结算记录是 `offered` 且 `autoOpen: true`、卡片在绑定前不说「已经开始」、绑定后才说已经开始、打开失败仍是 `offered`、旧的 `offered` / `opened` / `returned` 照常解析且 `returned` 不出卡。用户可见句长度 ≤20。真机清单 `docs/testing/rectification-explicit-entry-20261012.md`。
|
||||
- 相关记录：BUG-1247、BUG-1248（入口改为提议卡）、BUG-976/977（禁正则判意图）。
|
||||
- 复发自：无。
|
||||
- 复发：BUG-1317（2026-10-13。直达已部署，但第 0 步仍只有排盘工具，模型排完盘后没有带 explicitRequest 打开校正）。
|
||||
- 修复版本：staging `b8bdc003`（实现 `6a799582` 变基到 `9f1e8257`，代码逐字节相同；2026-10-12 Claude 验收通过、产品要求合入；部署核对：health gitCommit=b8bdc003、`requiredMigrationsPresent` true，`/login` 200，未登录 `/api/account` 401）。跟进项 F3（打开失败卡片仍说已开始）见 `TASK-rectification-1012-batch-fix-20261012`。 F3 跟进（`51a77721`）已部署 staging `586561eb`（2026-10-12 核对：health gitCommit / apiGitCommit=586561eb、`requiredMigrationsPresent` true，`/login` 200，未登录 `/api/account` 401；合并后 npm test 5025 条、失败 24 逐名同 `798e15ef` 基线）。
|
||||
- 决策日志（2026-10-12，产品）：选 A——用户明确要求做生时校正时直接进入校正，不先写解读、不用点卡；意图由模型判断，禁正则 / 关键词。**推翻 BUG-1248 两处**：①明确要求的这一轮不再「只出卡、点卡才进」；②`product_disabled`、`pricing_unavailable`「正文不要提校正」改为必须一句话说明做不了，不得静默。普通对话模型不得承诺收窄出生时间、不得在对话里收集经历假装校正；申报时段下不得写大运 / 子运精确起止。服务端本人 / 开关 / 进行中 case / 价格判定不变。同日另立 BUG-1307（最近分界开场）、BUG-1308（父母静态题研究）。
|
||||
|
||||
@@ -17703,3 +17704,94 @@
|
||||
- 复发自：无。
|
||||
- 修复版本：分支 `codex/report-focus-card-20261013`，尚未合入 staging。
|
||||
|
||||
## BUG-1317 | 明说要做生时校正时，仍先排完盘再写解读，校正没打开
|
||||
|
||||
- 状态：fixed-pending-verify（真机清单未走，没有模型凭据，不标 resolved）
|
||||
- 首次发现 / 最近更新：2026-10-13 / 2026-10-13
|
||||
- 来源：issue #54。staging 首页普通对话第一句说要生时纠正，回答先显示排盘完成，再写校正开不了、走另一个入口。
|
||||
- 现象：没有打开校正。正文是模型自己写的解读，不是那句固定过渡。
|
||||
- 触发条件：新对话第一句明确要做校正。普通问题、以及只是觉得解读不准，不在这条里。
|
||||
- 根因：第 0 步只给排盘工具（BUG-923）。模型必须先排完盘，才看得到校正工具。规则里「明确要校正就打开」夹在禁止句中间，「纠正」又和「用户纠正解读」撞了。BUG-1306 的测试直接调用工具，没有让真实模型选工具；真机清单因没有模型钥匙没跑过。
|
||||
- 决策：产品选 B。第 0 步在校正工具确实挂上时，可以排盘，也可以打开校正。`toolChoice` 仍是 auto。两个都没按就写答案时，仍走原来的「运行合同不完整」重试，逼它先排盘。不加关键词判断。
|
||||
- 修复：本命和申报时段的第 0 步，在挂了校正工具时多放这一个工具。还没看盘就顺口提议，不算已经提议过，先去排盘。明确要求则第一步就打开，不先写解读。规则第一句改成「校正就在这个对话里能开」，并把「纠正规则」改称「改读规则」。`FOLLOW_UP_CORRECTION_RULE` 本身没改。没挂校正工具时，第 0 步仍只有排盘工具。
|
||||
- 验证：见 `docs/tasks/PROGRESS-rectification-step0-entry-20261013.md`。规则原 374 字，新 416 字，增加 42，不超过 80。
|
||||
- 防复发：第 0 步断言锁住「没挂只有排盘、挂了是两个工具」。另有三条：第一步明确要求不排盘且正文是固定过渡；一步都不按会重试到排盘后的回答；没看盘的顺口提议不占额度。
|
||||
- 相关记录：BUG-1306、BUG-923、BUG-937、BUG-922。
|
||||
- 复发自：BUG-1306。
|
||||
- 修复版本：分支 `codex/rectification-step0-entry-20261013`，尚未合入 staging。
|
||||
|
||||
## BUG-1318 | 婚恋评级仍写成稳定或婚前咨询，配偶星分数被写成百分制
|
||||
|
||||
- 状态：fixed-pending-verify
|
||||
- 首次发现 / 最近更新：2026-10-14 / 2026-10-14
|
||||
- 来源：issue #56。上游 `f891a2c1`。任务书 `docs/tasks/TASK-upstream-sync7-20261014.md` T1。
|
||||
- 现象：D9 综合评级仍写「婚姻稳定」「强烈建议婚前咨询」。这份文字进全读导出包，模型能读到。配偶星证据行把 0 到 1 的指数写成「婚姻质量 x/100」。
|
||||
- 触发条件：算出婚恋几何指数，或关系时机证据带出配偶星。
|
||||
- 根因：同步第六轮按标题筛提交时，漏了 10-02 到 10-03 的这条措辞修正。分数行把 0 到 1 当成了百分制。
|
||||
- 修复：五档改成证据档位，并写明这是结构指数，不预测婚姻次数、稳定、离婚、伴侣好坏，也不提示婚前咨询。中文报告用中文档位，英文报告用英文档位。证据行改成「婚姻质量指数 x（0到1）」，不乘 100。
|
||||
- 验证：`tests/test_d9_evidence_bands.py` 3 通过。公开盘中英文各一条快照。配偶星行不再出现 `/100`。
|
||||
- 防复发：五档文字不得含「稳定、离婚、再婚、婚前咨询、几段」；快照锁住公开盘的两句。
|
||||
- 相关记录：BUG-1183。
|
||||
- 复发自：无。
|
||||
- 修复版本：分支 `codex/upstream-sync7-20261014`，尚未合入 staging。
|
||||
|
||||
## BUG-1319 | KP 落宫沿用本命中点判宫，传了宫头也不声明口径
|
||||
|
||||
- 状态：fixed-pending-verify
|
||||
- 首次发现 / 最近更新：2026-10-14 / 2026-10-14
|
||||
- 来源：issue #56。上游 `0337b77f`。任务书 T2。
|
||||
- 现象：KP 用的行星落宫和本命 Bhava Chalit 表一样，按相邻宫头的中点判宫。宫头传进 KP 分析时，结果不写明判宫口径。
|
||||
- 触发条件：打开 KP。本命 Bhava Chalit 表不走这条。
|
||||
- 根因：同步第六轮漏了夹在上游隐私提交里的判宫修正。本命表和 KP 共用了中点函数。
|
||||
- 修复：KP 改成宫头到下一宫头。本命表默认仍是中点，宫位数字不变。传了宫头却不声明口径就拒绝；没传宫头记整宫代理。KP 报告写出判宫口径。
|
||||
- 验证：`tests/test_kp_cusp_house_assignment.py` 3 通过。同一颗星在两种口径下落入不同宫；默认中点与改前一致。
|
||||
- 防复发：未知口径直接报错；报告正文必须出现 House occupancy basis。
|
||||
- 相关记录：BUG-1318。
|
||||
- 复发自：无。
|
||||
- 修复版本：分支 `codex/upstream-sync7-20261014`，尚未合入 staging。
|
||||
|
||||
## BUG-1320 | 瑜伽角宫主和三方主的顺序随进程哈希变化
|
||||
|
||||
- 状态：fixed-pending-verify
|
||||
- 首次发现 / 最近更新：2026-10-14 / 2026-10-14
|
||||
- 来源：issue #56。上游 `0337b77f`。任务书 T3。
|
||||
- 现象：同一张盘的角宫主、三方主列表用了集合去重。集合顺序会跟着进程哈希变，瑜伽参与者顺序不稳定。
|
||||
- 触发条件：规则表达式读取这两份宫主列表。
|
||||
- 根因：去重用了不保证顺序的集合。同步第六轮漏了上游把它们改成排序的那一处。
|
||||
- 修复：两处都改成先去重再按名字排序。
|
||||
- 验证：`tests/test_yoga_lord_order_stable.py` 1 通过。哈希种子 0 和 1 两个进程算出的参与者顺序相同。
|
||||
- 防复发：两个子进程的名单必须逐项相同，并且等于排好序的名单。
|
||||
- 相关记录：BUG-1319。
|
||||
- 复发自：无。
|
||||
- 修复版本：分支 `codex/upstream-sync7-20261014`，尚未合入 staging。
|
||||
|
||||
## BUG-1321 | 接口里的大运年长和推运脚本差了一点，起止会对不齐
|
||||
|
||||
- 状态：fixed-pending-verify
|
||||
- 首次发现 / 最近更新：2026-10-14 / 2026-10-14
|
||||
- 来源：issue #56。上游 `4d543209`。任务书 T4。
|
||||
- 现象：接口的兜底大运和「进入本运几年」用 365.25636 天为一年。同一条时间线的推运脚本用 365.25 天。年限一长，日期会差一天。
|
||||
- 触发条件：走兜底大运时间线，或计算进入当前大运的年数。
|
||||
- 根因：两处常量没有跟着推运脚本改。同步第六轮漏了上游 10-03 的这一处。
|
||||
- 修复：这两处改成 365.25，与推运脚本相同。其它大运系统的年长不动。
|
||||
- 验证：`tests/test_dasha_year_length_alignment.py` 2 通过。同一大运起止相差 0 天。158 年的旧常量会落到下一天，新常量不会。
|
||||
- 防复发：兜底时间线必须和推运脚本的起止是同一天；进入本运的年数按 365.25 除。
|
||||
- 相关记录：BUG-1320。
|
||||
- 复发自：无。
|
||||
- 修复版本：分支 `codex/upstream-sync7-20261014`，尚未合入 staging。
|
||||
|
||||
## BUG-1322 | 星历路径被设成空字符串后，计算退回低精度星历
|
||||
|
||||
- 状态：investigating
|
||||
- 首次发现 / 最近更新：2026-10-14 / 2026-10-14
|
||||
- 来源：issue #56。上游 `e1909724` 点出的同类问题。任务书 T5，本轮只核查、不改代码。
|
||||
- 现象：排盘和过境入口都把星历路径设成空字符串。本机随后计算太阳位置时，返回标记含低精度星历位，不含星历文件位。
|
||||
- 触发条件：调用排盘或过境计算。本轮没有改这条路径。
|
||||
- 根因：尚未在生产镜像里核实。本机仓库里的星历文件只在参考资料目录，不在计算进程会去找的路径上。空路径是进程全局的，后一次调用会盖掉前面设过的路径。
|
||||
- 修复：未改。建议另开一单：镜像里放一份星历文件，路径显式设上，并断言返回标记不再是低精度星历。
|
||||
- 验证：本机一次探针。生产镜像未打开，不能当作已确认。
|
||||
- 防复发：未做。等修复单再加断言。
|
||||
- 相关记录：BUG-1321。
|
||||
- 复发自：无。
|
||||
- 修复版本：未修复。
|
||||
|
||||
|
||||
@@ -0,0 +1,32 @@
|
||||
# 进度 · 明说要校正时第一步就能打开（2026-10-13）
|
||||
|
||||
- 分支：`codex/rectification-step0-entry-20261013`
|
||||
- 任务书：`docs/tasks/TASK-rectification-step0-entry-20261013.md`
|
||||
- 基线：`origin/staging` `0c04755560f0b6a772116130392b56eb2b40ae0e`（任务书写的 `963276ca2` 的后代，也是计划里的 base）
|
||||
- issue：#54，BUG-1317，复发自 BUG-1306
|
||||
|
||||
## 做了什么
|
||||
|
||||
1. 本命和申报时段的第 0 步，在校正工具挂上时可以排盘，也可以打开校正。没挂时仍只有排盘。选择仍是自动，没有改成必须调用某个工具。
|
||||
2. 还没看盘就顺口提议，不算已经提议过，先去排盘。这一轮明确要校正，第一步就打开，正文换成那句过渡。
|
||||
3. 规则第一句改成校正就在这个对话里能开，并写明校正、纠正、核对出生时间都算。不认同解读改称「改读规则」，避免和「生时纠正」撞词。
|
||||
4. 规则字数：原 374，新 416，增加 42，上限是加 80。
|
||||
|
||||
## 检查
|
||||
|
||||
| 检查 | 命令 | 结果 |
|
||||
| --- | --- | --- |
|
||||
| 定向测试 | `node node_modules/tsx/dist/cli.mjs --test` 五个相关测试文件 | 149 通过，0 失败，0 取消。类型收窄改完后，入口测试文件再跑 19 通过，0 失败，0 取消 |
|
||||
| 类型检查 | `frontend\node_modules\.bin\tsc --noEmit -p frontend` | 通过，退出码 0。第一次在测试里把「还没提议」收成永远是空，已改成先记在局部再断言 |
|
||||
| 前端 lint | `npm run lint --prefix frontend` | 退出码 0，0 error，125 条原有 warning，没有顺手改 |
|
||||
| 隐私标记 | `.venv\Scripts\python -m pytest tests/test_repo_privacy_markers.py -q` | 通过，退出码 0 |
|
||||
| 名人生平回测 | 未跑 | 本机没有模型钥匙 |
|
||||
| 数据库 | 未跑 | 不改表 |
|
||||
|
||||
## 偏离
|
||||
|
||||
- 没有。真机清单补在原来的 `docs/testing/rectification-explicit-entry-20261012.md`（第 1b 步和第 9 步），没有另写一份。
|
||||
|
||||
## 环境缺口
|
||||
|
||||
- 真实模型会不会在第一步打开校正，以及名人生平回测，都没有模型凭据，不能写成通过。部署后按真机清单，用 deepseek-v4-flash 和默认模型各走一遍。
|
||||
@@ -0,0 +1,41 @@
|
||||
# PROGRESS · 上游同步第七轮（2026-10-14）
|
||||
|
||||
- 分支：`codex/upstream-sync7-20261014`
|
||||
- 基线：任务书写的是 `77057a81`。开工时 `origin/staging` 已到 `99ef1bbd`，本分支从这里建。
|
||||
- 结论：T1 到 T4 已做完并推这个分支。T5 只核查，代码没改。星历在这台电脑上会退回低精度，生产镜像没打开，记 BUG-1322，状态是核查中。
|
||||
|
||||
## 做了什么
|
||||
|
||||
| 项 | 结果 |
|
||||
| --- | --- |
|
||||
| T1 婚恋断语 | 五档改成证据档位，中文给中文报告，英文给英文报告。写明不预测婚姻次数、稳定、离婚、伴侣好坏，也不提示婚前咨询。配偶星那一行改成 0 到 1 的指数，不再写 `/100`。BUG-1318，上游 `f891a2c1`。 |
|
||||
| T2 KP 判宫 | KP 按宫头到下一宫头。本命宫位表仍按中点，默认宫位不变。传了宫头却不说口径就拒绝；没传记整宫代理。报告多一行判宫口径。BUG-1319，上游 `0337b77f`。 |
|
||||
| T3 瑜伽排序 | 角宫主、三方主先去重再按名字排序。BUG-1320，上游 `0337b77f`。 |
|
||||
| T4 大运年长 | 接口里两处 365.25636 改成 365.25，和推运脚本同一天。别的大运系统没动。BUG-1321，上游 `4d543209`。 |
|
||||
| T5 星历 | 见下。不改代码。BUG-1322，核查中。 |
|
||||
|
||||
## 检查
|
||||
|
||||
| 检查 | 命令 | 结果 |
|
||||
| --- | --- | --- |
|
||||
| 婚恋档位 | `pytest tests/test_d9_evidence_bands.py` | 3 通过 |
|
||||
| KP 判宫 | `pytest tests/test_kp_cusp_house_assignment.py` | 3 通过 |
|
||||
| 本命宫位表 | `pytest tests/test_bhava_chalit.py` | 通过（与上面一批共 20 通过、0 失败） |
|
||||
| 几何指数旧测试 | `pytest tests/test_marriage_counting_geometry_only.py` | 通过（同上） |
|
||||
| 瑜伽顺序 | `pytest tests/test_yoga_lord_order_stable.py` | 1 通过 |
|
||||
| 大运年长 | `pytest tests/test_dasha_year_length_alignment.py` | 2 通过 |
|
||||
| 接口增长合同 | `pytest tests/test_api_server_growth_contract.py` | 通过 |
|
||||
| KP 报告标题回归 | `pytest tests/test_report_longform_parity.py` 里 KP 那一条 | 通过 |
|
||||
| 快速门、前端全量 | 未跑 | 按执行分工，留给验收方 |
|
||||
| 数据库 | 未跑 | 没动表 |
|
||||
|
||||
## T5 星历核查
|
||||
|
||||
本机把路径设成空字符串后，算太阳位置的返回标记带低精度星历，不带星历文件。仓库里的星历文件在参考资料目录，计算时用不到。排盘和过境两处都设成同一个空路径，所以这两处彼此一致，但都会退回低精度。路径是整个进程共用的，谁后设谁生效。
|
||||
|
||||
生产镜像这台电脑打不开，不能说线上也是这样。健康检查只看星历库能不能导入，看不出用的是哪一套。建议另开一单再改。
|
||||
|
||||
## 偏离
|
||||
|
||||
- 关系时机里还有一处用 65 和 45 去比这个 0 到 1 的指数。任务书只允许改配偶星那一行文字，所以没动。它现在加不上那一档分数。建议另开小单。
|
||||
- 生时校正打分文件没有改。
|
||||
@@ -211,6 +211,7 @@
|
||||
|
||||
| 任务书 | 进度 | 主题 | 状态 | 落点 |
|
||||
| --- | --- | --- | --- | --- |
|
||||
| `TASK-rectification-step0-entry-20261013.md` | — | **明说要校正时第一步就能打开（agent 循环 issue #54，BUG-1306 复发）**：第 0 步只放排盘工具、规则正向句埋在禁止句里、「纠正」撞词，模型没带 explicitRequest 调工具（BUG-1317）。产品选 B：第 0 步放出校正工具 + 规则重排；推翻 BUG-923 第 0 步限制，保险用现有 runtime-contract-retry。执行方 Grok | 待领取 | `codex/rectification-step0-entry-20261013` |
|
||||
| `TASK-report-focus-card-20261013.md` | — | **报告开篇「重点」做成摘要卡（agent 循环 issue #55）**：10-08 加的开篇重点从未设计——三重「重点」、标题无样式、MD/AD/PD 行话、数据句堆砌（BUG-1316）。产品选 A 摘要卡 + 名字与日期 + 保留提醒句；引擎出 `jyotish-focus` 围栏，前端一个组件渲染。执行方 Grok | 待领取 | `codex/report-focus-card-20261013` |
|
||||
| `TASK-report-translation-gaps-20261013.md` | — | **个人报告中英混杂、正文图盘空白、上升行、同位列（agent 循环 issue #53）**：中文完整数据版靠短词替换英文，正文残留 218 处英文词与 14 处中英粘连，卫生检查只有黑名单（BUG-1312）；完整数据版图盘节只有空标题、无围栏，BUG-1203 的回归（BUG-1313）；报告本命表无上升行（BUG-1314）；D9 同位列「—」读如没数据，改「是/否」（BUG-1315）。分盘核对段随 T1 自动消失。执行方 Grok | 待领取 | `codex/report-translation-gaps-20261013` |
|
||||
| `TASK-report-translation-gaps-fix-20261013.md` | — | **#53 第 1 次打回**：`a295afa4` 实现四项都验过，但分支未基于最新 staging，且全量 pytest 新增 1 条失败（报告 Jaimini 星位名改成「灵魂星（AK）」后 `test_chara_karaka_8_bphs_order` 未跟改）。要求 rebase + 按三栏改测试，不改 `KARAKA_CN` | 待领取 | `codex/report-translation-gaps-20261013` |
|
||||
@@ -330,6 +331,7 @@
|
||||
| `TASK-rectification-probe-supply-research-20260913.md` | — | 研究单：六题后引擎在剩余候选上再出带年月题的四种放宽规则，20 例公开 AA 数据离线量收益，有收益才立实现单 | 已合入（离线测量，不改线上） | `b063c668` |
|
||||
| `TASK-rectification-refresh-r3-r4-20260913.md` | `PROGRESS-rectification-refresh-r3-r4-20260913.md` | 刷新阶段 R3（MIN_BOUNDARY_DAYS 45→30）+ R4（pratyantar 与 D9/D10 上升 Narayana）；首轮出题不变。即使放宽仍有 0 题例子，定向补事另线保留（BUG-664/665） | 已实现 `ab1ade59`，已部署；2026-09-13 验收通过（实现单由执行方自拟，无产品决策记录段；收益口径见研究文档） | `codex/rectification-refresh-r3-r4-20260913` |
|
||||
| `TASK-upstream-sync6-20261007.md` | [PROGRESS-upstream-sync6-20261007.md](PROGRESS-upstream-sync6-20261007.md) | **上游同步第六轮（`23be1807`）**：10-05 五个计算修正一行未合——D5/D6/D8/D11 映射（乔布斯盘四张分盘星座全不同）、Vimsopaka 权重、Yogini 顺序与出生余额、Panchadhikari 宫位参照、Narayana 并列、特殊上升、出生秒数、Neecha Bhanga 两条件、首段大运子运、岁差被覆盖；逐项对照原书核实；最先做 | 已验收（门禁补修 `2df6ee72`，已部署 staging） | [PROGRESS-upstream-sync6-20261007.md](PROGRESS-upstream-sync6-20261007.md) |
|
||||
| `TASK-upstream-sync7-20261014.md` | [PROGRESS-upstream-sync7-20261014.md](PROGRESS-upstream-sync7-20261014.md) | **上游同步第七轮（BUG-1318 起）**：婚恋评级断语改证据档位、DK「婚姻质量 X/100」改对；KP 宫头到宫头判宫；瑜伽宫主排序去重；api_server 大运年长 365.25；星历路径只核查。不动校正打分。Grok 执行（agent 循环） | 待验收 | `codex/upstream-sync7-20261014`（BUG-1318～1321 已改；BUG-1322 星历路径核查中，未改代码） |
|
||||
| `TASK-special-lagnas-native-20261008.md` | `PROGRESS-special-lagnas-native-20261008.md` | **特殊上升点原生计算（线上缺陷）**：sync6 U6 运行时调 PyJHora，生产镜像没有 PyJHora → staging 上 Hora/Ghati/Sree/Indu/Pranapada 全 blocked；原生实现、PyJHora 只作冻结对照、快速门禁止运行时 import jhora；最先做 | 已验收（已部署 staging `795b8845`，BUG-1273） | `codex/special-lagnas-native-20261008`（未上线；部署以 `/api/health` 为准） |
|
||||
| `TASK-ephemeris-nutation-20261008.md` | `PROGRESS-ephemeris-nutation-20261008.md` | **恒星黄道少扣章动（BUG-1275）**：行星 = 含章动热带视位置 − 平岁差，全体偏 Δψ（≤17″），大运日期差 2–3 天；改标准算法、PyJHora 冻结对照、scoring-12、v5 重跑 | 已验收（已部署 staging `db0134f9`，BUG-1275） | `codex/ephemeris-nutation-20261008`（未推送，未部署） |
|
||||
| `TASK-sync6-gate-red-20261007.md` | — | **sync6 后门禁仍红**：run 3213 快速门已过，「Frontend and database tests」开跑 20 秒后日志中断、15 分钟后判失败，后续步骤 failure 0 秒；疑运行机掉线；先 Re-run，红则本机带 Docker 跑 `CI=1 npm test` 对照 `0ed45a4b` | 已完成（Re-run 通过，BUG-1271，部署 `2df6ee72`） | — |
|
||||
|
||||
@@ -0,0 +1,97 @@
|
||||
# TASK · 明说要校正时第一步就能打开（issue #54，BUG-1306 复发）
|
||||
|
||||
- 日期：2026-10-13
|
||||
- 来源：Gitea issue #54（agent 循环试点），产品负责人在 staging 首页普通对话（deepseek-v4-flash）第一句说「请你帮我生时纠正」，回答「已完成 3 步、本轮技法 43 项」后写「生时校正这次我这边开不了，它走的是另一个入口……」，没有打开校正
|
||||
- 执行方：**Grok（Windows + Docker）**，分支 `codex/rectification-step0-entry-20261013`，只推这个分支
|
||||
- 验收：Claude（Linux）
|
||||
- BUG 编号：**BUG-1317**（BUG-1316 已预留给 issue #55；开工时核对 `docs/BUG_HISTORY.md` 最大号）。BUG-1317 标「复发自 BUG-1306」，并在 BUG-1306 记录里补一行指向它
|
||||
|
||||
## 1. 基线
|
||||
|
||||
- 基线 commit：`origin/staging` `963276ca2`
|
||||
- `git log 586561eb..origin/staging -- frontend/src/mastra frontend/src/lib/consultation-thinking-plan.ts frontend/src/lib/rectification-in-chat*.ts frontend/src/lib/stream-agent-response.ts frontend/src/app/api/consult frontend/src/hooks/use-consultation-run.ts` 为空：BUG-1306 部署后这条链没人动过，**不是代码回归**。
|
||||
|
||||
## 2. 事故实证
|
||||
|
||||
- 产品负责人这一步就是 `docs/testing/rectification-explicit-entry-20261012.md` 第 1 步（「请你帮我进行生时纠正」），未通过。该清单（BUG-1306 的 T5）因无模型凭据从未跑过（`BLOCKED.md`「TASK-rectification-explicit-entry-20261012：T0 日志、T5 模型」）。
|
||||
- 用户看到的是模型自由写的整段解读。而工具只要收到 `explicitRequest=true`，不论放行还是拒绝，服务端都会用固定句覆盖模型正文（`frontend/src/lib/rectification-in-chat.ts` 的 `RECTIFICATION_DIRECT_*_COPY`，`frontend/src/lib/stream-agent-response.ts::rectificationDirectRunCompleted`）。所以**模型没有带 `explicitRequest=true` 调用 `offer-birth-time-rectification`**，这是代码可证的，不是推测。
|
||||
- 「另一个入口」「开不了」在提示词、skill、`frontend/src` 里都搜不到，是模型自己编的；「我也不会先用一两件事去反推一个更窄的时间」是在复述规则里的禁止句。
|
||||
|
||||
BUG-1306 的防复发措施逐条核对仍在：唯一规则 `RECTIFICATION_OFFER_RULE`（`frontend/src/lib/consultation-thinking-plan.ts`）注入首轮、追问轮与时段路线；`createRectificationOfferTool` 与 `finishExplicitRectificationRequest`（`frontend/src/mastra/consultation-tools.ts`）；`decideRectificationOfferWith`（`rectification-in-chat.ts`）；`contractReady()` 对 `rectificationDirectEntry` 放行（`stream-agent-response.ts`）；浏览器自动打开（`frontend/src/hooks/use-consultation-run.ts`）。
|
||||
|
||||
## 3. 根因
|
||||
|
||||
1. **第 0 步只给排盘工具。** `consultationNatalPrepareStep` / `consultationWindowPrepareStep`（`consultation-tools.ts`）在 `stepNumber === 0` 时 `activeTools` 只有排盘工具（BUG-923 定、BUG-937 改 `auto`）。模型必须先排完整盘（43 项），此时已进入解盘状态，才轮到它考虑校正工具。
|
||||
2. **规则正向句埋在禁止句中间。** `RECTIFICATION_OFFER_RULE` 以「用户说你推得不准时」开头，「明确要做校正就调用…explicitRequest=true」夹在「不承诺能收窄」「不在对话里收集经历」之间；模型照禁止句执行。
|
||||
3. **「纠正」撞词。** 同一规则写「按纠正规则认下、改读」，`FOLLOW_UP_CORRECTION_RULE` 讲的是用户「纠正」解读；用户说「生时纠正」被归到「读法问题、不提校正」那一支。
|
||||
4. **没告诉模型校正就在本对话里可开。**
|
||||
5. **为什么没拦住：** `frontend/tests/rectification-explicit-entry-20261012.test.ts` 直接 `tool.execute({explicitRequest:true})` 并用正则查规则文本；「真实模型是否选择调用」只能靠 T5，而 T5 一直是环境缺口。
|
||||
|
||||
## 4. 决策记录
|
||||
|
||||
- 产品负责人 2026-10-13 在 issue #54 选 **B：改规则 + 第 0 步可调用校正工具**（备选 A 只改规则、C 每个新对话加一次小模型意图判断均未选）。
|
||||
- **推翻 BUG-923「第 0 步只放排盘工具」**：第 0 步 `activeTools` 为「排盘工具 + `offer-birth-time-rectification`」（仅当本轮 `ctx.rectificationOffer` 存在，即该工具确实挂上时）。`toolChoice` 仍为 `"auto"`（BUG-282 / BUG-937 不变）。
|
||||
- 保险沿用现有机制，不另造：第 0 步模型既没排盘、也没走直接进入时，`contractReady()` 为假，`stream-agent-response.ts` 已有的 `runtime-contract-retry` 会重试，仍不就绪则按现有降级 / 失败处理。BUG-922 / 923 的「不看盘就写答案」不得因此复发。
|
||||
- 不加关键词 / 正则分类器（BUG-976/977、BUG-1247 的既有决定不变）。
|
||||
- 产品负责人已确认：普通问题（「看看事业」）仍先排盘再解读；「你说得不准」仍是认下改读、不主动拉去校正。
|
||||
|
||||
## 5. 硬红线
|
||||
|
||||
1. 不写任何按关键词判断意图的代码（含正则、词表匹配进入校正）。规则里列举「校正 / 纠正 / 核对出生时间」等说法只作为给模型的说明。
|
||||
2. `toolChoice` 不得改成 `required` 或指名工具（BUG-282 / BUG-937）。
|
||||
3. 第 0 步不得放出排盘与校正之外的工具；第 1 步起不变。
|
||||
4. 不改 `decideRectificationOfferWith` 的资格判断（本人 / 产品开关 / 进行中的校正 / 价格）、不改固定句文案、不改计费。
|
||||
5. 规则只在 `RECTIFICATION_OFFER_RULE` 一处定义（BUG-1248 / 1306），工具描述不复述规则。
|
||||
6. 不改数据库结构；不碰 `frontend/src/app/(app)/page.tsx`；不改 `.gitea/**`。
|
||||
7. 改既有断言按 §7.3 写「原值 / 新值 / 原因」三栏。开工先 grep：`grep -rn "consultationNatalPrepareStep\|consultationWindowPrepareStep\|RECTIFICATION_OFFER_RULE\|纠正规则\|activeTools" frontend/tests tests`（已知：`frontend/tests/consultation-agentic-runtime.test.ts` 「natal first step exposes only the chart calculation tool」与 window 对应用例、`frontend/tests/consult-single-pass-answer-20260927.test.ts`、`frontend/tests/rectification-explicit-entry-20261012.test.ts`）。
|
||||
8. 改了普通对话提示词：按 AGENTS.md §10 需要名人生平回测，本轮无模型凭据，写成环境缺口（见 §10），不得写成通过。
|
||||
|
||||
## 6. 任务分解
|
||||
|
||||
### T1 · 第 0 步放出校正工具
|
||||
|
||||
- `consultationNatalPrepareStep` / `consultationWindowPrepareStep` 改为能知道本轮是否挂了校正工具（例如改成工厂 `consultationNatalPrepareStepFor({ rectificationOffer: boolean })`，或在 `route.ts` 组装时传入），第 0 步 `activeTools` = 排盘工具 +（有则）`RECTIFICATION_OFFER_TOOL_ID`；没挂校正工具时与现在逐字节相同。
|
||||
- 第 0 步模型以**非** `explicitRequest` 方式调用校正工具（还没看过盘就想「顺口提议」）：工具返回一句「先排盘，看过盘再决定要不要提」之类的说明，**不**记为已提议（不占用「同一次对话提议过就不再提」的额度），之后照常排盘。
|
||||
- 验收：
|
||||
- `consultation-agentic-runtime.test.ts` 两条第 0 步断言按三栏改，新增「没挂校正工具时第 0 步只有排盘工具」「挂了时第 0 步是两者」。
|
||||
- 新增运行时测试（用现有假模型 / 假流的写法）：① 第 0 步直接 `explicitRequest=true` → 不调用排盘、正文是固定过渡句、`contractReady` 为真；② 第 0 步什么工具都不调用就写字 → 走 `runtime-contract-retry`，最终答案来自排盘之后；③ 第 0 步非 explicit 调用校正工具 → 不记为已提议，随后排盘、正常作答。
|
||||
|
||||
### T2 · 改写规则
|
||||
|
||||
- `RECTIFICATION_OFFER_RULE` 重排，**正向句放第一句**，大意：「校正就在这个对话里能开。用户这一轮明确要做出生时间校正（说法可能是校正、纠正、核对出生时间、看看出生时间准不准等），第一步就调用 offer-birth-time-rectification 并传 explicitRequest=true，不用先排盘，工具通过后只写那一句过渡。」其后才是「推得不准 → 先分读法 / 时间」与各禁止句。
|
||||
- 把规则里描述「用户不认同解释」那支的「纠正规则」改称「改读规则」（`FOLLOW_UP_CORRECTION_RULE` 的名字与内容不改，只改 `RECTIFICATION_OFFER_RULE` 里引用它的叫法），避免与「生时纠正」撞词。
|
||||
- 提示词总长不得明显增长（BUG-1256 瘦身后的口径）：新规则字数 ≤ 原规则 + 80 字，进度记录写原 / 新字数。
|
||||
- 验收：`rectification-explicit-entry-20261012.test.ts` 里查规则文本的断言按三栏改；新增断言：规则第一句含 `explicitRequest=true`，规则文本不含「纠正规则」。
|
||||
|
||||
### T3 · 记录
|
||||
|
||||
- `docs/BUG_HISTORY.md` 新增 BUG-1317（复发自 BUG-1306：为何旧测试与 T5 没拦住、本次推翻 BUG-923 第 0 步限制的决策、保险机制），BUG-1306 记录补「复发：BUG-1317」。
|
||||
- `docs/tasks/PROGRESS-rectification-step0-entry-20261013.md`、`CHANGELOG.md`。
|
||||
- 真机清单：在 `docs/testing/rectification-explicit-entry-20261012.md` 第 1 步后补一行「新对话第一句：『请你帮我生时纠正』（不带『进行』）」，并加第 9 步「新对话问『看看我今年事业』：照常先排盘解读，不出现校正」；或另写 `docs/testing/rectification-step0-entry-20261013.md` 引用原清单。
|
||||
|
||||
## 7. 让步顺序
|
||||
|
||||
T1 与 T2 都必须做（只做 T2 就是产品没选的 A）。时间不够时 T1 的第③条（非 explicit 调用不占额度）可降为「记录在 BLOCKED.md，回报里说明」。
|
||||
|
||||
## 8. 验收命令分工
|
||||
|
||||
| 谁 | 命令 |
|
||||
| --- | --- |
|
||||
| Grok 自跑 | 前端 `tsc --noEmit`、`npm run lint`；`node --test` 跑 `consultation-agentic-runtime.test.ts`、`consult-single-pass-answer-20260927.test.ts`、`rectification-explicit-entry-20261012.test.ts` 及新增文件（fail 与 cancelled 都为 0）。前端全量 `npm test`、整站构建不跑，以 Claude 为准 |
|
||||
| Claude 验收 | 上述 + 前端全量 `npm test` 与基线逐条比对 + `next build`（`/` 仍 Static，首屏 gzip ±2%）+ 逐行审规则文本 |
|
||||
| 不需要 | `test:db`、Python 快速门（不动 Python、不动数据库访问层） |
|
||||
|
||||
## 9. 开工前置命令
|
||||
|
||||
```bash
|
||||
git fetch origin --prune
|
||||
git worktree add -b codex/rectification-step0-entry-20261013 .worktrees/rectification-step0-entry-20261013 origin/staging
|
||||
cd .worktrees/rectification-step0-entry-20261013
|
||||
git log -1 --format=%h # 应为 963276ca2 或其后代
|
||||
grep -n "^## BUG-" docs/BUG_HISTORY.md | tail -3 # 核对最大号；BUG-1316 已预留给 #55
|
||||
grep -rn "consultationNatalPrepareStep\|consultationWindowPrepareStep\|RECTIFICATION_OFFER_RULE\|纠正规则\|activeTools" frontend/tests tests
|
||||
```
|
||||
|
||||
## 10. 环境缺口（预告）
|
||||
|
||||
- **真实模型是否会在第一步调用校正工具**，本机与 Grok 侧都没有模型凭据（供应商 key 加密存于管理端数据库），无法自动验证；名人生平回测同理。部署后由产品负责人按真机清单用 deepseek-v4-flash 与默认模型各走一遍（每个场景至少两次）。在此之前 BUG-1317 只能是 `fixed-pending-verify`。
|
||||
@@ -0,0 +1,80 @@
|
||||
# TASK · 上游同步第七轮：sync6 之后上游漏搬的 4 处小修 + 星历路径核查（2026-10-14）
|
||||
|
||||
- 日期：2026-10-14
|
||||
- 来源：产品 10-14 要求复查上游 Skill 仓（`/workspace/yinduzhanxing`，GitHub `732642856/yinduzhanxing`）。远端 main 仍停在 10-08 `0337b77f`，无新提交；按补丁内容逐条对照 10-02 以来 142 个提交：已有 38、不适用 101、**缺 3 个提交共 4 处**。产品 10-14 同意出本单，交 agent 循环由 Grok 执行。
|
||||
- 执行方：**Grok（Windows）**，分支 `codex/upstream-sync7-20261014`，只推这个分支
|
||||
- 验收：Claude（Linux）
|
||||
- BUG 编号：**BUG-1318 起**（开工时核对 `docs/BUG_HISTORY.md` 最大号；写作时最大号为 BUG-1317）。T1–T4 各一个号，T5 有结论再取号。
|
||||
|
||||
## 1. 基线
|
||||
|
||||
- 基线 commit：`origin/staging` `77057a81`。
|
||||
- 上游参照：`origin/main` `0337b77f`（10-08）。**上游 10-05 做过一次隐私改写，旧 SHA（`c593354f`、`23be1807`、`03bea6ed` 等）已不在上游 main**；本单只引用新 SHA。上游代码要点已抄在 §2，执行方不需要能访问上游仓库。
|
||||
- 只按下表逐项移植，不整文件覆盖上游文件。
|
||||
|
||||
## 2. 事故实证（`77057a81`，行号按符号定位）
|
||||
|
||||
| 项 | 上游提交 | 我方现状 |
|
||||
| --- | --- | --- |
|
||||
| T1 婚恋断语 | `f891a2c1` | `scripts/marriage_counting.py` 综合评级仍写「高（关系质量好，伴侣支持强，婚姻稳定）」…「低（关系质量有重大挑战，强烈建议婚前咨询）」；该结果经 `scripts/jyotish_engine.py` 放进导出包 `detail_blocks.marriage_counting`（模型可读）。另 `scripts/jyotish_api_server.py` DK 证据行写 `婚姻质量 {marriage_quality_score}/100`，而该分数是 0–1 |
|
||||
| T2 KP 判宫 | `0337b77f`（夹在隐私提交里） | `scripts/bhava_chalit.py` 只有 Parashari 中点判宫 `_planet_bhava`；`jyotish_engine.py` 的 `cmd_kp` 把同一结果当 KP 落宫用；`scripts/kp_system.py::calc_kp_analysis` 收了宫头却不声明判宫口径 |
|
||||
| T3 瑜伽去重排序 | `0337b77f` | `scripts/yoga_engine.py` 内 `_kendra_lords_list` / `_trikona_lords_list` 仍是 `list(set([...]))`（`jyotish_engine.py` 里的 `kl` / `tl` 已是 sorted，不用改） |
|
||||
| T4 大运年长 | `4d543209` | `scripts/jyotish_api_server.py` 两处 `365.25636`（大运兜底时间线 `end_date`、`years_into_md`），同一时间线 `scripts/dasha_analyzer.py` 用 `365.25` |
|
||||
| T5 星历路径（核查） | `e1909724` 揭示的同类问题 | `jyotish_engine.py::compute_chart_data` 与 transit 入口都 `swe.set_ephe_path('')`；上游发现路径是进程全局、未设路径的调用会悄悄退回 Moshier、结果随调用顺序变。我方是否同样，未查 |
|
||||
|
||||
上游代码要点（照此语义实现，命名可按我方风格）：
|
||||
|
||||
- **T1**：五档评级改为证据档位 `supportive_evidence_stronger` / `supportive_evidence_mixed_positive` / `mixed_evidence` / `pressure_evidence_mixed` / `pressure_evidence_stronger`，并加 `claim_boundary`：「D9 结构证据指数，不预测婚姻次数、稳定、离婚、伴侣好坏，也不提示需要婚前咨询」。
|
||||
- **T2**：`BhavaChalit` 新增 `_planet_bhava_from_cusps(planet_lon, cusps)`：宫 i 的范围是 `cusp[i] → cusp[(i+1)%12]`。计算入口加参数 `house_assignment`，取值只允许 `'sandhi'`（默认，本命 Bhava Chalit 表）或 `'cusp_to_cusp'`（KP），其他值抛 `ValueError`，结果里带 `house_assignment`。`cmd_kp` 显式用 `cusp_to_cusp`；`calc_kp_analysis` 新增 `house_occupancy_basis`，传了宫头却不声明就抛错，未传宫头时记 `whole_sign_proxy`；KP 报告表加一行「House occupancy basis」。
|
||||
- **T3**：`sorted(set(...))`，注释说明 set 顺序随进程哈希变化。
|
||||
|
||||
## 3. 根因
|
||||
|
||||
我方 sync6 参照的是 10-05 的五个计算修正；上游随后把 T2/T3 夹在 10-08 的隐私提交里，T1/T4 在 10-02～10-03 的提交里，当时按标题筛选时漏掉。
|
||||
|
||||
## 4. 决策记录（产品 2026-10-14 授权）
|
||||
|
||||
1. 移植 T1–T4；T5 只核查、出结论，**不改代码**（有问题另立单）。
|
||||
2. T1 用户可见措辞改中文证据档位（报告是中文为主；英文版用英文档位），**禁止**任何「婚姻稳定 / 离婚 / 再婚 / 几段婚姻 / 建议婚前咨询」类断语；`婚姻质量 X/100` 改为如实表达 0–1 指数（或去掉分母），不得乘 100 冒充百分制。沿用 sync4 T1（marriage_counting 删「再婚 / 几段关系」断语）的口径。
|
||||
3. 不搬：`fee84828` Sade Sati（我方无该表）；`59f61d3c` 等强制显式岁差（产品 10-03 已拒）；`ca20ae14` 健康改 D6/D8（占星师裁定只看 D30，甲8 试算变差）；10-02 校正门控 / 映射（试算未过门）；书库语料（来源版权不清）；上游 `AGENTS.md` §9 书库流程。
|
||||
|
||||
## 5. 硬红线
|
||||
|
||||
1. **不改生时校正打分**：T1–T4 均不在打分路径（KP 在 `OBSERVATION_ONLY_LAYERS`）。若任何改动触及 `scripts/research/sealed_holdout_rerun.py::PRODUCTION_FILES` 或其他冻结身份文件，停下回报（ERR-110），不得自行重新冻结。`test_rectification_validation_integrity_gate` 等冻结测试必须保持绿。
|
||||
2. `scripts/jyotish_api_server.py` 只允许 T1 那一行与 T4 两处常量的 bugfix 级改动；`tests/test_api_server_growth_contract.py` 必须过。
|
||||
3. golden 由真实引擎生成，不手造；改任何既有断言写「原值 / 新值 / 原因」三栏。
|
||||
4. 本命 Bhava Chalit 表的判宫结果必须逐字节不变（默认 `sandhi`）；只有 KP 层改变。
|
||||
5. 不改数据库、不改 workflow、不提升 main、不推 staging；只推 `codex/upstream-sync7-20261014`。
|
||||
6. 不写真实用户资料；示例只用公开名人盘（如乔布斯 AA）或虚构盘。
|
||||
|
||||
## 6. 任务分解
|
||||
|
||||
| 项 | 内容 | 验收 |
|
||||
| --- | --- | --- |
|
||||
| T1 | 婚恋评级改证据档位 + `claim_boundary`；DK 行「婚姻质量 X/100」改对；检查报告 / 导出包 / 中英文渲染里引用评级字符串的地方一并改 | 新测试：五档均不含断语词（稳定、离婚、再婚、婚前咨询、几段），`claim_boundary` 存在；DK 行不再出现 `/100`；中英文报告渲染各一例快照（公开盘） |
|
||||
| T2 | KP 宫头到宫头判宫，`house_assignment` / `house_occupancy_basis` 显式声明 | 新测试：构造宫头使行星落在「中点判宫」与「宫头判宫」不同宫，两种口径结果不同；默认 sandhi 与改前逐字节相同；`calc_kp_analysis` 传宫头不声明即抛错；KP 报告出现判宫口径行 |
|
||||
| T3 | 两处 `sorted(set(...))` | 新测试：用不同 `PYTHONHASHSEED` 起两个子进程算同一张盘，瑜伽参与者顺序一致 |
|
||||
| T4 | 两处 365.25636 → 365.25 | 新测试：兜底时间线与 `dasha_analyzer` 时间线同一大运起止一致（误差 0 天） |
|
||||
| T5 | 核查我方 Swiss Ephemeris 路径：`set_ephe_path('')` 实际落到哪套星历（看 `calc_ut` 返回 flag 是否含 `SEFLG_MOSEPH`）、生产镜像里是否有 `.se1` 星历文件、是否存在进程内不同调用路径用不同星历 | 进度记录写结论与证据；有问题写成新 BUG（`investigating`）并给建议，不改代码 |
|
||||
|
||||
每项一个提交，提交说明写上游提交号与 BUG 号。
|
||||
|
||||
## 7. 让步顺序
|
||||
|
||||
T1 不可让（违反「不断言婚姻」口径）。T3、T4 小，不可让。T2 可让（若改动面超出预期，先交 T1/T3/T4，T2 写清卡点）。T5 可让为环境缺口（Windows 无法确认生产镜像时如实写）。
|
||||
|
||||
## 8. 验收门（执行方自测 + Claude 复验）
|
||||
|
||||
- Python：`ruff`、`py_compile`、定向测试、**快速门全量** `scripts/run_quality_gate.py --profile quick`（`failures []` 或与基线同名）；冻结身份测试绿；隐私标记测试。
|
||||
- 本单只改 Python 与报告渲染；若碰到前端，加跑 tsc / lint / `npm test`（失败名单与基线逐名相同）/ build。
|
||||
- `docs/BUG_HISTORY.md`（BUG-1318 起）、`CHANGELOG.md`、`docs/tasks/PROGRESS-upstream-sync7-20261014.md`、`docs/tasks/README.md` 状态。
|
||||
|
||||
## 9. 开工前置
|
||||
|
||||
```
|
||||
git fetch origin --prune
|
||||
git status -sb
|
||||
git worktree add -b codex/upstream-sync7-20261014 .worktrees/upstream-sync7-20261014 origin/staging
|
||||
```
|
||||
|
||||
开工时核对 `origin/staging` 是否仍为 `77057a81`；若已前进，以最新 staging 为基，进度记录写明。
|
||||
@@ -5,6 +5,7 @@
|
||||
| 步 | 怎么做 | 通过标准 |
|
||||
| --- | --- | --- |
|
||||
| 1 | 新对话第一句：「请你帮我进行生时纠正」 | 直接打开校正。这一轮不写解读，不用点卡。过渡只有一句 |
|
||||
| 1b | 新对话第一句：「请你帮我生时纠正」（不带「进行」） | 同样直接打开校正，不先出「已完成几步」再写解读。BUG-1317 |
|
||||
| 2 | 另开三条新对话，分别说「帮我校正出生时间」「想核对一下出生时间准不准」「我出生时间是估的，帮我对一下」 | 三次都直接打开，不先出卡 |
|
||||
| 3 | 新对话先问一件普通的事，答完后再说「请帮我做生时校正」 | 这一轮直接打开，不把刚才的解读再写一遍 |
|
||||
| 4 | 新对话问事业，答完后说「你说我事业不顺，我觉得挺顺的」 | 认下、改读。不进入校正，下面没有提议卡 |
|
||||
@@ -12,5 +13,6 @@
|
||||
| 6 | 换到一个家人档案，第一句就说「请帮我校正出生时间」 | 一句「给家人校正暂时还不支持」。不打开校正 |
|
||||
| 7 | 在校正开关关闭，或价格暂时不可用时，本人说「请帮我做生时校正」 | 一句「出生时间核对这会儿还做不了。」不沉默，不写价格，不写内部原因。构造不了这一步就在进度里标环境缺口，不要改开关去试 |
|
||||
| 8 | 申报出生时段的本人档案，问一件普通的事，不要提校正 | 正文不写大运、子运的起止年月日，也不承诺能收窄出生时间 |
|
||||
| 9 | 新对话问「看看我今年事业」 | 照常先排盘再解读，不出现校正，下面没有提议卡 |
|
||||
|
||||
做不了的两句和家人那句以界面上的原句为准。点数：直接进入的那一轮不按解读扣咨询点；校正本身仍按原来的开案扣费。
|
||||
|
||||
@@ -25,8 +25,8 @@ Jyotisha 的可见文案是产品的一部分。正确性红线（真实性、
|
||||
|
||||
## 生时校正从对话进入（2026-10-07，BUG-1247～1251；2026-10-12，BUG-1306）
|
||||
|
||||
- **何时提议**：用户说推得不准时先分清读法问题和时间问题。只是不认同某个解释，按纠正规则认下、改读，不提校正。不承诺能收窄出生时间，不在对话里收集经历做校正。说出过去的具体事情和盘对不上、说出生时间是估的或记不准、但没有明确要做校正，才调用提议工具。同一次对话提议过、用户没接，不再主动提；用户自己再要求时传 `userAsked=true`。规则只定义在 `consultation-thinking-plan.ts` 的 `RECTIFICATION_OFFER_RULE`。不用关键词判断。
|
||||
- **明确要求则直接进入**：用户这一轮明确要做校正，由模型判断，不用关键词。服务端放行后直接打开校正：不先写解读，不用点卡。过渡只有一句「好，我们开始核对出生时间。」已经有一次没做完的，直接接着做那一次，不新开。开案还没成功时，回答下面仍是普通提议卡，不说「已经开始」；打开失败可以再点「开始核对出生时间」。开案并绑定来源之后才改成「已经开始」。
|
||||
- **何时提议**：校正就在这个对话里能开。用户说推得不准时先分清读法问题和时间问题。只是不认同某个解释，按改读规则认下、改读，不提校正。不承诺能收窄出生时间，不在对话里收集经历做校正。说出过去的具体事情和盘对不上、说出生时间是估的或记不准、但没有明确要做校正，要先看过盘再提议。同一次对话提议过、用户没接，不再主动提；用户自己再要求时传 `userAsked=true`。还没看盘就顺口提议，不算已经提议过。规则只定义在 `consultation-thinking-plan.ts` 的 `RECTIFICATION_OFFER_RULE`。不用关键词判断。
|
||||
- **明确要求则直接进入**：用户这一轮明确要做校正（校正、纠正、核对出生时间都算），由模型判断，不用关键词。第一步就可以打开，不用先排盘写解读。服务端放行后直接打开校正，不用点卡。过渡只有一句「好，我们开始核对出生时间。」已经有一次没做完的，直接接着做那一次，不新开。开案还没成功时，回答下面仍是普通提议卡，不说「已经开始」；打开失败可以再点「开始核对出生时间」。开案并绑定来源之后才改成「已经开始」。
|
||||
- **做不了必须说一句**：开关关着，或暂时没有价格，都说「出生时间核对这会儿还做不了。」不写内部原因，不写价格，不得沉默。家人档案说「给家人校正暂时还不支持」，不开案。有进行中的校正但这次打不开原来的会话，说「可在历史对话里接着做。」
|
||||
- **正文怎么提**（没有明确要求、只是时间可能不准）：一句，放在最后一段（例：「如果想确认出生时间准不准，可以用下面的卡片，答几道过去经历的题核对一下。」），不写价格和题数——卡片上写。
|
||||
- **卡片**：「可以用几道过去经历的题，核对一下你的出生时间。大约 N 题，会用掉 M 点；开始答第一题时才扣。」按钮「开始核对出生时间」；已开始（开案并绑定来源之后，不是结算当时）「出生时间核对已经开始。」/「继续核对出生时间」。点数来自 `feature_pricing`，不写死。
|
||||
|
||||
@@ -1215,11 +1215,17 @@ export async function POST(request: Request) {
|
||||
};
|
||||
const natalStreamOptions = {
|
||||
...streamOptions,
|
||||
prepareStep: consultationNatalPrepareStep,
|
||||
prepareStep: (input: { stepNumber: number }) => consultationNatalPrepareStep({
|
||||
stepNumber: input.stepNumber,
|
||||
rectificationOffer: true,
|
||||
}),
|
||||
};
|
||||
const windowStreamOptions = {
|
||||
...streamOptions,
|
||||
prepareStep: consultationWindowPrepareStep,
|
||||
prepareStep: (input: { stepNumber: number }) => consultationWindowPrepareStep({
|
||||
stepNumber: input.stepNumber,
|
||||
rectificationOffer: true,
|
||||
}),
|
||||
};
|
||||
const answerPhaseSignal = runClock.answerSignal;
|
||||
const startAnswerPhase = () => {
|
||||
|
||||
@@ -459,7 +459,7 @@ export function natalAnswerShapeInstruction(): string {
|
||||
* Never decided from keywords. Defined here once; the offer tool names the
|
||||
* same parameters and does not restate this rule.
|
||||
*/
|
||||
export const RECTIFICATION_OFFER_RULE = "出生时间核对：用户说你推得不准时，先分清是读法问题还是时间问题。只是不认同某个解释，按纠正规则认下、改读，不提校正。不承诺能收窄出生时间，不在对话里收集经历做校正。用户这一轮明确要做校正，就在写回答之前调用 offer-birth-time-rectification 并传 explicitRequest=true；工具通过后只写那一句过渡，不写解读。用户说出过去某件具体的事和盘对不上、说自己的出生时间是估的或记不准、但没有明确要做校正，才在写回答之前调用 offer-birth-time-rectification，再按工具结果在正文里用一句话提一下（不写价格和题数，卡片上有）。同一次对话提议过、用户没接，就不再主动提；用户自己再要求时调用并传 userAsked=true。工具说不能提供时（比如问的是家人），照工具说明用一句话说清楚。";
|
||||
export const RECTIFICATION_OFFER_RULE = "校正就在这个对话里能开：用户这一轮明确要做出生时间校正（说法可能是校正、纠正、核对出生时间、看看出生时间准不准等），第一步就调用 offer-birth-time-rectification 并传 explicitRequest=true，不用先排盘，工具通过后只写那一句过渡，不写解读。用户说你推得不准时，先分清是读法问题还是时间问题。只是不认同某个解释，按改读规则认下、改读，不提校正。不承诺能收窄出生时间，不在对话里收集经历做校正。用户说出过去某件具体的事和盘对不上、说自己的出生时间是估的或记不准、但没有明确要做校正，才在看过盘之后调用 offer-birth-time-rectification，再按工具结果在正文里用一句话提一下（不写价格和题数，卡片上有）。同一次对话提议过、用户没接，就不再主动提；用户自己再要求时调用并传 userAsked=true。工具说不能提供时（比如问的是家人），照工具说明用一句话说清楚。";
|
||||
|
||||
/** D4 / BUG-1166: the user corrects an earlier reading; acknowledge it, never defend the reading. */
|
||||
export const FOLLOW_UP_CORRECTION_RULE = "用户纠正了前面的判断（比如说父亲其实不常在身边）：先认下这件事，再只说盘上真正对得上的那几条、原来哪句读偏了；盘本身分不出的，直说「盘本身分不出这一点」，不把普通配置说成必然；不为原判断辩护。";
|
||||
|
||||
@@ -176,34 +176,41 @@ export const MAX_EVIDENCE_LOOKUPS_PER_TURN = 3;
|
||||
export const CONSULTATION_WINDOW_CALC_TOOL_ID = "run-jyotish-window-consultation";
|
||||
|
||||
/**
|
||||
* Step 0 exposes only the natal chart tool. Some thinking-mode providers
|
||||
* reject named and required toolChoice (BUG-282, BUG-937); the first step
|
||||
* therefore narrows with activeTools and leaves the choice as auto. Later
|
||||
* steps stay auto so the model can write after the request-scoped
|
||||
* calculation is in hand.
|
||||
* Step 0 narrows with activeTools and leaves toolChoice auto. Thinking-mode
|
||||
* providers reject named and required toolChoice (BUG-282, BUG-937).
|
||||
* When this turn mounted the rectification offer, that tool is available
|
||||
* beside the chart tool so an explicit request can open before a reading
|
||||
* (BUG-1317). Without it, step 0 is still only the chart tool (BUG-923).
|
||||
* Later steps stay auto.
|
||||
*
|
||||
* Window and general agents must not share this hook: they do not own this tool.
|
||||
* Window and general agents must not share the natal hook.
|
||||
*/
|
||||
export function consultationNatalPrepareStep(input: { stepNumber: number }) {
|
||||
return input.stepNumber === 0
|
||||
? {
|
||||
export function consultationNatalPrepareStep(input: { stepNumber: number; rectificationOffer?: boolean }) {
|
||||
if (input.stepNumber !== 0) return { toolChoice: "auto" as const };
|
||||
if (!input.rectificationOffer) {
|
||||
return {
|
||||
activeTools: [CONSULTATION_NATAL_CALC_TOOL_ID],
|
||||
toolChoice: "auto" as const,
|
||||
}
|
||||
: {
|
||||
toolChoice: "auto" as const,
|
||||
};
|
||||
}
|
||||
return {
|
||||
activeTools: [CONSULTATION_NATAL_CALC_TOOL_ID, RECTIFICATION_OFFER_TOOL_ID],
|
||||
toolChoice: "auto" as const,
|
||||
};
|
||||
}
|
||||
|
||||
export function consultationWindowPrepareStep(input: { stepNumber: number }) {
|
||||
return input.stepNumber === 0
|
||||
? {
|
||||
export function consultationWindowPrepareStep(input: { stepNumber: number; rectificationOffer?: boolean }) {
|
||||
if (input.stepNumber !== 0) return { toolChoice: "auto" as const };
|
||||
if (!input.rectificationOffer) {
|
||||
return {
|
||||
activeTools: [CONSULTATION_WINDOW_CALC_TOOL_ID],
|
||||
toolChoice: "auto" as const,
|
||||
}
|
||||
: {
|
||||
toolChoice: "auto" as const,
|
||||
};
|
||||
}
|
||||
return {
|
||||
activeTools: [CONSULTATION_WINDOW_CALC_TOOL_ID, RECTIFICATION_OFFER_TOOL_ID],
|
||||
toolChoice: "auto" as const,
|
||||
};
|
||||
}
|
||||
|
||||
const CONSULTATION_DOMAIN_DURATION_MS = 31_000;
|
||||
@@ -1174,6 +1181,12 @@ function createRectificationOfferTool(ctx: Readonly<{ state: ConsultationRuntime
|
||||
}
|
||||
return { offered: false as const, note: "已经在打开。不要再写解读。" };
|
||||
}
|
||||
if (input.explicitRequest !== true && !ctx.state.consultationToolCompleted) {
|
||||
return {
|
||||
offered: false as const,
|
||||
note: "先排盘，看过盘再决定要不要提。这次不算已经提议过。",
|
||||
};
|
||||
}
|
||||
if (hook.alreadyOffered && input.userAsked !== true && input.explicitRequest !== true) {
|
||||
return { offered: false as const, reason: "already_offered_in_session", note: "这次对话里已经提议过一次，用户没接。不再主动提校正，正常回答。" };
|
||||
}
|
||||
|
||||
@@ -679,26 +679,40 @@ test("guided-topic entrypoint ignores a model domain rewrite instead of executin
|
||||
|
||||
test("natal first step exposes only the chart calculation tool", () => {
|
||||
assert.equal(CONSULTATION_NATAL_CALC_TOOL_ID, "run-jyotish-consultation");
|
||||
// 原值: 第 0 步 toolChoice "required" / 新值: "auto"
|
||||
// 原因: BUG-282 供应商拒收 thinking 模式下的 required，BUG-937 撤回
|
||||
// 原值: 第 0 步 toolChoice "required"，后来改为只有排盘工具且 toolChoice "auto"
|
||||
// 新值: 没挂校正工具时第 0 步仍只有排盘工具；挂了时是排盘工具和 offer-birth-time-rectification。toolChoice 仍是 "auto"。第 1 步不收窄。
|
||||
// 原因: BUG-937 保持 auto；BUG-1317 按产品选择，第 0 步在工具确实挂上时可以打开校正。
|
||||
assert.deepEqual(consultationNatalPrepareStep({ stepNumber: 0 }), {
|
||||
activeTools: ["run-jyotish-consultation"],
|
||||
toolChoice: "auto",
|
||||
});
|
||||
assert.deepEqual(consultationNatalPrepareStep({ stepNumber: 1 }), {
|
||||
assert.deepEqual(consultationNatalPrepareStep({ stepNumber: 0, rectificationOffer: false }), {
|
||||
activeTools: ["run-jyotish-consultation"],
|
||||
toolChoice: "auto",
|
||||
});
|
||||
assert.deepEqual(consultationNatalPrepareStep({ stepNumber: 0, rectificationOffer: true }), {
|
||||
activeTools: ["run-jyotish-consultation", "offer-birth-time-rectification"],
|
||||
toolChoice: "auto",
|
||||
});
|
||||
assert.deepEqual(consultationNatalPrepareStep({ stepNumber: 1, rectificationOffer: true }), {
|
||||
toolChoice: "auto",
|
||||
});
|
||||
});
|
||||
|
||||
test("window first step requires the window consultation tool", () => {
|
||||
assert.equal(CONSULTATION_WINDOW_CALC_TOOL_ID, "run-jyotish-window-consultation");
|
||||
// 原值: 第 0 步 toolChoice "required" / 新值: "auto"
|
||||
// 原因: BUG-282 供应商拒收 thinking 模式下的 required，BUG-937 撤回
|
||||
// 原值: 第 0 步 toolChoice "required"，后来改为只有窗口排盘工具且 toolChoice "auto"
|
||||
// 新值: 没挂校正工具时第 0 步仍只有窗口排盘工具；挂了时再加上 offer-birth-time-rectification。toolChoice 仍是 "auto"。
|
||||
// 原因: 与本命同一条 BUG-1317 决定，申报时段也要能在第一步打开校正。
|
||||
assert.deepEqual(consultationWindowPrepareStep({ stepNumber: 0 }), {
|
||||
activeTools: ["run-jyotish-window-consultation"],
|
||||
toolChoice: "auto",
|
||||
});
|
||||
assert.deepEqual(consultationWindowPrepareStep({ stepNumber: 1 }), {
|
||||
assert.deepEqual(consultationWindowPrepareStep({ stepNumber: 0, rectificationOffer: true }), {
|
||||
activeTools: ["run-jyotish-window-consultation", "offer-birth-time-rectification"],
|
||||
toolChoice: "auto",
|
||||
});
|
||||
assert.deepEqual(consultationWindowPrepareStep({ stepNumber: 1, rectificationOffer: true }), {
|
||||
toolChoice: "auto",
|
||||
});
|
||||
});
|
||||
|
||||
@@ -233,8 +233,12 @@ test("consult streams reserve an answer budget and keep provider thinking on a s
|
||||
route.indexOf("const natalStreamOptions = {"),
|
||||
);
|
||||
assert.doesNotMatch(sharedStreamOptions, /prepareStep/);
|
||||
assert.match(route, /prepareStep: consultationNatalPrepareStep/);
|
||||
assert.match(route, /prepareStep: consultationWindowPrepareStep/);
|
||||
// 原值：prepareStep: consultationNatalPrepareStep / consultationWindowPrepareStep，函数本身不知道校正工具在不在。
|
||||
// 新值：路由把 rectificationOffer: true 传进去，因为这两条路线都会挂上校正工具。
|
||||
// 原因：BUG-1317，第 0 步在工具挂上时要能打开校正；没传时函数仍只留排盘工具。
|
||||
assert.match(route, /prepareStep: \(input: \{ stepNumber: number \}\) => consultationNatalPrepareStep\(\{/);
|
||||
assert.match(route, /prepareStep: \(input: \{ stepNumber: number \}\) => consultationWindowPrepareStep\(\{/);
|
||||
assert.match(route, /rectificationOffer: true/);
|
||||
assert.match(route, /streamWithOverflowRetry\(agent, natalStreamOptions\)/);
|
||||
assert.match(route, /streamWithOverflowRetry\(agent, windowStreamOptions\)/);
|
||||
assert.match(
|
||||
|
||||
@@ -72,8 +72,14 @@ function offerTool(options: {
|
||||
alreadyOffered?: boolean;
|
||||
decide?: () => Promise<OfferDecision>;
|
||||
loadResumableSessionId?: () => Promise<string | null>;
|
||||
/** False only for a step-0 call that has not seen the chart yet. */
|
||||
chartReady?: boolean;
|
||||
} = {}) {
|
||||
const state = createConsultationRuntimeState();
|
||||
if (options.chartReady !== false) {
|
||||
state.consultationToolCompleted = true;
|
||||
state.consultationToolSuccessCount = 1;
|
||||
}
|
||||
let decisions = 0;
|
||||
let loads = 0;
|
||||
const tools = createConsultationTools({
|
||||
@@ -520,6 +526,111 @@ test("an ordinary consultation still retries once when the calculation never fin
|
||||
assert.equal(events.some((event) => event.type === "activity" && event.label === "正在补齐方法与计算步骤"), true);
|
||||
});
|
||||
|
||||
test("step 0 explicit request opens rectification without calculating a chart", async () => {
|
||||
const fresh = offerTool({ chartReady: false });
|
||||
const result = await fresh.tool.execute({ explicitRequest: true });
|
||||
assert.equal(result.directEntry, "new");
|
||||
assert.equal(fresh.state.consultationToolCallCount, 0);
|
||||
assert.equal(fresh.state.consultationToolCompleted, false);
|
||||
assert.equal(fresh.state.rectificationDirectEntry?.sentence, RECTIFICATION_DIRECT_NEW_COPY);
|
||||
let contractRetries = 0;
|
||||
const response = streamAgentResponse({
|
||||
runId: "run-step0-explicit",
|
||||
requestId: REQUEST_ID,
|
||||
state: fresh.state,
|
||||
requireTool: true,
|
||||
pass4Mode: "verified_chart",
|
||||
stepScopedAnswer: true,
|
||||
toolStatus: () => "ready",
|
||||
receipt: () => receipt(fresh.state),
|
||||
stream: (async function* () {
|
||||
yield { type: "text-delta", payload: { text: "我先看看盘，然后写一段解读。" } };
|
||||
yield STOP_FINISH;
|
||||
})(),
|
||||
retry: async () => {
|
||||
contractRetries += 1;
|
||||
return (async function* () { yield STOP_FINISH; })();
|
||||
},
|
||||
});
|
||||
const events = await readStream(response);
|
||||
assert.equal(contractRetries, 0);
|
||||
assert.equal(visibleAnswer(events), RECTIFICATION_DIRECT_NEW_COPY);
|
||||
assert.equal(events.some((event) => event.type === "run.completed" && event.responseKind === "smalltalk"), true);
|
||||
});
|
||||
|
||||
test("step 0 text without a tool still retries into a chart answer", async () => {
|
||||
const state = createConsultationRuntimeState();
|
||||
let contractRetries = 0;
|
||||
const response = streamAgentResponse({
|
||||
runId: "run-step0-empty",
|
||||
requestId: REQUEST_ID,
|
||||
state,
|
||||
requireTool: true,
|
||||
pass4Mode: "verified_chart",
|
||||
stepScopedAnswer: true,
|
||||
toolStatus: () => "ready",
|
||||
receipt: () => receipt(state),
|
||||
stream: (async function* () {
|
||||
yield { type: "text-delta", payload: { text: "还没排盘就想写。" } };
|
||||
yield STOP_FINISH;
|
||||
})(),
|
||||
retry: async () => {
|
||||
contractRetries += 1;
|
||||
state.consultationToolCompleted = true;
|
||||
state.consultationToolSuccessCount = 1;
|
||||
return (async function* () {
|
||||
yield { type: "text-delta", payload: { text: "事业方向可以看。" } };
|
||||
yield STOP_FINISH;
|
||||
})();
|
||||
},
|
||||
});
|
||||
const events = await readStream(response);
|
||||
assert.equal(contractRetries, 1);
|
||||
assert.equal(visibleAnswer(events), "事业方向可以看。");
|
||||
assert.equal(state.rectificationDirectEntry, undefined);
|
||||
assert.equal(events.some((event) => event.type === "activity" && event.label === "正在补齐方法与计算步骤"), true);
|
||||
});
|
||||
|
||||
test("a soft offer before the chart is not recorded, then a chart answer can still offer", async () => {
|
||||
const fresh = offerTool({ chartReady: false });
|
||||
const early = await fresh.tool.execute({});
|
||||
assert.equal(early.offered, false);
|
||||
assert.match(String(early.note), /先排盘，看过盘再决定要不要提/);
|
||||
// 记在局部上再断言。直接断言 state 上的字段会把它收成永远是空，排盘后再读就对不上类型。
|
||||
const offerBeforeChart = fresh.state.rectificationOffer;
|
||||
assert.equal(offerBeforeChart, undefined);
|
||||
assert.equal(fresh.state.rectificationDirectEntry, undefined);
|
||||
assert.equal(fresh.decisions(), 0);
|
||||
fresh.state.consultationToolCompleted = true;
|
||||
fresh.state.consultationToolSuccessCount = 1;
|
||||
const later = await fresh.tool.execute({});
|
||||
assert.equal(later.offered, true);
|
||||
const offerAfterChart = fresh.state.rectificationOffer;
|
||||
assert.equal(offerAfterChart?.status, "offered");
|
||||
assert.equal(offerAfterChart?.autoOpen, undefined);
|
||||
assert.equal(fresh.decisions(), 1);
|
||||
const response = streamAgentResponse({
|
||||
runId: "run-step0-soft",
|
||||
requestId: REQUEST_ID,
|
||||
state: fresh.state,
|
||||
requireTool: true,
|
||||
pass4Mode: "verified_chart",
|
||||
stepScopedAnswer: true,
|
||||
toolStatus: () => "ready",
|
||||
receipt: () => receipt(fresh.state),
|
||||
stream: (async function* () {
|
||||
yield { type: "text-delta", payload: { text: "事业方向可以看。" } };
|
||||
yield STOP_FINISH;
|
||||
})(),
|
||||
retry: async () => {
|
||||
throw new Error("chart contract should already be ready");
|
||||
},
|
||||
});
|
||||
const events = await readStream(response);
|
||||
assert.equal(visibleAnswer(events), "事业方向可以看。");
|
||||
assert.equal(visibleAnswer(events).includes(RECTIFICATION_DIRECT_NEW_COPY), false);
|
||||
});
|
||||
|
||||
test("the offer rule is defined once, and direct entry settles with the free completion", () => {
|
||||
const definitions = walkSources(fileURLToPath(new URL("../src/", import.meta.url))).filter((file) => (
|
||||
readFileSync(file, "utf8").includes("export const RECTIFICATION_OFFER_RULE")
|
||||
@@ -530,7 +641,12 @@ test("the offer rule is defined once, and direct entry settles with the free com
|
||||
assert.match(RECTIFICATION_OFFER_RULE, /不在对话里收集经历做校正/);
|
||||
assert.match(RECTIFICATION_OFFER_RULE, /explicitRequest=true/);
|
||||
assert.match(RECTIFICATION_OFFER_RULE, /只写那一句过渡，不写解读/);
|
||||
assert.match(RECTIFICATION_OFFER_RULE, /只是不认同某个解释，按纠正规则认下、改读，不提校正/);
|
||||
// 原值：规则以「用户说你推得不准时」开头，并写「按纠正规则认下」。
|
||||
// 新值：第一句就写 explicitRequest=true，并改称「改读规则」。全文不含「纠正规则」。
|
||||
// 原因：BUG-1317，「生时纠正」和「纠正解读」撞词，正向句被埋在禁止句中间。
|
||||
assert.match(RECTIFICATION_OFFER_RULE.split("。")[0] ?? "", /explicitRequest=true/);
|
||||
assert.match(RECTIFICATION_OFFER_RULE, /按改读规则认下、改读，不提校正/);
|
||||
assert.doesNotMatch(RECTIFICATION_OFFER_RULE, /纠正规则/);
|
||||
assert.match(RECTIFICATION_OFFER_RULE, /userAsked=true/);
|
||||
|
||||
const tools = src("../src/mastra/consultation-tools.ts");
|
||||
|
||||
@@ -117,6 +117,11 @@ test("the server decides whether a card may be shown: self, product on, no case
|
||||
|
||||
function offerTool(options: { alreadyOffered?: boolean; decide?: () => Promise<{ ok: true; creditCost: number; questionEstimate: number } | { ok: false; reason: "not_self" | "product_disabled" | "case_in_progress" | "pricing_unavailable" }> } = {}) {
|
||||
const state = createConsultationRuntimeState();
|
||||
// 原值：建出来还没排盘也能直接提议。
|
||||
// 新值：这些用例表示已经看过盘，所以先标计算完成。
|
||||
// 原因：BUG-1317，还没排盘的顺口提议不算已经提议过。
|
||||
state.consultationToolCompleted = true;
|
||||
state.consultationToolSuccessCount = 1;
|
||||
const tools = createConsultationTools({
|
||||
userId: "user-fictional",
|
||||
sessionId: SOURCE_SESSION,
|
||||
@@ -194,7 +199,10 @@ test("the C2 rule is defined once and reaches first turns, follow-ups and declar
|
||||
assert.ok(followUpAnswerShapeInstruction().includes(RECTIFICATION_OFFER_RULE));
|
||||
const route = readFileSync(new URL("../src/app/api/consult/route.ts", import.meta.url), "utf8");
|
||||
assert.match(route, /这只是粗看。" \+ RECTIFICATION_OFFER_RULE;/);
|
||||
assert.match(RECTIFICATION_OFFER_RULE, /只是不认同某个解释，按纠正规则认下、改读，不提校正/);
|
||||
// 原值：/按纠正规则认下、改读，不提校正/
|
||||
// 新值：/按改读规则认下、改读，不提校正/
|
||||
// 原因：BUG-1317，避免「生时纠正」被读成「用户在纠正解读」。
|
||||
assert.match(RECTIFICATION_OFFER_RULE, /只是不认同某个解释，按改读规则认下、改读，不提校正/);
|
||||
assert.match(RECTIFICATION_OFFER_RULE, /userAsked=true/);
|
||||
});
|
||||
|
||||
|
||||
+23
-2
@@ -272,6 +272,20 @@ class BhavaChalitCalculator:
|
||||
# fallback: 最近的宫
|
||||
return 1
|
||||
|
||||
def _planet_bhava_from_cusps(self, planet_lon: float, cusps: List[float]) -> int:
|
||||
"""KP 宫头到宫头：宫 i（0 起）的范围是 cusp[i] → cusp[(i+1)%12]。
|
||||
|
||||
落在下一宫头上的点归下一宫。本命 Bhava Chalit 表不用这条。
|
||||
"""
|
||||
for i in range(12):
|
||||
start = cusps[i]
|
||||
end = cusps[(i + 1) % 12]
|
||||
arc = _angular_dist(start, end)
|
||||
pos = _angular_dist(start, planet_lon)
|
||||
if arc > 0 and pos < arc:
|
||||
return i + 1
|
||||
return 1
|
||||
|
||||
def _planet_rashi_house(self, planet_lon: float, asc_lon: float) -> int:
|
||||
"""整宫制宫位 (Rashi house)。"""
|
||||
p_si = _sign_idx(planet_lon)
|
||||
@@ -330,7 +344,8 @@ class BhavaChalitCalculator:
|
||||
asc_lon: float, mc_lon: float,
|
||||
house_system: str = 'sripati',
|
||||
jd: float = None, lat: float = None,
|
||||
lon: float = None) -> Dict:
|
||||
lon: float = None,
|
||||
house_assignment: str = 'sandhi') -> Dict:
|
||||
"""根据 Bhava 边界重新分配行星宫位。
|
||||
|
||||
Parameters
|
||||
@@ -346,13 +361,18 @@ class BhavaChalitCalculator:
|
||||
dict with keys:
|
||||
house_system, boundaries, planets
|
||||
"""
|
||||
if house_assignment not in ('sandhi', 'cusp_to_cusp'):
|
||||
raise ValueError("house_assignment must be 'sandhi' or 'cusp_to_cusp'")
|
||||
cusps = self.calculate_cusps(asc_lon, mc_lon, house_system,
|
||||
jd, lat, lon)
|
||||
sandhis = self.calculate_sandhis(cusps)
|
||||
|
||||
planets = {}
|
||||
for pname, plon in planet_lons.items():
|
||||
bhava = self._planet_bhava(plon, sandhis)
|
||||
if house_assignment == 'cusp_to_cusp':
|
||||
bhava = self._planet_bhava_from_cusps(plon, cusps)
|
||||
else:
|
||||
bhava = self._planet_bhava(plon, sandhis)
|
||||
rashi = self._planet_rashi_house(plon, asc_lon)
|
||||
si = _sign_idx(plon)
|
||||
deg_in_sign = plon - si * 30
|
||||
@@ -380,6 +400,7 @@ class BhavaChalitCalculator:
|
||||
return {
|
||||
'house_system': house_system,
|
||||
'house_system_desc': self.HOUSE_SYSTEMS.get(house_system, ''),
|
||||
'house_assignment': house_assignment,
|
||||
'ascendant_lon': round(asc_lon, 4),
|
||||
'mc_lon': round(mc_lon, 4),
|
||||
'planets': planets,
|
||||
|
||||
@@ -6378,7 +6378,7 @@ class JyotishAPIHandler(BaseHTTPRequestHandler, VedastroEvidenceMixin, SynastryM
|
||||
periods = []
|
||||
current = birth_dt
|
||||
for lord in DASHA_ORDER:
|
||||
end_date = current + timedelta(days=period_years * 365.25636)
|
||||
end_date = current + timedelta(days=period_years * 365.25)
|
||||
periods.append({
|
||||
'lord': lord,
|
||||
'years': period_years,
|
||||
@@ -7398,7 +7398,7 @@ class JyotishAPIHandler(BaseHTTPRequestHandler, VedastroEvidenceMixin, SynastryM
|
||||
current_idx, current_md = analyzer.find_current(timeline, today)
|
||||
antardashas = analyzer.build_antardasha(current_md)
|
||||
current_ad = analyzer.find_current_sub(antardashas, today)
|
||||
years_into_md = max(0.0, (today - current_md['start']).days / 365.25636)
|
||||
years_into_md = max(0.0, (today - current_md['start']).days / 365.25)
|
||||
five_levels = enhanced.calculate_five_level_dasha(current_md['lord'], years_into_md)
|
||||
formatted_timeline = [self._format_datetime_period(period) for period in timeline]
|
||||
formatted_antardashas = [self._format_datetime_period(period) for period in antardashas]
|
||||
@@ -7551,7 +7551,7 @@ class JyotishAPIHandler(BaseHTTPRequestHandler, VedastroEvidenceMixin, SynastryM
|
||||
evidence.append({
|
||||
'label': 'Darakaraka (DK)',
|
||||
'value': f"{dk_planet} · H{darakaraka.get('dk_house', '-')}",
|
||||
'note': f"{darakaraka.get('core_profile') or '配偶象征星'}；婚姻质量 {darakaraka.get('marriage_quality_score', '-')}/100",
|
||||
'note': f"{darakaraka.get('core_profile') or '配偶象征星'}；婚姻质量指数 {darakaraka.get('marriage_quality_score', '-')}（0到1）",
|
||||
})
|
||||
except Exception as exc:
|
||||
darakaraka = {'error': str(exc), 'dk_planet': dk_planet}
|
||||
|
||||
@@ -13963,6 +13963,7 @@ def cmd_kp(args):
|
||||
)
|
||||
bhava_chart = kp_house_calculator.get_bhava_chalit_chart(
|
||||
planet_lons, float(asc_lon), 0.0, 'placidus', jd, args.lat, args.lon,
|
||||
house_assignment='cusp_to_cusp',
|
||||
)
|
||||
bhava_planets = bhava_chart.get('planets') if isinstance(bhava_chart.get('planets'), dict) else {}
|
||||
|
||||
@@ -13977,7 +13978,12 @@ def cmd_kp(args):
|
||||
'house': bhava_row.get('bhava_house', pdata.get('house', 1)),
|
||||
}
|
||||
|
||||
result = calc_kp_analysis(planet_positions, asc_sign, house_cusps=boundaries.get('cusps'))
|
||||
result = calc_kp_analysis(
|
||||
planet_positions,
|
||||
asc_sign,
|
||||
house_cusps=boundaries.get('cusps'),
|
||||
house_occupancy_basis='cusp_to_cusp',
|
||||
)
|
||||
moon_lon = planets.get('Moon', {}).get('degree_raw', planets.get('Moon', {}).get('degree', 0.0)) if isinstance(planets.get('Moon'), dict) else 0.0
|
||||
try:
|
||||
birth_moment = datetime(int(args.year), int(args.month), int(args.day), int(args.hour), int(getattr(args, 'minute', 0) or 0))
|
||||
|
||||
@@ -371,6 +371,7 @@ def calc_kp_analysis(
|
||||
planet_positions: Dict,
|
||||
asc_sign: str = 'Aries',
|
||||
house_cusps: Optional[List[float]] = None,
|
||||
house_occupancy_basis: Optional[str] = None,
|
||||
) -> Dict:
|
||||
"""
|
||||
完整KP分析（基于 diliprk/VedicAstro MIT 算法）。
|
||||
@@ -379,6 +380,7 @@ def calc_kp_analysis(
|
||||
planet_positions: 行星位置 {planet: {'sign': str, 'degree': float, 'house': int}}
|
||||
asc_sign: 上升星座名称（无显式宫头时用于 whole-sign 代理）
|
||||
house_cusps: 可选的 12 个实际宫头黄经。提供时优先用于 KP 宫头与显著星。
|
||||
house_occupancy_basis: 传了宫头就必须声明判宫口径；没传宫头时记 whole_sign_proxy。
|
||||
|
||||
Returns:
|
||||
完整KP分析结果
|
||||
@@ -405,8 +407,11 @@ def calc_kp_analysis(
|
||||
}
|
||||
|
||||
explicit_cusps = house_cusps is not None
|
||||
if explicit_cusps and not house_occupancy_basis:
|
||||
raise ValueError('house_occupancy_basis is required when house_cusps are provided')
|
||||
if explicit_cusps and len(house_cusps) != 12:
|
||||
raise ValueError('house_cusps must contain exactly 12 longitudes')
|
||||
occupancy_basis = house_occupancy_basis if explicit_cusps else 'whole_sign_proxy'
|
||||
|
||||
# 2. 构建宫位信息（含 KP lords）。无实际宫头时保留历史 whole-sign 中点代理。
|
||||
houses = []
|
||||
@@ -438,6 +443,7 @@ def calc_kp_analysis(
|
||||
'source': 'diliprk/VedicAstro MIT License',
|
||||
'maturity_profile': kp_maturity_profile(),
|
||||
'house_basis': 'explicit_cusps' if explicit_cusps else 'whole_sign_proxy',
|
||||
'house_occupancy_basis': occupancy_basis,
|
||||
'planets': {pname: {'kp_lords': data['kp_lords'], 'significators': planet_sig.get(pname, {})}
|
||||
for pname, data in kp_planets.items()},
|
||||
'houses': {h['house']: {'sign': h['sign'], 'cusp_longitude': h['cusp_longitude'], 'kp_lords': h['kp_lords'], 'significators': house_sig.get(h['house'], {})}
|
||||
@@ -494,6 +500,7 @@ def build_kp_report_pack(
|
||||
f"- claim_status: `{maturity.get('claim_status')}`",
|
||||
f"- truth_matrix_allowed: `{maturity.get('truth_matrix_allowed')}`",
|
||||
f"- closed_oracle_parity_assets: `{', '.join(closed_parity_assets.keys())}`",
|
||||
f"- House occupancy basis: `{kp_analysis.get('house_occupancy_basis') or 'whole_sign_proxy'}`",
|
||||
f"- planet_count: `{len(planets)}`",
|
||||
f"- house_count: `{len(houses)}`",
|
||||
f"- dba_period_count: `{len(periods)}`",
|
||||
|
||||
@@ -21,6 +21,23 @@ from typing import Dict, Optional, List
|
||||
SIGN_CN = ['白羊座','金牛座','双子座','巨蟹座','狮子座','处女座',
|
||||
'天秤座','天蝎座','射手座','摩羯座','水瓶座','双鱼座']
|
||||
|
||||
# D9 结构证据档位（BUG-1318）。中文给报告正文，英文键与英文短句给英文版。
|
||||
# 不写婚姻稳定、离婚、再婚、段数或婚前咨询。
|
||||
D9_CLAIM_BOUNDARY = (
|
||||
'D9 结构证据指数，不预测婚姻次数、稳定、离婚、伴侣好坏，也不提示需要婚前咨询'
|
||||
)
|
||||
D9_CLAIM_BOUNDARY_EN = (
|
||||
'D9 structural evidence index. It does not predict marriage count, stability, '
|
||||
'divorce, or partner quality, and it does not suggest premarital counseling.'
|
||||
)
|
||||
D9_EVIDENCE_BANDS = (
|
||||
('supportive_evidence_stronger', '支持证据较强', 'Stronger supportive evidence'),
|
||||
('supportive_evidence_mixed_positive', '支持证据偏正', 'Mixed supportive evidence'),
|
||||
('mixed_evidence', '证据混杂', 'Mixed evidence'),
|
||||
('pressure_evidence_mixed', '压力证据偏杂', 'Mixed pressure evidence'),
|
||||
('pressure_evidence_stronger', '压力证据较强', 'Stronger pressure evidence'),
|
||||
)
|
||||
|
||||
|
||||
def sign_of(lon: float) -> int:
|
||||
"""从黄道经度计算星座序号 (0-11)"""
|
||||
@@ -348,25 +365,42 @@ def _assess_d9_marriage_quality(
|
||||
quality_points -= 1
|
||||
factors.append("D9 Ketu在7宫 → 关系中的分离倾向")
|
||||
|
||||
# 综合评级
|
||||
# 证据档位，不是婚姻结局（BUG-1318，上游 f891a2c1）。
|
||||
if quality_points >= 4:
|
||||
rating = "高（关系质量好，伴侣支持强，婚姻稳定）"
|
||||
band = D9_EVIDENCE_BANDS[0]
|
||||
elif quality_points >= 1:
|
||||
rating = "中上（关系质量尚可，需经营但基础好）"
|
||||
band = D9_EVIDENCE_BANDS[1]
|
||||
elif quality_points >= 0:
|
||||
rating = "中（关系质量一般，需用心经营）"
|
||||
band = D9_EVIDENCE_BANDS[2]
|
||||
elif quality_points >= -2:
|
||||
rating = "中下（关系有挑战，需提前沟通和调整期望）"
|
||||
band = D9_EVIDENCE_BANDS[3]
|
||||
else:
|
||||
rating = "低（关系质量有重大挑战，强烈建议婚前咨询）"
|
||||
band = D9_EVIDENCE_BANDS[4]
|
||||
|
||||
return {
|
||||
'quality_rating': rating,
|
||||
'quality_band': band[0],
|
||||
'quality_rating': band[1],
|
||||
'quality_rating_en': band[2],
|
||||
'quality_points': quality_points,
|
||||
'factors': factors,
|
||||
'claim_boundary': D9_CLAIM_BOUNDARY,
|
||||
'claim_boundary_en': D9_CLAIM_BOUNDARY_EN,
|
||||
}
|
||||
|
||||
|
||||
def render_d9_evidence_report(quality: Dict, language: str = 'zh') -> str:
|
||||
"""中文报告用证据档位短句；英文版用英文短句。两边都带同一条边界。"""
|
||||
if not isinstance(quality, dict):
|
||||
quality = {}
|
||||
if language == 'en':
|
||||
band = quality.get('quality_rating_en') or quality.get('quality_band') or ''
|
||||
boundary = quality.get('claim_boundary_en') or D9_CLAIM_BOUNDARY_EN
|
||||
return f"D9 evidence band: {band}\n{boundary}"
|
||||
band = quality.get('quality_rating') or ''
|
||||
boundary = quality.get('claim_boundary') or D9_CLAIM_BOUNDARY
|
||||
return f"D9 证据档位：{band}\n{boundary}"
|
||||
|
||||
|
||||
def _marriage_recommendations(base: Dict, d9_quality: Dict) -> List[str]:
|
||||
"""几何指数与伴侣数量、事件断语分开（BUG-1183）；不随指数大小给不同结论。"""
|
||||
return [
|
||||
|
||||
@@ -2140,6 +2140,7 @@ def render_pl9_parity_markdown(packet: dict) -> str:
|
||||
'### p123 KP Chart / Cusps',
|
||||
'',
|
||||
f"- House basis：{_cell(kp.get('house_basis'))}",
|
||||
f"- House occupancy basis：{_cell(kp.get('house_occupancy_basis'))}",
|
||||
'',
|
||||
'| House | Sign | Cusp longitude | KP lord chain |',
|
||||
'|-------|------|----------------|---------------|',
|
||||
|
||||
@@ -1687,11 +1687,13 @@ class YogaEngine:
|
||||
# 辅助：获取角宫主星列表
|
||||
def _kendra_lords_list():
|
||||
ai = SIGNS.index(ctx.ascendant) if ctx.ascendant in SIGNS else 0
|
||||
return list(set([SIGN_LORDS[SIGNS[(ai + h - 1) % 12]] for h in [1, 4, 7, 10]]))
|
||||
# set 顺序随进程哈希变化；排序后同一张盘的角宫主参与者顺序才稳定。
|
||||
return sorted(set([SIGN_LORDS[SIGNS[(ai + h - 1) % 12]] for h in [1, 4, 7, 10]]))
|
||||
# 辅助：获取三方宫主星列表
|
||||
def _trikona_lords_list():
|
||||
ai = SIGNS.index(ctx.ascendant) if ctx.ascendant in SIGNS else 0
|
||||
return list(set([SIGN_LORDS[SIGNS[(ai + h - 1) % 12]] for h in [1, 5, 9]]))
|
||||
# set 顺序随进程哈希变化；排序后同一张盘的三方主参与者顺序才稳定。
|
||||
return sorted(set([SIGN_LORDS[SIGNS[(ai + h - 1) % 12]] for h in [1, 5, 9]]))
|
||||
|
||||
safe_globals = {
|
||||
# 安全内置函数：只开放规则表达式需要的纯函数，避免 custom 规则因 all/any/len/set 缺失而静默失效。
|
||||
|
||||
@@ -0,0 +1,134 @@
|
||||
"""BUG-1318: D9 marriage rating is an evidence band, not an outcome claim.
|
||||
|
||||
Upstream f891a2c1. The five bands must not say the relationship is stable,
|
||||
ending, repeated, or in need of premarital counseling. The DK evidence line
|
||||
keeps the 0-1 index and does not print a fake /100 score.
|
||||
"""
|
||||
|
||||
from __future__ import annotations
|
||||
|
||||
import importlib.util
|
||||
import json
|
||||
import os
|
||||
import re
|
||||
import sys
|
||||
from pathlib import Path
|
||||
|
||||
ROOT = os.path.join(os.path.dirname(__file__), "..")
|
||||
SCRIPTS = os.path.join(ROOT, "scripts")
|
||||
if SCRIPTS not in sys.path:
|
||||
sys.path.insert(0, SCRIPTS)
|
||||
|
||||
from jyotish_engine import compute_chart_data # noqa: E402
|
||||
|
||||
|
||||
def _api_handler():
|
||||
"""Reuse the existing unbound handler helper. Do not add another forgery site."""
|
||||
path = os.path.join(os.path.dirname(__file__), "test_api_server_security.py")
|
||||
spec = importlib.util.spec_from_file_location("_api_security_helpers", path)
|
||||
module = importlib.util.module_from_spec(spec)
|
||||
spec.loader.exec_module(module)
|
||||
return module._handler()
|
||||
from marriage_counting import ( # noqa: E402
|
||||
D9_CLAIM_BOUNDARY,
|
||||
D9_EVIDENCE_BANDS,
|
||||
_assess_d9_marriage_quality,
|
||||
marriage_counting_full_analysis,
|
||||
render_d9_evidence_report,
|
||||
)
|
||||
from varga import calc_varga # noqa: E402
|
||||
|
||||
BANNED = re.compile(r"稳定|离婚|再婚|婚前咨询|几段")
|
||||
|
||||
|
||||
def _quality(points_chart: dict) -> dict:
|
||||
return _assess_d9_marriage_quality(points_chart, None)
|
||||
|
||||
|
||||
def test_five_bands_have_no_outcome_claims_and_keep_the_boundary() -> None:
|
||||
samples = {
|
||||
"supportive_evidence_stronger": {"Venus": 331.0, "Mars": 271.0, "Jupiter": 91.0},
|
||||
"supportive_evidence_mixed_positive": {"Venus": 31.0},
|
||||
"mixed_evidence": {"Venus": 10.0},
|
||||
"pressure_evidence_mixed": {"Venus": 151.0},
|
||||
"pressure_evidence_stronger": {"Venus": 151.0, "Mars": 91.0, "Jupiter": 271.0},
|
||||
}
|
||||
seen = []
|
||||
for key, chart in samples.items():
|
||||
quality = _quality(chart)
|
||||
assert quality["quality_band"] == key
|
||||
assert quality["claim_boundary"] == D9_CLAIM_BOUNDARY
|
||||
assert quality["claim_boundary_en"]
|
||||
assert not BANNED.search(quality["quality_rating"])
|
||||
assert not BANNED.search(quality["quality_rating_en"])
|
||||
seen.append(quality["quality_band"])
|
||||
assert seen == [band[0] for band in D9_EVIDENCE_BANDS]
|
||||
|
||||
|
||||
def test_public_chart_report_snapshots_in_both_languages() -> None:
|
||||
cases = json.loads(
|
||||
Path(ROOT, "references/real_case_calibration/minute_rectification_development_v1.json").read_text(encoding="utf-8")
|
||||
)["cases"]
|
||||
birth = next(case for case in cases if case["case_id"] == "steve_jobs_1955_development")["birth"]
|
||||
assert birth["source"]["rodden_rating"] == "AA"
|
||||
year, month, day = (int(part) for part in birth["date"].split("-"))
|
||||
hour, minute = (int(part) for part in birth["time"].split(":"))
|
||||
chart, *_ = compute_chart_data(
|
||||
year, month, day, hour, minute,
|
||||
birth["latitude"], birth["longitude"], birth["timezone_offset"],
|
||||
ayanamsa_name="raman",
|
||||
)
|
||||
longitudes = {name: row["degree_raw"] for name, row in chart["planets"].items()}
|
||||
d9 = {}
|
||||
for name, lon in longitudes.items():
|
||||
divisional = calc_varga(lon, 9)
|
||||
d9[name] = divisional["sign_idx"] * 30 + divisional["degree_in_sign"]
|
||||
result = marriage_counting_full_analysis(chart["houses"]["house_7"]["lord"], longitudes, d9)
|
||||
quality = result["d9_marriage_quality"]
|
||||
assert quality["quality_band"] == "mixed_evidence"
|
||||
assert quality["quality_points"] == 0
|
||||
chinese = render_d9_evidence_report(quality, "zh")
|
||||
english = render_d9_evidence_report(quality, "en")
|
||||
assert chinese == (
|
||||
"D9 证据档位：证据混杂\n"
|
||||
"D9 结构证据指数，不预测婚姻次数、稳定、离婚、伴侣好坏，也不提示需要婚前咨询"
|
||||
)
|
||||
assert english == (
|
||||
"D9 evidence band: Mixed evidence\n"
|
||||
"D9 structural evidence index. It does not predict marriage count, stability, "
|
||||
"divorce, or partner quality, and it does not suggest premarital counseling."
|
||||
)
|
||||
assert "/100" not in chinese
|
||||
assert "/100" not in english
|
||||
|
||||
|
||||
def test_dk_evidence_line_prints_the_zero_to_one_index() -> None:
|
||||
cases = json.loads(
|
||||
Path(ROOT, "references/real_case_calibration/minute_rectification_development_v1.json").read_text(encoding="utf-8")
|
||||
)["cases"]
|
||||
birth = next(case for case in cases if case["case_id"] == "steve_jobs_1955_development")["birth"]
|
||||
year, month, day = (int(part) for part in birth["date"].split("-"))
|
||||
hour, minute = (int(part) for part in birth["time"].split(":"))
|
||||
chart, asc_idx, *_ = compute_chart_data(
|
||||
year, month, day, hour, minute,
|
||||
birth["latitude"], birth["longitude"], birth["timezone_offset"],
|
||||
ayanamsa_name="raman",
|
||||
)
|
||||
longitudes = {name: row["degree_raw"] for name, row in chart["planets"].items()}
|
||||
handler = _api_handler()
|
||||
evidence = handler._compute_relationship_timing_evidence(
|
||||
{},
|
||||
chart["planets"],
|
||||
longitudes,
|
||||
asc_idx,
|
||||
chart["ascendant"]["sign"],
|
||||
)
|
||||
notes = [row["note"] for row in evidence["evidence"] if row.get("label") == "Darakaraka (DK)"]
|
||||
assert len(notes) == 1
|
||||
assert "/100" not in notes[0]
|
||||
assert "婚姻质量指数" in notes[0]
|
||||
assert "（0到1）" in notes[0]
|
||||
score = evidence["darakaraka"]["marriage_quality_score"]
|
||||
assert isinstance(score, float)
|
||||
assert 0.0 <= score <= 1.0
|
||||
assert str(score) in notes[0]
|
||||
@@ -0,0 +1,62 @@
|
||||
"""BUG-1321: the API fallback dasha year matches dasha_analyzer's 365.25 days.
|
||||
|
||||
Upstream 4d543209. The two 365.25636 constants in the API server made the
|
||||
fallback timeline and the years-into-mahadasha figure drift from the analyzer.
|
||||
"""
|
||||
|
||||
from __future__ import annotations
|
||||
|
||||
import importlib.util
|
||||
import os
|
||||
import sys
|
||||
from datetime import datetime, timedelta
|
||||
|
||||
SCRIPTS = os.path.join(os.path.dirname(__file__), "..", "scripts")
|
||||
if SCRIPTS not in sys.path:
|
||||
sys.path.insert(0, SCRIPTS)
|
||||
|
||||
from dasha_analyzer import build_dasha_timeline, lon_to_nakshatra # noqa: E402
|
||||
|
||||
|
||||
def _api_handler():
|
||||
"""Reuse the existing unbound handler helper. Do not add another forgery site."""
|
||||
path = os.path.join(os.path.dirname(__file__), "test_api_server_security.py")
|
||||
spec = importlib.util.spec_from_file_location("_api_security_helpers_dasha", path)
|
||||
module = importlib.util.module_from_spec(spec)
|
||||
spec.loader.exec_module(module)
|
||||
return module._handler()
|
||||
|
||||
|
||||
def test_fallback_timeline_matches_analyzer_to_the_day() -> None:
|
||||
birth = datetime(2000, 1, 1)
|
||||
nak_info, progress, _pada = lon_to_nakshatra(0.0)
|
||||
timeline, _elapsed, _remaining, _lord = build_dasha_timeline("2000-01-01", nak_info, progress)
|
||||
handler = _api_handler()
|
||||
years = timeline[0]["years"]
|
||||
periods = handler._fallback_dasha_periods(birth, "generic", {"years": years * 9})
|
||||
assert periods[0]["lord"] == timeline[0]["lord"]
|
||||
assert periods[0]["start"] == timeline[0]["start"].strftime("%Y-%m-%d")
|
||||
assert periods[0]["end"] == timeline[0]["end"].strftime("%Y-%m-%d")
|
||||
fallback_days = (
|
||||
datetime.strptime(periods[0]["end"], "%Y-%m-%d")
|
||||
- datetime.strptime(periods[0]["start"], "%Y-%m-%d")
|
||||
).days
|
||||
analyzer_days = (timeline[0]["end"].date() - timeline[0]["start"].date()).days
|
||||
assert fallback_days - analyzer_days == 0
|
||||
|
||||
long_periods = handler._fallback_dasha_periods(birth, "generic", {"years": 1422})
|
||||
expected = (birth + timedelta(days=158 * 365.25)).strftime("%Y-%m-%d")
|
||||
stale = (birth + timedelta(days=158 * 365.25636)).strftime("%Y-%m-%d")
|
||||
assert expected != stale
|
||||
assert long_periods[0]["end"] == expected
|
||||
|
||||
|
||||
def test_years_into_mahadasha_uses_the_analyzer_year() -> None:
|
||||
birth = datetime(2000, 1, 1)
|
||||
today = datetime(2003, 1, 1)
|
||||
handler = _api_handler()
|
||||
layer = handler._compute_vimshottari_analysis_layer(birth, 0.0, current_date="2003-01-01")
|
||||
days = (today - birth).days
|
||||
years_into = layer["five_levels"]["mahadasha"]["years_into_period"]
|
||||
assert years_into == days / 365.25
|
||||
assert years_into != days / 365.25636
|
||||
@@ -0,0 +1,58 @@
|
||||
"""BUG-1319: KP house occupancy is cusp-to-cusp and must be declared.
|
||||
|
||||
Upstream 0337b77f. Natal Bhava Chalit stays on the sandhi midpoint rule.
|
||||
"""
|
||||
|
||||
from __future__ import annotations
|
||||
|
||||
import os
|
||||
import sys
|
||||
|
||||
import pytest
|
||||
|
||||
SCRIPTS = os.path.join(os.path.dirname(__file__), "..", "scripts")
|
||||
if SCRIPTS not in sys.path:
|
||||
sys.path.insert(0, SCRIPTS)
|
||||
|
||||
from bhava_chalit import BhavaChalitCalculator # noqa: E402
|
||||
from kp_system import build_kp_report_pack, calc_kp_analysis # noqa: E402
|
||||
|
||||
|
||||
def test_cusp_to_cusp_differs_from_sandhi_and_default_houses_stay() -> None:
|
||||
calc = BhavaChalitCalculator()
|
||||
planets = {"Sun": 40.0}
|
||||
sandhi = calc.get_bhava_chalit_chart(planets, 15.0, 270.0, "equal")
|
||||
explicit = calc.get_bhava_chalit_chart(
|
||||
planets, 15.0, 270.0, "equal", house_assignment="sandhi",
|
||||
)
|
||||
cusp = calc.get_bhava_chalit_chart(
|
||||
planets, 15.0, 270.0, "equal", house_assignment="cusp_to_cusp",
|
||||
)
|
||||
assert sandhi["house_assignment"] == "sandhi"
|
||||
assert explicit["planets"]["Sun"]["bhava_house"] == sandhi["planets"]["Sun"]["bhava_house"] == 2
|
||||
assert cusp["house_assignment"] == "cusp_to_cusp"
|
||||
assert cusp["planets"]["Sun"]["bhava_house"] == 1
|
||||
assert cusp["planets"]["Sun"]["bhava_house"] != sandhi["planets"]["Sun"]["bhava_house"]
|
||||
|
||||
|
||||
def test_unknown_house_assignment_is_rejected() -> None:
|
||||
calc = BhavaChalitCalculator()
|
||||
with pytest.raises(ValueError, match="house_assignment"):
|
||||
calc.get_bhava_chalit_chart({"Sun": 10.0}, 15.0, 270.0, "equal", house_assignment="whole")
|
||||
|
||||
|
||||
def test_kp_cusps_require_an_occupancy_basis_and_the_report_names_it() -> None:
|
||||
planets = {"Sun": {"sign": "Taurus", "degree": 10.0, "house": 2}}
|
||||
cusps = [15.0 + 30.0 * index for index in range(12)]
|
||||
with pytest.raises(ValueError, match="house_occupancy_basis"):
|
||||
calc_kp_analysis(planets, "Aries", house_cusps=cusps)
|
||||
with pytest.raises(ValueError, match="house_occupancy_basis"):
|
||||
calc_kp_analysis(planets, "Aries", house_cusps=cusps, house_occupancy_basis="")
|
||||
declared = calc_kp_analysis(
|
||||
planets, "Aries", house_cusps=cusps, house_occupancy_basis="cusp_to_cusp",
|
||||
)
|
||||
assert declared["house_occupancy_basis"] == "cusp_to_cusp"
|
||||
proxy = calc_kp_analysis(planets, "Aries")
|
||||
assert proxy["house_occupancy_basis"] == "whole_sign_proxy"
|
||||
markdown = build_kp_report_pack(declared)["exports"]["markdown"]
|
||||
assert "House occupancy basis: `cusp_to_cusp`" in markdown
|
||||
@@ -0,0 +1,72 @@
|
||||
"""BUG-1320: kendra and trikona lord lists do not follow PYTHONHASHSEED.
|
||||
|
||||
Upstream 0337b77f. Two processes with different hash seeds must list the
|
||||
same yoga participants in the same order.
|
||||
"""
|
||||
|
||||
from __future__ import annotations
|
||||
|
||||
import json
|
||||
import os
|
||||
import subprocess
|
||||
import sys
|
||||
|
||||
ROOT = os.path.abspath(os.path.join(os.path.dirname(__file__), ".."))
|
||||
|
||||
_PROBE = r"""
|
||||
import json
|
||||
import sys
|
||||
sys.path.insert(0, "scripts")
|
||||
from yoga_engine import YogaContext, YogaEngine, detect_yogas
|
||||
|
||||
planets = {
|
||||
"Sun": {"sign": "Leo", "house": 5, "degree": 10},
|
||||
"Moon": {"sign": "Cancer", "house": 4, "degree": 5},
|
||||
"Mars": {"sign": "Aries", "house": 1, "degree": 8},
|
||||
"Mercury": {"sign": "Virgo", "house": 6, "degree": 12},
|
||||
"Jupiter": {"sign": "Sagittarius", "house": 9, "degree": 15},
|
||||
"Venus": {"sign": "Libra", "house": 7, "degree": 3},
|
||||
"Saturn": {"sign": "Capricorn", "house": 10, "degree": 20},
|
||||
"Rahu": {"sign": "Taurus", "house": 2, "degree": 9},
|
||||
"Ketu": {"sign": "Scorpio", "house": 8, "degree": 9},
|
||||
}
|
||||
rules = "references/yoga_rules.json"
|
||||
engine = YogaEngine(rules)
|
||||
ctx = YogaContext(planets, "Aries")
|
||||
namespace = engine._build_custom_exec_globals(ctx, {}, {})
|
||||
rows = detect_yogas(planets, "Aries", rules)
|
||||
print(json.dumps({
|
||||
"kendra": namespace["kendra_lords_list"](),
|
||||
"trikona": namespace["trikona_lords_list"](),
|
||||
"participants": [
|
||||
[row.get("rule_id"), str(row.get("combination"))]
|
||||
for row in rows
|
||||
],
|
||||
}, ensure_ascii=False))
|
||||
"""
|
||||
|
||||
|
||||
def _run(seed: str) -> dict:
|
||||
env = os.environ.copy()
|
||||
env["PYTHONHASHSEED"] = seed
|
||||
env["PYTHONIOENCODING"] = "utf-8"
|
||||
completed = subprocess.run(
|
||||
[sys.executable, "-c", _PROBE],
|
||||
cwd=ROOT,
|
||||
env=env,
|
||||
check=True,
|
||||
capture_output=True,
|
||||
text=True,
|
||||
encoding="utf-8",
|
||||
)
|
||||
return json.loads(completed.stdout)
|
||||
|
||||
|
||||
def test_yoga_participants_keep_the_same_order_across_hash_seeds() -> None:
|
||||
first = _run("0")
|
||||
second = _run("1")
|
||||
assert first == second
|
||||
assert first["kendra"] == sorted(first["kendra"])
|
||||
assert first["trikona"] == sorted(first["trikona"])
|
||||
assert first["kendra"] == ["Mars", "Moon", "Saturn", "Venus"]
|
||||
assert first["trikona"] == ["Jupiter", "Mars", "Sun"]
|
||||
Reference in New Issue
Block a user