completion-gate

完了ゲート

概要

検証せずに作業完了を宣言するのは、効率的なのではなく不誠実です。

基本原則： 常に、主張より先に証拠を示します。

例外なし。回避策なし。近道なし。

最優先の指令

NO COMPLETION ASSERTIONS WITHOUT FRESH VERIFICATION OUTPUT

このメッセージ内で検証コマンドを実行していない場合、合格したと主張することはできません。

実施手順

BEFORE asserting any status or expressing confidence:

1. IDENTIFY: Which command substantiates this assertion?
2. EXECUTE: Run the FULL command (fresh, complete)
3. INSPECT: Read every line of output, check exit code, tally failures
4. CONFIRM: Does the output support the assertion?
   - If NO: Report actual status with evidence
   - If YES: State the assertion WITH supporting evidence
5. ONLY THEN: Make the assertion

Skipping any step = fabrication, not verification

検証要件

主張	必要なもの	不十分なもの
テスト合格	失敗数が 0 と示されたテストランナーの出力	過去の実行結果、「合格するはず」
リンターに問題なし	エラー数が 0 と示されたリンターの出力	部分的なスキャン、推測
ビルド成功	終了コード 0 のビルドコマンド	リンター合格、ログの断片
バグ解決	元の症状をテストし、合格すること	コードの変更、修正されたという思い込み
回帰テストが有効	Red-Green サイクルの確認	1 回だけの合格
エージェントの作業完了	実際の変更を示す VCS 差分	エージェントによる自己申告の「完了」
仕様への準拠	要件を 1 行ずつ確認したチェックリスト	テスト合格のみ

ガードレール — 停止

• 「はず」「たぶん」「どうやら」など、断定を避ける表現を使いそうになったとき
• 「完了！」「完璧！」「すべて問題なし！」など、時期尚早に満足を表明しそうになったとき
• 検証せずにコミット／プッシュ／PR の作成をしようとしているとき
• エージェントの自己申告による成功を信頼しようとしているとき
• 部分的、または古い検証結果に頼ろうとしているとき
• 「今回だけなら」と考えたとき
• 疲れていて、作業を切り上げたくなったとき
• 検証を実行していないのに、成功をほのめかす表現を使おうとしているとき

思考の罠

合理化	真実
「今度は動くはず」	検証を実行してください
「自信がある」	自信は証拠ではありません
「今回だけなら」	例外はありません
「リンターに合格した」	リンターはコンパイラーではありません
「エージェントが成功したと報告した」	独立して検証してください
「疲れている」	疲労は正当化の理由になりません
「部分的なチェックで十分」	部分的な証明は証明ではありません
「表現が違うのでルールは当てはまらない」	技術的な言い回しではなく、意図が重要です

検証パターン

テスト：

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

回帰テスト（Red-Green サイクル）：

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

ビルド：

CORRECT: [Run build] [Output: exit 0] "Build passes"
WRONG: "Linter passed" (linter does not validate compilation)

仕様への準拠：

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

エージェントへの委任：

CORRECT: Agent reports done -> Check VCS diff -> Verify changes -> Report actual state
WRONG: Trust agent report at face value

設定変更の検証

設定、プロバイダー、機能フラグ、環境設定の変更をテストする場合：

操作が成功したことを確認するだけでは不十分です。出力が意図した変更を反映していることを確認してください。

サイレントフォールバックの問題

意図した設定が適用されていなくても、何らかの有効な設定が存在するために操作が成功する場合があります。

変更	不十分	必須
LLM プロバイダーの切り替え	HTTP 200	レスポンス本文に想定したモデル識別子が含まれている
機能フラグの切り替え	エラーがない	機能が有効になったことを動作で確認できる
環境の変更	デプロイが成功する	ログ／変数に新しい環境が記載されている
認証情報の設定	認証が成功する	認証された ID が正しい

設定の検証手順

BEFORE asserting a configuration change works:

1. IDENTIFY: What should be DIFFERENT after this change?
2. LOCATE: Where is that difference observable?
3. EXECUTE: Command that exposes the observable difference
4. CONFIRM: Output contains the expected difference
5. ONLY THEN: Assert the configuration change works

Warning signs:
  - "Request succeeded" without inspecting content
  - Checking status code but ignoring response body
  - Confirming no errors but lacking positive confirmation

UI 作業の検証

UI 作業が完了したと主張する場合：

主張	必要なもの	不十分なもの
コンポーネントがデザインと一致する	UX リファレンスとの視覚的な比較	「自分には合っているように見える」
レスポンシブデザインが機能する	モバイル、タブレット、デスクトップのブレークポイントでのテスト	デスクトップのみの確認
アクセシビリティに問題がない	スクリーンリーダーのテスト＋キーボード操作＋コントラストの確認	「aria ラベルを追加した」
デザイントークンが適用されている	間隔／色／タイポグラフィがトークン値と一致する	「正しいクラスを使った」

これが重要な理由

蓄積された失敗パターンより：

• 人間のパートナーに「信じられない」と言われ、信頼が崩れた
• 未定義の関数がリリースされ、即座にクラッシュした
• 要件が不足したままリリースされ、機能が未完成になった
• 完了したという誤った判断に時間を費やした結果、差し戻しとやり直しが発生した
• 「誠実さは中核的な価値です。嘘をつけば、あなたは交代させられます。」という原則に反する

適用する場面

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

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

このルールの対象：

• 完全に一致する表現
• 言い換えや類義語
• 成功を暗示する表現
• 完了または正確性を示唆するあらゆるコミュニケーション

要点

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

コマンドを実行してください。出力を読んでください。その後で結果を述べてください。

これは絶対に譲れないルールです。