ADR 0005: 管理画面を React Router v7 フレームワークモードで構築する
補足 (2026-06)
単一 Worker 化（ADR 0006）に伴い、構築する場合は別アプリではなく bot と同一の Worker に RR7 framework モードを載せる（noisy-crow-web と同型）。tied-bot に既存の管理 UI はないため、本 ADR の実装は移行完了後の後続フェーズとする。
Context
tied-bot には管理 UI が存在せず（Next.js は Slack / Inngest webhook の受け口専用）、tied-workspace 統合に合わせて管理画面を新規構築する。要件として React Router v7 の採用が確定している。
参考に、既存の noisy-crow-dashboard は Vite + react-router v7（ライブラリモード）の SPA を Cloudflare Pages にデプロイし、別の Hono API Worker からデータを取得する 2 層構成になっている。
管理画面は D1（reactions / memories）、Vectorize（意味検索）、R2（master-data）を横断して読む必要がある。
Decision
- 管理画面は React Router v7 のフレームワークモード（旧 Remix / SSR・loader・action） で構築する。
@react-router/dev+@react-router/cloudflareを用い、react-router.config.tsで SSR を有効化して Cloudflare Workers にデプロイする。 - loader / action からサーバーサイドで D1・R2・Vectorize・KV のバインディングに直接アクセスする。これにより
noisy-crow-dashboardのような別 API Worker を設けない（SPA + API の 2 層分離をしない）。 - 認証は Cloudflare Access (Zero Trust) に委譲し、アプリ層に認証ロジックを置かない。
Consequences
- 良い点: SSR により loader/action で各 Cloudflare リソースへ直接アクセスでき、別 API レイヤーが不要で構成が単純。データ取得・変更がルート単位に閉じ、型も共有しやすい。
- 悪い点 / 注意: tied-workspace にフレームワークモードの RRv7 は新パターン（既存はライブラリモードの SPA）。ビルド・デプロイ（Workers アダプタ）と CI を新たに整備する必要がある。Cloudflare Pages へ寄せる既存ダッシュボードとデプロイ先が分かれる点に留意。
- フォローアップ: ルート設計（
/,/reactions,/memories,/search,/master-data,/jobs）と、Workers のバインディング・wrangler.toml・Cloudflare Access 設定を確定する。
Alternatives
- 既存
noisy-crow-dashboardと同型（Vite SPA + react-router v7 ライブラリモード + Hono API Worker）: monorepo の一貫性は高いが、別 API レイヤーが必要で、要件のフレームワークモードに合致しない。却下。 - VitePress 等の静的サイトに埋め込む: 動的データ参照・操作（ジョブtrigger 等）に不向き。却下。