miniapp-devtools-gui-check

Miniapp Devtools GUI チェック

概要

CLI の preview では不十分で、ユーザーが GUI 側のランタイム証跡を必要とする場合にこのスキルを使用します。完全なビジュアルリグレッションではなく、スモークカバレッジに適しています。

クイックスタート

1. references/gui-check-playbook.md を読みます。
2. 実行が制限されたサンドボックス内ではなく、実際のホスト上で行われることを確認します。
3. アプリ全体ではなく、1 つのルートまたは 1 つのユーザーフローから始めます。
4. リポジトリがローカルの GUI チェッカーを提供している場合は、それを実行します。
5. 成功または失敗を主張する前に、生成された report.json を確認します。
6. report.json が存在しない場合は、リポジトリのコードを疑う前に、同じ実行ディレクトリ内の trace.log を確認します。

コアルール

• ホスト環境をテスト対象システムの一部として扱います。
• セッションが安定するまでは、「すべてのルートを一度に」よりも狭いスモークチェックを優先します。
• スクリーンショットよりも、ランタイム例外、コンソールイベント、ページパス、セレクターの存在を信頼します。
• スクリーンショットはベストエフォートの証跡として扱い、主要なシグナルとはしません。
• チェッカーを設定駆動型に保ち、ルートスペック、バックエンドの前提条件、出力場所を明示的にします。
• 実行ディレクトリに trace.log はあるが report.json がない場合は、まずステージごとに失敗を分類します。
  • ランチャーまたは websocket ステージは通常、DevTools セッションまたはホストのセットアップを意味します
  • ページステージは通常、ルートレベルのランタイムまたは状態の問題を意味します
• リポジトリのバグ、DevTools セッションの問題、ローカルサービスのブロッカー、および残りのビジュアルのみの疑問を分離します。

出力形式

回答する際は、結果を運用可能な形に保ちます。

1. どのルートまたはフローをチェックしたか
2. 自動化が実際に接続されたかどうか
3. どのようなランタイム証跡が収集されたか
4. 問題がリポジトリのコード、セッション状態、ローカルサービスの依存関係にあるのか、それともまだ手動のビジュアル確認が必要なのか
5. 次のコマンドまたはユーザーのアクション

リソース

• references/gui-check-playbook.md: ホストの前提条件、失敗の分類、レポートのガイダンス
• ../../tools/wechat-gui-check/README.md: 公開ハーネスの現在の抽出ターゲット
• references/example-prompts.md: 再利用可能なトリガー例と評価メモ