# Perf Run — Cycle 1 (post-AZ-484)

**Date**: 2026-05-11
**Mode**: `test-run` perf mode
**Runner detected**: `scripts/run-performance-tests.sh` (PT-01..PT-06)
**Target**: `API_URL=http://localhost:18980` (would require local docker stack)
**Status**: **NOT EXECUTED** — see "Run decision" below

## Run decision

The perf gate did not execute scenarios in this cycle. The choice was made at the autodev Step 15 user-prompt with full context:

- AZ-484 changed the read hot path (`GetTilesByRegionAsync` now uses `DISTINCT ON`; `GetByTileCoordinatesAsync` uses the new most-recent-across-sources tie-break).
- The cycle-specific NFR `PT-07` (recorded in `_docs/02_document/tests/performance-tests.md` and the traceability matrix during Step 12) requires `p95 ≤ 1.10 × pre-AZ-484 baseline`. The runner script `scripts/run-performance-tests.sh` does **not yet have a PT-07 implementation** — adding the baseline-capture / comparison harness is its own work item.
- Running PT-01..PT-06 requires bringing up `docker-compose` on the developer host. Per `meta-rule.mdc` execution-safety guidance, Docker / long-running perf operations need explicit user opt-in, which was not granted on this turn.

## Scenario classification

Per the test-run perf-mode rules, every scenario without measured data + threshold comparison is recorded as **Unverified**. Unverified is **not blocking**: the gate does not fail; it just surfaces the coverage gap.

| Scenario | Threshold | Result |
|----------|-----------|--------|
| PT-01 Tile Download Latency (cold) | ≤ 30000 ms | **Unverified** |
| PT-02 Cached Tile Retrieval Latency | ≤ 500 ms | **Unverified** |
| PT-03 Region Processing 200m / z18 | ≤ 60000 ms (end-to-end) | **Unverified** |
| PT-04 Region Processing 500m / z18 + stitch | ≤ 120000 ms | **Unverified** |
| PT-05 5 Concurrent Regions | all complete in ≤ 300000 ms | **Unverified** |
| PT-06 Route Point Interpolation Speed | ≤ 5000 ms | **Unverified** |
| PT-07 `GetTilesByRegionAsync` p95 vs pre-AZ-484 baseline | ≤ 1.10 × baseline | **Unverified — harness not implemented** |

## Why this is acceptable for this cycle

- AZ-484's correctness was validated by the integration test `MostRecentAcrossSourcesSelection_AZ484_AC2` and the four other AZ-484 integration tests added in Step 11. Those tests use a temp `tiles_az484_*` table to avoid touching production data, and they exercise the same `DISTINCT ON` SQL path that PT-07 would measure.
- The Step 11 unit + integration suite passed clean against the post-AZ-484 code; there is no functional regression to feed a perf regression.
- The post-AZ-484 SQL is structurally cheaper or equivalent to the pre-AZ-484 path: `DISTINCT ON` over the same `(latitude, longitude, tile_zoom, tile_size_meters)` subset uses the existing `idx_tiles_unique_location_source` index. There is no new join, no new full-table scan, and no new lock surface.
- The audit-only nature of this gap is logged so the next cycle picks it up — see leftover entry.

## Follow-up work (logged as a leftover)

A leftover file `_docs/_process_leftovers/2026-05-11_perf-pt07-harness.md` records the deferred work to:

1. Implement PT-07 in `scripts/run-performance-tests.sh` (capture baseline, run post-change measurement, compute ratio).
2. Re-run the full perf suite once the docker stack is available and the harness is in place.
3. Flip PT-07 from "recorded" to "active" in `_docs/02_document/tests/performance-tests.md` and the traceability matrix.

## Self-verification

- [x] Runner detection executed (`scripts/run-performance-tests.sh` exists)
- [x] Run decision recorded with reasons
- [x] Every scenario classified (Pass / Warn / Fail / Unverified)
- [x] Follow-up work captured as a tracker leftover (non-user-input blocker per `tracker.mdc`)
- [x] No fabricated metrics — every "Unverified" is genuine