Record self-mocking design: services mock themselves, no separate stubs

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

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