This isn't the usual 6-hour retrospective — there's too much for that shape. A lot converged in one long stretch: the App Store signing chain closed for real, the installer closed, the kernel's security domain closed, and the security gate as a whole narrowed from "several open items" down to essentially one. Separately — and explicitly not gating 1.0 — all three V3D hardware targets went from "designing" to "one step from a real GPU triangle." Here's the sweep, and an honest answer to the question everyone actually wants: how close are we?
The 1.0 checklist, today
| Item | Status | What closed it |
|---|---|---|
| Boots to Lumen desktop on real Pi4B | ✅ DONE | Reproducible on a pushed branch, not one rig's report |
| Agnostic bootloader (now named Signet) | ✅ DONE | MBR/GPT/FAT read-path composes end-to-end |
| Gate #2 (the cc0 compiler memory-safety bug) | ✅ CLOSED | Fixed, republished fleet-wide, fixpoint-verified |
| Installer: bootable IMG | ✅ DONE | A real cross-repo architecture debate, resolved correctly — see below |
| App Store signing chain | ✅ CLOSED | Accept/reject proven on real metal, two independent layers |
| SRDX secure transport | ✅ DONE | Real interop, real NIC |
| Core drivers (1.0 scope) | ✅ DONE | Storage + input real; NIC scope explicitly bounded |
| Security gate (9 domains) | 🔶 DOWN TO ONE ITEM | See the security section below |
| Release engineering | 🔶 IN PROGRESS | This document, and the doc it grows into |
Six of nine checklist rows are done. The seventh — the security gate — has gone from "several open domains" to one real item in flight: the Cap<T> object-capability model, which @grio deliberately chose to build as the real foundational primitive rather than patch around. Design is locked, a review panel is running feasibility passes right now, and two other historically-separate gaps (driver capability grants, a live unscoped-MMIO vulnerability) turned out to fold directly into the same fix instead of needing their own work. The eighth is release engineering itself — this document. We are not "close" in the vague sense. We are one real piece of design-to-implementation work away from a closed security gate, with everything else on the checklist already done.
The installer: a real cross-repo argument, resolved correctly
The installer's last gap — actually writing the computed MBR/GPT/FAT32 bytes to disk — surfaced a genuine architecture fork nobody had noticed: FS's whole filesystem stack used a 2-argument blk_write(lba, buf), while Kernel's own boot chain had independently, and just as thoroughly, standardized on a 3-argument blk_write(medium, lba, buf). Two new PRs landed on the same names with incompatible arities on the same day — Drivers caught it before it shipped, flagging it as the exact bug class gate #2 had just spent a whole cycle on.
Director ruled once (2-arg), reversed once after a deeper trace showed the split was older and deeper than either PR, and landed on the right answer: 3-arg is canonical, because epic #20's multi-device install requirement (HDD or USB key) genuinely needs a device-selector argument. Then, reviewing the fix before merge rather than trusting the arity match, Code caught a second, subtler bug: the arity was right but the success/failure return convention was backwards — a real write on real hardware would have been reported as a failure. It was fully masked because the test's own stub inverted the same way. Arity match isn't sufficient proof two functions are interchangeable is the lesson the fleet is carrying forward from this one.
App-signing: closed on real metal, not on a clean compile
Director held one line all cycle: a clean compile is not the close bar. It closed on two independent proofs, both on real hardware emulation:
- The crypto primitive — RPi-SME's driver on qemu-raspi3b:
SIGV 100— a valid signature accepted, a tampered message rejected, and a signature verified under the wrong key also rejected (the cert-binding property — verify checks the actual key bound to the signature, not just that some valid signature exists). - The full install-policy chain — Apps built a driver exercising the real
pk_verify_sigpkg → pk_install_policypath; Code, rather than trusting the PR, independently installed qemu-system-arm and booted it himself: real serial output"AR"— real key+signature accepts, cert-with-no-matching-key rejects.
Both layers, on real metal, independently run by someone other than the author. That's the bar this whole session has held itself to.
The security gate: from "several domains" to one
This cycle closed more of the gate than any other single stretch:
- Kernel's KERN domain — closed. FS discovered the real crypto primitives (pbkdf2, constant-time compare, a real CSPRNG) already existed in the codebase and just needed wiring — 40 of 40 tests passing.
- APP-6 — closed, in two honestly-separated halves. Scoping
ps/killto the calling process shipped clean. The other half — threading a real capability handle onto the file-I/O syscalls — was correctly not force-fit, because it's the same design question as the item below. - FS's own domain — went through a full formal re-verification, all 8 findings re-checked against live source under the newly-fixed compiler, not just cited from git history.
What's left funnels into one decision: Cap<T>, sigilOS's capability primitive. @grio looked at the options and chose to build the real thing — full object-capability, unforgeable, delegable, attenuable — rather than a narrow lexical stopgap, because the same type is wanted by MMIO grants, CAP_GPU, SRDX sessions, Lumen surfaces, and Signet's module grants. One primitive, done carefully, closes several fronts at once.
The review panel doing feasibility-and-soundness passes on the locked design (not re-designing it) surfaced two findings worth naming directly, because they're the kind of thing a security gate exists to catch:
FS found that the kernel's own existing capability-check code already documents its own hole in its comments: a process holding the MMIO capability type can map any physical address into itself — including kernel RAM or another process's memory — because the check authorizes the capability's kind but never its region. Separately, Drivers found the interrupt-controller path has zero capability gating today — any caller can enable or acknowledge any IRQ. Both are exactly what Cap<T>'s region-scoped, unforgeable design is built to close, and both fold into the same migration rather than sitting as separate deferred items.
Also worth knowing about, honestly not part of 1.0
A separate, very large thread ran in parallel this cycle: @grio activated full V3D 3D-acceleration (sigil-director#18) as active top-priority build work. It is explicitly not a 1.0 requirement — the desktop already composes on CPU raster, and V3D/GPU-raster stays 1.1 scope — but the amount of real progress is worth naming because of how it happened, not because it changes the checklist above.
In one long stretch: a real VC4 control-list encoder, QPU shader assembler, and MMIO kick/poll path were built, byte-verified end-to-end on the real ARM backend, and wired to a real framebuffer. Along the way, real hardware-only bugs surfaced that no amount of QEMU-only testing would have caught — an unaligned 16/32-bit memory-store fault that only manifests on bare-metal device memory (now being fixed at the compiler level, fleet-wide, rather than patched file-by-file), and a poll-status check that would have silently reported success on a GPU kick that never actually started. Both were caught before they could produce a misleading result on real hardware.
Pi3B — the first-triangle image is staged and flash-ready, twice re-staged after real bugs were found and fixed (a poll false-pass, then a genuine vertex-attribute-count bug independently metal-verified). Pi4B — the control-list encoder and GPU-side memory-management unit are both metal-verified; the newly-restructured two-phase submit path is merged and awaiting a fresh hardware-verify pass before anyone calls it done. Pi5 — the control-list and shader-record encoding for the newest GPU generation are code-complete; the next step needs a real register read from actual Pi5 hardware. All three: one concrete, named step away, and all three explicitly gated on physical hardware access, not more code.
Also from this stretch, entirely separate from 1.0: the agnostic bootloader now has a name — Signet 🔏 — chosen because a signet seals a sigil onto something, which is exactly what the bootloader will do to a machine's identity and license once the (not-yet-built, awareness-only) Editions & Licensing epic lands.
A correction to our own record
In the course of sweeping this stretch, Docs found that a chunk of its own recent local documentation work — a release-engineering RFC and its supporting design docs — never actually reached the pushed repository. It was written and committed on a local checkout that sits on the same external drive the fleet spent part of this cycle diagnosing as flaky; that drive is currently unreachable. The exact content is being reconstructed and re-pushed from source rather than re-typed from memory where it can be verified byte-for-byte (this release checklist among it); anything that can't be verified that way will be flagged, not silently re-asserted. Matching the fleet's own rule this whole session: a commit that only exists on a drive nobody else can currently read isn't real yet.
To Sigil-Video, for the Pi3B vertex-attribute audit: asked to pre-check a path in case a future flash came back with a blank screen, Video didn't just trace it and report — it found a real, confirmed bug (a hardware field telling the GPU to expect eight vertex-attribute records when exactly one was ever written), fixed it, and got it independently metal-verified, all before any flash result existed to prompt it. Runner-up to FS, for turning a "your own code already told you this was broken" comment inside cap_grant.sg into the clearest single justification for why the Cap<T> work matters.