Incident-Investigator

<p align="center"> <a href="https://github.com/stackrail-io/Incident-Investigator"> <img src="docs/banner.svg" alt="事件调查器 — 与厂商无关的MCP调查引擎" width="900"/> </a> </p> <p align="center"> <a href="https://github.com/stackrail-io/Incident-Investigator/stargazers"><img src="https://img.shields.io/github/stars/stackrail-io/Incident-Investigator?style=for-the-badge&logo=github&label=星标&color=181717" alt="星标"/></a> <a href="https://github.com/stackrail-io/Incident-Investigator/releases"><img src="https://img.shields.io/github/v/release/stackrail-io/Incident-Investigator?style=for-the-badge&label=版本&color=0ea5e9" alt="版本"/></a> <a href="LICENSE"><img src="https://img.shields.io/badge/许可证-MIT-22c55e?style=for-the-badge" alt="许可证"/></a> <a href="https://calendly.com/stackrail/production-audit"><img src="https://img.shields.io/badge/预订演示-StackRail-f97316?style=for-the-badge" alt="预订演示"/></a> </p> # 事件调查器 一个开源的 **AI调查运行时**，作为 [MCP](https://modelcontextprotocol.io) 服务器公开。 ## 为什么AI助手在事件调查方面挣扎 当今的AI助手可以 **收集** 证据 — 查询日志、拉取指标、读取警报 — 但它们不能可靠地 **调查**。它们缺乏一个有状态的运行时，持续回答四个问题： 1. **我目前知道什么？** — 假设、覆盖范围、矛盾 2. **我还需要什么？** — 阻塞问题、最高价值的下一个证据 3. **我可以回答吗？** — 充分性、置信度阈值 4. **为什么我相信这一点？** — 推理轨迹、日记、置信度分解 没有这些，助手要么过早停止（信心不足的猜测），要么高估结论（自信但不支持）。事件调查器填补了这一空白：它拥有 **推理**，而不是数据收集。 事件调查器 **不** 连接到Kubernetes、AWS、GitHub、Slack、Datadog、Prometheus或其他任何系统。它没有连接器和厂商SDK。相反，它是一个 **有状态的调查运行时**，引导AI代理进行多次推理迭代：它请求最高价值的证据，在代理提交的内容上进行推理，跟踪置信度的演变，并在调查足够时生成最终报告。 它与任何支持MCP的助手（如Claude Code、Codex、Cursor、Goose、OpenHands等）一起工作。 ## 核心哲学 > 调查不是证据的集合 — 它是 **问题** 的集合。证据只存在于回答问题。问题验证假设。假设回答调查目标。 | AI助手负责 | 运行时负责 | | ------------------------------------------------------------ | ----------------------------------------------------------------------------- | | 决定调用哪些外部工具 | 执行 **调查协议**（基于剧本驱动） | | 收集日志、指标、警报、部署、轨迹等 | 维护 **调查计划** — 调查的脑部 | | 用证据回答协议问题 | 从剧本中生成 **问题** 和 **证据请求** | | 知道CloudWatch / Datadog / Kubernetes是什么 | 解决问题的 → 更新假设 → 计算置信度 | | | 构建 **调查图**，问题图，推理轨迹和日记 | 运行时只理解 **证据类别**。它永远不会依赖厂商模式。 ## 架构 — 调查协议 运行时执行 **调查协议**，而不仅仅是一个引擎管道。每个调查都遵循相同的层次结构： ``` 调查 ↓ 目标 ↓ 问题 ← 由调查剧本驱动 ↓ 证据请求（链接到特定问题） ↓ 证据（由AI助手提交） ↓ 问题解决 ↓ 假设（由剧本规则更新，而不是直接由推理者） ↓ 置信度 → 报告 ``` 协议生命周期： ``` 创建调查 → 生成计划 → 创建问题 → 生成证据请求 → 提交证据 → 解决问题 → 更新假设 → 生成其他问题 → 重复 → 调查完成 ``` ``` AI助手（收集证据以回答协议问题） │ ▼ 事件调查器MCP │ ▼ 调查运行时 │ ├── 调查计划（问题、证据请求、阶段、置信度） ├── 调查剧本（声明性问题 + 假设规则） ├── **调查图**（规范模型 — 证据、问题、假设、服务、…） ├── 问题图（问题依赖关系、协议视图） ├── 问题解决引擎 ├── 充分性/覆盖率/策略引擎 └── **多推理器编排器** → 能力推理器 → 验证操作 ``` ## 多推理器架构 事件调查器 **不绑定到一种推理策略**。运行时编排多个独立的推理引擎。每个引擎都贡献 **观察作为声明性操作**；运行时验证、合并并应用它们。调查图仍然是真实性的规范来源。 > 推理器不调查。推理器做出观察。运行时进行调查。 ## 调查规范v1 事件调查器实现了 **[调查规范v1](spec/investigation-v1/README.md)** — 一个厂商中立、与传输无关的AI辅助事件调查协议（可以理解为 **OpenAPI for investigations**）。 规范定义： - **信息模型** — 调查、问题、证据、假设、发现、… - **规范生命周期** — 单个状态机（`started` → … → `completed`） - **协议操作** — 开始、提交证据、完成、…独立于MCP - **扩展** — 图、多推理器、事件情报 此存储库中的MCP工具是规范的 **绑定**。其他项目可以实现或使用相同的协议，通过REST、gRPC或SDK在不共享此代码库的情况下。 ``` 调查 ├── 问题 ├── 证据 ├── 图 ├── 假设 └── 发现 ``` 运行可移植的一致性测试： ```bash go test ./internal/spec/... ``` 测试用例位于 [`conformance/fixtures/`](conformance/fixtures/) — 任何实现都可以重放的传输无关的JSON场景。 ``` 调查运行时 │ 调查图 │ 推理编排器 │ ┌─────┴─────┬─────────────┬──────────────┐ │ │ │ │ 时间 因果 假设 一致性 语义 推理器 推理器 推理器 推理器 推理器 │ 推理动作列表 │ 运行时验证 → 应用 → 更新的调查 ``` ### 能力推理器（默认） | 推理器 | 优先级 | 责任 | | -------- | -------- | -------------- | | **时间** | 100 | 时间线排序、证据规划、时间图边 | | **因果** | 90 | 图原生根原因、辐射范围、最强路径（仅限图形） | | **假设** | 80 | 竞争假设、置信度、覆盖率、策略、图重建 | | **一致性** | 70 | 矛盾、不可能序列、图完整性 | | **语义** | 50 | 通过MCP采样（Claude/Codex）托管LLM；如果客户端缺乏采样，则跳过 | 推理器根据 **它们执行的推理类型** 进行分类，而不是根据它们如何实现。 **语义** 推理器通过 [MCP采样](https://modelcontextprotocol.io/specification/2025-11-25/client/sampling)在客户端支持时委托给MCP主机（Claude、Codex）— 服务器中没有厂商SDK或API密钥。 ### 推理动作 推理器永远不会直接修改会话状态。它们发出诸如 `IncreaseHypothesisConfidence`、`CreateQuestion`、`LinkGraphNodes`、`MarkContradiction`、`ReplaceHypotheses` 和 `UpdateGraph` 等操作。运行时在应用前验证每个操作（已解决的问题、置信度限制、无效节点）。 ### 编排策略 可配置：`sequential`（默认）、`parallel`、`weighted_voting`、`priority`、`consensus`。冲突的置信度变化通过加权平均进行合并，并在 **推理循环** 中记录。 ### 可解释性 每次重新计算都会保留一个 `ReasoningCycle`（推理器运行、操作应用/拒绝、持续时间）。使用 `get_reasoning_cycles` 重放任何迭代。 ## 事件情报 事件调查器不再执行隔离的调查。每项完成的调查都成为 **可重用的知识**。未来的调查通过以下方式随着时间的推移而改进： - 查找类似的过去事件 - 重用调查模式 - 根据历史结果校准置信度 - 推荐更好的证据和问题 - 加速根本原因分析 历史学习生活在单独的 **事件情报** 子系统中。调查运行时在 **关于历史** 方面保持 **无状态** — 它只向情报API提问；它永远不会直接读取存档。 ``` 已完成调查 ↓ 快照（不可变） ↓ 模式提取 ↓ 调查存档 ↓ 相似性搜索 ──→ 模式推荐 ↓ ↓ └──────────→ 调查运行时 ``` ``` 调查运行时 │ 事件情报API │ ┌──────────────┬──────────────┬──────────────┐ │ │ │ │ 相似性 模式引擎 置信度引擎 │ 调查存档 │ 调查图快照 ``` ### 核心组件 | 组件 | 接口 | 默认实现 | | --------- | --------- | ---------------------- | | 存档 | `InvestigationArchive` | `MemoryArchive`（内存） | | 相似性 | `SimilarityEngine` | `HeuristicSimilarityEngine`（确定性） | | 模式 | `PatternEngine` | `HeuristicPatternEngine`（内置库 + 历史） | | 校准 | `ConfidenceCalibrator` | `HeuristicCalibrator`（历史准确性混合） | 当调查完成时，运行时存储一个不可变的 `InvestigationSnapshot`（目标、根本原因、时间线、知识图、假设、证据摘要、指纹、元数据）。快照按 `InvestigationFingerprint`（目标、图/时间线哈希、服务、类别）索引，以加速相似性搜索。 **相似性** 是确定性的 — 没有嵌入或向量数据库。引擎比较目标、问题重叠、服务、证据类别、图拓扑、时间线形状、假设重叠、根本原因和指纹部分匹配。 **模式库** 包括可重用的剧本，如部署失败、证书过期、数据库饱和和重试风暴。模式推荐问题和预期的证据类别，并附有置信度评分。 **置信度校准** 将原始假设置信度与历史准确性相结合，适用于类似的调查，并始终返回解释（`CalibrationExplanation`，带有样本大小、正确计数和支持历史）。 **经验教训** 和 **调查建议**（典型的缺失证据、根本原因、问题）在与相似性匹配一起返回。运行时决定是否使用它们。 未来的存档后端（PostgreSQL、Neo4j、S3、对象存储）通过 `InvestigationArchive` 插件，无需更改运行时代码。 **没有** 向量数据库、嵌入API或外部AI服务在情报层。 ### 情报API | API方法 | 目的 | | ---------- | ------- | | `FindSimilarInvestigations(...)` | 将当前调查与存档案例进行匹配；返回经验教训和建议 | | `SuggestPatterns(...)` | 历史上的重复调查模式，附带推荐问题 | | `CalibrateConfidence(...)` | 使用历史结果调整原始置信度，并附带解释 | 默认的 `MemoryService` 在调查完成时存档快照。校准也在 `finish_investigation` 上自动运行。 MCP工具：`find_similar_investigations`、`suggest_patterns`、`calibrate_confidence`。 没有连接器。没有AWS SDK，没有Kubernetes SDK，没有GitHub SDK，没有Slack SDK，没有Prometheus SDK，没有Datadog SDK。什么都没有。 每个引擎都定义在Go接口后面，因此内置的启发式实现可以被替代实现（例如基于LLM的剧本）而无需触及运行时或MCP层。 ## 证据类别 引擎仅识别这些厂商中立的类别： `application_logs`、`infrastructure_events`、`deployment_events`、`alert_events`、`metrics`、`trace_events`、`configuration_changes`、`network_events`、`database_events`、`security_events`、`human_context`、`custom`。 ## 证据模型 助手提交的每个对象都被标准化为： ```json { "id": "uuid", "timestamp": "2026-06-27T09:01:00Z", "category": "application_logs", "source": "provided_by_client", "entity": "checkout-api", "summary": "数据库连接超时", "payload": {} } ``` `payload` 是不透明的 — 在其中放入任何内容。引擎从不解析厂商格式；它推理 `category`、`timestamp`、`entity` 和 `summary`，并显示 `payload` 键，如 `region`、`customer` 和 `api`/`endpoint`，用于辐射范围估计。 ## MCP工具 | 工具 | 目的 | | -------------------------- | ------------------------------------------------------------------------------------------------ | | `start_investigation` | 开始会话。返回 **计划**、**问题**、第一个 **证据请求**、阶段、假设。 | | `submit_evidence` | 提交证据以解决问题。返回已解决/新问题、更新计划、置信度变化。 | | `get_investigation_status` | 完整快照：计划、问题图、问题、证据请求、解决历史、指标。 | | `get_investigation_plan` | 返回完整的调查计划。 | | `list_open_questions` | 按优先级排序的未解决问题。 | | `resolve_question` | 在证据确凿时明确解决问题。 | | `explain_investigation` | **主要调试工具** — 计划、问题、图、阶段、轨迹、置信度。 | | `explain_reasoning` | 假设级推理轨迹、覆盖率、充分性、日记。 | | `get_graph` | 返回完整的调查图（所有节点和类型化关系）。 | | `query_graph` | 运行图查询：上游原因、下游影响、支持证据、矛盾等。 | | `get_subgraph` | 通过节点类型或显式节点ID提取过滤后的子图。 | | `explain_path` | 解释两个节点之间的因果路径，并为每个跳跃提供支持证据。 | | `get_reasoning_cycles` | 重放推理迭代：推理器、操作、应用/拒绝、时间。 | | `find_similar_investigations` | 查找与当前会话类似的存档调查；包括经验教训和建议。 | | `suggest_patterns` | 从历史数据中建议重复出现的调查模式。 | | `calibrate_confidence` | 使用历史记录校准假设置信度；返回原始值、调整值和解释。 | | `finish_investigation` | 当调查准备好结束时，最终报告。 | ### 调查目标 在 `start_investigation` 上设置 `goal` 以更改策略引擎的优先级： | 目标 | 优先级 | | ---- | ----------- | | `root_cause`（默认） | 部署、日志、警报 | | `timeline` | 警报、部署、基础设施事件 | | `blast_radius` | 指标、轨迹、警报 | | `deployment_verification` | 部署、配置更改 | | `performance_regression` | 指标、轨迹、日志 | | `availability` | 警报、指标、基础设施 | ### 示例：`start_investigation` 请求： ```json { "question": "为什么checkout在昨天失败了？", "service": "checkout-api", "goal": "root_cause", "time_window": { "start": "2026-06-27T09:00:00Z", "end": "2026-06-27T09:30:00Z" } } ``` 响应（缩写）： ```json { "session_id": "inv-…", "status": "collecting_evidence", "state": "waiting_for_evidence", "goal": "root_cause", "strategy": [ { "priority": 1, "category": "deployment_events", "reason": "需要确定部署是否先于事件发生。", "expected_confidence_gain": 35 } ], "required_evidence": [ … ] } ``` ## The investigation protocol Each iteration follows the runtime rules: 1. **Questions** create evidence requests 2. **Evidence requests** gather evidence (via the AI assistant) 3. **Evidence** resolves questions 4. **Resolved questions** update hypotheses (via playbook rules) 5. **Hypotheses** update confidence 6. **Confidence** determines completion ``` start_investigation └─> generate investigation plan + initial questions └─> list_open_questions / get_investigation_plan └─> submit_evidence (repeat — gather evidence for open questions) └─> questions resolve → hypotheses update → new questions generated └─> explain_investigation (inspect at any point) └─> finish_investigation when sufficient ``` Use `explain_investigation` as the primary debugging endpoint. The investigation **journal** records every state change for replay. Everything is **incremental** and held **in memory** for one investigation — nothing is recomputed from a database and there is no persistence layer (yet). ## Investigation Playbooks Playbooks are declarative investigation scripts. The runtime executes playbooks; reasoners generate them — reasoners never manipulate hypotheses directly. Example playbook fragment: ``` QUESTION deploy-before-errors Did deployment happen before errors? REQUIRES deployment_events application_logs alert_events IF TRUE Increase hypothesis-deployment-caused 25 IF FALSE Decrease hypothesis-deployment-caused 40 QUESTION config-changed Was configuration changed? REQUIRES configuration_changes deployment_events TRIGGER config GENERATES pods-restarted IF TRUE Increase hypothesis-configuration-change 30 ``` Default playbooks ship for `root_cause`, `timeline`, and `blast_radius` goals. See `internal/engine/playbook/` for the full definitions. ## Investigation Graph The **Investigation Graph** is the canonical representation of an investigation. Every engine interacts with the graph — evidence, questions, hypotheses, evidence requests, services, deployments, and conclusions are all **nodes** connected by **typed relationships**. The graph — not the LLM — is the source of truth. ``` Investigation Runtime ↓ Investigation Graph ↓ Planner · Reasoners · Timeline · Hypotheses · Reports · Queries ``` ### Node types `investigation`, `question`, `evidence`, `evidence_request`, `hypothesis`, `service`, `application`, `deployment`, `pod`, `configuration`, `metric`, `alert`, `trace`, `database`, `api`, `timeline_event`, `incident`, `conclusion`, `recommendation`, `region`, `cluster`, `customer_impact`, `custom` ### Edge types Each edge carries **confidence**, **weight**, **timestamp**, **reason**, and **evidence references**: `supports`, `contradicts`, `causes`, `triggered`, `depends_on`, `occurred_before`, `occurred_after`, `generated`, `resolves`, `requests`, `belongs_to`, `observed_on`, `recovered_by`, `correlates_with` ### Storage Graph logic is **storage-independent**. The `GraphStore` interface supports `AddNode`, `UpdateNode`, `DeleteNode`, `GetNode`, `AddEdge`, `RemoveEdge`, `GetEdges`, and `Traverse`. Only `MemoryGraphStore` ships today — Neo4j, Memgraph, PostgreSQL, and other backends can be added later without changing runtime behavior. ### Graph queries | Query kind | Example target | Returns | | ---------- | -------------- | ------- | | `upstream` | `checkout-api` | Deployment → Configuration → … | | `downstream` | `checkout-api` | Impacted services and effects | | `supporting_evidence` | hypothesis id | Evidence nodes supporting a hypothesis | | `contradictions` | hypothesis id | Contradicting evidence | | `unanswered_questions` | — | Open protocol questions | | `service_evidence` | `checkout-api` | All evidence linked to a service | | `blast_radius` | `checkout-api` | Downstream impact subgraph | | `shortest_causal_path` | `deploy->errors` | Shortest causal chain | | `strongest_path` | node id | Highest-confidence outgoing causal edge | Traversal modes (BFS, DFS, shortest path, topological, causal, timeline) are independent from storage. Subgraphs (deployment, database, hypothesis, timeline, customer impact) feed into reports. ### Example: `explain_path` ```json { "session_id": "inv-…", "from": "deploy", "to": "recovery" } ``` Returns a hop-by-hop causal explanation where every edge references supporting evidence — e.g. Deployment → Configuration Changed → Pods Restarted → Readiness Failed → Traffic Shift → API Errors → Rollback → Recovery. ## Install Pre-built binaries are published on [GitHub Releases](https://github.com/stackrail-io/Incident-Investigator/releases). Push a `v*` tag (e.g. `v1.0.0`) to trigger the release workflow and publish installers. ### macOS / Linux ```bash curl -fsSL https://raw.githubusercontent.com/stackrail-io/Incident-Investigator/main/scripts/install.sh | bash ``` Install to a custom directory: ```bash INSTALL_DIR="$HOME/.local/bin" curl -fsSL .../install.sh | bash ``` Install a specific version: ```bash INCIDENT_INVESTIGATOR_VERSION=1.0.0 curl -fsSL .../install.sh | bash ``` Verify: ```bash incident-investigator version ``` ### Windows ```powershell irm https://raw.githubusercontent.com/stackrail-io/Incident-Investigator/main/scripts/install.ps1 | iex ``` Specific version: ```powershell $env:INCIDENT_INVESTIGATOR_VERSION = "1.0.0" irm https://raw.githubusercontent.com/stackrail-io/Incident-Investigator/main/scripts/install.ps1 | iex ``` ### Docker Pull and run (stdio MCP server): ```bash docker pull ghcr.io/stackrail-io/incident-investigator:1.0.0 docker run -i --rm ghcr.io/stackrail-io/incident-investigator:1.0.0 ``` Or use the install helper (pulls the image and prints MCP config): ```bash curl -fsSL https://raw.githubusercontent.com/stackrail-io/Incident-Investigator/main/scripts/install-docker.sh | bash ``` Build locally: ```bash docker build -t stackrail/incident-investigator:1.0.0 . docker run -i --rm stackrail/incident-investigator:1.0.0 # Or with compose docker compose up --build ``` ### Claude Code plugin Install from this repository's marketplace (includes MCP server + investigation skill): ```text /plugin marketplace add stackrail-io/Incident-Investigator /plugin install incident-investigator@incident-investigator /reload-plugins ``` Use the bundled skill: ```text /incident-investigator:incident-investigation ``` Validate locally before submitting to the [Claude community marketplace](https://platform.claude.com/plugins/submit): ```bash claude plugin validate plugins/incident-investigator ``` See [plugins/incident-investigator/README.md](plugins/incident-investigator/README.md) for details. ### Codex plugin ```bash codex plugin marketplace add stackrail-io/Incident-Investigator codex plugin install incident-investigator --source incident-investigator ``` Browse installed plugins in the Codex TUI with `/plugins`. The official Codex Plugin Directory does not accept third-party submissions yet; this Git-backed marketplace works today. See [OpenAI's plugin build guide](https://developers.openai.com/codex/plugins/build). ### MCP client configuration After installing, point your MCP client at the binary or container: **Native (macOS / Linux)** ```json { "mcpServers": { "incident-investigator": { "command": "incident-investigator" } } } ``` **Windows** ```json { "mcpServers": { "incident-investigator": { "command": "C:/Users/you/AppData/Local/Programs/incident-investigator/incident-investigator.exe" } } } ``` **Docker** ```json { "mcpServers": { "incident-investigator": { "command": "docker", "args": ["run", "-i", "--rm", "ghcr.io/stackrail-io/incident-investigator:1.0.0"] } } } ``` > stdout is reserved for the MCP protocol, so all logging is written to stderr. ### Manual install Download the archive for your platform from [Releases](https://github.com/stackrail-io/Incident-Investigator/releases), extract `incident-investigator` (or `incident-investigator.exe`), and place it on your `PATH`. ### Build from source Requires Go 1.25+. ```bash git clone https://github.com/stackrail-io/Incident-Investigator.git cd Incident-Investigator go build -o bin/incident-investigator ./cmd/incident-investigator ./bin/incident-investigator ``` Or with `go run` (no install): ```json { "mcpServers": { "incident-investigator": { "command": "go", "args": ["run", "github.com/stackrail/incident-investigator/cmd/incident-investigator"] } } } ``` See [CONTRIBUTING.md](CONTRIBUTING.md) for development setup and [SECURITY.md](SECURITY.md) for reporting vulnerabilities. ## Build & run (developers) ```bash go test ./... go build -o bin/incident-investigator ./cmd/incident-investigator ./bin/incident-investigator version ./bin/incident-investigator ``` Releases are built with [GoReleaser](https://goreleaser.com/) when a `v*` tag is pushed (see `.github/workflows/release.yml`). ## How the reasoning works The built-in engines are deterministic, rule-based heuristics that operate purely on the abstract signals extracted from evidence (`internal/engine/signals.go`): - **Planner** — starts with a baseline (deployments, logs, alerts, metrics) and *dynamically* expands the request set as evidence arrives (e.g. once a deployment appears, it asks for configuration changes and traces). - **Hypothesis engine** — always produces *competing* hypotheses (deployment-caused, deployment-unrelated, database saturation, configuration change, network/DNS, certificate expiry, resource exhaustion, retry storm, unknown), scored and normalized into a probability field. - **Confidence engine** — rises with independent agreement, multi-category corroboration, and clean temporal ordering; falls with contradictions and missing critical evidence. - **Contradiction engine** — flags impossible/inconsistent sequences such as a deployment timestamped *after* the incident began, recovery before onset, and duplicate evidence. - **Blast-radius estimator** — derives affected services/regions/customers/APIs from entities and well-known payload keys. ## Project layout ``` internal/spec/ Spec v1 conformance tests (portable JSON fixtures) spec/investigation-v1/ Investigation Specification v1 (OpenAPI-style schemas) cmd/incident-investigator/ MCP server entrypoint (stdio) plugins/incident-investigator/ Claude Code + Codex plugin bundle .claude-plugin/marketplace.json Claude marketplace catalog .agents/plugins/marketplace.json Codex marketplace catalog internal/model/ Vendor-neutral domain types (evidence, graph, …) internal/reasoning/ Action model, validator, merger, hybrid orchestrator internal/reasoners/ Capability reasoners (temporal, causal, hypothesis, …) internal/intelligence/ Incident Intelligence (archive, similarity, patterns, calibration) internal/intelligence/fixtures/ 50+ completed investigation corpus for intelligence tests internal/graph/ Investigation graph store, queries, traversal internal/engine/ Planner, hypotheses, confidence, contradictions, … internal/runtime/ Stateful runtime + in-memory store internal/mcpserver/ MCP tool definitions and DTOs internal/fixtures/ Realistic incident scenarios used by tests ``` ## Testing Realistic incident fixtures (`internal/fixtures`) validate the planner, investigation graph, timeline, hypotheses, and confidence end to end. The intelligence corpus (`internal/intelligence/fixtures`, 56 completed snapshots) validates similarity search, pattern extraction, confidence calibration, knowledge reuse, and false-positive filtering. - Bad deployment - Database outage - Certificate expiry - DNS outage - Kubernetes restart loop - Memory leak - Retry storm ```bash go test ./... ``` There is also an end-to-end MCP test that drives the real protocol over an in-memory transport (`internal/mcpserver/server_test.go`). ## Out of scope (intentionally not implemented) Connectors, authentication, RBAC, a UI, and streaming telemetry are explicitly **out of scope**. The engine's only job is to reason over evidence. ## Community | Resource | Link | | -------- | ---- | | Plugin bundle | [plugins/incident-investigator/README.md](plugins/incident-investigator/README.md) | | Claude marketplace submit | [platform.claude.com/plugins/submit](https://platform.claude.com/plugins/submit) | | Changelog | [CHANGELOG.md](CHANGELOG.md) | | Contributing | [CONTRIBUTING.md](CONTRIBUTING.md) | | Code of conduct | [CODE_OF_CONDUCT.md](CODE_OF_CONDUCT.md) | | Bug reports | [Open a bug report](https://github.com/stackrail-io/Incident-Investigator/issues/new?template=bug_report.yml) | | Security | [SECURITY.md](SECURITY.md) | ## License MIT (see `LICENSE`).