# Vela - feature list

Status legend: ✅ done · 🟡 partial / in progress · ⬜ planned

> **At a glance** (jump to a section for the detail). For *how* each of these works and the code
> behind it, see [`docs/HOW-IT-WORKS.md`](docs/HOW-IT-WORKS.md).
>
> | Area | The short version |
> |---|---|
> | [Map & rendering](#map--rendering) | Keyless OpenFreeMap/Protomaps vector tiles, Google-style POI markers, hillshade, in-app light/dark, scale bar |
> | [Search & POIs](#search--pois-live-google-data) | Live keyless Google search - name/rating/reviews/hours/price/website/photos/popular-times/"people also search for" |
> | [Routing & traffic](#routing--traffic) | OSRM turn-by-turn (primary) + Google traffic ETA & jam reroute; alternates; **offline on-device routing** (135-region world catalog) |
> | [Navigation](#navigation) | Maneuver banner with a real lane diagram + highway shields, spoken + haptic guidance, speedometer, re-center, arrival summary; **Android Auto (first cut)** |
> | [Location](#location-degoogled) | AOSP LocationManager + rotation-vector heading - no GMS/Fused |
> | [Offline](#offline) | Downloadable basemap tiles + OSM POI index + **address geocoder (typed address → route, no signal)** + **whole-state place packs (Organic-Maps-style offline search)** + routing graphs + open building-footprint overlay (Microsoft, ODbL); combined map+routing area download; quiet offline indicator (no banner) |
> | [Platform](#platform--distribution) | GrapheneOS/no-GMS, CI-signed nightly + weekly-stable `v0.4.<run>` releases, Obtainium + own F-Droid repo, **in-app updater** |
> | [Resilience](#resilience--maintainability) | Signed remote calibration (pb/paths/JS) + notices - hot-fix drift without an app update |

## Map & rendering
- ✅ **Vela gives memory back when the system asks, and adapts to small phones (2026-07-23,
  adopted from the vela-dpad fork).** The speech model (about a quarter gigabyte while loaded) now
  unloads after two minutes unused and reloads in about a second on the next mic tap; map caches,
  the hidden web fetchers, and the image cache all release under real memory pressure instead of
  forcing the system to kill the app. Low-memory devices additionally skip speculative warm-ups
  and fetch a leaner map POI set, which targets exactly the out-of-memory crashes reported on
  budget tablets.
- ✅ **Voice search says why it failed, and a corrupt speech model can't crash-loop the app
  (2026-07-23, adopted from the vela-dpad fork).** Every voice-search failure now names its cause
  (model missing, mic permission, recorder busy, and so on) in a dialog with a retry, instead of the
  listening sheet silently closing. A corrupt or truncated engine download is quarantined after two
  failed loads and only that engine's files are removed; re-downloading clears the quarantine. Voice
  providers with no label now show their app name in the picker instead of a blank row.
- ✅ **Sheet chrome and landscape fixes (2026-07-23).** Swiping the handle of a place with
  nothing to expand no longer makes the search bar and layers button vanish: they only hide when
  the sheet measurably covers them. Rotating the phone with a place card or results list open now
  resizes it to the new orientation instead of keeping the old height over the search bar, and the
  landscape side panel widens to half the screen (400 to 520dp) instead of a fixed 400dp.
- ✅ **Street-level buildings preload while you idle (2026-07-23).** Zooming down to the ~200 ft
  view used to wait a beat while the building footprints streamed in. When the map sits still for a
  moment at a mid zoom, Vela now quietly fetches the buildings for the area you're looking at in the
  background (disk cache, no extra memory), so the zoom-in paints instantly. Canceled the moment you
  move the map; never runs during navigation.
- ✅ **Settings redesigned hub-and-spoke (2026-07-23, ported from the vela-dpad fork by
  alltechdev).** The single very long Settings page is now a short hub of category rows, each
  opening its own small sub-screen (Appearance / Map / Place pages / Navigation / Voice / Search /
  Offline maps / Saved places / Data & privacy / Diagnostics / About) - far less scrolling on any
  screen, and a keypad phone reaches any section in a few presses. Comes with an **AMOLED black**
  theme option (true-black surfaces) and a **settings search box on the hub**: type a setting's
  name and the match opens the right sub-screen directly. Every mainline setting survived the port
  (the fork's version had dropped Material You, map colors, interface size, POI sizing, parking
  history, lists export/import, the nightly toggle and more - all restored into the new structure).
  Device-verified on the Pixel 4a: hub, search-to-spoke, Appearance/Navigation/Voice/About walks.
- ✅ **Street View from a search result shows the mini map, not the results list (2026-07-18,
  user).** Opening the viewer clears the selected place, and the results sheet - which wins the
  bottom slot whenever nothing else claims it - fell through and drew the POI list over the
  bottom-half mini map. The sheet is now gated while the viewer is up (or loading) and returns
  when it closes. Device-verified on the exact repro path (search, open a result, Street View).
- ✅ **Closing a place from the results list leaves the camera where you are (2026-07-18,
  user).** The map used to forget its cluster framing while a place sheet was open and re-fit
  ALL results on close - a zoom-out yank away from the place you were just looking at. The fit
  is now remembered across a place sheet (and Street View), so closing returns to the list with
  the camera untouched, which is also exactly what the Google app does. The deliberate re-frame
  still fires in its intended case: pan away, collapse the list, pull it back up.
- ✅ **Collapsing the results list no longer snaps the camera to your location (2026-07-18,
  user).** The camera's generic branch fell back to the live GPS fix as a target whenever
  nothing else claimed it, so merely minimizing the results sheet (an inset change) flew the map
  away from the results to wherever the user physically stood, with a zoom snap on top. The live
  fix is now only a fallback target on an EMPTY map - results/markers up means collapsing the
  sheet leaves the camera exactly where it was.
- ✅ **Offline indicator stops crying wolf (2026-07-18, user).** The offline flag latched the
  instant the connectivity callback saw no active network - but WiFi-to-cellular handoffs and
  doze wakes routinely pass through exactly that moment, so the app flashed "Offline" (and gated
  fetches) while genuinely online. Going offline now requires the condition to hold for ~3 s;
  coming back online applies instantly; and any completed live fetch (search or the ambient
  fan-out) heals a stale flag on the spot. A search no longer latches offline at all - it only
  heals, and its own failure path still shows the offline guidance when the network is truly
  down.
- ✅ **The Vela voice is labelled and one tap away (2026-07-18, user).** The fleet-default
  navigation voice (HFC Female today, remote-calibratable) now reads "Vela voice (HFC Female)"
  in the voice browser, and whenever it is not installed - a failed download, a crash
  mid-install, cleared storage - the browser opens with an "Install the Vela voice" button at
  the top instead of making the user hunt the English group for the starred row.
- ✅ **Locate button no longer rubber-bands (2026-07-18, user).** Tapping current-location flew
  to the fix and settled, then the next GPS fix (metres away) re-triggered the generic camera
  branch at a slightly different default zoom - a second flight that read as a lurch or snap
  back. A jitter gate now treats a live-fix target that moved under ~40 m as the same place
  (adopted silently, never flown to), and every browse fly (locate, launch centre, search,
  recenter) lands at the same 15.5 (~1000 ft) - the tap was the lone 15.0 straggler, which is
  why the follow-up flight visibly changed zoom.
  Category searches ("restaurants") used to return exactly one page of 20, ranked by Google's
  keyless web ordering, which is prominence-heavy over the whole visible box - so a modest
  restaurant the user was standing next to ranked 21+ and never listed. Two fixes: (1) a FULL
  first page now triggers pages 2 and 3 concurrently (the same !8i offset pagination the web
  map uses, verified live: each page returns 20 fresh places), one extra round trip for up to
  60 results; specific-name queries return partial pages and never paginate, costing nothing.
  (2) matching places from the ambient pool (the tight-span category fan-out that feeds the map
  dots, which usually already holds the neighbour) are APPENDED to the results, nearest first,
  deduped against Google's list - never reshuffled into it, since the old distance re-rank
  experiment proved that floats junk above landmarks. Zero extra network for the merge. Some budget
  tablets' GL drivers (seen on a Samsung tablet's Android 14 update with a Unisoc chip) kill the
  app the instant the map's GL surface initializes - before the user can reach any setting. Vela
  now marks "map initializing" at surface creation and clears it on the first finished render;
  two consecutive launches dying inside that window automatically switch the map to TextureView
  rendering (a different graphics path that avoids most of these driver bugs, slightly slower)
  and the app just works from then on. Zero configuration, cannot misfire on healthy devices (a
  successful render resets the counter), and Settings → Developer → Compatibility rendering is
  the manual override in both directions. Known-fragile chips skip even the two crashes: Unisoc
  devices ON ANDROID 14 (the reported tablet's family + OS, identified from the hardware string;
  the documented driver faults are specific to the Android 14 builds) default straight into
  compatibility rendering on their first launch. The same silicon on older Android renders fine
  the normal way (car head units run this chip on Android 10 without issue) and is deliberately
  left alone, covered by the crash sentinel like everything else. Verified on-device: two simulated init deaths flip the
  fallback on, the map renders fully through it, and the toggle restores normal rendering; a
  Pixel stays on the normal path untouched.
- ✅ **Browsed areas keep their Google-quality places for weeks, online or offline (2026-07-17,
  user).** The ambient POI layer's disk cache grew into a durable store: the newest 32 browsed
  areas (up to 200 places each, about 1 MB total) persist for 14 days, paint instantly on a cold
  launch, and are served whenever Google cannot answer - an airplane-mode cold start in a town
  you browsed yesterday shows its full POI layer (device-verified). Write-through: being online
  keeps the store current for free (every live fetch overwrites its area) and caching never
  skips a fetch, so nothing gets staler than your last visit. The place sheet's details fetch
  stays the live truth for hours, phone and closed status, and a business it finds permanently
  closed is written back so its dot stays gone across restarts (and a just-closed sheet's pin
  never resurrects a dead place). Offline can no longer poison the store: a no-network fetch
  comes back as an empty SUCCESS (each category request swallows its error), and that empty
  pool used to blank the painted dots and overwrite the cached area with nothing - empty pools
  are now treated as no-answer (keep what is painted, serve the freshest covering area
  regardless of age, retry on the next settle), and blank areas are dropped at load. Groundwork
  for warming a whole city into the store at offline-download time (planned follow-up).
- ✅ **Big map-performance batch, worst-case-device tuned (2026-07-17, user).** A day of profiling
  on a Pixel 4a (the deliberate low-end reference) landed a set of coordinated changes:
  (1) **Buildings draw Google-style by zoom tier** - flat footprints from z16 (~250 ft), 3D
  extrusions from z17 growing to full height by z19, with sides shaded (vertical gradient) so
  same-coloured faces read as discrete buildings; dense-city towers no longer bury the roads at
  500 ft, and the most fragment-expensive layer starts a zoom later. (2) **The Microsoft
  building-footprint overlay auto-hides where OSM already has the area.** A bounded probe
  (12-point coverage sample, at most one run per 1.2 s, only at z16+) reveals the overlay only
  where OSM is genuinely sparse and only after a finished render, so it never flashes over a
  city while tiles stream in; layers are created hidden and earn their reveal. Coverage is
  measured by area, not feature count (tile generalization merges a dense block into a couple of
  giant polygons, which a count misreads as empty). (3) **Settings → Advanced → Fill missing
  buildings** turns the overlay off entirely, and **Settings → Developer → Building overlay
  debug** shows a live badge (overlay state + a UI-thread fps readout) for testing. (4) **POI
  density follows zoom** like Google (a tighter on-screen cap when zoomed out, the full cap when
  close) and the mid-stream repaint batching escalates once the map reads full, so dense arrivals
  re-run symbol placement ~2-3 times instead of ~8. (5) **Search lands at ~1000 ft** (z15.5, same
  as the locate fly-to) instead of z16.5, so searching a dense city arrives on roads+labels+POIs
  with the whole building stack one pinch away - a London search on the 4a settles at ~59 fps.
  (6) **Flock/ALPR cameras hide below z13 while browsing** (they draw with overlap forced, so a
  zoomed-out metro was a wall of badges); a planned route keeps the low floor so route overview
  still shows its cameras. (7) **Street View pauses the ambient fan-out** - panning the mini-map
  no longer scrapes/parses/repaints POIs behind the sphere. (8) **The place you just closed is
  pinned into the next POI repaints** for a couple of minutes, so the icon you tapped can't
  vanish to ranking jitter when the sheet closes. All verified on-device across a dense downtown,
  a college town, a small plains town and a big-city search, plus the standing suburb cases.
  used to blank every ambient icon around it (the layer was gated to the bare map) and closing
  the sheet re-placed the whole layer, then a refetch a beat later reshuffled it again. Now the
  area's icons stay up around the opened place, Google-style (only the opened place's own copy
  hides under the red pin), and a fetch newer than 3 minutes that still covers the view is
  served as-is instead of re-asking Google for the same area (its ranking jitters between
  identical requests, which is what randomly swapped or dropped icons after closing a sheet).
- ✅ **Compass moved clear of the layers button (2026-07-15).** The layers circle sat exactly on
  the compass slot in the top-right corner; with the layers button enabled the compass now sits
  below its touch target.
- ✅ **One-line landscape chrome, Google-style (2026-07-15, user).** In landscape the browse map's
  search bar takes half the width and the category chips scroll beside it on the same line, so
  the top-right stack (layers button, compass) rises a whole row; the stacked portrait layout
  pushed the compass down into the parking and locate buttons on a phone's ~390dp landscape
  height. Focusing the bar grows it to full width in place (the field must not remount or focus
  bounces) and the search page renders full-width below as usual. Portrait is unchanged, and the
  tiny keypad phones the D-pad work targets are portrait devices, so they never see this layout.
- ✅ **Landscape side panel for results and places (2026-07-20, user).** In landscape the search
  results list and the place sheet render as a width-capped LEFT panel (Google's landscape
  treatment) instead of a full-width bottom sheet, so the map keeps a real strip beside them and
  every right-side button (layers, parking, my location) simply stays visible, no situational
  hiding rules. The camera inset moves to the left axis to match: a focused pin or result
  cluster frames in the strip beside the panel. The minimized place card keeps its name, rating
  and action pills (Directions/Call) in landscape too, via a dp floor on the minimized detent
  (0.26 of a ~390dp landscape height only fit the name row). The layers button's overlap gate
  short-circuits in landscape (the panel never reaches its corner); in portrait the locate
  button now rides above a minimized place card's measured top edge instead of hiding.
  Scale bar yields to the panel; the satellite attribution centers in the map strip. The
  panel's EXPANDED detent caps below the search bar (landscape is a two-stop ladder,
  minimized <-> tall): the bar deliberately stays in landscape, so the portrait
  hide-the-bar-when-expanded rule is portrait-only and the panel stops under it instead
  of sliding beneath a bar that keeps taking taps.
- ✅ **Chinese, Chinese (Taiwan) and Japanese (2026-07-11, issue #55).** Vela speaks 14
  languages now. All three layers: UI chrome (values-zh Simplified, values-zh-rTW Traditional
  with Taiwan wording, values-ja), generated turn-by-turn text (three new NavStrings tables;
  Chinese splits by script so Taiwan gets 迴轉/公尺/圓環), localized place content (hl=zh-CN /
  zh-TW / ja with open/closed keyword tables for both scripts), Whisper dictation (multilingual
  model, pinned per language), and a Mandarin neural voice (Huayan) in the voice library that
  pairs with both Chinese scripts. Japanese has no Piper voice yet, so ja guidance speaks
  through any installed system Japanese TTS (the standard fallback); see ROADMAP.
- ✅ **Two map colour sets, remote-defaultable (2026-07-11).** Settings → Appearance → Map
  colors: Modern (the Google-app pixel-sampled palette, the default) or Classic (Vela's
  archived earlier look: white roads, yellow motorways, true greens). The fleet default rides
  the signed calibration channel (`defaultMapPalette`), so it can change without an app
  release; an explicit pick always wins. **Classic's night palette re-differentiated
  (2026-07-12):** Modern's dark was re-sampled to Google's deep navy, which left Classic's old
  blue-grey dark reading almost identical (user: "classic looks bluish like modern, houses too").
  Classic dark is now a NEUTRAL charcoal-slate identity - slate land, GREY buildings (no blue
  houses), muted-amber motorways echoing the classic-light yellow, its true greens and steel-blue
  water kept - so the two dark sets are clearly distinct. **Follow-up (2026-07-12):** the Microsoft
  building-footprint OVERLAY (the layer that fills OSM's gaps) had its colour hardcoded to Modern, so
  in Classic those houses stayed Google-navy while the OSM ones went grey; it now honours the palette
  too. Also, since the two sets currently diverge mostly in dark mode, the Settings hint says so.
- ✅ **Google-style nav puck (2026-07-11).** The navigation arrow is a white chevron inside a
  filled bright-navy circle with a soft drop shadow (no white ring, per user feedback); it rotates
  about the exact GPS point. Replaces the bare blue chevron. **Enlarged twice from feedback
  (2026-07-11/12): 96 → 112 → 136 px** so it reads clearly at a glance while driving.
- ✅ **Bold street names (2026-07-11).** Road-name labels render in the Bold font stack in both
  themes, like Google; other labels keep regular weight.
- ✅ **Bike paths in Google's teal (2026-07-11).** Dedicated cycleways (OSM highway=cycleway)
  draw as their own teal line layer, split out of the green foot-trail network. On-street
  painted lanes are not in the keyless tile schema (Overpass follow-up in ROADMAP).
- ✅ **"1 result" is finally singular (2026-07-11, issue #56).** The results-count bar uses real
  Android plurals in all locales, with the correct plural categories per language (Russian,
  Polish and Ukrainian get their one/few/many forms).
- ✅ **Result filters grew up (2026-07-10).** The rating and price chips open real menus (rating
  tiers 3.5+/4.0+/4.5+ like Google, price levels $ through $$$$) and Sort is a menu of
  Relevance / Rating / Distance, instead of chips that blindly cycled through hidden states. New
  "Wheelchair accessible" filter - the one place attribute Google's response carries per result
  keyless (parsed off the language-neutral attribute id, so it works in all supported languages);
  deeper attribute facets (vegetarian, reservations, …) only exist in the per-place About data,
  so they can't filter a result list keyless. Cuisine facets are deliberately absent: in a
  search-first app the query is the cuisine filter, and Vela's filters are local to the fetched
  results rather than server re-queries.
- ✅ **Privacy comparison matrix in the README (2026-07-11).** A plain-words table under
  Privacy comparing the Google Maps app, Google Maps web, and Vela: account linkage, device
  identifiers, GPS exposure, map-browsing visibility, search anonymity, routing telemetry,
  saved-place storage, ad profiling, and offline capability. PRIVACY.md stays the per-endpoint
  deep dive; the table is the ten-second version.

- ✅ **Urgent pushed notices can be a modal (2026-07-10).** A calibration.json notice with
  level "urgent" renders as a dialog (OK + optional Learn-more link) instead of a map card, for
  announcements that must be seen - the "servers overloaded, hang tight" class of message. Same
  signed channel, same one-time dismissal.
- ✅ **Minimizing the place card fades gracefully (2026-07-10).** The photos and body content
  fade out with the height as the sheet glides down instead of vanishing in one frame at the
  swap, and the compact card (name, stars, action pills) fades in - nothing pops. The header
  circles also became fixed-size plain buttons: the Material button's minimum-touch-target
  machinery kept re-inflating their layout past the visible circle, which is why they overlapped
  through two rounds of shrinking.
- ✅ **The photo viewer goes truly full screen (2026-07-10).** Google's treatment: system bars
  hide while viewing (swipe reveals them), the backdrop is the photo itself blurred and dimmed
  instead of flat black (Android 12+), and the author/date stamp sits bottom-left in every
  orientation. The full-screen reviews page also draws edge to edge so rotation can't leak the
  map through the borders. The photo strip's category chips are gone (the Menu tab replaced
  them), and the header's circled buttons slimmed to 36dp with wider gaps so they never touch.
- ✅ **Restaurant menus get their own tab (2026-07-10).** A place with menu photos shows a Menu
  tab beside Reviews and About: a browsable photo grid, titled with Google's own localized
  gallery-tab name, tapping through to the full-screen viewer. Google's keyless data carries no
  menu LINK (probed: the search payload has none), so photos are the menu surface; making the
  gallery scrape menu-exhaustive is the known follow-up for places where the tagged set is
  partial. The inline review search also folds into a magnifier beside the All-reviews pill  - 
  the stacked text field read as clutter, and the full-screen panel's server-side search stays
  the headline way to dig.
- ✅ **Gallery survives rotation + the save menu (2026-07-10).** The full-screen photo viewer
  draws edge to edge, so rotating to landscape no longer lets the map peek through the system-bar
  strips, and the photo caption's bottom clearance scales with the screen instead of floating to
  the middle in landscape. The place header's star is now the whole save menu (quick save, save
  to a list, edit note, set as home/work), replacing the separate overflow button that crowded
  the circled header.
- ✅ **Place sheet modernization (2026-07-10).** The header's Save/Share/more/close buttons sit in
  Google's subtle grey circles, every pill on the sheet shares the app's stadium shape, the
  reviews summary is Google's block (big number, stars and count stacked beside it, left-aligned)
  instead of a centered strip, the "All reviews" button drops the dated outlined look for the
  sheet's tonal pill language, and the minimized card carries Call and Website beside Directions
  (same gating as the full sheet) so it's useful without re-expanding.
- ✅ **One house number per address (2026-07-10).** The open-address overlay used to print an
  apartment complex's number over its whole footprint (OpenAddresses has a row per unit/parcel);
  the overlay build now collapses those to a single point per address, so each number appears
  once. Takes effect per state as the overlays rebuild.
- ✅ **The full-screen viewers match Google's chrome (2026-07-11).** The photo viewer and the
  full reviews page render in the app's own full-screen window (not a child dialog), so they
  truly reach every edge and survive rotation without the image floating on a shrunken
  background. The status bar stays visible over a gradient at the top, Google-style. The reviews
  page's back arrow became an X (matching the photo viewer, on the left) and swipes down from the
  top to close.

- ✅ **The photo viewer and reviews page reach the true screen edges (2026-07-10).** A window
  dump showed compose dialogs are wrap-content windows measured against inset bounds, so they
  stopped about a status bar short of the display at each end no matter which window flags were
  set; their roots now demand the real display size, which pulls the window out to the edges.

- ✅ **The Menu photos stop including things that were never the menu (2026-07-10).** The gallery
  scrape used to tag whatever was on screen while a category tab was selected, page chrome and
  the previous grid's leftover tiles included. It now snapshots the screen before each tab click
  and tags only what appears after the switch, dwells more than twice as long on menu tabs so
  long menus are walked to the end, and recognizes the menu tab's name in all supported app languages.

- ✅ **Settings reorganized + navigation UI refresh (2026-07-08, user request).** Settings had grown
  disjointed, so the sections now follow how you actually use the app: Appearance, then Map (traffic,
  transit lines, 3D buildings), then a new **Place pages** section (Show reviews, the "Read all reviews"
  button, Load photos), then Navigation, then Voice right after it (voice serves navigation), then
  Offline and the rest. The four stacked vibrate-on-turns switches became one row of chips, one per
  travel mode. And the in-drive UI got a facelift: the maneuver banner and the bottom bar are now
  soft-cornered floating cards with real shadows, a bigger turn glyph, a bolder distance, a heavier
  road name, and filled tonal buttons instead of thin outlined circles. Verified in a simulated drive.
- ✅ **Arrive step names the destination (2026-07-08).** The ARRIVE step in the maneuver banner, the step
  list and the arrival card shows the business name and its address under the "Arrive at your destination"
  line, Google-style. Handles partial data (offline routing often has no business name): name, else the
  address, else the raw coordinates - and no line ever just repeats another (an address search's "name" IS
  its address, so it prints once). `NavSession.destinationDisplay` (pure, unit-tested
  `DestinationDisplayTest`); the address rides `NavSession.State.destinationAddress` → `navDestAddress`.
- ✅ **Zoomed-in pan smoothness (2026-07-08).** Three targeted trims for the "stutters when zoomed right in"
  report: (1) the scale bar no longer recomposes every pan frame - the per-frame camera listener only pushes
  a new value when it changes over 1%, which is when the drawn bar could actually differ; (2) house numbers
  (both the basemap layer and the streamed overlay) no longer occupy the symbol collision index
  (`textIgnorePlacement`) - they still yield to icons and labels, but the densest symbols at street zoom now
  cost the placement pass almost nothing, and a number can never evict a business icon regardless of layer
  order; (3) a new **Settings → Map → 3D buildings** toggle (on by default) controls the z16+
  fill-extrusion layer - extrusion is the most fragment-expensive thing the map draws, so turning it off is
  the one-tap fix on weaker GPUs; the flat footprints stay either way. Localized.
- ✅ **Highlight transit lines (train + subway, 2026-07-07, user request).** Settings → Map → **Highlight transit lines** draws rail on the map in colour, Google-transit-layer style: heavy rail in purple, subway/light-rail/tram in teal. The data is already in the keyless OpenFreeMap basemap tiles (OpenMapTiles `transportation` source-layer, `class` = rail / transit), so this is just a coloured `LineLayer` over the existing tiles, **no new data source, no network** (`ensureTransit` in `VelaMapView`, width zoom-interpolated, inserted below the first symbol layer so station/road labels stay on top). **ON by default (2026-07-07, user call - rail is useful to see and the data's already in the tiles at no cost)**, persisted (`TransitLayer` holder). Device-verified: a metro's light-rail line draws in teal downtown. Removes cleanly when off; no-op on a non-OpenMapTiles basemap (a MapTiler variant / the demo style). Localized in all supported languages. *(Station markers are a possible follow-up; this ships the lines.)*
- ✅ **Terrain shading is a toggle, OFF by default (2026-07-12, user request).** Google doesn't shade
  topography unless you ask, and the hillshade muddied Vela's clean flat basemap, so Settings → Map →
  **Terrain shading** now controls it and it starts off. It was never baked into the tiles - the relief
  is a live `HillshadeLayer` over the keyless terrarium DEM - so this just flips the layer's visibility
  (`Topography` holder, `ensureTopography` in `VelaMapView`, mirrors the transit toggle); off = the DEM
  tiles never fetch. Flip it on for terrain context.
- ✅ **Reviews search circle no longer clips (2026-07-12, user report).** The magnifier button beside
  "All reviews" was an `IconButton` with a 44dp background circle; IconButton forces its own smaller
  box, so the circle overflowed and clipped on the right against the sheet edge. Now a plain sized,
  clipped `Box` draws the circle cleanly.
- ✅ **Build a route between two points on the map ("Choose on map", 2026-07-07, user request).** You could always route from your GPS location to a tapped place, but not pick an arbitrary START (or stop). The origin/stop picker now has a **Choose on map** row: tapping it leaves the search overlay and shows the live map with a **centre crosshair**, a hint banner, and a **Set start / Set stop** button (Google's "Choose on map"). Move the map under the crosshair and confirm, **or long-press** anywhere to set the point directly (both work). The picked point is reverse-geocoded (falls back to a bare pin) and the route recomputes. So a route between two arbitrary points is: long-press a destination, open Directions, tap From, Choose on map, set the start. `MapPick` enum + `pickOnMap` state; `chooseOriginOnMap`/`chooseStopOnMap`/`confirmMapPick`/`cancelChooseOnMap` in the VM; `onMapLongPress` honors the mode; the directions panel / place sheet / top search bar hide while the crosshair is up, and system-back cancels it. Localized in all supported languages.
- ✅ **Camera stays put when you close a place sheet or exit Settings (2026-07-07, reported bug).** Two separate causes. (1) Closing a place sheet dropped the map's bottom inset to 0, which nulled `lastCameraTarget` in `VelaMapView` and let the fall-through camera branch re-center on the now-stale `state.center` (the tapped place) at the zoomed-out browse level, so the map jumped back to the place and zoomed out after you'd panned away. The inset handler now only re-frames when the sheet APPEARS or grows, never when it closes. (2) `VelaRoot` swapped `MapScreen` out for `SettingsScreen`, disposing the remembered MapLibre `MapView`; returning rebuilt the map from scratch and re-seeded it from the stale center at the default zoom. Settings now draws as an opaque overlay ON TOP of a still-composed `MapScreen`, so the map view (and its camera/zoom) survives the round trip. **Follow-on fix (2026-07-07):** because closing a place no longer moves the camera, the ambient POI dots (loaded for the previous centre, and opening a place pans the camera to it) could end up off-screen with nothing to reload them. `clearSelection` now refreshes the ambient POIs for the current view, so they come back when you close a place.
- ✅ **Snaps to you on launch, even after a crash relaunch (2026-07-12, reported bug).** A cold launch centres on your location once GPS resolves, but a **crash relaunch** came back **zoomed to the whole US** - the process restart wipes the in-memory `center`, and MapLibre restored its last (wide) camera before the first fix landed, and the gentle `center = center ?: here` didn't override it. Now a **view-layer one-shot** centres on you the moment the map AND the first fix are both ready (it waits for the fix, however long GPS takes) - running in the view, after MapLibre has restored its camera, so it reliably overrides the stale wide view. Skipped once you've taken the wheel (a pan, or a search/route already owns the camera). One-shot per session. *(An earlier VM-side gate couldn't work: `center` is seeded from the last-known fix at init, so it was never null.)*
- ✅ MapLibre Native vector rendering (Compose-wrapped)
- ✅ Detailed open basemap: bundled OpenFreeMap Liberty + injected house numbers at close zoom; OpenMapTiles vector source pinned to OpenFreeMap's **versioned** tile path (the un-versioned path serves empty tiles - that was a blank-map bug)
- ✅ Route line, **tappable Google-style search-result pins**, location dot as GeoJSON layers
- ✅ Heading-up, tilted navigation camera; fit-route-to-screen on preview; recenter FAB. **Pinch-zoom during nav keeps the follow-camera (2026-06-21):** a pinch keeps tracking your position at the zoom you chose (a dedicated `OnScaleListener` adopts it as an override and suppresses the auto-zoom while you pinch), while a **pan** still detaches to let you look around (`OnMoveListener`) and **Re-center** clears the override back to auto-zoom + follow - telling the two gestures apart, which the move-started reason alone couldn't. *(Fixed 2026-06-21: the override snapped back to auto a beat later because a `navFollowing`-keyed reset fired every time follow re-attached; now the zoom is captured **continuously** during the pinch and cleared only on a **real pan** or at **nav-end** (keyed on `navMode`). And the pan-detach moved from `onMoveBegin` to **`onMove`** - `onMoveBegin` could fire before `onScaleBegin`, so a pinch was misread as a pan and **detached the camera the instant you zoomed**; `onMove` runs after `scaling` is set, so a pinch now **locks your zoom AND keeps tracking** (Google-style) and only a real pan detaches.)* **Predictive framing - tried + REVERTED (2026-06-21):** aiming the camera a little ahead of the puck (to see into turns) inched/stuttered on real GPS even off the smooth `progressM`, and feel-wise the plain **smooth puck-follow** was what worked - so the camera follows `navPuck.drawn` directly. (See-into-turns can return later via in-frame padding that lowers the puck WITHOUT swinging the camera target around.) **De-jittered 2026-06-19** (was re-animating every recomposition → lag/shimmer; throttled to real movement >4 m / turn >2° with a 550 ms ease). **Per-frame follow (2026-06-21):** that throttle still felt *stiff* (the camera re-pointed only ~1–3×/s); the follow-camera now runs in the **motion ticker at 60 fps**, easing toward the smoothed puck point each frame (~0.12 s) for a continuous glide - seeded from the live camera on (re)attach so the hand-off from the pre-engage framing / a Re-center is smooth. The old throttled block is kept only for the pre-engage / off-route case. *(Feel change - confirm on a real drive; revertible.)* With **speed-adaptive zoom** (Google-style: pulls back on the freeway to see ahead, tightens on city streets - **continuous + low-passed** since 2026-06-21: hard speed-band thresholds made the zoom ping-pong ("zooms in and back") whenever speed hovered near a boundary in stop-and-go, so it's a smoothly interpolated zoom over a damped speed now). **2026-06-21:** during nav it now follows the **smoothed motion-model puck point** (see the location-indicator entry below) rather than the raw GPS fix, so the view can't lurch to a far spot when the snap is briefly ambiguous
- ✅ **Traversed route greys out** behind the vehicle (Google-style) - a line-progress gradient on the route (grey for the part driven, live traffic ahead). **During nav the route line carries traffic per segment, not the whole map** (2026-06-19 per feedback - the `/maps/vt` whole-map overlay no longer auto-shows when navigating; it washed every road, and the ask was traffic on "just the road we're on"). The route line is now coloured **per segment** like Google - free-flow blue with amber/red bands over the congested stretches (from `route[3][5][0]` in the directions response; see "Routing & traffic"). The manual traffic toggle still paints the full map when you want it. Nav-overlay polish: speedometer + recenter lifted clear of the bottom bar, recenter is now an icon-only FAB tucked bottom-right. **Maneuver-banner swipe fixed** - `pointerInput(Unit)` had captured a stale step index so every swipe repeated one card; `rememberUpdatedState` makes each swipe walk to the next/prev step
- ✅ Compass kept clear of the status bar (inset-aware margins)
- ✅ Tap a labelled POI **or a search-result pin** to open it; camera frames all results after a search. Tapping a POI also reads `name:latin`/`name:en` (not just `name`), and an **unnamed** POI icon (an apartment gym, an unnamed park/playground) **reverse-geocodes to a pin + address** instead of being a dead tap. When several Google listings share the same spot (e.g. a co-branded "SpeeDee Midas" with a sparse **Midas** *and* a rich **SpeeDee** profile), the tap now opens the **most-reviewed = canonical** one rather than whichever happens to be a few feet nearer
- ✅ Bottom sheets (place sheet, steps) **fill to the screen edge** - content is padded off the gesture/nav bar, but the sheet background no longer stops short and lets the map peek through at the very bottom
- ✅ **Tap a house number or a building to open its address (2026-07-08, user request).** A single tap on a **house-number label** (the map's own `addr:housenumber` or the streamed address overlay) opens a pin + place sheet **snapped to that exact number** - tapping a numbered label opens exactly that house number, not a neighbour's. This matters because Google's reverse-geocode snaps to the nearest addressable point and routinely returns a different house (device: the raw geocode of a tapped label came back a few doors off); so the tap LEADS with the number on the label and uses the geocode only for the street/city. A tap on a plain **building footprint** (no number showing) reverse-geocodes the building to its address the same way. A real business on that spot still opens as the business. Empty land has no footprint, so a tap there does nothing and only a **long-press** drops a raw pin (below). Device-verified in a residential suburb (a tapped number opened exactly that house; a bare footprint reverse-geocoded to its own address)
- ✅ **Long-press the map** → drop a pin, reverse-geocode it to an address (Nominatim/OSM, keyless), then get Directions - works even where no building is drawn. When the point **doesn't snap to a street address** (a bare road, open land, or a failed geocode) the sheet surfaces the **lat/lng coordinates prominently** (a `MyLocation`-iconed row, tappable to copy) beside the road name we already show - Google-style. A house-numbered snap ("1020 Olive Dr") or a real business POI shows its address instead, so no clutter; the snap is detected by the name's first token being a pure-digit house number (a numbered street like "120th St" keeps its "th", so it reads as unsnapped → coordinates)
- ✅ Keyless **OpenFreeMap Liberty** basemap (active, loaded by URL - the setup that renders on-device, no key): **Google-style POI markers + category-coloured labels**, a **clean Google-style road treatment** - white road fills on light-grey land with the **casings faded out** (minor-road casing == the land, so streets are crisp white lines with **no outline**), soft-yellow motorways, **neutralised landuse** (no tan residential/commercial blobs), and **flattened fill-patterns** (Liberty's fern-hatch wetlands + dotted pedestrian plazas → flat fills, like Google) - plus light/dark recolour, all at **runtime** (tuned live in a MapLibre GL JS harness against Google, on-device-verified light + dark)
- 🟡 **MapTiler Streets** path stays wired but off (`USE_MAPTILER=true` to enable, needs the key). Map labels render in **Roboto** via self-hosted glyphs (Roboto composited over Noto per glyph, `ui/map/MapFonts` + `scripts/build-map-fonts.sh`; probe-and-fallback to plain Noto, so the old bundled-style dead end is retired - the blank basemap was its pinned dated tile path, not `fromJson`)
- ✅ **First-run welcome** - a clean branded intro (no tracking / real places & routes / free & open source) with a single "Get started"; shown once
- ✅ **Tasteful donation** - a permanent "Support Vela" entry in Settings, plus a **one-time** prompt that appears only **after a week** of use ("entirely optional, and this is the only time it'll ask"), trivially dismissed, never blocking. (`Onboarding` holder; `DONATE_URL` points at the project's Buy Me a Coffee page, and `.github/FUNDING.yml` puts the same link behind the repo's Sponsor button; forks point both at their own page). Both the Settings entry and the prompt route through `Onboarding.openDonate`, which shows a toast if **no browser is installed** to open the link (a stripped/degoogled ROM often has none) instead of a silent dead tap.
- ✅ **In-app Light / Dark / Follow-system switch** (Settings → Appearance) - sets Vela's theme **independently of the phone**, so you can run the app dark without flipping the whole OS (the whole app + the map recolour live off one preference, `AppTheme`/`isAppInDarkTheme`; persisted). Dark mode recolours **every** landuse/landcover fill (commercial, school, retail, …), not just a hardcoded few, so no light/cream patches break the night palette (verified on-device)
- ✅ **Google-style POI markers** - category-coloured circles with white Material Icons glyphs (food=orange, shop=blue, park=green, health=red, transit=blue, …), generated at runtime over a bundled Material Icons font, sized to read like Google's (`iconSize` 0.8); in light mode the POI **label text is coloured by category too** (like Google). **Density tuned for parity:** Liberty's always-on `poi_transit` layer (bus stops at every zoom = clutter) is pushed to **z16+** like Google, while the next business tier (`poi_r7`) is pulled down to **z15** so more shops/restaurants show; MapLibre's label collision keeps it tidy. **Nameless POIs are filtered out** (`has("name")` AND-ed onto each poi layer's rank filter) - the unnamed icons couldn't be opened anyway (they'd just drop a near-by address pin) and read as duplicate junk, so only labelled, tappable POIs render now. **Ranked by prominence, not tile order (2026-07-02):** when two OSM POIs collide, each poi layer sets `symbol-sort-key = rank` (the tile's prominence field, lower wins the slot). *(But the map's business POIs are Google's, not OSM's - see below; this only affects the OSM fallback when Google POIs aren't showing.)* **Marker restyle - grey teardrop pin + left-aligned labels, no white ring (2026-07-04).** The markers dropped the flat **white outline ring** and now sit in front of a **muted-grey TEARDROP/pin backing** (Google grey `#9AA0A6`) - a rounded body whose point extends below the coloured dot, with a **soft drop shadow** - so each reads like a Google pin (`PoiIcons.marker` redraw: a `Path` teardrop = body circle unioned with a tangent-sided triangle to the tip + `BlurMaskFilter` shadow; the coloured dot is the bitmap centre so the layer's default centre-anchor keeps the dot on the place, no placement shift). And the **label now sits to the LEFT of the icon** (Google-style) instead of under it - `textAnchor` RIGHT + a negative em `textOffset` (scales with the prominence-driven text size so it clears the dot across sizes), applied to both the ambient Google POI layer (`VelaMapView`) and the OSM `poi_r*`/`poi_transit` fallback layers (`PoiIcons.applyToLiberty`). Device-verified on a Pixel 5a in **both** themes: white ring gone, blue/orange/grey dots pop on the grey teardrop, labels clear to the left. **Labels are UPRIGHT everywhere (2026-07-06).** Liberty's default POI text face is **Noto Sans *Italic***, so while ambient Google POIs (which pin `Noto Sans Regular`) show upright, the moment ambient cleared - a search, a selected place, nav - the OSM `poi_r*`/`poi_transit` labels slanted, an "everything goes italic mid-search" flip. `applyToLiberty` now pins **`Noto Sans Regular`** on those layers too, matching the ambient layer and Google (whose labels are upright in every state).
- ✅ **Building footprints + house numbers, Google-style (2026-07-04).** Residential/building outlines read sparse because of a **real bug**: the bundled Liberty `building` FILL layer is `minzoom 13 / maxzoom 14`, and MapLibre `maxzoom` is **exclusive**, so the code's `setMinZoom(14f)` collapsed its range to empty (`14 ≤ z < 14`) - the crisp flat footprints **never painted**, leaving only the faint `building-3d` extrusion (the "sparse vs Google" look). Fixed by re-opening the top with **`setMaxZoom(24f)`** on the `building` layer in both `applyLight`/`applyDark`, so flat grey footprints with a crisp darker outline draw from ~z14 up (overzoomed z14 tiles fill z15+); `building-3d` extrusions are now **gated to z16+** (flat fill carries the browse-zoom look; extrusion is the per-pixel-expensive part on a Pixel 5a). **House numbers**: the `vela-housenumber` layer (OMT `housenumber` source-layer) is **confirmed functional** - OpenFreeMap really does serve that layer (verified against the live TileJSON + z14 tiles), so it renders where OSM has `addr:housenumber`; `minZoom` lowered 17→**16** to surface them a touch earlier. **Device-verified on a Pixel 5a:** a dense downtown renders full building footprints + house numbers at z16+. **Coverage caveat (OSM, not the renderer):** footprints are near-complete in US/EU metros but sparse in some newer suburbs, and `addr:housenumber` is patchy - Vela renders whatever OSM has, so a thinly-mapped neighbourhood still looks bare (that's an OSM data gap, not a Vela bug).
- ✅ **Traffic lights + stop signs on the map (2026-07-05).** OSM `highway=traffic_signals` draw as a small stoplight icon and `highway=stop` as a red **STOP** octagon, beneath the POI dots + pins, at close zoom (z ≥ 16). Zoom-scaled icon size + draw-all (allowOverlap, 2026-07-06) so they’re actually visible on the browse map, not culled by the denser POI layer. Keyless (Overpass), fetched per-viewport but **area-cached** - the fetch box is padded 50% beyond the view and reused while you stay inside it, so panning/driving through a neighbourhood doesn't re-hit the server.  Zoom-gated (no setting); shows in both browse and nav.
- ✅ **Camera facing cones (2026-07-21, user request).** Flock units are single-direction, so
  every direction-tagged DeFlock node (93% of the dataset) now fans a translucent purple cone
  showing which way the camera FACES, DeFlock's own treatment - the OSM `direction` /
  `camera:direction` tag rides the dataset as a 4th TSV column (cardinals normalized to
  degrees at bake; 3-column files still decode, so old bundled/hosted data keeps working).
  The avoid-cameras route count deliberately stays proximity-based: ALPRs commonly capture
  front AND rear plates, so a camera near the route can read you whichever way it points -
  the cone is information for your eyes, not a reason to relax the count.
- ✅ **Surveillance-camera (Flock / ALPR) layer (2026-07-12, user request).** Settings > Map > **Surveillance cameras** draws mapped automated licence-plate readers on the map - the community **DeFlock** project's `surveillance:type=ALPR` nodes in OpenStreetMap (Flock Safety, Motorola, police plate readers) - as a distinct purple camera badge, visible from route-overview zoom (z11+, 2026-07-13; both the fetch gate and the render layer - an earlier pass lowered only the fetch, so cameras arrived but never drew below z13.5, a gap the vela-dpad fork caught in issue #131). The dataset is **bundled on-device** (the whole global DeFlock set is ~1.3 MB) and **refreshes itself weekly** from a hosted copy, so the layer draws instantly with no network and stays current without app updates; live Overpass remains only a brief startup fallback. **ON by default since 2026-07-13** (`Flock` holder) - it costs nothing to draw now and it's a headline feature; turn it off in Settings > Map if you don't want it. Coverage is OSM's/DeFlock's - strong across the US, growing elsewhere. **Avoid surveillance cameras (2026-07-12, opt-in):** a SEPARATE Settings > Map toggle ("Avoid surveillance cameras", OFF by default, `FlockRouteAlert`) that both **warns and avoids**. It badges each route option with **how many mapped cameras it passes** (amber camera glyph + "N cameras on this route") AND **auto-prefers the fewest-camera alternate** - but only for a MODEST detour (`selectRoute` the min-camera route when it beats the fastest on cameras and costs at most **25% / 10 min** more; a "Rerouted to avoid cameras" toast explains the switch). That cap is where the line is drawn: a small detour to dodge cameras, never an hour around one on a 15-minute trip - and it only chooses among the alternates Google already returns (no impossible "avoid this whole region" routing). Long-press "route through here" stays as the manual override for a specific detour. Keyless: `OverpassAlprCameras.fetchAlong` counts the ALPR nodes within ~120 m of each route's polyline (reusing the `out body` fetch), off the hot path. **Device-verified: routing through a camera-dense corridor badged the fastest route "18 cameras" and auto-switched to the +1 min, 0-camera alternate.** Kept independent of the map layer on purpose (you might want one without the other). **Device-verified 2026-07-12 in Atlanta** (Ponce City Market): the purple camera badges draw on the map. Two bugs were caught and fixed in that verification: the Overpass query used `out tags`, which for a node returns id + tags but **no lat/lon**, so the parser dropped every camera and the layer was always empty - now `out body`; and `Flock.init` was missing from `VelaApp`, so the toggle **reset to off on every app restart** (the persisted pref was never loaded) - now initialised alongside the other layer holders. *(Tap-for-detail on a camera and an approach chime are possible follow-ups; this ships the map layer.)*
- ✅ **Map POIs are Google-ranked by real prominence, not OSM (2026-07-02).** The map's business POIs come from **ambient Google places** (`nearbyPlaces` - an 8-term category fan-out over the viewport), and OSM's `poi_r1/r7/r20` are hidden while those show. The bug: the ambient dots collided at the same building (a Safeway and a tiny sushi counter inside it), and the winner was decided by the fan-out's **category-term order** ("restaurants" queried before "stores"), so the sushi place outranked the Safeway. Fixed by ranking the deduped Google places by **real prominence** - `ambientProminence = ln(reviewCount+1) · (0.6 + rating/10)` (review count dominates, rating nudges) - so the anchor store (Safeway, ~1,300 reviews) beats its in-store tenant (dozens), and the map's top POIs are recognizable landmarks (device-measured: the regional mall, the big grocery anchors, Trader Joe's, Walmart…) instead of the 0-review junk the fan-out drags in (a mobile mechanic, a care home, a road intersection). **A distance-bucketed variant was tried and reverted** - it floated near-centre junk above the landmarks (caught by an on-device log). Pure prominence, exact distance only as a tiebreak. Unit-tested (`AmbientRankingTest`); `rankAmbientPlaces`/`ambientProminence` are pure `:core` functions. **Deeper + broader + zoom-scaled (2026-07-02):** three coordinated levers make the map fill with businesses like Google's. (1) **Broader categories** - the fan-out gained `grocery store / gas station / gym / bar / pharmacy` (13 terms) so the map shows a real MIX, not just food/shops. (2) **Deeper pool** - `!7i40 → !7i60` per term took the candidate pool from ~150 to **~690** (device-measured) so there's rank to descend into. (3) **Hand the map ALL of them, let collision do the zoom-scaling** - an early cut (`take(80)` → a zoom-scaled `take(260)`) turned out to be the "seeing fewer results" bug: over the ~3.5 km fetch span the deep pool's far, more-prominent places filled a small cap, so a low-commercial view's own nearby shops were cut *before the map could try to draw them* (device-caught: a residential viewport handed 260 POIs rendered **zero**, all in the commercial cores off-screen). Now the map is handed the POIs **near the view** (a `viewRadius × 1.25` filter, `AMBIENT_ONSCREEN_CAP = 140` by prominence) instead of the whole 3.5 km pool - because off-screen POIs can't render anyway, and MapLibre re-runs symbol collision over *every* handed feature each drag frame. So nearby businesses (incl. the welcome low-signal ones - care homes, a floral counter, a local LLC) render, **more appear as you zoom in** (dots spread out, fewer collide), and a low-commercial view keeps all its handful of local shops (under the cap → nothing cut, the "fewer results" fix stays). Low-signal can't crowd out a business (prominence order places real ones first; low-signal fills leftover collision gaps). **Perf:** the first cut handed the *whole* pool (~800) and a Pixel 5a lagged dragging - the collider was chewing 800 symbols/frame; view-filter + cap brought it to **1.38 % janky frames, 90th-percentile 15 ms** on the same 5a, with identical on-screen density (device-verified `gfxinfo` + screenshot). *(Keyless ceiling: the viewport query floors at a ~3.5 km span - Google's `tbm=map` returns FEWER hits for a tighter box - so a hyper-dense downtown at max zoom is still bounded by what one span returns; fine for the common case.)* **Prominence sizing + smoother panning (2026-07-03):** four more Google-like touches. (1) **Anchors read bigger + show from farther** - each ambient dot now carries its prominence to the layer (`MapMarker.prominence`), driving a **data-driven `iconSize` (~0.78 for low-signal → ~1.3 for a Safeway/mall) and `textSize` (11→14pt)** via MapLibre `interpolate` expressions (zero per-frame CPU), plus a **prominence-weighted keep-radius** (`viewRadius × (1.25 … 1.6)`) so a high-prominence anchor survives off-centre and appears at the edge like Google does at 500 ft. Doubles as "bigger POI icons". (2) **Smoother drag on the 5a** - `applyData` was re-`setGeoJson`-ing (a full symbol re-tessellation) on *every* recomposition (a nav mySpeed tick, a mute/theme toggle); now it **short-circuits when the marker/ambient lists are unchanged** (structural equality, reset on style reload). With a lighter halo (1.2→0.9) + icon-padding (3→1.5), drag jank on the Pixel 5a went **1.38 % → 0.47 % janky frames (90th-pct 15 → 10 ms)**.
- ✅ **Nav starts instantly again (2026-07-17).** Tapping Start could sit dead for up to ~20 s
  before "Starting navigation," and double-tapping announced it more than once. Cause: making
  traffic-light guidance standard put a live Overpass fetch (up to a 25 s server timeout, over
  the whole route) on the critical path BEFORE the session started - a regression. Nav now starts
  immediately on the plain route and the "pass the light, then turn" clauses fold in a beat later
  in the background (same geometry, only turn text changes), or are skipped if the fetch is slow -
  they're best-effort landmark text, never worth blocking the drive. Start is also guarded against
  re-entry, so a double-tap can't queue a second start.
- ✅ **Rerouting spins (2026-07-17).** The banner's refresh glyph rotates while a reroute fetch is
  in flight - the state was already loud (chime, buzz, "Rerouting" headline, bottom-bar tag) but
  nothing MOVED, so a slow fetch could read as frozen. Draw-phase animation (the angle is read in
  graphicsLayer), so the spinner never recomposes the banner and only exists while rerouting shows.
- ✅ **Route swaps record WHY (2026-07-17).** Every route block in a trip now carries its reason -
  "start", "reroute" (a wrong turn), "faster" (you accepted the faster-route offer), "heal" (the
  silent abbreviated-steps/traffic self-heal), "stop-added" - stamped at the session's swap sites
  and appended to the RD line (old files and parsers unaffected). Replays use it: only wrong-turn
  reroutes chime now; swaps that were quiet live stay quiet in replay. The audit prints each swap
  with its reason and fix index.
- ✅ **Replays chime at route swaps (2026-07-17).** The rerouting earcon now plays at a recorded
  trip's swap points during replay - replay is the nav test bench, and the chime is the audible
  marker that the route changed here. (Live reroutes were already chiming; replays suppressed
  the whole live-reroute path by design, so swaps were silent. Caveat: the trip format doesn't
  distinguish a wrong-turn reroute from a silent faster-route adoption, so replay chimes for
  both - a marker, not a re-enactment.)
- ✅ **Car-mode strips neighbourhood titles; water names stay (2026-07-17).** Hamlet and
  neighbourhood labels joined the drive-nav declutter list (the read-by-nobody tier). WATER
  names were briefly stripped too and restored the same day: rivers and lakes are real
  landmarks, the user liked them, Google keeps major water names in nav, and a viewport carries
  a handful at most - the saving was noise. Town, city and state names stay for orientation.
  Walking and biking keep everything, as before.
- ✅ **Thick-liquid nav camera (2026-07-17).** The follow camera's single fast ease (0.12 s on
  everything) made every road kink a camera rotation within a third of a second - the "squirrely"
  feel. The time constants are split now, Google's grammar: position stays fairly tight (0.25 s -
  the puck draws at its own point, so camera lag reads as glide, not error) while bearing (0.55 s)
  and zoom (0.5 s) get heavy damping - turns sweep around over about a second, the zoom breathes,
  and the puck's own bearing filter thickened a step so vertex-level polyline jitter never reaches
  the glass.
- ✅ **Trips are a flight recorder now (2026-07-17).** Beyond the GPS trace, route segments,
  off-route flag and build stamp, a recorded trip now carries: **every line the voice actually
  spoke** with timestamps (voice-vs-card questions answer themselves), **per-fix GPS accuracy**
  (the accuracy-scaled corridor's decisions become reconstructable), **30 s frame-pacing
  samples** during nav (UI-thread Choreographer cadence: frames, janky count, worst gap - "it
  felt laggy around the exit" becomes a number), and **battery every ~2 min** (drain per drive is
  measurable). All appended formats: old files and old parsers are unaffected, and the audit
  harness prints each section. Strictly local and opt-in as always - trips never leave the phone
  unless shared by hand.
- ✅ **Label pass de-hitched + the off-route flag is recorded (2026-07-17).** The cross-street
  pass was itself the "camera dropping frames" report: it materialized every loaded road-name
  feature on the main thread every 4 s and re-ran symbol placement whenever its sliding window
  moved a name in or out. It now snaps to 400 m quanta of progress - the whole pass (query,
  geometry, filter) runs once per quantum or when the upcoming turn targets change, the query
  carries a class filter so far fewer features are materialized, and the include set is
  byte-stable between quanta so placement stops churning. And recorded trips now carry the
  engine's LIVE off-route flag per fix (appended column, old files unaffected); the audit prints
  the off-route spans - a wrong-turn report is now diagnosable fix by fix.
- ✅ **"tacake" fixed + trips record their build (2026-07-17).** "Take exit 186" speaks as "take
  the 186 exit" - the espeak G2P mangles the bare take-exit adjacency the same way the old
  take/tyke bug did, and "take the" is the onset it reliably gets right (display text untouched).
  Recorded trips now stamp the versionCode that recorded them into the CSV header (appended
  column, old files and old parsers unaffected) and the audit harness prints it - so a "which
  build said that" question answers itself. Reroutes were ALREADY captured: every route the
  drive used (start + each reroute or faster-route swap) is its own segment in the trip file,
  activated at the fix where it appeared.
- ✅ **"Half a mile", and the turn target keeps its name (2026-07-17).** Sub-mile spoken distances
  phrase as fractions - "In half a mile", "In a quarter mile" - instead of "zero point five
  miles" (quarter-mile granularity below a mile, exactly Google's grammar; the banner keeps the
  precise figure, metric users already heard natural "500 meters", and other languages keep
  their own tables until they adopt the fraction forms). And the cross-street label pass got two
  correctness fixes: the exclusion list is per-step now (roads already DRIVEN), because excluding
  the whole route hid exactly the label that matters most - the road you are about to turn onto;
  the next two turns' target roads are force-included (a turn target meets the route at a shared
  junction vertex, which a proper-crossing test can miss); and the crossing window tightened to
  150 m behind / 2 km ahead so callouts hug the road you are on.
- ✅ **Nav labels: true cross-streets only + a steadier puck (2026-07-17).** The label bubbles now
  show ONLY streets whose geometry actually CROSSES the route ahead: every ~4 s a background pass
  takes the loaded road-name features and intersects them with the route window (300 m behind to
  4 km ahead), and the layers' filter tightens to that include-list. Parallel streets and
  near-misses stop getting callouts, and the "ghosts" stop too - the include set only changes as
  the drive progresses, so labels stop churning through the renderer's placement fade (also
  strictly fewer symbols per frame). Verified on a simulated drive: one bubble on screen, the
  cross street ahead. And REPLAYS stop feeding the phone's LIVE accelerometer into the puck's
  speed model - a handset on a desk fed sensor noise into the Kalman while a trace played, which
  was the "jittering very slightly all over" (real drives keep the fusion; replays dead-reckon on
  recorded speeds alone).
- ✅ **Street View works by D-pad (2026-07-17, from ars18's vela-dpad fork).** The panorama gets
  the fork's engage model: focused, OK engages look-around - arrows pan the sphere, +/- zooms
  (the same clamps as pinch), OK again WALKS forward when a neighbour pano sits within the
  facing arc, BACK disengages then closes. Arrows/controls join a predictable focus ring
  (pano -> close -> fullscreen -> time travel) since the overlaid controls defeat spatial focus
  movement, walk chevrons and the time-travel chips wear the dpadHighlight ring. Every key path
  calls the same code the touch gestures use (docs/dpad.md rule 3). Verified on-device with real
  key events: engage, pan, walk; touch behaviour byte-identical.
- ✅ **Baseline profile - nightlies install pre-warmed (2026-07-17).** Sideloaded installs get no
  Play cloud profiles, so every nightly ran interpreter-cold until overnight background dexopt -
  the "even Settings scrolls laggy, did you R8?" report (the APK was fine; the phone just hadn't
  recompiled it yet). Now a committed baseline profile (generated by the `:baselineprofile`
  macrobenchmark module on a headless emulator: cold start, map pan/fling, list scroll) is baked
  into every release build and `androidx.profileinstaller` AOT-compiles those paths at INSTALL
  time - a fresh nightly is fast from the first launch. A monthly GitHub workflow regenerates the
  profile on an emulator and opens a PR when it drifts. Generation must NEVER run against a
  connected phone: the test harness uninstalls the target app when it finishes.
- ✅ **Drive-feedback batch 4 (2026-07-17).** The persistent current-road shield **moved to the TOP
  nav card** (right of the distance; skipped when the maneuver's own chips already show that
  route). **Bare state refs chip now**: "NV 28" style spaced two-letter refs render as stylized
  badges (the pattern only knew the hyphen form; kept case-sensitive so "on 5" can't become a
  shield). **A rerouting chime**: a soft two-note earcon plays when a wrong turn triggers a
  reroute, before the spoken word - synthesized in-process on the guidance audio stream, silent
  when guidance is muted. **The road you're driving never labels itself**: the bubble layers
  exclude the route's own road names and refs (the highway used to call itself out repeatedly
  along a drive); only streets you cross get callouts, which is also fewer symbols per frame.
  **The car-mode declutter is now DRIVE-only**: walking and biking keep bike/trail accents, house
  numbers, hillshade, transit lines and the full POI mix - only the car strips them. Verified on
  a simulated highway drive: top-card shield, exit + interstate chips, no self-labels.
- ✅ **Drive-feedback batch 3 (2026-07-17).** **The road you're ON shows as its stylized shield in
  the bottom nav bar** for the whole stretch, not only when a maneuver mentions it ("the actual
  state route/interstate should always have the stylized version"). **Voice repeats are trimmed**:
  a step's second and third prompts drop the sign-destination tail ("Take the ramp on the right",
  not the whole sign again) and a MERGE announces once on approach - getting on a freeway used to
  narrate the same road in declining counts three or four times. **Nav strips more browse dressing
  for battery** (the phone-barely-charging report): basemap highway badges (the wall of shields,
  including the other direction's), bike-path and trail accents, transit lines, hillshade, 3D
  building extrusions and the address-overlay numbers all hide while navigating and return when
  the drive ends; the address-overlay viewport refresh pauses too. **Label bubbles got more
  contrast** in dark mode. Unit-tested (merge single-prompt, repeat-shortening). **And the
  cross-street tier FADES with zoom (2026-07-17)** instead of popping: the nav camera's zoom is
  speed-scaled, so the old hard cut made every minor-street bubble appear or vanish at once as
  speed crossed the boundary - now they ease in over half a zoom level, and only at genuinely
  slow speeds (Google shows that tier only when zoomed further than nav feasibly sits). Thinned
  further same day: tertiary roads ride the slow tier too, and bigger collision padding spaces
  the survivors out - fewer symbols per frame. And the VOICE speaks only the primary sign
  destination ("toward I 5 North", not the whole "...: Vancouver British Columbia" sign) - the
  full sign stayed long enough in the mouth that the next prompt cut it off mid-sentence. **The
  card matches (2026-07-17, user-agreed design):** the banner HEADLINE is the same spoken form -
  card and voice can never disagree - with the sign's secondary cities on a dim one-liner below
  it for confirming against the physical sign; the compound "then" row uses the short form (its
  chip already names the route), ending its arbitrary mid-sign ellipsis.
- ✅ **Drive-feedback batch 2 (2026-07-17).** During nav the map now shows **gas stations only** -
  the one POI class worth a glance mid-drive; everything else hid (the full POI layer over the route
  read as clutter). **Pinch-zooming no longer detaches the free-drive follow**: zooming while the
  camera tracks you keeps tracking, just at your zoom - only a genuine pan looks away (the same
  pan-vs-pinch split nav already made). **Turns announce earlier on the open road** (~35 s out, was
  ~25 s; a real-drive A/B had Google calling turns up to 0.2 mi sooner at highway speed - city and
  walking prompts unchanged). And **traffic-light landmark guidance is standard now** ("pass the
  light, then turn right"): the Advanced toggle is gone - when a turn is ambiguous, the light is the
  landmark, exactly when Google narrates it. Still conservative (1-2 lights, plain surface-street
  turns only) and English-only for now.
- ✅ **Drive-feedback batch (2026-07-16).** Every drive starts **heading-up** (the compass toggle is
  per-drive now - a north-up pick used to stick for the whole app session). **Floating road labels**
  during nav: horizontal, viewport-aligned street names hover over the roads you cross - legible even
  with the camera tilted, like Google's callouts (device-verified on a simulated drive). **Reworked
  2026-07-17 after the first real drive:** each name now sits in a real Google-style BUBBLE (rounded
  chip with a pointer tail touching its road, theme-matched, drawn via a stretchable style image +
  icon-text-fit so any name length fits), residential cross streets are back (the first cut dropped
  the "minor" road class for sparseness, which muted the layer on neighbourhood drives - minors now
  show from z16, i.e. at surface-street speeds, and stay out of the highway view), and the basemap's
  own line-following road names hide during nav so nothing draws twice (placement work saved every
  frame). Device-verified on a simulated drive: bubbles with tails on the cross streets, no doubles. **Basemap POIs
  stay visible while navigating** (gas stations on the way; the master Show-places switch still wins;
  narrowed to gas stations ONLY on 2026-07-17 - the rest read as clutter over the route).
  **Returning to the app mid-drive re-centres automatically** - a stray pan while backgrounding used to
  leave the camera detached until a manual tap. And **ramp instructions say which side**: "Take the
  ramp on the right toward X" instead of just "Take the ramp" (all 15 languages; the banner arrow
  already pointed the right way, now the words match). A shared onramp whose sign lists BOTH
  directions of the target highway ("99 North, 99 South") now announces only the branch you take -
  the folded fork disambiguates the destination, and its lane diagram survives the fold. Highway
  shields got roomier too (bigger badge, larger number).
- ✅ **Wrong-way detection + a real "Rerouting" banner (2026-07-16).** Off-route used to be judged by
  distance from the route line alone, so a wrong turn onto a road running close alongside the planned
  one never registered: no reroute, the old blue line stayed, and guidance kept speaking the old
  route's turns. The engine now also watches your COURSE - driving 60 deg or more against the route's
  direction counts as off-route even inside the distance corridor, with the usual debounce so lane
  changes and normal turns don't trip it. And while rerouting, the TOP banner says so - big
  "Rerouting..." with a refresh glyph in place of the stale instruction (it was only a small note on
  the bottom ETA card). The nav puck also stopped tracing every lane-level micro-kink of the road
  geometry: its drawn position averages a short window along the route, so it glides instead of
  wiggling side to side.
- ✅ **Reroute buzz (2026-07-10).** Going off-route now vibrates as well as speaking "Rerouting": three
  quick ticks then a long buzz, a pattern unlike any turn cue, so a cyclist who can't hear the voice
  (or anyone riding muted) still knows the route changed. Fired beside the spoken announcement and
  throttled the same way (once per burst, silent retries stay silent); honours the per-mode "Vibrate
  on turns" setting. Demo drives also pass the real travel mode now, so a simulated bike route
  buzzes exactly like the real ride would (it used to run haptics as Driving = silent).
- ✅ **Accuracy-scaled off-route sensitivity (2026-07-15).** How far you can drift before Vela reroutes
  now tracks the GPS fix's own reported accuracy, the way OsmAnd and Google behave - Google doesn't use a
  fixed distance at all, it map-matches. The corridor is `base + K×accuracy`, clamped: TIGHT when the fix
  is clean (a wrong turn is caught fast - driving drops well below the old flat 40 m when GPS is good),
  WIDE when it's noisy (urban-canyon multipath can't trigger a false reroute). It's also mode-relative -
  foot rides tighter than bike rides tighter than drive, because the PATH is narrow - so a pedestrian who
  takes the wrong footpath is caught quickly without over-firing when GPS degrades. (An earlier fixed
  22 m/28 m walk/bike pair was dropped as too aggressive; a scaled corridor is the right tool.)
- ✅ **Per-travel-mode "Vibrate on turns" (2026-07-03).** The single haptics toggle became **four** - Driving / Walking / Cycling / Transit - so you can buzz on turns while cycling/walking but stay silent driving. `Haptics.cue(type, approaching, mode)` checks the per-mode pref (`haptics_<mode>`). **Default = on for walk/bike/transit, OFF for driving** (`Haptics.defaultFor`) - in a car you've got the screen + spoken directions, so a buzz every turn is noise; an existing legacy `haptics_on=false` still wins.
- ✅ **Place-sheet header + actions, Google-style (2026-07-03, settled after a couple of iterations).** **Header:** name + **Save (★) · Share · ⋮ · ✕** as compact 40dp icon buttons; the name is `titleLarge` (22sp) with `maxLines=2`, so even "Starbucks Coffee Company" fits two clean lines beside the icons without ellipsising. **Action pills:** a highlighted **Directions** + short **Call / Website** (`ActionPill`, horizontally-scrollable as a safety) - the *fast path*. **Phone number + website live as their own tappable rows below the address** (showing "(425) 332-6175" and the domain), exactly where Google puts the detail. The collapsed **Hours** row no longer lets a long holiday value ("5 AM–1 AM · 4th of July (Observed)") squeeze the label into "Ho/urs" - fixed-width label, summary stripped to just the hours (`substringBefore("·")`) + ellipsised. Review-loading copy is the calm "Gathering reviews…". *(Iteration history: tried Save/Share in the header + a full-width Directions button, then all-in-scrollable-pills with the number in the Call pill - landed here: Save/Share on top like the previous build the user liked, short action pills, contact detail as rows.)*
- ✅ **Search targets the panned viewport, not GPS (2026-07-03).** Running a search now biases to the **map centre you're looking at** (`mapCenter ?: myLocation`), Google-style - so panning to another neighbourhood/city then searching returns results *there*, not back at your GPS location. Autocomplete suggestions do the same. (The "Search this area" button after a search is unchanged.)
- ✅ **A search that finds nothing says so (2026-07-12).** A successful-but-empty online search used to set the result list to empty AND clear the status, so the screen just went blank with no feedback (the "POI list isn't showing up" report). Now an empty online result first falls back to the **on-device OSM index** (a small local place Google may miss can still surface), and only if that's empty too shows a plain **"No results for X"** message instead of a blank screen. The offline fallback is now one shared path (`offlineSearch`) used by both the empty-result and the network-failure branches. Localized in all supported languages.
- ✅ **Faster POI loading via HTTP concurrency (2026-07-03).** The ambient-POI load fires ~13 parallel `google.com` category queries, but OkHttp's default **5-requests-per-host** serialised them into ~3 rounds - on a slow connection that's the "POIs take ~10 s to load" report (3 rounds × a slow round). Raised `Dispatcher.maxRequestsPerHost` to 24 so they all fire in one round, and added a 12 s `callTimeout` so one hung scrape can't stall the whole fan-out. (Device-measured ~2 s per fetch on wifi - that ~2 s is Google's own keyless response latency, the floor; the fix removes the ×3 serialisation penalty that dominates on slower links. Revisits are already instant via the ambient cache.) **Multi-area LRU cache (2026-07-03):** the single-slot ambient cache became a **16-entry LRU with a 30-min TTL** - revisiting *any* recently-viewed area (not just the last one) repaints its POIs instantly instead of re-waiting the ~2 s, and the TTL stops a since-closed shop lingering all session. *(A multi-agent exploration confirmed the honest ceiling: ~2 s per BRAND-NEW area is Google's own keyless response latency and can't be cut without a different data pipeline; the real wins are HTTP concurrency + this cache + not blanking the map. Progressive streaming / single-broad-query / vector-tile POI decoding were explored and rejected as dead ends.)*
- ✅ **POI dots reappear instantly on zoom-back (2026-07-03).** Zooming out cleared the ambient dots (they're off below z14) and zooming back in showed a beat of small OSM icons before the Google POIs popped in bigger. Now the last fetch is **cached** (`ambientCache`) and repainted immediately (re-centred + view-filtered) when you return to a nearby area, so there's no empty→OSM-flash→ambient "small then pop" - the network fetch then refines it. The settle debounce also dropped 500 → 300 ms for snappier first paint.
- ✅ **Voice settings decluttered + default speed 0.8× (2026-07-03).** Settings → Voice now shows just the essentials (pick voice · Test voice · System voice settings) with the rest - the playground, the speed stepper, the 900-voice variant picker - tucked behind a collapsed **"Advanced voice options"** header (most people never touch them). The default spoken-directions speed is **0.8×** (compiled + calibration v13; briefly 0.72 on 2026-07-06, reverted 2026-07-07), the user’s preferred cadence. And the review-loading copy that read "…this can take half a minute" is now a calm "**Gathering reviews…**" / "Reviews · N of ~M".
- ✅ **Replay uses the selected voice, not the system fallback (2026-07-03).** Replaying a recorded drive spoke through the GrapheneOS **system** TTS while still applying the voice-speed pref (the "system voice at 0.8×" bug) - because `replayTrip` started nav with a `null` voice engine (live nav passes the selected one). Now replay wires the neural synth and passes `selectedEngine.packageName`, so it speaks through the same Vela voice as a live drive. **During turn-by-turn ALL POI tiers are hidden** (`poi_r1`/`poi_r7`/`poi_r20`/`poi_transit` → off while navigating, restored on exit, keyed on the style so a dark/light flip re-applies it): POI labels re-ran MapLibre's symbol collision on every nav camera rotate/zoom and **popped in and out at zoom thresholds** - Google declutters its map the same way during nav, so the nav view is label-clean now *(top-rank `poi_r1` was kept at first but still flickered at the threshold, so 2026-06-21 it's hidden too)*
- ✅ **Buildings** (footprints + 3-D massing) - OSM building data already in the Liberty tiles (`building` 2-D fill + `building-3d` extrusion at high zoom), given enough contrast + a subtle outline to read (was coloured almost identical to the land), and the 2-D `building` layer's minzoom lowered to 14 so **residential houses surface a zoom-level earlier** (~z17 now). **Keyless, no API key, no new data/infra.** *Caveat (two distinct gaps):* (1) OpenFreeMap's keyless tiles drop small footprints from low-zoom tiles, so houses only appear zoomed-in (Google shows them at neighbourhood zoom because its tiles are richer); (2) more fundamentally, **some US residential houses are simply absent from OSM** and so render at *no* zoom - Google has them from satellite/assessor data that was never imported into OSM. Lowering minzoom fixes (1); only **(2) richer building data** closes the "house is on Google but never on Vela" gap. Options: **MapTiler** (still OSM-derived buildings → same data gap, just nicer styling; path wired, off) won't help here; the real fix is **our own tiles baked from Microsoft US Building Footprints (~130 M, ODbL) / Overture / Google Open Buildings** - free + open, but bulk files → self-hosting/PMTiles infra (a deliberate decision, not a quick toggle). **✅ UPDATE 2026-07-04 - gap (2) is now CLOSED for downloaded regions:** the Microsoft-footprint **building overlay** (see the Offline section) is baked into PMTiles by CI and rendered beneath OSM, so a suburb OSM never mapped now fills with real house footprints. **Device-verified on a Pixel 5a** - the same suburban blocks went from bare roads to full footprints after the overlay downloaded.
- ✅ **Terrain relief (hillshade)** - Google-style shaded relief from the **keyless
  open terrarium DEM** (AWS Open Data, no key, native fetch so no CORS), added at
  runtime under the road layers (so roads + labels stay crisp) and capped at z16
  (terrain context for the overview, gone at street level). Tuned per theme - a
  soft warm-grey shadow in light, deeper shadows + a cool highlight in dark.
  Verified in a MapLibre GL JS harness (same render engine as MapLibre Native)
  against the real DEM tiles before shipping
- ✅ **Two-finger tilt to 3D** (2026-06-27) - drag two fingers vertically to pitch the map
  between flat and a near-horizon 3D view (Google-style). Tilt gestures are now enabled
  explicitly and the max pitch is lifted to 70°; browse-camera moves use `newLatLngZoom`
  which preserves the pitch you set, so the tilt sticks until you change it
- ✅ **Ambient Google POIs on the map** (2026-06-27) - the basemap dots/labels are OSM
  (OpenFreeMap), so Google-only places used to appear only when searched. Now, on a bare,
  zoomed-in browse map, the visible area's prominent **Google** places are fetched automatically
  (one keyless `"places"` query - ~20 mixed-category hits - capped to 12) and drawn as **small
  Google-style category dots** - the *same* `vela-poi-<group>` icons as the OSM POIs (fork=food,
  cart=shop, fuel, etc.), with decluttered labels - so they read as native map POIs, not clashing
  red pins. Tap to open like any result. **Google-first balance:** while ambient Google POIs are
  showing, the OSM **business** POI layers (`poi_r1/r7/r20`) are hidden so the two don't duplicate
  ("OSM for the map, Google for the businesses"); OSM transit + the whole OSM basemap stay, and the
  OSM POIs come back when ambient is off (zoomed out / offline / nav / search). **Tightly gated** so
  scraping stays modest: zoom ≥ 14, bare map only (no results / open place / nav / replay),
  debounced 500 ms, skipped for pans under 250 m. On-device-verified (Applebee's, Subway,
  Safeway Fuel Station as category dots, tap → place sheet). **Coverage + zoom behaviour (2026-06-27):**
  the query **viewport tracks the map zoom** (`nearbyPlaces(center, span)` - span ≈ 9 km at z14
  down to 3.5 km zoomed in, with the `!1d`/`!4f`/`!7i40` pb tightened to match) so zooming into a
  strip mall fills it with ITS businesses - **~11–25 local hits within 500 m vs 1** with the old
  wide search (calibrated live). Re-queries on a real pan **or** zoom change, and the dots **clear
  when you zoom out past z14** (and the OSM POIs come back). **Category fan-out (2026-06-27):**
  `nearbyPlaces` now runs a small **parallel fan-out** of category queries
  (`places`/`restaurants`/`coffee`/`stores`/`services`/`beauty salon`) and merges+dedupes them - 
  one "places" query is biased to prominent food/shops and misses whole tiers (the strip mall's
  plumber, nail salon, IT shop), so the fan-out roughly **doubles local coverage (live: 22→52
  unique within 600 m)**; capped at 50. *(An on/off toggle is the next option.)*
- 🟡 Self-hosted PMTiles - the no-key, no-quota Google-look path - remains for later
- ⬜ Protomaps "Google-Maps-ify" style (road hierarchy ✅, hillshade ✅, POI icons ✅ done; this is the bundled-style variant)
- ✅ Satellite layer - shipped 2026-07-13 via the Layers panel (Esri World Imagery hybrid; see the Layers entry below). Terrain relief ✅ too
- ✅ Map rotation/tilt + heading-up mode during nav (tilted follow-camera, speed-adaptive zoom)

## Search & POIs (live Google data)
- ✅ **In-app Street View (2026-07-15, keyless, device-verified).** The Street View pill on a place
  opens a real panorama INSIDE Vela - drag to look, pinch to zoom, **walk between panos with the
  on-screen arrows, and go BACK IN TIME** through the older captures. It works keyless the way open
  Street View viewers do: resolve the pano metadata (the JS Maps API's `GeoPhotoService.SingleImageSearch`
  by lat/lng, `photometa/v1` by pano id for walking), fetch the equirectangular tiles
  (`streetviewpixels-pa.googleapis.com`), and texture them onto a GL sphere we render ourselves. No
  API key, no login; the pano `pb`s ride the signed calibration channel so a drift is a config fix,
  not an app release. The capture date shows in the attribution ("Davis, California · May 2024 ·
  © 2024 Google") - the copyright year tracks the shown capture, not the current year, and updates
  when you go back in time; when a spot has more than one capture, a clock chip (raised clear of the
  attribution so they don't overlap) lists them and switches the imagery. **Walking or jumping to another
  date morphs** - the outgoing pano is held and the new one crossfades in over ~300 ms with a subtle
  forward dolly, so it reads as stepping into the next spot rather than a hard snap. It **opens looking
  across the street at the building**, like Google: rather than a raw bearing to the place coordinate
  (which points down the road whenever Google's geocode sits on the road centreline), the camera snaps to
  the road-perpendicular on the building's side - the metadata heading gives the street's direction - and
  the real bearing nudges it up to 60 deg toward the facade, clamped so it can never swing down the road.
  Walking aims along the direction you moved. It's **half-screen over the live map** like Google: the pano
  takes the top of the screen and the map below shows the **nav puck with a view cone** at the pano's
  position, centred in the visible strip (the camera pads for the pane) - turn in the pano and the
  puck+cone turn with you, walk and it hops (the map eases along), and **tapping the mini-map jumps the
  viewer there** (pegman-drop: nearest pano at the tap, looking toward what you tapped, or down the street
  when you tapped the street itself) - with a corner button to go truly full screen and back (the mini-map
  hides entirely; Back backs out of full screen first; full screen keeps the same horizontal framing and
  reveals more sky/ground rather than zooming). All of this device-verified end-to-end. Best of all, it usually
  **opens on Google's own pick**: the
  search response's Street View thumbnail URL carries the exact pano id and camera yaw the Google app
  itself opens, so Vela uses them verbatim - same imagery, facing the same way, zero extra requests. Only
  when a response ships no thumbnail does it fall back to heuristics: nearest pano, then (if that pano
  isn't on the address's own street - a set-back geocode snaps to the alley cluster behind the building,
  which isn't even graph-connected to the frontage) perpendicular probes that adopt the closest pano that
  IS on the address's street, facing across the road at the building. Walk arrows show in historical views
  too (the neighbour graph is the base pano's), and they fetch the neighbour BY ID so the year and the
  picture always match. A place with no
  imagery gives a brief "no Street View here" toast. (The old approach - embedding Google's own WebGL
  page in a WebView - rendered black on many devices and was reverted; rendering the tiles ourselves
  is what makes it work.)
- ✅ **Toggles to hide reviews and skip photo loading (2026-07-08, user request).** Settings → Map gains two
  switches, both on by default. **Show reviews** off = the place sheet renders no review section at all (no
  tab, no featured quote, no "Read all reviews") and Vela never runs the review scrape for a selected place.
  **Load photos** off = no hero strip or gallery, and the WebView photo fetch (the heaviest per-place request)
  never starts; the search response's preview photo is hidden too, so this doubles as a data saver. Both
  persist (`ShowReviews` / `LoadPhotos` holders, same shape as the other reactive settings) and gate BOTH the
  fetch in the ViewModel and the render in the place sheet, so off means no traffic, not just hidden UI.
  Device-verified: with both off, an Applebee's sheet opens with rating, hours, phone and attributes but no
  photos and no review section. Localized in all supported languages.
- ✅ **"Hide adult categories" toggle (2026-07-08).** Settings → Map, **off by default**. On = drops places whose
  Google CATEGORY is adult / nightlife / alcohol / gambling / smoking (bars, clubs, casinos, liquor stores,
  hookah, cannabis, adult, …) from **both** search results and the ambient map. Matching is on the free-text
  category **only, never the name** (a place categorised "Restaurant" is always kept), and it's PRECISE - food
  "…bar" categories (sushi/juice/coffee/salad bar) stay. Because Google returns the category **localized**
  (`hl=<lang>`), the keyword list carries the equivalent terms for all supported UI languages, so the filter works in
  every locale, not just English. Pure `:core` `CategoryFilter` (unit-tested) applied at the data-source seam
  (`GoogleMapsDataSource.search` + `nearbyPlaces`); gated by a `:core`-visible `enabled` flag the `HideAdult`
  holder flips, so `:core` needn't depend on the app's reactive state. Localized in all supported languages.
- ✅ **"Hide website & external links" toggle (2026-07-08).** Settings → Map, **off by default**. On =
  place pages don't show the **Website** pill/row, the **Street View** pano, or the **Book / Reserve /
  Order** action, so no place-detail control launches an arbitrary external site. Internal actions
  (dial, directions, share a `geo:` pin) are unaffected. Plain `HideExternalLinks` holder
  (`ui/PlaceContent.kt`, same shape as `ShowReviews`/`LoadPhotos`). Localized in all supported languages.
  (Adapted from a community PR; the PR's separate "restricted" build flavor was not taken.)
- ✅ Place search - name, category, **full address (street, city, state, ZIP)**, rating, review count, coordinates
- ✅ Searching a **specific/far address** resolves to that single geocoded location (handles the response's single-result shape, not just the POI list - fixes the old "calibration error" on far addresses); genuinely-empty searches now show "no results" instead of an error
- ✅ **Address → business snap** - searching a raw address that *is* a business (e.g. "1020 Olive Dr, Davis") now lands on the **business** (In-N-Out Burger, rating/hours/category and all), not the bare address - Google lists the "at this place" business under the geocoded node (`[0][1][0][14][68]`) and Vela now reads it. *(verified on-device; unit-tested; the path is in calibration so it's remotely fixable)*
- ✅ **Business name stripped from the address line** (2026-07-01) - some places' formatted address comes back name-prefixed ("Safeway, 1451 W Covell Blvd"); since the sheet already shows the name on its own line, that read the name twice. `SearchParser.stripNamePrefix` drops a clean name prefix (only at a real word boundary, and never if it'd empty the line) and the component-array fallback filters out any component equal to the name. *(unit-tested)*
- ✅ Search-result rows show **5-star rating**, colour-coded open/closed status, and the **full address (city/state/ZIP)** to disambiguate similar names / lookalike residential addresses - **sized for legibility** (name at titleMedium, the rating/category/address lines bumped up from the cramped small text)
- ✅ Place sheet (**Google-styled**): high-contrast white-on-dark / black-on-white name + status time (fixed palette, not washed-out by Material You), **5-star rating visual**, **three-detent swipe (2026-07-07): expanded, peek, and a small minimized card** - a gentle swipe down steps one detent (expanded to peek to minimized), and the hardest flick lands straight on minimized from anywhere. *Since 2026-07-08 a swipe NEVER closes the sheet* - minimized is the floor, matching Google (the strongest inertia minimises; only the X or back dismiss), so a flick can't accidentally destroy the place you were reading. A single tap anywhere on the minimized card pops it back to peek (2026-07-08). **The minimized detent is a compact card - name, rating, and a Directions button, not the photo hero** (device-tested: at that small height leading with the photo strip showed only photos and let the horizontal gallery swallow dismiss drags, so the minimized state short-circuits to a clean header). Works from the handle or anywhere on the body (a nested-scroll handler; mid-list it just scrolls), status with the **word colour-coded** (Open green / Closed red) and the time in plain ink, **distance from your location** (when opened from a located search) + price + category, **full address with a copy button**, **collapsible weekly hours** (today first, expand for the week), and a **holiday-hours callout** - when a day this week carries Google's special-hours label (parsed from `day[6][1]`, e.g. "4th of July (Observed)"), the place card flags the SOONEST one Google-style in amber right under the status: *"4th of July (Observed) · tomorrow · 9 AM–5 PM"* (device-verified on Chase Bank, 2026-07-02), instead of leaving it buried on one day's row
- ✅ Full-screen photo viewer: **pinch-to-zoom** (+ pan when zoomed) and **swipe-down-to-dismiss**, swipe sideways between photos
- ✅ **System maps handler** - Vela registers for `geo:` URIs and Google-Maps web links (`/maps/place`, `/search`, `?q=`, `@lat,lng`, `maps.app.goo.gl`), so tapping an address or "open in maps" in any other app offers Vela. A query runs a search (biased to any coords in the link), a bare point drops a reverse-geocoded pin - the degoogled-replacement piece. (`MapLinkParser` in `:core`, unit-tested; parsed in `MainActivity`.)
- ✅ Viewport-biased "near me" search
- ✅ Recent searches (persisted) + **recently-viewed places** - opening a place records it; the search page shows a **Recent** section (pin icon, one tap to reopen - enriched via search) above **Recent searches** (clock icon). Capped at 8, deduped, cleared together *(verified on-device)*
- ✅ **Full-screen search page** (Google-style) - focusing the search box opens an opaque page with **Home/Work shortcuts**, saved + recent searches over the map (back arrow / back gesture closes it); running a search drops back to the map with the results list + red pins
- ✅ **Home / Work shortcuts** (Google's signature) - two pinned rows at the top of the search page. Unset shows "Set home/work address"; tapping arms an assign mode (a "Search for your home address" banner + Cancel) and the **next place you pick** - a suggestion, a saved place, or a tapped POI - gets pinned. A set shortcut shows the place name and a **⋮ menu (Change / Remove)**; tapping the row opens the place. You can also set the **currently-open place** as Home/Work straight from its **place-sheet ⋮ overflow**, or promote a Saved place via its ⋮. Persisted in `PlaceShortcutStore` (`vela_shortcuts` prefs), so they survive restarts *(verified on-device: set Home → "Sacramento Valley Station", ⋮ → Change/Remove)*
- ✅ **Autocomplete / suggestions as you type** - after a short debounce, the search page shows live **place matches** (name + address) to tap, like Google; tapping one opens its sheet directly. Reuses the calibrated search endpoint (no separate suggest RPC); a stale response is dropped if the query moved on. *(verified on-device: "starb" → Starbucks locations)*
- ✅ Clear-search (X) button; the **results list is a bottom sheet** with the place sheet's detent grammar (2026-07-08): MINIMIZED ("N results" bar) ↔ PEEK (~42%) ↔ EXPANDED (~82%) - tap the handle to step up a detent, drag up/down to grow/shrink one, and a nested-scroll handler shares the gesture with the list. The header has the **detent chevron** and, to its right, an **X that exits the search entirely** (results, pins and query - same as backing all the way out); the back gesture still peels detents first. *(X added 2026-07-08)*
- ✅ **Result filters** - chips in the results header: **"Open now"** (places open right now) and **"4.0★"** (rating ≥ 4.0); they stack and the count updates live
- ✅ **Back gesture peels one layer at a time** (steps → navigation → route preview → place sheet → results list) instead of closing the app - only the bare map exits
- ✅ **Full reviews - now via a hidden WebView, WITH per-review photos (2026-06-27).** Google
  **deleted** the keyless `listentitiesreviews` endpoint (it now 404s) and moved reviews behind a
  `batchexecute` RPC (`rpcids=T4jwAf`) whose request proto resisted capture. So reviews are now read
  the same way as photos/transit: **`WebReviewsFetcher`** loads the place's canonical `?cid=` page in
  a hidden, anonymous WebView (desktop UA), lets Google's own JS render the reviews, and scrapes each
  review card from the DOM - star rating, author, relative date, text, **and the reviewer's uploaded
  photos** - into JSON that **`ReviewsWebParser`** (`:core`) turns into `Review`s. **This finally
  delivers per-review photos** (the old endpoint only ever served avatars - see the strikethrough
  below). On-device-verified on a neighborhood park (real review text + photo rows).
  *(Wired into `MapViewModel.fetchReviews`; the cid = the low half of the `0x..:0x..` feature id as
  decimal. The old `listentitiesreviews` path/`ReviewsParser`/calibration `reviewsPb` are now dead
  but left in place.)* ~~pulled from Google's keyless `listentitiesreviews` endpoint by feature id.~~ **Review photos are collected by URL shape, not a fixed index** (recalibrated 2026-06-20): `ReviewsParser` takes only a reviewer's **uploaded** FIFE photos (`/gps-cs`, `/geougc`, `/p/AF1Qip`) and never their **avatar** (`/a/`, `/a-/`, `ACg8oc`, `ALV-`). This fixes a bug where the old "photos hang under `review[12]`" calibration was sweeping the reviewer's **profile picture** into the thumbnail strip - every review showed the author's face as if it were an uploaded photo. ⚠️ This RPC turns out to return **only avatars**, so the strip currently shows nothing; **real per-review uploaded photos need a separate source** (the photo-inclusion flag resisted discovery - see ROADMAP). Unit-tested (avatars excluded at `[0][2]`/`[12]`/`[60]`, genuine UGC collected). **Intermittent "no reviews" fixed (2026-06-21):** the RPC sometimes returns an empty page (a bot-degraded reply / rate blip), which used to stick as "no reviews" until you reopened the place (seen on a park and a cafe listing). `fetchReviews` now **retries with backoff (up to 4 tries across ~3 s - widened after a tap-to-retry confirmed a fresh call clears the flake within seconds) when the place's own review *count* is >0 but the fetch came back empty** - that count-vs-zero mismatch is the transient-miss tell - while a genuinely review-less place (count 0/unknown) still stops after one try, so review-less places are never hammered. **Plus an honest UI state:** when the count says there ARE reviews but the list is still empty, the tab shows **"Couldn't load reviews. Tap to retry."** (a load failure, distinguished from a real zero by the count-vs-empty mismatch) instead of the misleading "No reviews available", so a sticky outage that outlasts the auto-retry is one tap from recovering - `MapViewModel.retryReviews()`. *(Seen showing rating + count but no list on the same park; the count proves the featureId loaded, so it's purely the RPC flaking.)*
- ✅ **Save my parking spot (2026-07-08, v2 same day, device-verified end to end).** A dedicated
  P button above the locate FAB: tap saves the spot where you stand (toast; prefs, survives
  restarts) and the button turns teal while one is set. The map draws a teal "P" pin at the spot;
  tapping the pin (or the teal button) opens a "Parked car" place sheet with a car glyph beside
  the name, the normal Directions action (defaults to WALK for a parking spot) and a Clear
  parking pill. The camera frames the spot when opened from afar. All strings in all locales.
  *(v1 was a long-press on the locate FAB + a chip - reverted: undiscoverable, and Compose's
  FloatingActionButton consumes the down so outer long-press detectors never fire.)*
  **Re-parking hub (2026-07-11, user - "setting parking again when you already have a spot is a
  little clunky").** With no spot set, a tap still saves where you stand in one go. With a spot
  already set, a tap now opens a small **menu on the P button** instead of jumping straight to the
  parked-car sheet: **Find my car**, **Move parking here** (overwrites the spot with your current
  fix; the old one is not lost - it drops into history), **Earlier spots** (shown only when history
  holds a prior one), and **Clear parking**. So re-parking is one obvious choice rather than the old
  clear-then-tap-again dance. Long-press still jumps straight to the history sheet. New menu strings
  are English-first (localization backfill tracked with the other i18n leftovers).
- ✅ **Local place lists (issue #1, 2026-07-08, device-verified).** Google-Maps-style saved lists:
  a **Your lists** section on the search page, each list a coloured icon + name + count that opens as
  results. Create/edit via a dialog with a **name, a 10-icon picker and an 8-colour picker** (the
  "custom icons" the requester asked for). Any place's ⋮ menu has **Save to list** (a checkbox chooser,
  create-new inline, live count) and **Edit note** once it's in a list; the note shows on the sheet as
  an italic quote. Persisted in `vela_lists` (PlaceListStore). A pasted Google Maps share link
  previews as results with a **Save list** pill - nothing is added to Your lists until you tap it
  (opt-in, 2026-07-09), then it's a durable local list. Remaining: reorder, share-out, a dedicated
  full-screen list view.
- ✅ **Voice search mic (2026-07-10).** A mic in the search bar: tap it, a voice-input app you have
  (FUTO Voice Input, Google's recognizer on GMS phones, …) captures speech and the text runs as a
  search. Vela records nothing itself, the provider does, so no microphone permission. The mic only
  appears when it can actually work: a Settings toggle (Search section, on by default) AND an app
  that handles the recognize-speech intent. With no such app the mic is hidden, never shown dead,
  and Settings says why. Keyboard-only dictation (Sayboard, FUTO Keyboard) doesn't trigger it since
  apps can't invoke a keyboard's mic; those users keep using the keyboard mic, and a later build
  adds an on-device model so voice search works with no third-party app at all.
- ✅ **On-device voice search (2026-07-10).** Voice search now works with **no other app at all**:
  the mic is always in the search bar, and with nothing installed tapping it offers the one-time 58 MB Vela voice download. Once it's there, tapping the mic records and
  transcribes **entirely on your phone** with a bundled Whisper model, then runs the text as a
  search. Nothing is uploaded, no account, and it covers all of Vela's languages. A listening
  sheet shows the mic pulsing with your voice; it stops on its own after a beat of silence (or tap
  Done), and the microphone permission is asked only the first time you tap the mic. When both Vela voice and a
  voice-input app are present, a Settings picker chooses which to use (Vela voice by default). Device-verified end to end: download, install, the mic appears, the permission prompt,
  the listening sheet, and the model transcribing back into the search box. **Pauses your music
  while it listens (2026-07-12):** starting dictation takes transient audio focus
  (`AUDIOFOCUS_GAIN_TRANSIENT`, assistant usage) so whatever is playing pauses like a phone
  assistant does, and gives it back the moment the utterance ends so playback resumes.
- ✅ **Pick your dictation engine: SenseVoice + Moonshine (2026-07-20).** On-device voice search is
  no longer Whisper-only. Settings → Search lists three engines you can download and switch between,
  all running on-device through the same bundled sherpa-onnx runtime: **Whisper tiny** (the
  multilingual default, every language Vela supports), **SenseVoice** (more accurate + faster, for
  English/Chinese/Japanese/Korean/Cantonese), and **Moonshine** (lowest latency, English only). Each
  shows its languages and size; the first one you download becomes active, and a Use/Remove control
  switches or frees them. Whisper stays the default so no language regresses, and the other two are
  opt-in. The recognizer rebuilds automatically when you switch engine or change app language.
- ✅ **Transit lines are opt-in now (2026-07-10).** The purple rail highlight is off by default;
  it reads as mystery lines if you don't know what it is. Settings → Map → "Highlight transit
  lines" brings it back, and an earlier choice is kept either way.
- ✅ **Language switching leaves nothing behind (2026-07-10).** Switching back to English used to
  keep dates (parking history months) and freshly fetched place names in the old language until
  the app was killed; now the switch back is complete immediately. The translations also lost
  their machine-looking long dashes across all ten languages.
- ✅ **Pick your voice app (2026-07-10).** Settings → Search lists Vela Voice, "Android default"
  (your system-wide choice, untouched), and every installed voice app by name as a manual
  override. The mic launches exactly what the picker says.
- ✅ **The place card follows your finger (2026-07-10).** Dragging the place sheet moves it with
  your finger and, on release, it coasts on the fling to whichever size is closest - no more
  stepping between sizes in fixed hops.
- ✅ **Live gas prices on the map (2026-07-10).** Searching for gas stations shows each
  station's current price in the same bubble marker the restaurant ratings use, and the full
  price ("$5.34/Regular") gets its own bold pump-glyph line under the address in the result
  list and renders bold on the place page's price line. The
  price rides the keyless search response (place node [88][0], a remotely recalibratable
  path). EV chargers were checked too: the keyless response strips charger details (price,
  kW, availability) the way it strips popular times, so those stay marker-only for now.
- ✅ **Search results are Google-style red markers with real glyphs (2026-07-11).** Searching
  "restaurants" pins the map with named results instead of anonymous pins: every result keeps
  its grey teardrop and category glyph with the circle turned red, rated restaurants get a wide
  speech-bubble marker with the rating beside the circled glyph, and in a dense downtown the lesser results collapse into little red dots that
  expand back into pins as you zoom, so the view never turns into a pile of overlapping icons.
  The base map's OSM icons now BLEND with the Google dots instead of hiding wholesale: they
  yield only while the viewport truly sits inside the area the Google fetch covered, so panning
  or zooming past it keeps icons everywhere and fresh fetches merge in as they land. Stop signs
  and traffic lights also hold back on the browse map until true street zoom (they stay at nav
  zoom during turn-by-turn, where they're an aid rather than clutter).
  Result labels stay plain ink (only ambient POI labels take the category tint, like Google);
  every POI label on the map (results, ambient dots, base-map icons) can now sit left, right,
  below or above its icon, whichever side is clear, instead of vanishing when its usual spot
  was taken;
  and while a result set is up the base map's own POI icons, stop signs and traffic lights all
  step aside so the results are the only things on the map.
- ✅ **Traffic in words, not just colour (2026-07-10).** Route choices now say "light traffic",
  "moderate traffic" or "heavy traffic" to match the green/amber/red time, so the conditions read
  without relying on colour. And a freshly downloaded voice no longer speaks a sample on its own -
  only picking a voice in the library (or the Test button) plays one.
- ✅ **The route chooser swipes out of the way (2026-07-11).** Swipe the chooser down, from its
  body or its handle, to shrink it to a slim bar with a Start button and see the whole route on
  the map; it follows your finger and rides the throw, like the place card. Swipe or tap to bring
  it back.
- ✅ **Arrival time front and center (2026-07-10).** The directions panel's "Arrive at 5:30 PM"
  is bigger and bolder, and the redundant "current traffic" note under it is gone (the route ETAs
  already show traffic). The faster-route offer during navigation joined the tidy notification
  stack too, so it can't sit under the turn card.
- ✅ **The results list moves like the place card (2026-07-11).** Dragging the search results
  follows your finger and rides the throw's inertia to the nearest size, minimizing included, and
  the back gesture exits the search in one press instead of stepping through sizes. Grabbing the
  map GLIDES the list down to its bar so the map is yours to look at, and does the same to an
  open place card (down to its small state); the bar or a drag brings them back. The minimized
  bar now says WHAT it's holding: the search text (or list name) leads in full ink with the
  result count under it, instead of an easy-to-miss dim "20 results".
- ✅ **One tidy notification area (2026-07-10).** Heads-up messages, download progress, update
  offers and notices now stack below the search bar and chips (or just below the turn card during
  navigation, whatever its height), each dismissed on its own, instead of painting over each other.
  A missing-voice warning carries a "Get a voice" pill straight into the voice library.
- ✅ **Right fix for a missing voice, per language (2026-07-11).** The missing-voice pill now forks
  by cause. A language Vela can train a Piper voice for (French, Russian, …) still gets a "Get a
  voice" pill into the library. A language Piper **can't** do (Japanese: espeak-ng has no Japanese
  phonemizer, so there is no Vela ja voice) gets a **"System voices"** pill that opens the phone's
  own text-to-speech settings instead, because that is where Japanese guidance is spoken from (the
  system-TTS fallback) and the Vela library would be a dead end. `PiperCatalog.hasVoiceFor(lang)`
  drives the fork; the pill deep-links `com.android.settings.TTS_SETTINGS` (falling back to the main
  Settings screen on ROMs that lack it). So Japanese turn-by-turn works today through Google's (or
  any) system Japanese voice, and the app points you to install one if it's missing, rather than
  nudging you toward a voice that can't exist. A fully-offline bundled Japanese neural voice (Kokoro)
  stays a possible follow-up in ROADMAP.
- ✅ **Spoken directions toggle (2026-07-10).** Settings → Voice has an on/off switch for spoken
  navigation; it remembers your choice, and the mute button during navigation is the same switch.
- ✅ **Update button is a filled pill (2026-07-10).** The update card's Update action is a filled
  pill instead of tinted text, so it stands out by shape and fill rather than colour alone.
- ✅ **Recents you can prune, with addresses (2026-07-10).** Every recent search and recently-opened
  place has an X on its row to remove just that entry (Clear recents still wipes the lot). A real
  place shows its street address in smaller text under the name, and the Home/Work rows show the
  saved address too. The three-dot menus on Home/Work match the row text color now.
- ✅ **Route chooser and search stay coherent (2026-07-11).** Opening any new place, from search,
  a suggestion, a pin, or Home/Work, closes an open route chooser instead of leaving it covering
  the fresh place with a stale route. The locate and parking buttons also stay hidden under the
  chooser and step list instead of drawing on top of them.
- ✅ **Warns when you'd arrive near closing time (2026-07-10).** Starting navigation to a place
  that closes within an hour of your arrival (or before you'd get there) shows a heads-up card
  and speaks it: "closes at 9:00 PM and you arrive around 8:40 PM". Reads the closing time from
  the place's own status in any app language; says nothing when the place is closed already or
  has no hours.
- ✅ **Approximate location explains itself, and the blob actually shows (2026-07-10).** Granting
  approximate (at setup or from the locate button) now gets one plain dialog saying what it means -
  wide circle for a dot, no turn-by-turn - with an Allow-precise shortcut that goes straight into
  Android's upgrade choice. And the accuracy circle itself is finally visible: the locate zoom-fit
  had a pixel-density bug that always framed the circle bigger than the screen, so it read as
  nothing at all.
- ✅ **Notifications are asked during setup (2026-07-10).** Turn-by-turn keeps your next move in a
  notification, so onboarding now asks right after location; declining gets one are-you-sure and
  never blocks anything. Heads-up cards also drop below the turn card during navigation instead of
  colliding with it, and a mid-drive voice download stays visible instead of silently hiding.
- ✅ **Navigation asks for precise location instead of failing silently (2026-07-10).** Turn-by-turn
  needs GPS, and with approximate-only permission it used to start and sit at "Searching for GPS"
  forever. Tapping Start now explains it plainly and offers to allow precise location; Android shows
  its own upgrade choice and navigation begins as soon as it's granted. And if location is fully
  denied, the locate button explains itself and links to system settings instead of doing nothing.
- ✅ **Approximate location shows honestly (2026-07-10).** If you grant only approximate location
  (or the fix is just weak), the map now draws a soft translucent circle around the dot at the fix's
  real uncertainty radius, so "somewhere in this area" looks like what it is instead of a
  falsely precise point. Normal GPS keeps the plain dot, and the circle never shows during
  navigation.
- ✅ **Location asked at "Get started", not on the map (2026-07-10).** The location permission used
  to pop the instant the map first loaded, out of nowhere. It now fires as soon as you tap Get
  started on the welcome screen: the welcome screen already says what Vela is, so a maps app asking
  for location right there needs no second explanation (an earlier build put a separate rationale
  screen in between; that was one tap too many). Declining leaves search and browse working, and the
  locate button re-asks when you tap it; granting only approximate location works too (the map
  centres on a coarse fix).
- ✅ **Honest voice-setup choice (2026-07-10).** The first-run voice offer used to be download-or-
  dismiss; now it's a real two-way choice with the recommendation shown by emphasis, not by hiding
  the alternative: a prominent "Download Vela voice" and a quiet, still-functional "Use existing
  voice" that keeps whatever text-to-speech the phone already has.
- ✅ **Shorter onboarding, no wall of asks (2026-07-10).** First run is now just welcome → location →
  voice, then the map. The old offline-maps prompt and the diagnostics/trip-recording prompt were
  removed from onboarding: a brand-new user has no context for them yet. Both settings still live in
  Settings (off by default), and the diagnostics ask now appears *in context* on the crash-report
  card - if Vela actually crashes and diagnostics is off, that card offers to turn it on so the next
  one carries detail. Fewer things to read before the app is useful.
- ✅ **Dialog buttons are Google-style pills (2026-07-10).** Every confirm button across the app's
  dialogs (voice, location, diagnostics, trip recording, …) is now a filled pill and the decline
  stays a plain text button, so the recommended action reads at a glance. Long labels wrap the pill
  to its own line instead of breaking mid-word, and it all still works by D-pad on a feature phone.
- ✅ **Settings decluttered (2026-07-10).** The Settings page was one very long scroll. The rarely-
  touched toggles now live in two collapsed groups at the bottom: **Advanced** (3D buildings, traffic-
  light guidance) and **Developer** (simulate driving, simulate location, save trips - the demo/testing
  tools, each labelled "turn off for real use"). The content filters (hide adult categories, hide
  website & external links) sit with the other place-content toggles under Place pages.
  Everything else stays one tap away. **Offline moved up** near the top since you reach it often.
  **Language** is now a simple "Follow system language" switch that only shows the full language list
  when you turn it off. And the **voice library is its own screen** now (a "Browse voices" button in
  the Voice section) instead of a giant list unrolling inline. All of it still works by D-pad.
- ✅ **Update from Settings directly (2026-07-09).** The Version section's "Check for updates"
  used to answer "update available, go back to the map to install it" - now the full offer
  renders inline: version line, Update button, live download progress, Not now. Same state and
  download call as the map card, so starting it in either place shows progress in both.
- ✅ **One chronological Recent list + saved-row contrast fix (2026-07-09, device-verified).**
  The search page's separate "Recent" (places) and "Recent searches" sections merged into ONE
  list ordered by when you used them, the way Google mixes them - a pin icon marks a place you
  opened, a clock marks a query you typed. Both recents stores now stamp entries with a
  timestamp (new pref keys; the old-format data stays in place so a downgraded build finds it
  instead of wiping it, and old entries migrate once with synthesized order-preserving stamps).
  Also fixed: starred places on the search page drew their name in BLACK in dark mode - the
  page is a plain background Box, not a Surface, so a colourless Text falls back to black; the
  row now uses the same on-surface colour as every neighbouring row in both themes.
- ✅ **Material You dynamic colour (issue #15, 2026-07-09, device-verified light + dark).** A
  Settings -> Appearance toggle (Android 12+ only) tints every themed surface - buttons, chips,
  FABs, dialogs, the focus ring, the nav notification's arrow tile and accent row - from the
  system wallpaper palette. Off by default (Vela teal stays the stock look). Accents stay legible
  because everything uses the scheme's paired slots (primary/onPrimary etc.), which Android
  generates at accessible contrast in both themes; the dynamic scheme is also sanity-checked
  (background luminance must match the requested theme) and falls back to Vela's own colours on
  ROMs that hand back a broken palette (seen on GrapheneOS once). The tinting is deliberately
  split: chrome and transient surfaces follow the wallpaper (search bar, menus, dialogs, chips,
  FABs, Settings, the notification), while the place/results sheets keep their fixed greys and
  the map keeps its own colours - those are reading surfaces full of meaning-bearing colour
  (open/closed status, stars, the route line) that has to stay legible on every wallpaper.
  Worth knowing: Google Maps itself never adopted dynamic colour at all, so even the chrome
  tinting goes further than the app Vela replaces.
- ✅ **List notes stick to chain stores + show in the list (2026-07-09, device-verified).** Notes on a
  chain place (a Safeway with several co-located Google listings) silently vanished: list membership
  was keyed on a volatile internal id that could point at a different listing next visit, so the note
  wrote to nothing. Membership, notes, add/remove and the "Saved" affordances now match on the STABLE
  Google feature id first (the volatile id stays as fallback for places without one), and a saved
  place opened from the map or search carries its list note onto the sheet. An open list also shows
  each place's note under its row (italic quote) and leads the results sheet with the LIST'S NAME
  ("Sightseeing · 8"), not a bare results count.
- ✅ **Nav notification v2 (2026-07-09, device-verified).** The ongoing notification now shows a
  large maneuver ARROW (white on teal, drawn per turn type incl. U-turn/merge/fork/roundabout/
  arrival flag), the turn instruction with distance, and "N min - X mi - Arrive HH:MM". Teal
  accent, lock-screen public, no stale timestamp. Demo-drive mode now runs the same foreground
  service so the notification is part of the demo (and screenshot-verifiable without a drive).
- ✅ **Self-hosted F-Droid repository (2026-07-09).** CI builds a signed F-Droid repo index and
  publishes it to GitHub Pages (`fdroid-repo.yml`); users add
  `https://pimpinpumpkin.github.io/Vela/repo` to any F-Droid client (fingerprint in FDROID.md).
  Serves latest stable + the newest nightly when it's ahead, and **suggests the stable**: a
  default install updates weekly on stables, while the nightly rides the same index as an
  unstable version for users who enable unstable updates for Vela in their client (same
  stable-first default as Obtainium). Rebuilds automatically after every successful CI run and
  weekly promote (a plain release trigger never fired for CI-created releases - GitHub's
  anti-recursion rule). The index key is a dedicated repo keystore (`~/.vela-signing/fdroid.p12`,
  secrets FDROID_KEYSTORE_BASE64/_PASS); APKs keep the normal Vela signature so install sources
  are interchangeable.
- ✅ **Lists map shortcut + export/import + light-mode status bar + nightly updates (2026-07-09).**
  A ribbon (bookmark) button leads the category-chip row and opens Your lists in its own dialog (lists no longer clutter the search page). Lists export/import
  to a JSON file from Settings (same flow as saved places). The system status-bar icons (clock, wifi,
  battery) now flip DARK in Vela's light theme - they were white-on-white and unreadable over the
  light map. And Settings -> "Include nightly builds" points the self-updater at the newest
  prerelease instead of only stable, for users who want the freshest CI build.
- ✅ **Parking history (2026-07-08, device-verified).** Every "save parking" is kept in a capped,
  newest-first history so an accidental overwrite is recoverable: **long-press the P button** for a
  restore menu, or **Settings → Parking history** to restore/delete individual spots. Clearing the
  current spot never wipes the history.
- ✅ **Import a Google Maps shared list (2026-07-08, first cut, device-verified).** Paste a
  maps.app.goo.gl share link into the search bar and the list's places land as results - the
  list title fills the bar, the map frames the pins, and each place opens/saves like any search
  hit. The owner's per-place NOTE ("I don't wanna go here alone!") survives the import and shows
  on the sheet as an italic quote under the address - the part of a shared list Google's own
  export throws away. Fully keyless: the share link resolves logged-out and the page embeds a
  ready-made `entitylist/getlist` request (no pb construction; see SPEC). Unit-tested against a
  captured payload. Next: first-class local lists to import INTO (issue #1's real ask).
- ✅ **In-store department hours (2026-07-08).** A department store's sheet lists each department
  under the main hours - Pharmacy, Fuel Station, Liquor, Delivery/Pickup windows - each with its
  own colour-coded status ("Closed · Opens 9 AM Thu") and an expandable 7-day table, split shifts
  included ("9 AM–1:30 PM, 2–9 PM"). The whole block is NESTED inside the main Hours expansion
  (2026-07-08 follow-up), so the collapsed sheet stays one clean line and the full schedule story
  lives behind one tap. Parsed from the whole `[118]` response list, the same block
  whose FIRST entry used to be misread as the store's status (the "closes soon at 10 PM over a
  5 AM–1 AM table" bug - the fix and this feature are the same discovery); store-name prefixes are
  stripped ("Safeway Pharmacy" → "Pharmacy"). Unit-tested + device-verified on a 5-department
  grocery store.
- ✅ **Tabbed place sheet** (Google-style): **Reviews** (rating summary + featured highlight + full list) and **About**. Layout order: **photos (hero) → info → hours → action row → popular times → tabs** (photos lead so they're visible at the peek height; popular times sit **below** the action buttons, like Google)
- ✅ **About tab = business description + attributes** - leads with Google's **editorial one-liner** ("Welcoming coffeehouse with handcrafted coffee…", node `[32][1][1]`), then the business's own **"From the owner"** blurb (`[154][0][0]`), then the attribute sections (Service options, Highlights, Accessibility, …). The description comes *before* the rest, per request. All three rich fields are trimmed from the keyless/list response, so they ride a lazy WebView detail fetch (`PlaceDetails`) - **wired on every open path** (search-result tap, **recents/saved**, and **POI taps**; the latter two were missing the call, so popular times + the summary silently never loaded there - fixed 2026-06-20). **That same fetch now also backfills the fields a *summary* node drops (2026-06-21):** searching a **suite / multi-tenant address** snaps to the business via a lightweight summary node that omits the **review count, full weekly hours, address, phone, website, price, attributes** (e.g. a nail salon at a `Ste A-2` address showed `4.4` with no count and only today's hours). The focused name+address re-fetch is a FULL place node, so `PopularTimesParser` lifts those off too and `MapViewModel` merges them into any field the summary left blank - **feature-id-gated** (only from the matching result, so a neighbour's rating/hours can't be grafted on) and purely additive (no fetch/match → unchanged, no regression). *(reviews themselves always loaded via the reviews RPC; this restores the count + the rest of the card.)*
- ✅ **Action link - Book / Reserve / Order online** (2026-06-21) - Google's primary action button (a salon's "Book online", a restaurant's "Reserve a table" / "Order online") surfaces as a **prominent tinted button** on the place sheet that opens the provider link; the label adapts per business type. Parsed from `[1][75][0][0][5]` (label `[0]`, URL `[1][2][0]`, calibratable as `actionLabel`/`actionUrl`) and **defensively gated** - no real `http(s)` URL → no button, so a shape change can't render a broken action. *(structure verified against a real "Book online" node + unit-tested; on-device visual check pending an unlock; reserve/order coverage for restaurants wants one restaurant capture to confirm the same slot.)*
- ✅ **Attribute highlight chips** (2026-06-21) - the most-scanned attributes (service options, offerings, accessibility, …) surface as a **horizontal chip row on the place overview**, Google-style, instead of being buried in the About tab; pulled from the already-parsed `About` sections (priority-ordered, deduped, capped at 6) so every place with attribute data benefits, including the ones the summary-node enrichment now fills in. *(compiled + reuses the verified card-row pattern; on-device visual check pending an unlock.)*
- ✅ **"People also search for"** (2026-06-21) - a place opened from a **focused name search** (a business searched by its full name) shows a Google-style **horizontal row of related-place cards** (name + rating); **tap one to open it** as a full place (its own reviews/hours/popular-times then load). Lifted from the search response's `root[2][11][0]` (`SearchParser.parseSimilarPlaces`, calibratable as `similar`), each entry `[featureId, name, [[_,_,lat,lng], …, rating@6]]`, attached to the primary result. *(Present only when the query focuses on one result - Google's own behaviour; multi-result list taps and bare-address snaps don't carry it. Device-verified: 8 related salons on a nail salon's page, tapping one opened it with full details.)*
- ✅ **"Also at this location"** - when other Google listings sit at the same spot (a co-branded shop's duplicate profile, a different unit at the address), the place sheet lists them with rating + category, tap to open - like Google's co-located-businesses section. Drawn for free from search results already in hand (no extra request). Matches on the **same street line** (e.g. "239 G St", suite-insensitive), not raw proximity, so a shop across the street isn't wrongly listed
- ✅ **Directions panel** (Google-style popup, not buried in the place sheet): tapping **Directions** opens the route chooser. **The From → To header is a card at the TOP of the screen now (2026-07-13, Google's layout):** the search bar swaps for an endpoints card - origin ring, connector dots, red destination pin, stops between, back arrow and a **swap (⇄)** button to **reverse the route** (you ⇄ the place) - so the endpoints stay visible and editable even with the chooser collapsed to its Start bar. The bottom panel keeps **Drive / Transit / Walk / Bike** tabs, and a prominent **Start** + **Steps**. For drive/walk/bike it lists the **route options** - each with a **traffic-coloured ETA** (green free-flowing → amber → red), distance, **via-road name**, a **"Fastest"** tag on the best, and a **"+N min" delta** on each slower alternate (2026-07-01) so you can weigh them at a glance the way Google does; **tap an alternate to select it** (the map line switches to it). Transit shows the results board instead. **Collapsing the chooser to its Start bar re-frames the route closer** (2026-07-14): the camera fit re-runs with the freed screen, so minimizing is how you get the big route view instead of the fit staying zoomed out for a panel that's no longer there. And **map taps during a live drive are inert** (2026-07-14): only a pick from the in-nav search results becomes a stop; a stray tap on a POI dot can't silently pin itself onto the route anymore.
- ✅ **Route from a different starting point** (not just your location) - the directions panel's **From** row is **tappable** (pencil affordance): pick any place via search and the route recomputes from there, like Google. Mirrors the existing **To** + **⇄ swap**; the search overlay covers the panel while picking and restores it on choose/cancel. Editable in **both directions** - the pencil sits on the "From" row normally, and moves to the "To" row when the route is reversed (that's where the custom endpoint then lives). A "Your location" reset row drops a custom endpoint back to live GPS.
- ✅ **Avoid tolls / avoid highways (LIVE 2026-07-11)** - sticky chips in the route chooser (drive). All 135 region graphs carry the avoid profiles (v2 rebake) and the app reads the v2 manifest, so any downloaded region routes around tolls and motorways on-device; verified on a Delaware toll road. The public OSRM rejects exclude, so an online-only route (no graph downloaded) still falls back to a normal route
- ✅ **Satellite view + a layers panel (2026-07-13/14)** - a map-corner Layers button (optional, Settings toggle) opens a Google-style panel: **Satellite view** (open Esri World Imagery tiles, keyless, attribution shown with the area's **capture year** under it), plus the live traffic, transit-lines and terrain overlays in one place. Satellite mode is a real hybrid: translucent **ghost roads** keep the network readable under tree cover (freeways tinted yellow like the Google app), every map label flips to **white with a black halo**, and the POI teardrops go white so icons read over imagery. Overlays layer correctly above the photo; toggling back restores the normal palette cleanly.
- ✅ **Numbered stop pins on the map (2026-07-14)** - a trip's intermediate stops draw as teal pins numbered in visit order while the chooser is open or the drive is running; reordering stops in the editor re-numbers the pins immediately.
- ✅ **Multi-stop directions (waypoints)** (2026-07-01) - an **"Add stop"** row between From and To (Google-style) opens the same place picker; the pick becomes an intermediate stop and the route recomputes **straight through it**, with each stop **removable** (×). Routes OSRM through `origin → stops… → destination` (`routeVia`, which filters the spurious per-via arrive/depart into one continuous trip) and overlays Google's live in-traffic ETA ratio; a waypointed trip is a **single route** (no alternates). Stops reverse with **⇄**. Device-verified (Davis→Sacramento: adding a mall stop rerouted the trip a few minutes longer via a through-path, remove reverted to the direct route + alternates). *Stops editor 2026-07-08 (user: the inline arrow/X cram was ambiguous):* the panel header now shows ONE compact tappable summary of the stops; tapping it (or the pencil) opens a **dedicated stops editor sheet** (`StopsEditorSheet`) - origin at top, each stop a row with a **drag handle** (drag past a neighbour's midpoint to swap), numbered dot, and X, destination pinned last, Add stop + Done under the list. Edits are local until **Done** applies them in ONE reroute (`applyStops`); back/X discards. Under D-pad the rows show up/down arrows instead of the (undraggable-by-key) handle. *Glyph grammar (2026-07-08):* the origin wears a **location-blue pin** when it's your current position (the non-verbal "this is you"), the destination a **checkered flag** - in the directions header AND the editor; header rows share a fixed-width icon rail so the glyphs align, and the stop summary shows the first stop plus a **+N** badge.
- ✅ **Long-press to route through a point (2026-07-12).** While a route is being planned (the directions panel is up), **long-pressing any spot on the map adds it as a via-stop** and the route reroutes straight through it, with a "Stop added" confirmation. It's the quick, Google-like way to grab an arbitrary point - no search, no crosshair - and it's the practical way to steer a route **around** an area (a construction zone, a Flock-camera stretch): Google's keyless directions and OSRM can't be told "avoid this region", but a hand-placed waypoint forces the detour. The stop sits at the exact point pressed (the reverse-geocode only names it), reuses the existing multi-stop pipeline (removable/reorderable in the stops editor), and only fires while planning so a normal long-press still drops an inspect pin. **Device-verified** (a long-press mid-route added a trailhead as a stop and the ETA/line rerouted through it). Localized in all supported languages.
- ✅ **Multi-stop follow-ups** (2026-07-01): (1) **per-stop arrival cue** - nav announces "You've reached &lt;stop&gt;" as you pass each waypoint (`NavEngine.stopMarks` projects each stop onto the route line → an along-route metre "mark"; `NavSession` fires the voice cue in order as progress passes it - unit-tested, `NavEngine` untouched); (2) **reroute-through-remaining** - an off-route reroute (and the faster-route recheck) now route through the stops you **haven't reached yet**, instead of straight to the final destination (which used to silently drop them); the reaches-dest nav-safety guards are unchanged (the route still ends at the same dest). (3) **Reorder** - up/down arrows on each stop row (with 2+ stops) reorder them and re-route (`moveStop`).
- ✅ **Depart / arrive time (+ date, + Last available)** - one **Leave now / Depart at / Arrive by** chooser at the top of the directions panel (a **Last available** chip too in transit), applying to all modes, with **both a time field AND a date field** (plan any upcoming day, Google-style). Picking a time **re-fetches transit** for that moment: Google's board is time-dependent, so `WebDirectionsFetcher` inserts Google's time block into the `/maps/dir/…` data param - `!4m6!4m5!2m3!6e{0=depart,1=arrive,2=last}!7e2!8j<unix-seconds>!3e3` (the `!4m` wrappers are *descendant* counts, verified against a real Google transit-with-time URL; an earlier `!4m8!4m7` guess had the wrong counts and Google silently fell back to "now"). For drive it also shows the honest arrival/leave **window** from Google's own typical best→worst spread (`summary[10][4]` → `Route.typicalRangeSeconds`, e.g. "arrive 6:08–6:27 PM · in typical traffic"). Per-*minute* future-traffic prediction on drive stays login/Android-app-only, so drive surfaces the spread Google itself plans with rather than a false-precision single time
- ✅ **Search along route** - with a trip planned, the directions panel shows **Gas / Food / Coffee / Groceries** chips; tapping one searches near the route and shows only the results **within ~3 km of the route line, ordered start → destination** (so you find stops actually on the way). The route stays drawn. *Overhauled 2026-07-08:* each result now shows its **distance along the trip** (metres from the route start to where it sits), not the old crow-flies distance from the route midpoint (two stations at opposite ends both read "5.9 mi"); **tapping a result adds it as a STOP on the trip** and returns to the directions panel with the destination intact (it used to open the place's own sheet, whose Directions button silently replaced the whole trip); picking the destination itself or closing the results (X) just returns to the panel. The trip's destination is stashed in `alongRouteDest` while browsing. **Works DURING nav too (2026-07-13):** a search button floats on the nav map's right edge (with the volume toggle - the bottom bar keeps just ETA, Steps and End) and opens the chips PLUS a free-text field for arbitrary searches above the bar; a pick searches the remaining route, the results list takes the bottom slot (BACK peels it, never ends the drive), and tapping a result inserts it as the NEXT stop on the live drive (`NavSession.addStop` replans through it, voice says rerouting, remaining stops keep their order).
- ✅ **Consistent sheet styling** - the place sheet, directions panel, route chooser, **steps list**, nav bar, **the search-results list, the full-screen search page, and the "set as Home/Work" banner** now all share one Google-grey palette (`ui/SheetPalette`: `#1F1F1F`/`#FFF` surface, fixed ink/dim text, teal accent, green/amber/red traffic) instead of differently-shaded Material-You-tinted cards
- ✅ **Permanently-closed (dead) POIs** - detected from the place node's **`[23]==1` flag** (the reliable signal - a dead POI like Caffé Italia carries no open/closed status text at all, so the earlier text-only check missed it; the flag survives the keyless degraded response, calibrated live 2026-06-19), plus a "Permanently" text fallback. They **stay in search results** (labelled "Permanently closed" in red, in both the row and the place sheet) but are **dropped from the map pins** so they don't clutter the map (a place you explicitly open still gets its pin)
- ✅ **Alternate routes** - Google's 2-3 driving alternates are surfaced + selectable in the directions panel (e.g. "20 min · via I-80 E" / "21 min · via Co Hwy E6"); each draws along **Google's OWN route geometry** (delta-encoded in the response at `[0][7][i]`, decoded directly) so the line matches the via-label exactly, alternates included - **no more lines that double back on themselves or cut straight across** (the old scattered-point guess is gone; an open router is now only a fallback for routes Google omits geometry for)
- ✅ **Alternates drawn greyed on the map + tappable** (Google-style) - the non-selected routes render as **grey lines beneath the active blue one** (theme-aware shade so they read on dark/light tiles); **tap a grey alternate to switch to it** (same as picking it in the panel). The directions camera now also **frames the whole route above the panel** (per-edge bottom padding) instead of centring it behind the card *(rendering + framing verified on-device, Davis→South Lake Tahoe: grey I-80 arc alongside the blue US-50 route)*. The route line is drawn **below the basemap's label layers** (Google-style), so **road names and POI text stay legible on top of it** instead of being painted over *(2026-06-21)*
- ✅ Place sheet **peeks** (~56% screen) so the business info isn't immediately full-screen and the map stays visible above it; **drag the handle up to expand** (~92%, for the reviews), down to shrink, down again to dismiss. The body scrolls, so a tall place (hours + tabs) is fully reachable at either height
- ✅ **Pin stays visible above the sheet** - opening a place pushes the map's optical centre up by the sheet height (MapLibre bottom padding) and zooms in, so the pin sits in the visible strip above the card instead of being hidden behind it (Google-style)
- ✅ **Popular / busy times** (Google-style histogram in the place sheet, day chips + "busy right now") - **keyless, 2026-06-19.** Two catches fooled us. First: the keyless **OkHttp** search is bot-degraded (TLS-fingerprint, like photos/transit) and strips the `[84]` histogram, so we wrongly called it login-gated - a real browser engine isn't degraded. Second (the subtler one): even in the WebView, a **bare-name** search returns a 20-result `[64]` list *also* trimmed of `[84]`. The fix is a **specific query (name + address)** - that resolves to a single focused result whose `[0][1][0][14]` node keeps `[84]`. `WebPopularTimesFetcher` (warms google.com→maps, builds the name+address query into the `pb` + `q=`, same-origin-fetches it) + `PopularTimesParser`, wired lazily on **every** place-open path (search-result tap, recents/saved, POI tap - the latter two were missing it, fixed 2026-06-20). Since the fetch is slow (~10–20 s, real WebView) - and pre-warmed on search, so the first place you open after searching loads faster, the sheet shows a **"Loading popular times & details…" indicator** while it's in flight, so it reads as *loading*, not *missing* (clears to the chart, or to nothing for a place with no histogram)
- ⬜ "hours updated N ago" (place-RPC-only, absent from the search response); Updates/posts tab
- ✅ **Reviews now load MANY (~40, capped 50), not 3** (2026-07-01) - the buzzkill fix. Three root causes in `WebReviewsFetcher`: (1) the hidden WebView was **0×0** (never attached), so Google's **virtualized** review list - which lazy-loads off the scroll viewport - rendered only its chrome (rating histogram, topic filters) and **never the review cards**; giving the WebView a real **offscreen viewport** (`measure`+`layout` to 1200×3200) makes the scroll pane real so the list renders + pages. (2) The card detector was a fragile "div with one star + text" heuristic that matched the **place header** ("4.6 stars (57,969)") and affiliate ticket cards instead of reviews; it now selects **`.jJc9Ad`** cards directly and **accumulates across scroll windows de-duped by `data-review-id`** (the panel recycles DOM nodes on scroll, so any one snapshot holds ~10 - the union is the full list). (3) **The "still 3 on ordinary businesses" bug** (attractions worked, food/retail didn't): on busy business pages (Taco Bell, restaurants) the Reviews list takes **~8 s to render** after the tab is clicked, and the scraper's idle-termination (`atBottom && noGrow`) was counting that **blank pre-render window** as "done" - so it bailed with only the 3 overview cards before the full list ever appeared. Fixed by (a) opening via the **"Reviews" role=tab** (clicked-until-`aria-selected`, so a click on a not-yet-hydrated tab retries instead of no-opping - and never re-clicks a selected-but-loading list, which restarts its render), and (b) gating the idle-bail on review cards being rendered **at bail time** (`cardsNow`, per-tick). *(First shipped as a once-latched `sawCards` flag - that still had a timing hole: the OVERVIEW's 3 preview cards latch it just before the tab click blanks the panel, so unlucky timing still bailed with 3 (seen on Cheesecake Factory). The per-tick check closes it: an empty panel can never satisfy the bail, no matter what rendered earlier. A no-tab/no-button layout - a tiny place whose full list IS the overview - gets a 14-tick leash then returns what's rendered.)* **Per-review photos are preserved** (same per-card scrape). Device-verified: Taco Bell (612 reviews) **3 → 50**, Pike Place Chowder **3 → 37**, a landmark **37 → 46** - all with photos, author, stars, dates. *(Ships in the app - compiled JS, not remotely hot-fixable.)*
- ✅ **In-app neural voice - runs INSIDE Vela, no standalone app.** **CURRENT STATE (as of 2026-07-04): the neural voice is Piper.** A fresh install downloads **HFC Female** (`en_US-hfc_female-medium`, ~67 MB, single-speaker) into `filesDir/piper/<id>/`, run in-process by **`PiperSynth`** (sherpa-onnx VITS → `AudioTrack`) behind `:core`'s `VoiceGuide`/`NeuralSynth` seam, and it becomes the default once present. **Kokoro AND Matcha were tried and REMOVED** (Kokoro was ~0.4× realtime even on a Pixel 9); `MapViewModel` reclaims their old model dirs + sanitizes stale `vela.kokoro`/`vela.matcha` prefs to Piper. **The dated chronology that follows is the HISTORY of how it got here (Kokoro → +Piper → Piper-only → HFC Female default) - read it as a changelog, not the current design; the 126 MB / af_heart / `KokoroSynth` / `filesDir/kokoro` references below are all superseded.** ⤵
  *(Historical:)* the first iterations shipped **Kokoro** (int8 then fp32) and later **Matcha** as downloadable neural voices alongside Piper, with an installer, playground and upgrade path each. On-device A/B killed both: Kokoro ran ~0.4x realtime even on a Pixel 9 and Matcha read drier than Piper. **SIMPLIFIED to Piper-only (2026-07-02):** Kokoro and Matcha were **removed**. **Piper is now the sole neural voice** ("Vela voice"), default, real-time even on a 5-year-old phone - the right fit for budget Android. `VelaKokoro`/`KokoroSynth`/`VelaMatcha`/`MatchaSynth` deleted; Settings shows one **"Download the Vela voice"** button + the playground; system TTS engines still enumerable for override. Stale `vela.kokoro`/`vela.matcha` engine prefs sanitize to Piper on launch. (Future "faster Kokoro" would need a different runtime like ExecuTorch - a rewrite, parked.) **Voice = libritts_r + speaker picker (2026-07-02):** swapped the Vela voice model from `hfc_female` to **`vits-piper-en_US-libritts_r-medium`** (the most expressive Piper English voice - trained on richer speech), which is **multi-speaker (904 voices)**. Since no single speaker is "best", Settings → Voice → playground gains a **"Voice variant ◀ N ▶ of 904"** stepper: each tap speaks a sample and persists the choice (`voice_speaker` pref; `PiperSynth` reads + clamps it, exposes `numSpeakers`). Device-verified: downloads (~82 MB), loads (904 speakers, no crash), stepping speaks a preview in ~410 ms (realtime). **Type-a-number jump (2026-07-02):** since stepping through 904 one at a time is tedious, the picker also has a **"Variant #" number field + Go** - type a speaker number and it jumps straight there (clamped to range), persists, and speaks a sample (`MapViewModel.setSpeaker`). Device-verified: typing 14 → "Voice variant #14 of 904" + preview. **Voice speed + remote-settable defaults (2026-07-02):** Settings → Voice gains a **"Voice speed · N.NNx"** −/+ 0.1 stepper (0.5–2.0×, each tap speaks a preview) - for the neural voice a per-utterance Piper `speed` multiplier (`PiperSynth.speed()`), for AOSP engines a live `TextToSpeech.setSpeechRate` (`VoiceGuide.setRate`); device-verified 1.00→1.10× re-spoke the sample faster. The **default speaker AND default speed are remotely settable** without an app release: `Calibration.defaultVoiceSpeaker`/`defaultVoiceSpeed` ride the signed `calibration.json`, and `PiperSynth`/Settings seed the picker + speed from them (a user's own pick always wins). Shipped defaults (calibration **v8**): speaker **14** (picked by ear) and speed **0.8×** (a measured, easy-to-follow nav cadence), matched in the compiled `Calibration.DEFAULT`. **Clearer pauses at periods (2026-07-02):** the neural voice **splits each utterance on sentence boundaries (. ! ?) and splices ~0.32 s of silence between**, so a two-part prompt ("Starting navigation. **‹beat›** Turn right onto Main Street") gets a real beat instead of running together. The split is name-aware (`SpeechText.splitSentences`, unit-tested in `:core`): it only breaks at a period when the preceding word isn't an abbreviation/road word ("Jr.", "Mt.", "St.", "Blvd.", "N.") and the next clause starts capitalized - so "Martin Luther King **Jr.** Boulevard" is never split mid-name (a bug an adversarial review caught before ship). sherpa-onnx's own `silenceScale` config was tried first but is a **no-op on the Piper/VITS path** (A/B-measured on-device: 0.2 vs 1.4 → identical 2.5 s audio), so the pause is spliced in-app; single-sentence prompts are returned unchanged (no latency cost). Device-verified: a 2-sentence phrase 2.5 s → 2.7 s with the beat. **In-app voice browser - download & switch between many Piper voices (2026-07-03):** Settings → Voice → **Voice library** is a browsable catalog of ~23 curated Piper voices (the ones on the sherpa `tts-models` release), grouped US / British, each row showing accent · gender · quality · size + a one-line "sounds like" note, with per-row **Download / Use / 🗑**. Download several, switch between them (Use plays a sample), delete to reclaim space - the ★ voices (Lessac, HFC Female, HFC Male, Ryan, the LibriTTS-R default) are the closest to a Google-Maps read. Each voice lives in its own `filesDir/piper/<id>/` dir; the installed set is derived from the filesystem (a partial download self-heals), the pick persists in `voice_model`, and **speaker choice is now per-voice** (`voice_speaker_<id>` - libritts_r's 904 variants don't bleed onto single-speaker voices; the variant picker hides for those). `VelaPiper` generalized from one hardcoded model to a selected-id + registry; `PiperSynth.reloadVoice()` is a race-free single switch trigger (generation-bump + worker-serialized teardown → no use-after-free of the sherpa engine mid-utterance); a one-time migration relocates the old flat single-voice install in place. **Also fixed a pre-existing download bug:** the shared OkHttp client's 12 s `callTimeout` (added for scrape-bounding) was aborting any model download that couldn't finish the body in 12 s - the installer now uses a no-call-timeout client. Device-verified on a Pixel 5a end-to-end: migration preserved the existing voice + speaker, downloaded HFC Female (67 MB), switched both directions (engine reloaded, no crash), two voices coexisting at 149 MB. Catalog is compiled-in for now (`PiperCatalog`, `:core`, unit-tested); hosting it on the signed `calibration.json` is a future bet. **Street numbers read the human way + no clipped start (2026-07-03):** three-digit street ordinals are now spoken as people say them - "**120th** Street" → "one twentieth Street", not the neural G2P's stuttery "one, hundred and 28th" (`SpeechText.spokenNumbers`, unit-tested in `:core`, wired into `VoiceGuide.forSpeech`; only 3-digit ordinals 100–999 - espeak reads "5th"/"42nd" fine and 4-digit+ are left alone). And the very first prompt no longer cuts itself off: `NavSession.start` already speaks the depart ("Starting navigation. Head east on F St"), but `NavEngine` was **re-announcing the DEPART maneuver** (it sits at the start point, distance ≈ 0) and interrupting the opener with "a similar direction" - the engine now **skips the DEPART entirely and advances silently** to the first real turn (which announces itself on approach, as Google does). *(Piper's audible in-breaths between clauses are a VITS model artifact, not tunable without a different model - a known limitation.)* **New default voice = HFC Female @ 0.8× (2026-07-03, calibration v10).** After auditioning the browser, the user picked **HFC Female** (`en_US-hfc_female-medium`, bright + clear + very Google-like, single-speaker, 67 MB) as the fleet default over libritts_r. The default voice id is now itself remote-settable - `Calibration.defaultVoiceId` rides the signed bundle (like `defaultVoiceSpeaker`/`defaultVoiceSpeed`), so onboarding downloads it and a fresh install activates it; a user's own `voice_model` pick still wins. Compiled `VelaPiper.DEFAULT_VOICE_ID` + `calibration.json` v10 both set HFC Female + speed **0.8×**; `defaultVoiceSpeaker=14` stays but now only tunes libritts_r (the multi-speaker voice) when someone picks it. Nav prompts already carry the commas/periods that make Piper flow (the "In <dist>, <instruction>" comma + the sentence-split pause), so no manual punctuation is needed on real routes. **Voice library goes multilingual (2026-07-03, first step of app localization):** `PiperCatalog` generalized from US/GB-only to **any language** - it derives `langCode`/`region` from the voice id and the browser now **groups by language** (English first, then by endonym: Français, Deutsch, Español, Italiano, Português, Nederlands, Русский, Polski, Svenska, Українська), each with a recommended default (`fr_FR-siwis`, `de_DE-thorsten`, `es_ES-davefx`, `it_IT-paola`, `pt_BR-faber`, `nl_NL-alex`, `ru_RU-irina`, …). You can download + audition any of them in the playground now; full locale *pairing* (French UI + French nav text + a French voice, auto-suggested from your phone's language) lands with the [localization work](ROADMAP.md) in progress. **Spoken navigation now speaks 10 languages (2026-07-03).** The whole generated nav voice - turns, distances, the "In X, …" frame, lane guidance ("use the right 2 lanes"), start/arrival/stop/faster-route - is localized via a per-language `NavStrings` table in `:core`, and **auto-follows the phone's language** (`AppLocale`, default = system): **English, French, German, Spanish, Italian, Portuguese, Dutch, Russian, Polish, Swedish, Ukrainian**. These are per-language *templates*, not word swaps, so grammar is right (German dative "In 400 Metern", Slavic plural-noun agreement, Italian side-noun vs adverbial, Dutch separable verbs "de X op", Swedish "engelsk mil" to disambiguate the 10 km Scandinavian mile) - each translation drafted then corrected by a native-speaker review pass. English stays byte-identical (existing nav tests untouched); road/street names are never translated (they're data). Unit-tested (every language non-blank + preserves road names). A French phone already gets fully French turn-by-turn given a French voice; the visible UI chrome + Google POI content localize next. **Voice ↔ language pairing (2026-07-03).** So the nav text and the voice speak the *same* language, onboarding's one-tap install now grabs the voice that **matches the app language** (`PiperCatalog.defaultFor(lang)` - a French phone downloads `fr_FR-siwis`, not HFC), the Voice library **floats your language's voices to the top** (Google-style), and if your language is non-English with no matching voice installed it shows a **download nudge** ("Your app language is Français - download a Français voice so spoken directions match"). English still gets the remote-settable fleet default (HFC). **In-app language picker (2026-07-03).** Settings → **Language** lets you override the app language independent of the phone's system setting (Google-Maps style): "Follow system" (default) or any of the 11 by endonym (English, Français, Deutsch, Español, Italiano, Português, Nederlands, Русский, Polski, Svenska, Українська). It drives `AppLocale` → the spoken-nav language today (and the voice-library sort/nudge); the visible UI chrome switches with it once the `strings.xml` extraction lands. **UI chrome externalized to resources (2026-07-03).** All ~330 user-facing :app strings (Settings, place sheet, map, search, nav overlays, welcome, the foreground-nav notification) were moved out of inline Kotlin literals into `res/values/strings.xml` (English), referenced via `stringResource`/`getString` - the foundation for translating them. English is byte-identical (no visible change); a runtime locale switch (`MainActivity.attachBaseContext` + `AppLocale.wrap`, no-op when following system) re-reads them in the chosen language after a `recreate()`. A handful of **dual-purpose** literals were deliberately left inline (they double as logic keys - "Open"/"Closed" feed the status-colour parser, the search-along-route chips "Gas"/"Food"/… are also the query, the review sort/tab labels branch a `when`); those localize once display text is decoupled from the logic key (same "decouple detection from English" linchpin as the POI content). **The visible UI now speaks 10 languages (2026-07-03).** The externalized strings were translated (machine-translated then native-speaker-reviewed, per language) into **French, German, Spanish, Italian, Portuguese, Dutch, Russian, Polish, Swedish, Ukrainian** - `res/values-<lang>/strings.xml` × 10 (330 strings each). Every translation's format-placeholder set was validated against English before writing (a mismatch omits that one string → Android falls back to the English default, never a crash); all 3300 passed. Picking a language in Settings → Language (or following the phone locale) re-creates the Activity and the whole app - Settings, search bar, place sheet, nav overlays, welcome, the foreground-nav notification - renders in that language, alongside the already-localized spoken directions. **Device-verified on a Pixel:** English → Français switched the entire UI live (Paramètres, Impériales, Langue…), persisted across navigation, and round-tripped back to English with no crash; place names stayed untranslated (data). The native reviews caught real localization bugs the raw MT missed (French "Mo" not "MB", Italian "Passaggi" for route steps so it doesn't collide with "tappa"=stop, German noun capitalization, French `%` spacing). **Google POI content now comes back in your language too (2026-07-03) - the last i18n layer.** The scrape's `hl=en` is rewritten to the app/system language at request time (`GoogleMapsDataSource.localized()`, no-op for English → English users byte-identical), so **categories, hours, open/closed status, price and distances arrive localized** ("Ouvert · Ferme à 19:00", "Pizzeria", "09:00–19:00", "10−20 $", "549 m"). The linchpin - open/closed detection used to string-match English "Open"/"Closed" and would have broken - is solved by **matching the localized status TEXT against a per-language keyword table** (`SearchParser.parseOpenNow(status, lang)`, closed-words-first for every language, `lang` = the same `Locale.getDefault()` that set `hl=`); `placeStatusColor` colours from that boolean, so an open place is green in every language. *(Correction 2026-07-04: the first fix read a "locale-independent numeric status code" pinned from an `hl=fr` capture - a live EN capture then DISPROVED those ints (closed pharmacies carried the "open" code 6, an Open-24-hours business carried 13/4 → rendered red); they're span/style markers, not status codes, and the code path was removed. Text is authoritative - it's the same string the user sees, so colour can never contradict the words.)* Permanently-closed uses the numeric `[23]` flag, which IS real. **Device-verified on a Pixel:** searched in French → results + place sheet showed French categories/hours and a **green "Ouvert"**, English unchanged (still "Open · Closes 7 PM" green). Pinned by driving a temp `hl=fr` build + reassembling the 771 KB response from logcat. **Voice ↔ language mismatch handled (2026-07-04).** A Piper voice is a **single-language** model, so overriding the app/system language to one whose voice isn't downloaded made the *installed* voice read the new language - the English HFC voice literally reading Russian nav text (gibberish). Now `NeuralSynth.voiceLanguage` exposes the loaded voice's language (id prefix) and `VoiceGuide.speakNow` compares it to the language the nav text is generated in (`NavStringsRegistry`): on a mismatch it **routes to Android `TextToSpeech` in the target language** instead (lazily creating a default engine as the fallback - the system TTS is no longer shut down when the neural voice is active), and if the system has no voice for that language either it stays **silent** rather than mangling it, flashing a **"get a &lt;language&gt; voice in Settings → Voice"** hint (`langUnavailable` → `MapViewModel`). Same guard covers a whole-phone locale change. **Device-verified on a Pixel 5a:** app language → Русский with only the English voice installed produced **no** neural playback (correctly bypassed, no crash); switching back to English spoke normally through the neural voice (`PiperSynth: spoke 3.9s audio`). **Voice library language groups collapse (2026-07-07).** The ~40-voice catalog was one long flat scroll (a Reddit report). Each language is now its own collapsible sub-group with a voice-count badge and a chevron; a group opens by default only when it's your app language or already has a voice installed, so you see your own language plus whatever you have and the rest stays folded. A search in the box forces every group open so matches aren't hidden. Per-language toggle state (`langExpanded` map in `VoiceLibrary`); the whole Voice library section stays behind its own collapsible header as before.
- ✅ **POI hero photos - LRU cache (2026-07-02):** `WebPhotoFetcher` keeps an access-order `featureId → List<Photo>` cache (cap 32), so re-tapping a place (or bouncing back from directions) shows its gallery **instantly** instead of re-running the ~20 s scrape. (They already used the warm, streaming hidden WebView + the instant search-response preview; this closes the revisit gap.)
- ✅ **Reviews pivot follow-ups (2026-07-02).** (a) **Native review search emboldens the matched term(s)** in each result (author + text, case-insensitive `emphasize()` → AnnotatedString bold). (b) **Full-screen panel bugs fixed:** it rendered nothing until you toggled a chip, and photos/videos wouldn't open - both were the nested-panel carve fighting Google's own page. In full-screen the carve no longer pins `[role=main]` (`position:fixed` made main the containing block for Google's `position:fixed` lightbox → off-screen; `overflow-y:auto` hijacked scroll from Google's inner list so its virtualizer never paged → the "select a chip then back to All" bug) and skips `stretch()`; content now renders on first paint (device-verified 128 cards immediately) and **review photos are tappable → Vela's native gallery** (Google's own photo viewer is a page-nav the lockdown blocks and the carve can't host - verified a raw click with the carve fully removed still opens no viewer, so we intercept → native `PhotoGallery`, captioned "Author · date"). *(Video reviews still don't PLAY in full-screen - same nav/host limitation; a video's poster may open as a still. Open.)* (c) **Place sheet handle:** bigger hit target (36dp tall strip), **tap toggles expand/peek**, and **scrolling into the content grows the sheet to full height** Google-style (the nested-scroll handler expands on an upward scroll). Device-verified: bolded "beer" matches, full-screen photo→gallery, smooth Google scroll. (d) **Native review photo caption reliability (2026-07-02).** The inline review-photo caption ("Author · date") is only as good as the DOM scrape, and two things made the **date** and the **photo strip** flaky place-to-place (why author/date showed on one device/place but not another - same build, different live-DOM luck, NOT version skew): the date fallback grabbed the **first span merely containing "ago"** (so a short sentence in the review body could win) and only knew English "ago"/bare-year; and the photo collector read **only `<button>` background-images**, so a card whose uploaded photos render as `<img>` tiles got **no tappable strip at all**. Hardened in `WebReviewsFetcher`: the date fallback now anchors to the **full relative-date shape** ("10 months ago", "a year ago", "Edited 2 weeks ago") or a lone year, skips owner "Response" lines, and **skips any span whose text is part of the review body**; the photo collector now also sweeps `<a>` backgrounds and `<img>` `src` (avatar-filtered) so `<img>`-rendered photos are caught. *(Hero photos above the place name are a separate, still-unbuilt case: the fast WebView gallery scrape captures only image URLs - no contributor name or date - so `place.photoDates` is empty on that path and the hero caption has nothing to show. Adding it is net-new gallery-DOM scraping, tracked separately.)* **(e) Caption invisible on Android 15/16 - the real root cause (2026-07-04).** The "author/date still doesn't show" report reproduced on a stock **Pixel 9 (Android 16)** but NOT a Pixel 5a (Android 14). It was NOT the scrape (an on-device dump proved the caption reached `PhotoGallery` correctly, `val=[Theresa Jerome · 7 months ago]`) and NOT off-screen (a position probe showed it laid out on-screen at y≈2244 of 2424). The real cause: **a full-screen Compose `Dialog` on Android 15/16 doesn't propagate window insets to its own content (`navigationBarsPadding`/`safeDrawingPadding` read ZERO inside it) AND its window is clipped by the nav-bar strip** - so a `BottomCenter` caption was measured on-screen but sat in the clipped bottom ~180 px and **never painted** (a bright-red debug background at the bottom drew nothing; the same caption at `Center` drew fine - that isolated it). Reading the parent's insets didn't work either (the place-sheet is itself a modal, so its inset context is wrong). Fixed with a **fixed bottom clearance** (`padding(bottom = 88.dp)`) that keeps the caption in the drawable area regardless of the broken insets, plus a dark scrim pill for legibility. **Device-verified on the Pixel 9**: "Theresa Jerome · 7 months ago" now shows. (The earlier `safeDrawingPadding` attempt in 0.2.285 was based on a wrong overflow theory and didn't fix it.)
- ✅ **Reviews = native inline list + full-screen "Read all" Google panel (2026-07-02, THE ARCHITECTURE PIVOT - supersedes the inline-embedded panel below).** After days fighting scroll jitter in the inline-embedded panel, a workflow probe confirmed it's **inherent**: a Chromium-composited scroller nested inside a Compose scroll can never share a frame clock, so the top-boundary seam is always latent (three unsynchronized loops meet there - stale JS edge-state gating at touch rate, `dispatchRawDelta` racing the WebView's own scroll, async header re-insertion on disengage). Resolved by SPLITTING: **inline place-sheet reviews are now Vela's own NATIVE list** (`ReviewsTab`, a native `LazyColumn`) - smooth by construction, zero jitter, zero Google-chrome flash; review photos are **tappable** → the shared `PhotoGallery`, captioned "Author · date" (device-verified "Sammie Smith · 10 months ago"). A **"Read all reviews" button** opens the live Google panel **FULL-SCREEN** (`FullScreenReviews` → `GoogleReviewsPanel(fullScreen=true)`): no nesting, so Google's own **infinite scroll, server-side search, Sort, topic chips, AND native photo/VIDEO viewers** work (videos play) - dark-themed, back-to-close top bar. In full-screen the carve is lighter (a `FULL` flag skips the scroll-sync touch listener, the photo interceptor, and the native histogram/chips carve - Google's own controls show). The `LiveReviews` toggle now gates that button (Settings → Map: "Read all reviews button"). The native scrape (`WebReviewsFetcher`, ~50-cap, streams in) always runs now. **Device-verified end-to-end** (Boundary Bay: native list streams smoothly, photo→gallery caption, Read-all→full Google page with histogram/search/chips/photo-grids, back closes clean). *(The old inline scroll-sync machinery - delta-forwarding, engaged mode, edge bridge - is retired from the inline path; that code now serves only the full-screen view, where nesting doesn't exist so it's mostly dormant.)*
- ✅ **~~LIVE Google reviews panel - inline-embedded (2026-07-01)~~ → now the FULL-SCREEN "Read all" view (see pivot above).** *(History of the embedded approach retained below.)* The Reviews tab embedded **Google's own reviews pane in a visible WebView**, CSS-carved down to just the panel: loads at browser speed, **auto-pages as you scroll** (no polling loop, no cap - all 612 of a Taco Bell's reviews are reachable), and keeps **Google's own review search + Sort** (server-side, searches ALL reviews - the native search only filtered the ~50 scraped). Dark/light follows Vela's theme (invert+hue-rotate filter scoped to the panel, images re-inverted). **Trackers/beacons are blocked** at the network layer (`shouldInterceptRequest` feeds `/gen_204`, `play.google.com/log`, analytics/doubleclick/adservice hosts an empty response) and **every navigation after the initial load is blocked** - no tap can leave the panel. When the toggle is off (or the carve fails - Google markup shift), the tab **falls back to the native scraped list** automatically, and the background scrape only runs in that fallback (no wasted 20 s scrape behind the panel). The panel is **stripped to just the reviews** - Google's Overview/Menu/Reviews/About tab bar, the "Order online" promo block, the **"Write a review" button**, and each review's **Like / Share / ⋮ buttons are removed** (the last is a deliberate block - it leads to Google sign-in), and the background is **Vela's exact sheet colour** (`SheetPalette` #1F1F1F dark / #FFFFFF light) so there's no seam: `<body>` carries the colour while the panel content and every ancestor are transparent (in dark, only the content inverts, not the backdrop). **Google's own controls work embedded (2026-07-02):** Sort (Most relevant / Newest / Highest / Lowest) and the per-review/photo popups were dead because Google renders them into portal containers the carve had hidden (empty at carve time); a `revealOverlays()` pass un-hides those portals on tap, lifts them above the panel, clamps a menu that would overflow the viewport, and (dark) inverts them to match. The reviews-search keyboard now drops on submit (blur on Enter/`search`). Dark-mode **rating stars are re-inverted to true gold** (a scoped double-invert). **Tapping a review photo opens Vela's own full-screen gallery** (2026-07-02) - Google's embedded viewer renders nothing inside the carve, so the tap is intercepted, that review's photo URLs are collected + upsized (`=s1600`) and handed to the native `PhotoGallery`, **captioned "Author · date"** (e.g. "Ali W · 5 months ago" - author from `.d4r55` / the avatar's "Photo of …" label, relative date from `.rsqaWe`). **Photos are keyed off `jsaction*="review.openPhoto"`, NOT the aria-label (fixed 2026-07-02):** Google labels *some* photos descriptively ("Mixed dumplings with rye bread…") instead of "Photo N on …", so the old label-regex silently dropped them - the tapped one wouldn't open and the strip collected only its siblings (the "first pic won't open, shows 1/1" bug, reproduced + DOM-verified on Thais Miller's review of Pel'meni: 2 photos, only 1 matched → now 2/2). The URL now reads from inline bg, computed bg, **or a child `<img>`**. The panel now shows **only a spinner until the reviews actually paint** (gated on review cards present, with a grace fallback for zero-review places / class rotation) - no more Order-online-button flash during load. **Scroll-sync (2026-07-02, v2 - manual delta-forwarding):** the panel used to hog *every* vertical gesture (its `OnTouchListener` always `requestDisallowInterceptTouchEvent(true)`), so a finger on the panel could never move the Vela sheet - once you scrolled into the reviews you couldn't scroll back out (the panel fills the sheet). Now the page reports the reviews scroller's **top/bottom edge** over a JS bridge (`onPanelEdge`), and at a boundary - reviews at their top + finger dragging down, or bottom + up - the touch listener **forwards the raw drag deltas** to the sheet, which scrolls its body 1:1 with the finger (`bodyScroll.dispatchRawDelta`), then past the body's own ends mirrors the sheet's normal drag behaviour (collapse → dismiss on a pull past the top; expand on a push past the bottom); finger-up velocity carries a boundary fling into the sheet. Mid-list gestures stay 100% with the reviews. **v1 tried gesture HANDOFF instead** (flipping `requestDisallowInterceptTouchEvent(false)` at the boundary so Compose would steal the stream) - **don't go back to that**: Compose's drag detector has already abandoned a stream whose early events the WebView consumed, so the flip did nothing for real fingers/flings (a slow synthetic swipe happened to pass) and the panel stayed a scroll trap. Delta-forwarding transfers no ownership, so it also survives mid-gesture direction reversals. Device-verified end-to-end: from deep in the reviews, repeated down-swipes walk the reviews to their top, then the sheet body back to the photo hero, then collapse the sheet to peek (and on through to dismiss). **Polish round (2026-07-02, from real-finger feedback):** an inertial fling that lands on the reviews' top edge now **hands its leftover momentum to the sheet** (the page tracks a low-passed scroll velocity and reports an edge-fling over the bridge; forwarded only when no finger is down) - no more dead-zone snap; when the user starts really scrolling the reviews, a one-shot **engagement signal auto-expands the sheet + settles the body** so the panel takes the screen Google-style (re-armed when the reviews return to their top), and the panel is sized to fill the expanded sheet; the **rating histogram is scraped off the panel's DOM** (`tr[aria-label]` "N stars, M reviews" rows) and drawn **natively** in Vela's rating header (amber bars - the panel and the scraped-fallback modes now share one look), with Google's in-panel summary block faded out (**opacity, NOT display:none, and only after cards exist** - removing it from layout while Google's virtualized list mounts corrupts the list's offset math and the SPA permanently unmounts every card; reproduced live, twice); the load spinner anchors at the panel's **top** (visible as you scroll toward it); while the panel loads the **featured review from search shows as a teaser**; reviewer-name/review-count links lose their underline/tap-flash (navigation was already blocked); and newly-paged cards get their Like/Share stripped **immediately** (MutationObserver) instead of at the next 1 s tick. **Feed watchdog:** Google sometimes serves the page shell but silently withholds the review feed (soft bot-throttle - observed under heavy testing: tabs + histogram render, the feed request is never issued; the rate bucket is per client fingerprint - the hidden scraper pulled 55 reviews off the same page seconds after the panel got zero, and unblocking telemetry changed nothing, so the tracker blocking stays); ready-but-cardless for ~15 s now **fails over to the native scraper** instead of leaving an empty panel. **Round 2 (2026-07-02):** the native histogram is **narrower** (0.62 sheet width) and **hides while reading reviews full-screen** (returns on the drag back up); the "Reviews are automatically processed" ⓘ row is carved out with the summary - **two-phase**: opacity immediately (kills the flash of Google's own histogram; zero layout risk), `display:none` only after the feed has been healthy ~5 s (reclaims the blank space); and elements set in "Google Sans" are rewritten to the **system font** (generic `sans-serif` - inherits the phone's font choice, not pinned to Roboto), icon fonts untouched. **Round 3 (same day, real-finger feedback):** engaged reviews mode now clears the **whole native header - rating row AND the Reviews/About tab bar** (nothing floats above the reviews; everything returns when you walk the sheet up), and disengage happens at **gesture end** (re-inserting header content per-pixel mid-drag shifted layout under the held finger - read as flicker); the summary fade runs in the **pre-ready loop + on DOM mutations** (recycled nodes re-fade within a frame - the "saw the google histogram for a second" flash and top-area flicker); the **collapse only fires while the list is at its top** (collapsing 170px of content above a mid-list reader yanked the view - the "flung way down"); the engagement threshold went 40→**120px** of real scrolling (casual drags no longer trigger the takeover); underline suppression now covers **buttons** (author name/photo count are `<button>`s, not links); dark-mode **stars get saturate(1.7) brightness(1.12)** after the re-invert (a 0.92-invert + 1.0-re-invert compresses colour toward mid - mathematically can't restore full gold, so it's compensated). **Round 7:** the native histogram is **centered**; businesses with **no auto-parsed topics** still get the native search + sort (the empty chips case was holding the whole control row hostage - the page now reports "no topics" once the feed is healthy and the controls render chip-less); full gesture smoke passed on-device (engage → deep scroll → walk home with header restore → collapse → dismiss, no flicker, no stuck states). **Native search / sort / topic chips (2026-07-02, task 81):** Google's in-panel search box, Sort button, and auto-parsed topic chips ("potato dumplings" ×50) felt out of place - they're now **Vela-native**: the chips are scraped off the page over the bridge (anchored by the "All" chip - position, not classes), rendered as Vela `FilterChip`s beside a native search field (IME-search submits) and a native Sort menu (Google's four orders), all **driving Google's hidden originals** (`window.velaSearch/velaClickChip/velaSort` - fill-and-Enter the input; click the matching chip/menu item). So the search stays Google's server-side one across ALL reviews, wearing Vela's UI; Google's own rows are carved out (same two-phase fade/collapse policy) only once the chips data reached Vela. **Photos stream + warm (task 82):** the gallery scrape now reports partials whenever its accumulated set grows - the strip fills progressively (first partial = the page's hero photos, ~1 s after load) instead of arriving all at once ~20 s later (monotonic + feature-id-gated like review streaming) - and the first search **pre-warms the photo WebView** (renderer + HTTP/2 sockets + cache) so the first place open skips the cold start. **Round 6 (feel fixes):** engaged mode could never disengage - its exit test ("body walked up 150px") was unreachable once the panel filled the sheet (the body's whole range is smaller than that), so the header never returned and top-drags collapsed/dismissed instead; disengage now also fires at body-top and on any pull-collapse/dismiss. The **panel is one constant full-sheet size** - engaging only hides the header (a WebView RESIZE paints a frame late in Chromium = the reported black-band flicker). And the reveal-hold now waits for **all** carves (summary + Google's search/chips rows, which fade once the chips scrape lands - now also in the pre-paint microtask path), not just the summary. **Round 5 - the watchdog is class-agnostic:** Google A/B-serves front-end builds with rotated class names; on those, cards render fine but the class-based check counted zero and the watchdog killed a HEALTHY panel mid-read (user report). `velaHasReviews()` keys on relative-date texts ("2 months ago") - content can't rotate; a genuinely empty feed still fails over. **Round 4:** the summary fade also runs from a **document-level MutationObserver** - callbacks fire at *microtask* timing, before the browser paints, so Google's histogram can *never* flash on screen (the 250ms-tick fade left a visible-frame window; disconnects once landed); and engaged mode now sizes the panel to **fill the entire sheet** (hiding header pieces one at a time was whack-a-mole - the popular-times graph slid into the vacated window and floated; past the takeover point it's purely reviews, everything redraws on the walk back up). **Four adversarial-review-caught gesture bugs fixed before ship:** (1) deltas are measured in **window space** (view-local dy shrinks by however much the forwarded scroll just moved the WebView - the sheet tracked at HALF finger speed with every-other-frame stepping, and the fling velocity halved); (2) **multi-pointer**: an active-pointer id is tracked and re-based on `ACTION_POINTER_UP` (before, lifting one of two fingers read the other finger as one giant delta - enough to instantly collapse/dismiss the sheet); (3) leaving the boundary mid-gesture **ends the forwarding** (resets the pull accumulators + disarms the end-fling - a drag that touched the boundary then reversed into normal review scrolling no longer flings the sheet at finger-up); (4) a fling needs >24px of forwarded travel (a tap with a jiggle can't launch the sheet). Plus: content paging grows `scrollHeight` without a scroll event, so a MutationObserver re-reports the edge state (stale at-bottom briefly double-scrolled up-drags). **Maintenance is now lifetime, not 60 ticks (same fix):** the carve's upkeep loop (`strip`/`stretch`/`revealOverlays`) stopped after ~60 s, so review cards paged in later kept their Like/Share buttons AND a swapped scroller lost its stretch + edge hooks; it now runs every 1 s for the WebView's lifetime (the WebView dies with the sheet, killing the loop). *(Not doable: a **Like-count filter** - Google login-gates the "helpful" counts, so every logged-out review reads 0. The review **video** player remains open.)* Built by interrogating the live page over Chrome DevTools protocol; the carve recipe's non-obvious load-bearing parts are documented in `ReviewsPanel.kt` (vh units are 0 in the embedded WebView - everything is sized in px; the ancestor chain must be un-clipped AND un-transformed or nothing paints; the scroller is stretched only after the Reviews tab reports selected; disallow-intercept must be re-asserted on EVERY touch event or the sheet steals the gesture). - the Reviews tab shows a **"Search reviews"** box (appears once ≥5 reviews loaded) that live-filters the loaded reviews by **text or author**, case-insensitive; an empty result reads "No reviews mention "…" (searching the N loaded)" so it's clear the filter is over what's on-device, not a fresh server query. Clears per place. Device-verified on Taco Bell (typing "cramped" narrowed 50 → the one review that mentions it).
- ✅ **Live review-loading progress** (2026-07-01) - the scrape legitimately takes **~10–40 s** on busy places, so the Reviews tab shows **real progress instead of a bare spinner**: the scraper streams its running count over the JS bridge (`VelaBridge.onProgress`, reported whenever `accN` changes) → `MapState.reviewsFound` → **"Loading reviews… N of ~M"** with a **determinate progress bar** (M = the place's own review count capped at 50, i.e. what the scrape can at most deliver); before the first card lands it says "this can take half a minute" so the wait is expected, not a hang. Feature-id-gated (a slow scrape can't tick a different place's counter). Device-verified on Cheesecake Factory (10 → 19 of ~50 with the bar advancing). **Reviews STREAM IN under the bar (2026-07-01):** the scraper also sends the accumulated reviews themselves whenever the count grows (`VelaBridge.onPartial` → `fetchReviews`' streaming callback → the list renders below the progress header while it's still running) - so you read reviews from the first seconds instead of staring at a bar for 30 s. The partial-vs-final race is closed atomically (the streaming update is gated on `reviewsLoading` *inside* the state CAS; the final result clears that flag in the same copy, so a straggler partial can't overwrite the complete list), and a Kotlin-side timeout after partials keeps the streamed set instead of wiping the list (empty < partial < full). **Idle patience fixed (the "Taco Bell stopped at ~15" bug):** Google's lazy pager routinely takes >2.2 s to fetch the next ~10 reviews on a busy place, and the old 4-quiet-ticks idle-bail misread that as "done" - the opened list now waits 8 no-growth/6 at-bottom ticks (~4.4 s) before concluding it's exhausted; the unopened overview keeps the short fuse. Device-verified: Taco Bell (612 reviews) delivers the full **50 (cap)** with reviews visibly streaming in mid-scrape. *(Review-pass hardening, same day: a wedged scrape that streamed only a sliver still auto-retries - keeping the streamed set must not disable the retry loop, so it re-runs when the result is `< min(4, count)`; an in-flight scrape is a **cancellable job** superseded by the next place's fetch and cancelled on deselect/pin - before, an abandoned 40 s grind held the fetch mutex and queued the next place's reviews ~90 s worst-case; and the search box waits for completion so it doesn't shift rows mid-read - it takes the space the progress header vacates.)* **2.1× faster (2026-07-01):** the scrape ran at the pace of its own conservative polling, not Google's (an A/B with `onResume`/`resumeTimers` ruled out background-timer throttling - 37.4 vs 38.8 s). Three measured cuts: the poll loop ticks every **250 ms** (was 550) with every grace/patience window rescaled to keep its wall-clock size (38.8 → 24.5 s); the offscreen viewport grew **3200 → 6000 px** - a virtualized list renders/pages to FILL its viewport, so taller = more reviews per cycle - and the post-`onPageFinished` settle dropped 800 → 150 ms (the script self-polls; together 24.5 → **18.6 s**). Final: Taco Bell 50 reviews in **18.6 s**, a landmark in 24.9 s, first reviews streaming at ~3-5 s (page load + inject is only ~3 s - the rest is Google's own render + pager fetches). Deeper cuts need the visible-WebView architecture (see ROADMAP), not tuning. **Stale-flag hygiene:** a long-press **dropped pin** never fetches reviews *or* photos, and the previous place's in-flight fetches complete behind feature-id gates that no longer match - so `onMapLongPress` now clears `reviewsLoading`/`reviewsFound`/`photosLoading`/`loadingDetails` like the POI-tap path does *(before this, a pin dropped mid-scrape showed photo shimmer tiles on a bare road forever)*.
- ✅ Place actions in a **Google-style quick-action row** (circular icon + label): **Call** (dialer), Website, Save, **Share menu (Google Maps link / Map pin geo: / coordinates / address)** - the actions are **evenly weighted across the full width** so all five fit on one row without the trailing Share icon clipping off the edge. The **geo: pin** is the degoogled-friendly share (`geo:lat,lng?q=lat,lng(Name)` opens in any maps app, incl. Vela - no google.com); round-trips back through Vela's own `MapLinkParser` (unit-tested)
- ✅ **Place photos - full gallery, keyless via place-page scrape (2026-06-28).** The photo strip **leads the sheet as a hero** (horizontally scrollable; **tap → full-screen, swipeable gallery** with a counter). It opens instantly with the **search-response preview** - the hero block at `[1][72][0][i][6][0]` *(Google moved it `[105]`→`[72]` on 2026-06-27; hot-fixed via calibration `v7`)*, **de-duped** (Google serves the single hero twice) plus the small landmark-only `[1][204][0]` block - then the **full gallery (~9–25 photos) swaps in a few seconds later.** That gallery now comes from **`WebPhotoFetcher` loading the place's own `?cid=` Google Maps page in a hidden WebView and scraping the rendered photo URLs out of the DOM** (`googleusercontent`, avatars/Street-View filtered, de-duped by image id), the **same trick as the reviews scrape**. This *replaced* the bare `hspqX` RPC, which Google bot-degrades to a per-session Street-View-only reply (verified on-device: byte-identical degraded replies across retries - the page render is far harder to degrade than a naked RPC POST). While the scrape is in flight a row of **pulsing shimmer placeholder tiles** shows so it reads as "more photos loading" (`PlaceSheet.PhotoShimmerTile` driven by `MapState.photosLoading`). On-device-verified 9/10/23 photos across three places. *(No posted-date from a DOM scrape - that was an `hspqX`-only field.)*
- ✅ **Photo category tabs (Menu / Food & drink / Vibe / By owner)** (2026-07-01) - the gallery now carries Google-style **category filter chips**. Google keeps those tabs in the `?cid=` page DOM (verified on-device), so `WebPhotoFetcher` **visits each category tab in turn** (clicks it, scrolls, tags the photos it shows with that category), sweeps "All" for the rest, and returns `category⇥url` lines; `Photo.category` + index-aligned `Place.photoCategories` carry it through. The place sheet shows an **All + &lt;categories present&gt;** chip row above the strip; tapping one filters the strip (and the tapped photo still opens at the right spot in the full-screen viewer). Device-verified on The Cheesecake Factory: **All / Menu / Food & drink / Vibe / By owner** chips, and "Food & drink" correctly drops the exterior shot to show only food photos. *(Keyless - the tabs render to a logged-out browser. Ships in the app.)* **Populated FULLY, not 1-per-category (fixed 2026-07-01):** the category grids are **virtualized** like the reviews list, so at the headless WebView's 0×0 size each tab rendered ~1 tile; giving the photo WebView the same **offscreen viewport** (1200×3200) + collecting across scroll within each tab now yields ~15-30 photos per category (device-verified Cheesecake Factory: Menu 24 / Food & drink 15 / Vibe 17 / By owner 13). Cap raised to 80 so later tabs aren't starved; tab names filtered to clean category words (a "Menu · Photo 1 of 12" caption was being mistaken for a category).
- ✅ **Full gallery via a hidden WebView** (`WebPhotoFetcher`) - the gallery RPC (`batchexecute` `hspqX` / `/MapsPhotoService.ListEntityPhotos`) serves the user photos **only to a real browser engine**. A plain HTTP client - even with perfect headers + consent cookies - gets a degraded **Street-View-only** reply: bot-detection at the **TLS/fingerprint** level (verified on-device - OkHttp gets a 162 KB token-less "lite" `/maps` page). So Vela runs a **hidden Android WebView** (real Chromium) that loads `maps.google.com` as an **anonymous, no-login** session - exactly like a logged-out browser, which *does* show the photos - and does a same-origin `fetch` to the RPC, handing the raw response back over a JS bridge. **Keyless** (no API key, no account). Created **lazily** (only when a place's photos are wanted), strictly best-effort (failure → keep the preview). **On-device verified 2026-06-17: 31 photos for SpeeDee-Midas, Davis.** Tradeoff: the WebView runs Google's JS (a fingerprinting step for a degoogled app - the opt-in cost of richer photos), OkHttp fallback kept. Gotchas baked in: **desktop UA** (a mobile UA makes Google deep-link to `intent://` the native app), **block non-http(s) redirects**, and **`Handler`, not `View.postDelayed`** (a headless WebView never attaches to a window, so View timers never fire).
- ✅ Category quick-chips (Restaurants/Coffee/Gas/Groceries/Hotels/Pharmacy/ATMs/Parks) → one-tap search, each with a Google-style leading icon
- ✅ "Search this area" - re-search after panning the map. **Fixed to use the *panned* viewport (2026-07-02):** the button searched around a stale `mapCenter` (only refreshed on a POI tap / result select, not on a plain pan), so panning across town then tapping it re-searched where you *were*. `onViewport` now writes the live viewport centre to `mapCenter` on every camera-idle, so the search always targets what's on screen.
- ✅ Filter: **open now**, **rating ≥ 4.0**, and **price** (tap the Price chip to cycle ≤$ → ≤$$ → ≤$$$ → ≤$$$$ → off, filtering on `priceLevel`) - chips sit on their own horizontally-scrollable row in the results header, stackable
- ✅ Saved / favourite places (star from the place sheet) - reopening a saved place **enriches it via search** so photos, rating and reviews load (saved places carry no feature id of their own); each saved row in the search page has a **⋮ menu** to **Set as Home / Set as Work** (promote it straight to a shortcut) or **Remove** it *(verified on-device)*
- ✅ **Export / import saved places** (Settings → Saved places) - **Export** writes the starred list to a portable JSON file shared via the system sheet (same FileProvider as the diag export); **Import** picks a file and **merges** it (de-duped by id, never overwrites/removes), with a toast of how many were added. Keyless, local, portable between devices.
- ⬜ Overture/OSM POIs as a fallback source

## Routing & traffic
- ✅ Driving directions with **real traffic-aware ETA** (live `duration_in_traffic`)
- ✅ **Live traffic overlay** (browse mode) - Google's congestion-coloured roads, a **keyless raster layer** (the web map's own public `/maps/vt?…!2straffic` PNG tiles on www.google.com - no API key). **Toggle moved off the map into Settings → Map** (2026-06-19) - it's a niche browse-only layer now that nav shows per-segment route traffic, so it no longer earns a map button. **Drawn below the POI/label layers at ~0.6 opacity** so it doesn't render over POIs or bury the basemap. *(Inherent caveat: Google's pre-baked raster paints free-flow green everywhere and re-rasterises on zoom - it's a subtle scanning aid, off by default.)*
- ✅ **Per-segment route-line traffic** - the drawn route is coloured Google-style
  **along its length**: free-flow blue with amber/red/dark-red bands over the congested
  stretches, from the directions response's own congestion spans (`route[3][5][0]` =
  `[level, startMeters, lengthMeters]`, only the non-free-flow runs - parsed sorted by
  start so the bands walk the line start→end in order). Rendered as **solid colour bands**
  (a MapLibre `step` expression, not an interpolated gradient - the driven/ahead boundary
  and span edges are crisp, per test-drive feedback "should be solid"). Combined with the
  driven-grey split so the part behind the vehicle greys out - but only while actually
  navigating: a pre-nav route **preview** draws clean with no grey nub at the start.
  (Walk/bike and no-live-traffic routes fall back to a single overall blue→amber→red tint.)
- ✅ Alternative routes returned
- ✅ **Turn-by-turn from an OPEN router (OSRM), not Google (2026-06-28).** Google's keyless
  directions return **abbreviated** steps for longer routes - a real 6-mi route to Raising Cane's
  came back with **2 of ~10 turns** (the early roads existed only in the map line + the via-label),
  which made nav skip turns and mis-place the ones it had. Routing now comes from **FOSSGIS OSRM**
  (`steps=true`): every turn, with street names, for drive/walk/bike - so the step list is complete
  and the voice says the road. Google stays for what it actually wins - **live-traffic ETA**
  (scaled onto the open route) + POIs/hours/reviews/photos. This also retired the keyless step
  parser as primary and the Nominatim "guess the missing road name" hack. *(Open router for routing
  is also more on-ethos - routing is solved with open data; the FOSSGIS server is fair-use, self-host
  before a real release.)*
- ✅ **Traffic-AWARE routing (2026-06-28)** - OSRM routes by free-flow time, so it can't *avoid* a jam
  the way Google does. When Google's live-traffic route takes a **meaningfully different path** than
  OSRM's (detected by `RouteGeometry.divergent`, >700 m off), Vela re-runs OSRM **through ~12 points
  sampled off Google's polyline** → you follow Google's jam-avoiding route **with** complete
  OSRM street-named steps. The free-flow majority of routes stay pure OSRM (untouched, perfect turns);
  the snapped route leads and OSRM's free-flow options ride along as the alternates. **No backend** - 
  it's the serverless answer to "use Google's smart routing": *we* don't always-snap because the clean
  tool (map-matching) is capped to 10 coords on the public server and the dense-via fallback drops
  ~1-in-10 turns when a via lands on one - so we snap only when traffic actually made Google diverge.
  The unconditional "Google routes, OSRM names turns" version waits on on-device map-matching (see below).
- ✅ **Offline routing - fully on-device + live, world catalog hosted (2026-06-30).**
  When you're offline (or OSRM is down), `directions()` falls back to an **on-device GraphHopper engine**
  (`core/data/GraphHopperRouteEngine`) that loads downloaded **per-region Contraction-Hierarchies graphs**
  from internal storage and routes fully on the phone - complete street-named turn-by-turn, ~200 ms, no
  signal. Pure JVM (GraphHopper runs on ART with three workarounds - MMAP / a Janino-free `SpeedWeighting`
  factory / swallow-`close()`); graphs are built off-device by `tools/graphbuilder`. On-device end-to-end
  verified (Pixel 5a): downloaded a region from the GitHub release → offline → 21.8 mi route via the crosstown arterial
  with named steps + a correct 28-min ETA.
  - **Get a region two ways:** pick it under **Settings → Offline → Routing regions** (regions covering your current
    location sort to the top and are flagged "covers your location"; a **name filter** appears once the
    catalog is large, so a region you're *travelling* to - "Japan", "Texas" - is one type away instead of a
    long scroll), **or** just download offline map tiles for an area - "Download the area you're viewing" now
    **also grabs the routing graph for the region that contains it**, so one tap gives you map *and* navigation offline.
  - **Hosting + world catalog:** graphs + `routing-manifest.json` are static assets on the `routing-graphs`
    GitHub release; the catalog is **`tools/routing-regions.json`** (135 regions - all US states, Canadian
    provinces, ~36 European countries, + starter Asia/Oceania/Americas/Africa) and a **parallel GitHub-Actions
    matrix** builds a whole continent per dispatch (race-safe: per-region zips + entry artifacts, one manifest
    merge). *(Online still wins on live traffic + POIs; this is the no-signal fallback and the foundation for
    offline-first navigation.)*
- ✅ **Turn instructions keep the road name** ("Turn right **onto the local street**", spoken + on the banner). Now **native from OSRM** - `RouteGeometry.osrmPhrase` synthesizes the instruction from the step's `type`+`modifier`+`name`+**`ref`/`destinations`/`exits`** (OSRM ships no instruction text but every step carries its road id), so there are **no bare turns** to fill. **Highways name by `ref`, not `name`** (fixed 2026-06-30): a highway step's `name` is empty and its identity is the `ref` ("I 80") + sign `destinations` - so `road = name ?: ref` and ramps read "**Take exit 72B toward Richards Blvd**" instead of a bare "take the exit"; `Maneuver.ref` also drives the banner shield even when the visible text is a name (Yolo Causeway / I 80). Validated against live OSRM. *(Offline GraphHopper reads the same fields since 2026-07-13: every graph already stored street_ref/street_destination/motorway_junction per edge, so offline steps now carry shields, "toward" sign text and exit numbers too - no graph rebuild was needed.)* *(The retired Google-keyless path used `DirectionsParser` to tag-strip `<step>` markup and a `fillTurnRoads` Nominatim reverse-geocode to patch the ≈3-of-11 turns Google omitted a `<road>` on - both **gone** now that OSRM supplies complete names; the Google markup parser only survives on the unreachable-OSRM fallback.)* **Regression tests:** `OsrmRouterTest` pins the `osrmType`/`osrmPhrase` mappings; `NavRoadNameTest` still drives captured markup through `NavEngine` for the fallback path.
- ✅ **Walking / biking routes draw DASHED** (Google-style) - a second line layer on the route source (`vela-route-dash`, round-capped short on/off pattern) toggled by visibility, because MapLibre's `line-dasharray` disables `line-gradient` (so the solid traffic-gradient driving line and the dashed foot/bike line can't be one layer). Drive stays solid + traffic-coloured; Walk/Bike show the dashes. *Dot rendering rebuilt 2026-07-08 (twice):* dash patterns can never hold visual spacing across zoom (dash units are line-widths, the texture is quantised to integer zooms), and even MapLibre's line-placed symbol spacing stretches ~2x between integers. Final form: **Vela generates the dot POINTS itself** - one dot every ~17dp of screen distance along the route, recomputed as the zoom moves (0.2-zoom steps, live during the pinch via the camera-move listener; `regenRouteDots` in VelaMapView, capped at 3000 points) - chunky 26px SDF dots tinted like the old line, spacing EXACTLY constant at every zoom.
- ✅ **POI / interaction polish (2026-06-28):** (a) **ambient Google POIs now DECLUTTER** - the dot layer was `iconAllowOverlap=true`+`ignorePlacement=true`, so every POI stacked on its neighbours at tight zooms; now they collide + have `iconPadding`, sorted by prominence (`symbolSortKey`), so only non-overlapping ones show and more appear as you zoom in (Google-style). (b) **Tapping a POI while the directions chooser is up brings it to the FRONT** (closes the chooser) instead of loading the place sheet *invisibly underneath* it (the sheet is gated on `!directionsOpen`); picking the route origin by tapping the map adopts the tapped POI as origin. (c) **Search results get a clear "Hide results" bar at the bottom** of the panel - the list hangs from the top so a bottom collapse control is the natural close (the top handle alone read backwards); back gesture still works.
- ✅ **Recenter fixed + photo shimmer suppressed for addresses (2026-06-28):** (a) the recenter button used a `target != lastCameraTarget` guard that swallowed the tap when you were already "centered" then panned away (and a shown route/markers held the camera) - now a `recenterTick` nonce force-moves to the user once per tap, at top priority. (b) the photo-loading **shimmer no longer flashes for residential addresses** - it's gated on photo-worthiness (`rating`/`reviewCount`/preview present), so a bare address won't promise a gallery it'll never have (the scrape still runs silently in case it surprises us).
- ✅ **Honest remaining-distance / next-turn on routes that pass near themselves**
  (switchbacks, cloverleaves, out-and-backs) - `NavEngine` now tracks **monotonic
  forward progress** along the route (windowed projection around how far you've already
  driven) instead of a *global*-nearest point, and measures both "remaining" and "distance
  to next turn" **along the road** rather than crow-flies. Before, a return leg passing a
  few metres from the outbound leg made the global-nearest collapse "remaining" to almost-
  arrived while the next turn read crow-flies-huge - the test-drive's "51 mi to turn · 0.3
  mi remaining". *(2026-06-21; unit-tested with a hairpin route - `remainingStaysHonest…`; **verified on-device** on a real 14.5-mi route: `remaining` counted down 14.5→11.9 mi monotonically with 0 violations across 75 nav updates, next-turn always ≪ remaining.)*
- ✅ **Lane guidance - real per-lane diagram** (2026-06-30). OSRM gives true per-lane data
  (`intersections[0].lanes`: each lane's permitted arrows + whether it serves this maneuver), so the nav
  banner **and** the step list now draw a **Google-style lane diagram** - one cell per approach lane in
  road order, each with Canvas-drawn arrow(s) for what it allows, the lanes for THIS turn **bright** and
  the rest **dimmed** (`NavOverlays.LaneDiagram`/`laneHead`, `Maneuver.lanes`). **Arrow rendering cleaned up
  (2026-07-02):** a lane with several allowed directions now draws **one shared vertical shaft** + a head per
  direction (it used to draw a whole arrow each, double-drawing the shaft into a muddy blob and crowding the
  forked heads); heads are smaller and the cell wider so two heads don't overlap, dim arrows are a **flat grey**
  (not a translucent tint that built up where strokes crossed), and dim heads draw *under* the bright active one.
  On-device verified: a
  "Keep slight left toward I 5 South" step shows a bright straight arrow + a dimmed slight-right, with the
  I-5 shield. *(The older count-based strip from Google's "Use the right 2 lanes" hint is kept as the
  fallback for the OSRM-unreachable path; the main instruction stays clean - "Turn right onto …".)*
  **The diagram only appears within ~0.5 mi of the maneuver** (`LANE_SHOW_M`, 2026-07-01) - it used to
  render the whole time the maneuver was next, so on a long highway leg the "be in the right lane" arrows
  sat there for miles before the exit, which read as noise. Now they surface as you approach (Google-style);
  in step-preview (swiping the step list) they always show, since you're deliberately inspecting a step.
- ✅ **Spoken lane guidance - lanes-FIRST, Google-style (2026-07-03).** Vela now SAYS the lane, not just
  draws it, and it **prefaces** the maneuver instead of tacking it on the end: "**Use the right 2 lanes to**
  take exit 172 toward Sacramento" (not "…take exit 172 toward Sacramento. Use the right 2 lanes"). It's
  computed from the same OSRM per-lane `valid` data as the arrows (`Route.laneGuidance` reduces them to a
  side + count when the valid lanes are a contiguous block at one edge; no hint when any lane works or the
  block is non-contiguous - the diagram covers those). Spoken once, at the first (far) prompt distance, so
  it doesn't nag. Localized via `NavStrings.useLanesToDo` - English folds it into one smooth sentence
  ("Use the right 2 lanes to take exit 172…"), other languages fall back to a safe lanes-first two-sentence
  form ("Empruntez les 2 voies de droite. Prenez la sortie 172") until a native grammar is hand-written.
  Unit-tested.
- ✅ **No more "continue on the road you're already on" - even when the name changes (2026-07-04).** OSRM
  emits a `continue`/`new name` maneuver wherever one road flows into the next; Google stays silent there
  ("the name of the road does change but it literally is the same road just going straight"). Fixed at the
  **router-mapping seam**, not by heuristics in the engine: `ManeuverType.CONTINUE` is now *minted only* for
  "same physical road, keep driving straight" - OSRM `continue`/`new name` with a straight/absent modifier
  (`RouteGeometry.osrmType`) and GraphHopper `CONTINUE_ON_STREET` (`ghType`, whose old else-branch was also
  purified: u-turns/ferries/PT no longer masquerade as CONTINUE - a u-turn keeps its road name and would
  have been silenced) - and `NavEngine` voice-silences every CONTINUE (prompts, turn-now cue, haptics)
  **unless OSRM attached lane guidance** ("use the left 2 lanes to continue onto I-80" still speaks - the
  driver must position). A real bend that keeps the name (OSRM `continue`+`left`) maps to TURN_LEFT and
  speaks; a junction where straight is an active choice (`turn`+`straight`) stays STRAIGHT and speaks;
  forks/ramps/merges are structurally unaffected. The banner + step list still show every step. The
  first attempt (2026-07-03) suppressed CONTINUE-with-unchanged-road inside NavEngine - dead code, since
  OSRM never produced CONTINUE at all; the mapping-seam version is the real one. `NavReplay`'s drive-audit
  exempts CONTINUE from its SILENT-turn flag so trip-log audits don't cry wolf on intentional silence.
  Unit-tested (mapping pins + a mock drive asserting the silent continue and the still-spoken next turn).
  **Four more drive-reported nav fixes (2026-07-04):** (1) **straight rename no longer read out** - OSRM
  stamps a few-degree `slight left`/`slight right` bearing artifact on a dead-straight `new name` node
  (Olive Dr → Richards Blvd), which slipped past the null/`straight`-only CONTINUE test → spoken. `osrmType`
  now treats slight-modified `new name` as CONTINUE too (silent); `continue`+slight stays a real bend
  (spoken) - the branch is split on purpose, and the unit pins flipped to match. (2) **roundabout exit count
  restored** - OSRM's TWO-STEP roundabout (`roundabout` enter + `exit roundabout`/`exit rotary` exit, the
  latter carrying `maneuver.exit`) had the exit step unmodelled → it fell to a bland "Continue onto X" ("it
  was considered the same road"). `osrmType` now maps the exit types to EXIT_ROUNDABOUT and `NavStrings.phrase`
  (all supported languages) phrases the exit number ("take exit N onto …"). (3) **fastest route reliably leads the
  picker** - the sort key put traffic-inflated Google alts on a different axis than un-inflated free-flow
  OSRM routes; now every route is normalised onto one in-traffic axis (`?: durationSeconds * gRatio`) with a
  provisional/named tie-break. *Second hole closed 2026-07-08:* naming a picked (or top-sorted) provisional
  alternate re-snapped it through OSRM and swapped in a RECOMPUTED ETA in place, so a row's time could
  leapfrog its neighbours after the sort ("Fastest" tag below a slower first row). `nameRoute` now keeps the
  route's original Google duration/in-traffic figures; the snap contributes geometry, named turns and
  congestion spans only. *And the tag is singular now (2026-07-08):* a route under ~30 s slower rounded its
  delta to 0 and ALSO wore "Fastest" (two tags, different displayed minutes); only the top row gets the tag,
  near-ties just show their ETA. (4) **compass no longer buried under the nav card** - MapLibre's top-right
  compass is dropped ~112 dp below the top during nav so the full-width maneuver banner stops painting over
  it. *(Roundabout phrasing + route-sort both want one real drive to confirm against live data.)*
- ✅ **Nav survives a process kill - "Resume navigation?" (2026-07-04).** On GrapheneOS the Android-14
  FGS-location restriction can stop the foreground service from holding the nav process alive, so the OS
  reaps it mid-drive and you reopen into plain browse mode (route line gone, arrow pointing by compass
  instead of heading-up - a real drive report). Fix: `startNav` persists the **destination** (+ label/mode) to
  a `vela_nav_resume` pref; on the next launch `MapViewModel.maybeOfferResume` raises a **"Resume navigation
  to &lt;place&gt;?"** card (Resume / Dismiss) if that drive is recent (`RESUME_MAX_AGE_MS` = 60 min), and
  **Resume re-routes from your CURRENT fix** to the saved destination and restarts nav - a fresh route that
  accounts for however far you drove while the app was gone (and any traffic since), rather than restoring a
  stale line. Cleared on stop AND on **arrival** (the arrival branch now clears the resume pref too, so a
  completed drive isn't offered for resume next launch - audit 2026-07-06). The 60-min freshness window is
  **heartbeated every 5 min while driving** (`NAV_HEARTBEAT_MS`), so it measures time since the interruption,
  not since nav start - a >60-min drive can still be resumed (before, the timestamp was written once at start
  and a long drive fell outside the window). Only the destination is persisted (no Route serialization).
  **Device-verified on a Pixel 5a:** start nav → `am force-stop` (simulating the reap) → relaunch → the "Resume
  navigation to Safeway?" card appears; Resume re-routes + resumes. *(The other restart symptom - the map not
  re-plotting a still-live route on a mere Activity recreate - is moot here since the session is rebuilt from
  the current fix.)*
- ✅ **Navigation tracking overhaul - the standstill/progress glitches (2026-07-04).** Four field bugs from
  real drives ("mph keeps going when stopped", "progression halts as if I'm not moving", "turns showing up
  12 miles early"), all traced and fixed at the mechanism:
  **(1) GPS starvation at a standstill** - `LocationProvider` registered with a 2 m distance filter, so a
  stopped car got NO fixes: the speedometer froze at the last braking speed, the puck's Kalman never
  measured 0, and the dead-reckoner crept the puck forward on the stuck speed; pulling away then FROZE the
  puck (real position behind the crept target → every fix rejected as backward) until the car re-drove the
  phantom metres. Fix: **minDistance 0 m** (~1 Hz doppler≈0 fixes while parked - the readout and model
  settle by themselves), plus belt-and-braces: a 3 s no-fix zeroer + a 3 s speedless-fix evidence timeout
  (`SPEED_ZERO_MS`/`SPEED_HOLD_MS`), the Kalman now measures ONLY each fix's own doppler/derived speed
  (`mySpeedRaw` - feeding it the held display speed re-injected the stale value at near-unity gain), decays
  toward 0 during outages (`SpeedKalman.decay`, τ=4 s), and the spike filter only applies across ≤3 s gaps
  (else the post-tunnel 29 m/s doppler is rejected against a zeroed 0+15 forever - caught in adversarial
  review before ship).
  **(2) Parked-jitter ratchet** - the puck's monotonic `targetM` accepted every forward GPS wobble at a red
  light. Now gated at near-zero modelled speed (noise floor 8 m), and the 2 s dead-reckon window re-anchors
  only on ACCEPTED fixes (a rejected wobble used to re-arm the blind window every second).
  **(3) Mid-drive freezes** - three unfreeze paths: a persistent over-cap forward step is accepted on the
  2nd *consecutive* occurrence (post-gap catch-up used to deadlock against a stale plausibility cap;
  isolated multipath spikes at a light DON'T count - the streak resets on every normal fix), snap misses
  disengage at 3 (not 6), and the snap tolerance scales with speed (22→35 m - OSRM geometry sits half a
  road-width off the driven lane on divided roads) with the stale-bearing heading gate skipped when
  stopped. The look-ahead window is sized from the speed at the last accepted fix, not the decaying model.
  **(4) "Turns 12 miles early" - the out-and-back wrong-pass bug.** On a route that reuses the same asphalt
  (out-and-back, divided highway, cloverleaf), `NavEngine`'s GLOBAL maneuver projection matched a
  return-leg turn onto its outbound twin: the moment it became the target, its along-route distance read
  ≈0 and it announced/advanced miles early. Maneuvers are now located by a **prefix-sum of step lengths
  refined by a ±800 m windowed projection** (`maneuverAlong`), and off-window re-acquire **prefers the
  pass nearest current progress** (`projectNearAnchor`, 2 cm/m along-distance penalty - a far leg can
  never outbid a valid near match inside the 60 m acceptance band). For this to work the via-stitched
  routes (traffic snap, picked alternates, multi-stop) had to keep step lengths TILING the polyline - 
  the via filter now **folds dropped boundary-step distances into the last kept maneuver** (they used to
  vanish, drifting every later estimate km short; also caught in adversarial review). Unit-tested with
  synthetic out-and-back routes (wrong-pass distance, near-pass re-acquire) + replays feed the puck Kalman
  again (`mySpeedRaw` in the replay collector).
- ✅ **Full navigation audit + remediation (2026-07-04).** Before the next real drive, a 6-lens audit
  (position/reroute · speed chain · route-line rendering · banner/prompt timing · engine/session · a
  completeness critic, each benchmarked against OsmAnd/Google behaviour) produced 39 findings; the
  confirmed ones were fixed in one pass and adversarially re-reviewed. The big ones:
  **Position integrity:** NETWORK (BeaconDB) fixes are no longer trusted blindly - dropped outright during
  nav, and in browse only used when GPS has been quiet ≥12 s (OsmAnd's `useOnlyGPS` discipline); they were
  routinely 100-1000 m off and teleported the dot onto parallel streets → spurious reroute → teleport back
  → reroute again ("GPS thinking I am somewhere else"). Inter-fix `dt` now uses the monotonic
  `elapsedRealtimeNanos` (mixing GNSS UTC with network system-clock stamps made dt<0, which bypassed the
  outlier filter entirely - a one-fix teleport). Coarse fixes (accuracy >50 m) update the dot but never
  steer guidance.
  **Rerouting:** a failed reroute fetch used to KILL rerouting for the rest of the drive (the off-route
  event is edge-triggered and the latch never cleared) - failures now clear the latch so 4 more deviated
  fixes naturally retry (~4 s cadence), with single-flight + a 10 s adoption cooldown + "Rerouting" spoken
  at most every 30 s (no more reroute storms), a session-generation stamp (a late reroute can't resurrect
  the previous destination's route into a new session), a route-identity guard on the per-fix state write
  (the old-route progress can't be written onto a freshly swapped route → no false arrival after a
  reroute), no reroutes while provably stationary (red-light multipath drift), no reroutes within 150 m of
  the destination, and off-route now measured against the SAME windowed projection progress uses (being
  near the RETURN leg of an out-and-back no longer masks a genuine exit).
  **Guidance timing:** prompt distances scale with speed - max(400 m, v×25 s) far / max(150 m, v×8 s) near
  / turn-now (v×2.5 s, 25-90 m); the fixed 400 m gave a 75 mph driver 12 s to cross three lanes (Google:
  ~2 mi + 1 mi + 500 ft). City/walking behaviour is byte-identical. Short steps speak ONE prompt with the
  TRUE distance ("In 50 meters, turn left" - it used to fire both bands back-to-back announcing the literal
  thresholds). After a GPS gap, maneuvers passed in the tunnel advance SILENTLY (each used to replay as an
  at-the-turn command + firm haptic, one per second). Arrival gets an approach cue ("In 400 feet, your
  destination will be ahead" - new `NavStrings.destinationAhead`, all supported languages) and fires on PROXIMITY too
  (crow ≤40 m of the snapped endpoint, or stationary within 50 m remaining - parking short used to never
  arrive, then "Rerouting" fired in the lot). Lane arrows + the compound "then" row gate on a speed-scaled
  approach distance (~30 s; the "then" row used to sit on the banner for 12 km when a merge followed a far
  exit). The banner seeds the first turn's distance at start (no more "0 ft" flash), and a previewed step's
  headline now shows its APPROACH distance, not the leg after it.
  **ETA:** remaining time = the remaining STEPS' durations (pro-rated current leg, × the live-traffic
  ratio) - it used to divide remaining distance by the whole-route average speed, reading "4 min" for a
  15-minute downtown tail and poisoning the faster-route comparison. Faster-route offers also remember a
  dismissal (no re-speak of the same candidate every 2 minutes) and never re-fetch while one is on screen.
  **Speed chain:** the spike filter is now symmetric + accel-bounded (|Δv| ≤ 8 m/s²·dt + slack) against the
  last ACCEPTED measurement with a 2-fix persistence escape - the old one-sided +15 m/s check let a doppler
  down-glitch to 0 through at 67 mph and then rejected every real 30 m/s fix against the held 0 (speedo
  latched at 0 until you slowed below 33 mph); shared with the replay path (which had NO escape - one
  recorded glitch zeroed a whole replay). The no-fix zeroer moved 3 s→6 s (it fired between normal 3 s
  canopy fixes: 56→0→56 flicker), the dead-reckon window 2 s→3 s (glide-stall-lurch at canopy cadence), the
  DISPLAYED speed is smoothed with a stop deadband (raw 1 Hz doppler flickered 59/60/61 at cruise), and
  speed derivation requires two GPS fixes past an accuracy-scaled floor (a BeaconDB hop minted phantom
  16 mph readouts at red lights).
  **Route line ("the gradient when you zoom in"):** the driven/ahead cut is now a GEOMETRY split - a
  traversed-grey full line (theme-aware, dimmer than the alternates' grey) under an ahead-suffix layer cut
  exactly at the puck, updated at sub-pixel granularity for the current zoom, with traffic spans remapped
  onto the suffix. The old line-gradient stop could never be crisp: MapLibre bakes gradients into a
  256-texel texture, smearing any "hard" cut into a routeLength/256-metre ramp (~39 m on a 10 km route,
  hundreds of px zoomed in) - and MapLibre has no `line-trim-offset`, so geometry is the only exact cut.
  Route geometry also uploads only when it CHANGES (it re-tessellated thousands of vertices on every
  recomposition, ~1-2×/s during nav).
  **Voice/audio:** audio focus is refcounted per speech burst - queued prompts used to leak one request and
  abandon the other mid-sentence (music un-ducked OVER "Turn right onto Main St"), interrupts stranded the
  count (no `onStop` override), and there was no focus-change listener at all (guidance talked over
  incoming calls; it now stops speaking when a call takes focus). Session lines ("Rerouting", the
  faster-route offer, the stops notice) now speak in all supported languages via `NavStrings`.
  **Steadier ducking (2026-07-04, user: "not ducking enough, and it didn't reliably duck every time"):** the
  root cause was **flapping** - focus was abandoned the instant each prompt ended, so the driver's music
  snapped back to full volume between (and within) closely-spaced prompts, reading as weak/unreliable
  ducking. Fix: a **~1.5 s focus-hold** on release (`FOCUS_HOLD_MS`, `Handler`-debounced) instead of
  abandoning immediately - a compound prompt ("In 500 ft … turn right") or an interrupt flushing the previous
  one now keeps the audio ducked **continuously** across the gap; a new prompt within the window reuses the
  still-held focus (device-verified: two back-to-back prompts made ONE focus request, not two + an abandon).
  The request result is checked (`focusHeld`) so a FAILED grant is known rather than speaking over full-volume
  audio blind. **Stays on `AUDIOFOCUS_GAIN_TRANSIENT_MAY_DUCK`** (OS-managed duck + **auto-restore**): a brief
  detour to plain `GAIN_TRANSIENT` (pause the music entirely, for a deeper drop) was reverted - many players
  pause on transient loss but **don't reliably auto-resume** when focus is handed back ("Vela paused the music
  and didn't restart it"). Duck DEPTH is set by the OS/player, not tunable via the focus API; the continuous
  hold is what actually makes it read as ducked.
  **Lifecycle/UX:** arrival tears the foreground service down (dismissable notification; the location-typed
  FGS + ongoing notification + 1 Hz GPS used to run FOREVER if you pocketed the phone without tapping
  Done), and a "Searching for GPS…" chip (all supported languages) shows during nav when fixes stop - the banner used
  to freeze with a confident blue arrow and zero indication. `RouteGeometry.reposition` also placed every
  maneuver one full step late (off-by-one vs the placeManeuvers convention) - fixed. Unit-tested
  (`NavAuditRegressionTest`: speed-scaled prompts, single-prompt short steps, silent catch-up, proximity
  arrival, stationary-drift no-reroute, per-step ETA, arrival approach cue). **A second adversarial
  round then broke the first fixes and 10 more corrections landed before ship** - the important ones:
  the destination-zone reroute guard is measured by CROW distance with a deferred-fire flag (guarding on
  the frozen `remaining` made a turn missed near the destination a PERMANENT silent limbo - frozen
  banner, no reroute, no arrival, while the driver left the area); the stationary floor is MODE-AWARE
  (2 m/s classified every walker as parked → pedestrian rerouting dead + 50 m-early walking arrivals);
  the failed-reroute latch clear moved onto the location thread (the coroutine write raced the in-flight
  fix frame); PiperSynth's abort paths double-fired `onDone` (double-decrementing the focus refcount - 
  music un-ducked over the interrupting prompt); NETWORK fixes may paint the DOT after 12 s of GPS
  silence even during nav (guidance stays GPS-only - a GPS-less phone deserves a coarse position, not a
  dead app) and the GPS chip also fires when guidance is starved by sustained 50-80 m accuracy (coarse
  fixes kept the stale timer from ever firing); the split re-upload gained a 150 ms wall-clock floor; a
  mid-nav reroute seeds the ahead layer immediately (no grey-route flash); the arrival notification
  detaches BEFORE posting (else it stays non-swipeable) and Done clears it. *(Deferred, documented:
  backward-driving/U-turn detection, bearing-biased reroute origins, adaptive dead-reckon cadence,
  raw-vs-raw movement accumulation for speedless-chipset walking.)*
- ✅ **Trip replay made trustworthy: segments, hermeticity, real-time-scaled puck (2026-07-04).** Auditing
  the user's actual glitchy drive (`TripLog.audit` on the shared CSV) found the replay system itself was
  manufacturing most of the on-screen chaos:
  **(1) Franken-routes.** A trip records every route the drive used (start + each mid-drive switch as its
  own `RP/RD/M` block) - but the parser grabbed the FIRST polyline and EVERY maneuver line in the file, so
  a trip with a route switch replayed as one stitched route with two DEPART→ARRIVE runs: mid-replay
  "arrival", card distances km wrong, the arrow matched against the wrong half. `TripLog` now parses
  **segments** (each block + the fix index it activated at), `audit()` replays each segment against
  exactly the fixes driven on it, and the in-app replay **swaps routes at the recorded fix positions**.
  Live drives now also RECORD reroute/faster-route swaps as new blocks (previously only a manual nav
  restart wrote one).
  **(2) Live fetches during replay.** Replays ran the real reroute + faster-route recheck - a wrong turn
  in the trace fired a LIVE OSRM fetch and swapped the route mid-replay (matching the trace against a
  route never driven), and the recheck popped the faster-route sheet over a replay. `NavSession.replayMode`
  makes replays hermetic: no fetches, recorded swaps only.
  **(3) The 3× stutter.** Replays play 3× real time but the puck's dead-reckoning, blind window, easing
  time-constants and plausibility caps all ran on the WALL clock - the puck covered ⅓ of the ground
  between fixes and surged to catch up every fix ("stuttery arrow, pulsing mph"). The map view now runs
  those clocks in **trace time** (`replaySpeedup`; live = 1 → formulas byte-identical), closing the
  long-deferred nav-camera-replay item.
  **Bonus (benefits LIVE nav too):** maneuver positions are now resolved **sequentially** - each maneuver
  projects onto the polyline strictly FORWARD of the previous one (the stopMarks technique) - replacing
  the step-length prefix sums entirely. Exact on reused asphalt by construction and **independent of step
  metadata** (old recordings carry unfolded via distances; Google's fallback steps are abbreviated - both
  used to skew the estimates). The ETA pro-rate uses the resolved geometric leg length for the same reason.
  Also fixed: the documented `-DvelaTrip` audit harness had NEVER worked (the Gradle daemon property never
  reached the forked test JVM - the test silently skipped); `core/build.gradle.kts` now forwards it.
  Audit of the user's trace after the fixes: both segments track cleanly; the residual flags are artifacts
  BAKED INTO the old recording (raw BeaconDB teleport fixes the old pipeline recorded, and a second route
  computed from a minutes-stale origin) - the new live pipeline neither records nor feeds those.
- ✅ **Compound maneuver preview ("… then keep right")** - the banner's secondary "then &lt;next&gt;" line
  now shows **only when the next maneuver closely follows** this one (`COMPOUND_M` ≈ 0.3 mi, `isCompoundNext`,
  2026-07-01), the way Google surfaces back-to-back turns (exit-then-merge). It used to show for *any* next
  maneuver, even one miles away - the same noise as the lanes-too-early bug. The "then" line now also carries
  the **next step's highway/exit shield**, so a compound "then take I-580" shows the I-580 shield.
- ✅ **Highway/exit signage with real shield shapes** - route refs ("I-80 E", "US-50 E",
  "CA-99", "ON-401") and exit numbers ("Exit 4A") are parsed out of each instruction and
  rendered as Google-style badges: a **green exit tab** plus the **actual route-shield
  shapes** (2026-06-27) - a red-top/blue interstate shield, a white US-route shield (both
  drawn as Compose `Canvas` paths, real-signage colours, light/dark-independent), and a
  neutral white marker for state/provincial routes. The network is **inferred from the ref
  prefix + a state/province set** (`parseRouteRef`, unit-tested) - `I` → interstate, `US` →
  US route, a 2-letter state/province code → state - with **no OSM lookup**, per the design
  call. Anything unrecognised falls back to the plain bordered chip. *(v1 draws one neutral
  marker for all states/provinces; per-state shapes - a California spade vs Ontario's crown - 
  ride OSM Americana's set as the follow-up. Shown in both the nav banner and the step list.)*
- ✅ Route geometry via open router - **per-mode** FOSSGIS OSRM backends
  (`routed-car`/`routed-bike`/`routed-foot`), so drive/walk/bike each follow the
  correct network; Valhalla later
- ✅ **Live route re-check while navigating** - every ~2 min underway Vela re-queries traffic and
  offers a faster route when one appears (NavSession recheck; see Navigation below)
- ✅ Walking + cycling modes (drive/walk/bike) - each with its **own** path-following
  line, not a car route reused
- ✅ **Public transit** directions - a **Transit** chip in the directions chooser
  shows a Google-style results board: each option's **departure–arrival window**,
  **total duration**, **distance**, **agency**, and the **coloured line pills** you
  ride (real Google line colours + per-mode glyph: 🚆 train / 🚌 bus / 🚊 tram / …).
  Like photos, transit is served **only to a real browser engine** (a plain GET with
  the `!3e3` flag is silently downgraded to *driving*), so it goes through a hidden
  **WebView** (`app/web/WebDirectionsFetcher`) that loads the `/maps/dir/…/!3e3` page
  and reads the itinerary set out of `APP_INITIALIZATION_STATE` (the longest
  `)]}'` payload at slot [3]); `TransitParser` (keyless) parses it. **Verified
  on-device** Davis→Sacramento (6 options: Amtrak Thruway, Yolobus 42B/43/44, …).
- ✅ Transit **"departs in X min" countdown + live badge (2026-07-12).** Each board option
  leads with a Google-style countdown ("Departing" / "in 7 min") computed from the parsed
  departure epoch against a shared clock that ticks every 30 s; options departing more than
  90 minutes out (where the printed time carries it) or already gone are left unmarked. When
  the itinerary carries **real-time** data (a leg with a live delay, or a real-time time that
  differs from the timetable) the countdown reads **green** with a **Live** dot, and the
  boarding leg's **"N min late/early"** is surfaced right in the header (it was only in the
  drill-down before). Pure render off already-parsed fields (`TransitItinerary.departureEpochSec`,
  `TransitStep.delayText`), no extra fetch; localized in all supported languages.
- ✅ **Canonical transit stops on the map (2026-07-13, Transitous, device-verified).** At street
  zoom the bus stops you see are the agencies' own GTFS stop positions from Transitous (`map/stops`
  per viewport, area-cached), drawn as a blue bus badge with the official stop name - one icon per
  station (bays collapse onto their parent). **Tapping a stop opens its live departure board
  instantly by stop id** - no Google lookup, no name matching, so intersection-named stops and
  multi-bay hubs just work. Where this layer has coverage the OSM basemap's bus icons hide (no
  doubled stops); rail/airport icons stay basemap. **Stops keep working offline**: every area you
  browse online is cached to disk (24-area LRU) and redraws with no signal - the same
  continuously-fresh property as the surveillance-camera dataset; never-visited areas fall back
  to the OSM icons. **Directional curb pairs merge into one icon (2026-07-13, device-verified).**
  US feeds name both sides of the street identically with no direction field, so the same
  intersection used to draw two overlapping same-named badges. Same-named stops within 160 m now
  collapse to a single icon at their midpoint, and its board merges both curbs' departures - the
  headsigns distinguish the directions (one row heads to the regional hub, another to the opposite
  terminus), the way Google presents an intersection stop. Transit directions are unaffected: they
  already walk you to the exact boarding coordinate of the specific curb. Stops whose names carry
  the direction (NB/SB station styles) never merge.
- ✅ **Live stop departure board (2026-07-12, keyless + device-verified).** The board is
  **ownership-gated (2026-07-16)**: it renders only on the place it was fetched for, so a
  previously viewed stop's departures can never linger onto an unrelated place (a saved/recent
  place opened right after a stop used to show the stop's board). Tapping a transit
  station (subway / rail / BART / bus stop) shows Google's **"See departure board"** right in the
  place sheet: each line and direction with its **route number in its real line colour** (the "14"/
  "38AX" pill), its **destination/headsign**, the **next few departure times** (soonest bold, the rest
  quiet), a **countdown** on the soonest ("in 6 min", green + a **Live** dot when Google has a real-time
  fix), and the running **frequency**. Handles both layouts - a station grouped by line/direction, and
  a busy **bus stop** that lists departures flat (the parser groups those by route so route 14 is one
  "14" row with its next times, not 25 rows), soonest-first. It rides the SAME
  anonymous WebView + `APP_INITIALIZATION_STATE` channel as transit itineraries and photos - the
  board is embedded in the station's own place page (no separate RPC, no login; unlike popular
  times it survives a logged-out session), parsed keyless by `:core`'s `StopDeparturesParser`
  (`place[62]`, shape-tolerant leaf matching, unit-tested against a live NYC capture) via
  `WebStopDeparturesFetcher`. Gated to transit-category places so it never fires on an ordinary
  business. **Device-verified: BART Powell St rendered 8 lines** (Daly City / Richmond / SFO-Millbrae
  / Antioch / SFO) with their next departures. **Coverage is agency-dependent** - major systems that
  feed Google real-time carry the board (NYC MTA, SF BART confirmed); a place with none shows nothing
  (a small light-rail agency like SacRT was confirmed empty, correctly). Localized in all supported languages.
- ✅ **Tap-through route stop timeline (2026-07-12, keyless + device-verified).** Every route on the
  departure board is tappable (a **`>` chevron** hints it): tapping one opens a full-screen **stop
  timeline** for that route - the **board stop**, **every intermediate stop with its call time**, and
  the **alight stop**, drawn down a **vertical rail in the line's own colour** (board + alight bold).
  Tapping any stop on the timeline opens **that stop's own departure board**, so you keep drilling
  down the line the way Google's tap-through does. No new endpoint: the stop sequence is a lazy fetch
  not in the place blob, so it **reuses the proven transit-itinerary parser** - a keyless directions
  query from the tapped stop toward the route's headsign returns a ride leg whose `intermediateStops`
  already carry the per-stop times. The headsign geocode is **biased toward transit terminals** (a
  bare "Richmond" would otherwise resolve to a city district, not the BART terminal), and the leg we
  actually **board at this stop** is chosen. Best-effort: a headsign that will not geocode falls back
  to a quiet "Route details unavailable". **Device-verified: BART Powell St -> Yellow-S to SFO showed
  all 11 stops (Powell -> Civic Center -> 16th/24th St Mission -> Glen/Balboa Park -> Daly City ->
  Colma -> South SF -> San Bruno -> SFO) with times 12:23-12:54 PM, and tapping 16th St Mission opened
  that stop's own board.** Localized (`route_detail_unavailable`) in all supported languages.
- ✅ Transit **leg drill-down with full stop detail** - tap an itinerary to expand
  its ordered legs. A ride leg shows Google's whole layout: the **line pill + "towards …"
  headsign**, the **board stop** (name + agency **Stop ID** + real-time board time, with
  **"N min late/early"** when it drifts from the timetable), an expandable **"N stops"**
  list of every **intermediate stop with its time**, the **alight stop**, plus the trip's
  **service alerts** (detours/info) and a **"Tickets & info"** footer with the agency name +
  a **dialable phone** (and **fare** for agencies that provide one - many US agencies don't).
  All of it parsed (unit-tested) from `trip[1][0][1]` in the **same** keyless fetch - no
  extra RPC. **Calibrated + device-verified** Miami→Aventura Mall (route 9, 2026-07-07);
  single-digit route numbers ("9") now render a pill (the ≥2-char guard dropped them).
- ✅ Transit **walk-leg turn-by-turn** - tap a **Walk** leg in the drill-down to expand
  turn-by-turn walking directions between that leg's endpoints (the previous ride's alight
  stop / trip origin → the next ride's board stop / trip destination). The endpoints come
  from the stop coordinates in the **same** keyless transit payload (`TransitParser` now reads
  each stop's `[4][2]`/`[4][3]` and `assignWalkEndpoints` wires the adjacent stops onto each
  walk leg); the steps are fetched **on demand** via the normal walk router (OSRM foot) - no
  extra transit RPC. Collapsed by default; a chevron opens it and a spinner shows while the
  route loads.
- ✅ Transit **step-by-step guidance (Moovit-style)** - an expanded itinerary gets a **Start**
  button that opens a full-screen leg-by-leg guide: the current leg large (with its walk-directions
  drill-down), the remaining legs as a timeline, and **Back / Next** controls. It **advances
  automatically** as GPS reaches each leg's end (board/alight stop or the walk destination) and
  **speaks each instruction** ("Take Route 9 towards Aventura, get off at …", "Walk 7 min",
  "You have arrived") through the selected voice, localized in all supported languages. The auto-advance is
  **latched** (`MapViewModel`, `TransitNavState`): a leg must first be ARMED by being >90 m from its
  end, then advances on entering the 40 m radius - so a transfer hub with two leg-ends close together
  can't cascade and a short final walk can't fire a premature "arrived". Back exits guidance.
- ⬜ Per-minute **predictive** future-traffic ETA (login/app-only - keyless gives the typical *range* only, see Depart/arrive time above); avoid tolls/highways
- ⬜ Self-hosted routing backend (replace the FOSSGIS community server)

## Navigation
- ✅ **Steps viewer: swipe down anywhere to close + no stray stops while it's up (2026-07-15,
  user).** The route step list now dismisses with a downward swipe on the BODY once the list is
  at its top (nested-scroll into the same drag the handle uses; mid-list swipes still scroll),
  not just via the X. And the route-through-here map press is gated: while the steps viewer or
  the full route picker covers the map, taps on buildings/unnamed POIs (which share the
  long-press handler) no longer silently add a stop and reroute - adding a stop by pressing the
  map works only once the chooser is minimized to its Start bar, where the map is the primary
  surface. Deliberate flows (Add stop -> choose on map, the origin picker) are untouched.
- ✅ **Compact turn banner on short screens (2026-07-15, ported from the vela-dpad fork, credit
  ars18).** Below 500dp of screen height (landscape phones, car head units in landscape) the
  maneuver banner shrinks its paddings, glyph and distance type so it stops eating the map;
  ordinary portrait phones are byte-identical.
- ✅ **"Take the ramp" pronounced right (2026-07-11, ear-verified).** espeak's phonemizer
  mis-voweled "take" ("tyke") when the whole ramp sentence was phonemized in one breath; the
  spoken text now inserts a comma before "toward", so the maneuver clause and the sign
  destination are separate beats (Google pauses there too). Banner text unchanged.
- ✅ **Android Auto, full car-side navigation (2026-07-08, PR #17 by jacobjeger; replaces the first cut).**
  Vela registers as a navigation-category templated car app (sideloads appear once AA's developer "Unknown
  sources" switch is on). The car now runs the WHOLE flow by itself: a home screen (Home/Work, recents,
  saved), car-side search (debounced, biased to your location), a route preview with up to 3 live-traffic
  alternates, and active turn-by-turn with the turn card, a "then" step, the lane diagram, a faster-route
  action, mute, and instrument-cluster support (NavigationManager navigationStarted/updateTrip - without
  which the old cut never showed a turn card). Rendering moved off the fragile VirtualDisplay+Presentation
  hack onto MapLibre's supported MapSnapshotter (bitmap → car surface) with route MAP-MATCHING (puck snapped
  to the route within 40 m), eased puck/bearing interpolation, speed-adaptive zoom, a look-ahead camera, the
  traffic-coloured route line, a speed badge + offline speed-limit disc, and auto-recenter after a pan.
  Assistant `geo:` intents route into it (with a fix for opaque-URI parsing that crashed the old handler).
  The phone stays the nav brain: the same NavSession singleton drives both, so a trip started in the car
  shows on the phone and vice versa. Day/night keys off the host's own dark-mode signal.
- ✅ Turn-by-turn engine (step advancement, off-route detection, reroute) - 
  pure/Android-free, **unit-tested** (arrival-requires-final-maneuver, reroute
  fires once per off-route transition not per fix, off-route clears on return).
  **Maneuver-sync fixes (2026-06-27, from a real highway drive where the line was
  right but the spoken/announced turns were ~6 mi out):** (1) the prompts + step
  advancement now measure distance to the maneuver **ALONG the route**, not
  crow-flies - crow-flies fired "take the exit" miles early wherever the highway
  curved back near the exit, then skipped the real one; (2) `placeManeuvers` now
  pins each turn to the **START** of its step, not the end (it added the step length
  *before* placing, so every turn sat a whole step too far - invisible on short city
  steps, miles off on a long highway step). The blue route line was always correct;
  these were both in the maneuver layer on top of it. **Regression-tested** so they
  can't come back: a curved route where crow-flies ≠ along-route (must not skip a
  loop-back turn that's metres away as the crow flies but km along the road), a long
  highway step (the turn lands at the step's start), and imperial vs metric phrasing
- ✅ **Offline nav auditor - the cards/voice-vs-blue-line diff** (2026-06-27, from the
  same highway drive, so this class of bug can be *seen* from a log instead of recalled).
  The navigated **route is now saved into the recorded trip** (`RP`/`RD`/`M` lines via
  `core/replay/TripLog`, one format shared by the writer in `:app` and the reader in
  `:core`), so a replay drives the **exact blue line the user saw**, not a fresh re-route.
  `core/nav/NavReplay` then replays a trip's GPS fixes back through the **real `NavEngine`**
  and diffs what the banner + voice claimed against where the maneuvers truly sit on the
  route: per turn - announced how far out, turn-now fired?, worst card-distance error,
  nearest approach - and **flags** silent/missed turns, miles-too-early announcements, and
  lying card distances. One-call `TripLog.audit(csv)` on a shared travel log, or the
  on-demand harness `:core:testDebugUnitTest --tests '*auditSharedTripLog' -DvelaTrip=<csv>`
  (prints the per-maneuver report + the spoken-line-vs-route timeline). **Unit-tested**
  end-to-end: clean-drive measurements (turns announced ~400 m out, track passes through
  each), the flag heuristics, and a full save→parse→audit CSV round-trip
- ✅ **Screen stays awake while navigating** (2026-06-21) - turn-by-turn holds
  `FLAG_KEEP_SCREEN_ON` on the activity window so the next turn is always visible on
  a windscreen mount without tapping to wake the phone. Gated by **Settings →
  Navigation → "Keep screen on while navigating"** (default **on**); the flag is
  cleared the instant nav ends, the toggle is turned off, or the map screen leaves
  composition, so the display sleeps normally everywhere else (no battery drain when
  you're not driving)
- ✅ Spoken guidance via AOSP TextToSpeech (engine-selectable) - **tuned for the
  car**: a measured speech rate (0.97) + neutral pitch, and on init it auto-selects
  the **highest-quality offline voice** for the locale (engines often default to a
  low-quality or download-required one), so guidance sounds natural, not robotic.
  Speaks **"Head east on …"** (the initial cardinal is computed from the route's first
  leg and injected, since Google's markup only says "Head toward …"). **Settings →
  Voice** lists installed engines, a **Test voice** button (hear it on your hardware),
  and a **System voice settings** shortcut to install/download a voice. **Spoken
  distances now follow the Units setting (2026-06-27):** the prompt distance was
  hard-coded "In N metres" regardless of Imperial/Metric - now `NavEngine` phrases it
  per the preference ("In 500 feet" / "In 0.2 miles" vs "In 150 metres"), with the
  `imperial` flag threaded from `Units.imperial` through `NavSession.onLocation`.
  **Road abbreviations are expanded for speech (2026-06-27):** the engine spelled out
  "Pkwy"/"St"/"Ave"/"N" letter-by-letter; `VoiceGuide` now expands them whole-word for
  the spoken text only ("Parkway", "Street", "Avenue", "North", "I-80" → "Interstate
  80"), while the on-screen banner keeps Google's compact forms
- ✅ **Speaks the road name - "turn right onto Larch Way", not a bare "turn right"**
  (a deliberate divergence: modern Google Maps shortened its *spoken* cue to drop the
  street name - a TTS-pronunciation/brevity choice, **not** scraper defence; the name is
  still in Google's data + on its banner, which is where we read it keyless). Vela
  generates its own TTS straight from the **written** instruction (which keeps "onto
  <road>"), so it speaks the full phrase - the old style some drivers prefer.
  Regression-tested (`spokenPromptNamesTheRoad`). *(When Google's own step text has no
  road name - some ramps/roundabout exits - Vela, like Google, says just "turn right";
  synthesising a name from the next road is a possible follow-up.)*
- 🐞 **Fixed: every turn drew a generic forward arrow (2026-06-27, on-device diagnosis).**
  The keyless feed tags maneuvers with a GENERIC token - `maneuver='TURN'` / `'ON_RAMP'` /
  `'ROUNDABOUT_ENTER_AND_EXIT'` - and carries the left/right + slight/sharp in a child
  `<turn side='LEFT' type='SLIGHT'>`. `mapType` only knew the explicit `TURN_LEFT`-style
  tokens, so **every plain turn and ramp fell through to `UNKNOWN`** → a straight-ahead
  arrow in the banner + the wrong direction-coded haptic, even though the text said "Turn
  left onto …". Now the parser reads `<turn side/type>` → correct TURN/SLIGHT/SHARP/RAMP/
  ROUNDABOUT arrows + haptics. (Road names on regular turns were always in the text and
  unaffected; **roundabout steps carry no road name keyless** - Google omits "onto X" there,
  a known keyless gap.) Pinned to the real captured markup (`DirectionsManeuverTest`).
- 🐞 **Fixed: route line gradient spamming MapLibre errors (2026-06-27).** `routeGradient`
  built a stops-less `step(line-progress, base)` whenever the line had no driven-grey and no
  traffic spans (any directions preview, and early nav) - which MapLibre rejects ("line-gradient
  Expected at least 4 arguments, but found only 2"), leaving the line unstyled and logging the
  error on every refresh. Now it always seeds a valid base-colour stop.
- 🐞 **Fixed: silent navigation** - on a targetSdk-30+ build, Android package
  visibility hid every TTS engine (`getEngines()` empty, the engine couldn't be
  bound) so guidance was silently dropped. A `<queries>` for `TTS_SERVICE` restores it;
  picking an engine now actually re-inits TTS (it used to be ignored). *(verified
  on-device: audio focus + frames delivered on nav start)*
- ✅ **One-tap voice on a ROM with no TTS** - many degoogled ROMs ship no engine at
  all, so **Settings → Voice → Install eSpeak NG / Install RHVoice** downloads the
  latest open-source engine from **F-Droid** (resolved via its API) and hands it to
  the system installer; once installed it's a normal engine Vela already drives - no
  heavy synth bundled into the app, works on any ROM. A nav-start hint points there if
  you have none. **Pipeline polished 2026-06-19:** the install button now shows an
  inline **spinner while downloading** (not just a persistent map banner), the status
  **auto-dismisses**, and when the direct APK URL 404s - **eSpeak ships per-ABI split
  APKs**, so the single-file path failed silently - it now **falls back to opening the
  F-Droid page** so the install still completes. *(verified end-to-end on-device:
  download → install → eSpeak appears as a Vela engine → speaks)*
- ✅ **Mute voice during nav** - a speaker toggle in the nav bottom bar silences /
  restores spoken guidance on the fly (Google-style), independent of the haptic cues
- ✅ **Speedometer** - a Google-style circular badge (bottom-left during nav) shows
  your current GPS speed in mph or km/h (follows the Units setting)
- ✅ **Scale bar** - a Google-style ⊔ bracket (bottom-left, by the attribution) sized
  to a round distance, with the distance label above it; reads the live
  metres-per-pixel from the map (correct for zoom **and** latitude on Mercator) and
  follows the Units metric/imperial preference (m/km ↔ ft/mi). Updates as you zoom/pan
- ✅ **Pan-away + Re-center** - dragging the map during navigation **detaches the
  follow-camera** so you can look around (it stops snapping back on every GPS fix);
  a **Re-center** button appears and reattaches it, then hides once you're following
  again (Google-style)
- ✅ **Haptic turn cues** - a light "get ready" tick at the pre-turn prompt, then a
  firm **direction-coded** buzz at the turn (left = two long pulses, right = three
  short, straight/other = one), so you can navigate by feel while biking/walking.
  Toggle in Settings → Navigation ("Vibrate on turns", default on)
- ✅ **Google-style maneuver banner** - a large **directional turn arrow** (the
  maneuver-type glyph, not a generic icon), the distance, the instruction with
  inline **highway/exit shields**, a **lane-guidance** strip, and a compact
  **"then <icon> …"** preview of the maneuver after this one - + remaining
  time/distance **and the arrival clock time** ("3.4 mi · 7:42 PM") on the
  bottom bar. The Steps control is icon-only + the ETA column flexes so a long
  "X mi · 7:42 PM" never pushes the **End** button off-screen
- ✅ **Swipe the banner to look ahead** - drag the maneuver banner left/right to
  walk the upcoming steps (Google-style): the card **tracks your finger** and, past
  a threshold, **slides off and the next/previous step slides in** (a pager-style
  flick, not an instant swap); it greys out, shows that step, and the map's marker +
  camera move there; tap it to resume live guidance. The **re-center button also
  appears while previewing a step** and **snaps you back to the current step** (not
  just the camera) - previously it left you parked on a previewed turn
- ✅ **Traffic-coloured nav ETA** - the big remaining-time readout in the nav bar is
  tinted by live traffic (green free-flowing → amber → red), or the normal ink colour
  when there's no live data (offline / a traffic-less route)
- ✅ **Minimisable route chooser** - a drag handle on the directions panel: **swipe
  it down to minimise** (peek the whole route on the map before you commit), swipe up
  or tap to bring it back; a compact **Start** stays reachable while minimised
- ✅ **Directions step list / overview** (before *and* during nav); tap a step to preview that turn on the map - placed at its **true cumulative distance** along the route line (matching the polyline's own length, not the summed step distances), so the previewed spot lands on the actual turn. **Pre-nav steps + ETA now match nav from the start (2026-07-02):** the default route can be a **provisional** Google alternate (it sorts to the top on live ETA) whose turn-by-turn is a placeholder and whose ETA is over un-snapped geometry - so the preview showed wrong turns/ETA that only "corrected" when you hit Start. `route()` now **eagerly names** a provisional default (OSRM-snap + re-applied traffic) the moment it's built, exactly as picking an alternate does, so preview == nav. **Step maneuver glyphs are bigger (2026-07-02):** they were `Modifier.size(24.dp).padding(end=16.dp)` - the padding insets the glyph *inside* the 24 dp box, shrinking it to ~8 dp; now a real 30 dp icon + a separate spacer. **Lane arrows highlight only the turn you're taking (2026-07-02):** in a valid lane, only the arrow whose direction matches the maneuver lights bright (the other directions the lane also allows stay dim) - so a "go straight" step no longer lights the right-turn head on a straight-or-right lane; when the maneuver side isn't encoded (merge / roundabout) a valid lane lights all its arrows rather than guessing; compound two-head arrows widened so they don't overlap.
- 🟡 **Foreground navigation service** - guidance continues with the app
  backgrounded / screen off via an **ongoing notification** (`NavigationService`, a
  `location`-typed FGS; `POST_NOTIFICATIONS` requested on Start). Google-style content:
  the next turn led by distance ("In 500 ft · Turn right onto Main St"), ETA · distance
  remaining, "faster route available" when one is, a dedicated **nav status-bar icon**
  (`ic_nav`, not the launcher logo), an **End** action, and tap-to-reopen. Updates live
  off `NavSession`; best-effort (a blocked FGS start on Android 14/GrapheneOS falls back
  to in-app nav, no crash). **Open quirk:** Start can drop the activity to the launcher
  while the service keeps running - needs on-device repro (ROM/timing-specific)
- ✅ **Periodic live re-routing** - every ~2 min while underway Vela re-checks
  traffic and, when a meaningfully faster route exists, announces it and offers
  a one-tap switch (`NavSession.maybeRecheck`, RECHECK_INTERVAL_MS = 2 min)
- ✅ **Free-drive follow glides like navigation (2026-07-14).** The follow camera used to ease
  toward the raw once-a-second fix - a target that jumps and then sits still, so the camera surged
  and stalled every second (the reported jitter and snap-back). It now dead-reckons the target
  forward between fixes along the last fix's own speed and course, exactly the trick the nav puck
  uses, so the camera chases something that moves like the car: a continuous inertial glide, no
  route required. Bounded to 2.5 s of blind projection and only while genuinely moving; each new
  fix re-anchors and the ease soaks up the correction instead of snapping.
- ✅ **Free-drive follow drives HEADING-UP, like navigation (2026-07-15; superseded the
  2026-07-14 north-up pass for driving).** Driving with no route now rotates the map so the
  puck always moves up the screen, never sideways - once you're at driving speed the camera
  eases to the GPS course, tilts to navigation's 55 degrees, and aims a speed-scaled distance
  ahead of the puck so the road ahead owns the view (the same framing nav gets from camera
  padding, done here with a projected aim point so nothing sticky survives the follow).
  Stopping at a light holds the heading; only ending the follow releases driving mode. The
  puck's own heading prefers GPS course over the compass while driving (car bodies wreck
  magnetometers), so the arrow and the map always agree. Walking or slow browsing keeps the
  north-up flat behavior from 2026-07-14 (leftover rotations still self-correct, the compass
  shows while settling), and a manual rotate is a gesture, which drops follow - nothing
  fights the user's hand. Pinch zoom is preserved in both regimes.
- ✅ **Route overview button during navigation (2026-07-14).** A new fly-over button in the nav
  button stack fits the whole route on screen - camera only, Google-style: guidance and voice
  keep running and the puck keeps moving along the overview. It marks the camera detached, so
  the existing Re-center button appears and glides straight back into the follow. (Google hides
  the step list behind a pull-up on its ETA bar; Vela keeps the dedicated Steps button instead -
  the bar has three controls and room for them, and the overview button is the part that earns
  its place.)
- ✅ **Dense-area cold load: steadier frames, no icon shuffling (2026-07-14).** Two costs fixed in
  the streamed first paint of a POI-heavy area: the collision priority used to be the place's
  position in the list, which RE-RANKS as search terms land, so every partial repaint reshuffled
  the whole layer's placement and icons visibly consolidated and popped into each other - the
  priority is now the place's own prominence, identical in every upload, so placement holds
  still while the set grows. And the partial repaints themselves escalate their batch size (10
  places for the fast first dots, 25 once the map is populated), so a dense downtown runs
  roughly half the full-layer placement passes during the load. Off-route counting is gated off
  while stationary so red-light multipath can't reroute a parked car, but creeping out of a
  parking lot sits under that 2 m/s floor the whole way - the deviation never accumulated hits,
  the reroute never fired, and the blue line stayed stale. A FAR deviation (90 m+, comfortably
  beyond anything stationary jitter invents) now counts at any speed.
- ✅ **Perf audit remediation, batch 2 of 2 (2026-07-15, PR-gated for a canary drive).** The
  upload-churn surgeries from docs/PERF-AUDIT-2026-07.md. (1) applyData's whole tail is now
  identity-gated like its head: alternates (up to 4 full polylines re-tessellated per
  recomposition with the chooser open - during the exact fit flight being watched), the
  location dot, the step-preview pin, the browse route gradient, the me-layer property sets
  and the ensure* style probes all skip when nothing changed, with every new gate registered
  in the style-reload reset so theme/palette/satellite flips still repopulate. Route-mode
  visibility flips became transition one-shots. (2) Ambient POI uploads DEFER while a discrete
  camera flight is in the air (a depth counter around the locate/fit/overview/preview flights -
  never the per-frame follow tickers, which would starve paints for whole drives); the first
  recomposition after landing uploads the full set at camera-idle where the placement pass is
  invisible. (3) The in-nav route split re-uploads only a 3 km leading WINDOW every 150 ms;
  the far tail lives on a twin layer refreshed once per window advance, with traffic spans
  remapped onto each piece and the seam computed identically on both sides - it also sharpens
  the traffic gradient (256 texels over 3 km instead of the whole trip). (4) The walk/bike
  dot regen went from millions of iterations per pinch (a fresh whole-polyline scan per dot)
  to one monotonic pass. (5) The speed-limit poll skips while a flight or two-finger gesture
  is in progress. (6) Result-pin bitmaps survive style reloads in a small process LRU instead
  of re-rasterizing on every theme flip.
- ✅ **Perf audit remediation, batch 1 of 2 (2026-07-15).** A 43-agent audit (every finding
  adversarially verified - see docs/PERF-AUDIT-2026-07.md) confirmed 21 issues; the six
  camera-seam fixes landed first because they ARE the reported hitches. (1) Re-attaching the
  nav follow from the route overview eased position/zoom/bearing but snapped tilt and the
  puck-low padding whole on frame one - both now seed from the live camera and ease in, so
  Overview -> Re-center glides. (2) Detaching the nav camera (a pan, the Overview tap) let
  the camera logic fall through to the pre-nav route-fit branch, which fired an uninvited
  800 ms whole-route flight on the next ~1 Hz recomposition and raced the real overview fit -
  the branch now swallows during nav. (3) The follow's cold engage from a far-out camera was
  an instant teleport that also cancelled the launch flight; it is now a single owned flight
  the follow waits out. (4) The compass pushed up to 16 whole-screen recompositions per
  second while hand-held; a 200 ms floor caps it. (5) Ending or swapping a route in the
  CHOOSER ran the nav camera teardown and killed the route-fit flight at frame one - the
  teardown now fires only after a real drive. (6) All point GeoJSON sources cap their
  internal tile pyramid (maxZoom 12), cutting re-tiling and placement invalidation during
  every zoom change. Batch 2 (upload gating, deferred ambient paints during flights, the
  route-split window, walk/bike dot regen) is queued in the audit doc. The visible
  signal/stop icons sat at the very bottom of the symbol stack - under the bridges and both
  blue route lines - so the (now wider) route stripe painted straight over exactly the icons
  that matter most during a drive. They now draw above the route lines and bridge geometry
  but below the basemap text and every POI layer, the way Google paints its signals on the
  route. Street names still can't collide with them: the invisible claim twin keeps placing
  an always-on collision box at every sign, so labels dodge sign positions regardless of
  where the visible icons paint.
- ✅ **In-nav compass toggle: heading-up or north-up (2026-07-15).** Tapping the compass that
  already sits below the maneuver card flips the follow camera between the default heading-up
  view and a north-up flat view that still follows the puck (position, speed zoom, puck-low
  framing all kept; the arrow rotates on the map instead of the map rotating under it), easing
  over a beat rather than snapping. Outside navigation the compass keeps its stock
  reorient-to-north tap. (First cut added a separate button to the nav stack; replaced same
  day with the existing compass per feedback.)
- ✅ **Two-finger tilt works during navigation (2026-07-15).** The shove gesture had no guard,
  so the follow ticker rewrote its own tilt every frame and the gesture jittered and lost.
  The ticker now steps aside during a shove (like a pinch), the resulting tilt sticks as a
  per-drive override the way pinch zoom does, and a shove's incidental finger drift no longer
  reads as a pan that detaches the camera. Cleared when the drive ends.
- ✅ **Route overview fits the WHOLE route (2026-07-15).** The in-nav overview used to fit the
  bounds while keeping the follow camera's rotation and 55-degree pitch, which shows less than
  the whole route however correct the math. It now levels to north-up flat as part of the fit,
  like Google's overview.
- ✅ **Locate button restores a consistent zoom (2026-07-15).** The tap's zoom animation was
  being cancelled mid-flight by the free-drive follow's per-frame camera writes, so the final
  level was wherever the animation happened to be when interrupted. While the follow is
  active the standard zoom now rides the follow ticker itself (position and zoom ease
  together, uncancellable); the plain animation stays for the not-following case.
- ✅ **Places-on-the-map controls (2026-07-15, Settings).** A new section with a master "Show
  places" switch (off = a clean basemap - the ambient layer, its fetch AND the OSM fallback
  business POIs all hide; searched results still draw), a "Parks, schools and civic places"
  toggle (drops the non-business tier from the ambient pool, filtered in state so tap
  indices stay aligned), a "Transit stops" toggle (icons + their per-viewport fetch), and a
  "Place icon size" choice (Small / Default / Large) that scales the ambient icons+labels,
  the mini-dot tier, the OSM POI icons, transit stops and traffic controls together - Small
  exists for low-density car head units (a 1024x600 screen renders the fixed-px bitmaps
  physically huge); phones default to 1.0 and are untouched. All toggles act immediately.
  Since 2026-07-20 the scale also covers the layers the first cut missed: search-result
  pins and rating bubbles (with their labels), the collapsed result dots, saved-place pins
  and the surveillance-camera badges - so a gas or restaurant search on a head unit shrinks
  with the rest of the map. Transit-stop badges also claim a collision box now, so nearby
  labels place around them instead of printing over them.
- ✅ **Fire stations are not bus stops anymore (2026-07-15).** The category classifier's
  transit branch matched the bare word "station" before the civic branch could claim "fire
  station", so fire houses drew with the transit icon. Civic now classifies first, and the
  bare "station" keyword excludes the non-transit flavors (power, pumping, radio, ranger,
  weigh, polling stations and friends).
- ✅ **House-number searches resolve locally, like Google (2026-07-15, reported with two
  local test addresses).** Two holes closed. The on-device address geocoder (exact and
  interpolated house numbers from the downloaded pack) now joins ONLINE searches and
  suggestions for address-looking queries - it was gated to the offline/Google-failed path,
  so a wrong-but-nonempty Google result set blocked it completely, which is exactly what
  numbered streets with directional suffixes produced. And the suggest dedupe that dropped a
  Photon/local address hit whenever ANY Google suggestion sat within a block of it (on a
  commercial road, something always does) now only drops it when the Google entry carries
  the same house number. Address hits lead the list: local pack, then Photon, then Google.
- ✅ **Arrival speaks ONE line (2026-07-15).** "Your destination is on the right" when the
  route knows the side; "You have arrived" only as the fallback when it doesn't - they no
  longer stack.
- ✅ **Google-width route stripe (2026-07-15).** The blue route line (and the grey alternates
  a step thinner) scales with zoom instead of a constant 6 px: browse zooms look the same,
  street/nav zooms draw the fat stripe Google does.
- ✅ **A degraded route can no longer masquerade as a "faster route" (2026-07-15, real-drive
  report).** When the ~2-min recheck's Google fetch fails, the candidate comes back
  trafficless with abbreviated steps - and its free-flow ETA, compared against the live
  traffic-aware remaining time, always looks like a big saving. Accepting one explained a
  whole cluster of symptoms in one drive: a suspiciously fast ETA, white ETA text instead of
  traffic colours, no lane guidance (abbreviated Google steps carry no lane data), and the
  time "syncing back" to Google's a recheck later. Three gates now: a trafficless or
  abbreviated candidate is never OFFERED as faster (its ETA isn't comparable), a trafficless
  candidate never drives the live ETA recalibration, and the same-course self-heal that
  already restored full steps after an OSRM blip now also restores live traffic - a white
  ETA turns traffic-coloured again on the next recheck instead of staying white for the
  rest of the drive (neither quality can downgrade in the swap).
- ✅ **Faster wrong-turn rerouting (2026-07-15, reported: "waits far too long").** Three
  coordinated cuts to the off-route detection lag in `NavEngine`: the on-route corridor
  tightened 45 → 40 m (moving GPS error is well under 20 m plus a lane offset, and on a
  shallow-angle wrong road the corridor width is most of the wait), the jitter debounce
  dropped 4 → 3 consecutive off fixes, and a fix that is BOTH moving and unambiguously far
  off (90 m+, beyond anything jitter invents at speed) now counts double - so a clearly
  wrong road triggers the reroute after ~2 fixes instead of a full debounce. Stationary
  protection is untouched: a parked car at a red light still never reroutes.
- ✅ **Swipe down to dismiss the steps overview (2026-07-15).** The turn-by-turn step list
  (route preview and in-nav) now rides the finger down and dismisses on a flick or past a
  third of its height, springing back otherwise - the same drag grammar as every other
  sheet, with a grab handle to signal it. The X button and back gesture still work; drags
  over the list itself keep scrolling the list.
- ✅ **Google's label density at browse zooms (2026-07-14).** The ambient POI layer used to name
  every dot its collision pass could fit; Google names only a handful of anchors at browse zoom
  and lets the rest sit as bare icons/dots, with more names joining as you close in (A/B'd
  against the Google Maps app on the same downtown frame: ~7 named at their z15, ~13 plus bare
  dots at z17). Labels are now tiered by zoom x prominence: below z15.5 only true landmarks
  (prominence ≥ 6.0, roughly 400+ reviews) carry names, z15.5+ adds established places (≥ 5.0),
  z16.5+ names any real business (≥ 3.0, ~20+ reviews) while 0-review junk stays a dot, and
  z17.5+ names everything visible. Doubles as a dense-area frame win: an empty textField skips
  that symbol's label placement entirely, so browse zooms in a POI-heavy downtown run far fewer
  collision candidates per placement pass.
- ✅ **Fixed: ambient prominence silently zeroed on cold starts (2026-07-14).** Live-bisected on
  device: for the first ~3 seconds of a fresh session Google serves a stripped per-place block -
  rating present, review count ABSENT - and the exact same query+pb returns the full block once
  the session warms. The ambient category fan-out fires immediately at cold start, so its whole
  pool parsed with no review counts, which zeroed `ambientProminence` and quietly flattened
  everything keyed on it: prominence ranking (the anchor-beats-tenant logic), data-driven dot
  sizing, and the new label tiers all ran on zeros (and the disk cache then preserved the
  zeroed pool). `nearbyPlaces` now detects the slim flavor (rated places but a majority missing
  counts) and refetches once after the session warms; the rich pool replaces the slim one and
  the cache stores real counts. Costs one extra fan-out on cold start only.
- ✅ **Tunnels: navigation keeps estimating (2026-07-14).** When GPS dies mid-drive while solidly
  on route, Vela now synthesizes position ALONG THE ROUTE at the last speed (decaying over ~a
  minute, capped at 3 km of blind travel) and feeds it through the normal guidance path - so the
  arrow keeps moving, the banner keeps counting down, and turns still announce inside the tunnel,
  Google-style. The "Searching for GPS" chip stays up the whole time so the estimate is honest,
  and the first real fix re-anchors everything. Never during replays, never off-route, never
  from a standstill.
- ✅ **Nav declutter: no bus stops (2026-07-14).** The canonical transit-stop icons and their name
  labels hide during turn-by-turn (browse furniture, not a driving aid) and the per-viewport stop
  fetch skips while navigating.
- ✅ **Closer nav zoom (2026-07-14, closer again + 30% bigger puck 2026-07-15).** The
  speed-adaptive follow zoom now runs 18.5 (stopped) down to 15.8 (highway) - originally
  17.3-15.0, then 18.0-15.5 - with the puck riding low, the extra zoom is all road ahead.
  Pinch still overrides. The nav puck grew ~30% alongside it (176 px disc, redrawn at native
  size, not raster-scaled).
- ✅ **The road ahead owns the nav view (2026-07-14).** The follow camera renders the puck low on
  the screen (~72% down, via a sticky top camera padding reset when nav ends) instead of dead
  centre, so the view shows what's coming instead of splitting evenly with what's behind -
  Google's framing. Applies to the engaged follow and the pre-engage stationary framing alike.
- ✅ **Step preview no longer fights the follow camera (2026-07-14).** Swiping the maneuver cards
  flies the camera to the previewed turn, but the 60 fps follow ticker kept re-pointing it at the
  puck in the same frames - the two fought and the preview barely moved. Follow now yields while
  a preview is up (the puck keeps updating the whole time, only the camera steps aside), and
  Re-center or ending the preview hands the camera back with the usual smooth re-attach.
- ✅ **"Live traffic re-checks" privacy toggle (2026-07-14, Settings → Data & privacy).** The
  ~2-minute in-drive re-check sends your CURRENT position to Google - that's what makes a
  from-here candidate possible, and it's a periodic location beacon on top of the origin sent at
  start and on reroutes. It's now opt-out-able: off means no periodic requests (and therefore no
  faster-route offers, live ETA recalibration or abbreviated-steps self-heal); off-course
  reroutes still work, because navigation can't without them. PRIVACY.md documents the whole
  in-drive picture.
- ✅ **The traffic fetch retries like the router does (2026-07-14, from a real-drive report).**
  Google's keyless directions reply intermittently comes back degraded or empty (worst right
  after a burst of requests, like ending a route and restarting it), and it used to get exactly
  ONE attempt while OSRM got three - a single miss cost the whole fetch its traffic ratio, its
  jam-avoiding snap AND Google's alternates, so the picker led with free-flow OSRM routes whose
  white, trafficless ETAs read minutes faster than anything traffic-aware and varied drastically
  between restarts. `googleDirectionsRetried` now gives it the same 3-attempt backoff; a
  genuinely unreachable Google still degrades to free-flow, just honestly rarer.
- ✅ **Abbreviated-steps self-heal mid-drive (2026-07-14, from the same report).** If the open
  router is unreachable when a reroute fires, the fallback is Google's keyless route: complete
  polyline, ABBREVIATED maneuvers (a 6-mile route once carried 2 of ~10 turns) - the banner and
  voice then disagree with the blue line, and the line is the one telling the truth. Those
  routes are now tagged at the source (`Route.abbreviatedSteps`, also set when naming a picked
  alternate fails), and the ~2-minute recheck upgrades an adopted one SILENTLY the moment a
  full-stepped same-course candidate comes back: same path, fresh traffic, real turns, instead
  of staying degraded for the rest of the drive.
- ✅ **The arrival ETA tracks LIVE traffic even with no course change (2026-07-14).** The engine's
  remaining time scales the leftover step durations by the route's traffic ratio, which used to be
  frozen at whatever the traffic looked like at the LAST route fetch (nav start, or a reroute) for
  the entire drive - a jam forming ahead never moved the arrival time until you deviated. Now the
  same ~2-minute recheck that hunts for faster routes also RECALIBRATES the shown ETA: when the
  fetched candidate follows the route you're already driving (all sampled points within 250 m of
  the current line - `SAME_COURSE_M`, deliberately tighter than the 700 m jam-detour test so a
  parallel alternate can't calibrate the wrong road), its fresh traffic-aware ETA becomes the new
  baseline (`etaScale`, a multiplicative correction on every published remaining duration - the
  phone banner, the notification and the Android Auto card all read it). The correction resets
  whenever the route itself is swapped (a fresh route carries fresh traffic), is clamped to
  0.5-2.5x against a bad candidate, and the faster-route offer logic now compares against this
  live baseline too. Hermetic replays never recalibrate (no live fetches, as before).
- 🟡 **Posted speed-limit badge (2026-07-04; LIVE everywhere online via the streamed overlay below - only the offline-graph path still needs re-baked graphs).** During
  nav a Google-style speed-limit sign shows by the speedometer - **US MUTCD** style (white rounded rect,
  "SPEED LIMIT" + number) in imperial, **EU/RoW** (white disc + red ring) in metric, and the number reddens
  when you exceed the limit + a tolerance (GPS speed is noisy). Source is **OSM `maxspeed`, keyless + offline**
 - not Google (Google gates posted limits behind the paid Roads API; they're absent from the keyless
  payloads). Read from the **on-device GraphHopper graph Vela already ships**: `max_speed` was added to the
  graph's encoded values (`GraphBuilder`/`GraphHopperRouteEngine`, byte-identical), and `currentRoadLimit(lat,lng)`
  snaps the live fix to the nearest edge and reads it off the **base graph** - CH-safe (encoded values aren't
  on the CH overlay), route-independent (tracks the road under the puck even off-route), off the main thread,
  distance-gated + single-flighted per fix (`MapViewModel.updateSpeedLimit`); a sustained untagged stretch
  clears a stale limit rather than showing it forever. **Crash-safe by construction** (every GraphHopper call
  is `runCatching`-wrapped): a graph built before `max_speed` simply hides the badge - no crash, no routing
  regression - so existing installs are unaffected. **Adversarially reviewed** (GH 11 decompiled: US mph
  round-trips exactly; 150 km/h deliberately blanked since GraphHopper stores both a real 150 zone and a
  derestricted road as 150). Verified: a Monaco graph rebuilds cleanly with `max_speed` + CH. **Coverage =
  OSM `maxspeed` (partial)** - strong on highways/EU/urban, sparse on US residential. **Remaining to light it
  up for everyone: re-bake + re-host the region graphs with `max_speed` (CI), then a fresh region download
  shows it** (a version-discriminator so *existing* offline graphs auto-re-download is a small follow-up). **Now shown in FREE-DRIVE too (2026-07-12, user request):** the same `updateSpeedLimit` already ran on every live browse fix, it was only *rendered* during nav; the sign now also appears while you're simply driving with no route open (moving, on the clean map); it shares the unified speed box, which in free drive sits LOW in the corner, level with the locate button (2026-07-14) - only during nav does the box ride up to clear the ETA bar, and the scale bar yields the corner whenever the box is there. **Speed A** of the plan; **Speed B** (a keyless maxspeed PMTiles overlay) will remove the download-a-graph requirement so limits show anywhere, and the same badge lookup will fall back to it when no graph covers the road.
  shows it** (a version-discriminator so *existing* offline graphs auto-re-download is a small follow-up).
- ✅ **Speed-limit STREAMER - online maxspeed everywhere (2026-07-12, device-verified on a simulated drive).**
  The "Speed B" source so a posted limit shows **without a downloaded routing graph**. The data half already
  ships: `scripts/build-maxspeed-region.sh` + CI bake each region's OSM `maxspeed` ways into a small PMTiles
  overlay on the `maxspeed-overlays` release (all 50 US states hosted, e.g. Washington 31 MB). The app half now
  **streams** the covering region's PMTiles (`MaxspeedOverlayStore`, no download - MapLibre range-fetches the
  visible tiles), adds it as an **invisible-but-queryable** line layer, and every ~2.5 s while driving
  `queryRenderedFeatures` under the puck reads the `maxspeed` tag (`OsmMaxspeed.parseKmh`, unit-tested: bare
  km/h, `mph`, `none`/country-codes → null). The sign now prefers the offline graph and **falls back to this
  overlay** (`speedLimitKmh ?: speedLimitOverlayKmh`), so it lights up anywhere online. Keyless, ODbL.
  **Device-verified on a simulate-driving run (4a, no WA routing graph downloaded): the streamed overlay read
  72.42 km/h under the puck on the arterial and the sign showed "SPEED LIMIT 45" (`offline=null`).** Parser
  unit-tested; the WA maxspeed PMTiles streamed live (~640 range requests) and kept up with the demo puck.
- ✅ **Speedometer = a rounded rectangle now, not a circle (2026-07-12).** The traveling-speed readout during
  nav was a dark circle, which read differently from the rounded-rect SPEED LIMIT sign right above it. It's now
  a **rounded rectangle the same width + corner radius as the limit sign**, so the two stack as a matched pair
  (Google's layout) and your speed is trivially comparable to the posted limit at a glance. Dark fill keeps it
  distinct from the white limit sign. Device-verified paired on a drive: "SPEED LIMIT 45" over "45 mph".
- ⬜ Speed-camera + hazard alerts (lane guidance ✅ done above)
- ✅ **Android Auto - first cut shipped 2026-07-08** (see the entry at the top of this section). The old
  "needs GMS, out of scope" call was wrong: the car app library is plain androidx, and a sideload runs fine
  with AA's Unknown sources on. Remaining: car-side search + route start, and a real head-unit drive.
- ✅ **Arrival / trip summary** - on reaching the destination, a "You've arrived"
  card replaces the nav controls with the trip's total time and distance (and the
  destination name), and a Done button returns to a clean map. **Fixed 2026-06-20
  (test-drive bug): nav was declaring "arrived" up to tens of km early** - Google's
  step distances total a few % short of the route geometry, so `placeManeuvers` placed
  the ARRIVE maneuver at `sum(stepMeters)/polyLength < 1.0` (observed ~15 km short of a
  134 km route's end) and the 25 m arrival trigger fired there. The final maneuver is now
  pinned to the route end; diagnosed + verified on-device by replaying the recorded trip
  (`arriveLoc` now equals the destination). Unit-tested. (Foreground-service + live
  re-route hardening still pending a full on-device drive.)

## Location (degoogled)
- ✅ AOSP `LocationManager` (GPS + NETWORK), no Fused/GMS
- ✅ Last-known seeding for instant map; PSDS slow-fix tip
- ✅ **Google-style location indicator** - two modes. **Browse:** a blue dot (Google's `#4285F4`) with a white ring + a translucent heading cone/beam beneath the dot - points the **device-facing compass** (the `TYPE_ROTATION_VECTOR` sensor via `HeadingProvider`, low-pass smoothed along the shortest arc, OsmAnd-style) so it shows which way you're facing **even standing still**, where the GPS bearing is noise (2026-06-27); falls back to GPS course when the sensor's absent, hidden when neither is available. *(Navigation never uses it - there the heading comes from the matched road; the sensor heading is pushed to state only in browse and only on a real change, so it can't spam recomposition during nav.)* The dot **greys out when the fix is stale** (~12 s, or before the first live fix) and blue again on a fresh fix. **Free-drive follow (2026-07-11, user request - "driving along without a route open, the camera should track me, and the heading beam should be smooth like in-nav").** When the map is open and unobstructed the camera now **tracks your fix north-up** and the **heading beam eases per frame** the same way the nav puck does - a sibling of the nav motion ticker (`LaunchedEffect(navMode, driveFollowing)` in `VelaMapView`) that OWNS the location source while it runs, so the beam glides instead of chasing every jittery compass sample (the raw per-recomposition repaint is what made it twitch). On by default; a **pan drops follow** (Google-style "let me look around") and the **locate FAB re-arms it**. Suppressed whenever a focus surface owns the camera (search, a selected place, directions, the results list) so it never fights that framing, and idle frames are skipped (a settled follow at a red light doesn't re-upload the point or re-drive the camera 60x/s). Nav keeps its own tilted, speed-zoomed follow. *(Feel tuning - the 0.16 s camera ease + 0.15 s beam tau - to confirm on a real drive; revertible.)* **Nav:** a **solid blue arrow puck** (the dot is hidden) that **snaps onto the route line** and faces down the road, so lateral GPS jitter doesn't make the marker jump. The snap is **honest, not a lie**: it engages only when you're genuinely following the road - within ~22 m (≈ a road width + GPS error) **and** heading the road's way (±55°); a missed exit / off-road / wrong-way fails the gate and shows the **real** position so you can see the divergence (then the off-route reroute kicks in), Google-style *(arrow puck + heading-gated snap added 2026-06-20 from test-drive feedback - "we need an arrow", "don't snap so it's out of touch with reality"; verified on-device via trip replay)*. The puck rides a **Google-style forward-progress motion model** (added 2026-06-21) instead of teleporting to each raw fix: a per-frame ticker glides it **monotonically forward along the route** with **dead reckoning** (between the ~1 Hz fixes the position keeps advancing, so it never stalls mid-second), **eased** progress (it never jitters backward) and **smoothed heading** (rotates through bends instead of snapping at every vertex). **Accelerometer-fused speed (2026-07-01)** - the dead reckoning no longer glides at the *last fix's* speed (which overshot the moment you braked, and the monotonic progress could never walk it back - the puck sat metres ahead of a stopping car until it "caught up"): a **1-D Kalman filter** (`core/location/SpeedKalman`, unit-tested) fuses the GPS speed (measurement, each fix) with the **measured forward acceleration** (prediction, every frame - `TYPE_LINEAR_ACCELERATION` rotated into the world frame by `MotionProvider` and projected onto the travel bearing), and the reckoned advance is the **integral of the modelled speed** (∫v·dt, still blind-capped at 2 s). So braking collapses the predicted speed NOW, Google-style, and the puck decelerates with the car between fixes. No accelerometer → a = 0 → exactly the old constant-speed behaviour (and the filter still jitter-damps the GPS speed). The speed-adaptive zoom rides the same filtered speed. *(Road-test pending - tuned constants in `SpeedKalman`.)* The on-route match is **forward-only and monotonic, modelled on OsmAnd's `RoutingHelper`** (2026-06-21): once engaged it searches a **bounded look-ahead AHEAD of the current progress only** (`snapToRouteWindowed`, from `targetM − 25 m` to `targetM + speed·8 s` clamped 150–600 m) - never behind, never the whole route - so a route that **passes near itself** (switchback / cloverleaf / parallel return leg, or an ordinary road that runs close to itself) physically can't pull the puck onto a far or earlier leg. When nothing's ahead within tolerance (a GPS spike or a real off-route) it **HOLDS and dead-reckons forward instead of re-snapping globally** - the old global fall-back is exactly what teleported the camera to "a random spot along the route" - and only a sustained run of misses (~6 fixes) disengages to re-acquire, while `NavEngine`'s own off-route logic drives the reroute. The one global search left is the **initial acquisition** at nav-start / just after a reroute. *(Evolution: the first 2026-06-21 pass windowed the search but still fell back to a global nearest-point on any off-route blip and could re-anchor backward - replay was "better but still jumps to a random spot"; the forward-only matcher closes those two holes at the source.)* **The follow-camera tracks this same smoothed point** - not the raw fix - so the puck and the map move as one and the view no longer lurches to a far spot when nearest-point is briefly ambiguous; **off-route it now holds the last road-aligned heading instead of spinning to the raw GPS bearing** (which jittered and could point the map the wrong way on a brief off-route blip). The **traversed-grey split rides the puck's DRAWN position (`progressM`)** - exactly where the arrow renders, not the `targetM` it's easing toward - and is drawn as a **hard `step` at the EXACT fraction** (2026-06-21), not quantized to a 256-sample grid: the old sampling left the grey/colour boundary up to route-length/256 m (~80 m on a long route) *ahead* of the arrow, which read as a soft "gradient" before driven areas; now it's a clean solid cut dead under the puck, no feathering ("we either drove it or we didn't"). **The cut is also refreshed in the 60 fps motion ticker (2026-06-22, throttled to ~3 m of progress)**, not just at recomposition - otherwise it lagged the per-frame arrow at speed and left a sliver of coloured route just *behind* the arrow. (Still can't land on the wrong leg.) *(Forward-only matcher unverified on a live drive at ship time - to be confirmed by replaying a recorded trip on the new build, since mock GPS is too clean to reproduce the wrong-leg snap.)* **Heading & speed are synthesised from movement when a GPS fix doesn't carry them** (cold start, just-started-moving, some chipsets/ROMs) - gated on real movement so a standstill's jitter can't spin the marker - so the arrow always points the right way and dead-reckoning always has a speed. **A single-fix speed SPIKE is rejected** (2026-06-21) - a GPS glitch ("going 35, hops to 157 mph"); a car can't gain >15 m/s between fixes, so the prior speed is kept, in **both the live and the replay paths** (recorded traces carry the raw glitches too), so the speedo, dead-reckon and zoom don't lurch on a bad reading. **Position OUTLIERS are rejected the same way** (`sanePosition`, 2026-06-21): a coarse **NETWORK / multipath fix** that leaps farther than is physically plausible for the elapsed time - the network provider interleaving with GPS is the "every ~8 s the dot + distance + mph jump to a crazy number" jitter - is dropped, and the position runs through a **speed-adaptive low-pass** (2026-06-22) - heavy smoothing at low speed so parked/idle GPS jitter barely nudges the dot, easing to a 1:1 follow by ~10 m/s where real movement dominates the noise. Google smooths position this way; **OsmAnd notably does NOT** (its dot hops - it only Kalman-smooths the *heading* from sensors), so this is actually steadier than OsmAnd at idle. (Replaced a binary standstill-hold whose hard speed-cliff the GPS speed-noise kept tripping.) Live + replay. *(2026-06-22 fix: the **first fix of a session anchors** and a leap that **persists ≥2 fixes re-anchors** - without it, a replay that starts away from your live position rejected every fix as an outlier vs the stale start point and the dot never moved ("replay thinks I'm stationary").)* *(motion model + camera-locked-to-puck + derived heading/speed; **verified on-device 2026-06-21** via a mock-GPS drive of a real 14.5-mi Davis→Sacramento route: arrow puck tracking, solid grey-behind/blue-ahead route, heading-up camera locked to the puck through the I-80/US-50 interchange with no snap, and the banner/HUD counting down monotonically - `remaining` 14.5→11.9 mi with 0 monotonicity violations across 75 nav updates)*
- 🟡 BeaconDB WiFi positioning - NETWORK-provider coarse fixes are already used for the browse dot when GPS has been quiet (never during nav); an explicit opt-in and any deeper use are still open

## Offline
- ✅ **Offline maps live in Settings, not onboarding (declutter 2026-07-10; the 2026-07-07 first-run offline prompt was removed).** A one-time first-run prompt used to offer offline setup right after the voice offer. It was cut to keep onboarding short - a brand-new user hasn't searched anything yet, so "download an area" has no context. Offline map + routing downloads remain fully available in Settings → Offline (the section a search-with-no-signal or the locate flow points you to), which is where the download actually belongs.
- ✅ **Settings → Offline is collapsible (2026-07-02)** - collapsed by default (tap the header to expand), so its long routing-region list doesn't force a big scroll past to reach the sections below it.
- ✅ **Offline basemap region downloads** - **Settings → Offline → Map area → "Download the
  area you're viewing"** saves the last on-screen area's tiles/glyphs/sprites (via
  MapLibre's built-in offline store) so it renders later with **no network**; the
  same section manages/deletes saved areas. (Moved off the map FAB stack to declutter;
  the viewport is captured on camera-idle.) Open tiles, no Google, no backend.
- ✅ **Offline search** - downloading a map area also pulls its POIs from
  **OpenStreetMap/Overpass** (keyless) into an on-device SQLite index; when Google
  search can't be reached, search falls back to that index ("Offline results"). The
  index now **keeps the POI detail** OSM carries - **address, phone, website and
  opening hours** (from the `addr:*` / `phone` / `website` / `opening_hours` tags) - 
  so an offline place sheet isn't just a name on a pin (sparser than Google, but real).
  **Category words work offline now (2026-07-07):** the index is populated from OSM tags, so a gas
  station is stored as category "Fuel" (from `amenity=fuel`), not "gas" - a plain name/category LIKE
  missed it, so searching "gas" (or tapping the Gas chip) returned nothing and wrongly said "download an
  area". `OfflinePoiStore` now expands common words and the map's own category chips to the OSM tag
  values it stores (gas → fuel, coffee → cafe, food → restaurant/fast food, groceries →
  supermarket/convenience, pharmacy, hotel, bank, …), so offline category search works. **Multi-word
  queries work too (2026-07-07):** the search matches the whole phrase OR any word ≥3 chars, and ranks
  by how many query words hit the name/category, so "fast food" leads with the fast-food places and
  "mexican restaurant" surfaces the Mexican one instead of returning nothing. Device-verified (airplane
  mode): "gas" → Safeway Fuel Station, "restaurant" → Subway/Papa Murphy's/Applebee's,
  "fast food" → the two fast-food spots first. And when you DO have a downloaded area but nothing
  matches, the message is now "no offline results for X in your saved area" instead of telling you to
  download one you already have. Offline search also matches a POI's stored **address** now, so typing
  the street address of an indexed OSM place finds it.
- ✅ **True offline address routing - typed address → coordinate → route, no signal (2026-07-07).** Downloading
  a map area now also builds an on-device **forward geocoder** (`OfflineAddressStore`, SQLite), so an arbitrary
  typed street address resolves to a coordinate offline and routes via the on-device GraphHopper engine - not
  just addresses that happen to be an indexed POI. Two OSM sources, fetched (keyless Overpass) over a **padded
  ~15 km box around the viewport** (not just the few blocks of tiles on screen, so a saved area covers the
  surrounding metro): **`addr:housenumber` points** for house-precise hits, and **named road centrelines**
  (thinned to ~one point per 120 m) for a street-level fallback where OSM has the road but no house numbers - 
  the reality in new US suburbs, where houses are sparse but streets are complete. Geocoding is layered:
  (1) exact house number on the street, (2) **interpolate** the house's position between the two nearest
  mapped numbers ("1022" lands between 1020 and 1024), (3) nearest mapped house on the street (right block),
  (4) nearest point on the street's own centreline (works with zero mapped houses). Street matching is
  abbreviation-normalized ("Blvd"↔"boulevard", "W"↔"west"), so "W Covell Blvd" and "West Covell Boulevard" hit
  the same rows. **Device-verified (wifi fully off, in a residential suburb with thin OSM coverage):** the
  download saved **8591 addresses + 1466 streets**; a typed street address resolved to the right spot and
  routed *5 min · 1.5 mi* from on-device GraphHopper; an arbitrary house number on another street resolved
  through the fallback layers too. Names/streets themselves are never translated (data). Routing still works to
  anything else you can put on the map (offline search result, long-pressed pin, Choose-on-map).
  **Offline POIs now show an address (2026-07-07).** Most US chains have no `addr:*` in OSM (Applebee's came
  back as bare "WA"), so an offline place sheet showed no address. Opening an offline POI with no real street
  now **reverse-geocodes its location against the same on-device index** (`OfflineAddressStore.reverseGeocode`):
  the nearest mapped house within 60 m (usually the POI's own building), else the nearest street name within
  150 m. Device-verified: Applebee's offline now shows the street it sits on plus its
  OSM phone/website/hours.
  **No misleading "current traffic" offline (2026-07-07).** The directions ETA subtitle only says "current
  traffic" when the route actually carries a live in-traffic ETA; an offline GraphHopper route (or any
  traffic-less route) shows the arrival time with no traffic note instead of a false "current traffic".
  **Upgrade nudge for older saved areas (2026-07-07).** Because the address index is built at download time,
  areas saved before this feature have tiles + POIs but no address data. Settings → Offline shows a one-tap
  "Update saved areas" card when you have saved areas but the index is empty; it re-fetches the address/street
  data for every saved area so you don't have to re-download each one by hand. Localized in all supported languages.
- ✅ **Whole-region offline place packs - Organic-Maps-style state-wide search (2026-07-07, device-verified).**
  The gap this closes: Organic Maps finds "pel meni" in Fremont from anywhere in Washington offline, because its
  download carries the whole state's POI index; Vela's offline search only knew the small viewport areas you'd
  saved. Now **downloading a state (routing region) also pulls its PLACE PACK** - a per-region SQLite database
  baked by CI (`scripts/build-poi-region.sh` + `poipack_build.py`, workflow `poi-packs.yml`, hosted on the
  `poi-packs` release like the routing graphs) from the same Geofabrik OSM extract, holding the entire region's
  **named POIs (with address/phone/website/hours), address points and street names**. The pack schema is
  normalized (street names deduped into an int-keyed lookup) so a state stays reasonable: Washington - one of
  the heaviest US states, 163k POIs + 2.8M addresses + 1.2M street points - is **143 MB zipped** (was 761 MB
  naive). `OfflinePoiStore`/`OfflineAddressStore` query every installed pack alongside their own index
  (`OfflinePacks`), and the normalized shape keeps whole-state queries fast (street matching scans ~90k distinct
  names, never the 2.8M-row table; the big tables are hit through sid/housenumber/lat indexes). Packs ride the
  routing region: downloaded after its graph, deleted with it; regions installed before packs existed get a
  **"Get places"** button on their Settings row (and a friendly "no pack published yet" note while the catalog
  builds out). **Device-verified end-to-end (wifi off):** searching "pel meni" from the downloaded suburb returned
  Pel'Meni Dumpling Tzar · 3518 Fremont Place North (plus the Capitol Hill and Bellingham ones),
  ranked by relevance then distance, and its place sheet opened with address/hours/phone/website - all OSM,
  no signal. Typed-address geocoding also gains the whole state (the pack's addr/street tables feed the same
  layered geocoder). Localized in all supported languages.
- ✅ **Place packs stay fresh: monthly rebuilds, an Update button, and small delta downloads (2026-07-07,
  device-verified).** OSM never stops changing, so the packs can't be a one-time bake. Three pieces. First,
  `poi-packs.yml` runs on a monthly cron and rebuilds every published region from the current Geofabrik
  extract; each rebuild bumps that region's `rev` in the manifest. Second, once the manifest carries a newer
  rev than the one installed (tracked in `poipacks/revs.json`), the region's Settings row shows "Update
  available" and an **Update places** button. Third, the update is normally a **row-level delta**, not a
  re-download: CI diffs the new pack against the previous rev with SQL EXCEPT (`scripts/poipack_delta.py`)
  and publishes a small zip of del/ins tables when it comes out under half the full pack size; the app
  (`PoiPackStore.applyDelta`) applies it in a single transaction and verifies the result against per-table
  row counts from the manifest before committing, so a bad patch can never leave a half-updated pack. A
  verified Washington test delta was **5.6 KB against the 143 MB pack**. Anything off (wrong base rev, no
  delta published, count mismatch) quietly falls back to a full download. The piece that makes deltas small:
  street-name ids are **stable content hashes** (SHA-1 of the normalized name), not insertion counters, so a
  rebuild only changes the rows whose data actually changed. Device-verified end-to-end: a staged rev bump
  updated Washington through the 5.6 KB delta alone and the changed place was searchable offline right after.
- ✅ **Offline search ranks exact name matches above the category flood (2026-07-07).** A whole-state pack has
  thousands of rows matching a category word ("cafe"), and the internal 400-row candidate cap used to fill in
  table order before a name match deep in the table was reached, so searching a place by its exact name could
  come back empty. The pack SQL now orders whole-query name matches first, ahead of the cap.
- ✅ **State downloads show a heads-up progress card (2026-07-07, device-verified).** A routing-region download
  (and the place pack that follows it) now shows the same map heads-up progress card the Vela-voice download
  gets - "Downloading Washington (state) routing · N%" then "Saving Washington (state) places for offline
  search · N%" with a live bar - so a Settings-started state download stays visible after backing out to the
  map instead of running invisibly.
- ✅ **Quiet offline indicator, no banner (2026-07-07).** When there's no connection, instead of a card hanging
  over the map Vela shows two subtle cues: a greyed **globe-with-a-line-through-it icon + "Offline"** in the
  search bar (before the settings gear, only on the bare map), and a small **globe-slash chip tucked just under
  the category chips**, next to the search box. Driven by a reactive `ConnectivityManager` default-network callback (`MapUiState.offline`),
  seeded on launch and updated on every network change (fails safe to "online"). The old "Offline results"
  status line was removed - these two cues already say it. Device-verified in both the search bar and on the map.
  **Graceful when there's nothing to show (2026-07-07):** searching with no connection (or on a
  wifi that's connected but has no real internet, so the Google call fails with a host/timeout error)
  and no downloaded area now shows the plain guidance *"You're offline. Download an area in Settings ▸
  Offline to search without a connection."* instead of a raw "Unable to resolve host" error
  (`isConnectivityError` maps DNS/route/timeout/SSL failures to the offline message)
- ✅ **Open building-footprint overlay (Microsoft, ODbL - 2026-07-04, device-verified).** Fills the map's
  building gaps where OSM is thin (a suburb the Microsoft→OSM import never reached). **Online it
  STREAMS automatically - no download to see houses (2026-07-05):** the overlay is a PMTiles archive, so MapLibre
  reads the region-in-view straight from its hosted URL via HTTP range requests (only the visible tiles, a few KB),
  and footprints appear as you pan - verified device-side against downtown + suburban Reno streamed from
  `nevada.pmtiles`. Downloading a map area still saves that region's **building overlay** for **offline** use
  (renders from the local file with no signal); the overlay is Microsoft building footprints,
  baked off-device into a per-region `.pmtiles` archive by CI (`scripts/build-overlay-region.sh` → tippecanoe
  `-l building -Z14 -z16`, published to the `building-overlays` GitHub release + a signed-shape manifest,
  matrix workflow `.github/workflows/building-overlays.yml`). **World catalog (`tools/overlay-regions.json`, 361 rows, ~250 base
  regions):** 51 US states + DC (Microsoft US Building Footprints, one `.geojson.zip` each) **plus ~185 world
  countries** (Microsoft Global ML Building Footprints, quadkey GeoJSONL from `global-buildings/dataset-links.csv`)
 - one build script, two sources, chosen per catalog row. **Big countries (>1500 MB, incl. India/Brazil/Russia/
  Germany/Japan/…18 of them) are split into sub-national CHUNKS by quadkey prefix** (India → 24 pieces), each with
  its own bbox so the app's smallest-covering-box rule downloads just the piece covering you - keeping every file
  under GitHub's 2 GB limit and downloadable in reasonable sizes (361 total regions, dispatched by `group` since
  that's over GitHub's 256-job matrix cap). The app's `OverlayTileStore` (a single-file
  sibling of `RoutingGraphStore`) downloads it into `filesDir/overlays/<id>.pmtiles`; `VelaMapView` adds a
  `pmtiles://file://…` `VectorSource` + a `FillLayer` **beneath** the OSM `building` layer (themed to the same
  fill/outline as OSM), so footprints only fill the **gaps** where OSM is thin - a suburb the Microsoft→OSM
  import never reached. Same location-aware "smallest covering box" rule as
  routing; best-effort + silent (a background enhancement). **Fixed en route:** the 197 MB download was
  silently aborting at the shared OkHttp client's 12 s `callTimeout` (a scrape bound) → `OverlayTileStore` **and**
  `RoutingGraphStore` now use a derived `callTimeout(0)` download client (the same fix voice models already had).
- ✅ **Open house-number overlay (OpenAddresses - 2026-07-05, device-verified).** The Microsoft footprints have
  geometry but no addresses, so house numbers come from a **second streamed overlay**: **OpenAddresses** address
  POINTS (per-source open/government licences) baked into a per-state `.pmtiles` and rendered as a `SymbolLayer`
  of the `number` field ON TOP of the footprints, matched to the basemap `vela-housenumber` style
  (Noto Sans, grey + white halo, minZoom 17.5 so numbers appear only at street level, matching the basemap layer, collision thins dense
  blocks). Streams online exactly like the building overlay (`pmtiles://https://…`, HTTP range requests - no
  download). **Device-verified: real house numbers in an OSM-thin suburb render over the
  footprints** - filling the exact gap where OSM has no `addr:housenumber`. WA hosted; a CI pipeline
  (`scripts/build-address-region.sh`, `tools/address-regions.json`) fans out the 42 US states with an
  OpenAddresses statewide source, same pattern as the building overlay.
- ✅ Offline routing - on-device **GraphHopper** CH graphs (135-region world catalog), the heavy native lift, DONE 2026-06-30
- ⬜ Region downloads as portable PMTiles + historical traffic

## Platform & distribution
- ✅ **Project website (2026-07-15).** A single-page showcase at
  https://pimpinpumpkin.github.io/Vela/ - hero with a live nav mockup, feature grid, the
  privacy pitch, a screenshot strip and download paths (direct APK / Obtainium / build it).
  Lives in `site/` (self-contained HTML/CSS/JS, no external requests, screenshots are the
  public Davis set as optimized webp). It deploys through the SAME Pages artifact as the
  F-Droid repo and the map fonts (`fdroid-repo.yml` copies `site/` to the artifact root) - a
  separate Pages workflow would wipe `/repo` and `/fonts`, so don't add one. Site-only pushes
  skip CI (paths-ignore) and trigger the F-Droid workflow directly instead.
- ✅ **In-app updater (2026-07-08, user request).** The PipePipe pattern: Vela checks the newest GitHub
  release (about once a day on launch, or on demand from Settings → Version → Check for updates), and when
  the release is newer than the running build a card on the map offers it. Update downloads the APK with a
  progress bar and hands it to Android's normal package installer, which verifies it is the same app signed
  with the same key before anything installs - the updater can never sideload something the platform would
  not accept as an update. "Not now" silences that version until a newer one appears. The launch check is a
  Settings toggle (on by default); Obtainium users can turn it off or just keep using Obtainium, both work.
  All localized.
- ✅ No Google Play Services anywhere
- ✅ Material 3 Compose UI; Hilt DI; R8 release builds
- ✅ Public GitHub repo + local mirror + offline bundle
- ✅ CI (GitHub Actions): every push to main builds + tests + signs the APK and publishes a **nightly prerelease** (`v0.4.<run>`, versionCode `2000+run`); a **weekly job promotes the newest nightly to the stable release** (same APK, no rebuild). Obtainium tracks stable with zero config; nightly users flip on "include prereleases". The in-app updater follows stable
- ✅ **Downloads survive the background** (issue #212) - voice models, dictation engines, region graphs, place packs, building overlays, offline place data and the update APK all run on an app-lifetime scope with a refcounted `dataSync` foreground service (a quiet "Downloading X" notification) holding the process alive, so switching apps or swiping Vela from recents no longer kills an in-flight download (OEM background killers were reaping the process seconds after a Home press; downloads also used to die with the ViewModel). `app/download/DownloadService` + `MapViewModel.downloadLaunch`
- ✅ **Opt-in diagnostics / debug export** (Settings → Diagnostics, **off by default**) - a local-only event log (searches, computed routes, parser "drift", nav start/reroute/arrival) that the user can **Export debug session** to a JSON bundle and hand to a developer via the system share sheet. **Never auto-uploaded** - user-initiated and user-routed; turning it off wipes the log; in-memory only (capped at 300 events). The no-backend half of the telemetry plan; `core/diag/DiagLog` + `app/diag/DiagExporter`, consent dialog on enable, `PRIVACY.md` updated
- ✅ **Crash capture** - an uncaught-exception handler (`app/diag/CrashCatcher`, installed in `VelaApp`) **persists the stack trace + breadcrumbs + app/device versions to disk**, surviving the restart, so after a crash the user can **Export crash report** from Settings → Diagnostics (the fix for "nav crashed but the phone wasn't tethered, no logcat"). Captured even with diagnostics off (a stack trace is benign + local); never auto-sent; chains to the system handler so normal crash behaviour is unchanged
- ✅ **Trip recording + replay** (Settings → "Save my trips", **off by default, separate opt-in** - more invasive than diagnostics since it's your exact routes; never uploaded) - records each navigation's GPS trace to a local file (`app/replay/TripStore`), so a drive can be **replayed on the map at 3×** to test turn-by-turn **without driving it again** (`LocationProvider.replay` feeds the recorded fixes through the same nav/camera/dot pipeline). A replay shows a **"Stop replay"** button on the map and, when it finishes (or is stopped), **live GPS resumes automatically** - earlier the live feed never came back until the app was restarted. The trip is **saved the instant you arrive**, not only when you tap "Done", so it survives if you leave the arrival card. Recorded trips are listed in Settings (newest first) with their **recorded date + point count** and **Replay / Share / Delete**; the list refreshes on entry and shows an empty-state hint while recording is on but nothing's captured yet. **Share** exports the raw CSV trace via the system sheet (same FileProvider as the diag/saved-places export) - so a drive can be pulled off a **release** build and handed over for replay/debug **without a dev build** (this is how the 2026-06-20 early-arrival bug was diagnosed). *(Bigger picture - opt-in **encrypted** upload of traces for remote debugging is the natural next step as the tester pool grows; see ROADMAP's opt-in-telemetry big bet. Location traces are the most sensitive data the app touches, so: explicit per-share consent, client-side encryption to a key only the dev holds, minimal/redactable payload, self-hosted or pre-signed endpoint, auto-expiry.)* Both opt-ins now live only in Settings → Diagnostics (the first-run prompt that offered them was **removed** in the 2026-07-10 onboarding declutter; the diagnostics ask instead surfaces in context on the crash-report card). Replay now **auto-routes to the trip's destination** and starts turn-by-turn for you (best-effort - the trace still plays if routing fails - and the auto-started nav is torn down when the replay ends), so you no longer have to start nav manually first. *(Pending on-device verification.)*
- ✅ **Simulate driving (demo mode)** (Settings → Navigation → "Simulate driving (demo)", **off by default**) - tapping **Start** on any planned route drives it as a **synthetic GPS trace** instead of using the real fix, so **navigation runs anywhere** (a Davis route while the phone sits in another state) - for demos, screenshots and testing turn-by-turn without leaving the couch. It reuses the recorded-trip **replay pipeline wholesale**: `DemoTrace.fromRoute` (pure `:core`) walks the route polyline at a constant cruise speed emitting one clean `ReplayFix`/sec (real bearing + speed + monotonic time), and `LocationProvider.replay` feeds those through the **exact** live-nav loop (hermetic `NavSession.replayMode`, puck physics, follow-camera, spoken + haptic guidance, speed-limit badge). Unlike a recorded trace it's meant to **look like real nav** - no "Stop replay" pill; the normal **End** button stops it (`stopNav` cancels the demo job, which tears the session down and resumes live GPS). This is how the `05-navigation` screenshot was shot. **Turn it off to navigate for real.**
- ✅ **Simulate my location (demo mode)** (Settings → Navigation → "Simulate my location (demo)", **off by default**) - a sibling of simulate-driving for the *browse* map: flip it on and Vela pretends you're standing at the current map centre, so the location dot, the directions origin ("Your location"), and recenter all read from there instead of your real GPS. Lets the app be shown or photographed from anywhere without leaking a real position (`ui/SimLocation.kt`, a process-wide reactive holder persisted to `vela_settings`; `MapViewModel` pins `myLocation` to the captured point and suspends the live GPS collector, resuming it when you turn the toggle back off). It's how the Davis/Sacramento screenshots were taken from another state. **Turn it off to use real GPS.**
- ✅ Settings shows the installed app version (name + build code)
- ✅ **Full D-pad / no-touchscreen operation** (touch is a bonus, not required) - every surface reachable and activatable by focus traversal with a visible focus ring; the map itself is key-drivable (arrows pan, OK "taps" a centre crosshair, hold-OK long-presses/drops a pin, on-screen +/− zoom buttons); key alternatives for every gesture (banner step preview ←/→, sheet-handle OK-toggle, photo-viewer paging); the search overlay's focus traps fixed. A full-function sweep (2026-07-07) exercised every surface end-to-end by D-pad and closed the last gaps: text fields escape UP/DOWN via `dpadFieldEscape` (Settings + reviews search), the search field's DOWN drops into the suggestions, Choose-on-map keeps the map pannable to place the pin, and the directions panel scroll-caps so **Start** is reachable with 4 alternates (the last also fixes a touch layout bug). **Every screen/sheet/panel auto-focuses a sensible element on open (`rememberDpadAutoFocus`), so no keypress is wasted "waking up" focus** - and because a Compose `DropdownMenu`/`AlertDialog` can't be pre-focused (framework limit, ~10 approaches proven), menus and dialogs were rebuilt as **`VelaMenu`** (anchored DropdownMenu under touch, auto-focusing raw-Dialog chooser under D-pad) and **`VelaDialog`** (auto-focusing raw-Dialog), so those land focused too. Affordances appear only in key-driven input mode (`rememberDpadMode`), so touch UX is unchanged. Design/findings/merge policy: [`docs/dpad.md`](docs/dpad.md)
- 🟡 F-Droid: Vela's OWN repo is live (see FDROID.md - add it to any F-Droid client); official f-droid.org inclusion + reproducible build still open
- ⬜ UnifiedPush for delay alerts (no FCM)
- ⬜ ACRA / self-hosted crash reporting

## Resilience / maintainability
- ✅ **Remotely-updatable scraper calibration** - `calibration.json` at the repo
  root holds the `pb` templates, endpoint URLs **and (phase 2) the search parser's
  positional field-index paths** (`name`, `address`, `rating`, `photos`, … as
  `[i,j,…]` arrays). The app fetches it at launch and adopts a newer `version`
  (host-allowlisted to google.com) **without an app update** - so most Google
  drift (a moved `pb`, endpoint, or field index) is now a one-line edit + version
  bump, not a release.
- ✅ **Signed update channel** - the bundle is **ECDSA-P256/SHA-256 signed**
  (`calibration.json.sig`); the app verifies it against a **pinned public key**
  before adopting, so a repo/CDN compromise can't push config - or code - to
  devices (private key kept out of the repo; `scripts/sign-calibration.sh` re-signs;
  `BundleSignature.verify` is unit-tested). *(verified on-device)*
- ✅ **Pushed notices** - a `notices` array in the signed bundle surfaces dismissable
  alerts on the bare map ("search is down, fix coming") with **no app update**;
  dismissals persist per-id. *(verified on-device end-to-end)*
- ✅ **Remote parse logic** (phase 3) - a signed `transformsJs` bundle runs in a **Rhino
  sandbox** (interpreted, no Java access), so a *response-shape* change can be hot-fixed
  too - not just a moved field. Two search hooks (`parseSearch` full re-parse /
  `transformPlaces` post-process) over a flat place-JSON contract; **compiled Kotlin is
  always the fallback**. *(verified on-device: a pushed transform marked the first
  result, then cleared; engine + sandbox + contract unit-tested)*

## Known calibration debts (the NewPipe lifestyle)
- Google request/response shapes are pinned to a 2026-06-15 capture; expect
  periodic re-calibration (paths documented in the README). Pb/endpoint drift is
  now a remote `calibration.json` fix (above); **field-index paths are remote too** (phase 2, the `paths` object) - so index drift is also just an edit + version bump, no build.
- EU/EEA consent wall: pre-seeds Google's `SOCS`/`CONSENT` cookies in the shared
  jar so a cookieless session isn't bounced to `consent.google.com` (best-effort,
  US-verified only; the full form-POST handshake is the follow-up if it persists).

## Added 2026-07-11 (sheet-polish round)

- Destination side on arrival: the approach banner and the spoken arrival say "Your
  destination is on the left/right" when the router knows it (OSRM arrive modifier), in
  all supported languages.
- Sticky travel mode: the last-used mode is the default for the next directions session
  (parked-car routing still forces Walk).
- Zoomed-out searches cover the visible viewport instead of a fixed ~25 km window.
- Results-sheet filters drop the matching map pins, not just the list rows.
- Native rating histogram on the Reviews tab, scraped in passing by the photo walk.
- Menu photo tiles carry their upload date (RPC dates joined onto the categorised walk).
- The route chooser drags from anywhere with inertia; travel-time picks are Material 3
  dialogs that refuse past times; search-along-route chips are filled action chips.
- Save is a bookmark icon; sheet headers share one circled-button language (place sheet,
  directions close, results chevron and close, recent-search remove).

- ✅ **Hebrew (עברית): the 15th language and first RTL locale (2026-07-09/11, contributed by
  The-Young-boy; landed 2026-07-12 alongside the Chinese/Japanese work).** All three i18n layers
  cover Hebrew: the ~531 UI strings (in `res/values-iw/strings.xml` - `iw` is AAPT's legacy Hebrew
  resource qualifier - every format-placeholder validated against English), the generated spoken nav
  voice (`HeNavStrings` in `:core`, masculine-singular Waze/Google-Maps register: "פנה ימינה",
  "בעוד 300 מטר", feminine roundabout-exit ordinals "ביציאה השלישית", "היעד שלך מצד שמאל/ימין"), and
  the Google POI scrape (`hl` follows the locale; open/closed keyword table keyed under both `iw` and
  `he`). Registered under **`he`** in the picker/NavStrings: on JDK 17+ (`useOldISOCodes=false`) the
  resolved code is `he`, the resources live in the legacy `values-iw` folder (the platform maps a
  `he` locale onto it), and `NavStrings.forLanguage` accepts both `he` and `iw` (Android hands back
  the old code on-device). RTL is automatic: the app already declares `android:supportsRtl` and
  re-creates the Activity with a Hebrew config, so Compose's `LayoutDirection` flips (a whole-app scan
  found no hardcoded left/right, `Absolute` arrangements or forced `LayoutDirection`). Unit-tested.
- ✅ **Community translations via Weblate (2026-07-14).** UI-string translation moved to hosted
  Weblate so anyone can translate or fix strings in a web editor, no git required - see
  [docs/TRANSLATING.md](docs/TRANSLATING.md) for the project link, the rules (placeholders, CLDR
  plural categories, no em dashes) and the maintainer component config. New strings are added to
  the English base only; Weblate opens PRs to fill the locales, and untranslated strings fall
  back to English in the meantime.

## Added 2026-07-17 (offline routing on pre-Android-14 devices)

- ✅ **Downloaded routing graphs now load on Android below 14 (API 34).** Three pre-API-34 gaps in
  the GraphHopper offline engine meant a downloaded graph loaded on API 34+ only, and silently
  failed everywhere below (never caught because the `:ghprobe` test device was on Android 14):
  the custom model is now built programmatically instead of via the jar's Jackson record probe
  (`Class.getRecordComponents` is API 34+), profiles are set after `init()` to skip a second
  Jackson round-trip, and a build-time ASM transform rewrites `MMapDataAccess`'s JDK-13
  absolute-bulk `ByteBuffer` calls to an API-1 shim. Offline routing now works down to minSdk 26.
  Fix contributed by ars18 (vela-dpad fork); a unit test guards the hand-built model against
  GraphHopper-upgrade drift.

## Added 2026-07-16 (community QOL batch, issues #169 #170 #171 #172 #173)

- ✅ **Edit the destination from the route picker (issue #170).** Both endpoint rows on the
  directions top card are editable now: the your-location end keeps the origin picker, and
  tapping the place end opens the same search overlay to swap the destination in place,
  keeping the custom origin, stops and travel mode (backing out used to lose the other end).
  "Choose on map" works for the destination too, with its own crosshair labels.

- ✅ **Read + copy a full business name (issue #169).** A very long place name (CJK businesses
  especially) clips at two lines in the sheet header; tapping the name now toggles the full
  name, long-pressing copies it to the clipboard, and the share menu carries a "Copy name"
  item (also the key-only path on D-pad phones, where the name is its own focus stop).
- ✅ **Saved places show on the map while browsing (issue #171).** Every list place and
  quick-save draws a small ringed disc in its list's colour with the list's icon (or emoji)
  on the browse map; tapping one opens the place. Hidden while search results, navigation,
  a replay or Street View own the map. Sparse deliberate objects, so they always render
  (no collision fade).
- ✅ **Settings search (issue #172).** A magnifier in the Settings top bar opens a floating
  search field; every section title and row label self-registers its position as it lays
  out, so matches are complete with no hand-kept keyword table, and picking one scrolls
  straight to the row. D-pad: the field auto-focuses, DOWN escapes into the results, BACK
  closes the panel first.
- ✅ **Custom emoji icons on lists (issue #173).** The list editor's icon row grows an emoji
  tile: a curated picker grid (works on key-only phones) plus a free-type field for any
  emoji. Stored in the existing icon field as "emoji:X", so old payloads and old builds
  fall back to the bookmark; the emoji renders in list rows and as the saved-place map pin.
- ✅ **Hebrew open/closed status fix (issue #95 diag).** Google prefixes Hebrew status strings
  with "המקום" ("the place"), so the bare closed/open words never matched at the start of the
  string and every Hebrew place drew no status colour at all. The keyword tables now carry the
  prefixed forms, pinned by tests against the exact strings from a live device diag.
- ✅ **Remote keyword tables actually wired.** The signed calibration bundle's word-table
  overrides (status open/closed words, transit gate + exclusion words, departure-board
  indices) were parsed nowhere: the fields existed and the app pushed them into the parsers,
  but the bundle parser silently dropped them, so every one of those overrides was dead.
  They now parse leniently like the tuning dials (bad entries skipped, empty means absent).
- ✅ **No-GPS search bias guard.** A device that never gets a location fix (WiFi tablet) sits
  on MapLibre's virgin camera near 0,0 and every search was biased to open ocean. A bias
  point within about 50 km of null island is now discarded so regional ranking wins instead.
- ✅ **Full review text in the inline list (issue #181).** Long reviews rendered with a data-side
  "…" because a card is often harvested on the same tick its More toggle is clicked, before
  Google's async re-render swaps in the full body, and the accumulator kept the first capture
  forever. A longer text for a known review now replaces the stored entry, and the More click
  uses the button's class hook so it works in every UI language (the old label match only knew
  English). Device-verified on a busy coffee shop: multi-paragraph reviews end in real sentences.
- ✅ **Foreign street names are spoken, not skipped (issue #184).** When guidance is in one language
  but a road name is in another script (Hebrew "רחוב הרצל" while you drive with the English voice),
  the name used to vanish, because a single-language voice has no phonemes for those glyphs and
  drops them. The spoken string now romanizes foreign-script name runs into the voice's alphabet
  (ICU, built into Android), the way Google reads "onto Rehov Herzl", while the on-screen banner
  keeps the real local-script name that matches the street sign. It only touches the runs the voice
  can't say (existing Latin text and its accents are left alone) and only for Latin-script voices (a
  Hebrew or Russian voice reads its own script natively). CJK is deliberately left to the native
  Japanese/Chinese voices, since ICU mis-reads kanji as Chinese pinyin; a proper kanji-to-romaji
  step is a possible follow-up.
- ✅ **No stale voice-prompt burst when a voice attaches late.** If you drove with no voice
  installed (nav queues prompts with nothing to speak them) and then installed one, the whole
  backlog used to flush at once, a burst of out-of-order directions. The queue now speaks only
  the most recent line on attach and is cleared whenever guidance stops, so installing a voice
  can't trigger a stale replay.
- ✅ **Install the Vela voice straight from Voice settings.** When no Vela voice is installed, the
  one-tap install button now sits in the Voice settings section itself, not only inside the Voice
  library, so you don't have to dig for it.
- ✅ **Search your own history and lists as you type (issue #180).** As you type, matches from
  your recent searches, recently-viewed places, and saved lists surface at the top of the
  suggestions, above Google's, each with an icon that tells them apart (clock for a past search,
  pin for a place you opened, bookmark for a saved-list place). It is computed on-device, so it
  is instant and the only thing that shows when you are offline. A network suggestion that
  duplicates one of your own is dropped (matched by name and location, since saved places carry
  no Google id). Tapping a place opens it; tapping a past search re-runs it. Press-and-hold any
  suggestion (or tap its ⋮) to save a place into one of your lists or drop a history row, the same
  list picker the place sheet uses. Looking up one location out of a chain no longer means
  re-typing the city.