Decoded Z27AG signals: layouts in signals.json can blocks, the only source

engine_rpm moves to source z27ag (no OBD-II on this car's CAN). Ten more:
accelerator, brake, handbrake, indicators, side lights, dipped beam, doors,
A/C compressor. Guideline 6: no service writes a CAN ID of its own.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DDwfd6Ki8UfG4hK6W5YpJz

README.md

@@ -17,11 +17,14 @@ definitions from here.
 |---|---|
 | [`schema/topics.json`](schema/topics.json) | Topic namespace: payload kind, retention, rate, publisher |
 | [`schema/envelope.json`](schema/envelope.json) | JSON Schema for the decoded-signal envelope |
-| [`schema/signals.json`](schema/signals.json) | Signal registry — the single source for name, unit, type and range |
+| [`schema/signals.json`](schema/signals.json) | Signal registry — the single source for name, unit, type and range, and for where each decoded Z27AG signal sits in its CAN frame (`can` block) |
 | [`docs/BOUNDARY.md`](docs/BOUNDARY.md) | Display boundary protocol: what crosses between `svc-gw` and the app |
 | [`checklists/`](checklists/) | Recording checklists as data; the app bundles exact copies (its **Captures** page) |
 
-The Z27AG DBC lands here too, once Phase 2 produces one.
+Decoded Z27AG signals (source `z27ag`) carry their frame layout in `signals.json` itself,
+so name, unit and bits cannot drift apart. A DBC for tools like SavvyCAN or cantools,
+if one is wanted, is generated from it, never edited by hand. Findings behind each
+layout: [`docs/impl/reports/`](docs/impl/reports/).
 
 - For implementation practice guidelines, refer to the [guidelines](docs/GUIDELINES.md);  
 - For implementation plans and history, refer to [them](docs/impl/);