Jyotisha/docs/tasks/TASK-owner-case-purge-fix2-20260919.md

TASK · 库主案例清除验收修复单（2026-09-19，第二轮）

状态：待领取。串行在 codex/owner-case-purge-20260919（fe9489e6）之上，同一分支继续提交。上一轮验收结论见 docs/tasks/README.md 状态板。 本单不转录任何出生日期、出生分钟、经纬度、本机用户名。

0. 基线

• 分支：codex/owner-case-purge-20260919 @ fe9489e6，基于 origin/staging 35ca7299。
• 验收环境（Linux，Python 3.11 + pyswisseph 轮子，Node 20，依赖装在 worktree 内）：tsc 0 错；lint 0 error / 120 warning 与基线相同；npm test 3530 条、33 红、15 skip，失败清单与基线逐条相同；next build / Static，首屏 gzip 617,915 字节与基线字节相同；Python 全量 64 红 vs 基线 63 红。
• 执行方在 Windows 上没能跑完 Python 全量（缺 mcp / hypothesis），进度记录里「0 新红」的结论只覆盖定向测试，所以漏了下面 F1。

1. 事故实证

F1（P0）新增一条 Python 红：答案键字面量守卫命中导入脚本，staging 快速门会红

• tests/test_rectification_engine_convergence.py:396-416 EngineConvergenceAnswerKeyTests.test_scripts_and_frontend_have_no_answer_key_literals 在 scripts/、frontend/src、frontend/tests 里禁止三个字面量（target_minute、pl9_1993、regression_only，测试里用字符串拼接写的）。
• scripts/import_yinduzhanxing.py:56-64 新增的 REQUIRED_PRIVACY_PATH_PATTERNS 第三项是 "**/*pl9_1993*"，命中该守卫。基线上该测试通过。
• 这条模式被第一项 "**/*1993*" 完全包含，删掉不减少任何拦截能力。
• run_quality_gate.py:66 的 CORE_PYTEST_TARGETS 含 glob tests/test_rectification_*.py，该测试在快速门内。验收实跑 --profile quick：Python 步 856 条只有这 1 条红，== Quality gate failed ==。合入 staging 会让门禁红、镜像不发布，所以是 P0。

F2（P3）上游指令被脱敏到不可执行

• docs/tasks/UPSTREAM-INSTRUCTION-owner-case-purge-20260919.md 在 fe9489e6 里把案例 ID、函数名、文件名批量替换成 [库主案例标识已移除] / [私人案例引用已移除]，并删掉了第三步的 git ls-files | grep 命令。案例 ID 和函数名不是出生资料；原单只禁出生日期、分钟、经纬度、本机用户名。替换后库主拿到的是无法定位的占位符。
• 产品手里已有 35ca7299 版本的原文（验收时已单独发出），这条不阻塞交付，只是仓内归档件应可读。
• 同类替换也落在 TASK-rectification-convergence-20260830.md、TASK-upstream-sync-20260903.md 等 11 份历史文档里，其中真实出生日期 / 分钟的替换（[隐私标记 R001/R003 已移除]）是对的，保留；文件名被替换成整句「会话转录已按 … 决策删除」造成句子不通，属美观问题，不要求回改。

F3（P2）进度记录缺逐项删除测试清单

• 执行方在 PROGRESS-owner-case-purge-20260919.md 写明因写入权限没能落盘。验收从 diff 得到的清单如下，直接抄进进度记录即可（都是文件名，不含隐私）： test_deep_fragment_oss_reuse_gate_round2、test_fragment_migration_registries、test_fragment_second_pass_candidate_ledger、test_high_value_gap_registries、test_technique_promotion_audit_kp_gochara_muhurta、test_truth_source_runtime_identity、test_whole_machine_jyotish_fragment_scan、test_workbuddy_round3_candidate_ledger、test_workbuddy_round4_candidate_ledger、test_workbuddy_round4_formalization_registry、test_workbuddy_round4_usage_closure_queue、test_workbuddy_round5_transfer_status（12 个文件）。
• 验收实测 Python 收集数（Linux 全依赖环境，0 收集错误）：基线 2,905 条 / 501 文件 → 分支 2,970 条 / 491 文件，净 +65 = 108 新增 − 43 已删，文件 −10 = 12 删 + 2 增；与进度记录在 Windows 上算出的 +65 一致（那边绝对数 2,758 → 2,823 是因为 13 个模块收集失败）。

2. 决策记录

• 沿用原单与执行方补充单（TASK-owner-case-purge-fix-20260919.md）的全部授权，不新增范围。
• F2 只恢复 UPSTREAM-INSTRUCTION-*.md 一份文件到 35ca7299 的措辞（git show 35ca7299:docs/tasks/UPSTREAM-INSTRUCTION-owner-case-purge-20260919.md），其余历史文档的脱敏保持 fe9489e6 状态。恢复前用分支上的 tests/test_repo_privacy_markers.py 扫一遍，命中即不恢复并写进度记录。

3. 任务

#	动作	验收
F1	删 REQUIRED_PRIVACY_PATH_PATTERNS 里的 "**/*pl9_1993*"；tests/test_import_yinduzhanxing.py:81,361 按 len() 参数化，不需要改；若有断言写死 7 条则改成 6 并三栏说明	pytest tests/test_rectification_engine_convergence.py tests/test_import_yinduzhanxing.py -q 全绿；用原单的检索键确认 scripts/ 仍 0 命中
F2	恢复上游指令文件到 35ca7299 版本	pytest tests/test_repo_privacy_markers.py -q 通过
F3	把上面 12 个测试名与收集数核算写进 PROGRESS-owner-case-purge-20260919.md	文件里能找到 12 个名字
F4	docs/BUG_HISTORY.md BUG-973 补一行「验收发现 pl9_1993 模式撞答案键守卫，已删」；BLOCKED.md 里「删除测试清单写入权限」一条划掉	—

4. 硬红线

原单 §4 全部沿用；额外：不动 tests/test_rectification_engine_convergence.py 的禁止字面量列表来换绿。

5. 开工前置

cd /workspace/Jyotisha && git status -sb && git fetch origin refs/heads/codex/owner-case-purge-20260919:refs/remotes/origin/codex/owner-case-purge-20260919
git worktree add .worktrees/owner-case-purge-fix2-20260919 origin/codex/owner-case-purge-20260919 -b codex/owner-case-purge-20260919-fix2

完成后快进合回 codex/owner-case-purge-20260919 并推同名远端分支，Claude 再验一次全量后合入 staging。