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
2026-09-04 07:59:27 +09:00
parent d5c4da8e38
commit 4af8fcc37f
1 changed files with 24 additions and 0 deletions
@@ -55,3 +55,27 @@ to be a separate process, that becomes a refactor rather than a rewrite.
 | Downstream to app | simplex push stream, lossy-tolerant | app connects |
 | Upstream from app | simplex request/response, acknowledged | app |
 | Route requests onward | request/response, HTTP | this service |
+
+## Self-mocking
+
+The input side sits behind an interface. The real implementation subscribes to the
+bus; the mock synthesises vehicle state. Everything from aggregation outward — the
+boundary protocol, serialisation, per-client queues, reconnection — is identical in
+both, so there is no second implementation of the contract to drift.
+
+Same shape as `svc-nav`'s routing provider. A service that can produce its own
+inputs needs no external stub, and `tool-mock` deliberately does not contain one.
+
+This is what makes `app-flutter` developable against a single binary with no
+broker, no fixtures and no Jetson.
+
+Two rules constrain it:
+
+- **The mock must degrade.** Missing, stale and implausible signals are the normal
+  state in a car. A mock that always emits a complete, fresh, plausible dataset
+  trains the app to assume something false, and the assumption breaks on the first
+  real drive.
+- **Mock data must be visibly mock downstream.** Synthetic vehicle readings
+  indistinguishable from real ones, on a display in a moving car, is a safety
+  problem rather than a tidiness one. The mode is off by default and flagged in the
+  stream, not merely in a log line at startup.