关于 db-temporal-history
db-temporal-history 是聚焦数据生命周期设计的数据库架构审查技能。它会标记软删除不一致、审计历史缺失、保留或擦除路径不明确及时间有效性问题,但不会断言法律结论。
主要功能
- 01检查软删除一致性和查询保护
- 02查找缺失的审计与历史机制
- 03标记缺少保留或擦除路径的 PII
- 04检查时间有效性和日期约束
- 05提供证据及带置信度的影响评估
适用场景
- 01审查架构中的软删除是否一致
- 02定位缺少变更历史的敏感表
- 03识别未记录清除路径的 PII
- 04检查有效期数据表的约束
安装
复制下面的命令,在终端中运行。
$
npx skills add https:/ / github.com/ hainrixz/ claude-db --skill db-temporal-history安装后在 Claude Code 中输入/db-temporal-history确认已加载。
详细介绍
db-temporal-history(M8)
数据具有生命周期:创建、变更、停用,而且在法律要求下,有时必须删除。明确建模这一生命周期,可以避免已“删除”的行死而复生、出错时缺少审计轨迹,以及因本应清除的数据而面临 GDPR/CCPA 风险。本模块属于 design 轴(Temporal 类别),适用于各种范式。
检查内容
- 软删除一致性:部分表有
deleted_at/is_deleted列,其他表却没有;或者虽然有这些列,却缺少相应的保护措施——查询、唯一约束或外键忽略了这些列(导致已删除的行在联接中死而复生、发生 UNIQUE 冲突)。这与 M5 的过度可空 UNIQUE 陷阱相关。 - 审计/历史轨迹:敏感表(财务、身份验证、权限、配置)没有变更历史(没有
*_history/*_audit表、时态列或触发器/CDC)——出问题时,无法记录谁在何时更改了什么。 - 保留与删除(GDPR/CCPA):PII 没有保留期限、没有记录清楚的清除/匿名化途径,或者在法律要求实际删除或匿名化时使用了“软删除”。参见 M10 中的 PII 检测。
- 时态有效性:双时态/按生效日期确定的数据只使用单个时间戳,而实际需要
valid_from/valid_to;缺少end_date >= start_dateCHECK。
轴与严重程度
- 轴:design;影响程度分档,绝不捏造记录数或罚款金额。
- PII 没有保留/删除途径(合规风险):严重程度 4,
warn,置信度directional(法律适用性需要人工审核——绝不自动封顶)。 - 软删除不一致且没有查询/唯一约束保护:严重程度 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,但联接/唯一约束忽略该列,导致已删除的行死而复生(严重程度 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,并将法律判断留给人工;绝不将罚款或违规断言为既定事实。 - 软删除是有效模式;仅标记不一致之处(部分表/查询遵循软删除规则,其他则没有),而非标记其使用本身。
- 绝不捏造保留期限或记录数;对影响程度分档,并指出缺失的机制,而非编造数字。
评论
支持 Markdown