# Persistent Scenario Diagnostic Ownership

<!-- auto-oncall-optimization-record
{
  "schemaVersion": "auto-oncall-optimization-record-v1",
  "optimizationId": "scenario-diagnostic-agent-ownership-2026-08-12",
  "problems": [
    {
      "problemId": "router-rationale-drives-provider-query-before-scenario-diagnosis",
      "summary": "The runner started Evidence from the Scenario Router rationale and created a fresh Scenario Diagnostic Agent only after acquisition, so the scenario diagnosis owner did not choose the initial evidence question or retain reasoning across rounds.",
      "status": "optimized_unverified",
      "issueKeys": ["ST-2863", "APID-29296"],
      "sourceRefs": [],
      "signalTextIncludesAny": [
        "Router decides what evidence to query",
        "Scenario Diagnostic Agent starts after evidence",
        "fresh Scenario Diagnostic Agent every round",
        "scenario reason used as evidence objective"
      ],
      "observedThrough": "2026-08-12",
      "effectiveAt": "2026-08-12T09:37:52+08:00",
      "verifiedAt": null,
      "attemptedAction": "Start one persistent Scenario Diagnostic Agent before provider acquisition, let it own the initial evidence question and later refinements, pass only that question to the Evidence Agent, and keep Router ownership limited to assignment and final ticket-level reconciliation.",
      "evidenceUrl": "https://github.com/tidbcloud/aisupport/tree/main/auto-oncall-services/docs/opts/2026-08-12-scenario-diagnostic-agent-ownership.md"
    }
  ]
}
-->

- Optimization ID: `scenario-diagnostic-agent-ownership-2026-08-12`
- Owner: auto-oncall-services diagnostic runner
- Source reference: diagnostic architecture review on 2026-08-12
- Implementation status: deployed to staging in image
  `6ec97a78441c49a841d1fcd0271112e26c423789`
- Effective status: `optimized_unverified`

## Bounded problem

The Router correctly selected scenarios and the canonical target/window, but
its scenario rationale also became the first Evidence Agent objective. The
Scenario Diagnostic Agent started only after provider execution and was
recreated for every round. This gave the Router unintended query ownership and
made local diagnosis continuity depend on repeated inline packets.

## Candidate change

- Start one offline, read-only Scenario Diagnostic Agent thread per selected
  provider-backed scenario before Evidence.
- Let its first turn produce one neutral evidence question and observable stop
  condition; let later turns consume handoffs and own refinements.
- Reuse one separate Evidence Agent thread to translate those questions into
  concrete provider plans.
- Remove Router rationale from provider context and keep the Router responsible
  only for assignment and final cross-scenario reconciliation.

## Verification evidence

Local validation completed on 2026-08-12:

- `npm test` passed all 738 tests across 61 suites.
- Targeted runner, scenario, and OP evidence tests passed 68, 53, and 10 tests.
- Wetech and Manus provider contracts passed 65 and 26 tests.
- `quick_validate.py` passed for `op-diagnosis`, `wetech-op-grafana`, and
  `manus-op-grafana`.

Source PR `tidbcloud/aisupport#800` and app-delivery PR
`tidbcloud/app-delivery#76905` merged. Staging image
`6ec97a78441c49a841d1fcd0271112e26c423789` reached 1/1 Ready with zero
restarts; `/healthz` and `/readyz` returned HTTP 200.

Two deployed `mode=read` replays exercised the lifecycle:

- `APID-29296` run `c530fc32-0448-474a-b21b-79f1b019c9ac` started persistent
  Scenario Diagnostic threads before Evidence for `query-latency` and
  `workload-hotspot`. The hotspot thread consumed its first handoff, requested
  one new load-bearing onset/peak/recovery comparison, then consumed round 2
  on the same thread and stopped without another refinement.
- `ST-2863` run `d81a6a05-f691-42b1-8a67-dcf0e357bd09` used the same lifecycle
  for `memory-oom` and `capacity-resource-pressure` over Clinic. Both completed
  their local diagnosis after one materialized round.

These runs prove that Router rationale no longer directly starts acquisition
and that one Scenario Diagnostic Agent owns the initial question plus later
refinement. The problem remains `optimized_unverified` because `mode=read` did
not refresh the stable Jira internal comments and both replays exposed separate
quality gaps.

## Unresolved gaps

- The 500-character evidence-question limit produced syntactically incomplete
  questions in both replays, although their stop conditions remained complete.
- `APID-29296` query-latency failed on unsupported `get_token_time` before its
  provider batch materialized; the same-round plan-repair path did not recover
  this helper parameter error.
- `ST-2863` Clinic acquisition remained degraded by repeated HTTP 500/502
  failures and empty historical TiFlash metrics.
- No Jira internal comment was refreshed because both replays used `mode=read`.

## Next validation action

Fix bounded evidence-question truncation and same-round unsupported-field plan
repair, then rerun `APID-29296`. If the complete diagnosis criterion passes,
use the authorized `mode=write` path and verify the stable internal comment by
ID before promoting this problem to `optimized_verified`.