Jyotisha/docs/tasks/TASK-upstream-sync-fix-20260903.md

任务书 · 上游同步修复单：全域咨询合同回归、finance 严格证据口径变化、模板注册表缺引用、门禁覆盖（2026-09-03）

基线：origin/staging @ c1e3f32a（含上游同步任务 0 / 1 / 2 / 4 / 6：45d13258、f2241463、734d2059，以及整备修复单 027e4b08、c1e3f32a）。分支 codex/upstream-sync-fix-20260903。BUG 编号开工时以 docs/BUG_HISTORY.md 最大号 +1 为准（staging 现最大 BUG-513）。

这是 TASK-upstream-sync-20260903.md 任务 0 / 1 / 2 / 4 / 6 的验收修复单。任务 3 / 5 / 7 尚未开工，不在本单。

---

验收实证（2026-09-03，独立工作树 c1e3f32a，CI 同款依赖：hypothesis、mcp 1.29）

通过的部分

• 任务 0：references/cross_project_contract/imports/commit-a6f47abd….json 与镜像 SKILL.md 就位；tests/test_consultation_contract_golden.py、test_upstream_git_import_a6f47abd.py、test_import_yinduzhanxing.py、test_upstream_import_plan.py 绿；两份隐私扫描 pass: 0 findings；产品代码里 grep "14:49\|1993-04-17" 为空。
• 任务 1：注册表 116 项，README 徽章 116 / 79 / 8 / 0 与之一致；test_readme_badges、test_capability_evidence_pool、test_commercial_skill_truth_contract 绿；6.9.15 版本目录新增、6.9.14 未动。
• 任务 2 / 6 的产品路径端到端（本地起 API，虚构盘 2000-01-01 12:00 UTC 0/0，career）：传 lahiri → Moon Swati，传 raman → Vishakha，回执里所有 ayanamsa* 标签与请求一致（含 Gulika）；响应顶层已有 timing_narrative / module_execution_audit / pratyantar_dasha_timeline / planetary_friendship。jyotish_api_server.py 11143 行 ≤ 上限 11363。
• 任务 4：tests/test_vedastro_rest_bridge.py 绿；默认 payload 不含 14:49。
• 前端：tsc 0 错、lint 0 error、全量 2575 pass / 25 fail / 10 skipped，25 条全是 Docker / rsync / YAML / Playwright 环境项，class-name-definition-contract 已绿。
• 全量 Python 跑完 git status --short 为空（整备修复单任务 4 达标）。

没过的部分

全量 Python（--continue-on-collection-errors）：c1e3f32a 90 红 / 0 收集错误，对比 01a45363（整备合入点）73 红。17 条新红全部由上游同步引入，且这些文件都不在 run_quality_gate.py --profile quick 的 CORE 列表里，所以执行方的 "quick 门 503 passed" 与 staging 门禁都没拦住。

P1 · 全域咨询合同：非原生主题从 degraded 变成 blocked（734d2059，任务 6）

• tests/test_consultation_workflow_domains.py::test_complete_consultation_workflow_handles_every_canonical_domain[*] 6 条红：general / timing / family / education / migration / annual 的 thematic_report.themes[<domain>].status 现为 blocked，合同要求 degraded 且 adapter.upstream_contract_available is True。f2241463 上该测试绿，734d2059 起红。
• 机制：scripts/report_orchestrator.py:129 runtime_status = "degraded" if normalized_evidence or upstream_contract_available else "blocked"；任务 6 在 _compute_consultation_workflow 里 attach_merged_engine_fields(chart, …) 之后执行 chart['ai_prompt_pack'] = handler._build_chart_prompt_pack(chart)，把原有 ai_prompt_pack.evidence_snapshot（含 strict_workflow_contracts）整体重建丢掉，upstream_contract_available 随之为假。
• 产品影响待执行方用真实请求确认：对 timing / general 主题发一次 /api/consultation_workflow，看 thematic_report.themes[<domain>].status 与前端报告中心对 blocked 的处理（是否直接不出内容）。

P1 · finance 严格证据口径变了，且没有记录（45d13258 / f2241463，任务 1 / 2）

tests/test_mcp_strict_workflow_finance.py 从 1 红（01a45363，存量）变 10 红；tests/test_vedastro_external_technique_evidence.py 从 3 红变 4 红。原因不是环境：

现象	代码	性质
_derive_yogi_wealth_support 强钩子变 weak；avayogi 判定翻转	mcp_server.py 合并时把 Yogi 点从 Sun+Moon 改为 Sun+Moon+93°20′、Avayogi 改为 Yogi+186°40′（formula_profile: pyjhora_yogi_sphuta_v1）	上游的计算正确性修正（Yogi Sphuta 标准公式），但 PROGRESS 的 mcp 冲突表没有列出这一块，等于按硬红线 5(ii) 取了 theirs 却没写取舍
confidence_cap 从 medium-high 变 low（完整 Shadbala 分量的用例）	_collect_strict_evidence finance 分支	疑似真回归：完整分量却降到 low，需定位是哪个新检查把它压下去
d11_rudramsa 出现在 used techniques 首位，wealth_promise_strength 后移	_collect_strict_evidence 新增 "d11_rudramsa": _safe_get(modules, "varga_full", "D11_Rudramsa")	新增证据项本身合理，但顺序/断言未同步，且 d11_rudramsa 未在 PROGRESS 列出

