root/Jyotisha
1
0
Fork 0
Code Issues 1 Pull Requests Actions Packages Projects Releases Wiki Activity

docs(tasks): repo-hygiene brief — default ayanamsa back to Lahiri (P0), release gate reproducibility, registry allowlist, repo URLs, history logs, branch cleanup; status board rows

Browse Source 
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0193vBv6w5MV2cifdTUu9H5P
This commit is contained in:
Jesse_Chen
2026-09-03 07:23:08 +00:00
parent d159f08eb2
commit 62e1592001
2 changed files with 221 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/tasks/README.md
+7 -2
View File
@@ -44,7 +44,7 @@
| `TASK-rectification-adopt-flow-20260902.md` | — | 采用流程整治 | 已验收 | `35e5781e`（BUG-497～500） |
| `TASK-rectification-adopt-flow-fix-20260903.md` | — | 采用流程修复单（含删「用这个时间看盘」） | 已验收 | `e8c98c37`（BUG-501/502） |
| `TASK-rectification-uncertainty-stop-20260903.md` | — | 不确定度停止规则加样本下限 | 已验收 | `0c0df426`（BUG-503） |
| `TASK-rectification-ux-20260902.md` | `PROGRESS-rectification-ux-20260903.md` | 会话面空白假死与交互摩擦 | 待合并 | 分支 `codex/rectification-ux-20260903`（09-03 在新基线重做，BUG-505–509，已推送待验收） |
| `TASK-rectification-ux-20260902.md` | `PROGRESS-rectification-ux-20260903.md` | 会话面空白假死与交互摩擦 | 已验收 | `d159f08e`（09-03 在新基线重做后合入，BUG-505～509） |
### 聊天主链路与首页
@@ -85,9 +85,14 @@
| 主题 | 内容 | 状态 |
| --- | --- | --- |
| 仓库小活 | `pyproject.toml` / `SKILL.md` 仓库地址更新；registry `experimental_variant` 让 evidence-pool 测试变绿；三份早期日志移出根目录并改 `run_quality_gate.py`；清理已合入的远端分支 | 待写任务书 |
| staging 测试账号 | 给验收环境一个虚构资料的受控账号，让 API 级端到端验收可做 | 待产品负责人提供 |
### 仓库整备与发布前置
| 任务书 | 进度 | 主题 | 状态 | 落点 |
| --- | --- | --- | --- | --- |
| `TASK-repo-hygiene-20260903.md` | — | 默认岁差回 Lahiri（P0，单独先推）、发布门本地可复现、注册表白名单、仓库地址、早期日志搬家、远端分支清理 | 待领取 | 分支 `codex/repo-hygiene-20260903` |
## 命名与归档
- 文件名：`TASK-<kebab-主题>-<YYYYMMDD>.md`；同主题的修复单加 `-fix`；进度记录同名换前缀。
docs/tasks/TASK-repo-hygiene-20260903.md
+214
View File
@@ -0,0 +1,214 @@
# 任务书 · 仓库整备与 main 提升前置：默认岁差回 Lahiri、发布门可跑、地址/日志/分支清理（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 口径的公开来源，所以门槛从满分掉到 0.94。`run_quality_gate.py --profile release` 包含真实案例复验（`skip_real_cases: False`），也就是说**现在的 staging 过不了发布门**，`main` 无法提升。
- 一致性问题（无论默认取哪个都要修）：`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. **默认岁差回到 Lahiri**（本任务书 PM 决定，理由：Lahiri 是 JHora / VedAstro / 公开来源的默认口径，全部公开案例复验与既有 benchmark 都按它校准；生产用户至今看到的是 Lahiri 盘，提升 `main` 后不能让同一个人的 Moon nakshatra 无声换掉；`80102459` 未记录改口理由，也未重校任何参考集）。Raman 与 `true_pushya` **保留为显式可选**，`AYANAMSA_MODES` 不删。若产品负责人推翻本条，改为"全部标签、VedAstro 对照、前端常量统一 Raman + 重新采集 real-case 参考值 + CHANGELOG 声明"，同样不允许两头默认。
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 目标值一律不动。
2. 不得在同一提交里既改默认岁差又改校正引擎的打分/阈值；`80102459` 里 08-20 新增的 Raman packet JSON（`*_2026_08_20.json`）若因默认回 Lahiri 而对不上，按"原值 / 新值 / 原因"三栏说明处理，不得静默删。
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，单独先推）· 默认岁差回 Lahiri，并让"算的"和"写的"一致
1. `scripts/ayanamsa_utils.py`：`DEFAULT_AYANAMSA_NAME = 'lahiri'`；模块 docstring 里"never silently collapse to Lahiri"的语义保留（未知名字仍抛 `UnsupportedAyanamsaError`）。
2. `scripts/jyotish_api_server.py:2853`、`:4017`、`:7030`：字面量 `'lahiri'` 改为**该请求实际使用的岁差名**（有则用请求里的，无则 `DEFAULT_AYANAMSA_NAME`）；`:7086` 的 `ayanamsa_display` 从实际名派生（`AYANAMSA_LABELS` 或等价映射），不再兜底 `'Raman'`。
3. 前端：`frontend/src/lib/birth-time-journey-assessment.ts:28,40`、`global-birth-payloads.ts:49` 及 `80102459` 触及的其余前端文件（`consult/route.ts`、`birth-time-journey-service.ts`、`personal-report-generation.ts`、`consultation-technique-audit.ts`）——把默认值收敛到**一个**导出常量（建议 `frontend/src/lib/ayanamsa.ts` 的 `DEFAULT_AYANAMSA = "lahiri"`），类型 `"lahiri" | "raman" | "kp" | "true_pushya"` 与 Python `AYANAMSA_MODES` 一致；技法审计表、报告证据包、校正回执里显示的岁差必须来自服务端回执，不得前端猜。
4. 校正引擎：核对 `frontend/src/lib/rectification-agentic/v9/**` 与 `scripts/active_rectification_*.py` 中是否有按 Raman 校准的阈值或 golden（重点：08-20 新增的 `*_2026_08_20.json` packet、`tests/rectification-v9-contracts.test.ts`、`tests/rectification-eight-method.test.ts`）。对得上就不动；对不上按三栏说明改 fixture，**不改阈值**。
5. 记录：`CHANGELOG.md` 新条目（写明 08-20 曾默认 Raman、本轮回 Lahiri、Raman/true_pushya 仍可显式选）；`docs/BUG_HISTORY.md` 新增 BUG（现象=公开案例复验 valid=false、根因=`80102459`、关联记录=无、复发自=无）。
6. 验收：
- `.venv/bin/python tests/run_real_case_revalidation.py` → `valid: true`、`gated 66/66`、`pass_rate ≥ 0.98`。
- `tests/test_user_invocation_acceptance_contract.py::test_fixture_dasha_timeline_rejects_workbuddy_regression_claims` 通过（不改期望值）。
- 表 A 那张虚构盘 `jyotish_engine.py dasha` 输出与生产 `7b620c7a` 一致（Swati / Rahu 余运）。
- `grep -rn "'lahiri'\|\"lahiri\"\|'raman'\|\"raman\"" scripts/jyotish_api_server.py frontend/src --include=*.py --include=*.ts --include=*.tsx | grep -v test` 只剩常量定义与标签映射，没有散落的兜底字面量。
- 产品负责人在 staging 部署后用同一份虚构出生资料对照生产：Moon nakshatra、当前大运主一致。
### 任务 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 | 岁差默认改 Raman（任务 0） |
| `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`，不写"通过"。