# Digest Publication Semantic Guard

<!-- auto-oncall-optimization-record
{
  "schemaVersion": "auto-oncall-optimization-record-v1",
  "optimizationId": "digest-publication-semantic-guard-2026-09-07",
  "problems": [
    {
      "problemId": "digest-publication-regex-rejects-time-clarification",
      "summary": "Publication regex treated an incident-time clarification mentioning an existing Digest as a request to provide that Digest, causing an extra correction and HTTP 500.",
      "status": "optimized_verified",
      "applicability": "Direct-path replies that request another discriminator or state that an existing SQL Digest will be used.",
      "issueKeys": [
        "APID-29470"
      ],
      "sourceRefs": [
        "https://tidb.atlassian.net/browse/APID-29470#problem:digest-publication-regex-rejects-time-clarification"
      ],
      "signalTextIncludesAny": [
        "Publication regex treated an incident-time clarification mentioning an existing Digest as a request to provide that Digest, causing an extra correction and HTTP 500."
      ],
      "observedThrough": "2026-09-07",
      "effectiveAt": "2026-09-07T03:14:34Z",
      "verifiedAt": "2026-09-07T03:32:56Z",
      "attemptedAction": "Remove SQL/Digest semantic regex validation and its post-analysis correction trigger. Keep the selected semantic answer owner responsible for supplied identity.",
      "evidenceUrl": "https://tidb.atlassian.net/browse/APID-29470?focusedCommentId=23815229"
    }
  ]
}
-->

- Owner: SQL/Digest branch in `src/runner.ts::runPublicationGuard`.
- 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 failed run's initial reply said it would use the existing customer Digest.
Its simulated follow-up asked for the incident time and timezone, followed by
"以便按 Digest 查询". The publication regex matched the word `Digest` within
60 characters after `请提供`, regardless of the requested object. The corrective
reply explicitly said no repeated SQL or Digest was needed, and the same regex
still rejected it. This was not evidence that the final answer requested the
Digest again.

Remove this diagnostic-semantic branch, its evidence reread, regex, obsolete
trace flag, and error. Do not add negation patterns or a second LLM validator.
The selected Primary Analysis or Scenario Router continues to own customer
context semantics; the actual authorization and publication boundaries remain.
Other legacy guard branches are outside this bounded repair.

The runner regression supplies existing Digest evidence and a complete valid
reply asking for time while mentioning Digest use and negating a repeat ask.
It verifies successful result handling without a publication-guard correction.
The full runtime trace is in
`/tmp/apid-29470-deployed-check-A2lZdU/frozen-run.tgz`.

This local runner check does not establish that the deployed source-case
analysis or Provider diagnosis succeeds. Keep the problem unverified until a
post-deployment read replay completes without this false rejection and the
applicable internal-comment refresh succeeds.

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.