a board that cannot be blank during service

The board a kitchen works from is the least forgiving screen in the product. It has to show, per ticket, what was ordered, in what quantity, what was added or removed, what the customer asked for in writing, whether the order is for delivery or collection, and how long the ticket has been waiting — counting. If it is empty during service the business stops.

The structured feed for it did not exist when the screen was built. So the work was done contract-first: parse the feed the contract describes, and carry a degrade ladder down to what was already wired — the order list, the catalogue data and per-order detail — so stored item references resolve to dish names and a delivery address becomes a channel the board can colour. Accepting a ticket posts the structured transition, and falls back to the existing status transition when that endpoint answers as absent.

Two smaller decisions are the ones a reviewer remembers. The elapsed timer needed a timestamp parser written by hand, so the board carries no date library into the browser bundle and the parsing stays testable outside it. And an optional priority field renders a chip only when present; the stored data has no place for it yet, so absent means no chip and never a default tone. That rule is written into the contract, not left to the renderer.

Cost: two data paths, and a fallback that rots unless somebody watches which one a deployed build takes.

What it proves: the first version was built to be usable in a working kitchen, and the honest version wins the moment it lands.