# Expected Diagnosis: compaction-signals-on-db-tikv-9-in-saas01-during-latest-window

This ad-hoc case evaluates whether the agent can collect exact single-node TiKV
compaction evidence for `db-tikv-9` in `saas01` during the latest completed
Beijing `11:00-11:05` window.

The runtime hooks resolve the latest completed daily window, then discover the
exact metric instance for `db-tikv-9` and build a live reference from the same
window. The expected agent response should:

- keep the scope on `db-tikv-9` instead of drifting to cluster-wide aggregates
- collect TiKV compaction evidence from the exact target node, not a broad
  prefix that can accidentally include sibling nodes such as `db-tikv-90`
- emit exactly one JSON code block with the required fields:
  `cluster_id`, `tikv_node`, `window`, `evidence_sufficient`, `signals`
- avoid extra explanatory prose outside that JSON block
- return the same cluster id, TiKV node, resolved window, and per-signal values
  as the runtime reference

The judge intentionally avoids hard-coding static metric values. The exact
window, resolved metric instance, and reference signal values come from live
runtime evidence.