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.