Week two of July. This week's three pieces join into one line — the screen comes from outside, the permission is stopped inside.
This week's Signal
The screen is delivered. "The Screen Arrives From the Server" puts not one line of UI code in the client. The server serves the definition and the runtime draws it. Edit the definition and the next connection is different — no rebuild, no reinstall.
Hiding a button is not security. "Who May Press This" puts permission on the tool side, not the screen. Hiding a button on the screen is manners; what actually stops it is the tool refusing. A screen is JSON and JSON changes with every deployment — what catches it last must always be the server.
Paid back in numbers instead of words. "Only the Screen Thaws" merges the launch issue and February's vision pieces into one and replaces every number they asserted without measuring. Is a screen definition really small — 656 bytes. Does an edit really arrive instantly — 83 milliseconds, zero builds.
Tool and package notes
There is a trap in the order you register resources. Nothing a client can ask for may depend on hardware or a scan response. Register the screen resource after a device scan and a client attaching within that round trip gets Resource not found. Fast hardware passes, slow hardware fails — the least pleasant class of defect there is. Register first (synchronously), connect, then scan.
A short thought
"The server gives you the screen" sounds convenient, but it moves responsibility. The moment the screen leaves the client, what you put on the screen becomes what you permit. Which is why this week needed its second piece. Whoever serves a definition must also know how to refuse.
Next week
On to double bookings, the duplicates that retries create, and the place where a domain judgement becomes a rule without translation.
makemind.dev "Signal" — once a week, what went up and what got in the way while building it.