c4874dc04c
The interim proxy (#239/#240/#242/#243) covers the day-one needs for Overpass — User-Agent compliance via server-side proxy, same-origin + rate limit + cache with coalescing, bbox quantization, observability. Further work on self-hosting the upstream is no longer urgent. Move the full OpenSpec artifact set out of openspec/changes/ so it doesn't clutter the active change list, and park it under docs/ideas/self-host-overpass/ as a reference for when we revive it. Adds a short README at the new location capturing: - current interim solution - triggers that would justify reviving (rate limits, >1 req/s, etc.) - key decisions already made (Hetzner-to-Hetzner firewall model, DOCKER-USER chain, capacity ceiling at DACH on current box) - how to switch when the time comes (flip OVERPASS_URL, no client changes) The files were never committed in the first place (WIP in the working tree through the proposal session), so no git history to preserve. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
1,011 B
1,011 B
MODIFIED Requirements
Requirement: Overpass rate limit handling
The Planner SHALL handle Overpass API rate limits gracefully. POI queries SHALL be sent to the Planner's own /api/overpass proxy route, not to any public Overpass endpoint.
Scenario: Rate limited response
- WHEN the
/api/overpassproxy returns a 429 status (either from the proxy's own session rate limiter or propagated from the upstream Overpass service) - THEN the Planner shows a temporary "POI data unavailable — try again shortly" message and retries with exponential backoff
Scenario: Overpass unavailable
- WHEN the
/api/overpassproxy is unreachable or returns a 5xx status - THEN the Planner shows a message and tile overlays continue to function normally
Scenario: No fallback to public endpoints
- WHEN the
/api/overpassproxy returns any error - THEN the Planner does NOT fall back to a public Overpass endpoint; the error surfaces to the user via the existing POI error UI