Jyotisha/docs/tasks/PROGRESS-upstream-sync5-20261002.md

PROGRESS · 上游同步第五轮 + 生时校正 4 件 3 域（2026-10-02）

• 任务书：docs/tasks/TASK-upstream-sync5-20261002.md（origin/staging 677d40f9）。
• 执行方式：产品授权直接执行。Claude（PM）先在本会话移植上游代码（U2–U8 各一或两个提交）；子代理完成 U8 后续、R1、测试修复、记忆化 golden、研究记录重新冻结、评测、golden、回测与记录。只 commit，未 push。
• 分支 / worktree：codex/upstream-sync5-20261002 / .worktrees/upstream-sync5-20261002，基线 677d40f9（代码同已部署 3d0c3cdf）。
• 上游参照：/workspace/yinduzhanxing origin/main c593354f（只读；未从上游复制文案，本地 ref 未改）。
• BUG 编号：开工核对 origin/staging 最大号 BUG-1191；本单 BUG-1192～1198（提交前再核对，未被占用）。

提交

提交	项	内容	BUG
cb9d942b（PM）	U2	8 星制 Chara Karaka 罗睺按 30° 减度数排位（上游 197672e3）	1194
bdbff99a（PM）	U3	五大人格燃烧顺 / 逆行表（上游 eaf6918b）	1195
533c3a30、9959e514（PM）	U6	诅咒格 / Rashi Tulya 健康措辞 + 测试（上游 b40c7fde、28f41912）	1197
765ff66c（PM）	U8	Badhaka 12 上升测试（上游 6abfe983）	1192
cf78d4ca（PM）	U3	全引擎燃烧表统一到 COMBUSTION_ORBS / is_combust，含月亮、逆行与普通对话层（上游 080c286c，改编）	1195
5172620c（PM）	U5	Yogini 按月宿起运（上游 cb7fe017）	1196
45d6dbf6（PM）	U7	水星燃烧时 Budha-Aditya 降为有条件（上游 994638f0 只取此段）	1198
54f6930b、67aa1b33（PM）	U4	三方净化、单宫主净化（上游 9531d1dc、868f1dad）	—
7fb165ec	U8 后续	诅咒格 Badhaka 宫按上升取 11/9/7、删早夭 / 早逝措辞	1192
758fee95	R1	生时校正交付门槛 4 件 3 域；政策 v4；记忆化 golden v3；30 个前端测试文件 + 4 个 Python 测试	1193
1029cbaa	R1 / ERR-110	研究记录重新冻结（标签 upstream_sync5_2026_10_02）	1193
917e18a0	—	普通对话回测 golden 重生成	—
03d60e29	U3 后续	两张燃烧表相等测试	1195
90dcafe7	R1 后续	隐私扫描按行号钉的两处碰撞保持原行	1193
（本提交）	—	记录：BUG 历史、CHANGELOG、本文件、任务索引、回测第七轮	—

逐项

U1 Narayana 默认版本 —— 不搬（产品延后）

上游 acdc3551 只改了 scripts/cmd_narayana_dasha.py 一行：variant_profile 默认值 legacy_local → kn_rao。本仓的 cmd_narayana_dasha.py 根本没有 variant_profile 开关（上游更早加入的 K.N. Rao profile 本仓未同步），生时校正（event_probes、active_rectification_event_engine）直接调 narayana_dasha.calc_narayana_mahadasha 等函数，也不经过这个命令入口；要「默认 K.N. Rao」得先整体移植 profile 机制，不是一行默认值；而「产品是否改用 K.N. Rao 版本」是占星师待裁决项（乙表），改函数默认会同时改生时校正打分。本轮不移植，留待占星师确认后单独立单（需过 v5 评测与历史可打开核对）。

U2 Chara Karaka 罗睺（BUG-1194）

PM 移植。生时校正只用 jaimini.calc_arudha_padas，不读 Karaka；77 例 A/B 分数相同。

U3 燃烧（BUG-1195）

• PM 移植两提交。全引擎现在两张表：jyotish_engine.COMBUSTION_ORBS（全读、普通对话 graha drishti 层）与 pancha_mahapurusha.COMBUSTION_ORB（上游形状）。数值相同；03d60e29 加测试锁两表相等，并在每个容许度边界验证两个函数。scripts/validate_yoga_accuracy.py 另有一张简化表（只顺行），是离线校验脚本，不在产品路径，未改。
• 普通对话卡上的变化：9 位回测名人中只有齐达内一颗逆行金星由燃烧改为不燃烧。

U4 八分法净化 —— 函数已加，未接入输出

上游只新增 calc_trikona_shodhana / calc_ekadhipatya_shodhana（上游仓内也没有调用方）。本仓同样不接入报告、数据卡与生时校正，SAV 原值不变；函数可供后续调用。scripts/ashtakavarga.py 在生时校正冻结身份里，字节变化按 ERR-110 重新冻结。

