# Router Fallback Clinic Handoff

<!-- auto-oncall-optimization-record
{
  "schemaVersion": "auto-oncall-optimization-record-v1",
  "optimizationId": "router-fallback-clinic-handoff-2026-08-28",
  "problems": [
    {
      "problemId": "router-fallback-clinic-handoff-not-actionable",
      "summary": "When Clinic target resolution and Router reconciliation both failed, the deterministic fallback used a generic mixed-language response instead of one customer-safe progress update and one target-only Support action.",
      "status": "optimized_unverified",
      "applicability": "Diagnostic runs where the Clinic target cannot be resolved and Router reconciliation cannot produce the canonical response pair.",
      "issueKeys": ["ST-2922"],
      "sourceRefs": ["https://tidb.atlassian.net/browse/ST-2922#problem:router-fallback-clinic-handoff-not-actionable"],
      "signalTextIncludesAny": [
        "diagnostic_clinic_target_missing",
        "diagnostic_router_reconciliation_failed"
      ],
      "observedThrough": "2026-08-28",
      "effectiveAt": "2026-08-28T09:22:01Z",
      "verifiedAt": null,
      "attemptedAction": "Render the target-only fallback in the ticket language, keep the internal target-mapping failure out of the customer message, and tell Support only to confirm the actual cluster and invoke a new analysis with a real Jira ADF Auto Oncall mention.",
      "evidenceUrl": "https://github.com/tidbcloud/aisupport/pull/1144"
    }
  ]
}
-->

- Owner: `boundedDiagnosticRouterFallback`
- Source: ST-2922 single-ticket finding `st-2922-router-fallback-handoff`
- Implementation status: merged in `tidbcloud/aisupport#1144`
- Effective status: `optimized_unverified`

## Bounded problem

The target-resolution packet correctly retained that Clinic evidence was not
acquired, but the Router reconciliation fallback described the next step as
generic human synthesis and incorrectly warned against rerunning a successful
acquisition. Support received no executable continuation step.

## Intended change

For this exact fallback combination, preserve `human_required` and render both
messages in the ticket language. The customer message states only that Support
will continue its internal check. The internal-only message contains the one
target-resolution action: confirm the actual cluster, then trigger a new
analysis with a real Jira ADF `@Auto Oncall` mention and the cluster name. Other
Router fallbacks are unchanged.

## Verification

A deterministic Chinese runner regression test forces an unresolved Clinic
target and a Router reconciliation timeout. It verifies the typed decision,
paired language and customer boundary, the compact internal continuation
action, and absence of the machine failure code, a false successful-acquisition
description, and an unnecessary escalation tree.

The full TypeScript suite passed with 1,010 tests. PR #1144 merged as
`bbfe8d1fb63e5b7bd0d68feb39d87e9d5aae8556`; app-delivery PR #78658 then
deployed that exact image. The live Deployment reached 1/1 Ready with zero
restarts, and both `/healthz` and `/readyz` returned `ok`.

The post-deployment current-ticket read replay
`9576e101-ac2e-4344-94c8-707cebe4ed20` completed through the newer
direct-artifact path. A first write attempt
`475baae7-0c65-4e2a-903e-ee5c6f1888fe` failed in the Agent9 turn before any
Jira or database write. After confirming that the stable comment and database
were unchanged, the one retry `cd68a5d6-8232-4139-a905-dec89068fe08` succeeded
as database run 150150. It updated the existing Jira internal comment
23731369; readback confirmed `public=false`, the new bounded execution-plan
analysis, and removal of the old failure-code fallback text.

## Unresolved gaps

The Jira organization attached to ST-2922 currently exposes only US-region
Clinic targets while the ticket names `gosaas 亚太02`. The target-resolution
failure is therefore the correct same-org safety result and is not changed by
this optimization. The current Jira snapshot now includes an execution-plan
attachment, so both deployed replays selected direct-artifact completion and
did not exercise the repaired target-missing plus Router-failure fallback.
Deployment and current-case refresh therefore establish effectiveness but not
the exact fallback criterion; the problem remains `optimized_unverified`.

## Next validation action

Replay the historical pre-attachment ST-2922 input, or an equivalent deployed
runtime case that reaches both Clinic target missing and Router reconciliation
failure. Verify the paired target-only fallback before promoting this problem
to `optimized_verified`.
