Jesse_ChenandClaude Fable 5.1
74aaa1ba99
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0193vBv6w5MV2cifdTUu9H5P
231 lines
24 KiB
Markdown
231 lines
24 KiB
Markdown
# 任务书 · 仓库整备与 main 提升前置：岁差默认 Raman 且用户可选、发布门可跑、地址/日志/分支清理（2026-09-03）
|
||
|
||
基线：`origin/staging` @ `d159f08e`（校正会话面重做 `codex/rectification-ux-20260903` 已合入）。分支 `codex/repo-hygiene-20260903`。BUG 编号从 **510** 起（staging 当前最大 BUG-509；开工再 `grep -oE '^## BUG-[0-9]+' docs/BUG_HISTORY.md | sort -t- -k2 -n | tail -1` 核对）。
|
||
|
||
本任务书是 2026-09-03 产品审查决定的"仓库小活"，但调查时发现任务 0 不是小活：它决定 `main` 能不能提升。**任务 0 单独先做、先推、先验收**，任务 1–5 随后。
|
||
|
||
---
|
||
|
||
## 为什么要做（事故实证）
|
||
|
||
### A. 默认岁差（ayanamsa）在 staging 上从 Lahiri 变成了 Raman，公开真实案例复验因此失效（P0）
|
||
|
||
- 来源：`80102459`（2026-08-20，`feat(product): present consult and rectification in local skill form`，Cursor 执行）把 `scripts/ayanamsa_utils.py` 的 `ACTIVE_AYANAMSA_NAME = 'lahiri'` 改为 `DEFAULT_AYANAMSA_NAME = 'raman'`，并把 `scripts/jyotish_engine.py` 全部 `default='lahiri'` 改成 `DEFAULT_AYANAMSA_NAME`；前端 `birth-time-journey-assessment.ts:28,40`、`global-birth-payloads.ts:49` 同步硬编码 `"raman"`。提交信息只有一句 "Default ayanamsa to Raman with true_pushya support"，`CHANGELOG.md` 与 `docs/BUG_HISTORY.md` 均无记录。
|
||
- 影响量化（同一台机器、同一 `.venv`，只换 checkout）：
|
||
|
||
| 检查 | 生产 `7b620c7a`（Lahiri） | staging `8e214e29`（Raman） |
|
||
| --- | --- | --- |
|
||
| `tests/run_real_case_revalidation.py` `valid` | true | **false** |
|
||
| `pass_rate`（门槛 0.98） | 1.0 | **0.9394** |
|
||
| `gated_passed / gated_total` | 66 / 66 | **62 / 66** |
|
||
| 虚构盘 2000-01-01 12:00 UTC (0,0) Moon nakshatra | Swati | Vishakha |
|
||
| 同盘 Vimshottari 首段 | Rahu 余运 → Jupiter 2000-09-20～2016-09-20 | Jupiter 余运 1998-11-27～2014-11-27 |
|
||
| `tests/test_user_invocation_acceptance_contract.py::test_fixture_dasha_timeline_rejects_workbuddy_regression_claims` | 通过 | **失败** |
|
||
|
||
两套岁差相差约 1°26′，Moon 落在 nakshatra 边界附近的盘会整段大运换主；公开案例复验的参考值来自 Lahiri 口径的公开来源，而 `tests/run_real_case_revalidation.py:64` 调用 `jyotish_engine.py` 时**没有显式传 `--ayanamsa`**，跟着默认走，所以门槛从满分掉到 0.94。`run_quality_gate.py --profile release` 包含真实案例复验（`skip_real_cases: False`），也就是说**现在的 staging 过不了发布门**，`main` 无法提升。根因不是 Raman 本身，而是：参考集对照没有锁定自己的口径；产品没有把岁差作为用户可见、可选的设置；三处标签与实际计算不一致。
|
||
|
||
- 一致性问题（无论默认取哪个都要修）：`scripts/jyotish_api_server.py:2853` 与 `:4017` 把 `ayanamsa_policy` 兜底成字面量 `'lahiri'` 交给 VedAstro 适配器，`:7030` 把返回体里的 `'ayanamsa'` 写死 `'lahiri'`，而本地引擎按 `DEFAULT_AYANAMSA_NAME` 算——本地与 VedAstro 对照用的不是同一套岁差，且证据包标签可能与真实计算不一致。`:7086` 的 `ayanamsa_display` 又兜底 `'Raman'`。
|
||
|
||
### B. 技法注册表新 entry_type 没进白名单
|
||
|
||
`references/technique_registry.json` 的 `rangacharya_jaimini_variant` 用了 `entry_type: "experimental_variant"`、`evidence_role: "comparison_only"`，`tests/test_capability_evidence_pool.py::test_registry_is_backend_evidence_pool_not_flat_user_skill_list` 的白名单没有这两个值 → 常红。`scripts/capability_evidence_pool.py` 对未知 role 既不计入 `audit_only_entries` 也不报错。
|
||
|
||
### C. 仓库地址还是旧研究仓
|
||
|
||
`pyproject.toml:54-58`、`.codex-plugin/plugin.json:7,9,10,39`、根 `SKILL.md:4` 的 description、`scripts/skill_release_package.py:27`、`scripts/skill_release_manifest.py:15`、`skills/jyotish-engine-modules/SKILL.md:67` 都指向 `https://github.com/732642856/yinduzhanxing`。这是**上游研究仓**，不是本产品仓。`tests/test_skill_release_package.py:59`、`tests/test_skill_release_manifest.py:16` 锁着旧地址。`scripts/remote_repo_visibility_check.py:22` 在 remote 不是 GitHub 时退回这个旧 slug 做可见性检查，而本仓 origin 是 Gitea。
|
||
|
||
### D. 根目录还剩四份早期实现日志
|
||
|
||
`progress.md`（209 KB）、`findings.md`、`task_plan.md`、`CHANGELOG_v6.2_to_v6.9.md`。`scripts/run_quality_gate.py:125,126,137` 的 `RELEASE_CRITICAL_UNTRACKED_PATHS` 锁着前三个路径，所以 09-03 的文档轮没能搬。
|
||
|
||
### E. 远端 70 条分支，66 条已完全合入 staging
|
||
|
||
`git branch -r --merged origin/staging` 的结果见任务 5。未合入的只有 4 条。
|
||
|
||
### F. 本地环境与 CI 依赖不一致，全量 pytest 在本地无法收集
|
||
|
||
本地 `.venv` 装的是 `mcp 2.1.1`（`requirements.txt` 钉 `mcp>=1.0,<2`）且没装 `hypothesis` → 13 个测试模块收集失败（`test_mcp_strict_workflow_*`、`test_varga_bphs`、`test_historical_event_backtest` 等）。`scripts/user_invocation_acceptance_check.py` 因 PyJHora `missing_dependency` 输出 `status: fail`，对应测试红；`requirements-reference-engines.txt` 不在任何 workflow 的安装步骤里。这些不是代码 bug，但发布门要的是"一条命令本地可复现 CI 结论"。
|
||
|
||
---
|
||
|
||
## 决策记录（产品授权，2026-09-03）
|
||
|
||
1. 产品已同意：每周提升一次 `main`；仓库小活交 coding agent；删除已合入的远端分支。
|
||
2. **产品负责人 2026-09-03 拍板：默认岁差保持 Raman，并在用户设置里可选。** 可选值 `raman`（默认）/ `lahiri` / `kp` / `true_pushya`，与 Python `AYANAMSA_MODES` 一致。PM 曾建议回 Lahiri（理由：公开来源与既有 benchmark 都按 Lahiri 校准；生产用户此前看到的是 Lahiri 盘），产品明确否决；因此本轮的原则改为：**产品计算用用户设置（默认 Raman），参考集与外部对照各自显式锁定口径，任何地方不再依赖"默认值恰好是什么"**。提升 `main` 后生产用户的 Moon nakshatra / 大运可能相对旧版变化，这是产品已知并接受的后果，CHANGELOG 必须写明并告诉用户可在设置里切回 Lahiri。
|
||
3. 本任务书**不改**任何被哈希锁定的 `skills/*/versions/**`，也不改指向上游研究仓的 `references/cross_project_contract/**`、`references/upstream/**`、`tests/test_import_yinduzhanxing.py`、`tests/test_upstream_import_plan.py`——那些地址是导入来源的真实记录。
|
||
4. `progress.md` / `findings.md` / `task_plan.md` 的"发布关键文件必须已跟踪"检查保留，只改路径。
|
||
|
||
---
|
||
|
||
## 硬红线
|
||
|
||
1. 任务 0 不得通过改期望值让测试变绿：`test_fixture_dasha_timeline_rejects_workbuddy_regression_claims` 的日期、`tests/run_real_case_revalidation.py` 的参考值、`references/**` 的 oracle 目标值一律不动；让它们变绿的唯一合法手段是**显式传参口径**（`--ayanamsa lahiri`），并在三栏说明里写清"原来依赖默认值"。
|
||
2. 不得在同一轮里改校正引擎的打分/阈值；`DEFAULT_AYANAMSA_NAME` 本轮**不改**（保持 `raman`）。
|
||
3. `scripts/jyotish_api_server.py` 行数不得增长（`tests/test_api_server_growth_contract.py`）；一致性修复是改字面量为常量，不是加逻辑。
|
||
4. 分支删除只删任务 5 列出的已合入名单；4 条未合入分支不删；本地 worktree 正在使用的分支（`codex/unified-loading-20260902`、`codex/frontend-optimization-20260828`、`codex/streaming-ux-20260901`）远端可删、本地不动。
|
||
5. 不改 `.gitea/workflows/**` 的触发条件；给发布门补依赖只允许改 `requirements-dev.txt` / `requirements.txt` 与 workflow 的 `pip install` 行。
|
||
6. `npm run lint` 0 error、`tsc --noEmit` 通过、测试总数不低于开工基线；无 Docker 的失败清单与基线逐条比对。
|
||
7. 不在脏工作树切分支；不自行提升 `main`。
|
||
|
||
让步顺序：功能与测试不回归 > 发布门本地可复现 > 岁差一致性 > 地址/日志/分支整洁。
|
||
|
||
---
|
||
|
||
## 开工前置
|
||
|
||
```bash
|
||
git fetch origin --prune
|
||
git worktree add -b codex/repo-hygiene-20260903 ../.worktrees/repo-hygiene-20260903 origin/staging
|
||
# CI 同款依赖（本地复现发布门）
|
||
.venv/bin/python -m pip install -r requirements.txt -r requirements-dev.txt
|
||
.venv/bin/python -m pip show mcp | grep Version # 必须 1.x
|
||
```
|
||
|
||
先读：`AGENTS.md` §2/§3/§5/§9、`docs/research/pre_work_error_ledger.md`（本轮碰引擎默认值与远端分支，§9 预检必跑）、`scripts/ayanamsa_utils.py` 全文、`git show 80102459 --stat`、`scripts/run_quality_gate.py` 的 profile 表。
|
||
|
||
---
|
||
|
||
## 任务分解
|
||
|
||
### 任务 0（P0，单独先推）· 岁差成为用户设置（默认 Raman），参考集显式锁口径，"算的"和"写的"一致
|
||
|
||
**0.a 参考集与外部对照显式锁定口径（先做，这一步单独就能让发布门变绿）**
|
||
|
||
1. `tests/run_real_case_revalidation.py:64` 的 `jyotish_engine.py` 调用显式加 `--ayanamsa lahiri`（参考值来自 Lahiri 口径的公开来源），报告 JSON 增加 `reference_ayanamsa: "lahiri"` 字段；`scripts/local_accuracy_report.py` 同理。
|
||
2. `tests/test_user_invocation_acceptance_contract.py::test_fixture_dasha_timeline_rejects_workbuddy_regression_claims` 的 `base` 命令显式加 `--ayanamsa lahiri`（三栏说明：原值＝依赖默认、新值＝显式 lahiri、原因＝夹具日期是 Lahiri 口径）；期望日期一字不改。
|
||
3. VedAstro / oracle 对照：`scripts/jyotish_api_server.py:2853`、`:4017` 的 `ayanamsa_policy` 不再兜底字面量 `'lahiri'`，改为**该次请求实际使用的岁差名**，让本地与 VedAstro 对照同口径；`references/oracle/**` 的目标值不动（它们各自的 `ayanamsa` 元数据字段就是口径）。
|
||
4. 验收：`tests/run_real_case_revalidation.py` → `valid: true`、`gated 66/66`、`pass_rate ≥ 0.98`；上述夹具测试通过；`scripts/user_invocation_acceptance_check.py` 的 `checks.user_invocation_tests: true`。
|
||
|
||
**0.b 标签与实际计算一致**
|
||
|
||
5. `scripts/jyotish_api_server.py:7030` 的 `'ayanamsa': 'lahiri'` 改为实际值；`:7086` 的 `ayanamsa_display` 从实际名派生（`AYANAMSA_LABELS` 或等价映射），不再兜底 `'Raman'`。所有回执（`/api/consultation_workflow`、`/api/chart`、校正、报告证据包）必须带 `ayanamsa` 实际名，前端只显示回执，不得自己猜。
|
||
6. 验收：`grep -rn "'lahiri'\|\"lahiri\"\|'raman'\|\"raman\"" scripts/jyotish_api_server.py frontend/src --include=*.py --include=*.ts --include=*.tsx | grep -v test` 只剩常量定义、标签映射与设置选项，没有散落的兜底字面量。
|
||
|
||
**0.c 用户设置：账户与出生资料面板里可选岁差**
|
||
|
||
7. 数据：`profiles` 加 `ayanamsa` 列（Drizzle 迁移，`frontend/db/migrations/`；`text not null default 'raman'`，check 约束四个值）。这是本轮唯一的动表，`npm run test:db` 必须真跑（AGENTS §7.6）。
|
||
8. 接口：`/api/account` 读写该字段；服务端校验只接受四个值；未登录/旧客户端不带字段时按 `raman`。
|
||
9. 界面：「账户与出生资料」面板加一个单选（Raman【默认】/ Lahiri / KP / True Pushya），每项一句话说明（文案先对 `frontend/docs/VOICE.md`），下方一行提示"切换只影响之后的新计算；已生成的报告和校正结果保持当时的口径"。`frontend/DESIGN.md` 同提交更新。
|
||
10. 贯通：`frontend/src/lib/global-birth-payloads.ts:49`、`birth-time-journey-assessment.ts:28,40` 及 `80102459` 触及的其余前端文件（`consult/route.ts`、`birth-time-journey-service.ts`、`personal-report-generation.ts`、`consultation-technique-audit.ts`）不再硬编码，统一从一个导出 `resolveAyanamsa(profile)`（新建 `frontend/src/lib/ayanamsa.ts`，类型 `"raman" | "lahiri" | "kp" | "true_pushya"`，默认常量 `DEFAULT_AYANAMSA = "raman"`）取值；咨询、校正、报告、星盘库、每日星语全部把它传给 Python。
|
||
11. 已有数据：校正案例与已生成报告记录创建时的岁差（若表里没有字段，本轮只在新写入的 JSON 载荷里带 `ayanamsa`，不追加第二个迁移）；切换设置不重算历史。校正引擎（`frontend/src/lib/rectification-agentic/v9/**`、`scripts/active_rectification_*.py`）里若有按 Raman 校准的阈值或 golden，本轮**不动**，只确认它们在 `lahiri` 下不会崩（跑一遍 `tests/rectification-*.test.ts`），异常写 BLOCKED。
|
||
12. 验收：
|
||
- 设置切到 Lahiri 后，用附录那张虚构盘（2000-01-01 12:00 UTC，0/0）发一次咨询：回执 `ayanamsa = lahiri`、Moon nakshatra = Swati；切回 Raman：`ayanamsa = raman`、Vishakha。技法审计表与星盘头显示的岁差与回执一致。
|
||
- `tsc` 0 错、`npm run lint` 0 error、`npm run test:db` 通过、相关前端套件 fail=0；`page.tsx` 行数不增长。
|
||
- 产品负责人在 staging 部署后按上面两步实测一次。
|
||
|
||
**0.d 记录**
|
||
|
||
13. `CHANGELOG.md` 新条目：默认岁差自 `80102459`（2026-08-20）起为 Raman，本轮补齐用户设置与四个可选值，说明升级后老用户可能看到 Moon nakshatra / 大运变化并可在设置切回 Lahiri。`docs/BUG_HISTORY.md` 新增 BUG（现象＝公开案例复验 `valid=false` 与三处标签不一致、根因＝参考集未锁口径 + 字面量兜底、修复＝0.a/0.b、关联记录＝无、复发自＝无）。
|
||
|
||
### 任务 1（P0）· 发布门一条命令本地可复现
|
||
|
||
1. 依赖：`requirements-dev.txt` 已有 `hypothesis`；确认 `mcp>=1.0,<2` 在 `requirements.txt` 生效（本地 `.venv` 装错版本是环境问题，写进 PROGRESS 的"环境备忘"即可，不改 pin）。
|
||
2. `scripts/user_invocation_acceptance_check.py`：PyJHora 缺失时 `status` 现为 `fail`。改法二选一并写明：(a) 在 workflow 安装 `requirements-reference-engines.txt`（注意 AGPL 隔离说明，只装在门禁 runner，不进镜像）；(b) 让 `missing_dependency` 归入 `partial` 且 `test_one_command_user_invocation_acceptance_check` 的断言 `report["status"] == "pass"` 按三栏说明改为接受 `partial`，同时 `external_adapter_status` 仍必须在 `{"pass","partial","complete"}`。建议 (b)：PyJHora 是外部参照引擎，缺席应降级不应失败。
|
||
3. 用 CI 同款依赖跑 `python -m pytest -q --maxfail=1`（发布门原命令）与 `.venv/bin/python scripts/run_quality_gate.py --profile release`，把每一条红按"代码 bug / 环境 / 参考值过期"分类写进 PROGRESS，代码 bug 的修在本轮内，环境类给出复现命令，参考值过期的**不改值、写 BLOCKED**。起点数据见附录。
|
||
4. 测试不得改写仓库文件：本地全量跑一遍后 `git status` 出现 12 个 `docs/research/character_level_*_latest.*` 与 2 个 `references/oracle/*_2026_07_2x.json` 被改写（`scripts/character_level_inventory_manifest.py:27-30` 等把"latest"报告直接写进仓库路径）。让这些脚本在测试里写 `tmp_path`，或测试用只读模式；验收标准是全量 pytest 后 `git status --short` 为空。
|
||
5. 验收：release profile 本地退出 0；PROGRESS 里有全量红名单处理表；`docs/tasks/README.md` 状态板"已合入 / 待核对"各行不受影响。
|
||
|
||
### 任务 2（P1）· 注册表 `experimental_variant`
|
||
|
||
1. `tests/test_capability_evidence_pool.py` 白名单加 `experimental_variant`（entry_type）与 `comparison_only`（evidence_role）；`scripts/capability_evidence_pool.py` 把 `comparison_only` 计入 `audit_only_entries` 同等处理（不能影响结论），summary 增加 `comparison_only_entries`。
|
||
2. 加一条断言：所有 `entry_type == "experimental_variant"` 的条目 `verification_level.prediction` 与 `.rule` 必须是 `blocked`，`user_visibility` 必须是 `expert_audit`。
|
||
3. 验收：该测试文件全绿；`scripts/audit_capabilities.py --mode validate` 仍 `valid=true, problem_count=0`。
|
||
|
||
### 任务 3（P1）· 仓库地址
|
||
|
||
1. 改：`pyproject.toml` 五个 URL（Homepage/Repository/Changelog → `https://git.copse.top/root/Jyotisha`，Bug Reports → `https://git.copse.top/root/Jyotisha/issues`，Documentation → 仓内 `README.md` 的 Gitea 链接）；`.codex-plugin/plugin.json` 四处；根 `SKILL.md:4` description 里的 `GitHub:` 改为 `Repo: https://git.copse.top/root/Jyotisha`；`scripts/skill_release_package.py:27`、`scripts/skill_release_manifest.py:15`、`skills/jyotish-engine-modules/SKILL.md:67`。
|
||
2. `tests/test_skill_release_package.py:59`、`tests/test_skill_release_manifest.py:16` 同步（三栏说明）。
|
||
3. `scripts/remote_repo_visibility_check.py`：remote 不是 GitHub 时不再退回旧 slug，改为报告 `provider: gitea` 并用 `git ls-remote` 验证可达；`tests/test_remote_repo_visibility_check.py` 的 slug 解析用例不动，新增一条 Gitea remote 用例。
|
||
4. 验收：`grep -rn '732642856/yinduzhanxing' --include=*.py --include=*.toml --include=*.json --include=*.md . | grep -v 'references/\|skills/.*/versions/\|docs/\|progress.md\|findings.md\|tests/test_import_yinduzhanxing\|tests/test_upstream_import_plan\|tests/test_project_fragment_governance'` 为空；`python3 scripts/pre_work_check.py --remote-timeout 8 --command-timeout 45` 不因 slug 误报 blocked。
|
||
|
||
### 任务 4（P2）· 早期日志搬家
|
||
|
||
1. `git mv progress.md findings.md task_plan.md CHANGELOG_v6.2_to_v6.9.md docs/history/`，新建 `docs/history/README.md` 一段说明（"2026-06～08 的实现日志，不是运行说明"）。
|
||
2. `scripts/run_quality_gate.py` `RELEASE_CRITICAL_UNTRACKED_PATHS` 三个路径改为 `docs/history/...`；根 `README.md` 文档地图与 `AGENTS.md` §4 最后一行同步。
|
||
3. 验收：`run_quality_gate.py --profile release` 的"关键文件已跟踪"检查通过；根目录 `ls *.md` 只剩 `AGENTS.md BLOCKED.md CHANGELOG.md CLAUDE.md CONTEXT.md README.md SKILL.md`（`COVERAGE_AUDIT_REPORT.md` 在 .gitignore，不算）。
|
||
|
||
### 任务 5（P2）· 远端分支清理
|
||
|
||
已完全合入 `origin/staging` 的 66 条，一次删除（先 `git fetch origin --prune` 再核对 `git branch -r --merged origin/staging` 与下表一致，多出或少了的写 PROGRESS）：
|
||
|
||
```text
|
||
codex/admin-account-reset codex/agent-voice-20260901 codex/agentic-consultation-runtime
|
||
codex/consultation-birth-accuracy-20260901 codex/fix-daily-starlanguage-guard-20260818
|
||
codex/fix-feature-flag-admin-runtime-policy-20260811 codex/fix-gitea-artifact-upload-20260805
|
||
codex/fix-gitea-manifest-auth-20260805 codex/fix-local-artifact-inputs-20260805
|
||
codex/fix-rectification-case-context-20260811 codex/fix-rectification-current-turn-binding-20260812
|
||
codex/fix-rectification-duplicate-collect-20260902 codex/fix-rectification-focus-baseline
|
||
codex/fix-rectification-free-settlement-20260811 codex/fix-rectification-history-hydration-20260812
|
||
codex/fix-rectification-home-new-session-20260812 codex/fix-rectification-session-model-20260811
|
||
codex/fix-rectification-turn-projection-20260812 codex/fix-report-scroll-product-admin-20260818
|
||
codex/fix-sidebar-contract-ci-20260820 codex/fix-staging-artifact-resolution-20260805
|
||
codex/fix-vendored-artifact-inputs-20260805 codex/frontend-optimization-20260828
|
||
codex/integrate-github-main-gitea-20260805 codex/internal-gitea-artifact-action-20260805
|
||
codex/pr1-skill-registry codex/pr2-final-response codex/pr3-rectification-v10
|
||
codex/pr4-rectification-event-contract-v2 codex/pr5-report-evidence-bundle-v2
|
||
codex/pr6-report-document-v2 codex/pr7-product-domain-registry codex/pr8-evals-observability
|
||
codex/pr8-local-gate-closure codex/production-selfhosted-migration
|
||
codex/rectification-activity-birth-context-20260812 codex/rectification-p0-p1-20260820
|
||
codex/rectification-provisional-adopt-20260901 codex/rectification-question-in-message-20260902
|
||
codex/rectification-same-turn-confirm-20260812 codex/rectification-tails-20260901
|
||
codex/remove-admin-step-up-20260816 codex/report-blocked-repairs-20260902
|
||
codex/report-writer-failure-20260902 codex/run-vendored-artifact-uploader-20260805
|
||
codex/staging-gate-repair-20260811 codex/staging-skill-style-present-20260820
|
||
codex/streaming-ux-20260901 codex/ui-optimize-staging-20260817 codex/unified-loading-20260902
|
||
codex/use-gitea-artifact-action-20260805 delivery/payment-package-epay
|
||
docs/close-staging-controller-incident docs/close-staging-release-acceptance
|
||
docs/correct-report-smoke docs/personal-report-staging-acceptance
|
||
docs/record-staging-env-owner-drift docs/record-staging-host-key-rotation
|
||
feat/one-way-skill-personal-report fix/staging-admin-verification-host
|
||
fix/staging-controller-fetch-timeout fix/staging-gate-attested-controller
|
||
fix/staging-gate-build-timeout fix/staging-gate-retry-and-admin-audit
|
||
fix/staging-public-verification-race fix/staging-ssh-secret-and-env-owner
|
||
revert/staging-from-main
|
||
```
|
||
|
||
```bash
|
||
git push origin --delete <上表>
|
||
```
|
||
|
||
未合入的 4 条不删，只登记：
|
||
|
||
| 分支 | 最后提交 | 领先 staging | 处置 |
|
||
| --- | --- | --- | --- |
|
||
| `codex/rectification-ux-20260903` | 2026-09-03 | 5 | 进行中（已验收待合入），不动 |
|
||
| `codex/rectification-ux-20260902` | 2026-09-02 | 3 | 被 0903 版替代，等 0903 合入后由产品决定删除 |
|
||
| `codex/diagnose-rectification-request-20260827` | 2026-08-27 | 5 | 8 月诊断分支，产品决定 |
|
||
| `fix/staging-gate-checkout-retry` | 2026-08-06 | 1 | 已被后续门禁修复覆盖的可能性大，产品决定 |
|
||
|
||
验收：`git ls-remote --heads origin | wc -l` 从 71 降到 5（`main`、`staging` 加 3 条保留分支，若 0902 已删则 4）。
|
||
|
||
---
|
||
|
||
## 附录 · 2026-09-03 本地全量 pytest 起点数据
|
||
|
||
环境：同一台机器、同一 `.venv`（缺 `hypothesis`、`mcp` 为 2.1.1、无 PyJHora / Docker）。`python -m pytest -q --continue-on-collection-errors tests`：
|
||
|
||
| 检出 | FAILED | 收集 ERROR |
|
||
| --- | --- | --- |
|
||
| staging `8e214e29` | 89 | 13 |
|
||
| 生产 `7b620c7a`（只跑 staging 红的 54 个文件） | 83 | — |
|
||
|
||
也就是说 89 条红里 **83 条在生产提交上同样红**，属于环境缺依赖或参考值/产物过期，不是这两周的回归；执行方分类时可直接从这 83 条的"环境 / 过期"两类起手，重点核对以下 **6 条 staging 独有的红**：
|
||
|
||
| 测试 | 本地现象 | 初判 |
|
||
| --- | --- | --- |
|
||
| `test_user_invocation_acceptance_contract.py::test_fixture_dasha_timeline_rejects_workbuddy_regression_claims` | Jupiter 段 2014-11-27 ≠ 期望 2016-09-20 | 夹具是 Lahiri 口径却跟着默认 Raman 跑（任务 0.a） |
|
||
| `test_user_invocation_acceptance_contract.py::test_one_command_user_invocation_acceptance_check` | `checks.user_invocation_tests: false` → `status: fail`（`external_adapter_status` 已是 `partial`） | 同上，上一条的连带 |
|
||
| `test_skill_release_clean_trial.py::test_premium_skill_zip_runs_from_clean_directory` | 打包后的 acceptance check 同样 `fail` | 同上，连带 |
|
||
| `test_local_accuracy_report.py`（2 条） | `scripts/local_accuracy_report.py` 抛 SystemExit | 大概率是公开案例复验 `valid=false` 传导，任务 0 完成后复跑；若仍红再单独查 |
|
||
| `test_dynamic_rectification_fact_priority.py::test_historical_event_priority_preserves_vimshottari_actor_difference` | `assert 0.0 > 0`（信息增益为 0） | 依赖 Vimshottari 边界，先在任务 0 之后复跑；仍红则归校正引擎，写 BLOCKED 交产品 |
|
||
| `test_minute_rectification_development.py::test_v3_development_result_stays_shadow_only` | `assert 1 == 0` | 同上 |
|
||
|
||
13 个收集 ERROR 全部是 `No module named 'hypothesis'` 或 `mcp.server.fastmcp`（mcp 2.x），装对依赖即消失。
|
||
|
||
## 交付物
|
||
|
||
- 任务 0 单独一次推送（含 CHANGELOG + BUG_HISTORY），推送后在 PROGRESS 写明 staging 部署 SHA。
|
||
- `docs/tasks/PROGRESS-repo-hygiene-20260903.md`：每个任务的命令输出摘要、全量 pytest 红名单处理表、三栏说明、环境备忘。
|
||
- `docs/tasks/README.md` 状态板：本任务书一行，并把"待开的任务书 · 仓库小活"那行改为指向本文件。
|
||
- 做不了的写 `BLOCKED.md`，不写"通过"。
|