db-temporal-history

db-temporal-history（M8）

データにはライフサイクルがあります。作成され、変更され、廃止され、法的要件により消去しなければならない場合もあります。このライフサイクルを明示的にモデル化することで、「削除済み」の行が復活したり、問題発生時に監査証跡が失われたり、本来消去すべきデータが残ってGDPR/CCPAへの違反リスクが生じたりするのを防げます。このモジュールは設計軸（Temporal カテゴリ）です。パラダイムを問わず適用されます。

チェック内容

• 論理削除の一貫性：一部のテーブルには deleted_at/is_deleted 列があるのに、ほかのテーブルにはない、あるいは対応するガードがない状態です。論理削除を考慮しないクエリ／UNIQUE 制約／FK によって、JOIN で削除済みの行が復活したり、UNIQUE 制約で競合したりします。M5 の過剰な NULL 許容による UNIQUE の落とし穴に関連します。
• 監査／履歴の記録：機微なテーブル（金融、認証、権限、設定）に変更履歴（*_history/*_audit テーブル、テンポラル列、トリガー／CDC）がない状態です。問題が起きても、誰がいつ何を変更したのかを確認できません。
• 保持と消去（GDPR/CCPA）：PII の保持期間がなく、削除／匿名化の方法も文書化されていない状態、または実際の消去や匿名化が法律で必要な箇所に「論理削除」を使用している状態です。M10 の PII 検出も参照してください。
• 時間的有効性：双時制／有効期間付きデータで、valid_from/valid_to が必要なのにタイムスタンプを 1 つしか使っていない状態です。また、end_date >= start_date の CHECK 制約がない状態です。

軸と重大度

• 軸：設計。影響度は段階で示し、記録件数や罰金額を捏造しません。
• 保持／消去方法がない PII（コンプライアンス上のリスク）：重大度 4、warn、信頼度 directional（法的な適用可否には人間によるレビューが必要です。自動的に上限を設けてはいけません）。
• クエリ／UNIQUE 制約のガードがない、一貫性を欠いた論理削除：重大度 3、warn。
• 金融／認証テーブルに監査証跡がない：重大度 3、warn。
• M8 には重大度 5 の上限はなく、Temporal カテゴリの値に影響します。

Tier-0 静的チェック

scripts/parse-schema.mjs を使って DDL／スナップショットを解析し、論理削除列を検出して、一貫して存在するか、UNIQUE／部分インデックスの定義に含まれているかを確認します。機微なテーブルに対応する *_history/*_audit テーブルやテンポラル列があるかを確認し、保持／消去を示す要素がない PII を含むテーブル（email、name、phone、address、dob）に警告を出します。静的チェックのため、信頼度は directional です。

Tier-1 検証クエリ

論理削除に対応する監査用テーブルがないテーブルを特定し、論理削除された行が「一意」キーを引き続き満たすことを確認します。

-- $DATABASE_URL, read-only
SELECT table_name FROM information_schema.columns
WHERE column_name IN ('deleted_at','is_deleted')
  AND table_schema NOT IN ('pg_catalog','information_schema');
-- resurrection check: deleted rows colliding on a natural key
SELECT email, count(*) FROM users GROUP BY email HAVING count(*) > 1;  -- if soft-deleted dupes appear

検出結果

schema/finding.schema.json に従って出力します。例：

• M8.users.pii_no_retention_or_erasure — 保持期間も削除／匿名化の方法もない PII 列（重大度 4、warn、軸 design、信頼度 directional）。
• M8.orders.soft_delete_inconsistent — deleted_at があるものの、JOIN／UNIQUE 制約がこれを考慮せず、削除済みの行が復活する状態（重大度 3、warn、軸 design）。
• M8.permissions.no_audit_trail — 認証上重要なテーブルに変更履歴がない状態（重大度 3、warn）。 各検出結果では、evidence.observed に該当する DDL／列をそのまま引用します（PII の値は決して出力しません）。verification.reproduce には、上記の実行可能なクエリを指定します（method: ddl_parse / schema_introspect / query_stat）。expected_impact は段階と信頼度を付けて示します。

誠実さ

• GDPR/CCPA の適用可否は法的判断であり、スキーマから判断できる事実ではありません。消去方法がないことによるリスクを信頼度 directional で示し、法的判断は人間に委ねます。罰金や違反が確定したかのように述べてはいけません。
• 論理削除は有効なパターンです。一部のテーブル／クエリでは考慮され、ほかでは考慮されないといった不整合のみを検出し、使用そのものを問題にしてはいけません。
• 保持期間や記録件数を捏造してはいけません。数値ではなく、影響度を段階で示し、不足している仕組みを根拠として挙げます。