検証の検証：通過印の後の自己反省

1. 通過印は検証の終わりではない

第1編で RULE-118 hook + 不可逆 status ID ブロックリスト + verify_safety.sh 13/13 ゲートで「全部体系化した」と締めくくっていた。 数日後、ふと開いてみると settings.local.json matcher で write ツール13個が hook 実行対象から漏れていた。その日に分かった単純な事実 — sh hook がすべてではない。 hook 自体は通過しても、hook を経由しない raw 呼び出し経路がそのまま生きていた。

コードを読んで「ちゃんとできている」と判断したことが、まさにその場所で崩れた。通過印が 押されたという事実と、検証が実際に起きたという事実は別の命題だ。そこから 実使用検証 — 実際に呼び出しを投げて遮断されるか / 通過するか — の場所ができた。コード read は 仮説、実呼び出しが検証。

表紙だけ見て判断するな。

2. 自分のツールを自分の手で再び狭める

2026-05-04。composite ツール — price_verify、payment_forensics、 shipping_diagnostics — の結果を引用する自分のパターンを見直していて、一つが 気にかかった。結果は少なかったが、どの discrepancy フィールド=値を見たかを明示しないまま 一般論で叙述するケースが多かったということ。単語一つ文一つが — 見直せば — 確実なデータに 触れていなかった。

そこで STAGE 4 PR1、warning-only gate を敷いた。composite の結果を引用しながら具体的な discrepancy を引用しなければ warning が出る。第1編で composite ツールを作ったときの thesis が「削ぎ落とす勇気」だったとすれば、今度はそのツールを使う自分の手を狭める layer だ。 ツールを作った人間がそのツールの使用を再び制限することは矛盾ではない — 自己反省が一段深くなっただけのことだ。