retry-idempotency-checklisted

## Purpose 「リトライしたら二重に請求された」「同じデータが2行挿入された」を防ぐ。 べき等性の有無を確認し、リトライが安全に行えるフロー設計を保証する。 ## Use When - Webhook / API 呼び出しを含む自動化フローを設計する前 - Stripe Webhook の処理ロジックを設計・レビューする場合 - trigger-action-map の後に、リトライ安全性を確認したい場合 - 「このフロー、二重実行されたらどうなる?」が気になる場合 ## Inputs - **対象フロー・処理**: べき等性を確認する処理の説明 - **リトライのトリガー**: どのような条件でリトライが発生するか - **外部 API**: 呼び出す外部サービス（Stripe / Supabase / n8n 等） - **データ変更の有無**: DB への INSERT / UPDATE / DELETE が含まれるか ## Output Contract 1. **論点**: このフローのべき等性で最も危険な箇所 2. **根拠**: その論点をそう判断した理由 3. **べき等性評価**: 処理ステップ別の安全性確認 4. **含意**: べき等性の欠如が引き起こすビジネス・データへの影響 5. **改善案**: べき等キー・冪等性保証の実装方針 6. **代替案**: 別のリトライ設計・フォールバック方式 7. **判断材料**: リトライ設計の確定に必要な人間の判断事項 ### べき等性評価 フォーマット | ステップ | 処理内容 | べき等か | リトライ安全か | 対応が必要な理由 | |---|---|---|---|---| | 1 | | Yes/No/条件付き | Yes/No | | ## Review Lens - **目的妥当性**: べき等性確認が本来の安全性目的に対して有効か - **範囲の過不足**: 外部APIへの副作用（メール送信・決済等）を全て確認したか - **中長期リスク**: べき等キーの衝突・有効期限切れのリ��ク - **LAB全体との整合性**: Stripe Webhook のべき等性設計を含んでいるか - **非エンジニア理解可能性**: 「同じ処理が2回起きても安全か」を説明できるか - **他LLM移植耐性**: 設計が Claude 固有に依存していないか ## Instructions 1. フローの各ステップを「読み取り / 書き込み / 外部API呼び出し」に分類する 2. 書き込み・外部API の各ステップにべき等性があるか確認する 3. べき等キー（idempotency key）が必要な箇所を特定する 4. Stripe Webhook は `idempotency_key` の実装を必ず確認する 5. DB への INSERT は `ON CONFLICT DO NOTHING` または `UPSERT` を検討する 6. リトライ回数・バックオフ方針を定義する（無限リトライは禁止） 7. リトライが安全でない処理（メール送信等）の重複防止策を設計する ## Guardrails - 「リトライしない」をフォールバックとして採用する場合は、失敗の検知方法を必ず含める - べき等キーの有効期限を「無期限」にしない - Stripe の二重請求は特に慎重に確認する（テスト環境で必ず検証） - 「おそらく大丈夫」でべき等性を確認済みに