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`。