チャットアプリの内蔵ブラウザのような、開発者ツール（console・networkタブ）を开けないホスト環境では、「実 Chromeでは成功するのに内蔵ブラウザだけ失敗する」種の不具合を、ログやスクリーンショットだけで切り分けようとしても手助けがない。なぜ失敗しているか（未初期化なのか、タイムアウトなのか、不対応確定なのか）を外部から区別できない。

適用条件: 対象ホストがdevtoolsを使えない（または使いづらい）埋め込み環境で、非同期な初期化（ホストAPIの注入待ち、能力登録など）を含む場合に重要。通常のWeb開発（自分のChrome DevToolsで即座に確認できる）なら不要。

対処方法: 非同期初期化の重要な状態遷移（例: waiting→registered(n)→unsupported）を公開 APIとして公開し、ページ上の控えめな1行表示（例: フッターのステータス行）で常時見えるようにする。表示はローディング中の画面でも隠さず、可能な限り早い段階から存在させる。リスナー接続パターン（setter関数で後付け接続し、接続直後に現在値を即時再送信する）にすると、フレームワークコンポーネントがどのタイミングでmountしても遷移を取りこぼす。

確認方法: 実ホスト環境（今回はChatGPTアプリ内蔵ブラウザ）での検証中、開発者はスクリーンを見てこの1行だけで「リトライ中か、確定失敗か、登録済みか」を判別できる。自動テストでも同じセレクタを問い合わせて状態遷移を直接検証できるので、行卐採取やスクリーンショット目視より安価な回帰テストになる。

教訓: 「内部実装の状態はconsole.logで十分」という直感は、自分のツールで検証できる間は正しいが、対象ホスト自体がdevtoolsを提供しない場合は成り立たない。その場合の最小コストな代替手段は、重要な非同期状態をUI自体に常時可視化すること。