# Larger execution facts within the existing handoff budget

<!-- auto-oncall-optimization-record
{
  "schemaVersion": "auto-oncall-optimization-record-v1",
  "optimizationId": "evidence-fact-64k-2026-09-07",
  "problems": [
    {
      "problemId": "decoded-plan-exceeds-single-fact-budget",
      "summary": "APID-29470 decoded SQL execution facts exceed the 16K single-fact limit before scenario diagnosis.",
      "status": "optimized_verified",
      "applicability": "Runner-owned diagnostic evidence facts; 128 KiB aggregate handoff budget remains unchanged.",
      "issueKeys": [
        "APID-29470"
      ],
      "sourceRefs": [
        "https://tidb.atlassian.net/browse/APID-29470#problem:decoded-plan-exceeds-single-fact-budget"
      ],
      "signalTextIncludesAny": [
        "diagnostic_observations_statement_invalid"
      ],
      "observedThrough": "2026-09-07",
      "effectiveAt": "2026-09-07T13:18:37.160Z",
      "verifiedAt": "2026-09-07T15:31:35Z",
      "attemptedAction": "The post-change isolated read run 5aa523af-28ca-4bec-bf8e-6ae4270cc033 passes the bounded plan-materialization criterion. On explicit operator request, publish-read preserved its exact fingerprint and updated internal Jira comment 23815249, DB run 150218, evaluation and Base; no new replay.",
      "evidenceUrl": "https://tidb.atlassian.net/browse/APID-29470?focusedCommentId=23815249"
    }
  ]
}
-->

Owner: AOS runner diagnostic evidence contract. Source: explicit operator request on 2026-09-07.

Raise the single compact fact limit from 16,384 to 65,536 JavaScript string-length units. Keep the total Scenario handoff at 128 KiB of UTF-8 JSON and preserve whole-observation omission, query coverage and canonical references. No Provider package or model-context budget changes.

Local verification on 2026-09-07: 109 focused tests passed, including exact 64K acceptance, rejection above 64K, unmodified SQL/plan preservation and aggregate-budget enforcement. Frozen APID-29470 run `86eca81f-c2ee-4506-affd-92cf8b08c748` Provider output now materializes for both scenarios: query-latency has 1 observation and 34,340 handoff bytes; workload-hotspot has 9 observations and 64,512 bytes. Both retain the detailed plan. This is offline runner validation, not a new model/Provider replay; TopSQL failures remain partial acquisition.

PR #1385 is merged and deployed. Post-deployment verification below checks whether the same ticket reaches Scenario Diagnostic with the detailed execution plan while retaining the total budget. The historical TopSQL 503/OOM root cause is a separate question.

## Deployment and isolated replay

AOS `eefdf77930d9c425299f1e7a1b21c32e3fc31afd` is Ready on image digest `sha256:f777036a6a3f42f76013867c4f4c7655443bf0fcdb461c112788ad7bc86226f4`. Release workflow 34125767050 and app-delivery PRs #79452/#79453 succeeded. Evidence Agent installation readback confirms Wetech v54 (`eecc16ae2f187145db39fbf048ba678779ed22e355b076b336ee4676c8e1b00b`). Agent9 loaded the AOS-owned bundle on both Ready replicas without an application-image change.

One isolated read replay completed at 2026-09-07T13:38:20.091Z after 1,182,931 ms (19m 42.931s): Job `aos-replay-apid-29470-a1926c51`, run `5aa523af-28ca-4bec-bf8e-6ae4270cc033`, answer fingerprint `5e39a78d896f8865a3d1ef05f48278da93bd002c2eb98707385e392c22c4d649`. Judge returned `ai_better`; response generation completed, evidence acquisition remained degraded. Full run, frozen read-publication, summary and logs were exported to `/home/nizheming/.cache/auto-oncall-services/replays/apid-29470-main-eefdf779-20260907`; the Job was deleted after collection. No Jira, DB or Base publication was performed.


Both scenario handoffs accepted the 28,651-character target SQL/execution-plan fact and reached real Scenario Diagnostic turns. Serialized handoffs were 48,263 and 74,473 UTF-8 bytes, below the unchanged 128 KiB total cap. No `diagnostic_observations_statement_invalid` recurred. Query latency was confirmed from forced index lookup, row flow and expression/index-column mismatch; the final answer retained that diagnosis and did not request SQL or Digest again. This passes the bounded materialization/replay criterion, but the record initially remained `optimized_unverified` because no applicable Jira refresh had yet been requested. Overall case acceptance is still limited by an incomplete workload refinement and a time-label mismatch: provider epoch 1788547260–1788547860 is 2026-09-05 10:41–10:51 UTC+08:00, while the final answer labels it 02:41–02:51 UTC+08:00. Those are separate owners, not a reason to enlarge the fact limit again.


## Exact read-result publication

At the operator's request, the existing read replay was published after deployment of AOS `65232e57`; no new full replay was started. Its frozen `read-publication.json` was transferred byte-for-byte to the new Ready service and checked against SHA-256 `1661a168c8fca88050bc7f0b72cbe080824ffd1808a896eae03776d25e0ec28e`. The dedicated `POST /v1/tickets/publish-read` returned HTTP 200 with the same run ID and answer fingerprint, updated internal Jira comment `23815249`, DB run `150218`, persisted evaluation and `feishuDashboard=updated`, with no publication errors. Publication success was recorded at 2026-09-07T15:31:35Z.

This completes the Jira refresh requirement for the already-passed 64K fact criterion only. The published answer remains the original eefdf779/v54 answer, including its known time-label mismatch and incomplete workload refinement. The later v58 canary returned unknown Tool result and is recorded separately; neither publication nor Judge `ai_better` makes the whole case verified. No further query or replay was requested in this completion step. Publication evidence: `/home/nizheming/.cache/auto-oncall-services/replays/apid-29470-v55-canary-publish-20260907/publication-response.json`.