金銭・管理操作の監査ログ(append-only)を初期から用意すると決める

背景

誰がいつ請求を確定・価格を変更・管理者を付与・返金したか、という金銭・管理操作の証跡を残す仕組みが無い。

なぜ今決めるか

監査証跡は記録し始める前の操作を後から復元できない。可観測性一般(メトリクス・トレース)は加算的に足せるが、金銭・権限操作の監査ログだけは事後に遡れない。#15 で変更系を解禁し #18 で管理者操作を入れる前に、それらを記録する受け皿を先に決める必要がある。

論点・選択肢

• 置き場所: 独立した append-only の audit テーブルにするか、お金の記録の台帳に統合するか。
• 記録項目: actor(プリンシパル)・操作・対象種別/ID・前後値・リクエスト ID・時刻。
• 強制ポイント: 変更系プロシージャが必ず監査行を書くようにする(packages/api/src/orpc.ts の assertMutationsEnabled と同じ層に監査フックを置くか)。
• actor の一意記録: 現役 traQ セッションのプリンシパルと、再入部時のメール確認プリンシパル(#16)の双方を一意に記録できるかを認証の設計と合わせる。
• メトリクス/トレース等の一般可観測性は加算的なので暫定/後回しでよい(seam だけ意識)。

受け入れ条件

• 監査ログのテーブル形状と「変更系は必ず監査行を書く」規約が決まり、変更系が本格稼働する前に受け皿が用意されている。

関連

#15(認可でプリンシパルが確定)・#18(管理者操作)の前提となる横断基盤。お金の記録アーキテクチャと接続する。

Start by reading packages/api/src/orpc.ts, especially assertMutationsEnabled, and the related decisions in #15, #16, and #18. Compare the proposed standalone append-only audit table with integration into the money ledger, including actor, operation, target, before/after values, request ID, and time. Done means the table shape and mandatory-audit convention are decided before mutation and administrator operations become active.