直す前に検査を書く

順序を逆にすると失敗します。

対象を直してから検査を書くと、書いた結果に合わせて検査が緩みます。 自分の直し方が基準になってしまうからです。

対象を1つも触らずに、基準だけコードで固定してから始めました。

在庫（allowlist）を免罪符にしない

既存の該当分は在庫ファイルへ退避します。ただし2つの向きを両方エラーにします。

向き	意味
在庫に無い新しい該当	基準が緩んだ合図
直したのに在庫に残っている行	「直した気になっている」状態

2つ目が肝です。これが無いと在庫が減りません。この向きがあるから在庫は単調に減ります。 802 → 0 になりました。

在庫へ足す機能は用意しません。 足せると、直すかわりに逃がす道ができます。

空になっても空のファイルを残します。 消すと、次に該当が出たとき「逃がす場所を作る」ところから始まってしまいます。空のファイルがあれば、足すのではなく直す、が既定になります。

検査は在庫に無いものしか出しません。通ればよい／落ちればだめ、の関門だからです。

すると在庫に入っている分が直す側に見えません。 在庫を無視して中身ごと出す、別の口が要ります。

5人に使わせたら、私が作った検査の不備が2つ出ました。

表示する数字と、判定に使う数字が違っていました。 表示は生の文字数、判定は識別子を除いた長さ。表示を見て直すと外します。

句読点を消して照合していました。 文をまたいで偶然つながった文字列を「写した」と判定し、自然な日本語を潰す方向に働いていました。区切り記号に置き換えると、相手側にも同じ位置に区切りがあるときだけ一致します。

直した直後、該当が 0 → 16 に増えました。 区切り記号を一致文字数に数えていたためです。区切りは中身ではありません。

識別子（NEXT_PUBLIC_ / package.json）や、実データそのもの（ログ行）は言い換えようがありません。

長さの計算からも本文照合からも外します。 外さないと、直す必要の無いものまで該当し、直そうとして不自然な方へ倒れます。

ここが一番危ないところです。

対象0本でも「該当ゼロ」と出ます。

実際、YAML のキー名を読み違えて対象0本になっていたことがありました。検査は緑でした。読めなかったら例外で止める必要があります。

同じ理由で、数える道具そのものを疑います。 最初の集計を正規表現で書いたら、YAML のブロックスカラーを拾えず、値が全部壊れていました。そのまま報告しかけました。

見張りを書いたつもりで、変異テストが2回続けて通りました。

どちらも、書いた時点では正しく見えました。壊して落ちるところまで見ないと、見張っていることになりません。

規約・ポリシー・案内文は、実装を変えた日にずれます。ずれても画面は正常に動き、テストも通ります。気づくのは指摘されたときだけです。

アクセス解析を入れる直前、プライバシーポリシーに「ログイン状態の維持にのみ Cookie を使用します」と書いてありました。入れた瞬間に嘘になります。

見張り方は、どちらか一方だけを変えると落ちる形にすること。「計測するコードが入っているか」と「ポリシーがそう書いているか」を両方向で突き合わせます。片方向だけだと、消し忘れ／書き忘れのどちらかを見逃します。

本番確認で ¥[0-9,]+ を grep し、「金額が出ていない」と読み違えました。

React は ¥ と数値を別ノードに出すので、HTML では ¥14,800 になり、連結では一致しません。日本語の組版で挿入されるゼロ幅スペースでも同じことが起きます。

描画後の文字列（innerText）で見ます。

CSP の許可漏れのように、画面は普通に動くのに一部の通信だけが塞がれるものは、コードを読んでも出ません。

計測タグが画像ビーコンを別ドメインへ撃つことは、実際に ID を入れて開くまで分かりませんでした。