# Bridge Comment Classifier Provenance - Owner: runner comment selection and customer evidence materialization (`src/run-workspace.ts`). - Source: user-requested investigation of failed read run `67001b30-7e1f-4d94-bedc-78fea27eeb9c` on deployed `c5f5ce2a8a79ed554da57cc87b36e625d3822f91`. - Repair base: `dab58f3930d991e5826ca337e9a604ae628b3526`. - Status: deployed on `9faf894581356ca6af51fbf9f7a23ff6672258c9`; the bounded source-case criterion and exact-result publication passed. ## Exact cause and local verification The original classifier session `01a079bc-4cf0-7773-96d0-33d8de7ed947` contained the full Digest in comment text but `customerEvidence.sqlDigests=[]`. The classifier output itself requested `sql_or_digest`; policy normalization did not introduce this omission. Historical workspace evidence later contained the Digest because that path bypassed the customer-author filter. The visible-comment selector rewrote the transport author `TiDB Support Bot` to the bridge speaker's email. The customer filter could no longer recognize the bridge container and verify that speaker. The actual request-comment API has no account type for these comments; an `app` account type can also exhibit the same failure. The earlier local check used unprojected comments, so it did not exercise this production selector boundary. The fix preserves original author metadata through live, automatic replay, and explicit historical selectors. Comment presentation still shows the bridge speaker. Classifier and workspace evidence now run the same customer filter; no new semantic rules or LLM prompt changes were added. Local real-model checks used `gpt-5.6-sol / medium`, one trial per input: - The exact four visible customer bodies from the failed replay: Digest present, `evidence_assisted`, no missing keys, diagnostic admission passed; 15.136 s. - Original first two customer comments: same successful admission; 13.562 s. - Synthetic four-comment control removing only the Digest: `clarification_needed`, `missingKeys=[sql_or_digest]`, diagnostic admission blocked; 14.919 s. The script asserted four-comment IDs and bodies against the original classifier prompt before model execution. The source comment metadata was read again from Jira and normalized using the production field mapping. No later human finding was supplied. Artifact root: `/tmp/apid-29470-deployed-check-A2lZdU`, including `classifier-original.json`, `check-provenance.mjs`, and `provenance-results.json`. Deterministic regression now feeds the actual live and historical selectors into classification, verifies the same workspace Digest provenance, and excludes internal Support evidence. The local checks do not exercise Provider execution, Router diagnosis, final answer completion, or publication. A deployed source-case read replay and applicable exact-result publication are still required. Validation: TypeScript build, all 136 focused tests, all 1,109 full-suite tests, and `git diff --check` passed. ## Post-deployment verification on 2026-09-07 The live staging service reported build `9faf894581356ca6af51fbf9f7a23ff6672258c9`, with a Ready Pod, zero restarts, and HTTP 200 health/readiness responses. Both staging applications were updated through app-delivery PRs #79344 and #79345; release run `34078483769` succeeded. One read replay, `eff3e954-b116-4f5a-80ae-b91cde2e087a`, completed with HTTP 200 in 915.321 seconds. Its historical cutoff was `2026-09-05T10:19:36+0800`, target human comment `23815280`, with exactly customer comments `23815229`, `23815232`, `23815277`, and `23815279`: the same four-comment input as the failed baseline. Later human MVCC and expression-mismatch findings were not model inputs. The classifier's actual input contained the supplied Digest with source `23815229`. Classification returned `evidence_assisted`, present `sql_or_digest`, and no missing keys. Diagnostic admission, Router assignment, both scenario branches, Router reconciliation, and Final Response all completed. The final reply did not ask for SQL or Digest and no Digest publication correction ran. Its only customer clarification was confirmation of the assumed cluster alias. Judge returned `different_but_valid`, with no AI gaps. That does not establish the SQL's root cause or validate an index recommendation. Evidence acquisition was `degraded`: target execution detail hit `provider_dashboard_login_failed` with navigation `ERR_ABORTED`, and one TiKV metrics request hit `provider_grafana_query_failed` after a 30-second query timeout. Both scenarios remained inconclusive; those independent Provider limitations remain unresolved. `publish-read` published this exact frozen result without a second analysis: - answer fingerprint: `34979c3a2a11d6ad0b64596fabe41021f9f46f87bcbce831823607881011467b`; - database run: `150211`; database and evaluation: `written`; - stable Jira internal comment: `23815249`, updated in place; - Jira readback: `public=false`, with matching paired body; - Feishu/Base: `updated`; publication errors: none. Verification is limited to this record's bounded problem, not completion of all APID-29470 SQL diagnosis. Evidence is preserved under `/tmp/apid-29470-provenance-release/`, including the actual classifier input, frozen run, HTTP result/timing, publication response, and Jira readback.