yukart/svc-nav
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Record link shapes and boundary semantics in initial plan

Browse Source 
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013kj58Jugkic783b8ZrtTVZ
This commit is contained in:
Mikkeli Matlock
2026-09-03 20:28:32 +09:00
parent 570a8c541d
commit 1f47943e57
1 changed files with 19 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/impl/plans/INITIAL.md
+19
View File
@@ -30,3 +30,22 @@ worth having before any navigation UI exists.
Live guidance needs a GNSS fix, which needs gpsd, which needs the SIM7600 brought 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 up in [orin-nano-env-setup](gitea:yukart/orin-nano-env-setup). Everything else here
can be built and validated against a replayed trace. can be built and validated against a replayed trace.
## Links
| Link | Shape | Initiator |
|---|---|---|
| `yukart/gnss/fix` | subscribe | — |
| `yukart/nav/{guidance,route}` | publish, retained | — |
| Route requests | request/response, HTTP | `svc-gw` |
| Cloud routing API, if used | request/response | this service, outbound only |
`svc-nav` never talks to a display. Guidance reaches the app as bus state via
`svc-gw`, and route requests arrive proxied. Nav does not know displays exist.
## GNSS is scaffolding for now
The PCBs are not assembled, so there is no real fix yet. Positions come from a
replayed trace publishing `yukart/gnss/fix` with the **real schema** — see the
fixtures rule in [ARCHITECTURE.md](gitea:yukart/project-yukart). Everything
downstream is then identical when the hardware lands.