# Expected Diagnosis: tikv-read-iops-full-ranking-across-two-premium-clusters-during-incident-window

This ad-hoc case evaluates a dynamic-window, two-cluster TiKV full-node ranking
task for the latest completed Beijing 11:00-11:05 window.

The runtime hooks resolve the latest completed daily Beijing 11:00-11:05
window, then build a reference answer for that same window across two target
clusters. The expected agent response should:

- avoid treating a raw shared dataplane aggregate as directly cluster-scoped
- return the full TiKV node list for both target clusters, not just a top-N
  subset
- sort cluster groups by `cluster_id` ascending, then sort each cluster's
  `nodes` array by `max_1m_read_iops` descending and use `tikv_node`
  ascending as the tie-breaker
- calculate `max_1m_read_iops` from sampled node-disk read IOPS inside the
  resolved 5-minute window rather than from a single endpoint snapshot
- emit exactly one JSON code block with the required fields:
  `window`, `mapping_strategy`, `evidence_sufficient`, `nodes_by_cluster`
- avoid extra explanatory prose outside that JSON block
- return the same resolved window and the same `mapping_strategy` as the
  runtime reference
- include one grouped section per target cluster, with `nodes` encoded as
  `[tikv_node, max_1m_read_iops]` tuples

The judge intentionally avoids hard-coding specific node names or static
per-cluster values in YAML. Exact node identities, row counts, and max sampled
read-IOPS values come from the runtime-built reference evidence.