Files
contracts/docs/impl/plans/INITIAL.md
T
mikkeli b55ccba268 Define display boundary protocol v0
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
2026-10-09 20:19:05 +09:00

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

  1. 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.
  2. gnss/fix schema, driven by what tool-mock replays.
  3. 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