# Impact-first mitigation

<!-- auto-oncall-optimization-record
{
  "schemaVersion": "auto-oncall-optimization-record-v1",
  "optimizationId": "impact-first-mitigation-2026-08-11",
  "problems": [
    {
      "problemId": "deep-root-cause-uncertainty-blocks-safe-mitigation",
      "summary": "Scenario diagnosis waits for a complete deeper root cause before preserving an already-supported, human-owned mitigation for active user impact.",
      "status": "optimized_unverified",
      "issueKeys": ["ST-2863"],
      "sourceRefs": [
        "https://tidb.atlassian.net/browse/ST-2863#problem:deep-root-cause-uncertainty-blocks-safe-mitigation"
      ],
      "signalTextIncludesAny": [
        "root cause uncertainty blocks safe mitigation",
        "asks for deeper diagnosis before reducing active impact",
        "managed capacity mitigation omitted while impact continues"
      ],
      "observedThrough": "2026-08-11",
      "effectiveAt": "2026-08-11T05:47:29Z",
      "verifiedAt": null,
      "attemptedAction": "Give every Scenario Diagnostic Agent the same impact-first contract, require the Router to add capacity-resource-pressure when an enforced resource limit is reached, and require Final Synthesis to preserve conditional PingCAP temporary backend scale-out without waiting for complete RCA.",
      "evidenceUrl": null
    }
  ]
}
-->

- Optimization ID: `impact-first-mitigation-2026-08-11`
- Owner: auto-oncall-services diagnostic orchestration
- Source reference: `ST-2863` answer-version feedback
- Implementation status: deployed to staging
- Effective status: `optimized_unverified`

## Bounded problem

The diagnosis correctly recognized an enforced TiFlash memory boundary but
treated the missing deeper workload cause as a reason to continue asking for
SQL identity and plan evidence before giving a useful mitigation. This left an
active-impact answer without the bounded action that the already-established
immediate mechanism could support.

The common diagnosis contract should separate mitigation sufficiency from RCA
sufficiency. It must not authorize or execute a production operation. It should
preserve a safe, reversible, human-owned mitigation when direct evidence
supports it, while keeping the deeper trigger unresolved and continuing the
investigation.

For TiDB Cloud capacity ownership, Starter, Essential, and Premium are managed
by PingCAP. A backend capacity adjustment may be an incident mitigation, but
the durable follow-up is to explain why automatic resource management did not
meet the load. Dedicated capacity remains customer-managed.

## Candidate change

- Put one impact-and-mitigation rule in the common Scenario Diagnostic Agent
  contract used by every scenario and provider.
- Preserve the mitigation through `humanHandoff`; do not add a parallel
  scenario representation or a provider-side diagnosis field.
- Require Final Synthesis to present active impact and a safe mitigation before
  deeper RCA, while keeping mitigation ownership and uncertainty explicit.
- Keep all production actions human-owned and outside automatic execution.

## Verification evidence

Implemented in the shared Scenario Diagnostic Agent and Final Synthesis
contracts. On 2026-08-11, the `ST-2863`-shaped regression passed for every
scenario, and the complete TypeScript suite passed with 723 tests. This is
local contract evidence only: availability to auto-oncall and a case-specific
post-change replay are still required before promotion beyond `candidate`.

An isolated, automation-disabled staging Pod then ran `ST-2863` in `mode=read`
as run `2747df87-e94f-4199-8983-be1478f0c9c5`. The Clinic fallback completed
all three scenario decisions and Final Synthesis. The final draft led with
pause-retry, smaller-batch, and lower-MPP-concurrency mitigation, and preserved
PingCAP ownership for Starter, Essential, and Premium versus customer
ownership for Dedicated. It did not write Jira, DB, or Feishu. This proves the
candidate behavior in the isolated Pod, but it is not yet available in the
shared runtime.

A follow-up isolated replay `458900b9-e5ed-4be4-830f-53407f5421c5` exposed
that the Router omitted `capacity-resource-pressure`. The actual Router thread
`019feea4-bdd6-7232-beee-3ed18bcefc5c` acknowledged that this was too narrow:
the observed TiFlash memory-limit breach was a capacity boundary and should
have added that secondary scenario. The actual Final Synthesis thread
`019feead-4aa5-7752-a406-6385c777c3d0` also stated that incomplete RCA does not
block temporary expansion and that its earlier ordering was too conservative
for a continuing Premium impact.

After correcting both common contracts, isolated `mode=read` replay
`c8abec16-33e8-460e-b50c-6152e7e3665a` routed `memory-oom`,
`capacity-resource-pressure`, and `query-execution`. Its final draft preserved
the conditional action: for Starter, Essential, or Premium with continuing
impact, PingCAP should evaluate temporary TiFlash backend scale-out while
continuing the automatic-resource-management and workload investigation. The
capacity provider evidence remained partial after a bounded Clinic HTTP 502,
so this proves mitigation publication rather than complete capacity diagnosis.
No Jira, DB, or Feishu write occurred.

## Unresolved gaps

- No post-change replay has proved that the final draft preserves both the
  mitigation and the unresolved autoscaling or workload cause in the shared
  runtime.
- The service tier was still unavailable, so the verified draft correctly kept
  PingCAP backend scale-out conditional rather than claiming the case was
  definitely Premium.
- The capacity scenario ended with partial evidence after Clinic HTTP 502; no
  complete capacity diagnosis was established.
- No Jira internal comment has been refreshed.
- The common contract is available in staging image
  `6fcd789dfe896594b405cfdb0b8df7fc50a47fc3`, but no post-deployment ST-2863
  replay has verified it in the shared runtime.

## Next validation action

Replay `ST-2863` with its historical cutoff and verify the existing Jira
internal comment in place.