# Image-Derived Wetech Target Routing

<!-- auto-oncall-optimization-record
{
  "schemaVersion": "auto-oncall-optimization-record-v1",
  "optimizationId": "image-derived-wetech-target-2026-08-11",
  "problems": [
    {
      "problemId": "wetech-router-could-not-see-image-target",
      "summary": "Reply-safe ticket images were visible to the general analysis agent but not to the Scenario Router, so an explicit dashboard cluster name could not become the exact Wetech route target.",
      "status": "optimized_unverified",
      "issueKeys": ["APID-29296"],
      "sourceRefs": ["https://tidb.atlassian.net/browse/APID-29296#problem:wetech-router-could-not-see-image-target"],
      "signalTextIncludesAny": ["diagnostic_wetech_target_missing", "op_batch_target_invalid", "cluster target visible in screenshot"],
      "observedThrough": "2026-08-11",
      "effectiveAt": "2026-08-11T05:47:29Z",
      "verifiedAt": null,
      "attemptedAction": "Supply already materialized reply-safe images directly to the Wetech Scenario Router, admit only one unambiguous visible cluster target, and allow an exact configured dashboard cluster name to resolve its canonical Wetech alias and region before deterministic readiness validation.",
      "evidenceUrl": "https://github.com/tidbcloud/aisupport/tree/main/auto-oncall-services/docs/opts/2026-08-11-image-derived-wetech-target.md"
    }
  ]
}
-->

- Optimization ID: `image-derived-wetech-target-2026-08-11`
- Owner: auto-oncall-services
- Source: APID-29296 replay `5fec418f-1e22-4a87-9e07-20d12c066c13`
- Implementation status: deployed to staging, case route verified

## Bounded problem

The general ticket Agent received local images, but the routing-only Scenario
Router received text JSON only. APID-29296 therefore routed with `entity=null`
even though its dashboard screenshot visibly contained the exact Wetech cluster
name, and provider execution stopped before metrics or TopSQL.

## Attempted change

For Wetech routes only, pass the same reply-safe, cutoff-filtered local images to
the Scenario Router. It may set `anchor.entity` only from exactly one explicit,
unambiguous visible cluster name or alias. It cannot search clusters, override an
explicit textual target, or cross the selected Wetech account; deterministic
readiness still validates the exact target before queries.

When a dashboard shows the full cluster name rather than the internal Wetech
alias, readiness may resolve that name only through a unique exact
`dashboard_cluster_name` entry. It then uses that entry's canonical alias and
region; ambiguous or absent mappings fail closed.

## Verification status

Unit coverage verifies Wetech Router image delivery, non-Wetech exclusion, the
unambiguous-target/fail-closed prompt contract, and exact dashboard-name mapping.
Temporary-pod replay `87f32f09-75ce-43dc-a84b-2af1192386d9` recognized
`gcp-fra-prod-saas-gosaas-region-tidb`, mapped it to canonical alias `SaaS` and
region `middle-east-prod`, passed readiness, queried the exact Prometheus
datasource, and produced a metric-backed answer. This was the pre-deployment
runtime proof.

Staging image `6fcd789dfe896594b405cfdb0b8df7fc50a47fc3` then ran
APID-29296 as read-only replay `34eff525-726b-4f5f-b0b0-c9c6325a6d6b`.
The Scenario Router read the supplied image and selected
`gcp-fra-prod-saas-gosaas-region-tidb`; deterministic readiness mapped it to
`wetech:middle-east-prod:SaaS` in 28 seconds, and both scenarios completed their
Prometheus queries against that target. The final answer remained
`human_required` because the first Dashboard operation failed and workload
identity stayed unresolved. No Jira, DB, or Feishu write occurred.

## Unresolved gaps

The route and provider target are verified, but the diagnosis-quality change is
not complete until a replay obtains the required Dashboard workload evidence
and the existing Jira internal comment is refreshed. If vision returns zero or
multiple candidates, the case intentionally remains `human_required`.

## Next validation action

Repair or restore the Wetech Dashboard session, rerun APID-29296, and refresh
the existing Jira internal comment before promoting this problem to
`optimized_verified`.