用途：以一条具体线索（/dnr-hunt 产出的 INC-n 事件编号、告警队列中的 JSON 或散文告警、IP/账号/路由/会话标识等 IOC、或自由文本）为起点，按顺序回答事件指挥官所需的四个问题：发生了什么、攻击是否成功、影响范围多大、该如何处置。
主要能力：按实体拉取日志活动并向外扩展一圈关联（IP、账号、路由）；合并错误日志与告警队列为单一时间线；给出判定与区分性证据；用查询结果量化影响（涉及哪些路由/表、多少条记录、时间跨度、多少不同用户）；只读检查活动是否仍在持续；在源码中定位缺陷并本地启动应用做最小 PoC 与反向 PoC；生成含遏制、根除修复、恢复、检测工程和开放问题的响应方案；更新 INCIDENTS.json。
使用方式：调用 /dnr-respond <lead> [--logs dir] [--repo path] [--fresh]。--logs 默认 targets/dnrcanary（若存在）；--repo 默认目标的 app/；--fresh 忽略检查点并新建运行目录。执行目录逻辑与 /dnr-hunt 相同，状态存于 {RUN}/.dnr-respond-state/，分阶段 0–4，通过 checkpoint.py 的 rundir、load、save、done 管理。响应方案写入 {RUN}/RESPONSE.md，若同一目录已有其他事件的方案则写 RESPONSE-<lead>.md，不覆盖。
硬性规则：仅日志证据不能确认漏洞，confirmed_exploited 需日志证据加源码缺陷加本次会话本地触发的 PoC，否则上限为 suspected；查询而非通读日志，仅小文件可整读；只提出建议、绝不执行，不做阻断、禁用、轮换或配置变更，方案由人执行；仅本地，PoC 打 127.0.0.1 且不触碰远程主机；每个数字都必须来自本次会话运行的查询管线。
适用场景与限制：适合已有明确线索后的单线索取证与处置建议，以及将真实告警逐条接入；范围持续扩张时应改用 /dnr-hunt。可用于日志、CDN/WAF 导出、EDR 事件等来源，但需保持单一合并时间线。若无可运行应用，判定上限为 suspected。官方文档未提供收费、价格或具体支持平台等信息。