# 跨午夜门禁断言修复补验（2026-09-20）

## 当前边界

Windows 与同机隔离 Linux 容器的浮点行为确实不同：原测试在 Windows 通过，Linux 的 ordinal 2/3 失败；修复后两环境全绿。这不是两台独立机器，任务书 F1 的另一台 Linux 机器复验仍待完成。不要把旧 review 的 Linux 红测当成修复后绿测。

## 另一台 Linux 机器 / 受控 runner

1. 使用本轮最终提交的独立检出；先 `git status -sb`，记录 `git rev-parse HEAD`、Python、pyswisseph 与平台版本。不要借用他人账号或密钥。
2. 用项目 `.venv`，按现有 `requirements.txt`、`requirements-dev.txt` 准备依赖，不改版本约束或测试断言。
3. 执行：
   ```bash
   .venv/bin/python -m pytest tests/test_dasha_transition_proximity_cross_midnight.py -ra
   .venv/bin/python -m pytest tests/test_rectification_cross_midnight_gate.py -ra
   .venv/bin/python -m pytest tests/test_rectification_*.py -ra
   .venv/bin/python scripts/run_quality_gate.py --profile quick
   ```
4. 原文件与 bridge 分别应为 9 项；两者一起跑 18 项但仅 9 个独立场景。三个 same-day ordinal 必须通过，不能 skip/xfail 或换回另一份硬编码哈希。
5. 记录命令退出码、通过/失败数、脱敏失败标题。不附真实出生资料、完整请求或模型原文。
6. 如复做回退验收，在隔离进程内临时令 helper 的 `candidate_date = birth_date`，不提交生产文件修改：三个同日用例仍通过，`test_real_cross_midnight_all_candidates_match_independent_dated_calculation` 必须失败。

## 合入与产品边界

- 双机验收及完整快速门通过后，按授权交付 staging 并核对远端 SHA；不自行提升 main。健康检查只证明版本部署，不能证明旧缓存重新计算。
- BUG-984 是 BUG-981 端到端验收阻塞项。缓存补单需明确策略后单独执行；本轮不改缓存/SQL，不标 BUG-981 resolved。
- `unknown` 全天初始窗同日；需要验证跨午夜时，用真实受控的 late_night 场景或选择后形成的跨午夜窗，不能把全天路径本身当作跨日复现证据。
- 无登录态时不冒称受控会话端到端通过；沿既有 `rectification-cross-midnight-20260920.md` 补验，禁止借用凭据。