# SQL Query Tuning Diagnostic Owner

<!-- auto-oncall-optimization-record
{
  "schemaVersion": "auto-oncall-optimization-record-v1",
  "optimizationId": "sql-query-tuning-owner-2026-08-18",
  "problems": [
    {
      "problemId": "sql-performance-scenario-diagnostic-missing-query-tuning-workflow",
      "summary": "The modern provider-backed pipeline prohibited the Evidence Agent from using tidb-query-tuning but also did not supply that workflow to the Scenario Diagnostic Agent that owns query causality.",
      "status": "optimized_verified",
      "applicability": "Provider-backed sql_performance_tuning scenarios after the runner has materialized query-specific Slow Query or plan evidence.",
      "issueKeys": ["APID-29340", "APID-29344", "TCID-12989", "TCID-13038"],
      "sourceRefs": [
        "https://tidb.atlassian.net/browse/APID-29340#problem:query-tuning-diagnostic-owner-missing",
        "https://tidb.atlassian.net/browse/APID-29344#problem:query-tuning-diagnostic-owner-missing",
        "https://tidb.atlassian.net/browse/TCID-12989#problem:query-tuning-diagnostic-owner-missing",
        "https://tidb.atlassian.net/browse/TCID-13038#problem:query-tuning-diagnostic-owner-missing"
      ],
      "signalTextIncludesAny": [
        "query plan was collected but not analyzed",
        "why the exact query was slow remained unresolved",
        "tidb-query-tuning was not used by scenario diagnosis"
      ],
      "observedThrough": "2026-08-18",
      "effectiveAt": "2026-08-18T02:06:49Z",
      "verifiedAt": "2026-08-18T02:48:05Z",
      "attemptedAction": "Materialize the installed tidb-query-tuning skill plus its bounded MVCC and plan-verification references into the persistent Scenario Diagnostic Agent's initial SQL-performance turn while keeping the Evidence Agent neutral and provider-only.",
      "evidenceUrl": "https://tidb.atlassian.net/browse/APID-29344?focusedCommentId=23559192"
    }
  ]
}
-->

- Optimization ID: `sql-query-tuning-owner-2026-08-18`
- Owner: Scenario Diagnostic Agent
- Source references: `APID-29340`, `APID-29344`, `TCID-12989`, `TCID-13038`
- Implementation status: deployed to staging in image `3d785707e86be521b2c2f6168e096b4b2cc916e0`; source-case replay completed
- Effective status: `optimized_verified`

## Bounded problem

The Evidence Agent correctly remained a neutral provider planner and was
forbidden from applying `tidb-query-tuning`. The persistent Scenario Diagnostic
Agent, however, was also told not to load diagnosis skills, so the stage that
owns query causality did not consistently apply the plan, scan-amplification,
statistics, rewrite-safety, and before/after verification workflow.

## Change

For `sql_performance_tuning`, the runner reads the installed
`tidb-query-tuning` skill and its two bounded references and supplies them to
the persistent Scenario Diagnostic Agent's initial turn. The later
finalization turn explicitly continues that workflow against the validated
handoff. The Evidence Agent still loads only its selected Provider skill and
must not diagnose the query.

## Verification status

Staging deployment was Ready with zero Pod restarts on 2026-08-18. Local
contract coverage proves that the Scenario Diagnostic Agent receives the
installed query-tuning workflow and references, the Evidence Agent receives the
exact query identity only for neutral acquisition, and its diagnosis boundary
remains unchanged.

Two applicable deployed write replays verified the diagnostic behavior:

- `APID-29344` run `6aa66004-e09a-49bf-af92-4f43f1df3a3b` named the observed
  3.75x scan increase and matching latency increase, separated scan workload
  from wait/backoff/spill, refused to infer that `IndexHashJoin` alone was the
  cause, and kept IndexJoin, hint, binding, index, statistics, and rewrite
  changes conditional on same-parameter plan comparison. The Judge returned
  `ai_better`.
- `TCID-13038` run `69adacb2-2539-4d8c-b1e3-bc6eda333e4b` named the observed
  large-range scan and resource profile, refused to invent a plan conclusion
  after digest validation failed, and kept SQL/index/config actions pending a
  valid plan and before/after comparison. Its `human_better` verdict was due to
  a separate missing product fact about the approximately 340-second public
  endpoint idle timeout, not a reversal of the query-tuning workflow.

`APID-29340` stopped at Wetech target resolution and `TCID-12989` was classified
as `cluster_runtime_issue`, so neither reached this problem's applicability
boundary. All four Jira internal comments were updated in place and read back
as `public=false`.

## Unresolved gaps

This change does not manufacture missing plan facts and does not turn a plan or
rewrite proposal into a verified improvement. The applicable before/after
replay or Plan Replayer comparison remains required.

## Next validation action

Keep the query-tuning owner boundary under regression coverage. Track missing
plan evidence and the TCID-13038 public-endpoint timeout knowledge gap as
separate problems; neither should reopen this owner-placement action.