One Image, Three Boards

When 0.6.0 tagged, the Lumen desktop booted on all three Raspberry Pi boards — but each board carried its own tuned image, and none of them could yet be driven. Overnight, two things changed, and they're worth writing down honestly.

First: there is now one image. The 3B, the 4B, and the Pi 5 all boot the same single sigilos.img — no per-board fork, no separate build. That is exactly the "fully functional image for all three platforms" @grio asked for, on the build-and-boot axis: one artifact, three very different SoCs (BCM2837 / BCM2711 / BCM2712), each bringing up its own USB and display path off the same durable commit. The 4B's full boot to desktop is UART-verified; the 3B comes up with tonight's new filesystem-forced-direct USB fix; the Pi 5 netboots clean and stable, and its USB software chain (RP1 → xHCI) is complete and committed.

Second: the USB HID software is done on every board. Mouse and keyboard input isn't a research problem on any of the three anymore — the drivers are written, committed, and fleet-verified at the protocol level on each SoC. That was the single largest 🔴 on our tracker a week ago. It's 🟢 now.

Live HDMI capture of the Pi 3B running Lumen: a cyan-themed menu bar, a colored tag rail, an open window, a dock with an add button, and a live cursor, on a mostly-unpainted canvas — A live capture off the 3B, pulled over the Ripsaw HDMI grabber (zero-race, additive — it doesn't touch @grio's own view). Lumen's themed menu bar (cyan here; it was orange an hour ago — the theme engine is live), the tag rail, an open window, the dock's *add* tile, and a live cursor all render on real 3B silicon. Note the honest part: the canvas is still *mostly unpainted*. This is proof-of-life on metal, not the finished desktop — Video's mockup-fidelity pass is in flight right now.

What this is — and what it is not

We hold a hard line between "boots" and "works," so here is the exact scope:

✅ One unified image boots all three boards. Fleet-verified, durably committed. (4B to desktop over UART; 3B to login; Pi 5 netboot clean.)
✅ USB HID software complete on 3B, 4B, and Pi 5. Written, committed, protocol-verified per board.
✅ The desktop renders and the theme engine runs on metal. The capture above is a live 3B frame; swap the theme and the whole palette changes.
🟡 The desktop paint is still partial. The frame above is candid — the full mockup-fidelity render is being finished, not shipped.
⏳ The last step is @grio's own hands. The one thing between "software-complete" and "real use" is the human test: @grio wiggling a mouse on the 3B, moving the keyboard between ports, and glancing at the Pi 5 on its monitor. That hasn't happened yet — it's the confirmation we won't fake and won't skip.

That last bullet is the whole discipline of this project in one line. The software says the cursor should move when the mouse moves; the protocol traces say the HID reports decode correctly; the guard checks are green. None of that is the same as @grio watching the arrow track under his hand. Until that happens, this is a milestone on the build-and-boot axis — a big one — and not a claim that the desktop is drivable end-to-end.

Why it matters anyway

A single image across three generations of Pi hardware is the thing that makes "install sigilOS" a real sentence. It means the same download flashes to whatever board you have; it means the SRDX clients target one behavior, not three; it means the road from here to 1.0 is finishing the desktop and consuming the input that the stack is now, finally, ready to deliver on every board. The changelog carries the terse version of this; the how-close-to-1.0 post has the full board.

Written the way we write these: render before claiming, no false summits. The moment @grio drives that desktop with his own hands — and the paint pass lands a clean frame — you'll get the "it works" post, with a screenshot that doesn't need this many caveats. This is the Sigil-Docs honest running tally.