前言¶

在 DSH（DeepSeek Harness）里做 Web 或 Agent 项目，日志、监控往往已经接上了。真正难的是合规与应急：预案写在哪、凌晨三点该找谁、日志和业务是否同机同账号、出了数据事件要不要报、要不要告知用户——这些平时很少在代码评审里逐项过，出事那天才暴露缺口。

@deepwhale-cn/dsh-incident-package（社区目录名 feely0208/dsh-incident-package）面向「应急响应准备」做静态自查：在仓库与文档里找应急预案、应急联系人、日志证据保全、事件上报流程是否「有迹可循」。它不替代人工演练或主管部门认定，但能在开发阶段把「有没有」先扫一遍。维护者为 feely0208，分类为 admin-security；npm 包当前版本为 0.1.1（MIT），要求 Node.js ≥18、DSH ≥0.1.0-rc.6。

这是什么¶

一句话：应急证据包——查出了事能不能拿出证据，覆盖预案、联系人、日志保全、上报流程。

插件挂在 DeepSeek Harness 插件生态里（社区目录见 SkillHub 插件页，源码在 GitHub）。与「出事时通知谁」的 dsh-alert-relay、查日志留存周期的 dsh-cn-log-retention 分工不同：本插件侧重出事之前材料与配置是否齐备，以及日志是否具备「事后仍可采信」的保全线索。

它查什么¶

README 用表格归纳了检查项与依据，可按严重级别理解优先级：

README 特别强调的一类风险是：日志和业务库在同一台机器、同一账号下时，攻击者可能优先删日志，导致事后无法举证；等保对审计记录的要求包括避免未预期的删除、修改或覆盖。插件会从配置与文档侧提示是否存在保全相关描述或配置，不验证 WORM、权限是否真实生效。

安装与启用¶

在 DSH Web 配置档下安装（命令来自官方 README）：

dsh plugin --profile web add @deepwhale-cn/dsh-incident-package

不经过 DSH 进程、仅作 CLI 时：

npx @deepwhale-cn/dsh-incident-package

安装前建议阅读仓库源码与 MIT 许可证；插件以当前 dsh 进程权限扫描工作区，勿在未审代码的情况下对敏感仓库直接执行。

典型用法¶

README 给出的可复现入口如下。

演示模式（查看示例输出，不依赖真实仓库结构时可先跑）：

dsh-incident-package --demo

列出规则与依据说明：

dsh-incident-package --list-rules

将报告导出为 HTML 文件（示例文件名为 r.html）：

dsh-incident-package --html r.html

官方 README 附有检查报告、演示模式输出、规则与依据的截图（deepwhale.org.cn/plugin-assets/dsh-incident-package/），便于对照 CLI 结果长什么样。

边界与适用场景¶

适合：需要在交付或自查清单里快速回答「应急预案有没有写进仓库 / 文档」「联系人、上报流程有没有留下可查痕迹」「日志保全是否在配置或文档里体现」的团队；与深鲸网安守护系列里其他「一个插件一件事」的 guard 插件配套使用时，更接近完整链条。

务必知晓的边界（均来自 README）：

1. 不检查预案质量——只查「有没有」；内容好坏、是否演练需人工评审。
2. 不验证联系人能否打通——只查文档里是否出现。
3. 预案可能在其他仓库或内部系统——报缺是提示确认，不是断定未做。
4. 证据保全只看配置与文档——存储权限、不可篡改策略是否生效需人工验证。

使用者须遵守所在地法律法规；README 声明对使用本项目造成的后果自行承担责任。

结尾¶

dsh-incident-package 把「平时不备、事到临头就晚」的几类缺口——预案、联系人、日志可信保全、上报流程——收成可重复的仓库级扫描，方便在 DSH 工作流里与告警外发、日志留存等插件分工配合。

• 社区目录：https://www.skillhub.cn/plugins/feely0208/dsh-incident-package
• 源码与说明：https://github.com/feely0208/dsh-incident-package