검증의 검증: 통과 도장 이후의 자기반성

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 도구를 만들 때 명제가 "비워낼 용기"였다면, 이번에는 그 도구를 쓰는 내 손을 좁히는 layer다. 도구를 만든 사람이 그 도구 사용을 다시 제한하는 게 모순이 아니다 — 자기반성이 한 단계 더 깊어진 것뿐이다.