Files

2.1 KiB

Decisions: aiops-alert-scope-control

Clarify

  • Entry summary: tighten AIOps report scope after runtime verification showed payload mode still analyzes all active alerts.
  • Slug: aiops-alert-scope-control
  • Scale: standard-light.

Context

  • AIOps traceability is implemented and verified.
  • Mock Prometheus returns multiple active alerts.
  • Payload demo supplies HighCPUUsage/payment-service, but previous report expanded to HighMemoryUsage and SlowResponse.

Grill Question Pool

# Dimension Question Mode Status
Q1 Product Boundary What makes /api/ai_ops different from /api/chat when payload exists? evidence-driven Payload is alert-event driven and should be scoped to that event.
Q2 Scope Should payload mode ignore all other active alerts? user-interview No; mention only as related risk/context.
Q3 Compatibility Should no-payload mode keep old "query active alerts" behavior? evidence-driven Yes.
Q4 Enforcement Should Java filter unrelated tool results now? evidence-driven No; prompt-only is sufficient for this small change.
Q5 Verifier Should this change add AIOps Verifier? user-interview No; keep deferred.

Evidence-Driven Conclusions

Conclusion Evidence Source Result
Scope issue is prompt-level. /api_ ai_ops trace showed all mock alerts analyzed despite payload. Update task prompt.
No API or persistence changes are needed. AIOpsRequest already carries payload and trace works. Keep endpoint unchanged.
Blast radius is low. buildTaskPrompt(...) is internal to AiOpsService. Add tests for prompt content.

GitNexus

GitNexus remains skipped by prior user decision and because tools are not exposed in this session. Local impact analysis is recorded instead.

Key Decisions

  • Payload mode is detected when any alert field is present.
  • Payload mode final report must focus on the supplied alert.
  • No-payload mode must first call queryPrometheusAlerts.
  • Other active alerts in payload mode can appear only as related risk, not as separate root-cause sections.