browserflow inspectが読むものと同じソースです。
実行履歴 — /runs
/runsは、組織全体を対象にしたセッションスコープの実行インデックスです。所有するすべてのオートメーションにわたるすべてのRunが新しい順で並び、状態ドット、オートメーション名、状態バッジ（成功 / 失敗 / 実行中 / 待機中）、タイムスタンプが表示されます。行を選択すると、そのRunのInspectorである/automations/[id]/runs/[runId]に移動します。
この一覧は、セッション認証された
GET /api/runsを読みます。これは、あなたのオートメーションを経由するJOINによってあなたの組織にスコープされます。エンジン自身の素の/runsではありません。この分離が重要な理由は、Jinba Trailとはのセキュリティノートを参照してください。/runs/[id]（パス内にオートメーションを含まない素のRun ID）も解決されます。ただし、これはレガシーリダイレクト専用です。RunをIDで検索し（run-ref idと基盤エンジンのrun idのどちらも受け付けます）、以下の詳細な/automations/[id]/runs/[runId] Inspectorへ転送します。新しく作るものでは、オートメーションスコープのURLに直接リンクしてください。素の形式は、古いブックマークやリンクを動かし続けるためだけに存在します。Run Inspector — /automations/[id]/runs/[runId]
Runを開くと、上から下へ積み重なった4つのものが表示されます。ヘッダー、任意のライブブラウザーペイン、手順トレース、マスク済み出力、完全なJournalログです。
ヘッダー
状態ドットとバッジ、呼び出し元（API呼び出しの場合はapi_key:<id>）、所要時間、そしてオートメーションのライブなバージョン、つまりこのRunが実行された時点でのFlowのcontent-addressed digestが表示されます。Journalがまだストリーミング中の間は、ヘッダーの横にライブインジケーターが表示されます。Runが終端状態に達すると、このインジケーターは消えます。
このRunがlocator mismatch（記録された要素がライブページと一致しなくなった状態）で失敗した場合、ヘッダーのすぐ下にReRecordBannerが表示され、タスクを再記録するためにBuild（/automations/[id]/build）へ直接ディープリンクします。完全な復旧フローは、トラブルシューティング: 「サイトが変わったため再記録する」を参照してください。
ライブブラウザー表示 — Runが進行中の間のみ
Runの状態が実行中または待機中のときだけ、InspectorはGET /api/automations/[id]/run-liveへのWebSocketを開き、ライブブラウザーペインを表示します。これは、決定論的リプレイが操作している実際のChromiumセッションをフレーム単位でストリーミングしたものです。これはBuild Studioがオーサリングに使うものと同一のLiveBrowserコンポーネントで、ここではオンデマンドRunのために再利用されています。「シミュレーションではなく実際のブラウザーを見ている」という保証も同じです。Runが実行中/待機中を離れた瞬間に、ペインはアンマウントされ、ソケットも閉じられます。
このペインはRun IDではなく、オートメーションIDをキーにします。同期Runが完了するまで呼び出し元はRunのIDを知ることができず、その時点では見るものが残っていないためです。そのため、リレーはオートメーション配下に登録され、その特定のRunが終わると破棄されます。
手順トレース
同じJournalリプレイ上でディスパッチされる、手順ごとのライブタイムライン（トレース）です。各手順には、状態ドット、名前、そして失敗時にはDomainErrorコード、リトライ可能かどうか、不要部分を取り除いたエラーメッセージが表示されます。失敗コードがtool.browser.locatorで始まる手順は、上記のページレベルのReRecordBannerと一致する形で、locator mismatchとしてインライン表示されます。
出力
Runの記録済み出力が、投影されたrun.outputから整形済みJSONとしてレンダリングされます。Runが出力を生成しなかった場合は、単純な「出力は記録されていません」カードが表示されます。シークレットは常にマスクされます。シークレット由来の値は記録時に{secret:<slot>}プレースホルダーとしてJournalに記録され、平文が記録されることはありません。そのため、Inspector内のどのビューでも、どのロールでも、生の値を表示することはできません。この境界が上流でどのように強制されるかは、シークレットを参照してください。
完全なログ — 順序どおりの完全なJournal
最後のセクションは、上にある折りたたまれた手順ごとのロールアップではなく、順序どおりのJournal全体です（GitHub #56）。これは手順トレースと同じSSE replay-then-tail（GET /api/runs/:id/stream、組織スコープ、2本目の接続なし）からストリーミングされるため、トレースやヘッダーと同期が外れることはありません。トレースとは異なり、折りたたみビューが意図的に落としているすべてのエントリタイプが含まれます。
| エントリ | 表示内容 |
|---|---|
run_started | flow digest + inputs digest（切り詰め） |
step_started | 試行番号 |
step_succeeded | output digest |
step_failed | エラーコード、メッセージ、リトライ可能フラグ |
step_skipped | スキップの理由 |
effect_recorded | 冪等性キー → result digest |
run_finished | 終端状態（成功 / 失敗 / キャンセル） |
run_finishedでのみ閉じるため、すでに完了したRunでInspectorを開いても完全なログが表示されます。Runをライブで見る場合に限定されません。
関連
トラブルシューティング: サイトが変更された場合
locator mismatchによる失敗の意味と、再記録バナーが公開済みに戻す流れ。
Build Studio
ReRecordBannerがディープリンクする、記録 → レビュー → 公開のループ。
PlaygroundとAPIキー
このページが検査するオンデマンドRunをトリガーします。
Run Inspectorと可観測性（エンジン）
このページのInspectorがホスト型ビューとして扱う、基盤のBrowserflow Journalモデル。