# Wetech exact-Digest execution plans Owner: AOS Managed Wetech Provider Executor for acquisition and compaction; `agent9-provider-evidence.ts` for preserving those sanitized rows in the handoff. Base: fetched `origin/main` at `59ab3bf045056c38cf17b4b37a499e9cd79fa5a7`. The nominated historical answer is run `24706246-6dbd-4ee6-be6a-a7854dce1716`, fingerprint `354db88bd2c091a0a32c6ee71c137cf6d2946e80c8896c44e6183d17187778dd`, feedback 130908 (`wrong`). The customer supplied the SQL and exact Digest, and already mentioned g1 full scan. Preserved Agent9 turns show both Scenario Diagnostic sessions successfully read `tidb-query-tuning` and its plan reference. The exact-Digest Provider result redacted `plan`, `binary_plan` and `query_time`; the workload-hotspot branch inferred PRIMARY workload from cop/process aggregates. PRIMARY is an index label, not a table. The later human/customer comment supplies TableFullScan_33 with 33,947,150 rows, TableReader_35 at 3.03 s and HashJoin_19 at 3.2 s. Those later numeric facts are regression motivation, not evidence available to the historical AI. Implementation alone does not establish whether a fresh answer reproduces the historical diagnostic error; the post-deployment replay and subsequent manual acceptance below provide the separate case-level assessment. An exact Digest now automatically requests plans for at most three execution records. Broad discovery omits plans. Raw binary plans remain Provider-local; Dashboard's authenticated decoder can produce structured operators, which are allowlist-compacted before crossing the Provider boundary. Missing plans and truncation remain explicit. SQL/predicates, opaque raw identities and raw plans are excluded. Same-row timings and tree relationships survive runner materialization past the former 4,000-character preview boundary. No Diagnostic parameter, diagnosis prompt, Router or Final Response behavior is added. Validation: deterministic tests cover exact/broad request wiring, actual Dashboard visualplan field shapes, same-row association, bounded decoding, missing/undecodable plans, tabular plans and large-plan handoff preservation. Dashboard schema reference: https://github.com/pingcap/tidb-dashboard/blob/master/pkg/apiserver/utils/binary_plan.go The bounded local Docker query on 2026-09-07 stopped at `dashboard_login` with `dashboard_session_not_ready`, after accepted P81 MFA landed on the Downloads portal. It never executed Slow Query and is not a Provider-data pass. No unchanged login retry was made. The login failure is a separate transport gap and is not included in this repair. Local logs: `/tmp/wetech-digest-plan-local.log` and `/tmp/wetech-digest-plan-tests.log`. All 1,107 tests pass on the updated main baseline, including the 80 focused Provider/package/materializer tests. Immutable Wetech v41 package `ee865eff97be8e0b8dc26567d08a727932f40166ca41734e26e73f2936f9df9f` is published in bundle `9e167aec4a778dd5f6a9d6785bad26a4942e5e8296daddc07dccf1223c7fb72f`. Exact-version download SHA-256 and source/pin validation pass. Earlier package versions are preserved. This is artifact publication only; it does not install the package, change the running Agent9 image or establish live effectiveness. ## Local data and deployment verification After the user corrected the local Dashboard password, the same bounded Docker query passed and returned three real executions with complete six-operator plans. Each g1 TableFullScan_33 scanned 33,690,582 rows. The containing TableReader_35 took 2.53–2.57 s against SQL latency 2.75–2.78 s; the other IndexReader_43 took 63.3–120.7 ms. These are same-execution branch timings, not a claim that TableFullScan itself consumed the entire TableReader time. Evidence: `/tmp/wetech-digest-plan-password-retest.log`. Source PR #1351 merged as `819eacbebafa014a14eca6fa1ff551e248c5b41d`. The AOS-owned bundle rollout loaded v41 into both Agent9 Pods with loader exit 0 and Ready true; the existing Agent9 image stayed unchanged. Release 34077937505 succeeded at source `dab58f3930d991e5826ca337e9a604ae628b3526`. Exact Evidence Agent installation readback showed Wetech v41 and the package digest above, with its existing unrestricted network grant. app-delivery PRs #79339/#79340 merged. The active analysis Deployment was then synchronized to that exact merged image; metadata returned the matching SHA and root, health and readiness endpoints returned HTTP 200. The first read replay, `ffbf9029-5f83-4c0f-8974-a394b40065f8`, was interrupted by a concurrent rollout to `03d6d2d1e8effc22ae501edf71b714d0285affb0`. Its HTTP response was 500 `Pool is closed.` after 188267 ms; the subsequent exec process exited 137. Its successful primary-analysis call is not a completed replay result. The transient workspace disappeared with the Pod. A temporary standalone Pod then used that already-live descendant image with the same configuration snapshot and Secret references, automation/report/Base/ notification/publication flags disabled, a private emptyDir in place of the shared Codex PVC, and a 30-minute lifetime. Its first setup attempt omitted the main service's local Codex auth file, so classifier run `1ca5bb6f-de2b-4ad2-90bd-83e4379bc144` fell back to `scenario_classifier_failed`. The test client also exposed Node fetch's five-minute header timeout. This invalid setup was archived and terminated; neither failure evaluates the plan repair. The Pod was recreated with authentication copied privately before server startup, and the local client used native HTTP with a bounded 30-minute response wait. No production model or execution timeout was changed. The corrected read replay is `275eedcd-c476-43c8-a402-ed96642ab28b`. Classification succeeded as `sql_performance_tuning/direct_answer`, explicitly retaining `table_full_scan_reported`, with no Provider selected. This path does not exercise the new plan acquisition/materialization through Scenario Diagnostic. It completed with HTTP 200 in 235462 ms, fingerprint `4fab38f492d8f311f69c9dfc759a026cf8eb1f5a6d846c50979f75c30dc844e5`. The answer explicitly names the original g1 full scan and the customer's 2–3 s to 0.23 s improvement with the forced index. The historical PRIMARY workload attribution is absent. Its subsequent advice focuses on candidate g2 indexes and EXPLAIN ANALYZE validation. This is reasoning from customer input, not use of the newly acquired operator facts; no Provider call or Scenario Diagnostic run occurred. Judge returned `different_but_valid` with `eligibility=comparable`. Its human reference is comment 23808074, explaining the later index comparison and recommending binding the tested index; the replay cutoff remains comment 23807383 and later comments are excluded from model input. This is not the same answer/reference pair as historical feedback 130908. Judge also claimed that an index suggested for g2 could not filter g1; inspection of the frozen SQL shows both aliases refer to `ad_site_game`, so that particular critique is not accepted as a proven SQL defect. Judge's persisted verdict is retained. Database, Jira, evaluation persistence and Feishu publication all remain `not_requested`. The exact read response, output messages and complete run archive were saved before deleting the temporary Pod. No shared PVC was modified, and no production model or timeout setting changed. Artifacts are under `/tmp/apid-29460-plan-replay-Srxbv0/`. ## Accepted optimization outcome — 2026-09-07 Status: `optimized_verified`, following the user's explicit review and request to mark this optimization goal achieved. Status-update base: fetched `origin/main` at `8d95e799562775a8113f2d1cd5d7dd0ec9c911a7`. The accepted criterion combines the bounded local real-data Provider check with the completed post-deployment source-case replay. The local check proves that exact-Digest results retain usable execution plans and same-row timings; the replay retains the customer's g1 full-scan evidence and does not repeat the historical unsupported PRIMARY workload attribution. The user's actual request supplied SQL, the full-scan observation and the forced-index improvement, then asked for alternative approaches. Classifying that self-contained method review as `direct_answer` is appropriate. No routing change or forced Provider query is required to close this accepted optimization goal. Verification remains bound to read run `275eedcd-c476-43c8-a402-ed96642ab28b` and fingerprint `4fab38f492d8f311f69c9dfc759a026cf8eb1f5a6d846c50979f75c30dc844e5`. The current Judge verdict remains `different_but_valid`; historical feedback 130908 remains `wrong` on its original answer. This status does not establish that the plan patch caused the direct answer's improvement, nor that every possible optimization question on APID-29460 is resolved. The user accepted the existing evidence and requested this record-status update. This is a manual acceptance of the bounded outcome, not a claim that the standard automatic repair/publication lifecycle completed. The replay did not exercise live Provider-to-Scenario-Diagnostic plan consumption, and Jira, DB, evaluation persistence and Feishu remain unchanged. Those limits are retained explicitly rather than represented as completed verification or publication. Next validation action: none required for this user-accepted outcome. A future case that actually requires Provider evidence can separately verify the live plan-consumption path; it is not a blocker for this status update.