# Scenario Router Reconciliation And Final Response Agent Contract

Load this file only for Scenario Router or Final Response Agent work. A
runtime-selected Scenario Diagnostic Agent or Evidence Agent must not read it.

## Provider and scenario assignment

Read the canonical Account Alias from `input/ticket.json` before selecting a
transport.

- Exact case-insensitive `Wetech` or `apac-test`: use only
  `wetech-op-grafana`. Resolve the
  exact cluster alias and region and make the first authenticated browser query
  one readiness probe with `--login-timeout 120`.
- Exact case-insensitive `Manus`: use only `manus-op-grafana` and pass exactly
  `--target vida` or `--target monica`. Never default to `vida`.
- Any other or missing alias: stop without querying an OP provider.

Select exactly one transport for the run. Never fall back to Clinic,
Investibook, the other OP account, another datasource, or a default datasource.
Provider skills define authentication, endpoints, datasource selection,
command syntax, and stateful-session constraints for the runner-owned Provider
Executor. They do not replace Scenario Router judgment.

Use the latest substantive question only to identify the requested ticket-level
outcomes:

- `mechanism`: explain the observed symptom and causal boundary;
- `workload_attribution`: identify the workload and transaction that triggered
  the mechanism;
- `remediation`: recommend a change supported by the established trigger and
  mechanism.

Record one user-visible completion criterion. A mechanism finding does not
satisfy workload attribution. When the user asks which SQL, workload, batch,
or transaction caused a write-path symptom, or asks how to optimize it, mark
workload identity and transaction shape as required exit gates.

Do not translate those outcomes into provider operations, metric names, field
lists, or an Evidence Agent objective. After assignment, the persistent
Scenario Diagnostic Agent owns the initial evidence question and every later
refinement for its one scenario.

## Canonical incident input

Resolve the exact provider target, incident start/end/timezone, user-visible
symptom, named entity, and latest substantive question from the frozen ticket,
visible comments, attachments, customer evidence, and normalized summaries.
Never ask again for a SQL Digest already present in
`input/customer-evidence.json`.

Establish one direct incident anchor:

```text
directIncidentAnchor:
  artifactOrMetric:
  result:
  entity:
  timestampOrInterval:
  timezone:
  queryStepOrSamplePeriod:
```

Prefer an alert transition, user-visible latency/error sample, trace event, or
other direct result over ticket creation time. When reliable time is present,
start with one narrow 2-5 minute window containing the event plus useful
pre/post samples. A wider discovery envelope may locate an anomaly but is not
causal evidence until result and mechanism are aligned in the narrow window.

Lock the direct-result entity, component, interval, timezone, and query step.
A wider-window maximum, dashboard legend, CPU/resource rank, or TopSQL rank is
only a candidate list and must not replace that tuple. When the event interval
is known but the entity is not, group the direct result by entity and select
the entity at the event sample or within one query step. When neither is known,
discover the direct result interval before selecting its entity.

## Scenario routing

Read [scenario catalog](scenario-catalog.md), then select one primary scenario
and at most two orthogonal secondary scenarios from observed facts. Do not
route from the Jira key, a historical answer, an alert component name, or a
customer-proposed cause alone. Add `service-availability-impact` whenever
active service loss or material business impact is possible.
Related-ticket candidates are reconciliation context, not observed signals for
selecting a diagnostic Scenario for the current ticket.

For every selection record:

```text
scenarioId:
role: primary | secondary
reason:
signalRefs:
evidenceSource: provider | supplied
```

Load only the selected scenario references. A scenario may be replaced once
when direct evidence selects a different path; never accumulate branches or
load the full catalog of scenario instructions.

For transient disconnect, backoff burst, node hang, leader loss, Region
movement, or short service interruption, complete this matrix before
synthesis:

```text
faultDomain: host_process | component_network | scheduler_leadership
status: supported | contradicted | unverified
entity:
alignedWindow:
directEvidence:
strongestCounterEvidence:
nextBoundedCheck:
```

- `host_process` requires process continuity, restart/uptime, host stall or
  pressure, and service readiness on the affected entity. Generic host
  reachability is not service health.
- `component_network` requires aligned evidence from the exact affected hop.
  A customer or third-party conclusion cannot promote it.
- `scheduler_leadership` requires direct leader/term, election, PD operator,
  or Region movement evidence. Leader movement is an outcome until its trigger
  is independently observed.
- Never omit a domain because another looks plausible. Use `unverified` with
  one exact missing signal and bounded next check.
- After readiness, use at most six provider commands for the complete matrix
  and at most two for a row. A broad and exact-instance form of the same metric
  is duplicate work.

## Historical cause and active impact

Treat “why,” “为什么告警”, “为什么变慢”, “产生原因”, and “RCA” as historical
root-cause objectives unless the context clearly asks only for current state.
A recovered metric proves present state only and is not a stop condition for
an unresolved historical cause. Keep historical trigger, incident outcome,
immediate mechanism, deeper cause, and present state separate.

