validate-ui

受け入れ確認 — UI

kimi-webbridge を使って、ユーザーの Chrome または Edge で実行中のアプリを操作します。 実際に画面に表示されている内容を確認しながら、クリック、入力、送信、再読み込みを行います。 コンポーネントテストではネットワークをモックしますが、これは接続されたスタックの動作を検証するものです。新しいヘッドレスブラウザーは別のセッションであり、この操作には該当しません。また、このスキルではヘッドレスブラウザーをインストールしません。

validate-feature から受け入れ確認台帳の一部を指定して呼び出すか、フロントエンドの変更に対して直接実行します。台帳の順に進めてください。

1. アプリを実行し、手順を記録する

docs/agents/project.md の Run locally (dev) を確認します。記録されているコマンドでフロントエンド（および呼び出すバックエンド）を起動します。記載がなければ起動方法を調べてアプリを起動し、ブラウザーで読み込めることを確認してから、コマンドを project.md の ## Run locally (dev) に記録してください。完了条件：アプリが読み込まれ、コマンドが記録されていること。

事前条件 — 認証、データ、環境。 フローにログイン済みセッション、シード済みアカウント、または環境設定が必要な場合は、リポジトリでの提供方法を調べて project.md に記録してください。ログイン済みのブラウザーがセッションです。ヘッドレスランナー用の storageState ファイルは作成しないでください。ログイン画面で進行が止まった場合は、ユーザーに操作用タブで一度サインインしてもらってから続行します。画面が空のままでは合格になりません。

UI／アクセシビリティ基準（任意）

読み込み先： skills/project/define-system-doc/consult-recipe.md。
パス： docs/standards/ui.md、docs/standards/accessibility.md。
承認済みの場合は参照し、存在しない場合は何もしません。重要な場合は /define-system-doc standards/ui|accessibility を一度だけ提案してください。自動で呼び出してはいけません。

2. 操作には kimi-webbridge を使う

kimi-webbridge スキルに従います。この機能のすべてのコマンドで、同じセッション名を使ってください。最初の navigate では newTab:true を指定します。find_tab に active:true を指定してユーザーのタブを借りてはいけません。デーモンが停止している場合は起動します。拡張機能が接続されていない場合は、そのスキルで指定されているヘルプページを案内して停止してください。今回の確認では @playwright/test、Cypress、その他のブラウザーハーネスをインストールしてはいけません。また、リポジトリにすでにブラウザーがあるからといって、新しいヘッドレスブラウザーでフローを操作してはいけません。完了条件：kimi-webbridge を介して操作用タブでアプリが開いていること、または拡張機能未接続による停止が記録されていること。

3. 各チェックリストのフローを操作する

台帳の UI 項目ごとに、ユーザーとして操作します。snapshot でロールまたは名前からコントロールを見つけてから、click または fill を実行します。画面上のテキスト、入力欄が空になったこと、リストの順序、エラーメッセージの表示など、目に見える結果を確認し、そのテキストを台帳に引用して記録してください。条件に「保持される」とある場合は、同じ URL に再度 navigate して状態が維持されていることを確認します。サーバーに保存された内容を確認する場合は、操作の前に network の start を実行し、stop の前に detail を実行して、ステータスとレスポンスの事実を記録します。要件 ID はアプリケーションのソースではなく、台帳に対応付けてください。

4. 問題を切り分ける

失敗を見過ごしてはいけません。失敗したフローをもう一度操作します。

• ユーザーに見える結果での再現性のある失敗 — 誤ったテキスト、誤ったステータス、表示されるはずの要素の欠落など — はプロダクトの不具合です。必須サブスキル： root-cause を使用してください。失敗を再現するループは、同じ webbridge による操作であり、新しいブラウザースイートではありません。修正の回帰テストは、test-first を使ってリポジトリの既存テストスタックに追加します。
• 非決定的な失敗（再操作では成功する場合）または操作上の問題 — 一致しなくなった参照、待機処理の不足、シード状態の欠落など — は、別のハーネスを立ち上げるのではなく、操作手順を修正します。

root-cause に進むのは、実際の結果で再現性のある失敗があった場合に限ります。 完了条件：すべての UI フローが、新しい webbridge 操作で合格すること。

5. 操作結果を記録する

.skills/<CODE>/validate-ui.md に、各フローのブロック、引用した画面上のテキスト、再読み込みの結果、合否を記録します。このファイルが受け入れ確認の証拠になります。結果を台帳にも記録してください。今回の確認でブラウザーハーネスのテストスイートをコミットしてはいけません。完了条件：記録がディスクに保存され、そのすべてのフローが合格していること。

もっともらしい理由付け

考え	実際のところ
「Playwright がないので、インストールして CI で再実行すればよい」	このパスで使うのはユーザーのブラウザーです。ここではそのためのテスト環境を作成しないでください
「ヘッドレスのほうが信頼性が高い」	それは別のセッションです。サインイン済みブラウザーが必要なフローは、そこで実行できません
「リポジトリにはすでにブラウザーテスト一式があるので、それを動かせばよい」	そのままにしてください。この受け入れ確認でも、引き続き kimi-webbridge を使います
「ログイン画面が表示されるなら、機能が失敗したということだ」	ドライブ用のタブで一度サインインし、その後続行してください

注意すべき兆候

• このパスのためにブラウザーテストの依存関係や設定を追加する
• 新しいヘッドレスブラウザーで記録されたパス
• active:true を指定した find_tab
• ログイン画面のスクリーンショットをフローの結果として扱う