試験の壁時計締切を定数から過負荷率の関数へ(ADR-DOE-ENFORCE-001 R6)— 2 つの締切を一緒に伸ばし、伸ばした事実は黙らない

[proboscis]

何を直したか

operator 裁定 decision-doeff-land-gate-deadline-2026-08-17.html 「A. 締切を直す」 の執行。

試験の壁時計締切が捕まえるべきものは hang であって busy ではない。外部プロセス
(semgrep・CLI・build)を待つ試験の所要は機械の過負荷率に比例して伸びるのに、締切だけが
定数だったため、過負荷帯では 正しい仕事に赤を出す装置 へ退化していた。

実測(2026-08-17)

確かめたこと	結果
着地の門の連敗	5 連敗(毎回ちがう外部プロセス起動テスト)。他席の 4 回と合わせて 9 回
枝の欠陥か	違う — 同じ semgrep 試験が手つかずの main を単独で回しても同じく落ちる(対照実験)
semgrep 単体の所要	load 80 で 29.7 秒(定数の予算は 60 秒)。電池全体の負荷が乗ると超える
機械	18 コアに対し 1 分平均 load 60〜156 が定常

修理

• 係数 = 1 分平均 load / コア数(下限 1.0・上限 PYTEST_DEADLINE_SCALE_CAP 既定 8)。
  上限があるので真の hang は依然として有界時間で落ちる
• 無効化は PYTEST_DEADLINE_SCALE=off(負荷を自分で制御する CI 用)
• 締切は 2 つあり、必ず一緒に動かす — pytest-timeout の per-test 締切と、その上に立つ
  SIGKILL watchdog。watchdog は常に per-test より厳密に上に居る。
  ⚠ 片方だけ上げると「遅い試験 1 本が赤くなる」が「走行ごと SIGKILL で全損する」に化ける
  (実測: PYTEST_TIMEOUT=600 を素の 90 秒 watchdog に当てて全数電池が 45% で即死)
• marker の締切(@pytest.mark.timeout)も同じ係数に掛かる — pytest-timeout は marker を
  ini より優先するので、ini だけ伸ばすと「自分は遅いと申告した試験」= 外部プロセスを起こす
  当の試験群が素の締切に取り残される
• 伸ばしたことは黙らない — 係数が 1 を超えた走行は実効値を stderr に出す。伸びた締切は
  同時に「この機械は過負荷である」の信号でもあり、8 倍かかった走行が黙って緑を返すのは
  観測の欠落

per-test 締切の家は pyproject.toml ただ 1 つのまま(conftest は ini を読んで掛けるだけで、
60 という数字を第 2 の場所へ写さない)。呼び手が env や --timeout で明示した値は潰さず、
その値を掛ける — 潰したら escape hatch が嘘になる。

法・反例

ADR-DOE-ENFORCE-001 に R6 と law deadline-measures-hang-not-load(反例 5):

1. 今回の 5 連敗の実測(定数の締切)
2. 片方だけ伸ばして走行全損に化ける形
3. ini だけ伸ばして marker が取り残される形
4. 係数に上限を置かず、今度は hang を busy と誤認する形
5. 黙って伸ばして過負荷の観測を失う形

台帳も同便で更新(law 84→85・deftest 37→38 — R5 anti-drop ratchet)。

検証

• tests/test_deadline_load_scaling.py 5 本 + 台帳 + ADR = 10 passed
• 5 連敗の当事者だった tests/semgrep/test_vm_failfast_semgrep_rules.py が
  16 passed(14m16s)。出力は deadline scale x5.5 (load/core) — per test 328s, watchdog 491s

この便が塞いでいたもの

resume の根治(PR #593 — ADR-DOE-AGENTS-006 R10)がこの門で 5 回止まっていた。
本便が着地すれば #593 を通せる。

🤖 Generated with Claude Code

---

基底追随の再登記(2026-08-17 引き継ぎ席)

統合形(宣言 + 修理の 1 commit 束)は着地の門で 4 連敗した(L29〜L32・最後は門 2700s に対し
2713.4s の時間切れ)。「修理入りの全量検査は 1844s で収まる」という統合の前提は
負荷依存で反証された — 収まるかどうかが機械の負荷帯で変わる以上、門の持ち時間の宣言は
基底側に先に居る必要がある。

• 宣言(gate.timeout_s 2700→7200)は 宣言先行便 L33(branch wt/gate-timeout-7200)として
  main へ着地済み(1676378)
• 本便はその新基底へ追随し、.agents/land-queue.toml に触れない 1 commit(4 paths・+329/−8)へ
  畳み直した — 宣言と重複していた統合 commit(8426a0b)の toml hunk は落とした
• 再検証: R6 条文検査(gate.timeout_s >= 7200 を基底から読む)+ 新規 5 本 = 9 passed
  (load 66〜77 帯で実測)

[proboscis]

L34 として main へ着地済み(156d1cc — 窓の train 再構築で sha は変わったが patch-id 同一・内容同一の 4 paths +329/−8)。宣言 gate.timeout_s 7200 は L33(宣言先行便)で先行着地。着地後の main 断面で R6 条文検査 + tests/test_deadline_load_scaling.py = 9 passed を実測。本線到達済みのため close。