# Internal Only Extra Information

<!-- auto-oncall-optimization-record
{
  "schemaVersion": "auto-oncall-optimization-record-v1",
  "optimizationId": "internal-only-extra-information-2026-08-13",
  "problems": [
    {
      "problemId": "internal-only-repeats-customer-answer",
      "summary": "The Internal Only section repeated the customer-facing conclusion before adding one private caveat, even though the section should contain only useful information omitted from the customer reply.",
      "status": "optimized_verified",
      "applicability": "Paired direct-answer, continuation, and diagnostic responses whose internal-only message overlaps the customer message.",
      "issueKeys": ["ST-2891"],
      "sourceRefs": [
        "https://tidb.atlassian.net/browse/ST-2891#problem:internal-only-repeats-customer-answer"
      ],
      "signalTextIncludesAny": [
        "internal only repeats the customer answer",
        "internal only should contain only additional information"
      ],
      "observedThrough": "2026-08-13",
      "effectiveAt": "2026-08-13T06:47:00Z",
      "verifiedAt": "2026-08-13T06:49:24Z",
      "attemptedAction": "Define Internal Only as the meaningful set difference from the customer reply, remove repeated conclusions and instructions, and use a language-specific no-additional-information marker when no useful private information remains.",
      "evidenceUrl": "https://tidb.atlassian.net/browse/ST-2891"
    }
  ]
}
-->

- Optimization ID: `internal-only-extra-information-2026-08-13`
- Owner: paired response audience projection
- Source reference: `ST-2891`
- Implementation status: merged and deployed to staging
- Effective status: `optimized_verified`

## Bounded problem

The ST-2891 replay correctly produced a compact `Internal Only` message, but it
first repeated the customer-facing capability conclusion and user-binding
behavior before adding the one genuinely additional tier limitation. Internal
Only should contain the extra tier boundary alone, not a summary of the answer.

## Implemented change

- Treat `internalHandoffMarkdown` as the meaningful set difference from
  `customerReplyMarkdown`.
- Keep only useful facts, evidence boundaries, ownership, actions, or escalation
  conditions deliberately omitted from the customer message.
- When no extra information remains, emit `无额外内部信息。` or
  `No additional internal-only information.` instead of repeating the answer.

## Verification status

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

ST-2891 `mode=read` replay run `b100295e-8ef9-4a02-a6a9-e7a5b10964d6`
remained `decision=internal_only`. All capability, tier, SQL, and connection
guidance was already in `customerReplyMarkdown`, so `internalHandoffMarkdown`
contained exactly `无额外内部信息。` and repeated none of that answer. Jira,
database, evaluation, and Feishu writes were all `not_requested`. Rendering
the response with the production comment builder preserved the two visible
sections and placed only that marker under `【Internal Only】`.

## Next validation action

Keep the set-difference and language-specific empty-marker tests as
preservation checks. No write replay or Jira comment refresh is required for
this presentation-only verification.