# AIOps Alert Acceptance Case

## Goal

Validate that the legacy AIOps endpoint can act as a traceable alert-triggered diagnosis entry.

## Input

- Session id: `mvp-demo-aiops-payment-cpu-001`
- Endpoint: `POST /api/ai_ops`
- Profile: `mvp-demo`
- Alert:

```json
{
  "sessionId": "mvp-demo-aiops-payment-cpu-001",
  "alertName": "HighCPUUsage",
  "service": "payment-service",
  "severity": "P1",
  "description": "服务 payment-service 的 CPU 使用率持续超过 80%，当前值为 92%。实例: pod-payment-service-7d8f9c6b5-x2k4m。",
  "timeRange": "last_15m",
  "userRequest": "请结合 Prometheus 活动告警、system-metrics 日志和知识库生成告警分析报告。"
}
```

## Acceptance Criteria

1. The SSE stream emits a `session` message containing the requested session id.
2. The AIOps run creates or updates `diagnosis_session` with `agent_flow = AI_OPS`.
3. The persisted session query contains the alert name, service, severity, time range, and description.
4. If a final report is generated, `diagnosis_session.answer` contains that report.
5. `GET /api/diagnosis/{sessionId}/trace` returns the AIOps session, ordered agent steps, and ordered tool invocations.
6. In payload mode, the report focuses on `HighCPUUsage/payment-service`; unrelated active alerts may appear only as related risk or context, not as separate full root-cause sections.

## Known Limits

- This slice does not add a Verifier Agent to AIOps.
- Full runtime verification still depends on valid DB, Redis, Milvus/Zilliz, model, and embedding configuration.