# Supplied SQL Digest in Classifier Input - Owner: Scenario Classifier input and prompt (`src/llm-scenario-classifier.ts`). - Source: user-requested follow-up to the failed local APID-29470 check after PR #1350. Source base: `a7b193cf99dfff514fb58c8eef3220c9d6ea78e2`. - Implementation status: deployed; the post-deployment source-case replay still reproduces the missing SQL-target classification. ## Bounded change Reuse the existing pure `customerEvidence` builder to supply only `sqlDigests` and their provenance to the classifier. Keep the same visible-comment and customer-author filtering used for workspace evidence. No new Digest parser, classification output field, downstream correction, or Provider authority is introduced. An empty Digest list does not imply that SQL text or a plan is absent. ## Local verification on 2026-09-07 The baseline at `751b293f` extracted the exact Digest from comment `23815229`, but one real `gpt-5.6-sol / medium` classification still returned `clarification_needed`, `missingKeys=[sql_or_digest]`, and diagnostic admission reason `customer_sql_target_required`. After this change, the same model and reasoning setting were run once per input: - Source case: the same two unedited customer comments (`23815229`, `23815232`) returned `sql_performance_tuning / evidence_assisted / wetech`, `lookupKeysPresent` included `sql_or_digest`, `missingKeys=[]`, and diagnostic admission passed. Model wall time: 18.282 seconds. Local run: `23aa294a-8c09-4664-a835-a25cc2058479`. - Synthetic control: remove only the Digest from the first comment, retaining the cluster context and index DDL. Classification kept `clarification_needed` and `missingKeys=[sql_or_digest]`; diagnostic admission remained blocked. Model wall time: 26.428 seconds. Local run: `5743c1c9-0437-4eda-83ea-306d2884d857`. The original runtime workspace was unavailable; the source input was rebuilt from the unedited Jira comments selected by its persisted input manifest. Later human findings and the later incident-time clarification were excluded. Local evidence is retained at `/tmp/apid-29470-classifier-check-iyRVIc/result.json`, alongside the exact prompts, parsed classifications, input and tested source diff. The TypeScript build, 52 focused tests, and all 1,102 full-suite tests passed. ## Remaining verification These checks cover classifier input, real-model classification, customer evidence materialization and deterministic diagnostic admission. They do not query a Provider or exercise Router diagnosis, Final Response, Jira, database or Base writes. One trial per input is not a reliability estimate. Keep this problem unverified until an authorized post-deployment APID-29470 read replay passes the same missing-target criterion and the applicable internal-comment refresh completes. ## Deployment verification on 2026-09-07 Deployed merged-main image `c5f5ce2a8a79ed554da57cc87b36e625d3822f91` through [app-delivery PR #79335](https://github.com/tidbcloud/app-delivery/pull/79335). The running service reported that exact build SHA, Ready 1/1, zero restarts, and HTTP 200 from both health endpoints. The release retained Wetech v40; it did not include the later v41 source change. One `mode=read` request produced run `67001b30-7e1f-4d94-bedc-78fea27eeb9c`. The automatic historical cutoff selected human comment `23815280`, including customer comments `23815229`, `23815232`, `23815277`, and `23815279`. This includes the later incident-time clarification and is not identical to the two-comment local regression. Later MVCC and expression-mismatch findings remained excluded. Customer evidence retained the exact Digest with source `23815229`, but the fresh replay classification still returned `clarification_needed` and `missingKeys=[sql_or_digest]`. The diagnostic pipeline was ineligible with `customer_sql_target_required`; Router and scenario stages did not run. The fallback analysis did not obtain Wetech evidence. The request finally returned HTTP 500, `codex_re_requested_existing_customer_sql_digest`, after 244.714 seconds. No successful answer fingerprint or publishable read result was returned, and no publish-read call was made. Keep this problem `ineffective`: the local one-trial result did not generalize to this deployed replay input. The next investigation must examine the classifier's exact input and semantic decision on the four-comment replay, then the owner of diagnostic admission; deployment readiness alone is not a pass. No additional implementation or repeat replay was performed in this release. Evidence: `/tmp/apid-29470-deployed-check-A2lZdU/replay.json`, `replay-timing.txt`, and `frozen-run.tgz`. ## Follow-up root cause Inspection of the exact original classifier session later established that its Digest projection was empty, despite the full Digest remaining in comment text. The failure was an input-materialization defect at the comment-selector boundary; the one-trial local check had bypassed that selector. This supersedes the earlier hypothesis that the supplied-Digest prompt did not generalize to four comments. See [bridge comment provenance](2026-09-07-bridge-comment-classifier-provenance.md). The final HTTP 500 was a separate regex false positive, documented in [Digest publication guard](2026-09-07-digest-publication-semantic-guard.md). The follow-up bridge-provenance repair subsequently passed deployed replay `eff3e954-b116-4f5a-80ae-b91cde2e087a` and exact-result internal publication on `9faf8945` (database run `150211`, fingerprint `34979c3a2a11d6ad0b64596fabe41021f9f46f87bcbce831823607881011467b`). The earlier action's `ineffective` status describes its failed standalone validation; the current answer no longer reproduces that missing-Digest signal. Current verified attribution belongs to the bridge-provenance repair above.