# Expected Diagnosis: top-tidb-p99-latency-nodes-in-saas01-during-latest-window

This ad-hoc case evaluates a dynamic-window, cluster-scoped TiDB P99 latency
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. The expected agent
response should:

- collect TiDB P99 latency evidence for the exact cluster and resolved window
- rank TiDB pod nodes by the average of their 1-minute P99 latency samples over
  the full 5-minute window, using the original full-precision averages for
  ordering before rendering the final numeric output
- for those top 3 TiDB nodes, also provide the same-window average P99
  breakdown for plan building, distributed execution, KV request latency, TSO
  wait latency, and Go GC STW pause latency
- also provide cluster-level averages computed over all relevant server nodes
  for TiKV-side gRPC request handle latency and PD-side TSO request handle
  latency
- emit exactly one JSON code block with the required fields:
  `cluster_id`, `window`, `evidence_sufficient`,
  `cluster_avg_tikv_grpc_request_handle_p99_s`,
  `cluster_avg_pd_tso_request_handle_p99_s`,
  `top_nodes_by_avg_p99_latency`
- render all latency `*_s` fields with 6 decimal places
- avoid extra explanatory prose outside that JSON block
- return the same cluster id and resolved window as the runtime reference
- avoid fabricating a ranking when the primary latency metric is absent or only
  yields empty series, or when any required node-level breakdown metric or
  cluster-level service-side metric is missing, and instead return
  `evidence_sufficient=false`

The judge intentionally keeps the exact node identities and numeric values in
the runtime-built reference rather than hard-coding them in static YAML.