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

よくある失敗

主張	必要なもの	不十分なもの
テストに合格した	テストコマンドの出力：失敗 0 件	以前の実行結果、「合格するはず」
リンターの問題がない	pnpm lint:fix の出力：エラー 0 件	部分的なチェック、推測
フォーマットに問題がない	pnpm format の出力：変更なし	目視確認、思い込み
ビルドが成功した	ビルドコマンド：終了コード 0	リンターの合格、ログが良好に見えること
バグを修正した	元の症状をテスト：合格	コードを変更したこと、修正したという思い込み
リグレッションテストが機能する	レッド・グリーンのサイクルを検証済み	テストに一度合格したこと
エージェントが完了した	VCS の差分に変更が示されている	エージェントの「成功」という報告
要件を満たした	行ごとのチェックリスト	テストに合格したこと
コード品質ゲートを通過した	pnpm lint:fix と pnpm format に合格	テストに合格したこと

危険信号 - 作業を止めてください

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

もっともらしい言い訳を防ぐ

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

重要なパターン

テスト：

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

リグレッションテスト（TDD のレッド・グリーン）：

CORRECT: Write -> Run (pass) -> Revert fix -> Run (MUST FAIL) -> Restore -> Run (pass)
WRONG: "I've written a regression test" (without red-green verification)

ビルド：

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

リンターとフォーマット（必須ゲート）：

CORRECT: [Run pnpm lint:fix] [See: 0 errors] [Run pnpm format] [See: no changes] "Lint and format clean"
WRONG: "Code looks formatted" / "No obvious lint issues" / "Should be clean"

要件：

CORRECT: Re-read plan -> Create checklist -> Verify each -> Report gaps or completion
WRONG: "Tests pass, phase complete"

エージェントへの委任：

CORRECT: Agent reports success -> Check VCS diff -> Verify changes -> Report actual state
WRONG: Trust agent report

これが重要な理由

失敗の分析から：

• 「あなたの言うことは信じられない」— 信頼が損なわれる
• 未定義の関数が出荷される — クラッシュするおそれがある
• 要件が満たされないまま出荷される — 機能が不完全になる
• 誤った完了報告で時間を浪費する → 差し戻し → 手戻り
• 次の原則に違反する：「誠実さは中核的な価値観です。嘘をつけば、あなたは置き換えられます。」

適用するタイミング

必ず、次の前に適用してください：

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

このルールの対象：

• そのままの表現
• 言い換えや類義語
• 成功を示唆する表現
• 完了や正しさを示唆するあらゆるコミュニケーション

要点

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

コマンドを実行し、出力を読み、それから結果を主張してください。

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

鉄則

1. 現在のセッションで新たに検証コマンドを実行せずに、タスクが完了したと決して主張しないでください
2. 結果を主張する前に、コマンド出力全体を必ず読んでください。最後の行や終了コードだけでは不十分です
3. 検証を実行する代わりに、「通るはず」「おそらく動作します」といった曖昧な表現を決して使わないでください
4. 必ずレッド・グリーン・リファクターのサイクルを適用してください。テストが失敗することを確認し、修正後に成功することを確認し、元に戻して再び失敗することを確認します
5. すべてのゲート（テスト、lint、フォーマット）が通ることを示す検証済みの証拠なしに、決してコミット、プッシュ、タスクのクローズを行わないでください

アンチパターン

アンチパターン	失敗する理由	正しいアプローチ
コマンド実行前に成功を主張する	主張が真実であることを示す証拠がありません	コマンドを実行し、出力全体を読んでから主張します
以前の実行結果を信頼する	前回の実行後に状態が変わっている可能性があります	現在のセッションで常に新たに検証を実行します
一部のみ検証する（テストのみでlintを省略）	テストが通ってもlintの失敗でCIが失敗します	すべてのゲートを実行します。テスト、pnpm lint:fix、pnpm format
「はず」や「おそらく」という表現を使う	検証ではなく推測を示します	曖昧さをなくし、検証してから事実を述べます
レッド・グリーン・リファクターのサイクルを省略する	常に成功する回帰テストでは何も検出できません	完了とする前に、元に戻した状態でテストが失敗することを確認します

メモリプロトコル（必須）

開始前： .claude/context/memory/learnings.md を読みます

完了後：

• 新しいパターン → .claude/context/memory/learnings.md
• 発見した問題 → .claude/context/memory/issues.md
• 決定した事項 → .claude/context/memory/decisions.md

中断されることを前提にしてください。メモリに記録されていなければ、実行されていないものとします。