Decoded Z27AG signals: layouts in signals.json can blocks, the only source
/ crosscheck (push) Successful in 1s
Rust consumers (L4T) / Clippy, test, build, glibc for every service that compiles contracts in (push) Failing after 6s

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
This commit is contained in:
2026-10-13 21:31:51 +09:00
parent 77d6b79c6b
commit 34140cc666
3 changed files with 163 additions and 6 deletions
+11 -1
View File
@@ -33,4 +33,14 @@ type: guidelines
- There is no version in any topic or payload. A recorded session names the
contracts tag it was captured under, which is what keeps old captures readable.
## 6. To be added
## 6. A decoded signal's layout lives only in its registry entry
- Every `source: z27ag` signal has a `can` block in `signals.json`: frame ID, byte,
bit or length, byte order, scale and offset. The decoder reads those blocks and
nothing else, so a correction lands in one file and every consumer sees it.
- ⚠ **No CAN ID or bit position is written in any service's code.** A layout
hard-coded downstream is a second source that silently disagrees the day the
registry is corrected.
- Each block names the report with its evidence (`evidence`). A layout without
evidence is a guess and does not go in.
## 7. To be added