---
name: op-diagnosis
description: "Run evidence-driven read-only TiDB diagnosis for TiDB Cloud and supported OP environments through one common Scenario Router, Evidence Agent, Provider Executor, Scenario Diagnostic Agent, and Final Response Agent contract. Provider transport stays isolated and there is never cross-provider fallback. The package path remains op-diagnosis for runtime compatibility."
---

# TiDB Cloud and OP Scenario Diagnosis

Use the runtime call name to select exactly one stage. Do not load references
owned by another stage.

## Stage references

- Scenario Router and Final Response Agent: read
  [routing and reconciliation contract](references/router-synthesis-contract.md) and
  [scenario catalog](references/scenario-catalog.md). After routing, read only
  the one to three selected `references/scenario-<scenario-id>.md` files.
- Scenario Diagnostic Agent: read
  [scenario diagnosis contract](references/scenario-diagnostic-contract.md) and exactly
  `references/scenario-<scenario-id>.md`. Do not read the routing/reconciliation contract,
  catalog, another scenario, or either provider skill.
- Evidence Agent: do not read this skill, routing/diagnosis contracts, the
  catalog, or scenario references. Load exactly the provider query skill named
  by the runtime contract and write one plan per runner-authorized batch round.
  It never invokes the provider. A later round may adapt from structured earlier
  errors or gaps; it must use the new round-specific paths and may not blindly
  repeat a query.
- Provider Executor and authentication/bootstrap are runner operations, not
  agents or diagnosis stages.

The stable runner-owned Evidence Agent handoff is documented at
[child evidence handoff](references/child-evidence-handoff.md). It is not a
normal Evidence Agent input. Read it only when the runtime explicitly requests
handoff-schema debugging; reading it never authorizes an agent to write or
patch the handoff. Its `child` filename and schema token are compatibility names
only, not an agent role.

## Entry and provider gate

`input/direct-artifact-gate.json` with `status=candidate` records materialized
evidence only; it is not a Provider gate. This skill is unavailable when
`input/diagnostics/manifest.json` has `providerPolicy=prohibited`, or when the
Scenario Router selected `evidenceSource=supplied` for the scenario. Continue
only when the manifest explicitly has `providerPolicy=agent_read_only` and the
Scenario Router selected `evidenceSource=provider`.

The runtime-selected evidence provider is binding:

- `APID` and `NAID` project identity is a runner-owned OP boundary. Agents do
  not reinterpret a ticket as Cloud from an organization- or cluster-shaped
  value.
- `clinic` requires one exact typed TiDB Cloud `orgId` plus a runner-resolved
  target set containing one to three exact `clusterId` values and selects only
  `clinic-api`. An exact typed cluster ID binds one target directly; a missing
  cluster ID may be resolved before this stage from a bounded same-org Clinic
  inventory when the ticket explicitly names the cluster or clusters.
- `Wetech` or `apac-test` selects only `wetech-op-grafana`.
- `Manus` selects only `manus-op-grafana` and requires exactly one ticket
  target, `vida` or `monica`.
- Any other, missing, or ambiguous OP alias stops OP provider acquisition.

Never fall back from Clinic to an OP transport, from OP to Clinic or
Investibook, between OP accounts, or to a default datasource.
OP TiCDC does not require Cloud Dataflow changefeed metadata; the selected
Wetech route uses its bounded metrics and logs.

## Common ownership

- The Scenario Router owns provider selection, scenario assignment, the
  canonical entity set/window anchor, and the final ticket-level reconciliation
  after all scenario decisions return. Its routing reason is not an evidence
  acquisition objective.
- The Evidence Agent owns only neutral provider query planning. It does not judge
  identity, causality, severity, safety, remediation, or scenario status.
- The runner-owned Provider Executor owns bounded query execution and helper
  retries. Agent9 Wetech Metrics calls may run independently and each Evidence
  Agent Turn keeps at most two Dashboard calls in flight. Manus is strictly
  serial; independent Clinic batch operations may execute concurrently. The
  runner owns compact-report and handoff materialization and validation.
- One persistent Scenario Diagnostic Agent owns the initial evidence question,
  later refinement questions, and diagnosis judgment for only its selected
  causal path. It never reroutes, prescribes provider syntax, or drafts the
  final Jira response.
- The Scenario Router owns cross-scenario deduplication, conflict resolution,
  evidence precedence, impact, final severity, mitigation, and handoff.
- The Final Response Agent owns wording, organization, language, and length
  only. It receives the canonical Router decision, not scenario packets.
- Wetech has no AOS runner-level provider lock; its per-Turn Dashboard limit
  does not apply to Metrics calls or start another Evidence Agent Turn. Manus
  readiness, queries, bounded retries, and same-account Provider Executor work
  remain serial. The Manus provider lock does not own Evidence Agent planning
  or Scenario Diagnostic Agent reasoning.

## Common safety boundary

- Keep every provider action read-only. Never change configuration, execute
  DDL/DML, kill work, restart, scale, fail over, or perform a production
  operation.
- Never expose or persist cookies, authorization headers, passwords, tokens,
  verification codes, or provider credentials. SQL, plan predicates and Digests
  supplied as diagnostic evidence may be cited where they support the conclusion.
- Use the canonical target and incident window supplied by the runtime. Never
  switch target, provider, or time semantics inside a scenario.
- Treat compact provider output as the reasoning input. Raw/detail artifacts
  are audit sources and stay out of agent context unless one explicitly named
  load-bearing field requires a bounded inspection.
- Preserve exact missing provider dimensions as evidence gaps. Empty, failed,
  unsupported, aggregate-only, or top-N-limited results are not healthy or
  negative evidence.
- For metric coverage, `verified_empty` supports only the narrow absence of a
  trusted sparse event. `unexplained_empty` and `unclassified_empty` remain
  gaps and cannot rule out a mechanism. Decide whether the gap is load-bearing;
  never prescribe PromQL, labels, grouping, or provider syntax to repair it.