Scaffold repo: docs layout, guidelines and initial plan

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_013kj58Jugkic783b8ZrtTVZ
2026-09-03 18:48:32 +09:00
commit 570a8c541d
4 changed files with 71 additions and 0 deletions
@@ -0,0 +1,32 @@
+---
+type: default
+---
+# Initial plan
+
+## Scope
+
+Turn a GNSS fix plus a destination into guidance on the bus. Nothing about
+rendering — that belongs to the display client.
+
+## Order
+
+1. Confirm Valhalla builds and runs on the Jetson (arm64). This is the one real
+   integration risk in the whole navigation workstream — upstream's arm64
+   container story is unsettled. Do it before anything else.
+2. Stand up Valhalla against artifacts from `tool-mapmint`, serving HTTP locally.
+3. Define the routing provider interface, with Valhalla as the first implementation.
+4. Bridge: subscribe to `yukart/gnss/fix`, publish `yukart/nav/guidance`.
+5. Meili map matching over recorded sessions — see below.
+
+## Why map matching comes early
+
+Meili's `trace_attributes` snaps a recorded GNSS trace onto OSM and returns road
+attribution along it: speed limit, road class, geometry. That is ground truth for
+validating reverse-engineered CAN signals, which is otherwise guesswork. It is
+worth having before any navigation UI exists.
+
+## Blocked on
+
+Live guidance needs a GNSS fix, which needs gpsd, which needs the SIM7600 brought
+up in [orin-nano-env-setup](gitea:yukart/orin-nano-env-setup). Everything else here
+can be built and validated against a replayed trace.