# OP Serial Evidence Batch - Optimization ID: `op-serial-evidence-batch-2026-08-05` - Owner: auto-oncall-services with Wetech provider skill handoff - Source reference: `APID-29231` replay `de874fd8-c11c-416f-8b85-f57d59996f02` - Implementation status: merged and deployed to staging in `58de9bd`, with runtime prompt alignment in `9d99eb4` and Manus plan compatibility in `39ba8da` - Effective status: `optimized_verified` for the bounded repeated-turn problem ## Bounded problem The `APID-29231` Wetech scenario consumed 584 seconds. About 65 seconds passed before the evidence child started, the child spent about 465 seconds loading diagnosis context and alternating provider calls with compact-report and handoff rewrites, and the parent spent about 54 seconds after the final handoff. Individual provider operations completed in bounded intervals; no single Wetech query consumed the scenario duration. The same responsibility split and concurrency policy must apply to both OP providers. OP queries are not safe to parallelize merely because they are read-only: Wetech uses shared browser/session state, while either provider can put avoidable load on Grafana, Prometheus, or TiDB Dashboard. ## Implemented change - The scenario parent loads `op-diagnosis`, the scenario contract, and exactly one selected scenario reference. It never loads or invokes a provider skill. - The evidence child loads exactly `wetech-op-grafana` or `manus-op-grafana`. It does not load diagnosis, schema, validator, runner, or test instructions. - The child writes one bounded provider plan and invokes one `batch` command. Wetech and Manus helpers execute the selected queries strictly serially. - A dependent Wetech TopSQL query may declare the preceding metric query that supplies its exact instance. The helper resolves that dependency after the metric finishes without returning control to the agent. - Provider helpers atomically preserve partial results after each completed query. The auto-oncall runner deterministically creates compact reports and `auto-oncall-diagnostic-child-evidence-v2`; neither agent patches those schemas. - Manus scenario threads and same-account runs are serialized as well as Wetech work. ## Local verification - TypeScript contract tests cover parent/child skill isolation, one helper call, serial OP policy, Manus scenario serialization, runner-owned context, batch validation, and deterministic handoff materialization. - Manus provider tests cover one strictly serial batch call and historical window enforcement. - Wetech provider tests cover strictly ordered metric and TopSQL execution, deterministic instance dependency resolution, and historical window enforcement. - The service test suite passes 635 tests, the Manus helper passes 24 tests, and the Wetech helper passes 46 tests. ## Staging verification - `APID-29231` replay `21c8e176-5638-43c8-84b4-4dec86c2ab3d` completed through the deployed serial batch path. The diagnostic scenario fell from 584.107 seconds to 468.670 seconds, a 115.437-second or 19.8% reduction. - The provider helper executed one six-operation batch strictly serially in 185.488 seconds. Four operations completed; TopSQL and one Grafana metric operation failed within their bounded timeouts, and their partial results were preserved for parent judgment. - The parent loaded only the diagnosis skill and scenario references. The provider child owned the Wetech query skill, and the runner materialized the compact report and handoff from the batch result. - Jira internal comment `23279460` was updated in place and read back with `public=false`. The replay did not create a duplicate or customer-visible comment. ## Unresolved gaps - End-to-end latency only fell from about 774 seconds to 741.321 seconds. The verified optimization removed repeated provider-query agent turns, but did not address the 119.403-second auth bootstrap, roughly 206 seconds of scenario plan preparation, 185.488 seconds of real serial provider work, parent finalization, synthesis, evaluation, or publication. - The failed TopSQL and Grafana metric operations consumed 131.313 seconds of the provider batch. Serial execution is intentional, so a later optimization must bound or avoid non-load-bearing queries rather than run them in parallel. - Manus batch compatibility is implemented, deployed, and locally tested, but it is not live-replay verified. Per operator direction, no Manus replay was run while its provider path is currently unusable. ## Next validation action Treat deterministic Wetech auth bootstrap, compact recipe-based query planning, and tighter failure budgets for non-load-bearing serial operations as separate candidate problems. Do not replay Manus until its provider path is usable or an operator explicitly requests that validation.