reality-check

Reality Check

期待される状態と観測可能な証拠を比較し、明示された目標を測定するか、ネイティブのステータスを報告します。求められた質問を選択してください。スナップショットを作成するのに、完了したという主張をでっち上げる必要はありません。作業を選定せず、事実と不足点を報告してください。近接する項目：計画や変更への助言はReview、完了した変更への受け入れ判定はValidateを参照してください。

主張の比較

開始されなかった作業も含め、明示されたすべての主張を列挙し、それぞれに個別の判定を付けます。確認済み（証拠を引用）、不足（何が欠けているか、または何が主張と矛盾するかを引用）、または検証不能（判断を確定できる証拠を明示）です。名指しされた失敗パターンは、差分が触れた箇所だけを監査することです。証拠に痕跡のない主張項目は不足であり、報告から除外してはいけません。

1. 主張の正確な文言とその出典を読み、個別の項目に分けます。
2. 関連ファイル、コマンドの結果、成果物を調べ、確認済みの動作、具体的な不足、不完全な証拠、変更された前提を区別します。証拠が示す内容だけを評価してください。出力のない実行報告、デフォルトや別コンポーネントに委ねられた動作、主張された結果を検証していないテストは、確認済みではなく検証不能です。検証できない主張を断定で解決せず、不足している証拠を明示してください。
   動作が実装されているという主張については、関連コードを検索し、見せかけの実装がないか確認します。定数またはハードコードされた結果、TODO または未実装の分岐、サンプルデータ、テストコード以外のテストダブルなどが該当します。該当箇所はそれぞれ呼び出し元まで追跡してから分類してください。プレースホルダーに本番経路から到達できる場合、その項目は不足です。テストでのみ使われるテストダブルや、どこからも呼び出されないコードは該当しません。
   名前を挙げたコミットまたはプルリクエストで作業をプッシュ、マージ、リリース、修正したという主張の完了状況は、ローカルの参照、プッシュ出力、保存されたステータスではなく、現在のリモート状態から到達可能かどうかで確定します。対象ブランチの現在の先端に内容が残っているか、また主張どおりに動作するかは、上記のとおり確認します。プッシュ済みとは、指定されたリモートブランチ、またはプルリクエスト自身のヘッドリポジトリにある現在のヘッド（フォークを含む）から到達可能であることを指します。マージ済みとは、主張で指定された対象ブランチ、指定がなければデフォルトブランチの先端から到達可能であること、またはそのブランチをベースとするプルリクエストがマージされていることを指します。別のベースへのマージでは確認済みになりません。リリース済みとは、リポジトリのリリースポリシーで定められたもの（タグ、公開リリース、デプロイメント）に含まれていることを指し、その情報源から読み取ります。スカッシュやリベースにより祖先関係が失われている場合は、同等のコミットだと決めつけず、内容を対象と比較してください。指定された SHA またはプルリクエスト番号は、コマンドに渡す前に形式を確認してください。
3. 計画について尋ねられた場合は、提案された範囲を元の目標と比較します。権限のない追加はスコープの拡大であり、報告で承認できません。測定を繰り返す場合は、同じ質問と基準を再利用してください。質問が変われば、別の比較として扱います。
4. 確認した範囲と未確認の範囲を含め、台帳を返します。ネイティブのトラッカー、Git、実行時、決定的チェック、意味的判断の事実を混同しないでください。

Claim: <the claim as stated, and where it came from>
| # | Stated item | Disposition | Evidence, or what would settle it |
|---|---|---|---|
| 1 | <item> | confirmed / gap / unverifiable | <file:line, command output, artifact> |
Checked: <what was inspected>. Not checked: <what was not>.

台帳は証拠を報告するものであり、判定、準備状況の評価、PASS は含みません。

簡潔な回答はインラインで返します。選択した永続的な不足レポートではreality-check-report.v1を使用します。呼び出し元が選んだ保存先（デフォルトは.agents/scratch/reality-check/<run-id>/）にreality-check-report.jsonを作成し、このスキルのscripts/validate-output.sh <report.json>で検証してください。主張、証拠に裏付けられた所見の種類、項目ごとの判定をcoverageに記録します。この形式ではverdict、readiness、PASSの各フィールドは許可されません。観察結果は、独立した意味的判断ではありません。

要求された結果の確定

「完了した」「リリース済み」「修正済み」「すべての項目が完了」といった明示された主張を証拠と照合して確認する依頼であれば、追加の質問をせず、上記の主張比較を選択します。明示された目標の測定やネイティブなステータスの報告を求める依頼も同様です。主張も確定した目的も示されていない、単なる準備状況の質問は曖昧です。依頼者が助言としての所見を求めているのか、受け入れの判定を求めているのかを一度だけ尋ね、回答を待ちます。主張の監査は受け入れ判定ではなく、Validate による新たな、作成者とは別の評価の代わりにはなりません。受け入れ判定を求められた場合は引き継ぎ、新たなレビュアーがいないことは、検証が行われたかのように扱わず、未解決の問題として報告します。 共通の振り分けと引き継ぎの詳細： 助言または受け入れ判定。

ヘルススナップショット

「このリポジトリは健全ですか」または「チェックは合格しますか」と聞かれた場合は、プロジェクト独自の読み取り専用チェックを実行します。対象は、プロジェクトの指示や CI 設定に記載されているもの、またはビルドファイルで確認できるものです。--check、ドライラン、または検証用のバリエーションがあれば、そちらを優先します。追跡対象ファイルへの書き込み、公開、デプロイ、または認証情報を必要とするステップは、その理由とともに未実行として列挙します。何を選択したか、またその情報の出所を記録します。各チェックを個別に実行し、失敗後も続行して、後続の結果が失われないようにします。 各チェックの結果は、合格、失敗、ツールが利用できないため未実行、または出力を取得できなかったため判定不能のいずれかとして報告します。結果は出力の解析ではなく、終了ステータスに基づいて判定します。実行しなかった、宣言済みのチェックも明記します。何も修正せず、失敗を隠すような単一のスコアに結果をまとめないでください。

目標の測定

宣言済みの目標ソースと、その派生スナップショットを対象に ao goals を実行する方法、および返す内容については、目標を参照してください。目標の追加、削除、優先順位付け、移行、修復を行ったり、測定上の不足を割り当て済みの作業に変えたりしないでください。

ネイティブなステータス

エビデンスストアを ao status で読み取る方法と、スナップショットでは確認できない内容については、ステータスを参照してください。成果物のタイムスタンプが最近であることは、エビデンスが新しいことを示すものであり、作業者が稼働中であることを証明するものではありません。

境界

選択したレポートまたはスナップショットを返します。このスキルは、ネイティブな状態を変更したり、意味的な PASS を出したり、記録を修復したり、作業をスケジュールまたは再試行したりしません。出力に伴う副作用は、文書化された目標スナップショットと、要求されたレポート／仕様の書き込みだけです。許可された結果を目指すネイティブな依頼者は、これらの情報を用いて作業を続けます。レポートモードが依頼者に代わって完了を判断することはありません。