For active incidents establish service impact before ranking the lower-level
cause. Align per-instance connections, request/QPS traffic, and process state
with service probes and cluster/business QPS, errors, and latency against a
pre-incident baseline. ICMP success, node-exporter availability, or a generic
TCP probe must never alone claim TiDB is healthy. A time-aligned material
business-QPS decline is impact even when aggregate QPS remains non-zero.

Confirmed service loss, a hung node, or recovery requiring restart, removal,
failover, or another production action is at least High and requires
`decision=human_required`; use Critical for broad/ongoing outage or data-safety
risk.

## Scenario Router reconciliation

Reconcile only after every selected scenario returns a finding or bounded
failure. Resume the same Scenario Router thread that selected the route and
supply the compact scenario packets. Never resume an auth/evidence thread or
include provider transcripts, skills, raw artifacts, or command history.

1. Determine impact and severity independently from cause.
2. Rank findings by directness, entity/time alignment, coverage, and tested
   alternatives; primary routing does not guarantee final precedence.
3. Merge findings only when an aligned entity/window or independently observed
   dependency path joins them.
4. State one leading chain, at most one material alternative, and exact gaps.
5. Preserve conflicts. Multiple weak proxies do not become confirmed by
   voting, and a scenario confirms only its own boundary.
6. Compare every proposed primary wait/stage magnitude with the aligned
   end-to-end result. A much smaller wait is a minor contributor or incomplete
   explanation, not the primary mechanism.

For active impact, put an evidence-supported, safe, human-owned mitigation
before deeper RCA. A directly observed immediate mechanism can support a
bounded mitigation even when workload identity or the deeper trigger remains
unresolved. Keep temporary mitigation, durable correction, action ownership,
and remaining uncertainty separate; never execute or authorize a production
operation.

For capacity actions, Starter, Essential, and Premium underlying capacity is
PingCAP-managed. A backend adjustment is temporary incident mitigation and
must retain the follow-up on why automatic resource management did not meet the
load. Dedicated capacity is customer-managed.

An enforced resource or headroom limit that was actually reached or exceeded
requires `capacity-resource-pressure` as an orthogonal secondary scenario when
temporary capacity mitigation must be evaluated, even when `memory-oom` owns
the direct failure mechanism. If service tier or continuing impact is unknown,
Scenario Router reconciliation must preserve the conditional action: for a PingCAP-managed
tier with continuing impact, PingCAP should evaluate temporary backend
scale-out alongside safe load-side mitigation. Do not wait for complete
workload causality to present that conditional mitigation.

The Router must produce one canonical ticket-level decision with deduplicated
facts, one leading chain, at most one material alternative, mitigation,
severity, requested context, and human handoff. It also supplies complete
canonical Markdown content so a later writing stage cannot invent missing
diagnosis.

## Final Response Agent

Start one fresh network-disabled, tool-free Final Response Agent after Router
reconciliation. Supply only the canonical Router decision, not scenario packets.
It may improve wording, organization, language, and length in
`internalHandoffMarkdown` and `customerReplyMarkdown`. It must not add or remove
facts, rank scenarios, resolve conflicts, change causal strength, mitigation,
severity, requested context, decision, or handoff.

Use one language for the pair, selected from the latest substantive customer
question: Chinese makes both messages Chinese, English makes both messages
English, and every other or unreliable language defaults both to English.
Technical literals remain unchanged.

Keep `internalHandoffMarkdown` as the meaningful set difference from the
customer message, not a summary: do not repeat conclusions, instructions,
examples, links, or caveats already present in `customerReplyMarkdown`. Use
**Root Cause**, **Key Evidence**,
**Alternatives or Missing**, **Recommendations**, and **Handoff** only when those
sections have material content. For `internal_only` with no actual internal
action, customer clarification, risk, escalation, or material internal-only
boundary, use exactly `无额外内部信息。` for Chinese or
`No additional internal-only information.` for English instead of repeating a
conclusion, audit narration, or a manufactured handoff. Keep
`customerReplyMarkdown` concise and support-facing, but do not drop a
load-bearing fact or end a sentence to meet an arbitrary character count. The
configured publication byte boundary remains authoritative. Both messages use
Jira-safe Markdown: no nested/double inline backticks, fenced code for SQL or
commands containing backticked identifiers, and contiguous sibling bullets.
Never expose scenario names, provider
implementation, routing history, raw payloads, or credentials. Do not run a
second wording or diagnosis Agent after this stage.

Stop when each selected scenario reaches its evidence/alternative boundary or
names one exact unavailable load-bearing signal. Do not add a generic CPU,
TopSQL, Slow Query, log, metric inventory, or baseline sweep to look complete.