# Internal Only Support-readable Work Note

<!-- auto-oncall-optimization-record
{
  "schemaVersion": "auto-oncall-optimization-record-v1",
  "optimizationId": "internal-only-support-readable-work-note-2026-08-13",
  "problems": [
    {
      "problemId": "internal-only-exposes-machine-state-instead-of-support-work",
      "summary": "The APID-29340 Internal Only message transcribed runner and Provider state such as null entities, internal error codes, bounded-failure labels, canonical target aliases, and routing mechanics, so Support could not tell what technical evidence was missing or what work to perform next.",
      "status": "optimized_verified",
      "applicability": "Diagnostic response pairs whose internal acquisition is failed, degraded, empty, or blocked and whose Internal Only message must guide Support follow-up.",
      "issueKeys": ["APID-29340"],
      "sourceRefs": [
        "https://tidb.atlassian.net/browse/APID-29340#problem:internal-only-machine-state"
      ],
      "signalTextIncludesAny": [
        "entity=null",
        "op_batch_target_invalid",
        "Provider bounded failure",
        "canonical target",
        "support cannot understand internal only"
      ],
      "observedThrough": "2026-08-13",
      "effectiveAt": "2026-08-13T07:25:00Z",
      "verifiedAt": "2026-08-13T07:32:00Z",
      "attemptedAction": "Make Scenario Router and especially Final Response translate machine state into a Support-facing technical work note containing the affected target/window, missing evidence, blocked customer decision, concrete next diagnostic action, and human-facing escalation condition, with localized concise headings.",
      "evidenceUrl": "https://tidb.atlassian.net/browse/APID-29340"
    }
  ]
}
-->

- Optimization ID: `internal-only-support-readable-work-note-2026-08-13`
- Owner: Scenario Router and Final Response audience projection
- Source reference: `APID-29340`, internal comment `23548869`
- Implementation status: merged and deployed to staging
- Effective status: `optimized_verified`

## Bounded problem

The customer progress text was understandable, but `Internal Only` exposed
implementation state directly: `entity=null`, `op_batch_target_invalid`,
`Provider bounded failure`, the `Wetech asia-prod` canonical target, and
internal routing mechanics. Those details did not tell the Support engineer
which evidence was missing, why the batch-size answer remained unsafe, or how
to continue the investigation.

## Candidate change

- Keep the semantic fact that internal acquisition did not complete, but do not
  transcribe machine fields, codes, aliases, lifecycle states, or retry
  bookkeeping.
- Translate the gap into the affected target and window, missing technical
  evidence, blocked customer decision, next concrete Support check, and the
  human-facing escalation condition.
- Keep `Internal Only` additive to the customer reply and use concise localized
  headings only when they help.

## Verification status

The focused Scenario Router, Final Response, workspace, and runner tests passed
138/138. The complete local suite passed 791/791 after a clean TypeScript
build.

Source PR `tidbcloud/aisupport#873` merged as
`ab8e5cbca5628efe3988f5ed79031ac8fd856e0b`. Deployment workflow
`31677290379` built that image, and app-delivery PR
`tidbcloud/app-delivery#77200` updated staging. The live Deployment reported
the exact image with one Ready Pod and zero restarts.

APID-29340 read replay `c1a8d9b9-5787-43ba-8fc9-20959445b051` preserved the
technical boundary and Support work in concise Chinese sections: the unchecked
window and latch/SQL/workload evidence, the batch-size decision still blocked,
the next alignment check, and the monitoring-team assistance condition. It did
not contain `entity=null`, `op_batch_target_invalid`, `Provider bounded
failure`, `Wetech asia-prod`, or an English `Handoff` heading. The replay used
`mode=read`; Jira, database, evaluation, and Feishu writes were all
`not_requested`.

## Next validation action

Keep APID-29340 as a preservation case for failed internal acquisition. A Jira
comment refresh requires separate explicit write authorization.