# Wetech Runner-Owned Acquisition - Optimization ID: `wetech-runner-owned-acquisition-2026-08-10` - Owner: auto-oncall-services runner - Source reference: Focus #606 replay evidence for `APID-29265` and `APID-29232` - Implementation status: runner-owned acquisition and query-ID contract correction deployed to staging - Effective status: `optimized_unverified` ## Bounded problem The existing Wetech scenario prompt assigns the scenario parent responsibility for starting an evidence child. Recent same-cutoff replays show that this instruction is not a runtime guarantee: a parent can consume the scenario budget without starting the child, so no Wetech batch exists and provider capability remains unverified. Moving or strengthening the same parent prompt did not exercise the intended mechanism consistently. This problem is only ownership and ordering of Wetech evidence acquisition. It does not change Wetech authentication, query recipes, TopSQL semantics, batch helper behavior, attachment handling, Judge interpretation, required capability semantics, or Focus lifecycle. ## Candidate change - The runner starts a dedicated Wetech acquisition thread before scenario judgment. The acquisition thread loads only the Wetech provider skill and cannot delegate provider work to another child. - Runner-owned context fixes the exact provider target, scenario ID, and historical time window. The acquisition thread cannot search for another target or fall back to another provider. - One acquisition round submits exactly one bounded batch plan. The existing Wetech helper remains the owner of strict serial execution and bounded retry; the runner remains the owner of deterministic compact-report and handoff materialization. - Only after the runner validates the batch and handoff does it start a fresh, tool-free and network-disabled scenario judgment thread. - An adaptive evidence request starts another runner-owned acquisition round with the prior compact handoff, one exact refinement question, and its stop condition. It does not return provider control to the scenario parent. - A missing initial batch fails with `diagnostic_wetech_batch_missing_after_acquisition`; scenario prose cannot substitute for the artifact. ## Local verification - Contract tests verify the exact target and window, one helper call, strict serial execution, no provider fallback, no child delegation, and the narrow acquisition acknowledgement. - Runner tests verify acquisition occurs before a tool-free scenario judgment, the validated runner-owned handoff is the only provider input to judgment, and a missing batch prevents judgment and returns the exact failure code. - TypeScript typecheck and targeted diagnostic scenario, OP evidence, and runner tests pass locally. The complete suite passes with 690 tests. Local tests prove the ownership and query-ID contracts only; they do not prove successful live Wetech acquisition. ## Staging verification - The staging workload became Ready at `2026-08-10T02:22:27Z` with a current image that contains the runner-owned acquisition change. - A read-only `APID-29265` replay created run `99e17816-6f85-4690-8c56-2b79d05e9877`. Its trace proves the runner started the dedicated Wetech acquisition before scenario judgment with the exact target and historical window. - That acquisition did not produce a valid batch: the plan invented metric-specific query IDs, while the helper accepts only the shared semantic query IDs. The run ended with `diagnostic_wetech_batch_missing_after_acquisition`; no Jira write was made. - The follow-up contract correction explicitly supplies the helper-supported query-ID set and forbids invented metric-specific IDs. - The corrected staging image was deployed through [aisupport run 31350202911](https://github.com/tidbcloud/aisupport/actions/runs/31350202911) and [app-delivery PR 76590](https://github.com/tidbcloud/app-delivery/pull/76590). The live Deployment and optimizer CronJob both resolved to an image containing commit `b151e2024eeff2d74c6e827ab00a57b3d0abf9ad`; the Pod was Ready with zero restarts and `/readyz` returned HTTP 200. - Corrected read-only replay `APID-29265` run `8a81cf79-d741-4fd1-ae11-efdac4a34bfb` exercised three runner-owned Wetech acquisition rounds and materialized batch and handoff artifacts. It still ended with `diagnostic_wetech_parent_finalization_budget_exhausted`, so the case outcome was not corrected and Jira was not updated. - Corrected read-only replay `APID-29232` run `1e390c28-6ac2-4ef8-8029-da1d5a6ce9ae` exercised three runner-owned Wetech acquisition rounds and materialized batch and handoff artifacts. It still ended with `diagnostic_evidence_refinement_not_required_invalid`, so the case outcome was not corrected and Jira was not updated. - These replays verify a clear improvement from “no provider acquisition” to repeated, valid runner-owned acquisition. They do not satisfy case-level verification, so the problem remains `optimized_unverified`. ## Unresolved gaps - This candidate does not reduce Wetech auth or query latency and does not alter helper-side query selection or TopSQL target resolution. - Both replays exposed a separate downstream boundary: the child handoff did not give the judgment enough factual metric summaries, causing unnecessary refinement rounds and either finalization-budget exhaustion or an invalid terminal refinement object. That problem should be handled as a separate bounded Focus rather than added to this acquisition-ownership optimization. - It does not decide how Judge should interpret missing provider capability or `requiredCapabilities`; that is a separate problem. - It does not handle attachment availability and does not change Focus selection, attempt retirement, or lifecycle policy. ## Next validation action Open a separate bounded Focus for factual handoff materialization and terminal refinement/finalization behavior. After that independent problem is fixed, replay `APID-29265` and `APID-29232` with their applicable historical cutoffs. Only when both return the corrected case outcome should the existing auto-oncall Jira internal comments be updated in place using their stable idempotency mappings and read back with `public=false`; only then may this problem become `optimized_verified`.