# Enable DDL schema advice auto coverage in staging

<!-- auto-oncall-optimization-record
{
  "schemaVersion": "auto-oncall-optimization-record-v1",
  "optimizationId": "ddl-schema-advice-auto-coverage-2026-08-06",
  "problems": [
    {
      "problemId": "ddl-schema-advice-excluded-by-auto-coverage",
      "summary": "DDL schema advice is classified as a direct answer but skipped because the scenario is absent from staging Auto Coverage.",
      "status": "optimized_verified",
      "issueKeys": ["APID-29304", "APID-29306"],
      "sourceRefs": [
        "https://tidb.atlassian.net/browse/APID-29304#problem:ddl-schema-advice-auto-coverage",
        "https://tidb.atlassian.net/browse/APID-29306#problem:ddl-schema-advice-auto-coverage"
      ],
      "signalTextIncludesAny": [
        "ddl_schema_change_advice",
        "schema advice",
        "table schema design",
        "auto_coverage_disabled"
      ],
      "observedThrough": "2026-08-05",
      "effectiveAt": "2026-08-06T10:36:14+08:00",
      "verifiedAt": "2026-08-06T10:45:00+08:00",
      "attemptedAction": "Add ddl_schema_change_advice to the staging Auto Coverage scenario allowlist, deploy it, and rerun both affected cases through live auto-oncall.",
      "evidenceUrl": "https://github.com/tidbcloud/aisupport/pull/647"
    }
  ]
}
-->

- Optimization ID: `ddl-schema-advice-auto-coverage-2026-08-06`
- Owner: auto-oncall-services
- Source reference: `APID-29304`, `APID-29306`
- Implementation status: merged and deployed to staging
- Effective status: `optimized_verified`

## Bounded problem

Both source tickets were classified as `ddl_schema_change_advice` with
`direct_answer`. The resolution is already enabled in staging, but the scenario
is absent from `AUTO_ONCALL_AUTO_COVERAGE_ENABLED_SCENARIOS`, so the worker
stops before analysis with `auto_coverage_disabled`.

This change adds only `ddl_schema_change_advice` to the staging scenario
allowlist. It does not bypass the L1 gate, enable customer-visible replies,
admit operation requests, or change production configuration.

## Verification evidence

- Pre-change DB gate records show both source tickets were skipped at Auto
  Coverage with `ddl_schema_change_advice/direct_answer`.
- The staging source template now includes `ddl_schema_change_advice`.
- A focused configuration test proves that the scenario and `direct_answer`
  combination evaluates to `enabled`.
- `tidbcloud/aisupport#647` merged as `7b566bd42f039face7d992a309eadbe955266483`;
  app-delivery template PR `#76365` and image PR `#76367` both merged.
- The live staging Deployment runs image `7b566bd42f039face7d992a309eadbe955266483`.
  Its replacement pod was created at 2026-08-06 10:36:14 +08:00, reached
  1/1 Ready with zero restarts, returned HTTP 200 from `/readyz`, and exposed
  `ddl_schema_change_advice` in its actual process environment.
- `APID-29304` refreshed both L1 and Auto Coverage gates to `allowed`, then
  completed run `00812bfe-9b2d-4257-80e9-e387575b7b13` as `internal_only`.
  DB run `120026`, evaluation, and Base sync succeeded. Jira comment
  `23449107` read back with HTTP 200 and `public=false`.
- `APID-29306` refreshed both gates to `allowed`, then completed run
  `b4e3bcc8-cbb2-4fdb-a13b-a1f0a11d93b5` as `human_required` because reducing
  production table replicas requires a human-reviewed support boundary. DB
  run `120027`, evaluation, and Base sync succeeded. Jira comment `23449154`
  read back with HTTP 200 and `public=false`.
- The DB had no `queued`, `running`, or `retry` jobs after both reruns.

## Unresolved gaps

- `APID-29306` correctly remains `human_required`; enabling the scenario does
  not authorize a production replica-count change or replace support review.

## Next validation action

Monitor later DDL advice tickets for classification regressions. Treat
production DDL or replica-count changes as separate human-owned operations.