failure-point-reviewlisted

## Purpose 「動いているときは考えない」障害シナリオを、事前に潰す。 SPOF（単一障害点）・カスケード障害・サイレント障害を発見し、許容できる障害と対処が必要な障害を区別する。 ## Use When - 自動化フローのリリース前 - システム統合（Stripe / Supabase / n8n 等）の設計レビュー - trigger-action-map の後に障害シナリオを深掘りしたい場合 - 「このフロー、何か見落としていないか」という不安がある場合 ## Inputs 以下を準備すること。不足している場合は推測せず、不足を明示する。 - **対象フロー**: 障害点を確認するフロー・システムの説明 - **依存サービス一覧**: 外部API・DB・メッセージキュー等 - **許容ダウンタイム**: 各コンポーネントの許容停止時間 - **現在の監視**: 今どのような監視が存在するか（ない場合は「なし」と明示） ## Output Contract 以下の順で出力すること。順序を変えない。 1. **論点**: このフローで最も危険な障害点はどこか 2. **根拠**: その論点をそう判断した理由 3. **障害点マップ**: 分類別の障害シナリオ（後述フォーマット） 4. **含意**: 障害パターンが示すアーキテクチャの脆弱性 5. **改善案**: SPOF の解消・検知性の改善・フォールバック追加 6. **代替案**: アーキテクチャを見直して障害リスクを根本的に下げる案 7. **判断材料**: 「対応必須 / 後回し / 受容」を決めるための情報 ### 障害点マップ フォーマット | 障害点 | 種別 | 影響度 | 検知可能か | 対応方針 | |---|---|---|---|---| | （障害の説明） | SPOF/タイムアウト/データ破損/サイレント失敗/カスケード | 高/中/低 | 自動/手動/不可 | フォールバック/リトライ/受容/修正 | 種別の定義: - **SPOF**: ここが止まると全体が止まる - **タイムアウト**: 応答が遅い・返ってこない - **データ破損**: 誤ったデータが書き込まれる - **サイレント失敗**: エラーにならずに失敗している - **カスケード**: 一部の障害が連鎖して全体に波及する ## Review Lens - **目的妥当性**: 列挙した障害点がシステムの目的に対して有意か - **範囲の過不足**: サイレント失敗・カスケード障害を見落としていないか - **中長期リスク**: 今は発生しないが、スケール時に顕在化する障害がないか - **LAB全体との整合性**: Stripe / Supabase / n8n のそれぞれの障害パターンを含んでいるか - **非エンジニア理解可能性**: 「このシステムが止まると何が起きる」を説明できるか - **他LLM移植耐性**: 障害分類が Claude 固有の基準に依存していないか ## Instructions 1. フローを構成する全コンポーネント（外部API含む）をリストアップする 2. 各コンポーネントに対して「止まったら何が起きるか」を記述する 3. SPOF を特定する（ここが止まると他も全部止まるポイント） 4. タイムアウト・応答遅延シナリオを列挙する 5. データ不整合・二重処理・欠損のシナリオを列挙する 6. サイレント失敗（エラーにな