# Low-replica configuration guidance

<!-- auto-oncall-optimization-record
{
  "schemaVersion": "auto-oncall-optimization-record-v1",
  "optimizationId": "low-replica-configuration-guidance-2026-08-14",
  "problems": [
    {
      "problemId": "acknowledged-risk-configuration-steps-omitted",
      "summary": "APID-29306 asked for one-replica and two-replica TiDB 8.5 table configuration steps while explicitly accepting the risk, but Primary Analysis treated the guidance request as production approval and omitted the requested steps, checks, verification, and rollback.",
      "status": "optimized_verified",
      "applicability": "Direct-answer customer configuration guidance where the customer asks for bounded steps and acknowledges availability, durability, or performance trade-offs without asking Support to execute or approve the change.",
      "issueKeys": ["APID-29306"],
      "sourceRefs": [
        "https://tidb.atlassian.net/browse/APID-29306#problem:acknowledged-risk-configuration-steps-omitted"
      ],
      "signalTextIncludesAny": [
        "客户已知风险，就要单副本和两副本配置的步骤",
        "acknowledged risk configuration steps omitted",
        "human review removed verified configuration guidance"
      ],
      "observedThrough": "2026-08-14",
      "effectiveAt": "2026-08-14T09:14:26Z",
      "verifiedAt": "2026-08-14T09:29:23.904Z",
      "attemptedAction": "Separate customer configuration guidance from Support execution or approval, preserve established subanswers and bounded steps even when an operational boundary remains human-owned, and add the TiDB 8.5 low-replica Placement Policy support boundary and regression coverage.",
      "evidenceUrl": "https://tidb.atlassian.net/browse/APID-29306?focusedCommentId=23449154"
    }
  ]
}
-->

- Optimization ID: `low-replica-configuration-guidance-2026-08-14`
- Owner: shared analysis guidance plus auto-oncall product knowledge consumed
  by Primary Analysis and the Scenario Router
- Source reference: `APID-29306`, human feedback comment `23453463`
- Implementation status: deployed to staging in image `8e5847bd85933d4fc5aae445e1236364d3a18763`
- Effective status: `optimized_verified`

## Bounded problem

APID-29306 explicitly requested TiDB 8.5 configuration steps for one-replica
and two-replica tables and stated that the availability and durability risks
were already understood. Primary Analysis successfully found the documented
two-replica follower relationship, but treated the request as production
approval. It returned a generic human-review response and omitted both the
established two-replica subanswer and the requested prechecks, configuration,
verification, and rollback guidance.

The historical Auto Coverage optimization for this ticket proved only that the
existing DDL direct-answer route reached analysis. It did not verify this
separate answer-completeness problem.

## Candidate change

- Distinguish customer-executed configuration guidance from a request for
  Support to execute or approve a production operation.
- Preserve established product facts and independently verified subanswers even
  when an unresolved or operational boundary remains human-owned.
- For TiDB 8.5 low-replica Placement Policies, state that two total TiKV voting
  replicas use `FOLLOWERS = 1`, do not propose invalid `FOLLOWERS = 0` for one
  replica, and use the established TiKV constraint-count form for the one-replica
  example.
- Include bounded prechecks, asynchronous-placement verification, risk caveats,
  and rollback to the previously reviewed policy or replica count without
  granting a production go-ahead.

## Verification status

- Service PR `tidbcloud/aisupport#917` and app-delivery PR
  `tidbcloud/app-delivery#77304` deployed image
  `8e5847bd85933d4fc5aae445e1236364d3a18763`; the staging Pod became Ready at
  `2026-08-14T09:14:26Z` with zero restarts and both health endpoints passing.
- Historical read replay `a09a9587-b24a-4b8c-83d7-a907615c184e` supplied both
  one-replica and two-replica configurations, prechecks, placement verification,
  asynchronous scheduling, availability/durability risk, and rollback without
  claiming that Support approved a production change.
- Write replay `2a2def15-bad8-4f5d-aa9b-a3edf7ac1882` persisted DB run `150043`
  and updated Jira internal comment `23449154` in place. Jira readback found
  exactly one Auto-oncall comment, `public=false`, with the expected paired body
  and every bounded configuration-guidance element.
- The replay intentionally remained `human_required` for the low-replica risk
  boundary, so the general comparison Judge was `not_compared`. That state does
  not reproduce the selected problem: the answer preserved the requested
  established guidance while keeping production ownership human.

## Unresolved gaps

- The TiDB 8.5 low-replica conclusion is the established Support answer in Jira
  comment `23438318`, used as a bounded reusable response rule rather than as
  hidden historical replay input. Auto-oncall still must not inspect TiDB
  product source code to extend or reinterpret that conclusion.
- The established TiDB 8.5 syntax boundary remains limited to the verified
  Support conclusion and must not be generalized to other versions without
  applicable evidence.

## Next validation action

Treat a later acknowledged-risk configuration answer that again removes
established steps merely because execution remains human-owned as a regression.
Do not use this record to suppress unrelated syntax, version, or safety gaps.