---
type: plan
status: active
updated: 2026-09-04
---
# Initial plan

## What actually needs building

| Need | Answer | Ours? |
|---|---|---|
| A CAN bus that isn't a car | `vcan` — kernel module, no bitrate to configure | No |
| Replay real captures | `canplayer`, with frame mapping so a log recorded on `can1` plays onto `vcan0` | No |
| Traffic before any capture exists | **ICSim** — simulated cluster with speed, doors, indicators | No |
| GNSS fix | GPX or synthetic track → `yukart/gnss/fix` | **Yes**, small |
| Local broker | a mosquitto config for the workstation | Trivial |
| App boundary peer | only if the full stack proves too heavy for Flutter iteration | **Deferred** |

Two of the three fixtures are configuration, not code.

## Why ICSim matters more than it looks

Phase 2 is the hard part of this project: correlating observed frames against a
written event log to work out what the Z27AG is saying. ICSim is built for exactly
that exercise — a simulated cluster with controllable speed, doors and indicators,
and four noise levels where level 0 is clean packets and level 3 randomises
arbitration IDs and byte positions.

So the whole decode workflow can be practised, and the decoder written and tested,
before a single real capture exists. That is worth doing while the PCBs are
unassembled.

## Order

1. `vcan` bring-up script — everything else needs a bus.
2. ICSim, vendored or documented, driving `vcan0`.
3. GNSS fixture publishing `yukart/gnss/fix`.
4. Local mosquitto config, and a single entry point that brings the whole fake car up.
5. `canplayer` wrappers — only useful once Phase 1 has produced real captures.