用途：db-temporal-history（M8）属于设计轴（Temporal 类别），跨范式适用，用于审计数据生命周期建模，避免已删除行被“复活”、出错时缺少审计轨迹，以及本应清除的数据带来的 GDPR/CCPA 暴露。
主要能力：检查软删除一致性，例如 deleted_at/is_deleted 列只出现在部分表，或缺少配套守卫，导致查询、唯一约束、外键忽略它（连接中复活已删除行、UNIQUE 冲突）；检查敏感表（财务、认证、权限、配置）是否缺少变更历史（无 _history/_audit 表、无时间列、无触发器/CDC）；检查保留与擦除，如 PII 无保留窗口、无清除/匿名化路径，或在法律要求实际擦除时仅用软删除；检查时间有效性，如需要 valid_from/valid_to 却只用单一时间戳、缺少 end_date >= start_date 的 CHECK。
严重度：PII 无保留/擦除路径为 severity 4、warn、confidence directional；软删除不一致且无查询/唯一守卫为 severity 3、warn；财务/认证表无审计轨迹为 severity 3、warn。M8 无 sev-5 上限。
使用方式：Tier-0 静态检查通过 scripts/parse-schema.mjs 解析 DDL/快照，检测软删除列是否一致出现于 UNIQUE/部分索引定义，查找敏感表的 _history/_audit 伴随表或时间列，标记含 PII（email、name、phone、address、dob）但无保留/擦除标记的表。Tier-1 验证查询示例（只读，$DATABASE_URL）：SELECT table_name FROM information_schema.columns WHERE column_name IN ('deleted_at','is_deleted') AND table_schema NOT IN ('pg_catalog','information_schema'); 以及复活检查 SELECT email, count() FROM users GROUP BY email HAVING count() > 1;。发现按 schema/finding.schema.json 输出，如 M8.users.pii_no_retention_or_erasure、M8.orders.soft_delete_inconsistent、M8.permissions.no_audit_trail，证据逐字引用相关 DDL/列（不回显 PII 值），verification.reproduce 为可运行查询，method 为 ddl_parse/schema_introspect/query_stat。
限制：GDPR/CCPA 适用性是法律判断而非 schema 事实，只标记暴露并交由人工裁定，不宣称罚款或违规成立；软删除本身是有效模式，只标记不一致；不虚构保留期或记录数，影响按区间标注并引用缺失机制。