# Scenario Diagnosis Router - Optimization ID: `scenario-diagnosis-router-2026-07-24` - Owner: auto-oncall-services - Source references: `APID-29220`, `APID-29230`, `APID-29231`, the internal Troubleshooting Guide, nutshell diagnostic skills, and existing `docs/opts/` problem signals - Implementation status: merged through `tidbcloud/aisupport#498` and available in the staging runtime by the `2026-07-27` Focus baseline - Effective status: `optimized_unverified`; routing is active, but the source cases do not yet pass the full transient fault-domain criterion ## Bounded problem The shared OP diagnosis skill currently owns provider routing, incident discovery, every diagnostic branch, evidence ordering, and final RCA in one linear document. That structure makes the first plausible hypothesis overly influential and encourages generic follow-up checks when two independent scenarios should be evaluated separately. The bounded optimization changes the main diagnosis into an orchestrator. It selects at most three relevant scenarios, runs independent read-only query batches concurrently where the provider permits it, and synthesizes their structured findings only after each scenario has reached its own stop condition. Scenario references are bundled in this repository. External runbooks are provenance and design inputs only. ## Verification evidence - The skill validator passed for the bundled `op-diagnosis` directory. - Contract tests cover the 16-entry catalog, all reference links, the maximum three-scenario route, safe concurrency boundaries, structured Scenario Findings, post-scenario synthesis, every Troubleshooting Guide topic, source provenance, causal alignment, and prior critical diagnostic guards. - The full repository suite passed with 421 tests before the runtime prompt was changed from the old single latency branch to the OP scenario router. Targeted prompt and skill suites passed again after that change. ### APID-29230 forward test At `2026-07-24`, an independent forward evaluator read only the historical replay-safe input and the candidate skill; it did not read the old answer, later comments, or query an external provider. - Routed `service-availability-impact` as primary and `connection-network-path` as secondary. - Did not route `tiflash-io-apply`: the component field and alert text were not direct TiFlash IO/apply evidence. - Kept both findings `inconclusive` from input alone because per-instance connection/request/process outcomes, business QPS, probe semantics, and load-balancer state were absent. - Returned provisional Medium plus `human_required` for the still-active unresolved incident, with the explicit rule that observed service loss or a required production recovery action promotes it to at least High. - Did not use probe success, non-zero aggregate QPS, or an unsupported network or TiFlash mechanism as the conclusion. This passed the routing and synthesis criteria. It is a contract-level forward test, not a post-deployment provider replay. ### APID-29220 forward test At `2026-07-24`, a separate independent evaluator used only the historical replay-safe input and candidate skill, without provider queries or the old answer. - Routed only `connection-network-path` for the TiDB-client backoff alert on the named instance and exact two-minute window. - Did not infer a TiKV/region/leader scenario from the title or component label. - Kept the finding `inconclusive` until a per-point, per-instance backoff series split by reason/type identifies one exact hop. - Did not join cross-time/cross-instance aggregates or confirm network, region-error, or a deeper cause. This passed all bounded causal-alignment criteria. The previously preserved staging-egress replay remains evidence that aligned backoff and region-error rates can bound the immediate mechanism, but the new scenario-router candidate itself has not been deployed or rerun in staging. ## Unresolved gaps - The router and scenario catalog are effective in staging, but current replay can still omit one competing fault domain or bypass OP diagnosis after a classifier mismatch. - Provider-backed replay has not yet passed the full three-domain criterion. - No Jira internal comment has been refreshed. ## Next validation action Deploy the current classifier correction and transient fault-domain matrix, then replay one multi-scenario service-impact case and one latency/causal case using their historical cutoffs. Promote the problem only after every applicable case-specific replay passes and its stable Jira internal comment is verified.