# Wetech OP Batch Target Normalization

<!-- auto-oncall-optimization-record
{
  "schemaVersion": "auto-oncall-optimization-record-v1",
  "optimizationId": "wetech-op-batch-target-normalization-2026-08-05",
  "problems": [
    {
      "problemId": "wetech-op-batch-drops-runner-target-reference",
      "summary": "The evidence child preserves the exact Wetech target as a top-level targetReference, but the provider helper reads only a nested target object and rejects the whole batch before any query runs.",
      "status": "optimized_verified",
      "issueKeys": ["APID-29231"],
      "sourceRefs": [
        "https://tidb.atlassian.net/browse/APID-29231#problem:wetech-op-batch-target-reference"
      ],
      "signalTextIncludesAny": [
        "op_batch_target_invalid",
        "Wetech OP batch requires an exact cluster target",
        "targetReference"
      ],
      "observedThrough": "2026-08-05",
      "effectiveAt": "2026-08-05T16:40:57Z",
      "verifiedAt": "2026-08-05T16:50:55Z",
      "attemptedAction": "Normalize the exact Wetech cluster and region from the runner-owned auth targetReference, top-level or nested plan target, and compatible query fields inside the deterministic batch helper; also normalize agent-facing operation aliases before execution.",
      "evidenceUrl": "https://tidb.atlassian.net/browse/APID-29231#comment-23279460"
    }
  ]
}
-->

- Optimization ID: `wetech-op-batch-target-normalization-2026-08-05`
- Owner: auto-oncall-services and wetech-op-grafana
- Source reference: `APID-29231` replay
- Implementation status: deployed to staging and verified by same-cutoff replay
- Effective status: `optimized_verified`

## Bounded problem

Replay `c04b9047-6bc9-4b7d-81c4-fde67e1f6792` wrote an exact top-level
`targetReference` for `SaaS02` in `asia-prod`, but the Wetech helper inspected
only `plan.target`. It returned `op_batch_target_invalid` before provider
access. The same agent plan also used the semantic operations `metric` and
`slow-query`, while the helper accepted only the underlying CLI command names.

## Candidate implementation

- Bind the helper to the runner-owned `auth.targetReference`, with compatible
  top-level, nested-plan, and query target forms normalized at one boundary.
- Normalize `metric`, `slow-query`, `statements`, and `topsql` to the concrete
  provider commands before validation.
- Keep execution target-stable and serial; do not add a discovery call or a
  second agent planning turn.

## Verification

- Wetech helper contract tests pass 51/51.
- Auto-oncall full tests pass 648/648.
- A full batch fixture matching the failed replay's top-level target and
  semantic operation format resolves `SaaS02`/`asia-prod` and executes the
  metric followed by dependent TopSQL.
- Same-cutoff replay `a546140e-6d6b-44b8-b47a-778f8a50f5af` accepted
  `wetech:asia-prod:SaaS02:datasource=wQrYqYMvk`, normalized the semantic
  operations, and ran all five provider queries. The serial batch completed in
  72.156 seconds with status `complete`; `op_batch_target_invalid` did not
  recur.
- The replay completed with HTTP 200 and DB run id `120025`. It updated the
  existing Jira internal comment `23279460`; direct readback returned
  `public=false`.

## Unresolved gaps

- No unresolved gap remains for target or operation normalization. The replay's
  later `human_required` decision concerns a separate workload-identity and
  causality boundary, not provider target resolution.

## Next validation action

Monitor later Wetech provider batches for `op_batch_target_invalid`. A new
failure with an exact runner-owned target is regression evidence for this
problem.