verification-before-completion

完了前の検証

概要

検証せずに作業が完了したと主張するのは、効率化ではなく不誠実です。

基本原則： 常に、主張する前に証拠を確認してください。

このルールの文言に違反することは、このルールの精神にも違反することです。

鉄の掟

NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE

このメッセージに記載された検証コマンドを実行していないなら、成功したと主張することはできません。

ゲート機能

BEFORE claiming any status or expressing satisfaction:

1. IDENTIFY: What command proves this claim?
2. RUN: Execute the FULL command (fresh, complete)
3. READ: Full output, check exit code, count failures
4. VERIFY: Does output confirm the claim?
   - If NO: State actual status with evidence
   - If YES: State claim WITH evidence
5. ONLY THEN: Make the claim

Skip any step = lying, not verifying

よく使う検証コマンド

テスト：

# Preferred: bun
bun test

# Alternative: npm
npm test

ビルド：

# Preferred: bun
bun run build

# Alternative: npm
npm run build

リンター：

# Preferred: bun
bun run lint

# Alternative: npm
npm run lint

型チェック：

# Preferred: bun
bunx tsc --noEmit

# or: npx tsc --noEmit

よくある失敗

主張	必要なもの	不十分なもの
テストに合格した	テストコマンドの出力：失敗 0 件	前回の実行、「合格するはず」
リンターに問題がない	リンターの出力：エラー 0 件	部分的なチェック、推測
ビルドに成功した	ビルドコマンド：終了コード 0	リンターの合格、ログが良好に見えること
バグを修正した	元の症状を検証するテスト：合格	コードを変更したこと、修正済みという思い込み
回帰テストが機能する	Red-Green サイクルを検証済み	テストに一度合格したこと
エージェントが完了した	VCS の差分に変更が示されていること	エージェントの「成功しました」という報告
要件を満たした	行ごとのチェックリスト	テストに合格したこと

危険信号 — STOP

• 「〜のはず」「おそらく」「〜のようです」を使う
• 検証前に満足を表す（「すばらしい！」「完璧！」「完了！」など）
• 検証せずにコミット／プッシュ／PR をしようとしている
• エージェントの成功報告を信頼している
• 部分的な検証に頼っている
• 「今回だけなら」と考えている
• 疲れていて、作業を終わらせたいと思っている
• 検証を実行していないのに成功を示唆する表現を使っている

正当化の防止

言い訳	現実
「これで動くはず」	検証を実行する
「自信がある」	自信 ≠ 証拠
「今回だけなら」	例外はない
「リンターに合格した」	リンター ≠ コンパイラー
「エージェントが成功したと言った」	独自に検証する
「疲れている」	疲労 ≠ 言い訳
「部分的なチェックで十分」	部分的なチェックでは何も証明できない
「言い回しが違うからルールは適用されない」	文言より精神を重視する

主なパターン

テスト：

✅ [Run test command] [See: 34/34 pass] "All tests pass"
❌ "Should pass now" / "Looks correct"

回帰テスト（TDD Red-Green）：

✅ Write → Run (pass) → Revert fix → Run (MUST FAIL) → Restore → Run (pass)
❌ "I've written a regression test" (without red-green verification)

ビルド：

✅ [Run build] [See: exit 0] "Build passes"
❌ "Linter passed" (linter doesn't check compilation)

要件：

✅ Re-read plan → Create checklist → Verify each → Report gaps or completion
❌ "Tests pass, phase complete"

エージェントへの委任：

✅ Agent reports success → Check VCS diff → Verify changes → Report actual state
❌ Trust agent report

これが重要な理由

失敗の記録より：

• 誤った主張によって信頼が損なわれた
• 未定義関数がリリースされ、クラッシュするところだった
• 要件が欠けたままリリースされ、機能が不完全になった
• 誤った完了報告によって時間が無駄になり、方向転換とやり直しが必要になった
• 「誠実さは中核的な価値です。嘘をつけば、あなたは入れ替えられます」という原則に反する

適用するタイミング

必ず以下の前に適用してください：

• 成功や完了を主張するあらゆる表現
• 満足を表すあらゆる表現
• 作業状況に関するあらゆる肯定的な発言
• コミット、PR の作成、タスクの完了
• 次のタスクへの移行
• エージェントへの委任

ルールの適用対象：

• 正確な表現
• 言い換えや同義語
• 成功をほのめかす表現
• 完了や正しさを示唆するあらゆるコミュニケーション

結論

検証に近道はありません。

コマンドを実行します。出力を読みます。その後で結果を主張します。

これは譲れないルールです。