用途：对失败的 GSD auto-mode 运行做事后分析（post-mortem），从症状追到根因。适合 /gsd forensics 已运行但需要更深调查、自动模式异常退出原因不明、同一单元被重复派发疑似卡死循环、会话崩溃且 auto.lock 过期，或用户反馈“它突然停了/做错了”等场景。
核心原则：只读，不触碰实时状态。允许 ps、top -b、cat /proc/* 等非变更性检查，禁止任何 gsd_* 写入、修改状态、执行有副作用命令、写文件（最终报告除外）或重跑失败单元，以保持证据原始完整。所有结论需引用工件路径与行号或 JSONL 字段；预解析线索只当作待验证假设，不是结论。
涉及工件：activity/{seq}-{unitType}-{unitId}.jsonl（每单元完整工具调用与消息流）、journal/YYYY-MM-DD.jsonl（迭代级事件）、metrics.json（token/成本账本，同 type/id 重复即卡死信号）、auto.lock、forensics/、debug/、runtime/paused-session.json、doctor-history.jsonl。
排查步骤：先定位证据（判断 auto.lock 是否过期、取最新 activity 日志、当日 journal、metrics 重复项、暂停原因）；再从 activity 日志重建失败，搜索 isError: true 的 toolResult，回溯产生该调用的 assistant 消息读取其推理，继续回溯找到状态认知偏差点；接着交叉比对 journal 的 stuck-detected、guard-block、unit-end/unit-start 重复、terminal 等事件，用 flowId 重建单次迭代、causedBy 追因果链；然后命名根因，要求具体（函数、状态转换、缺失守卫）、可证伪、可溯源；最后提出最小修复、应补充的测试并判断是否为近期提交回归。
报告格式为可提交 GitHub issue 的结构：Symptom、Evidence Trail（逐条引用工件与行号）、Root Cause（指名文件与函数）、Proposed Fix、Test、Confidence。报告需保存到 .gsd/forensics/<slug>.md；如需通过 mcp__github__issue_write 提交 issue，须获用户明确确认。反模式包括：取证期间运行 gsd_* 写工具、重跑循环“复现”覆盖日志、根因含糊、无引用、跳过 journal、自动提交 issue。成功标准：引用症状原文、每条断言有出处、根因指名具体代码、修复最小且可证伪、诚实给出置信度、报告必存。安装与运行命令资料中暂未提供。