The last week of July. This week has no simulator. The verification does not pass without a board either.
This week's Signal
A board handed over its screen. "Boards Hand Over Their Screens" attaches an STM32H723 on the desk over USB serial, and an ESP32 found by mDNS over Wi-Fi TCP. Each board serves its own screen definition, and pressing a button really lights an LED. The client code does not differ by a character between the two — the only change is which bridge program runs.
Three terminals attached to one chip. "Attach to One Chip" stands one server beside the shop's payment terminal and attaches a tablet, a PC and a kitchen screen. No app was built for any of the three, and the card authorisation path was not touched by a single line.
Tool and package notes
This week's real gain was not an article but a defect found. Attached to a real board, listResources() died instantly.
type 'Null' is not a subtype of type 'String' in type castThe board was the first suspect. But the MCP spec makes a resource's description optional, and the board simply did not send it. The board was right. mcp_client 1.1.1 was casting that field as non-null; 2.1.0 already had it fixed.
Why had it not shown up? Because consumers that call listResources() are rare. A path that only runs initialize → tools/list → tools/call → resources/read never touches that code. A parser that requires a field the spec makes optional only dies when it meets someone who followed the spec. And that meeting usually comes on the day real hardware is connected.
A short thought
A simulator usually answers the way we wrote it. So it passes right through the places where we misunderstood. What this week confirmed was neither performance nor convenience but that — real hardware does not agree to our mistakes.
Next month
Down to field terminals. A queue, a picking route, a shift handover, a till with the network gone.
makemind.dev "Signal" — once a week, what went up and what got in the way while building it.