# Public Draft Internal-Detail Boundary

<!-- auto-oncall-optimization-record
{
  "schemaVersion": "auto-oncall-optimization-record-v1",
  "optimizationId": "public-draft-internal-detail-boundary-2026-08-13",
  "problems": [
    {
      "problemId": "internal-provider-mechanics-enter-customer-progress-draft",
      "summary": "A human-required customer progress draft exposed that internal monitoring retrieval failed and that Support would validate the cluster-to-monitoring target mapping, even though those mechanics belonged only in the paired internal handoff.",
      "status": "optimized_verified",
      "applicability": "Evidence-assisted final or progress responses where an internal acquisition attempt failed, degraded, timed out, was rejected, or returned an invalid target or mapping.",
      "issueKeys": ["APID-29338"],
      "sourceRefs": [
        "https://tidb.atlassian.net/browse/APID-29338#problem:internal-provider-mechanics-enter-customer-progress-draft"
      ],
      "signalTextIncludesAny": [
        "internal monitoring data retrieval failed",
        "validate the cluster-to-monitoring target mapping",
        "内部监控数据尚未成功获取",
        "核对该集群的内部监控映射"
      ],
      "observedThrough": "2026-08-13",
      "effectiveAt": "2026-08-13T01:15:45Z",
      "verifiedAt": "2026-08-13T01:31:39Z",
      "attemptedAction": "Make Scenario Router and Final Response preserve acquisition failures, target mappings, retries, internal routing, and escalation mechanics only in internalHandoffMarkdown while customerReplyMarkdown retains the exact open customer conclusion and a concise Support-owned follow-up.",
      "evidenceUrl": "https://tidb.atlassian.net/browse/APID-29338"
    }
  ]
}
-->

- Optimization ID: `public-draft-internal-detail-boundary-2026-08-13`
- Owner: Scenario Router and Final Response audience projection
- Source reference: `APID-29338`, job `150062`, internal comment `23543864`
- Implementation status: deployed to staging in image
  `e9c0f68cda3d48315ffa8fd6563623d7018bbca9`
- Effective status: `optimized_verified`

## Bounded problem

The canonical pair existed and Jira preserved both sections correctly. The
customer field itself was wrong: it stated that internal monitoring data had
not been retrieved and that Support would validate an internal monitoring
mapping. The Validator correctly denied the public write, but a denied write
does not repair the upstream audience projection.

## Candidate change

- Require Scenario Router to keep internal acquisition status, target mapping,
  query or transport errors, retry paths, owner routing, and escalation details
  only in `internalHandoffMarkdown`.
- Require Final Response to preserve those exact facts in the pair without
  copying them into `customerReplyMarkdown`.
- Express the customer-visible progress only as the exact open conclusion,
  continued internal checks, and a Support follow-up.

## Verification status

- Source PR [#849](https://github.com/tidbcloud/aisupport/pull/849) and
  app-delivery PR
  [#77077](https://github.com/tidbcloud/app-delivery/pull/77077) are merged.
- The staging Deployment read back the exact image SHA above, with one ready
  replica and no restart.
- APID-29338 historical read replay
  `0eed250e-c243-4424-a826-fdff903b327f` and write replay
  `50003366-f2ba-4bca-b8bc-c9b3da39db4e` both produced a customer draft that
  omitted internal acquisition and target-mapping mechanics while retaining
  `op_batch_target_invalid`, mapping validation, and internal escalation in
  `internalHandoffMarkdown`.
- Jira internal comment `23543864` was updated in place and read back with
  `public=false`. Its customer section is clean while the original
  `human_required` internal handoff remains intact.
- The generic write replay created an unintended initial job and duplicate
  internal comment for this bot-assignment-owned ticket. The duplicate comment
  `23547324` was removed after exact-ID and `public=false` verification. This
  replay-owner compatibility gap is separate from the verified audience
  boundary.

## Next validation action

Fix the separate write-replay owner lookup so a bot-assignment-owned ticket
reuses its existing initial owner job and stable Jira comment instead of
creating a legacy `triggerKind=initial` job.