FIELD NOTES / A SMALL BUILD WITH CHECKS
The hallway departure board can wait. The app build does not have to.
Imagine leaving for work while a hallway display still has nothing useful to tell you about your train. The app needs building, but you need to leave. That is the scenario behind this demonstration.
We built its first piece: a small departure-board prototype in a real Claude session. The phone handoff, live railway feed and physical display integration remain future work. The video makes that distinction explicit.
A small brief with an awkward case
The brief asked for three sample departures, a nearest sample station and a manual station selector if simulated location was denied. Missing delay data had to remain Unknown. Everything was labelled demo data, not live departures.
Those constraints gave the session something it could actually finish and gave the reviewer something concrete to check. “Build a train app” would have left too much of the result undefined.
The work stayed in the session
The recorded build used Open AgentHub RC5 on an always-on local test server. Claude built the app, and the edited recording shortens a build that took about seven minutes. It is not evidence of a full-day or overnight run.
The footage also shows Claude reopening the actual app inside the integrated browser for a later inspection. During the recorded work, Claude corrected an edit after finding that Python was unavailable. The useful result was not a claim that every step succeeded immediately.
Then someone had to check it
The producer ran separate browser checks. Denying simulated location left the manual station selector usable; choosing a station with the keyboard brought the board back. A seven-minute delay appeared as seven, and missing information still appeared as Unknown.
That is the small lesson worth taking away: decide which awkward state matters before handing off the build. Then inspect that state rather than accepting a completed agent message as the result.
What would make it a real hallway display?
A real train feed needs its own data integration and error handling. A display needs a supported way to receive or show the app. If that connection requires a secret, the session needs a deliberately scoped grant and the integration still needs testing.
None of those steps is completed by this prototype. A centrally stored secret enables access; it does not prove a deployment succeeded. Nor does an always-on server remove the need to inspect the output. Infrastructure and provider usage can have separate costs.
Try the bounded version first
Ask for a board with three synthetic rows: one on time, one delayed, one with an unknown delay. Require a visible NOT LIVE label, a simulated denied-location path and a keyboard-usable manual picker. Ask for actual checks and a pass, fail or blocked report.
The video offers a working starting point for the imagined hallway project. The next useful step is connecting it to reality without losing the checks.