From 358662de1bab3ffbbdc955f25dfc7b0be07260bd Mon Sep 17 00:00:00 2001 From: Mikkeli Date: Fri, 4 Sep 2026 07:59:27 +0900 Subject: [PATCH] Record self-mocking design: services mock themselves, no separate stubs Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_013kj58Jugkic783b8ZrtTVZ --- docs/GUIDELINES.md | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/docs/GUIDELINES.md b/docs/GUIDELINES.md index b5b8310..c9a92f4 100644 --- a/docs/GUIDELINES.md +++ b/docs/GUIDELINES.md @@ -9,12 +9,14 @@ type: default - A fixture that invents its own topic or shape is worse than no fixture: it defers the integration work instead of removing it. -## 2. Never stub our own services -- Stub the **car** and the **hardware**. Never stub `svc-gw`, `svc-nav` or anything - else we wrote. -- A stub of our own service is a second implementation of our own contract, and it - will drift from the first. Run the real service against fake inputs instead — - none of our services touch hardware, so they all run on x86 unmodified. +## 2. Do not reimplement our own services +- Stub the **car** and the **hardware**. Never write a *separate* implementation of + `svc-gw`, `svc-nav` or anything else we wrote — a second implementation of our own + contract will drift from the first. +- A service mocking **itself**, behind its own input interface, is the right shape: + one codebase, one contract implementation, a swappable data source. That belongs + in the service's own repo, not here. +- None of our services touch hardware, so they all run on x86 unmodified either way. ## 3. Prefer upstream tools, wrap rather than rewrite - `vcan`, `canplayer` and ICSim already solve the CAN problem. This repo holds the