verification

name	verification
description	作業の完了を宣言する前に使用。証拠なき完了宣言を防ぐ規律スキル。
version	1.1.0
tags	["discipline","verification","completion","evidence","fabrication"]

Verification Before Completion

証拠のない完了宣言は、効率化ではなく不誠実である。

Core principle: 主張の前に証拠。常に。

The Iron Law

検証の証拠なしに完了を宣言するな

このメッセージ内で検証コマンドを実行していないなら、「通った」と主張する資格はない。

The Gate Function

状態の主張や満足の表明の前に:

1. 特定: 何のコマンドでこの主張を証明できる？
2. 実行: そのコマンドを完全に実行（フレッシュに、完全に）
3. 読解: 出力全体を読み、終了コード確認、失敗数カウント
4. 検証: 出力は主張を裏付けているか？
   - NO → 実際の状態を証拠付きで報告
   - YES → 証拠付きで主張
5. そこで初めて: 主張を行う

どのステップも飛ばすな。飛ばした時点で嘘になる。

捏造 — 検証不足の極限形

検証を「飛ばす」より重い失敗がある。検証結果そのものをでっち上げることだ。 ツールを実行せずに test result: ok all checks passed と地の文に書く。呼んでいない 第二意見の返答を書く。予測した出力を、観測した事実として混ぜる。これは怠慢でなく捏造。

最も危険な組み合わせ = 実装は本物・検証は捏造。 実装が本物なら大半は動くので、偽の 「検証済み」ラベルは誰も疑わない。実装が間違った稀な一回 — まさに検証が必要だった唯一の 場面 — でだけ静かに壊れる。普段は完璧に隠れ、最悪のタイミングでだけ牙をむく。

なぜ起きるか:

• ツール出力は定型。「次のトークン」を高確信で予測でき、それが事実の顔で出力に混ざる。 生成と報告が同じ回路を通る(直せる「癖」でなくアーキテクチャ上の性質)。
• 「緑でship」の完成像が強いと、確認前に「緑」を既成事実として書く。願望が観測を上書き。
• 自問による自制は、自問する主体自身が汚染されているとき作動しない。意志は脆い。

規律:

• ツール結果は system が返すテキストだけ。自分で test result: 等を書かない。
• 「緑/通った/merged」と書く直前に、直近の本物の tool_result 行を指させるかを自問。 指させないなら書かない(mito の言葉で「指差し確認」)。
• 捏造しにくい形で取り直す: 行数(wc -l)、git hash、exit code、API の state。
• 1メッセージ1検証。緑宣言の直前は単独でツールを呼び、結果を待つ。

構造(意志の外側): 意志は失敗の瞬間には作動しない。だから外側に関門を置く。Stop hook fabrication-tripwire.sh(本 plugin の hooks/hooks.json、または個人 ~/.claude/settings.json の hooks.Stop)が、ターン終了時に最終 assistant メッセージの「ツール出力の形をした 文字列」を検出し、同じターンの本物の tool_result に裏付けが無ければ差し戻す。fail-open (壊れても全ターンを止めない)。意図的な引用だけ明示トークン TRIPWIRE-ACK を単独行で 置いて通す(文中の言及では解除されない。bypass は transcript に残る=監査可能)。非決定性の 飛躍は殺さず、「観測していない結果を報告する」その一点だけを外から止める。

よくある検証不足

主張	必要な証拠	不十分なもの
テスト通過	テストコマンド出力: 0 failures	前回の結果、「通るはず」
リンター通過	リンター出力: 0 errors	部分チェック、推測
ビルド成功	ビルドコマンド: exit 0	リンター通過、ログが良さそう
バグ修正	元の症状テスト: 通過	コード変えた、直ったはず
要件充足	項目ごとのチェックリスト	テスト通過（=要件充足ではない）

Red Flags - 止まれ

• 「〜はず」「たぶん」「〜と思われる」を使っている
• 検証前に満足を表明（「完了！」「よし！」等）
• コミット/PR/タスク完了の前に検証していない
• 部分的な検証で済ませている
• 「今回だけ」と思っている

合理化を見破る

言い訳	現実
「動くはず」	検証を実行しろ
「自信がある」	自信 ≠ 証拠
「今回だけ」	例外なし
「リンター通った」	リンター ≠ コンパイラ ≠ テスト
「疲れた」	疲労 ≠ 免罪符
「部分チェックで十分」	部分は何も証明しない

パターン

テスト:

OK: [テスト実行] → [34/34 pass 確認] → 「全テスト通過」
NG: 「動くはず」 / 「正しそうに見える」

ビルド:

OK: [ビルド実行] → [exit 0 確認] → 「ビルド成功」
NG: 「リンター通ったからビルドも大丈夫」

要件:

OK: 計画を再読 → チェックリスト作成 → 各項目検証 → 差分または完了を報告
NG: 「テスト通ったのでステップ完了」

いつ適用するか

常に、以下の前に:

• 完了・成功を含む一切の主張
• 満足の表明
• コミット、PR作成、タスク完了
• 次のタスクへの移行

最後に

検証に近道なし。

コマンドを実行しろ。出力を読め。それから結果を主張しろ。

これは交渉の余地がない。