sb-flows

sb-flows — 監査の接続部分

ルート一覧だけでは網羅性を証明できません。フローグラフにはエッジと永続的なナビゲーションソースが必要です （サイドバー／ヘッダー／フッターのリンクはすべての画面に表示され、ページ本文の走査では検出されません。監査で最も見落とされやすい点です）。マッピングの前に references/flow-capture.md を読み込んでください。

実行する

SKILL=${CLAUDE_PLUGIN_ROOT:-${CLAUDE_PLUGIN_ROOT}}
CORE=${CLAUDE_PLUGIN_ROOT:-${CLAUDE_PLUGIN_ROOT}}
"$SKILL/scripts/extract-flows.sh"      # 1. generic first pass → .storybook/flows.json (routes + edges + navSources)
"$CORE/scripts/scaffold-wrapper.sh" --flow   # 2. AppFlowGraph + JourneyGraph (+ icons.tsx)

# 3. The app-graph the wrappers actually render (edges with ACTION labels, deep store/service
#    tracing, role lanes, component lists). Copy the reference template, ADAPT its 3 marked blocks
#    to this repo's router/nav/role-gate, then run it. It writes app-graph.json + component-pages.json.
cp "$SKILL/templates/extract-app-graph.mjs" .storybook/scripts/extract-app-graph.mjs   # then edit ADAPT-1/2/3
node .storybook/scripts/extract-app-graph.mjs

抽出ツールがナビゲーション用のクロームを検出したときに出力する走査リマインダーに対応してください。また、⚠ LIKELY UNDER-EXTRACTION が出力された場合は、flows.json をドラフトとして扱ってください。アプリは、スクリプトがまだ解析できないイディオム（nanostores クラスの見落とし）で遷移しています。edgeCount を鵜呑みにせず、一覧にある未照合の呼び出し箇所を読み、実際のエッジを特定してください（正規表現を増やすより、リポジトリ内のソースを考慮したリゾルバーが有効です）。そして、汎用的なイディオムを extract-flows.sh に反映してください。全体の手順については references/flow-capture.md → "When extraction under-reports." を参照してください。

深いエッジ（浅いパスだけで終わらせないでください）。 ストア／サービスのアクション（または深くネストされた機能コンポーネント）から呼び出されるナビゲーションには、それ自体の画面がありません。実際の起点は、それを呼び出す側です。テンプレートの moduleOrigins は、再エクスポートを考慮してこの起点を追跡します（バレルをたどるため、ストア経由で再エクスポートされたサービスも、ストアのインポートトークンから見つけられます）。インポートグラフをたどってルーティングされたページまでさかのぼります。これにより、浅いパスでは取りこぼされていた実際の switchToHotel → scheduler エッジを復元できました。references/flow-capture.md → "Deep-edge tracing" で確認してください。

検証 — 存在しないエッジを捏造しないでください。 仕様では、すべてのエッジにファイルと行の出典情報が必要です。帰属先を特定できないものは、捏造せずに unresolvedEdges／dynamicCallSites に記録します。実行後、node -e で JSON を確認してください。unresolvedEdges は少数で、それぞれの理由が正直に記録されている必要があります（ルートがない 404、真に動的なディスパッチなど）。また、module-trace エッジをいくつかソースと照合してください。references/flow-capture.md → "Validate the graph." を参照してください。

モデル化する

• <AppFlowGraph graph={...}> — アプリ全体のルートマップです。ロール別のスイムレーン、型付き／色分けされたエッジ、網羅性の色分け、クリックしてストーリーを表示する機能を備えています。flows.json から派生した AppGraph を渡してください。
• <JourneyGraph journey={...}> — 1 つのフローのジャーニーマップです（Docs インデックスの Flows/*）。各ステップは storyId で、その状態ごとのストーリーにリンクします。デフォルトでは「フローの追加方法」という折りたたみ済みの作成ヒントが表示されます（hideAuthoringHint で非表示にできます）。「これは何？」という出典バナーはデフォルトで表示されます（フローマップはレポートです）。setProvenance(false)／__SB_WB_PROVENANCE__ = false を指定すると全体で非表示になり、hideIntro を指定すると 1 つのマップだけで非表示になります。 journey は厳選されたナラティブ、つまり、キャプチャされたグラフをたどる 1 人のペルソナの経路であり、flows.json のフィールドではありません（flows.json には AppFlowGraph が描画するルートノードとエッジが格納されます）。
• どちらも差し替え可能な icons プロパティを受け取ります（lucide／プロジェクトのアイコンを渡してください）。絵文字は使わないでください（CONTEXT.md §wrapper-view-design）。
• 固定のカラーパレットではなく、アプリのトークンでテーマを設定してください。 クローム（パネル、テキスト、枠線、レーンのストライプ）は var(--color-foreground|surface|border-subtle|muted-foreground, <fallback>) を読み取ります。そのため、.dark を切り替えるだけでマップ全体のライト／ダークが切り替わり、トークンがないアプリでもフォールバックによって描画できます。リテラルのままにするのは、データのエンコーディングだけです。網羅性を示すドットと EdgeKind ごとの色相はカテゴリを表すもので、クロームではありません。クロームの var() をハードコードした色に置き換えないでください。

重要なルール

• すべてのナビゲーションソースを網羅してください。ページ本文だけでなく、flows.json.navSources[] も対象です。
• ルートだけでなく、エッジも記録してください。flows.json.edges[] が対象です。
• ロールを調査してください。同じアプリでも、ペルソナごとにグラフが異なります。flows.json には、各ルートのaccess（public/user/admin。パスに基づく推定）とroleSignals[]（実際のガード）が記載されています。ガードに照らしてアクセス権を検証し、グラフをロールごとのレーンに配置（node.role = route.access）して、境界をまたぐ経路を監査してください。匿名ユーザーがユーザールートに到達できるか？ユーザーが管理者ルートに到達できるか？flow-capture.md → **「Step — explore roles.」**を参照してください。
• ページ／フローは実際の幅でレンダリングしてください。layout: 'fullscreen'とデスクトップのビューポートに加え、モバイル表示も使用し、幅の狭い中央揃えのキャンバスは使わないでください。ドキュメント化する状態ごとに、独立したフル幅のストーリーを作成してください。
• 番号付きの名前はN · labelの形式にし、storyIdでリンクしてください（flow-capture.mdを参照）。

次の手順

調査結果を追記し、各画面の状態についてsb-storiesを実行するか、網羅性を確認するためにsb-auditを実行してください。