U5 Yogini（BUG-1196）、U6 诅咒格措辞（BUG-1197）、U7 Budha-Aditya（BUG-1198）

PM 移植；测试见各提交。U5 上游对本仓不存在的测试文件的改动未带；U7 上游同一 hunk 里其它卡片闸门字段来自别的提交，未带。

U8 Badhaka（BUG-1192）

• 核对：本仓两处 Badhaka。yoga_engine.YogaContext.is_badhaka 已按动 / 定 / 变取 11 / 9 / 7（上游测试 765ff66c 通过）；curse_yoga_detector 亡灵格（Preta Yoga 两条）加重宫位写死 [8, 11, 6]、注释「11宫=Badhaka」—— 记忆里说的「写死 11 并输出过早死亡风险」就是这里（「过早死亡风险」已由 U6 去掉）。
• 修复：yoga_engine.badhaka_house() 成为唯一定义，is_badhaka 与诅咒格都调它；Preta 两条的加重宫位改为按上升展开（D9 检测用 D9 上升；上升未知时 Badhaka 宫不参与加重，原 is_badhaka 对未知上升返回 7 宫，现在返回 False）。
• 死亡措辞 grep：rg "过早死亡|死亡风险|早夭|早逝|夭折|血脉.*(中断|停止)|死亡之神" scripts references/*.json 后剩余：诅咒格「家族影响」两条（子女早夭、家族血脉停止）→ 改为责任 / 传承主题；references/yoga_rules.json 母亲不利格效果「母亲早逝 / Early loss of mother」→ 删除。剩余命中只在 scripts/misconceptions.py、scripts/case_validator.py（李小龙案例笔记，供内部案例校验，不进用户输出）与 references/*.md 讲稿资料。前端两份报告阅读 fixture（report-reader-main-fictional*.json）是历史引擎输出，仍含「母亲早逝」，未重采（不影响线上）。
• 测试：tests/test_curse_yoga_badhaka_house.py（12 个上升、未知上升、源码与实际输出正则扫描）。

R1 生时校正 4 件 3 域（BUG-1193）

门槛位置（改前 → 改后）

位置	改前	改后
references/rectification_policy.v1.json minConfirmationEvents / minConfirmationDomains	4 / 3（只被确认门读）	不变，成为唯一定义
frontend/src/lib/rectification-agentic/core/types.ts MIN_TRAINING_EVENTS = 3（收敛判定，只数训练件）	3 件	删除；新 MIN_DATED_EVENTS / MIN_DATED_DOMAINS 读政策文件；收敛判定数训练 + 留出，并加领域条件
core/rectification-decision.ts MIN_STANDALONE_DATED_EVENTS / DOMAINS（区间交付门、出牌前「继续采集」）	3 / 2	= MIN_DATED_*（4 / 3）
v9/evidence-model.ts MIN_ACCEPTANCE_EVENTS / DOMAINS + trainingScoreableGate（训练门：何时开始出选择题、出卡）	3 / 2，只数训练件	= MIN_DATED_*，数训练 + 留出的全部带日期主经历
v9/decision-from-dossier.ts 推断后 trainingGateOpen	训练件 3 / 2	训练 + 留出 4 / 3
scripts/rectification/decision_policy.py MIN_ACCEPTANCE_EVENTS / DOMAINS（回执 event_quality / domain_diversity，决定 acceptance_allowed / selection_allowed）	3 / 2，只数训练件	= MIN_CONFIRMATION_*（政策文件），数全部可计分经历；POLICY_VERSION v3 → v4
其它（未改，含义不同）	case_holdout.py / split-holdout.ts 第 4 件起留出 1 件；candidate_contrast.MIN_DISCRIMINATOR_*（区分题供给）；研究脚本 holdout_v5_build 7 件 4 域（数据集入选标准）；minute_rectification_holdout_validator 每例 3 件（固定协议）	—

• 计数口径：产品口径「至少 4 件事」按用户给出的带日期主经历算，包括被留作 holdout 的那一件（留出规则不变：第 4 件起留 1 件）。若改成只数训练件，用户要说 5 件才够。
• 遗留（待产品）：留出规则优先把只有一件的领域留作 holdout，刚好 4 件 3 域时，实际参与打分的常是 2 个领域 3 件事。要不要改成「训练件也要 3 个领域」（等于要 5 件以上），请产品定。
• 打分不变：77 例 v5 用 score_candidates（±10，分钟步长 2，冻结日期）A/B 逐分相同；记忆化 fixture 分数与 v2 golden 相同，只有回执变（policy_version v4、event_quality.minimum 3 → 4、domain_diversity.minimum 2 → 3 且 2 域不再通过、代表候选 UUID 随 policy 命名空间变、feature_hash 随 ERR-111 变）。按 BUG-1181 先例「同输入出不同分才升算法版本」，不升 rectification-v5-matrix-scoring-11；ALGORITHM_VERSION 仍 scoring-10，policy 身份 v4。记忆化 golden 按先例由 write_golden 写 v3，v2 冻结并按 sha256 钉住（新测试断言 v2 / v3 分数相同、只回执 policy 变）。
• 历史 Case 能否打开（BUG-621）：算法版本与 Skill 版本都没变；policy 版本只参与「缓存分数是否可复用」与候选 UUID，旧结果按存储的身份只读打开、重新比较时按 v4 算。前端 rectification-history-open / engine-version-cross-midnight / dated-algorithm-generation 等测试全过（npm test 失败名单与基线相同）。未做浏览器级验证。
• 采集文案：preciseGapNarration 不再一律「再来一件……就能开始筛」，按缺口写「再来两件记得大概年月的事，其中至少一件不是上学或工作的，就能开始筛」「再来四件……、至少涉及三个方面，就能开始筛」，只差一件时仍是「再来一件……」。保留「就能开始筛」字样（多处合同测试按它识别缺口句）。VOICE.md 第 293 行同步。user-copy.ts 的 insufficientEventsGate / insufficientDomainsGate（「再来一件……」）只被 acceptanceGateNarration 用，而该函数在 answer-choice.ts 只 import 未调用，未改（死代码，记一笔）。遗留表单 components/birth-time-life-events.tsx（无引用方）文案与校验同步为 4 条、3 个领域。Skill 文本里没有写 3 件 2 域（只有「propose_allowed 需要可评分事件≥4、领域≥3」），Skill 版本不变。
• 采集流程：训练门（trainingScoreableGate）同时决定「继续口述采集」与「开始出选择题 / 出卡」，门槛抬到 4 / 3 后，采集线会一直问到 4 件 3 域（原 3 件 2 域就转选择题）。BUG-1048 是出题闸门最小间隔问题，与件数无关；BUG-647 的「holdout 不饿死训练」不变（4 件时训练仍 3 件）。

测试三栏（摘要；逐条注释写在测试里）

文件	用例	原值	新值	原因
rectification-convergence-budget	insufficient standalone evidence keeps collecting	{2/2}→dated、{3/1}→domains	{3/3}→dated、{4/2}→domains	R1 门槛下方各取一格
同上	standalone delivery floor（改名 shares the 4/3 policy…）	3、2	4、3 且与政策同源	R1 单一定义
同上	dossier wiring	3 条 career → insufficient_domains	3 career + 1 relationship → insufficient_domains	3 件会先落 insufficient_dated_events
rectification-decide-next-action	discrimination waits for…（改名 four dated events across three domains）	three.open=true、3 件出区分题	false、继续采集；新增 4 件 2 域门关	R1
rectification-decision-authority	invariant 2	事件 [0,2,3] × 领域 [0,1,2]	事件 [0,2,3,4] × 领域 [0,1,2,3]，3 件 2 域也必须挡	R1（测试更严）
rectification-eight-method	three dated events with one holdout…	holdoutCount=0	1（补第 4 件，训练仍 3）	R1
rectification-occupation-dated-answer	raises the training gate by one career event	训练 2 → 3	训练 + 留出 = 改前 + 1，holdout=1	R1 按训练 + 留出计
rectification-probe-pool-exhausted	T4 标题	「对照了 4 件经历」	「对照了 5 件经历」	夹具多一件第 3 域经历
rectification-collect-stall	revision 5…	holdout e-rel-start	holdout e-finance、e-rel-start 断言为训练	夹具补第 3 域后单件域被留出
rectification-block-scan	题名 three dated events in two domains…	—	four dated events in three domains（断言不变）	R1
tests/test_rectification_confirmation_and.py	four events two domains（改名 neither selects nor proposes）	selection_allowed=True	False，domain_diversity 不过、minimum 3	R1
tests/test_rectification_relative_support.py、test_rectification_v5_services.py	policy 版本	v3	v4	R1
tests/test_rectification_engine_memoization.py	当前 golden	v2	v3（v2 冻结 + 分数相等测试）	R1 回执变

其余 23 个前端文件只改夹具（补第 4 件 / 第 3 域，保持原场景），每处带「R1（BUG-1193）」注释；没有删断言。

生时校正评测（v5 77 例）

• python3 scripts/research/holdout_v5_baseline.py --dataset v5 --out-dir <dir>，改前在 origin/staging 677d40f9 一次性 worktree、改后在本分支 917e18a0 一次性 worktree（引擎与 R1 全部改动之后）各跑一次：sweep / cluster_width / futile_collect 三段 JSON 逐字节相同（只差耗时），数字与第四轮 a18f8d4e 相同。

指标（v5 77 例）	±10	±30	±60
先验头名 前 / 后	0.1818 / 0.1818	0.0909 / 0.0909	0.0779 / 0.0779
六题回放头名 前 / 后	0.6364 / 0.6364	0.4935 / 0.4935	0.3117 / 0.3117
线上区间回放头名 前 / 后	0.6623 / 0.6623	0.5584 / 0.5584	0.4026 / 0.4026
覆盖 前 / 后	0.987 / 0.987	0.987 / 0.987	0.987 / 0.987
中位宽度（线上回放）前 / 后	13 / 13	33 / 33	65 / 65

红线（任一格下降 > 1 pp）未触发。

• R1 对交付的影响：评测按每例全部经历打分，不经过交付门，所以数字不随 R1 变。按数据集本身核算：77 例每例都有 ≥ 7 件、≥ 4 个领域的主经历，给全经历时 0 / 77 被 4 件 3 域挡住。若按经历发生先后逐件说出：旧门槛 3 件 2 域中位在第 3 件达到，新门槛中位在第 4 件；55 例只需多说 1 件，12 例多 2 件，2 例多 3 件，8 例要多 4–7 件（前几件集中在一两个领域，第 3 个领域出现得晚）。
• 另：77 例 score_candidates A/B（±10、冻结日期）逐分相同；reported offset 900 例 0 例变化、sealed holdout 20 例逐条相同（见重新冻结提交）。

普通对话 golden 与回测

• consult-evidence-card-golden.json、consult-biography-backtest-golden.json 用 capture 脚本各跑两次（PYTHONHASHSEED=0、缓存 TTL 0），逐字节相同。证据卡 golden 与提交版相同；回测 golden 只有齐达内逆行金星不再燃烧（graha drishti 四条路由各一处）。
• 名人回测第七轮：docs/testing/consult-affliction-backtest-20261001.md「改动后（第七轮，上游同步五）」。72 + 14 份全部读完。事业类型冲突 9 → 13 / 18（8 位名人卡未变，属模型波动）；父母严重冲突 0、禁句 0、纠正追问 8 / 8、事业追问 6 / 6；对照组轻度误报 6 → 8、读反 2 → 5（都在健康开场）、1 份全篇两处请求。

门禁

项	结果
ruff（门禁清单 5 个文件）、py_compile scripts/*.py jyotish_vedic/*.py mcp_server.py	通过
run_quality_gate.py --profile quick --skip-yoga-logic --skip-frontend-runtime	failures []，exit 0（1,046 passed、1 skipped；在含记录的提交上跑）
隐私扫描 tests/test_repo_privacy_markers.py	通过（R1 改测试时一度把按行号钉住的两处碰撞挤下一行，90dcafe7 修回）
Python 全量（pytest tests -n 4）	63 个失败，全部在开工基线 67 个之内；基线里 5 个（prashna 系列，依赖本机文件）本次通过。新增失败 0
tsc --noEmit	0 错
npm run lint	0 error（126 warnings）
npm test（Node 22）	4,921 项，fail 24、cancelled 0；失败名单与同机 origin/staging 基线逐条相同（基线另有 1 条答题钟计时用例偶发失败）；名字表只少 3 个改名用例（新名字都在）
next build --webpack	/ 仍 ○ Static；首屏 gzip 607,159 B，基线 607,110 B（+49 B，+0.008%）
数据库套件	未跑（无 Docker；本单不改表结构、无迁移）

上游未搬 / 不在本单

• U1 Narayana 默认（见上）。
• 任务书 §2.3 不搬：上游生时校正显式权重 / 行运锚点 / 双轨门、五大人格规则 profile、父母 / 事业盲测与现实校准合同。
• U7 同一 hunk 里上游其它卡片闸门字段（来自别的提交）。
• U4 两个函数不接入任何输出（上游同样未接）。

遗留 / 待产品

1. R1 计数口径：刚好 4 件 3 域时打分常只用 2 域 3 件（holdout 留走单件域）。是否要求训练件也 3 域。
2. acceptanceGateNarration（user-copy.ts）只 import 未调用，insufficientEventsGate / insufficientDomainsGate 两句仍写「再来一件」，属死代码；按「多余入口宁可删」可另开小单删除。
3. report-reader-main-fictional*.json 两份前端 fixture 是历史引擎输出，仍含「母亲早逝」；下次重采报告 fixture 时自然消失。
4. 名人回测事业类型冲突仍远高于通过线（13 / 18），需提示词或卡片单处理。
5. 真机：部署后在 staging 新建一次校正，只说 3 件（2 个方面），确认不出时间卡且提示写「还差……」；补到 4 件 3 个方面后出选择题 / 卡。历史校正记录能从列表打开。