# Wetech Query Key And Batch Capacity - Optimization ID: `wetech-query-batch-capacity-2026-08-10` - Owner: auto-oncall-services runner and Wetech provider helper - Source reference: Focus #606 replay evidence for `APID-29265` and `APID-29232` - Implementation status: merged and deployed to staging - Effective status: `optimized_unverified` ## Bounded problem `queryId` is consumed as an artifact-directory key, a uniqueness key, and a same-batch dependency reference. Those uses require a bounded safe slug and uniqueness; they do not require a fixed diagnostic vocabulary. The temporary seven-value allowlist fixed one incompatible acquisition plan, but it also prevented the child from naming several concrete metrics or alternatives in a single batch. The same path capped every Wetech batch at six serial queries. Recent successful replays used five queries per round, while another already-known alignment or alternative check could require a complete later acquisition round. That round adds agent planning and parent-judgment latency in addition to provider query time. This record owns only Wetech query-key semantics, Wetech batch capacity, and the directly corresponding handoff/coverage capacity. It does not change the four-round quota, Clinic or Manus limits, provider authentication, query concurrency, per-query timeout, scenario finalization, Jira publication, Judge, attachments, required capabilities, or Focus lifecycle. ## Candidate change - Accept a unique query ID matching `^[a-z][a-z0-9]*(?:-[a-z0-9]+)*$`, with at most 64 characters. - Resolve `windowFromQueryId` and `instanceFromQueryId` against an earlier result in the same serial batch instead of a fixed semantic allowlist. - Raise only Wetech's batch ceiling from 6 to 12 and preserve all twelve compact observations, query-coverage entries, and artifact refs for the parent. - Keep queries strictly serial and tell acquisition that twelve is a capacity ceiling, not a target; low-value queries must not be added to fill it. - Leave Manus and Clinic at six queries and leave the four-round quota intact. ## Verification evidence Local contract tests cover twelve safe unique query IDs, arbitrary same-batch dependency IDs, all twelve facts reaching the parent, unsafe IDs being rejected, and the Manus limit remaining six. The complete TypeScript suite passes with 699 tests, and the Wetech helper suite passes with 52 tests both locally and in the staging publisher Pod. The helper was published to the staging skill PVC with SHA-256 `fbf6e0175abd5d1bc020260274bcdb9113609bb2205877b412b6b1e8c174bfa2`. The source mount and installed runtime copy have the same hash; runtime import reports `OP_BATCH_MAX_QUERIES=12` and no fixed `OP_BATCH_QUERY_IDS` allowlist. The prior skill directory remains backed up on the PVC. [aisupport PR 704](https://github.com/tidbcloud/aisupport/pull/704) and its CI merged the runner change. [Deployment run 31356124392](https://github.com/tidbcloud/aisupport/actions/runs/31356124392) built image `47fa5ae6136f616dbd77cbf1922e27b31492ba89`, and [app-delivery PR 76639](https://github.com/tidbcloud/app-delivery/pull/76639) merged the staging bump. The live Deployment and optimizer CronJob use that image. The Deployment is 1/1 updated, ready, and available; its Pod is Ready with zero restarts, `/readyz` returns HTTP 200, and runtime import reports four rounds, twelve Wetech queries per batch, and the safe-slug query-ID pattern. These checks prove that the new contract is effective in staging. They do not by themselves prove that a real acquisition will use the capacity correctly. Two post-change read-only replays then exercised that runtime criterion: - `APID-29265` run `e7d5e2c6-7a9e-40ac-b5e3-fdaea6f34be7` completed with verified Wetech capability in one round. Its single batch selected eleven concrete query IDs, completed nine and returned two empty results, and spent 62,221 ms in provider execution. The complete request returned HTTP 200 in 370.9 seconds without a finalization-budget failure. - `APID-29232` run `a2a104ba-bd4a-45e7-946a-82b04544561a` completed with verified Wetech capability in one round, down from the prior two-round replay. Its single batch selected ten concrete query IDs, completed eight and returned two empty results, and spent 72,239 ms in provider execution. The complete request returned HTTP 200 in 403.8 seconds. - Both requests used `mode=read`; publication, database, evaluation, Feishu, and Jira writes were `not_requested`. No customer-visible or internal Jira comment was changed. These replays prove that the larger capacity is usable, does not force twelve queries, preserves successful and empty coverage, and can eliminate a later refinement round. Because the resulting case drafts have not been refreshed into their existing Jira internal comments and read back with `public=false`, the problem remains `optimized_unverified` under the case-refresh contract. ## Unresolved gaps - A larger batch reduces extra agent rounds only when more than six queries are already known to be load-bearing before execution. - Wetech queries remain serial. Twelve slow provider calls can still consume the scenario budget, so the acquisition prompt must select only necessary checks. - This change does not reduce authentication or agent planning latency and does not add timeout or retry machinery. - Jira internal-comment refresh and readback remain unresolved for both replay cases. ## Next validation action With explicit Jira-write authorization, update each existing auto-oncall Jira internal comment in place from its successful replay draft, then read back the exact comment ID and verify `public=false`. Promote this problem to `optimized_verified` only after both comment refreshes succeed.