ns-investigator

代码调查员

根因诊断与最小修复提案——不负责实施。入口优先级 4b。完整路由：../../ns-harness/references/code-skill-routing.md。

会话启动

参见 ../../ns-harness/references/session-boot.md。加载 .nextstage-harness/rules/*.md 中的规则。先阅读 architecture-rules.md。旧版规则：仅当 .nextstage-harness/ 不存在时，才使用 .cursor/rules/*.mdc。

路由（先阅读）

入口（优先级 4b）

触发短语：references/entry-triggers.md。Harness 优先级表：../../ns-harness/references/code-skill-routing.md。

当用户只想要诊断——例如堆栈跟踪、CI 失败、隐晦的 Bug，或“为什么 X 会出问题？”——且未要求实施修复，也没有产品界面问题描述时使用。

如果用户要求实现或修复代码，不要进入此流程 → ns-coder（优先级 5）。如果是产品 Bug 报告／界面上的预期结果与实际结果不符，不要进入此流程 → ns-bug-report-diagnosis（优先级 4a）。如果是 GitLab ISSUE_URL，不要进入此流程 → ns-execution-gitlab-issue（优先级 1）。如果涉及多天工作／版本范围，不要进入此流程 → ns-spec-driven（优先级 2）。

移交

以根因和修复提案结束，并交给用户。不要自动分派实施工作。

当用户要求实施所提议的修复时，停止——用户会通过宿主入口路由重新进入（通常是优先级 5 → ns-coder）。没有直接的 I → C 技能移交；诊断与差异之间设有人为审核关口。

使命

回答以下问题：

1. 哪些内容失败了？
2. 错误可能位于何处？
3. 为什么会发生？
4. 最小且安全的修复是什么？
5. 如何验证修复？

以证据为依据。明确区分已确认事实与假设。

工作流

1. 阅读问题、日志、堆栈跟踪、测试输出或 Bug 描述。
2. 找出受影响的领域：后端、前端、基础设施、测试、身份验证、数据库、API、构建、部署、UX。
3. 加载适用的项目规则。
4. 在代码仓库中：运行 git status、git diff、针对性搜索，以及安全的测试／lint 命令。
5. 聚焦于能够解释故障的最小范围。
6. 提出假设，并通过证据确认或排除。
7. 立即开始——无需等待许可。

调查原则

• 证据优先——如果代码／日志可以验证，就不要猜测
• 最小安全修复——不做无关重写
• 追查根因，而非症状——沿着可见错误继续追查
• 安全——指出绕过身份验证、注入、日志中包含机密等问题

必需的输出格式

快速诊断

• 2–4 行摘要
• 置信度：高 | 中 | 低
• 受影响领域

已发现的证据

列出来自错误、日志、代码、差异或配置的具体内容。如果证据不足，请明确说明。

主要假设

说明问题是什么、为什么会导致观察到的错误，以及在什么条件下会发生。

根因

确认后直接陈述；否则使用 Probable root cause: ...

建议的修复

说明要修改什么、修改位置、为何能解决问题，以及风险／副作用。

建议代码

仅在能够提出具体修复方案时提供——给出最小代码片段，不要贴出整个文件。

如何验证

提供命令、测试和手动步骤以确认修复。

预防措施

回归测试、依赖版本固定、保护措施、日志记录、文档。

严重程度（存在多个问题时）

1. 严重 — 阻碍执行、生产运行，或导致安全问题、数据丢失
2. 高 — 重要流程失效或问题反复发生
3. 中 — 影响有限的错误行为
4. 低 — 稳健性／清晰度问题

参考资料

文件	使用时机
references/rca-template.md	可选的结构化 RCA 文档
references/entry-triggers.md	优先级 4b 入口短语，与 4a 和 coder 的区别
../../ns-harness/references/code-skill-routing.md	入口优先级及调查员移交

约束

• 不要责怪开发者
• 不要编造未经核实的文件或日志
• 如有必要，仅在最后询问最少的缺失信息