# Description SQL Digest Evidence

<!-- auto-oncall-optimization-record
{
  "schemaVersion": "auto-oncall-optimization-record-v1",
  "optimizationId": "description-sql-digest-evidence-2026-08-18",
  "problems": [
    {
      "problemId": "description-bare-sql-digest-not-supplied-to-provider",
      "summary": "An exact SQL Digest on its own line in a multi-line ticket description was visible to classification but absent from runner-owned customer evidence, so Wetech used broad Slow Query searches instead of the exact workload identity.",
      "status": "optimized_verified",
      "applicability": "SQL performance tickets whose frozen description contains one exact labelled 64-hex SQL Digest or one bare 64-hex Digest occupying a complete line.",
      "issueKeys": ["APID-29340"],
      "sourceRefs": ["https://tidb.atlassian.net/browse/APID-29340#problem:description-digest-not-in-provider-context"],
      "signalTextIncludesAny": ["exact SQL Digest in description", "broad Slow Query search", "description digest missing from customer evidence"],
      "observedThrough": "2026-08-19",
      "effectiveAt": "2026-08-19T00:57:14+08:00",
      "verifiedAt": "2026-08-19T10:24:47+08:00",
      "attemptedAction": "Extract exact labelled or complete-line bare SQL Digests from the frozen ticket description in the runner-owned customer-evidence artifact and bind the single exact value to query-latency Slow Query acquisition.",
      "evidenceUrl": "https://tidb.atlassian.net/browse/APID-29340?focusedCommentId=23548869"
    }
  ]
}
-->

- Optimization ID: `description-sql-digest-evidence-2026-08-18`
- Owner: runner-owned frozen input materialization
- Source reference: `APID-29340`
- Implementation status: deployed in image `00add7fc3ad53efc10d99e6fa9e687b1fae3197c`
- Effective status: `optimized_verified`

## Bounded problem

The ticket description supplied one exact Digest on its own line. The
classifier recognized that the ticket had SQL identity, but `customer-evidence`
extracted Digests only from visible customer comments. The immutable Wetech
context therefore had no exact Digest and the Provider plan fell back to broad
Slow Query searches.

## Change

- Extract labelled 64-hex Digests and complete-line bare 64-hex Digests from
  the frozen description as runner-owned customer evidence. For Jira ADF, read
  hard-break and block boundaries from the immutable raw description before
  the reply-safe ticket projection flattens whitespace.
- Record description-versus-comment provenance without asking an Agent to
  re-extract identity.
- Keep inline unlabeled hexadecimal text inadmissible and keep Provider exact
  binding limited to one supplied Digest.

The first deployed replay (`ab3f5e35-5ddc-43da-92bb-975113b71bd5`) exposed a
materialization gap in the initial implementation: `ticket.json` had already
collapsed the ADF hard break around the bare Digest, so `customer-evidence`
remained empty and Wetech still performed broad `text=DELETE` searches. That
run did not verify this optimization. The corrected implementation derives the
line boundary from the raw Jira ADF while continuing to reject inline opaque
hexadecimal values.

## Verification evidence

Read replay `ee2e4329-e044-4ea1-bd7a-9de9c8553337` and write replay
`e3615672-9bb2-4245-9f6c-9ad2f5e565c0` both bound Wetech Slow Query acquisition
to the supplied DELETE Digest. The query-latency, write-path-contention, and
workload-hotspot scenarios returned retained exact executions instead of a
broad text-only approximation. The written answer used those executions to
compare six 33.6--45.5-second runs with the 0.73-second final run.

The write replay updated existing Jira internal comment `23548869`; direct
readback confirmed the expected text and `public=false`. Database run `150100`,
evaluation, and Feishu Base publication all succeeded.

## Unresolved gaps

An exact Digest identifies the workload but does not prove that its transaction
caused the alert. Provider retention may still omit the matching execution or
decoded plan.

This bounded frozen-input identity problem is verified. The exact Digest does
not by itself prove that the DELETE caused the rare scheduler alert; that
separate attribution boundary remains explicit in the answer.