# Alert Firing Scenario Context Isolation

<!-- auto-oncall-optimization-record
{
  "schemaVersion": "auto-oncall-optimization-record-v1",
  "optimizationId": "alert-firing-scenario-context-isolation-2026-08-20",
  "problems": [
    {
      "problemId": "alert-firing-and-resource-root-cause-context-mixed",
      "summary": "An explicit alert-firing question shares a generic resource-pressure Scenario with workload, capacity, and scale-out reasoning, so a different resource metric can be treated as a rule contradiction and unrelated capacity context can affect the answer.",
      "status": "optimized_verified",
      "applicability": "Provider-backed tickets that explicitly ask why one uniquely identified managed alert fired or how its threshold maps to the observed value.",
      "issueKeys": ["ST-2865"],
      "sourceRefs": ["https://tidb.atlassian.net/browse/ST-2865#problem:alert-firing-and-resource-root-cause-context-mixed"],
      "signalTextIncludesAny": ["why did the alert fire", "告警为什么触发", "MaxTiKVMemoryUsageTooHigh", "max memory utilization across TiKV nodes"],
      "observedThrough": "2026-08-20",
      "effectiveAt": "2026-08-20T11:44:10Z",
      "verifiedAt": "2026-08-20T12:14:53Z",
      "attemptedAction": "Route a uniquely identified alert-firing question to an isolated alert-firing-explanation Scenario, inject only the Router-selected rule topic into that Scenario, and keep resource root cause, workload attribution, capacity action, and scale-out in separate existing Scenarios.",
      "evidenceUrl": "https://tidb.atlassian.net/browse/ST-2865?focusedCommentId=23432370"
    }
  ]
}
-->

- Optimization ID: `alert-firing-scenario-context-isolation-2026-08-20`
- Owner: Scenario Router assignment and Scenario Diagnostic Agent context handoff
- Source reference: `ST-2865`
- Implementation status: deployed, case-replay verified, and Jira refreshed
- Effective status: `optimized_verified`

## Bounded problem

The customer asks why one concrete alert fired. The existing route can put the
question in `capacity-resource-pressure`, where alert-rule reconstruction,
resource root cause, workload discovery, and capacity action share one local
diagnostic context.

## Candidate change

- Add `alert-firing-explanation` for one uniquely identified alert rule.
- Keep the Router as the only rule-applicability and rule-selection owner.
- Give that Scenario only the selected rule topic and rule-equivalent evidence
  objective.
- Keep workload, resource root cause, mitigation, and scale-out in their
  existing Scenarios.
- Do not select the new Scenario from a generic alert word or an ambiguous set
  of rules.

## Verification status

Focused product-knowledge and Scenario contract tests pass (74/74), and the
full repository suite passes (930/930).

A branch-local real-model ST-2865 routing simulation recalled both Max and
Total alert candidates, selected only
`wetech-cloud-max-tikv-memory-alert`, and routed only
`alert-firing-explanation` as primary. It did not add capacity or workload
diagnosis. The Router thread was
`01a01ef1-aa2e-7520-9155-f2b43afe9587`.

A separate real-model Scenario Diagnostic Agent turn received only the selected
Max rule and asked for the same per-instance host-memory quantity, actual
threshold, configured duration, crossing instance, and aligned interval. It did
not ask for workload attribution, allocator analysis, capacity action, or
scale-out. The thread was `01a01ef2-33c9-7170-b161-5c5fb9c05d42`.

PR [#1038](https://github.com/tidbcloud/aisupport/pull/1038) and app-delivery
PR [#77878](https://github.com/tidbcloud/app-delivery/pull/77878) were merged.
Staging then ran image `0ebfb633ac5e81adc362cc22bb1728801da1cae4`
Ready with one replica and zero restarts.

The deployed `ST-2865` `mode=read` replay completed as run
`8edfd714-c07b-4a35-bafc-95a744ee9d94`. Its route selected only
`wetech-cloud-max-tikv-memory-alert` and the primary
`alert-firing-explanation` Scenario. The Scenario marked workload attribution
`not_applicable`, confirmed the exact alert state in the incident window, and
kept the non-equivalent `MemAvailable` reconstruction from being treated as a
rule contradiction. The single-ticket Judge verdict was `ai_better`, with no
AI gaps.

After human authorization, the verified replay body was written directly to
the existing stable Jira internal comment `23432370` without another replay.
Pre-write and post-write reads confirmed the same issue and comment ID,
`public=false`, and the expected paired customer/Internal Only body. The
existing DB mapping `auto-live:v1:ST-2865:initial` already pointed to that
comment, so no DB run, evaluation, mapping, or Base history was rewritten.

## Unresolved gaps

- The exact triggering TiKV instance remains Support-owned follow-up because
  neither available reconstruction used the complete rule-equivalent source
  quantity.

## Next validation action

Preserve the rule-equivalent source-quantity gap as a Support follow-up; do not
infer the triggering instance from a non-equivalent memory metric.