Roadmap
Eight phases over about ten weeks of mostly solo work. A usable platform exists from phases 3–4. Weeks are relative to the start.
| Week | Phase | Status |
|---|---|---|
| 1 | 1. Foundations, CI/CD, Kubernetes | In progress: repos, CI, images, manifests done |
| 2–3 | 2. JT/T 808 engine | Codec, ingest and simulator done; real V53 pending |
| 4 | 3. GPS storage and processing | Schema and domain rules done; persistence pending |
| 5 | 4. API and real time | Skeleton only |
| 6 | 5. Dashboard | Status page only |
| 7 | 6. Geofences and alerts | Not started |
| 8 | 7. Remote V53 control | Command texts and lifecycle modelled; downlink routing works |
| 9–10 | 8. Reliability, security, production | Not started |
1. Foundations and Kubernetes deployment (critical)
Repositories, Cargo workspace, multi-stage Docker images, namespace phimi, Secrets
for PostgreSQL, the device auth secret and configuration, PostGIS, GitHub Actions,
HTTPS for the UI, a separate public TCP endpoint, readiness/liveness probes and
Prometheus metrics.
Validation: a commit builds, tests and deploys to the development environment.
2. JT/T 808 engine in Rust (critical)
Framing, codec, messages, sessions, registration/authentication, locations (GPS, Wi-Fi, LBS, batches), heartbeats, downlink commands, ACK correlation, simulator. BCD ids, partial and concatenated TCP frames, length checks, duplicates, size limits, device authentication and keeping unknown packets.
Validation: passes tests built from the vendor hex dumps (done) and accepts registration, authentication and positions from a real V53.
3. GPS storage and processing (critical)
Store every position with tracker time and server time. Distinguish GPS, Wi-Fi and LBS; reject impossible coordinates; deduplicate retransmissions without losing real observations; never let an old point replace the latest; record battery, signal and source; archive raw frames in MongoDB when needed; compute distance and duration with GPS noise filtered.
Validation: a received position is stored, queryable and correctly dated; an identical retransmission creates no duplicate.
4. Rust API and real time
Axum + SQLx, WebSocket for new positions, user authentication independent of device identity, per-tracker access, paginated history and request limits.
Validation: a Next.js client gets latest positions and history and receives updates without reloading.
5. Next.js dashboard
MapLibre map, a colour and marker per cat, last position and report time, GPS status, battery, network and mode, date navigation and trip replay, tracker details, handling of stale data and lost connections. A PWA is enough at first.
Validation: all four cats display correctly and new positions appear live.
6. Geofences and notifications
Circular or polygonal zones (home, garden, watched zones). Events zone_enter,
zone_exit, battery_low, device_offline, gps_unavailable. Delay, minimum accuracy
and hysteresis so a single slightly-outside point does not raise an alert.
Validation: crossing and signal-loss scenarios produce the expected alerts without repeats.
7. Remote V53 control
Command queue with queued, sent, acknowledged, succeeded, failed, timed_out.
Profiles Normal, Economy, Find My Cat, Emergency and Night, once the commands and their
battery cost are validated on hardware.
Validation: a command from the dashboard changes the tracker's behaviour, with a confirmed result.
8. Reliability, security and production
Network loss, tracker reboot, pod redeploy, retransmission, recovery and command expiry tests. Prometheus/Grafana dashboards, PostgreSQL backups tested by restore, GPS retention, and logging that never exposes coordinates or SIM identifiers.
Validation: four trackers run for several days in real conditions with correct reconnections, consistent data and no systematic history loss.