# Enable BR and backup/restore auto coverage in staging

<!-- auto-oncall-optimization-record
{
  "schemaVersion": "auto-oncall-optimization-record-v1",
  "optimizationId": "br-backup-restore-auto-coverage-2026-07-20",
  "problems": [
    {
      "problemId": "br-scenario-not-enabled-in-auto-coverage",
      "summary": "BR diagnosis is classified but skipped because backup_restore_or_dr is not enabled.",
      "status": "optimized_verified",
      "issueKeys": ["APID-29203"],
      "sourceRefs": [],
      "signalTextIncludesAny": ["backup_restore_or_dr", "br diagnosis", "backup and restore", "auto coverage", "自动处理范围", "被跳过"],
      "observedThrough": "2026-07-20",
      "effectiveAt": "2026-07-20T19:22:23+08:00",
      "verifiedAt": "2026-07-20T19:26:00+08:00",
      "attemptedAction": "Add backup_restore_or_dr to the staging Auto Coverage scenario allowlist.",
      "evidenceUrl": "https://github.com/tidbcloud/aisupport/pull/387"
    }
  ]
}
-->

- Optimization ID: `br-backup-restore-auto-coverage-2026-07-20`
- Title: Admit BR backup and restore Q&A and diagnosis into staging auto-oncall
- Owner: auto-oncall-services
- Source type: daily report follow-up
- Source reference: `APID-29203`; staging daily report
  `2026-07-19 18:00 ~ 2026-07-20 18:00`

## Bounded problem

`backup_restore_or_dr` is a valid classifier scenario and its normal handling
modes are already present in the staging resolution allowlist, but the scenario
itself is absent from `AUTO_ONCALL_AUTO_COVERAGE_ENABLED_SCENARIOS`. BR cases
are therefore skipped before analysis even when the ticket contains enough
evidence for an AI draft.

This change admits only the existing `backup_restore_or_dr` scenario in
staging. It does not enable customer-visible replies, bypass L1, safety, or
operation gates, or change production configuration. A BR answer may still be
`human_required`, as for exposed credentials or an unverified operational
parameter.

## Status

- Implementation: merged in aisupport PR
  https://github.com/tidbcloud/aisupport/pull/387 and synced by app-delivery PR
  https://github.com/tidbcloud/app-delivery/pull/74989.
- Effective/deployment: available in staging since 2026-07-20 19:22 +08:00.
  The restarted live pod reads `backup_restore_or_dr` from its rendered
  environment; production was not changed.

## Problem validation

| Problem signal | Ticket keys | Status | Evidence |
| --- | --- | --- | --- |
| BR diagnosis is classified but skipped because `backup_restore_or_dr` is not enabled | `APID-29203` | `optimized_verified` | The live worker gate returned `enabled` for `backup_restore_or_dr/direct_answer`; staging dry-run `b904c444-c083-4a4d-ac74-c8484093d6b1` produced a bounded BR/S3 diagnosis while preserving `human_required` for exposed credentials. |

## Validation evidence

- Pre-change staging template excludes `backup_restore_or_dr` while allowing
  `direct_answer`, `clarification_needed`, and `evidence_assisted` resolutions.
- 2026-07-20: staging kustomize render contains the BR scenario while
  `AUTO_ONCALL_CUSTOMER_REPLY_ENABLED` remains `false`.
- 2026-07-20: full `npm test` passed, 334/334.
- 2026-07-20 19:22 +08:00: live staging ConfigMap and restarted pod environment
  contained `backup_restore_or_dr`; `AUTO_ONCALL_CUSTOMER_REPLY_ENABLED`
  remained `false`, health returned `ok`, and Deployment was 1/1 ready.
- A live in-pod coverage evaluation classified `APID-29203` as
  `backup_restore_or_dr/direct_answer` and returned
  `autoCoverageDecision=enabled` with no missing keys.
- Read-only staging dry-run `b904c444-c083-4a4d-ac74-c8484093d6b1` produced a
  substantive S3 `503 SlowDown` diagnosis. Safety correctly kept the result
  `human_required` because the Jira description exposed AWS credentials; no
  Jira comment or Feishu message was requested.
- Post-rollout logs showed successful poll and continuation cycles, idle
  workers, report completion without failures, and Base sync with zero failed
  records. DB verification found no `queued` or `running` jobs and both poll
  cursors present; the historical job `60137` remained unchanged as
  `skipped/auto_coverage_disabled`.

## Unresolved gaps and next action

- Future BR tickets in supported handling modes are now admitted to staging.
- The historical `APID-29203` job is intentionally not re-enqueued or rewritten;
  this rollout does not backfill completed jobs.
- A later BR quality optimization may improve concrete TiDB-side remediation,
  but that is separate from this verified coverage-gate problem.