1.9 KiB
1.9 KiB
Why
The MVP already has a strong traceable chat diagnosis path, but the legacy /api/ai_ops endpoint still behaves like an early standalone demo: it accepts no alert payload, generates an internal session id that callers cannot reuse, and streams a report without reliably persisting the final answer for trace replay. For an Agent Engineer interview project, AIOps should become a second entry point into the same observable diagnosis story rather than a disconnected legacy path.
What Changes
- Allow
/api/ai_opsto accept an optional alert diagnosis request body. - Resolve a stable session id from the request or generate one when omitted.
- Persist the AIOps alert query and final report into
diagnosis_session. - Emit the resolved session id in the SSE stream so reviewers can call
GET /api/diagnosis/{sessionId}/trace. - Keep the existing AIOps planner/executor flow and evidence tools; do not replace it with the chat flow in this slice.
- Document the AIOps demo path beside the existing MVP demo trace flow.
Capabilities
New Capabilities
aiops-traceable-diagnosis-entry: Makes the AIOps alert endpoint traceable by session id and replayable through the existing diagnosis trace API.
Modified Capabilities
- Existing
/api/ai_opsbehavior is extended from a no-input SSE trigger into an optional request-body alert diagnosis endpoint.
Impact
- Affected code:
ChatController,AiOpsService,AIOpsRequest, focused tests, MVP demo documentation, devflow records. - Affected API:
POST /api/ai_opsremains SSE, but now accepts an optional JSON body and streams a first message containingsessionId. - Affected persistence: no schema migration; writes existing
diagnosis_session.query,answer,status, timing, and aggregate counts. - Non-goals: no full AIOps/Chat service unification, no new database table, no production security cleanup, no full offline fake runtime, no mandatory Verifier integration for AIOps in this slice.