What crosses between svc-gw and the app: hello, heartbeats both ways, state snapshots of envelopes with mock flagged per message, and commands carrying an idempotency key. TTS utterances are left for when a TTS exists. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01DDwfd6Ki8UfG4hK6W5YpJz
1.5 KiB
type, status, updated
| type | status | updated |
|---|---|---|
| plan | active | 2026-10-09 |
Initial plan
What is defined
The envelope, the topic namespace, and the standard OBD-II signals — the ones whose names, units and ranges are fixed by the standard rather than by the car.
What is not
Z27AG-specific signals. They do not exist until Phase 2 identifies them from
observed traffic. They arrive as DBC entries plus registry rows with
source: "z27ag", one at a time as each is confirmed.
Composite payload shapes. gnss/fix, nav/guidance, nav/route and
system/<service> have their fields named in topics.json but no JSON Schema
yet. They get one when a publisher exists to constrain.
The app ↔ svc-gw boundary protocol is at v0 in BOUNDARY.md:
heartbeat both ways, idempotency key on every command, mock flagged per message.
Still missing from it: the TTS utterance shape (id, chunk sequence, terminator,
expiry), defined when a TTS exists to send one.
Order
- Schema validation available to all three languages — the Rust services, the Python fixtures and the Dart client must reject a malformed message identically, or the contract is decorative.
gnss/fixschema, driven by whattool-mockreplays.- Z27AG signals, as Phase 2 confirms them.
Consumers
| Repo | Reads |
|---|---|
svc-core |
signals, envelope, DBC |
svc-gw |
topics, envelope |
svc-nav |
topics, envelope |
app-flutter |
topics, envelope, signals (for display units) |
tool-mock |
all of it — fixtures publish the real schema |