[coinmandeer]

Change

A floating Search this area after a map move, place search biased to the view, and one pass over what made the live site slow (/v2/themes median 3.8 s, untuned PostgreSQL without statistics, a 2.4 MB startup bundle, a 367 kB icon font, cold Discover endpoints after each restart).

Search this area

• After a long pan the pin layers deliberately wait to be asked, but the only button that asked was inside the Map status popover, so the map seemed not to load. The button now floats over the map (above a phone's sheet, stacked with Discover's chip, hidden behind a full sheet or the map picker) whenever the view waits for it.
• It counts only layers that wait for it. Loading, partial and failed layers have their own indicators; counting them, and every expensive layer during the 300 ms debounce, made it flicker.
• Pressing it refreshes only out-of-date layers (LayerEngine.searchHere); layers already loaded or loading for the view cost nothing, fresh data is not refetched and tiles are not reattached.
• With the assistant open, the last place search is offered again once the reader moved the map (drag, wheel, keys — MapLibre's originalEvent), and pressing it asks that question for the new view. The answer's own camera fit is not a move.
• A search result, My location or a country asked for data right after starting the flight, so the view being left loaded and the destination waited for the button. The request now waits for the camera to land.
• Settings: the unused "Search this area" switch becomes "Load only on Search this area" (manualRefresh, off): the reader's own moves then load nothing until asked; programmatic jumps still load.
• Place search sends the view centre as near (two decimals, from region zoom); /geocode passes it on as a bias, never a filter (Mapy preferNear, Nominatim viewbox + bounded=0, distance tie-break in the offline gazetteer).
• Removed three unmounted components (Places panel, activity indicator, layer notices).

Backend

• /v2/themes: coverage is shared per zoom band (the zooms where the dataset choice changes) and per view snapped outward to that band's grid, for 15 minutes, with concurrent requests on one query; the join reads only theme datasets; the answer is cacheable for five minutes. The client asks with the same key (statCoverageRequest in @mapos/adapter-sdk), so an ordinary pan asks nothing.
• Theme inventory cached for two minutes; Discover boundary coverage kept per published revision; both catalogues are computed once after the API starts listening (first visitor after a restart waited ~8 s).
• PostgreSQL: JIT off, 512 MB shared buffers, 32 MB work_mem, 256 MB maintenance memory, SSD page cost, 256 MB /dev/shm — sized for the shared 8 GiB host, overridable with POSTGRES_*. The API also sets JIT off and work_mem per connection.
• Imports analyse the tables they rewrote; the deploy analyses tables never analysed or changed by more than a tenth.
• Vector tiles are gzipped by the API (MVT was on neither the plugin's nor the edge proxy's list); the web image precompresses its assets for nginx gzip_static.
• Deploy housekeeping after a healthy rollout: three newest releases and backups (never the live or previous one), six rollback image tags per service, dangling images and week-old build cache. Never fails the release.

Frontend

• Icon font 367 kB → 64 kB: the subset now keeps exactly the 229 icons' glyphs (layout closure had pulled in all 6,186) and the script fails if any name stops forming its ligature. Rendered icons match the old font within anti-aliasing.
• Startup JS one 2.42 MB chunk (706 kB gzip) → four chunks, 2.26 MB (651 kB gzip): React Query removed (unused), @mapos/layer-sdk marked side-effect free (drops the table parser and fflate), satellite.js loaded with its layer, MapLibre's CSP build (its worker already loads separately), and MapLibre, React and the UI kit in their own chunks that stay cached across releases.
• App CSS 225 kB → 194 kB: rules for ~110 classes nothing renders.
• Tile watchers no longer serialise the whole style on each sourcedata event (hundreds per pan); a click reads the layer order once instead of the style three times; pixel ratio capped at 2; store snapshot hooks keep one subscription; repeated loading flags, empty layers and source reports don't notify; a partial answer with a scheduled retry is not asked again.
• The legacy service-worker cleanup runs once per browser.

Measured on vite build: icon font 375,564 → 65,536 bytes; startup JS 2,420,314 bytes in one chunk (706 kB gzip) → index 858 kB + maplibre 970 kB + ui-kit 243 kB + react 194 kB (651 kB gzip); app CSS 295 kB (incl. MapLibre CSS) → 194 kB + 70 kB MapLibre CSS.

Evidence

• Relevant unit and contract tests pass — npm test (layer-sdk 111, adapter-sdk 85, map-runtime 4, API 852, web 590; skips are the existing environment-gated ones), test:contracts, test:privacy (218), test:migrations (37), test:load, test:secrets, test:css-tokens. New unit tests: engine waiting/manual/searchHere, area-query slot, near parsing and bias, TtlCache, coverage snapping, compressible types, tile watcher style reads, store no-op notifications.
• Type, lint and formatting checks pass — npm run typecheck, npm run lint, npm run format:check.
• Integration/E2E, visual, accessibility or load evidence — local runs with the preinstalled Chromium: default suite 220 passed, 1 skipped (the existing MAPOS_LONG_PERF gate), 1 failed before the change dropped below (that spec now 18/18); profiles, run after it, offline 5/5, security 1/1 (production bundle under CSP, so MapLibre's CSP build and worker work), accessibility 8/8, visual 18/18, runtime-starter 2/2, performance 2/2. New e2e: the chip floats without opening anything; a long drag waits and one press loads the new view; a place picked in search loads at the destination without asking; manual mode loads nothing until asked; with the assistant open, a drag offers the last place search and pressing it re-asks it with the new bbox. Walk-through at 1440 px and iPhone 14 Pro size (long pan → chip → load, search "Brno", settings): no page errors.
• No test was presented as run when it was skipped. One change was dropped after the full run: loading a newly enabled layer without the 300 ms debounce fired its first request before the camera settled at startup, so it was cancelled and viewportRefresh.spec.ts:174 failed; with the debounce back the spec passes 18/18.

Layer or provider integration (if applicable)

• Versioned manifest, query/100-feature budget and cancellation — no new layer or provider; searchHere reuses the engine's per-layer cancellation and query keys.
• Loading, empty, partial, error and provider-outage states — unchanged indicators; the chip deliberately no longer reacts to partial/error states, which have their own alert and retry.
• Filters, legend, provider-neutral detail/actions and accessible non-map alternative — the chip is a labelled button with a busy state and a title naming the question it repeats.
• Permissions, private-data boundary, AI exposure and entitlement policy — near is the view centre rounded to ~1 km, sent to our API and on to the geocoder only as a ranking bias; no device location is involved. Re-asking the assistant happens only on an explicit press.
• Fixture/contract tests, health/SLO owner and disable/rollback path — offline gazetteer honours near; manual mode is a setting; caches are in-process and bounded.
• No provider secret or untrusted extension JavaScript reaches the client.

Release safety

• Migration: none. The deploy recreates PostgreSQL once when its settings change (inside the rollback boundary; a failed rollout restores the previous settings). Expect a few seconds of database restart during that deploy.
• Feature flags: none. Rollback of the database settings is removing the command/shm_size block or overriding POSTGRES_*; the chip's manual mode is a user setting.
• Security, privacy, dependency and bundle impact — one runtime dependency removed (@tanstack/react-query); harfbuzzjs and wawoff2 declared as dev dependencies (already installed via subset-font); bundle numbers above.
• Docs: docs/environment.md (PostgreSQL sizing), docs/operations/backup-restore.md (restart, ANALYZE, pruning, restored databases have no statistics), infra/.env.production.example.

Not in this PR: lazy loading of the AJV manifest validator (it backs the synchronous assertLayerManifestV2 contract used by the layer registry — worth its own change), and the PWA service worker (separate PR as agreed).

🤖 Generated with Claude Code

https://claude.ai/code/session_01J3QFugXbaTxPuuP3q3rR16

---

Generated by Claude Code

[coinmandeer]

The deploy check here is the Deploy VPS workflow, triggered manually (workflow_dispatch) at the repository owner's request to deploy this branch — it is not part of this PR's merge gate; check and e2e are green and the head is mergeable.

It failed immediately, before touching the VPS:

##[error]Set the VPS_SSH_KEY or VPS_PASSWORD repository secret.

Neither secret is set on the repository (Settings → Secrets and variables → Actions). This isn't fixable from the PR — no code change addresses a missing secret. Once the owner adds VPS_SSH_KEY (preferred) or VPS_PASSWORD, re-running the workflow against claude/stoic-hopper-jutqgy will deploy it.

---

Generated by Claude Code