这些直接影响聊天财富主题的置信度上限与技法审计表，属于任务书硬红线 4 "咨询响应契约不得变形" 的范围：golden 只锁键路径和类型，锁不住值，所以没拦住。

P2 · 解读模板注册表校验失败（f2241463，任务 2 快进了 interpretation_template_registry.json +145 行）

scripts/validate_interpretation_templates.py → valid: false, problem_count: 4：dual_luminary_timing_context / seventh_house_topic_split / empty_window_not_success / dasha_boundary_not_event_date 四个模板引用 references/mevg_chinese_full_layer_and_practice_audit_2026_08_26.md，本仓没有这个文件。tests/test_interpretation_template_registry.py 红。个人报告写作用这份注册表。

P2 · staging 部署链自 591ffd21 起没有成功过

Gitea 运行记录（本机只读 API）：

运行	SHA	结果	我的判断
validate	01a45363	failure	门禁跑 npm test，当时 class-name-definition-contract 红
validate	734d2059	failure	同上
validate / publish	027e4b08	success	类名修复后
deploy	027e4b08	failure	原因看不到，需要仓库所有者贴日志
migrate	c1e3f32a	failure	同上；20260903010000_profile_ayanamsa.sql 的 grant update (ayanamsa) … to authenticated 与其它 26 份迁移写法一致，角色由 deploy/postgres/001 / 002 保证，不像是它
validate	c1e3f32a	running（验收时）	—

staging health 仍是 591ffd21。整备的岁差设置、上游合并的所有东西，线上一个都还没落地。这条不归执行方修代码，归产品负责人先把 actions/runs/2358（deploy）与 2360（migrate）失败步骤的最后 30 行贴出来。

---

决策记录

1. Yogi / Avayogi 公式改为 PyJHora Yogi Sphuta 标准式：接受（PM 判断：Sun+Moon 漏了 93°20′ 的 Pushya 起点常量，旧值是错的）。产品负责人若不同意，改回 ours 并在 PROGRESS 写明。
2. d11_rudramsa 进入 finance 证据：接受，但顺序规则要写明（wealth_promise_strength 仍是主判据，分盘只作支持项）。
3. confidence_cap 从 medium-high 掉到 low：不接受，视为回归，找到根因修回。
4. 本单把 tests/test_consultation_workflow_domains.py、tests/test_mcp_strict_workflow_finance.py、tests/test_interpretation_template_registry.py、tests/test_vedastro_external_technique_evidence.py 加进 run_quality_gate.py 的 CORE 列表；quick 门时长增加写进 PROGRESS。
5. 上游同步任务 3 / 5 / 7 在本单合入之前不得开工（它们都建立在任务 6 的透传路径上）。

硬红线

1. 不改 golden 的键路径来迁就；不删 strict_workflow_contracts；report_orchestrator.py:129 的判定规则不动。
2. 改断言必须三栏（原值 / 新值 / 原因），且只允许在决策记录 1、2 覆盖的范围内改；决策 3 对应的断言不得改。
3. jyotish_api_server.py 行数不增长；不动校正；不动数据库；不改 workflow。
4. 不为了让模板注册表通过而删模板；缺的引用文档要么从上游镜像目录以只读快照方式带入（先过两份隐私扫描），要么把 source_refs 指向本仓已有文档并在 PROGRESS 说明。

任务分解

任务 1（P1）· 恢复非原生主题的 degraded 合同

1. _compute_consultation_workflow：重建 ai_prompt_pack 时保留原 evidence_snapshot 里已有的键（尤其 strict_workflow_contracts），或者只把新字段合并进现有 pack，不整体替换。
2. 验收：tests/test_consultation_workflow_domains.py 12 条全绿；真实请求 timing / general 的 thematic_report.themes[*].status 为 degraded，upstream_contract_available 为真；career / marriage / wealth / health 仍 supported。

任务 2（P1）· finance 严格证据

1. 按决策记录 1、2 更新 tests/test_mcp_strict_workflow_finance.py 与 tests/test_vedastro_external_technique_evidence.py 的相关断言（三栏）。
2. 定位 confidence_cap 降到 low 的检查并修回；该用例断言不改。
3. CHANGELOG.md 新条目写明 Yogi Sphuta 公式修正与 D11 支持项；docs/BUG_HISTORY.md 记 confidence_cap 回归。
4. 验收：两个测试文件红数回到 01a45363 基线（1 条存量 attaches_existing_interpretation_source_pack 与 3 条 vedastro 存量）或更少；存量红逐条写 BLOCKED 或修掉。

任务 3（P2）· 模板注册表引用

按硬红线 4 二选一；验收 scripts/validate_interpretation_templates.py → valid: true, problem_count: 0，测试绿。

任务 4（P2）· 门禁覆盖

按决策记录 4 扩 CORE 列表；run_quality_gate.py --profile quick 本地退出 0；tests/test_api_server_growth_contract.py::test_quality_gate_runs_api_server_growth_contract 类的守护测试仍绿。

任务 5（产品负责人）· 部署链

贴出 deploy 2358 与 migrate 2360 的失败日志；执行方据此另开修复或在本单追加。在 health gitCommit 前进到含岁差设置的 SHA 之前，docs/testing/ 的岁差实测不能做。

交付物

docs/tasks/PROGRESS-upstream-sync-fix-20260903.md；状态板本单一行；做不了的写 BLOCKED.md。