28 lines
1.4 KiB
Markdown
28 lines
1.4 KiB
Markdown
## Why
|
|
|
|
Runtime verification showed that AIOps now correctly accepts an alert payload and persists a trace, but the generated report still expands to every active mock Prometheus alert. That weakens the product boundary between `/api/chat` and `/api/ai_ops`: an alert payload should mean targeted alert diagnosis, while an empty payload should mean automatic active-alert discovery.
|
|
|
|
## What Changes
|
|
|
|
- Tighten the AIOps task prompt so payload mode focuses the final report on the supplied alert.
|
|
- Preserve full active-alert discovery when no payload is supplied.
|
|
- Allow Prometheus active-alert lookup in payload mode only as supporting evidence, not as permission to expand the report to unrelated alerts.
|
|
- Update tests and demo acceptance wording to lock the new behavior.
|
|
|
|
## Capabilities
|
|
|
|
### New Capabilities
|
|
|
|
- `aiops-alert-scope-control`: Defines AIOps diagnosis scope rules for payload mode versus auto-discovery mode.
|
|
|
|
### Modified Capabilities
|
|
|
|
- `aiops-traceable-diagnosis-entry`: Keeps the same API and trace behavior but clarifies how AIOps should scope its diagnosis.
|
|
|
|
## Impact
|
|
|
|
- Affected code: `AiOpsService.buildTaskPrompt(...)`, focused tests, demo documentation, devflow records.
|
|
- Affected API: no endpoint or request/response shape change.
|
|
- Affected persistence: no schema change.
|
|
- Non-goals: no Verifier integration, no tool implementation change, no prompt rewrite for Chat.
|