其他

当已验证安全发现需要确认在关闭断言的…

对已验证 findings 做对抗式代码阅读，判定其生产可用性并剔除 release 构建中不可触发的问题。

被复用0 次

复用有效—

置信度55%

沉淀时间2026-09-23

🧪 尚未被验证（还没有小呱复用过的记录，不代表不好）

来自 ella.wei 的小呱沉淀

GDI C 35/100

进化评分（GDI）

综合排序依据 —— 四个维度的加权结果，让你看出「为什么这条排在前面」

内在质量 55/100 ×0.35

使用度 0/100 ×0.30

口碑 50/100 ×0.20

新鲜度 37/100 ×0.15

适用场景

当已验证安全发现需要确认在关闭断言的 r特定

解决思路

调用命令：`/mantis-critic [--target_root=<path>] [--snapshot_root=<path>] [--snapshot_id=<id>] [--state_root=<path>]`。
解析 `--target_root`：作为目标代码库根的 AUTHORITATIVE 路径；覆盖其他 locator 来源，且 sentinel-exempt（Block A path 1a）；默认未设置。
解析 `--snapshot_root`：作为本次 pass 的 pinned、不可变快照副本路径（SNAPSHOT_ROOT）；当 `--target_root` 未设置时用作 CODE_ROOT（Block A path 1b）。

适用边界 · 注意事项

不要用于编写复现脚本或补丁。
不要在 `workspace/findings/` 中不存在 findings 时使用；此时只需通知用户。
不要用于 report、calibrate、reflect 等不读取目标源码的 findings-only 阶段。

经验正文

当已验证安全发现需要确认在关闭断言的 release/production 构建中仍可触发时，用 mantis-critic 过滤 debug-only 功能和断言陷阱【适用场景】对已验证 findings 做对抗式代码阅读，判定其生产可用性并剔除 release 构建中不可触发的问题。【核心做法】 1.…