verify

主張より先に証拠を示します。直近のコマンド実行結果がない限り、主張してはいけません。

最短経路：計画が1文で、仕様ファイルがない場合、ゲートとなるのはその文の基準です。変更を検証するテストだけを実行し、変更した経路もエンドツーエンドで実行します。それでも最短経路タスクでゲートに2回目に失敗した場合、そのタスクは明白ではありません。停止して、そのタスクに対して drill を実行します。

1. これから行おうとしている主張に名前を付けます：「完了した」「修正した」「合格した」「動作する」。
2. 主張を分類します。コマンドで確定できる主張は、ここで検証します。品質に関する主張は、コマンドの結果にかかわらず、ただちに rubric スキルに送ります。品質に関する主張とは、設計、UI、公開インターフェース、名前、または文章についての主張です。証明不可能として却下するのは、ルーティングの失敗です。コマンドに合格しても、品質に関する主張が合格したことにはなりません。
3. 主張が誤りだと証明できるコマンドを実行します：テスト、ビルド、リンター、変更した動作です。完全なゲートは、すべてのテスト、ビルド、リンターです。コミットごとに1回、コミットしようとしているツリーに対して実行します。最短経路では、ゲートはその文の基準です。スライス内では、テストループはそのスライスを検証するテストだけを実行します。仕様で定義されたフェーズ内では、コミット時に変更対象領域のチェックを実行します。フェーズの最後のコミットでは、完全なゲートを実行します。
4. 仕様が docs/specs/<slug>.md にある場合、各基準を個別にゲートします。スライスのコミット時には、そのスライスが対象とする基準をゲートします。宣言されたフェーズの終了時点に達する基準は、フェーズの最後のコミットまで保留します。作業全体が完了したと主張するときは、すべての基準をゲートします。ハッシュがツリーと一致する場合は、それぞれの結果を最新の証拠記録から取得します。各基準の検証コマンドを実行し、それを証明する出力を引用します。基準の行に rubric と記載されている場合は、その評価者の判定を使用します。作業全体が完了したと主張するときは、基準は現在のタスクリストの項目とします。リストがなく、基準が3つ以上ある場合は、リストを作成します。項目を完了にするのは、それを証明する出力または判定がある場合だけです。証拠のない基準は未完了のままにします。次に、仕様の非目標に照らして差分を確認します。テストに合格していても、対象外の範囲に変更があれば、主張は失敗です。仕様に ## Open decisions セクションが残っている場合、それは草案です。草案に対して主張を行うことはできません。drill に差し戻します。
5. 変更した経路を単体テストだけでなく、エンドツーエンドで実行します。変更にランタイムインターフェースがある場合は、それを操作し、その結果を保持します。ランタイムインターフェースとは、UI、CLI、TUI、またはサービスです。コマンド出力、ログ、スクリーンショット、またはトランスクリプトを保持します。ベースブランチにレシピがある場合は、app-check.md の説明に従って、変更対象の機能をそのレシピで実行します。レシピとは、verify-<app> という名前のプロジェクトスキルです。ユーザーから依頼された場合に限り、同じリファレンスに従ってレシピを作成または更新します。レシピのないランタイムインターフェースの場合は、レシピを作成することを1行で提案します。プロキシを介して変更した経路の結果を読む場合は、prove it works を読みます。プロキシとは、タイムスタンプ、ステータスファイル、キャッシュ値、スクリーンショット、または別のエージェントからのレポートです。チェックが失敗した場合、または移植や移行を行う場合も、同じものを読みます。
6. 出力を読みます。合格とは、コマンドが終了したことではなく、出力に合格と示されていることです。
7. 実行した内容と、その結果を報告します。失敗した場合は失敗したと伝え、出力を示します。仕様でデモ成果物が指定されている場合は、その成果物を再度実行してデモを示します。以前の実行について説明してはいけません。デモは変更が動作することを示しますが、基準を証明するものではありません。そのため、ブランチで作成したスクリプトをデモに使うこともできます。

ルール：

• デフォルトの回答は却下です。新しい出力で証明されるまでは、主張は誤りです。実装者の言葉は証拠ではありません。
• 以前の実行の記憶をもとに主張してはいけません。証拠記録は、作業ツリーのコンテンツハッシュと、各コマンドおよびその保存済み出力です。ハッシュは git ls-files -z -co --exclude-standard -- . ':!*.md' | sort -z | xargs -0 sha1sum | sha1sum で取得します。macOS では sha1sum の代わりに shasum を使用します。テストで Markdown を読み取る場合は、':!*.md' の除外指定を削除します。ハッシュがツリーと一致する記録は、記憶ではなく新しい出力です。その記録を再利用し、コマンドを再実行してはいけません。コミット、同じツリーへの切り戻し、または Markdown だけの編集では、ハッシュと記録は変わりません。implement、debug、land およびこのスキルでは、記録を再利用します。ハッシュ対象のファイルを次に編集すると、記録は無効になります。
• 主張に必要なコマンドをすべて計画し、それぞれを一度だけ、単一の呼び出しで実行します。その後、出力を基準に照らし合わせます。各コマンドの完全な出力は、> /tmp/verify-<hash>-<name>.log 2>&1 でファイルに書き込みます。そのファイルを読み、検索します。出力をさらに見るためにコマンドを再実行するのは、重複実行です。独立したコマンドは同時に実行します。ファイル、ポート、データベース、ビルドディレクトリを共有しないコマンドは独立しています。基準とは、すでに存在する出力を読み取ることであり、テストスイートを再度実行することではありません。
• 検証コマンドとは、プロジェクトのテストランナー、ビルド、またはリンターです。変更と同じブランチで作成されたスクリプトは、検証コマンドではありません。そのスクリプトが成功しても、そのスクリプトに依存する主張は却下します。verify-<app> のレシピが該当するのは、ベースブランチにある形式の場合だけです。主張対象のブランチで作成または変更されたレシピは、そのブランチのスクリプトです。
• スキップしたチェックは、スキップしたと報告します。検証が部分的なら、主張も部分的なものにします。「テストは成功しました。動作は検証していません」は誠実な報告です。「完了しました」では不十分です。
• 測定値に依存する主張では、数値の説明に従い、その数値の上限を定める条件を記載します。測定値とは、ベンチマーク、速度向上、レイテンシ、サイズ、合格率、または実行回数です。
• レビューのフィードバックも主張です。対応する前に検証します。不明瞭なフィードバックは確認します。確認せずに従ってはいけません。