用途：列出当前项目中在用户指定时间窗口内被软删除的功能开关，并附上删除者与删除时间。适合回答“上周或最近 N 天删了哪些开关”、审计近期删除、或查明某个开关何时被谁删除。不适用于活跃过期开关的清理，那属于清理过期开关的场景。
主要能力：分两步执行。先用 SQL 枚举候选：查询 system.feature_flags 中 deleted = true 的记录，按 created_at DESC 排序，默认 limit 100，team_id 默认取当前项目。再用 posthog:feature-flags-activity-retrieve 对每个候选并行获取活动日志（limit 5, page 1），从中找到 activity == "deleted" 的条目，其 created_at 为实际删除时间，user.email / user.first_name 为删除者。最后用 scripts/strip_deleted_suffix.py 从被重命名的键（形如 original:deleted:<id>）还原原始键，过滤出落在窗口内的删除事件，并以表格输出。
用法要点：若“上周”含义模糊，需澄清或同时给出滚动 7 天与上一自然周两种解释，截止时间以 UTC 计算。批量大小建议：最近 7 天查前 20–25 个候选，30 天查前 50 个，90 天走完约 100 个；若未走完需在报告中说明并提议补充。还原原始键时把整个候选列表一次性以 JSON 传入脚本，不要逐个调用。
限制与注意：system.feature_flags 不暴露 deleted_at、updated_at 或 last_modified_at，无法单条 SQL 按删除时间过滤；删除时间只在每个开关的活动日志中，且没有批量活动接口。created_at 不能作为删除时间代理，活动日志才是唯一依据。按 created_at DESC 排序只是启发式，较早创建但最近删除的开关不会排在前面。重命名键属正常现象。窗口边界约 1 小时内的情况应标注为临界。走完所有候选较慢，应作为可选后续而非短窗口的默认做法。
相关工具：posthog:execute-sql 用于枚举，posthog:feature-flags-activity-retrieve 用于取删除事件，posthog:feature-flag-get-definition 可用于进一步查看已删除开关的定义。