Skip to content

2026-08-08 failed 状態の記録手段(Issue #8)

  • 課題: failed は状態機械に定義されているのに管理画面から設定できず、Runbookが直接DB書き込みを案内していた。直接書き込みは application_events を経由しないため、オンチェーン操作の失敗という最も記録が必要な場面で監査証跡が残らなかった。
  • 決定: /admin に「Allowlist 失敗として記録」「配布 失敗として記録」を追加し、failed への遷移も他の操作と同じ Server Action と監査記録の経路を通す。
  • 失敗理由: 必須にする。Runbookが「承認者が理由を記録したうえで」と定めており、再試行の判断材料になるため。空白のみの入力は理由なしとして扱う。理由入力は失敗操作にのみ追加し、却下理由が固定値("運営判断")である点は別課題として残す。
  • 申請者への表示: failed は「運営が対応中です」と表示し、pending(未実施)と区別する。失敗の詳細は申請者側で対処できないため出さない。表示文言はコミュニティで確定するまでの暫定とする。
  • 状態機械は変更しない: failed -> failed は許可しないままとする。2回目以降の失敗の経緯は運用ログへ記録する運用とし、画面から複数回記録する必要が出た時点で再検討する。

秘密情報(SESSION_PASSWORD、Supabaseキー、Safeの認証情報)はドキュメント・Issue・ログへ貼らないでください。