Version 1 record
This page describes software that has been retired. It is accurate about Version 1 and is not a description of what runs now — see the current site and the archive.
C-18 Browser client
Status: partly built
- Code:
client/src/— the component diagram and its layout, the liveness reducer and its windows, the speed control, the arrival-time control, the trajectory query, and the route and uncertainty layer data - Delivered by:
specs/003-component-shell-client, extended byspecs/012-visualisation; the capture harness underclient/e2e/byspecs/016-visual-capture - Covered by:
client/tests/, includingno-mock.test.tsfor the rule below andrecorded.test.tsagainst recorded broker traffic, plus the end-to-end specifications inclient/e2e/ - Not present: there is no map surface. The route and uncertainty layers exist as data, accessors and downsampling with a stated resolution, and are tested as such, but no Deck.gl layer object is constructed and nothing renders the forecast volume — the component diagram was delivered without a map base, so there is nothing yet to put a layer on
Responsibility: visualisation and control.
What it does
React, TypeScript and Deck.gl. It draws the component layout, the forecast volume, the planned route as a four-dimensional curve through that volume with a time control showing conditions at arrival, and the uncertainty field decaying and refreshing over time. It also exposes the simulation speed control, which means the client drives the clock rather than merely observing it.
Liveness, not configuration
The client renders all eighteen components from the first day, greyed out, and
lights each one only because a message from it arrived within that component's
declared liveness window. There is no manual override, no enabled: true flag,
and no hardcoded list of what is running.
There is also no mocked traffic, ever. A mock asserts the existence of something that does not exist, which is precisely the failure this rule exists to prevent. There is no demo mode, no fixture mode, and no path that populates the display for a screenshot.
The consequence, on day one, was a screen on which nothing was lit. That looked like a broken application and was the only honest picture of a system with nothing running. The first thing to light it was the simulation clock's heartbeat, and every component since has lit the same way — which is why a component that is running against a stack that is not shows nothing, still, and correctly.
Those two states are worth seeing side by side, because the difference between them is the whole of this rule.
Neither picture was arranged. The second was taken against a running clock publishing to a real broker, and the seventeen boxes that stayed grey stayed grey because those components were genuinely not running. There is no path in the client that could have produced the second image without the first being true first.
Making the core visible
The requirements ask the visualisation to make the distinction between bespoke logic and bought plumbing visible rather than hiding it — so that it stays obvious which parts of the system were built and which were configured.
Requirements: FR-01, FR-45 to FR-49, FR-52. Feature: 003, extended by 012.