# Bare SQL Optimization Requests Ask for the Target First

<!-- auto-oncall-optimization-record
{
  "schemaVersion": "auto-oncall-optimization-record-v1",
  "optimizationId": "bare-sql-target-clarification-2026-08-27",
  "problems": [
    {
      "problemId": "bare-sql-optimization-runs-global-discovery-before-target-selection",
      "summary": "An explicit SQL optimization request without a customer-selected SQL target could enter Provider discovery and present globally expensive SQL candidates before asking which SQL the customer wanted optimized.",
      "status": "candidate",
      "applicability": "Explicit SQL optimization or tuning requests with no supplied target SQL, Digest, or concrete plan and no concrete slow-query, latency, resource, or other runtime symptom.",
      "issueKeys": ["APID-29360"],
      "sourceRefs": ["https://tidb.atlassian.net/browse/APID-29360#problem:bare-sql-target-clarification"],
      "signalTextIncludesAny": [
        "直接先确认具体sql digest",
        "SQL optimization without a target SQL",
        "global workload discovery before target selection"
      ],
      "observedThrough": "2026-08-27",
      "effectiveAt": null,
      "verifiedAt": null,
      "attemptedAction": "Classify an explicit bare SQL optimization request as clarification_needed with sql_or_digest missing, stop before Scenario Router and Provider execution, and ask only which SQL or Digest the customer wants optimized.",
      "evidenceUrl": "https://tidb.atlassian.net/browse/APID-29360#comment-23721033"
    }
  ]
}
-->

- Owner: Scenario Classifier missing-context decision, deterministic routing
  normalization, and diagnostic pipeline admission
- Source: APID-29360 feedback comment `23721033`
- Implementation status: local candidate
- Effectiveness status: `candidate`

## Bounded problem

The customer requested SQL optimization without identifying a target SQL,
Digest, or plan and without describing a concrete runtime symptom. Auto-oncall
could treat the request as workload discovery, query TopSQL or Slow Query, and
present globally expensive candidates even though those candidates could not
identify which SQL the customer wanted optimized.

## Candidate change

- Preserve `sql_or_digest` as customer-owned context for this exact request
  shape while keeping symptom-led slow-query and latency discovery unchanged.
- Normalize an Agent classification that incorrectly selects
  `evidence_assisted` for this shape back to `clarification_needed`.
- Stop diagnostic admission before Scenario Router or Provider execution.
- Ask only which SQL or Digest should be optimized. Do not add speculative
  index, rewrite, or global workload guidance before that target is supplied.
- Keep response-format policy presentation-only; the ownership decision stays
  in classification and Primary Analysis.

## Verification evidence

Focused contract tests cover deterministic classification, normalization of an
Agent-produced evidence-assisted classification, Provider-pipeline admission,
Primary Analysis input, and the unchanged response-format ownership boundary.
The change has not been merged or deployed, so it remains `candidate`.

## Unresolved gaps

- APID-29360 cannot provide an equivalent current Wetech replay because the
  Wetech OP Provider is disabled.
- No deployed non-Wetech runtime has yet demonstrated the new stop boundary and
  paired clarification response.

## Next validation action

After deployment, run a read-only representative Cloud ticket snapshot with a
typed org and cluster plus a bare SQL optimization request. Verify that the
result asks only for the target SQL or Digest and that runtime trace contains
no Scenario Router, Evidence Agent, Scenario Diagnostic Agent, or Provider
execution before that target is supplied.