# SQL ID Structured Plan Handoff

<!-- auto-oncall-optimization-record
{
  "schemaVersion": "auto-oncall-optimization-record-v1",
  "optimizationId": "sql-id-structured-plan-2026-08-18",
  "problems": [
    {
      "problemId": "explicit-sql-id-not-bound-to-structured-plan",
      "summary": "An exact 64-hex SQL ID in customer context was not admitted as a supplied Digest, so the Wetech Slow Query request remained broad and did not retrieve the exact structured plan needed to answer an operator-choice question.",
      "status": "optimized_verified",
      "applicability": "Provider-backed SQL performance cases where the customer supplies one exact 64-hex SQL ID and asks about the corresponding plan or operator choice.",
      "issueKeys": ["APID-29344"],
      "sourceRefs": [
        "https://tidb.atlassian.net/browse/APID-29344#problem:explicit-sql-id-not-bound-to-structured-plan"
      ],
      "signalTextIncludesAny": [
        "SQL ID was not extracted as a Digest",
        "exact structured plan was not retrieved",
        "operator question was answered without the exact plan"
      ],
      "observedThrough": "2026-08-18",
      "effectiveAt": "2026-08-18T10:52:19Z",
      "verifiedAt": "2026-08-18T11:45:00Z",
      "attemptedAction": "Recognize an explicit 64-hex SQL ID in runner-owned customer evidence, bind that exact identity to the Wetech Slow Query request, and make the resulting structured plan primary while keeping screenshots supplementary.",
      "evidenceUrl": "https://tidb.atlassian.net/browse/APID-29344"
    }
  ]
}
-->

- Optimization ID: `sql-id-structured-plan-2026-08-18`
- Owner: runner-owned customer evidence and Provider context handoff
- Source reference: `APID-29344`
- Implementation status: merged in PR `#970`, deployed, and replay verified
- Effective status: `optimized_verified`

## Bounded problem

The customer supplied one exact 64-hex value under the label `SQL ID`, but the
runner only recognized Digest, template-ID, or whole-comment bare-hex forms.
The Wetech Evidence plan therefore searched broadly and never received the
exact identity needed for the already-supported decoded Slow Query plan path.

## Change

- Admit an exact `SQL ID: <64hex>` value into the existing runner-owned
  `sqlDigests` field; do not create a second identity field.
- Reuse the existing exact-Digest Provider Executor binding and binary-plan
  projections.
- Treat the structured Slow Query plan as primary. A supplied screenshot may
  add context, but OCR is not a prerequisite when the exact plan is available.

## Verification status

Local contract coverage must prove extraction, immutable Provider handoff,
exact Slow Query binding, plan projection, and Scenario Diagnostic ownership.
Case-specific replay and Jira internal-comment refresh remain pending.

## Unresolved gaps

An unavailable or undecodable plan remains an explicit evidence gap. This
change does not broaden the direct-artifact gate or infer plan semantics from
an operator name alone.

## Next validation

Deploy once local integration passes, replay `APID-29344`, and verify that the
request binds the supplied SQL ID, materializes safe operator facts, answers
the IndexHashJoin-versus-IndexJoin question from the exact structured plan,
and refreshes the existing Jira internal comment in place.