# Internal Handoff Ticket Language

<!-- auto-oncall-optimization-record
{
  "schemaVersion": "auto-oncall-optimization-record-v1",
  "optimizationId": "internal-handoff-ticket-language-2026-08-13",
  "problems": [
    {
      "problemId": "internal-handoff-language-diverges-from-ticket",
      "summary": "Chinese tickets produced a Chinese customer message but an English internal handoff because the shared language contract applied only to customerReplyMarkdown.",
      "status": "optimized_verified",
      "applicability": "Paired customer and internal messages produced by direct analysis, continuation, and the diagnostic Router plus Final Response path.",
      "issueKeys": ["APID-29338", "ST-2891"],
      "sourceRefs": [
        "https://tidb.atlassian.net/browse/APID-29338#problem:internal-handoff-language-diverges-from-ticket",
        "https://tidb.atlassian.net/browse/ST-2891#problem:internal-handoff-language-diverges-from-ticket"
      ],
      "signalTextIncludesAny": [
        "chinese customer reply with english internal handoff",
        "internal handoff does not follow ticket language"
      ],
      "observedThrough": "2026-08-13",
      "effectiveAt": "2026-08-13T05:05:01Z",
      "verifiedAt": "2026-08-13T05:15:09Z",
      "attemptedAction": "Select one language from the latest substantive customer question and require both response fields to use it while preserving technical literals.",
      "evidenceUrl": "https://tidb.atlassian.net/browse/APID-29338"
    }
  ]
}
-->

- Optimization ID: `internal-handoff-ticket-language-2026-08-13`
- Owner: paired response presentation
- Source references: `APID-29338`, `ST-2891`
- Implementation status: merged and deployed to staging
- Effective status: `optimized_verified`

## Bounded problem

The response language rule selected Chinese or English only for the customer
message. The diagnostic Final Response prompt then explicitly applied that rule
only to `customerReplyMarkdown`, allowing a Chinese ticket to retain an English
`internalHandoffMarkdown`.

## Implemented change

Select one ticket language from the latest substantive customer question and
apply it to both messages in direct, continuation, Router, and Final Response
paths. Product names, identifiers, SQL, commands, and field names remain
unchanged.

## Verification status

Source PR `tidbcloud/aisupport#865` passed CI and merged as
`5caaa255c338e8cbc3cdd2c945bed9e1b2b62ff3`. Deployment workflow
`31668862599` built that image, and app-delivery PR
`tidbcloud/app-delivery#77144` updated the staging tag. The live Deployment
reported that exact image with one Ready Pod and zero restarts; `/healthz` and
`/readyz` both returned HTTP 200.

Two post-change `mode=read` replays verified the paired language without any
Jira, DB, evaluation, or Feishu write:

- ST-2891 run `1e732945-4283-4ff2-b761-ac7fc945dbb4` returned Chinese customer
  and internal messages.
- APID-29338 run `6e2c48d0-eb08-40b3-bb8f-03c0eb153eba` returned Chinese
  customer and internal messages through the diagnostic Router plus Final
  Response path.

## Next validation action

Keep the shared-language contract tests as preservation checks. No write replay
or Jira comment refresh is required for this presentation-only verification.