# Bounded Diagnostic Multiturn - Optimization ID: `bounded-diagnostic-multiturn-2026-07-25` - Owner: auto-oncall-services - Source reference: `APID-29194` - Implementation status: deployed and enabled in staging - Effective status: `optimized_verified` ## Bounded problem A first diagnostic turn may leave one or two causal gaps that the already selected read-only provider can resolve. The current runtime cannot perform one bounded evidence turn and then synthesize without collecting more evidence, replaying a very large evidence transcript, or allowing independent stage timeouts to exceed the worker's safe duration. ## Verification evidence The pre-implementation controlled experiment showed that a timed-out evidence turn could still leave useful same-thread context for a later no-tool synthesis. It informed the contract but is not post-change verification. The candidate requires contract tests for eligibility, structured gaps, information-gain selection, shared absolute budgets, compact synthesis, timeout continuation, no-tool auditing, monotonic safety, traceable failures, normalization fallback, and publication safety. Repository test results belong to the implementation commit and do not promote this problem beyond `candidate`. Two branch-local, historical-cutoff forward replays ran on 2026-07-27 without reading the target support reply or later comments: - The first completed in 9m49s after a Wetech P81/Grafana session-readiness wait consumed about five minutes and returned no provider evidence. This established the need for the 60-second authenticated transport preflight and bounded polling rule. - After restoring the skill-managed browser session, the second collected provider evidence in a 12m09s initial turn and stopped after 12m28s total, below both the 13.5-minute allocated initial budget and the 22-minute pipeline deadline. It narrowed the mechanism to aligned Commit/Prewrite latency and CPU, rejected scheduler latch and MVCC scan amplification by magnitude, and preserved the missing reward-DML/transaction mapping. The run then failed on a structured-output mismatch: `required=false` accompanied one customer-resolvable causal gap. The parser now drops such non-internal gaps, and a regression test covers that exact output shape. No third provider replay was run after the parser fix. - A separate blind `APID-29231` control replay completed in 14m03s and retained the prior time/entity causal-alignment behavior: Commit, `kv_commit`, and scheduler command latency aligned on the same TiKV instance and interval, while latch and Raft magnitudes were rejected as the immediate explanation. It used 18 actual metric queries and about 3.48 MB of evidence. That result motivated active-type-first metric discovery and an earlier stop once the aligned scheduler boundary explains the result. - A later compact-provider `APID-29194` replay, run `8ffc7354-5bfa-46d5-b400-e25614f4b252`, reached the 13.5-minute initial-turn deadline and was aborted after 13m51s of Codex execution, 14m09s for the complete replay command. It produced no accepted initial result, so the gap and synthesis stages did not run. The trace and rollout show that the first window had already resolved both required gates at about 12m36s: `prev_stmt` mapped slow COMMIT rows to large `UPDATE dh_active_receive_logs ... WHERE id IN (...)` transactions with 68,000 write keys, about 5.55-6.21 MB per transaction, and 0.30-0.65s commit latency. Before that result, the initial turn ran four separate broad Statements searches for `INSERT`, `UPDATE`, `DELETE`, and `REPLACE`. After resolving the first-window gates, it still started an exact lookup in the second customer incident window and exhausted the deadline there. This replay directly motivated the initial-turn boundary now in the OP prompt and write-path SOP: no four-verb broad Statements sweep, one exact post-TopSQL originating-DML drilldown, no generic COMMIT-first exact lookup, and no second-window query outside the backend gap round. The run created no Jira, database, deployment, evaluation, or customer-visible side effect. - The subsequent historical-cutoff replay `c8f42913-d4c0-4535-8edd-0f2d8dd37e0e` returned HTTP 200 in 609.27 seconds and passed the branch-local acceptance criterion for this bounded problem. The initial turn succeeded in 7m52s using only the first customer incident window. It mapped slow COMMIT rows to `UPDATE dh_active_receive_logs ... WHERE id IN (...)` transactions with 68,000 write keys and about 5.62-6.22 MB per transaction. It emitted one load-bearing gap for recurrence in the second window. The evidence turn made one bounded second-window Slow Query lookup, found the same Digest and transaction shape, and resolved the gap. Compact fresh-thread synthesis then completed without tools and retained `human_required`: the two windows support the same large-batch write-path mechanism, but the available evidence still does not directly map the TiDB request to the hot TiKV path or prove exact peak alignment. The replay made zero broad Statements searches, zero second-window queries in the initial turn, and zero raw provider-artifact reads. It created no Jira, database, deployment, evaluation, or customer-visible side effect. - Later read-only replay `f79d1126-2a24-46ea-b1d8-f0a0a949a735` returned HTTP 200 in 353.271 seconds after the first incident window established the originating UPDATE, 68,000-key transaction shape, leading mechanism, safety decision, and recommendation. The initial stage completed in 302,715 ms, returned `diagnosticFollowup.required=false`, and correctly skipped both the gap and synthesis stages; normalization completed in 14,981 ms. The accepted result used five bounded replay-context sections and was rated `ai_better`. This is positive branch-local evidence that the pipeline does not force a second turn when no load-bearing gap remains. Post-deployment write replay `affdf41b-faf3-472e-8dec-fd2f04ae7670` completed through the effective staging runtime and updated the stable Jira internal comment `23202442`. The result identified the large-batch `UPDATE dh_active_receive_logs ... WHERE id IN (...)` transaction shape, quantified the 68,000-key and 5.55-6.21 MB samples, retained safe gray-release guidance, and was judged `ai_better`. No load-bearing follow-up remained, so the runtime correctly stopped after the sufficient initial diagnosis instead of forcing another turn. The Jira comment was read back by ID after the write. This verifies the selected `diagnostic-first-turn-leaves-load-bearing-causal-gaps` problem signal only. It does not prove every diagnosis gap in `APID-29194` is resolved. ## Unresolved gaps - Production remains disabled; this record verifies the staging auto-oncall runtime only. - Provider-call counting is observable only after SDK items arrive; there is no reliable hard provider-call budget inside one provider command. The shared deadline, summary-first SOP, one-refinement rule, and stop conditions remain the current hard and behavioral bounds. - The diagnostic deadline starts when the worker claims an initial job and becomes active only after that live-initial scenario is confirmed eligible for diagnostic multiturn. Continuations and ineligible scenarios retain the legacy path. The same abort signal is checked around analysis, validation, and Jira publication. Some Jira/provider/materialization clients do not accept an AbortSignal, so an already in-flight request cannot yet be forcibly cancelled; the deadline is enforced at the next boundary. This is not a complete wall-clock hard cap for those residual calls. ## Next validation action Keep the bounded stage summaries and stop conditions in regression coverage. If a newer case shows that a resolvable load-bearing gap was left open, select that new problem ref without reopening this verified historical signal.