# Expected Diagnosis: topsql-links-for-hottest-two-tikv-nodes-during-incident-window

This ad-hoc case evaluates a dynamic-window, single-cluster TopSQL link
generation 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. The expected agent
response should:

- avoid treating a raw project/shared aggregate as directly cluster-scoped
- identify the hottest two TiKV nodes within the target cluster by `max 1m
  read IOPS` inside the resolved 5-minute window
- emit exactly one JSON code block with the required fields:
  `cluster_id`, `window`, `mapping_strategy`, `evidence_sufficient`,
  `topsql_links`
- avoid extra explanatory prose outside that JSON block
- return the same cluster id, resolved window, and `mapping_strategy` as the
  runtime reference
- keep `topsql_links` ordered by heat descending and use `tikv_node` as the
  node identity in each element
- generate TopSQL URLs that point to the same cluster, window, and TiKV
  instance as the runtime reference, regardless of query-parameter ordering or
  URL-encoding differences

The judge intentionally avoids hard-coding static node names or fixed TopSQL
links in YAML. Exact node identities and reference URLs come from the
runtime-built reference evidence.