[hdknr]

Fixes #460

何を変えたか

• scripts/check-all.py — check-mutation-claims.py を起こすときだけ --jobs max(1, 親の --jobs // 2) を渡す。親が --jobs 1 なら入れ子も直列。docstring に、半分にした根拠となる実測（10 コアの macOS 1 台）と、打ち切りの原因が特定できていないことを書いた
• scripts/test-check-all.py — 契約 9: 入れ子に渡す --jobs が親より多くなく、親 1 なら 1 であることを、値ではなく性質で見る。変異 3 件
• scripts/test-worktree-scripts.py — コメントの 1 文だけ。根拠の無い因果を、記録にある事実だけに直した（2 パス目の R5）
• docs/plans/issue-460.md — 計画・実測・採否の表

プラグインの中身は変えていないので版は上げていない。反映経路なし（scripts/ だけ）。

検証

• python3 scripts/check-all.py: 51/51（失敗 0）。最後に回したのは bba67c9 の時点
• 関門: Verifier（sonnet・dev-loop:dev-loop-verifier）と /code-review（high）を 2 パス。それに加えて、2 パス目の修正に狭いパスを 1 回。結果と採否の表は PR コメントに書く

🤖 Generated with Claude Code

[hdknr]

レビュー結果（dev-loop 手順 6）

関門

関門	結果
Verifier 1 パス目（sonnet）	反証 0 件・注意 1 件
/code-review 1 パス目（high）	指摘 9 件 → CR5 を直した（b99fc7f）、CR7 は測り直した。残りは残課題
Verifier 2 パス目（当て直し）	反証 0 件・注意 2 件（基準 4 の証拠の弱さ）
/code-review 2 パス目（high）	指摘 10 件 → R5 を直した（bba67c9、人間の判断で範囲を広げた）。残りは残課題
狭いパス（R5 の修正だけ）	反証 0 件。Verifier は変異を設計しなかった（コメントだけの変更なので）。素通りした変異: なし（当てていない）

関門は 2 パスで打ち切った。採否の表（1 件 1 行）は docs/plans/issue-460.md の「既知の限界・決着済みの論点」にある。

検証して確かめたこと

• 基準 1・2: 入れ子に渡す --jobs が親より多くなく、親 1 なら 1——test-check-all.py の契約 9 と変異 3 件で確かめた。実物の起動は、10 コアで親が既定なら入れ子は 5
• 基準 3: check-all.py 51/51（失敗 0）
• 基準 5・6: test-check-all.py・test-worktree-scripts.py が緑。test-worktree-scripts.py の差分はコメントだけ
• 生成物なし（check-diagram-freshness.py・skill-metrics.py --check が緑）

基準 4（wall が大きく悪化しない）は証拠が弱い

同じツリーで交互に測ったのは 1 組だけ（base 248.8 秒 / HEAD 243.1 秒）。交互でない測定のばらつき（217〜262 秒）と、この変更で予想される +8%（約 19 秒）は、この 1 組では判別できない。1 分平均の負荷も 11〜47 と揺れており、統制したのは他の check-all.py の重なりだけ。基準 4 には閾値も無い（Verifier 2 パス目の注意 1・2、/code-review 2 パス目の R1・R2）。人間のレビューで判断をお願いします。

未証明（この環境では証明できない）

• 遅い機械やコア数の違う機械で、打ち切りに届かなくなること（測れたのはこの 1 台だけ）
• この機械でも、この変更が打ち切りを防ぐこと——重ならない回では、変更前でも打ち切りは再現しなかった（最長の red は 90〜99 秒）。打ち切りの原因は特定していない（R6）

残課題（直していない指摘）

• CR1〜CR3: 契約 9 の網の穴（既定の起動を見ない・他の歯止めに --jobs が渡ることを見ない・親 1 と 4 しか見ない）。実物は満たしている
• CR4・R4: --jobs 1 でも孫（red が起こす test-check-mutation-claims.py の main()）は既定の並列で回る。基準 2 は「check-mutation-claims.py --jobs 1」と定義している
• CR6: 実測では入れ子が N のときの red は打ち切りから遠い。並列の形は N×N ではなく (N-1)+N（決着の理由への反論）
• CR8・R7: CPU の数で頭打ちにしていない。10 コアで --jobs 32 を指定すると、入れ子は変更前の 10 から 16 に増える（基準 1 の「親より多くない」は満たしている。決着の理由への反論）
• CR9: FAIL の行に、入れ子に渡した --jobs が出ない
• R3: 計画の経路表の「red が check-all.py を起こす主張は無い」は誤り（red が test-check-all.py の主張が 4 件ある）。ただし run は偽物に差し替えられているので、重い入れ子にはならない
• R8: 捨てた測定と残した表の値が近く、混ざったかどうか、1 セッション目の記録からは確かめられない
• R9: 名前で 1 段だけ絞る形。環境変数で継ぐ上限なら全段に効く（設計の提案）
• R10: 半分に固定すると、終盤に約 N/2 コアが空く（+8% の原因という推測）
• Verifier 1 パス目の注意: 契約 9 は「半分」という値を固定しない（意図して性質を見ている）
• 他のセッションの check-all.py と重なったときの打ち切りは、この周の範囲外

満たしていない受入基準

なし（Verifier の反証は全パスで 0 件）。ただし基準 4 は上のとおり証拠が弱い。