# Clinic Store Flow-Control Localization - Optimization ID: `clinic-store-flow-control-localization-2026-08-18` - Owner: Clinic Evidence Agent provider plan - Source reference: `TCID-12989` - Implementation status: deployed in image `00add7fc3ad53efc10d99e6fa9e687b1fae3197c` - Effective status: `optimized_verified` ## Bounded problem Slow Query evidence alone did not answer whether the affected TiKV store experienced flow control. The missing chain was store identity, store-to-TiKV topology mapping, and a same-window throttle-duration measurement on that exact instance. ## Change and validation The Clinic provider contract now defines the store relationship and keeps the concrete metrics, labels, grouping, and up to two selector-dependent refinements with the same Evidence Agent. It explicitly supports starting from an aligned throttled TiKV instance, mapping it to numeric store, and then testing exact-store Commit/Prewrite without a whole-cluster client histogram. A Provider Executor compaction step now accepts only `pd_scheduler_store_status{type="store_capacity"}` rows containing a numeric `store` and TiKV DNS `address` on port `20160`, then emits the exact first DNS label as `tikvInstance`. It does not mistake that metric's PD-scraper `instance` or `pod` labels for TiKV identity, and it does not derive mappings from TiFlash, IP, wrong-port, or unrelated metric rows. A live read-only check mapped store `2393604` to its TiKV instance and observed an aligned throttle-duration P99 of about 5.94 seconds in the correct incident window. A local Clinic `query-range` check over the same window returned 14 store-capacity series and reproduced the exact mapping while showing `instance` and `pod` as `pd-sche-server-1`. Local compactor and prompt contract tests pass, and the full repository suite passes 910/910. The tests verify that the Evidence Agent receives this chain, reuses one thread across three total batches, and leaves the Scenario Diagnostic Agent semantic. The first deployed replay, run `5c483bf3-c410-46a6-90e9-3d31a918374a`, exposed one narrower executor defect: the Evidence Agent correctly used `max by (store, address)`, but that Prometheus aggregate removed `__name__` and `type`, so the initial compactor did not emit `tikvStoreMappings`. The Scenario Diagnostic Agent could read the raw address/store rows and improved its answer, but the next Evidence round repeated the mapping instead of consuming a provider-owned dependency and querying exact-store Commit/Prewrite. The follow-up accepts only the exact raw selector or exact two-label aggregate as provenance; unrelated aggregates remain negative regression cases. Post-change read replay `b94a4804-f538-4712-9bf1-a7825f46960a` and write replay `555872f3-6317-44f1-91d9-d786991d9899` both crossed that boundary. The Provider Executor materialized 11 store mappings, including store `2393604` to its primary TiKV instance. The next Evidence round then executed exact-store Commit/Prewrite rate queries and an aligned primary-TiKV scheduler-throttle P99 query instead of repeating topology discovery. The observed throttle P99 averaged about 4.26 seconds and peaked at about 5.94 seconds, material against the reported 8.82--10.85-second write latency; the exact-store histogram query was empty and was not interpreted as absence of latency. The write replay updated the existing Jira internal comment `23371042`. Direct Jira and Service Desk readback returned that same comment body and `public=false`; database run `150093`, evaluation, and the Feishu dashboard write also completed without publication errors. ## Remaining diagnostic boundary This bounded store-localization problem is verified. The replay still cannot uniquely map the observed 60,000-key slow-write workload to `bank_transaction` or prove that `AUTO_RANDOM(5)`, 16 partitions, or the global index caused the incident. That separate workload-to-DDL attribution gap remains visible in the internal handoff and is not suppressed by this record.