# Wetech LLM Target Resolution

<!-- auto-oncall-optimization-record
{
  "schemaVersion": "auto-oncall-optimization-record-v1",
  "optimizationId": "wetech-llm-target-resolution-2026-08-13",
  "problems": [
    {
      "problemId": "wetech-ticket-target-spelling-rejected-before-readiness",
      "summary": "APID-29338 supplied a valid full Wetech cluster name, but deterministic alias lookup rejected it before readiness even though the same inventory entry already owned that known name.",
      "status": "optimized_verified",
      "applicability": "Wetech OP diagnostic routing when ticket text or a reply-safe image names a cluster using a canonical alias, business alias, Dashboard name, datasource name, or another semantically clear spelling represented by the current region-scoped inventory.",
      "issueKeys": ["APID-29338"],
      "sourceRefs": [
        "https://tidb.atlassian.net/browse/APID-29338#problem:wetech-target-semantic-resolution"
      ],
      "signalTextIncludesAny": [
        "unknown cluster alias: ali-sg-prod-saas-gosaas-region-tidb-v85-02",
        "diagnostic_wetech_readiness_failed",
        "valid full cluster name rejected before readiness"
      ],
      "observedThrough": "2026-08-13",
      "effectiveAt": "2026-08-13T03:14:00Z",
      "verifiedAt": "2026-08-13T03:32:56Z",
      "attemptedAction": "Give the Scenario Router a sanitized region-scoped Wetech candidate list, require it to return one canonical alias and region under explicit Aliyun Asia and Middle East rules, validate only exact inventory membership, and pass that pair unchanged to readiness.",
      "evidenceUrl": "https://github.com/tidbcloud/aisupport/tree/main/auto-oncall-services/docs/opts/2026-08-13-wetech-llm-target-resolution.md"
    }
  ]
}
-->

- Optimization ID: `wetech-llm-target-resolution-2026-08-13`
- Owner: Scenario Router and Wetech readiness boundary
- Source reference: `APID-29338`
- Implementation status: merged and deployed to staging
- Effective status: `optimized_verified`

## Bounded problem

Wetech target spellings have repeatedly been added to deterministic alias
tables one case at a time. APID-29338 supplied the valid full name
`ali-sg-prod-saas-gosaas-region-tidb-v85-02`, which already appeared as a known
name on the `asia-prod/SaaS02` inventory entry, but readiness accepted only the
canonical or explicitly configured aliases and stopped before Provider access.

## Candidate change

- Give the Scenario Router only sanitized target candidates: region, canonical
  alias, business aliases, and known full names.
- Default to Aliyun Asia; choose Middle East only from explicit user intent or
  a `gcp` full name, and choose Asia for an explicit `ali` full name.
- Resolve one uniquely clear candidate inside that region. Conflicts, large
  spelling differences, multiple plausible candidates, and cross-region
  fallback return no target.
- Let deterministic code validate exact `(region, canonical alias)` membership
  and pass the pair unchanged to the helper. Keep Grafana, Dashboard, and
  datasource transport configuration deterministic and outside Agent context.

## Verification evidence

Verified locally on 2026-08-13:

- `npm run typecheck` passed.
- `npm run build` passed.
- Focused diagnostic-scenarios, runner, and optimization-record tests passed,
  including the APID-29338 full-name-to-`asia-prod/SaaS02` regression, exact
  inventory membership, sanitized candidate input, and readiness target
  mismatch checks.
- The complete compiled test suite passed: 779 tests, 0 failures.

PR [#851](https://github.com/tidbcloud/aisupport/pull/851) was merged and the
change was present in staging image `fdd400505de3f656c28682b1d986cd2922cda174`.
The later staging image `f7555f3112be796010b49a56e0891e6e9b9c4e4c`
contains that commit as an ancestor.

Post-deployment APID-29338 read replay
`99ffc488-7299-4852-9a66-f58d2f67f283` completed with HTTP 200. The Scenario
Router resolved the full Aliyun name to `asia-prod/SaaS02`; Wetech readiness
passed, `evidenceAcquisition` and `responseGeneration` were both `complete`,
the provider reported no failure codes, and the evaluation verdict was
`ai_better`.

Write replay `ee8aaad0-cb44-43f7-a160-3e473e069149` again resolved
`asia-prod/SaaS02`, completed Wetech evidence and response generation without
provider failure codes, persisted run `150017`, and received an `ai_better`
evaluation. Its normal Jira update failed because the persisted comment mapping
contained nonexistent id `23547324.0`. A bounded direct recovery identified the
existing auto-oncall comment `23543864`, verified it was authored by TiDB
Support Assistant and `public=false`, updated that exact comment with the
verified replay body, then read it back with `public=false` and an exact ADF
body match. No duplicate or customer-visible comment was created.

## Unresolved gaps

The target-resolution problem is verified, but two separate signals remain
eligible for later work: the stale/nonexistent persisted Jira comment mapping,
and the different metric semantics selected across otherwise successful read
and write replays. Neither is part of this target-resolution criterion.

## Next validation action

Investigate the persisted Jira comment mapping independently before another
write replay, without reopening the verified target-resolution problem.