trm/docs
3
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

log: Phase 3 plan + tasks 3.1 / 3.2 / 3.5 landed on dev

Browse Source
This commit is contained in:
Julian Çuni
2026-05-04 17:52:05 +02:00
parent 0fcc6f179b
commit c6b8507ca6
1 changed files with 12 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
log.md
+12
View File
@@ -265,3 +265,15 @@ Resolves debt #4 from the previous entry — Phase 2 cold-load is verified end-t
3. Wire-format IMEI/UUID closure — Phase 2 backend question, not blocking dogfood.
4. ~~SPA Phase 2 cold-load lifecycle~~ — resolved today; pending push to `dev`.
5. **Phase 3 dogfood readiness** — error boundaries, mobile responsive baseline, per-device detail panel, operator-friendly empty/loading states. The next biggest fish for Rally Albania 2026-06-06.
## [2026-05-04] note | Phase 3 plan + tasks 3.1 / 3.2 / 3.5 landed on dev
Drafted `trm/spa/.planning/phase-3-dogfood-readiness/` task plan: eight per-task `.md` files numbered to match task IDs (01–08 ↔ 3.1–3.8). Path-1 execution order picked: 3.1 → 3.2 → 3.5 → 3.4 → 3.3 → 3.6 → 3.7 → 3.8 (reliability surface first, then operator polish, then mobile + tests, then observability, then brand).
**3.1 — error boundaries** (commit `c1410b0`). `<ErrorBoundary regionId>` class component + `error-bus` pub/sub + `<RegionFallback />` panel. Three boundaries wired: chrome (in `_authed/route.tsx`), route (in `__root.tsx`), map (in `monitor.tsx` wrapping just the layer + camera children). Notable deviation: spec sketched the map boundary inside `map-view.tsx` wrapping ALL children, but that would also wrap the floating controls (event picker, basemap switcher, connection chip), which violated the spec's own acceptance bullet. Moved into `monitor.tsx` to scope the boundary to layers + camera. `<MapView>` stays a clean positioning singleton with no opinion on what's protected. Verified via Playwright with a temporary throw-on-query helper.
**3.2 — connection-state UI escalations** (commit `8e830f0`). `<ConnectionBanner />` (top-of-map; muted at 5–30 s of outage, warning style ≥ 30 s or terminal `disconnected`) and `<DeviceListPanel />` (collapsible card; sorted last-seen-ascending). Connection store gains `outageStartedAt` set on `connected → !connected`, cleared on the inverse, and explicitly NOT set on cold-load `disconnected → connecting` so the banner only escalates for mid-session outages.
**3.5 — empty / loading state polish** (commit `bc7483f`). `<EmptyState />` + `<LoadingState />` primitives, `<MapStatusOverlay />` (soft "Connecting to live feed…" / "No devices reporting yet" cue layered over the map, hides itself once any positions arrive), `<DeviceListPanel />` distinct "Connecting…" disabled state, login submit-button spinner.
**Open issue surfaced during 3.2 smoke:** the device list panel renders 8-char device-id prefixes (e.g. "35042406") instead of IMEI labels because `useDevicesById()` doesn't find those IDs in Directus's `devices` table. The Redis stream's `deviceId` and Directus's `devices.id` are diverging — the IMEI/UUID closure debt (#3) surfacing in the SPA. Will block 3.4's vehicle / crew join until closed; flagged in `04-per-device-detail-panel.md`'s risks section.