Live Transit Detroit · Installment 02 · October 2026
Build Notes: October 6 Promotion
Published October 6, 2026 · By Justin Spencer Smith
Nine changes moved from staging to the production Live Transit page today, in two promotions (v20261006-1815 and v20261006-2120). Every change passed a 16-check staging UAT and a two-level production UAT before serving. Two defects found during UAT were fixed before promotion. This is the record.
What shipped
| Change | What it does |
|---|---|
| Marker redesign | Bus pillars 620m → 220m; glow, core, beacon, and ground ring rescaled to match. Pillars no longer tower over the downtown buildings they stand beside. |
| DisplayBounds | Measures viewport, device class, edge insets, and on-screen chrome per frame; exposes the safe frame every camera move must respect. Debug readout at ?dbdebug=1, hostname-gated to staging. |
| TransitionEngine | Central camera-transition controller. Bus selection glides to a 32° vantage at the safe-frame center; pointer input cancels immediately; cancelled transitions never engage follow. Mobile gets a compact bus bar, frame-and-hold, and an explicit Follow toggle; desktop auto-follows on natural completion. |
| Minimum-jerk easing | Camera tweens now use the quintic t³(6t²−15t+10) profile — zero velocity and acceleration at both endpoints — replacing ease-in-out cubic. |
| Badge decluttering | Greedy screen-space placement for route badges; selected bus prioritized, stable slot order, spiral candidate search. Clustered badges stay individually legible. |
| Kalman motion + halos | Per-bus Kalman filter (arc position, velocity, covariance; 15m GPS sigma) replaces raw dead reckoning. Uncertainty renders as a soft disc of radius 3σ, clamped 15–150m, opacity 0.16. |
| Stop camera intent | Selecting a stop glides the camera to a 700m, 32° stop vantage with no follow. Previously the card opened and the camera stayed put. |
| Depth-ordered tap picking | One raycast across bus and stop meshes; the frontmost marker wins. Previously buses were tested first and always won, so a stop standing in front of a bus pillar could not be selected. Found from an on-device report, fixed same day. |
| Landmark massing (Phase A) | True-form OSM building massing for downtown Detroit — 6,981 vertices, 6,753 triangles, one merged draw call, 272KB. High fidelity reserved for close zoom; progressive detail is Phase B. |
Verification
Staging UAT (16 checks, automated browser, read-only): 14 passed. One failure — stop selection never moved the camera — root-caused to an unmigrated Phase 2 intent and fixed before promotion. Mobile checks could not run (no viewport emulation in the test harness).
Production UAT, Level 1 (smoke): 6/6 passed — clean load, correct stamp, 72 live buses, landmarks serving, no errors, feed live. It also caught a stale hardcoded build string in the help footer, fixed in a follow-up commit.
Production UAT, Level 2 (interactive): bus selection, glide, follow, card close, badge legibility, and stop glide all passed. Depth-ordered picking and the trip planner received partial verification; mobile remains untested in automation.
Every deploy was verified by served bytes, not by workflow success: the HTML stamp, the JS feature markers, and the landmarks payload were each fetched from the live URL and confirmed.
Also fixed today
- Telemetry pipeline race. The 5-minute logger and the timing-model builder both write
data/timing/segments.json; a logger commit landing mid-build broke the builder's rebase. The commit step is now conflict-proof: on rebase conflict it aborts, rebuilds on the new tip (watermark-idempotent), and retries the push. - Stop label stacking. Production screenshots showed stop name labels piling into unreadable stacks at street zoom. The greedy screen-space collision used for street labels now applies to stop labels.
- Build string drift. The help footer carried a hardcoded build number that went stale for days. It now derives from the cache stamp at load.
Open items
- Mobile verification (compact bar, frame-and-hold, Follow toggle) has no automated path; on-device testing is the only coverage.
- Landmark Phase B (progressive LOD) is designed, not implemented.
- SMART live feed remains blocked on the Swiftly API key.
