# Bounded Provider Evidence Input - Optimization ID: `bounded-provider-evidence-input-2026-07-27` - Owner: auto-oncall-services with Wetech provider skill handoff - Source reference: `APID-29194` replay duration and evidence-volume review - Implementation status: local candidate; not deployed - Effective status: `candidate` ## Bounded problem The diagnostic agent can receive a compact provider preview but still open raw TopSQL, Statements, Slow Query, metrics, plan, or log artifacts. A broad provider query may also select the first discovered instance or enumerate many instances before the affected path is known. This expands context without improving the causal boundary. ## Candidate change The diagnosis contract now requires a run-scoped provider output directory and progressive evidence consumption: - choose exactly one affected or highest-impact instance for each component surface from time-aligned metrics; - query that instance's Top 10 Digests rather than treating the first Dashboard instance as top; - keep Statements and Slow Query reasoning to at most ten projected decision rows on the selected TiDB instance; - use compact stdout and the compact report as the default reasoning source; - retain raw/detail files for audit and replay without loading them into model context; - when a load-bearing field is missing, perform one narrow exact query or return a bounded provider limitation. The local Wetech provider package is being updated separately as an external skill implementation. This repository does not import or depend on its code. The bundled Manus provider also requires an explicit metric-selected TopSQL instance and defaults to Top 10 Digests. ## Verification evidence Repository contract and provider unit tests must verify the single-instance, Top 10, compact-summary, and raw-artifact boundaries. A blind historical replay must then verify actual provider commands, output bytes, files read by Codex, and diagnosis quality. Unit tests alone do not promote this problem beyond `candidate`. The historical-cutoff `APID-29194` replay `c8f42913-d4c0-4535-8edd-0f2d8dd37e0e` is only partial evidence. It showed zero explicit raw provider-file reads, one selected-instance TopSQL command, and a successful bounded evidence/synthesis path. However, it used the previous Wetech provider implementation: the TopSQL command emitted 554,415 bytes, its report was 691,679 bytes, and the initial turn consumed 2,030,971 input tokens. It therefore does not verify the compact-summary boundary and must not be treated as a passing compact-provider replay. Later replay `63a5df5e-b424-4bc5-bae0-b78e3199d161` exercised the current compact provider query path. It persisted a 1,169,980-byte raw TopSQL artifact while exposing an 8,622-byte compact report, and persisted a 75,503-byte raw Slow Query artifact with a 12,111-byte compact report. The agent used one readiness query, one mechanism query, one selected-instance TopSQL Top 10 query, and one table-text Slow Query without reading the raw artifacts. That query chain found the expected originating UPDATE and transaction shape. The later run timed out during final JSON generation and returned no accepted case result. It is positive implementation evidence for compact provider handoff, not complete end-to-end acceptance. The durable status remains `candidate`, with null effective and verification timestamps, because the candidate is not published to staging and no post-change replay has returned a complete result. Branch-local read-only replay `f79d1126-2a24-46ea-b1d8-f0a0a949a735` subsequently returned HTTP 200 in 353.271 seconds and supplied complete end-to-end acceptance evidence for the local provider boundary: - the selected TiKV TopSQL Top 10 query used literal `--window 10s`; - the 1,169,980-byte TopSQL raw artifact was represented by an 8,622-byte compact report; - the 76,940-byte Slow Query raw artifact was represented by a 13,403-byte compact report; - the trace contained zero commands that read raw provider artifacts; - after the generic transaction wrapper, the agent used one table-text Slow Query rather than broad TiDB TopSQL or Statements exploration. The compact evidence still preserved the fields needed to identify `UPDATE dh_active_receive_logs ... WHERE id IN (...)`, 68,000 write keys, about 5.55-6.21 MB per transaction, and the relevant stage timings. The final evaluation rated the result `ai_better`. This verifies branch-local behavior only: the provider package and auto-oncall candidate are not published or effective, so the machine-readable status remains `candidate`. ## Unresolved gaps - The Wetech skill change is local and has not been published to the PVC-backed staging skill source. - Top 10 can omit a lower-ranked causal Digest; omission is unavailable evidence, not proof that the workload is absent. - A TiKV store does not identify the originating TiDB instance without a direct mapping. When TiDB-side metrics cannot select one instance, the workload-attribution gate must return a bounded failure rather than enumerate every TiDB. ## Next validation action Publish the reviewed Wetech skill to the PVC-backed staging source and make the candidate runtime available only in staging. Repeat the historical-cutoff replay through the rendered pod, confirm the same compact report/raw artifact separation and zero raw artifact reads in the live trace, and verify the stable Jira internal comment before promoting this problem beyond `candidate`.