ui-review

UI レビュー

レンダリング結果が証拠です。説明、DOM テキスト、ソースコードは、それを補足するにすぎません。重大度、13 項目の基準、エッジケースについては references/criteria.md を参照してください。インストール済みのデザインシステム独自のルールがある場合は、そちらを優先し、合意済みの基準として扱います。

手順

1. 対象範囲。 呼び出し元が指定した画面、指定がなければブランチで変更された画面、それもなければ上位 5 つのルートを対象にします。
2. リント。 対象ファイルに対してプロジェクト独自のリントを実行します。コマンドと終了コードを記録します。
3. キャプチャ。 各画面を各幅（アプリの最小幅と最大幅。デフォルトでは 390 と 1280）で、重要な状態をそれぞれキャプチャします。幅ごとに、新しいナビゲーションを 1 回行います。build-design-system がインストール済みの場合、build-design-system/scripts/capture.mjs はすべての書き込みをブロックするガードのもとでこれを実行し、各キャプチャのアクセシビリティツリーを保存します。アプリの書き込みを一覧にした --writes <file>、または --no-backend が必要です。書き込み先は --out フォルダーだけです（.ui-review/ の下にしてください）。それ以外の場合は、ホストのブラウザーツールを使用し、ツリーを手動で保存します。プロジェクトにアクセシビリティスキャナーがある場合は、それも実行します。
4. 各画面の目的を 1 行で修正します。呼び出し元から目的が示されていない場合は、「仮定」と記します。
5. 各画面の落とし穴を確認します。ローカルビルドのみで、キーボード操作の経路、閉じた後のフォーカス、読み込み状態とエラー状態、スロットルをかけたタブ、動きを抑える設定、タッチ操作時の幅を確認します。各確認について、測定結果または実行しなかった理由を記録します。Event Timing API（event エントリーを監視する PerformanceObserver を使用し、各 duration が 100 ms 未満であること）で押下時のフィードバックを測定します。共有データに書き込む操作はクリックしないでください。
6. 各幅で基準を確認します。各指摘には、番号と基準名、またはインストール済みルールの ID を記載します。
7. 分類。 レビュアーが複数いる場合（パネル）は、全員に同じプロンプトを渡し、ペルソナを設定せず、読み取り専用でレビューしてもらいます。次にコーディネーターが、各指摘を blocking、should-fix、note、dismissed のいずれかに分類し、提起した人の名前と理由を 1 行で記載します。2 人のレビュアーがそれぞれ独自に挙げた指摘は、最も強いシグナルです。細かすぎる指摘、実際の呼び出し箇所に紐づけられていない仮定、そして「自分なら別の方法にした」という意見は却下します。各分類内では、データを書き込む画面を先にし、その後、影響を受ける箇所の数順に並べます。パネルがない場合も、同じ手順を 1 人で行います。
8. エッジケースを確認し、それぞれが表示されたかどうかを記します。
9. 最後に判定を書く。

ルール

• 指摘には、基準、特定可能な場所（キャプチャを添えた要素のロールと名前。例：button 'Save changes' (settings-1280.png)）、幅、証拠が必要です。好みに基づく指摘は除外し、「対象外」にします。
• 悪い例：「余白が詰まっているように感じます。」良い例：「ラベルは自身のフィールドから 24 px、次のフィールドから 8 px の位置にあります（基準 4、settings-390.png）。」
• 推測に基づく指摘は、それを確定するための確認事項として記載します。推測に基づく blocking の指摘がある場合、判定は no, pending <the check> とします。
• 動作する、または修正済みとする主張には、このセッションで使ったコマンドまたはキャプチャを明記します。
• コントラスト、ターゲットサイズ、キーボード操作の問題は優先度を付けます。意味情報を追加するだけのアクセシビリティツリーの変更にも優先度を付けます。意味情報を削除または再構成する変更は、担当者に委ねます。
• 入力への応答性（基準 13）について、スクリーンショットに基づく指摘や合格判定は無効です。測定した確認が必要です。フォーカスリングは逆です。実際に Tab キーを押してコントロールに移動し、キャプチャ上でリングを評価してください。:has(:focus-visible) を通じてリングを描画するコンテナでは、フォーカス中の要素がアウトラインなしと報告するためです。
• 修正に関するプロダクト上の判断は、「担当者の判断が必要」にします。ユーザーの入力を保持することは、決してその対象にしません。

出力

最初の行では、依頼への回答を平易な言葉で示します。続けて出荷可否の行を記載します：Ready to ship: no. Enter in Email cancels the invite (blocking 1, should-fix 2, 3 questions for a person). blockingの指摘が1つでもあれば判定はno、推定による指摘がある場合はno, pending <the check>、should-fixのみならyes, with fixes、注記のみならyesです。

続けて、以下の順に記載します。

1. レビュー記録。 ソース、ツール、幅、日付、基準ファイル、目的が提示されたものか推定したものか、すべての前提と不足情報。
2. 指摘事項を分類ごとに記載し、それぞれについて、指摘者、確認した内容、場所、基準、今回それが重要な理由、証拠、現行ビルドで失敗するチェックとしての修正内容（Fix Enter in Email so that it sends 1 POST）を示します。
3. 確認できなかったエッジケース。 1行につき1項目。
4. 人が判断する事項。
5. 却下して対象外とした事項。 指摘者とその理由をそれぞれ記載します。

単独で実行し、レポートを.ui-review/<date>-<flow>.mdに保存し、キャプチャもその隣に保存します。コーディネーターからキャプチャのみを求められた場合は、キャプチャのパス、幅、Coverage:行を返し、指摘事項は記載しません。チャットの返信には回答行と出荷可否の行、各コマンドとその終了コード、次のステップに進むために人が貼り付けられるプロンプトを1つ記載します。

完了条件

すべての指摘事項に、基準、場所、証拠、および該当する幅のみが記載されています。すべてのプローブに結果または実施しなかった理由があります。最初の行、出荷可否の行、要約の内容が一致しています。最後の行はCoverage:で始まり、測定したルート、幅、テーマ、プローブに続けて、未確認の項目を記載します。