Every build to date, with dates =============================== Source: https://cubelinux.com/cubelinux-builds-to-date.html Dated: 2026-10-24 Mirrored: 2026-10-29T08:23:07Z UTC How: HTML converted to text, structure kept, nothing editorial changed. Words: 9941 ======================================================================== License: quote it, cite the URL and the date. This mirror exists so the record survives a crawl the origin server cannot serve. ------------------------------------------------------------------------ # CUBELinux · The Builds to Date Build record · 2026-09-23 · kernel 6.19.3-cubelinux0.7+ · newest build #102, installed and running · follows A Coordinate-Addressed OS Update, 2026-09-25 — what has changed since this record was written. The box has rebooted into #96: dmesg reports Linux version 6.19.3-cubelinux0.7+ … #96 SMP PREEMPT_DYNAMIC Wed Sep 23 23:12:18 EDT 2026, so the “#87 is what is running” statements below describe the box as it was on 2026-09-23 rather than as it is now. The live store holds 71,586 records with errors=0 at generation 2276 (cube-image digest /var/lib/cubelinux/store.img) — the ~70,400 quoted below was that day’s figure. The workspace suite is 218 tests, 0 failures (cargo test --workspace --release); the summary strip above carries 206 from an earlier snapshot, and the front page carried 216. The runner still names 28 gates, and the run for #96 reports 26 of 26 green. Built since this record was written: the gate on the doorway (see § Not claimed), and the boot record's guarantee and honest epoch (see § Next). Kernel #97 is built and installed — #97 SMP PREEMPT_DYNAMIC Thu Sep 24 23:44:36 EDT 2026, installed additively with nothing rebooted, so #96 is still what is running until someone reboots. The workspace suite is 224 tests, 0 failures, which is the 218 above plus the six the two builds brought with them. The wall run for #97 reports 27 of 27 gates green, with 1 skipped and not counted as passing: the USB store gate, because no dongle is attached to this machine. That accounts for all 28 gates the runner names. (The run recorded for #96 carries 26 of 26 and no skip line at all, so the two runs are not line-for-line comparable — the difference is stated here rather than given a cause this record has not checked.) Built since this note — kernel event capture. Every record could already carry a 16-bit class, the ops to write and retrieve by class were in the kernel and gated, and the vocabulary those bits belong to was already a userspace convention; what was missing was a kernel that captures events rather than only what a caller asked for. It now writes them into the events space (0xFB): a request the interface does not offer, refused and classed ERROR; a clock correction that made the boot record’s epoch provisional, classed BOOT; and a boot whose record only landed on a retry, classed ERROR|BOOT. They are found by class with CUBE_OP_FLAG_SCAN, read like any other record, and survive the fold. The kernel’s writing about itself is bounded (EVENT_BUDGET: 32 a boot, 8 of them refusals), because a kernel that appends a record per event can turn a storm of refusals into a storm of writes. Gated by verify-event-capture, which also checks the classes the driver spells out against the mask userspace’s vocabulary names. Not claimed: the capture rides the same cube_boot_record=1 switch, only those three events exist, and a store that cannot be read at all is the one refusal the kernel cannot record into itself. Kernel #98 is built and installed; the wall run for #98 names 29 gates and reports 28 of 28 green with 1 skipped (the USB store gate — no dongle attached). The wall names 30 gates as of the fold fix below. The wall run for #102 — the kernel that is installed and running, bzImage md5 8df249f3056dc938da881c0791cc5ab9 — reports 29 of 29 green with the same single skip. The workspace suite is unchanged at 224 tests, 0 failures. Found and fixed: a fold resurrected a deleted record. A fold turns the log's effects into the image's by keeping, per coordinate, the last entry in the merged order — that is how “the later write wins” is implemented. That order came from a derived comparison over the entry's fields in declaration order, and the class mask was declared before the arrival sequence, so the tie-break was the class and not the arrival. A del is written with no class (0); a sealed record is written with 0x0800. For the same coordinate the removal therefore sorted before the record it removed, and the record won: put → present, del → “(not found)”, cube-fold → “folded the log into the image” with the generation advancing and the log emptied, get → the value, back. Measured on the box on 2026-09-25, and reproduced through a sealed front-end and an unsealed one. The entry order is now explicit — (space, key, seq, …) — with the reason written beside it, because “the fields happen to be declared in this order” is what went wrong. Gated by verify-fold-delete: it fails against #98 with “a fold resurrected a deleted record” and passes against the kernel carrying the fix. The gate writes a classed record on purpose — an unsealed store writes both entries with the same flags, the tie falls through to the sequence, and the defect is invisible there, which is exactly what the gate did before this and why it agreed with a bug it could not see. One qualification on numbers this record has quoted. The digest is taken over the same merged order the fold writes, so the record counts above (~70,400 … 71,944) come from a merge that could resurrect a deletion, and may include records whose removal was still in the log when they were counted. They are what the tool said; they are not certified by this defect being fixed, and the first digest taken on the kernel below is the first one that is. Kernel #102 — installed, with #98 still running until the next reboot and the previous pair kept in /boot/cubelinux-prev/. (The number moved past #99 because each build of the tree stamps a new one, including the attempts that failed to link.) Proven on the metal, 2026-09-25 — with #102 installed and running, which is where the box stands now. The eight records the old kernel had resurrected — every one carrying flags=0x0800, which is the shape that failed — were deleted and folded twice: all five spaces read 0 record(s) afterwards and every coordinate answers (not found), where the previous kernel brought them back with their old values. And the same boot produced the case the epoch fix was written for, unprompted: this machine's clock arrived 43.96 s out, chronyd stepped it, and the kernel wrote boot=1790393113 uptime=40 clock=set — the record rewritten with the corrected time, with the clock-set event captured into the events space (0xFB, one record, flags=0x0080) rather than only logged. The first digest taken under it is therefore the first one this defect cannot have touched: 73,045 records, errors=0, generation 3623. the store lives in the kernela coordinate is an addressa region is a seek206 tests · 0 failures ### In this document 1. What CUBELinux is now 2. Milestones reached 3. The build line 4. What it does 5. The store and its interface 6. A region is a seek 7. What the gates prove 8. Defects the gates caught 9. What the future holds 10. Checking this record yourself ## Abstract This is the running record of the CUBELinux builds: what the system is, what each build added, what the gates proved, and what is still ahead. The first whitepaper documents the design and is left untouched as that design record; this document records the builds, and it is written to be read on its own. The store lives in the kernel. A coordinate is no longer only a way to name a record but a way to reach one — a lookup is a search over arithmetic addresses. A region is a way to query one: a box is found by seeking to the foot of its key span and reading forward. And as of today the whole path works on the metal: this machine boots CUBELinux, the kernel serves the store, writes are durable, listings return the store's records, and the log that makes writes cheap is now folded on a schedule instead of by hand. Every number below is measured by a gate, by the test suite, or by a command whose output is quoted. Where something is not proven, it says so. ## 1. What CUBELinux is now CUBELinux is a coordinate-addressed operating system. A coordinate is (space, point) — a 32-byte space selector and a 192-bit key produced by a space-filling curve (Morton by default) over three 64-bit axes. Records live at coordinates, not behind names; the space is a hard partition, so cross-space access is structurally impossible from a query. The store is in the kernel, the interface is cube(2), and everything above it is written against that interface — a name, a path, or a mount is a view at the edge, not the substrate. Today that is a running system rather than a design: It boots.6.19.3-cubelinux0.7+, build #102, is installed on the workhorse — bare metal, not a VM, and it is what the default entry boots. The store driver is built into the kernel (CONFIG_CUBELINUX_STORE=y), registers /dev/cubelinux at boot, and is told which image to serve by the command line: cube_store=/var/lib/cubelinux/store.img, with panic=30 so a fault returns the machine rather than hanging it. Build #86’s one change was to durability: the entry a write appends goes down unsynced, and the control block that counts it carries the single fsync for both — one sync where there were two, ordered so that a crash can lose an unacknowledged mutation but can never count one that is not there. The half of that sentence nobody checked was the assumption underneath it, that there is always a control block to carry the flush — and for a store with no control block there was nothing on the append path to flush at all, which §8 measures and #96 fixes. verify-torn-tail is the gate that justified the collapse, by tearing the log between the two and reading the result with userspace on the same bytes. #87’s change is the arrangement vocabulary’s second half: a value written as several records at consecutive z now comes back joined from one plain read of the first slice’s coordinate — and what it deliberately will not join is a sealed chain, because a sealed slice is an envelope with its own header and nonce, so joining those belongs to whoever holds the key. #87 is what is running — the box says so itself, Linux version … #87 … Wed Sep 23 19:51:11 EDT 2026 — and #96 is installed, taking over on the next reboot: it is the build that makes a refusal a refusal, and that makes an acknowledged write durable in both shapes the store takes (§8). It supersedes #95, which was installed for twenty minutes and never booted — every measurement in this record was taken on #87, and re-taking them on the metal is what the next boot is for. The first attempt at the benchmark boot would not start and is recorded in §8: its initramfs carried no disk driver, and on this machine the disk's driver is a module. The machine came back on the default entry after a cold boot, the boot is now rehearsed in QEMU against a disk of the same shape, and it is armed again for the next reboot — because the figure this build has not been measured for is its own durable write. It is the default now, with the workhorse kernel as the way back. As of 2026-09-23 GRUB's default entry is the CUBELinux entry, named by its explicit id (GRUB_DEFAULT='cubelinux'), and the previous workhorse kernel 6.19.3-cube+ is named as GRUB's fallback — so an entry that will not load hands the machine to the kernel that was there before. What that covers is an entry failing to load (a missing kernel or initramfs), and not a kernel that loads and then faults: panic=30 reboots into the same entry, and the way out of that is the boot menu or grub-reboot gnulinux-6.19.3-cube+-advanced-2a7b1834-83ed-4394-a8ee-816b885b5624. It has booted by default since 2026-09-23: a plain reboot, with nothing armed one-shot, came up on CUBELinux with cube_store= and cube_boot_record=1 both on the command line. A running kernel on this machine is therefore still a question about which boot, and /proc/cmdline is where the answer is. It serves its store. A client asks the front-end for a listing and gets the store's records; it writes, and the write is acknowledged once the kernel has taken it into the log and flushed it. The store on disk carries 70,408 records — measured today, and it grows as this site writes — in a v4 addressed image, sealed, with the format's own verifier reporting errors=0. That word "flushed" was earned back today: "acknowledged" had been taken to mean "durable", a store with no control block was acknowledged without a single flush on the path, and #96 fixed it at the cause — §8 has the measurement, and §9 records the decision. It maintains itself. A fold — the operation that empties the log into the image — now runs on a daily timer, so the store no longer depends on somebody remembering to fold it. It records its own boots.cube_boot_record=1 is on the command line, and it is doing the work: the kernel appended boot=1790189822 device=/var/lib/cubelinux/store.img kernel=Linux version 6.19.3-cubelinux0.6+ … into reserved space 0xFC, classed 0x0080, through the same append() as every other record — the OS storing itself, written by the kernel rather than by a client. It is verified three ways on the box, the way its gate verifies it: the record exists; cube(2) serves it back (a read of that coordinate answers 219 bytes with the mask 0x0080, and the front-end answers the same bytes for the name boot); and userspace finds the same record in the image after the log is folded (cube-image flag-scan for class 0x80 finds exactly one). The userspace marker it supersedes is retired; that marker had also stopped working, answering Function not implemented on a kernel with no cube(2). And it is fast where it counts, measured on the box. A coordinate read through cube(2) is 11 µs — the mean of 200 reads that find their coordinate, worst 21 µs — and a ten-record listing is 47 µs, and asking which spaces exist is 0.158 ms. One thing about that figure belongs here rather than left standing: those 200 reads asked for a coordinate the box’s store does not contain. The benchmark’s probe space (0x5c…) exists in the gates’ stores, which are built with it, and not in this machine’s, so the number is the cost of a read that finds nothing — the fast path — and the listing timed a space with nothing in it. It is left in place because it is a real measurement of a real question; what it is not is the cost of finding a record. The benchmark boot now names a space and a coordinate the live store actually holds, so the next run measures the question this paragraph was claiming to answer. A durable write is 4.962 ms on build #87, worst 5.652 ms over ten writes — measured on the metal after this build folded the write's two fsyncs into one, which is what halved it from the 8.2 ms that build #85 measured. Those are not the measurements this record carried before, and the write is the reason: the write path resolved the store's layout by reading the whole device — 100,663,296 bytes — in order to append seventy, which cost 60–131 ms per write and was never gated at all, because the gate timed only reads. It now reads the control block and the log's head. On the read side, the control-block validation, the header, the space table and the log window are held across calls instead of re-read per call, and the validation itself dropped from 4096 bytes to 96: the question every call asks of the control block is one number, and it is in the first 48 bytes of each of the two copies. The unfolded log is capped at 256 KiB and folded from the write path, because every read pays for it — the log's capacity is 50,335,744 bytes, so a full one would have put ~48 MB in front of every coordinate read. ## 2. Milestones reached Dated, because a milestone is a thing that happened on a day: whenmilestonehow it is known 2026-09-20/21The store moves into the kernel and the live store is converted in place — folded to the addressed format, sealed, every record and value preserved byte for byte.the store's digest before and after: same fnv1a64, 69,638 records 2026-09-21A region becomes a query: CUBE_OP_RANGE seeks a box's key span instead of scanning the space.verify-range, against userspace, over a box with a trap record inside the span and outside the box 2026-09-22The class mask travels with the record: format v4 widens the index entry, and CUBE_OP_FLAG_SCAN retrieves by class.verify-flag-scan, 18 matched records, both layouts, diffed against userspace 2026-09-23The kernel serves the live store on the metal. A listing walks the box's own 96 MiB sealed v4 store through cube(2) — 12 spaces — and every record userspace can see in the image is present in the kernel's answer.verify-enum-live, run on this machine, PASS 2026-09-23The walk terminates. A defect that made every enumeration re-serve the space forever — and took the front-end to 6.4 GiB twice, to the OOM killer — is fixed at its cause and bounded in the client. §8 names it.the walk ends on the contract's own rule: a cursor that stops moving; the front-end's resident size stays flat at 3–4 MB 2026-09-23The log folds on a schedule.cube-fold plus a daily timer; the operation no longer waits on a person.by hand: log 49,280 bytes → 0, active_slot 0 → 1, store sound afterwards 2026-09-23No red gates remain. The previous record carried one — verify-efi-boot — and re-running it is what retired the claim: the boot chain the box uses passes.verify-efi-boot, pass 2026-09-23The install gate and the way back are honest. The installer keeps a copy of the release it replaces instead of relying on a hand-made convention, and the preflight reads the boot entry rather than the running kernel.the preflight that refused this install now reports READY — 16 checks pass, one of them having become a note when the default entry was pointed at CUBELinux itself, and its judgement restated around the question that still has an answer: is a copy of the kernel this install overwrites kept? The five copies the installer had left beside the live kernels were being enumerated as ten unbootable menu entries, because 10_linux globs /boot/vmlinuz-*; they now live in /boot/cubelinux-prev/, and the menu is 17 entries rather than 27 2026-09-23The kernel joins a chain. A value written as several records at consecutive z comes back from one plain read of the first slice’s coordinate: joined, in order, with a buffer too small told the length and a hole failing the whole read rather than returning the prefix that is still there. A sealed chain is deliberately not joined, and the flags say so rather than pretending.verify-chain, seven checks, PASS — and the measurement that made reading those bits safe at all: 0 records in the live store carry any of them 2026-09-23The benchmark ran on the metal, and the write halved. Booting into an initramfs with nothing else running, cube(2) against a copy of the live store: a durable write is 4.962 ms mean and 5.652 ms worst over ten, where build #85 measured 8.2 ms — the two fsyncs becoming one, confirmed on the hardware rather than argued from the code. A read that finds its record is 11 µs; the 4 µs this record carried before was a read asking for a coordinate the store did not hold.the benchmark boot's own transcript, whose first line is the kernel's identity from uname; the boot is rehearsed in QEMU first (rehearse-bench-initramfs.sh) 2026-09-23A walk with no store behind it refuses, and says why. The defect that hung the first benchmark boot — about two hundred thousand invented records a minute, forever — is fixed at its cause: 38 error returns in the store driver negated an errno that was already negative, so a refusal reached every caller as a success. The walk arm that advances its own cursor now refuses a positive answer as well, and a store that is not there answers "No such device" instead of the walk's own end signal. §8 names all of it.the reproduction in the guest: 0 records and a boot that finishes in 5 s, where it served 364,994 invented record lines in the 90 seconds the instrument allowed; verify-no-store, pass 2026-09-23The wall was run whole, and every red it reported was chased to a cause. 26 gates, 26 pass. Four were red at some point in the day: the walk's own defect (fixed in #95), two gates accusing the kernel of what the live box was doing (both instrument defects, both fixed), and one real one — a store with no control block whose writes were acknowledged without a single flush on the path (#96), which the record had first attributed too broadly and now records as the correction it was.run-all-gates.sh — 26 named claims, one verdict, and each red held to a measurement rather than to an explanation 2026-09-23A store on a device that is not this machine. A USB dongle carries a CUBE store of its own — control block, two slots, a log — and the kernel serves it as its store: four records written at coordinates through cube(2) were walked back off the device by a later boot, after the machine that wrote them was gone. It is the smallest form of the question the cube-edge design asks about a device with its own identity, with a USB stick doing the embedded part.verify-dongle, pass — the device found by its own serial rather than by /dev/sdX, refused if anything is mounted from it, the write read back after a power cycle, and the device named as a space of its own with a portal leading to it ## 3. The build line The builds that changed the system's shape, in order: buildwhat it changedhow it was checked #49format v3 — the image carries its own addresses: a space table, a fixed-stride index, values in index order.the live store folded to v3 with the digest unchanged #50the fold fixed on the box; the live store converted in place, sealed.gates run on the box, store walked both ways #52the kernel can author its own boot record — one record in a reserved space, at the first write of a boot.verify-boot-record, the record read back three ways #53the addressing primitives move into one shared file, and the driver uses it — no second copy of the key to drift from.verify-enum, verify-syscall #55CUBE_OP_RANGE — a region is a seek: the box's key span, binary-searched and read forward.verify-range, against userspace —format v4 — a 16-bit class mask in both the index entry and the log entry, so a record's classification travels with it and survives a fold. Now the live store's format: the fold wrote it.verify-flag-scan, through both layouts, against userspace —CUBE_OP_FLAG_SCAN — classify at write time, retrieve by class later. The scan names a mask, a mode (any/all) and a scope (one space, or every space).verify-flag-scan — 18 matched records diffed line for line against userspace —one frame for every walk — get, enum, range and flag scan all return the class mask beside the key and value, so nothing has to be re-read to learn what a record is.verify-enum, verify-syscall, verify-flag-scan —one value, several records — a chain is read back by one plain read of its first slice's coordinate: the kernel joins the slices in z order, tells a buffer too small the length it needs, and fails the whole read on a hole rather than returning the prefix that is still there. A sealed chain is not joined, and the flags say so.verify-chain — seven checks, PASS, including a userspace reader of the same vocabulary agreeing byte for byte #79the walk skips what the cursor has already returned. Every enumeration had been re-serving its space from the first record, so the cursor—the walk's only end signal—never stopped moving. Fixed in the kernel; bounded in the client.verify-enum-live on the box, PASS; verify-enum, verify-enum-cost, verify-frontend, verify-flag-scan, verify-file-store, all pass #95A refusal is a refusal. Every error return in the store driver had two minus signs where Error::to_errno() already carries one — 38 call sites — so a refusal reported itself as a success to every caller that tests ret < 0. That is what let a walk with no store behind it serve invented records forever. The conversions are corrected; the one walk arm that advances its own cursor now refuses a positive answer; a store that is not there answers "No such device" rather than the walk's own end signal; and the walk with no store is a gate of its own.the reproduction, in the guest: cube_store=/dev/null cubelinux.enum=1 serves 0 records, says walk: spaces failed: Invalid argument, and the boot finishes in 5 s — it served 364,994 invented record lines before. verify-no-store, pass #96An acknowledged write is durable, in both shapes the store takes. The collapse to one fsync per append — the entry unsynced, the control block's flush carrying both — is sound where there is a control block to write. Where there is not, the count write never happens and nothing on the append path was flushed: four writes were acknowledged and gone after a kill. append now takes the entry's own fsync exactly when no later write in the same operation will carry one — one boolean, both branches gated — so the box's shape keeps the measured 4.96 ms win and the bare shape pays its entry's flush, which is what it always did.verify-kernel-append, pass — over two device shapes now, each folded the way userspace reads it and compared against the same userspace store, with the guest killed by SIGKILL and no shutdown at all; verify-torn-tail and the whole wall, 26 of 26 ## 4. What it does Stated as capability, so it can be checked against the machine rather than believed: Address a record by where it is.cube(2) (syscall #548) puts, gets, deletes and syncs at a coordinate. No path, no name, no inode, and no lookup table between the caller and the bytes. Walk a space in bounded batches.CUBE_OP_ENUM returns whole records packed as key(24) | flags(2) | value_len(u32) | value, with a cursor that counts the records already returned. A short batch is not the end; a cursor that stops moving is. Ask a question about a region.CUBE_OP_RANGE answers the records of a space inside a box, by seeking rather than scanning. §6 has the numbers, including what the bound costs when the box is not aligned. Retrieve by class.CUBE_OP_FLAG_SCAN takes a mask, any or all, and one space or every space. Write durably, cheaply. A write is acknowledged once it is durable in the log, not once the image has been rewritten; the image is rewritten by a fold, which is now on a schedule. On this machine a write advances the store's on-disk generation and is visible to the very next listing — 6,164 records, one write, 6,165. Survive a kill. Acknowledged writes were shown to survive a SIGKILL (verify-kernel-append), and a torn log entry at the tail is discarded rather than replayed (verify-torn-tail). Both are measured on the two shapes a store takes — with a control block, whose count write carries the flush, and without one, where the entry carries its own — which is the distinction #96 found and §8 records. Serve a store that is not on this machine, and name the device that holds it. A USB dongle carries a CUBE store of its own, and the kernel serves it as its store: verify-dongle writes four records at coordinates through cube(2), lets the machine that wrote them go away, boots again and walks them back off the device — 4 spaces, 8 records — including the device's own space and the portal that leads to it. The device is found by its serial, never by /dev/sdX, and the gate refuses a device that is mounted or carries a filesystem. A device is an entity, and this substrate names an entity with a space. The reserved tags are classes — 0x00 root, 0xFB events, 0xFC boot, 0xFD keystore, 0xFE portal, 0xFF edges — and a device is the first class whose instances have to be told apart, so 0xF9 names the class and the rest of the id names the instance: 0xF9 ‖ SHA-256("cubelinux.device.v1:" ‖ serial)[0..31], unguessable because a space id is a capability. Declaring a device writes two records — the identity at that space's origin, and a portal descriptor in the portal space, entered from this machine's root and leading to the device — and the gate proves all of it from outside: the kernel's walk reports the space and the portal, and the same descriptor decodes off the device with the decoder that wrote it. Keep the store sealed at rest, with the records as ciphertext on the device. ## 5. The store and its interface control block two copies, 0x0000 and 0x0800 magic, slot size, active slot, generation image slot ×2 (the fold writes the idle one, then flips) [header 46] magic, version, curve, extents, counts [space table: space_count × 48] space | first index | records [index: record_count × 40 (v3) / 42 (v4)] key | [flags] | value offset | value length [values: packed, in index order] log region the unfolded writes, drained by a fold The index is fixed-size and sorted by key, so a reader computes a record's place as index_off + i × INDEX_ENTRY — a coordinate is an address, exactly as claimed. The format is described once, in drivers/cube/cube_format.rs, compiled by the kernel and included by userspace; two descriptions of one format is what once shipped an hour of unsupported-version. A fold is safe to interrupt, and that is a property of the layout rather than a hope: the image lives in two slots, a fold writes the slot that is not active and then points the control block at it. Observed on this store: active_slot 0 → 1 with image_off 4096 → 25165824, and the log went from 49,280 bytes to 0. Through cube(2) the operations are the verbs the design always named: PUT, GET, DEL, SYNC (fold), ENUM and SPACES (the bounded cursor walks), RANGE (the region seek) and FLAG_SCAN (by class). Each argument block is versioned by its own size field, so the interface grows by gaining a block rather than by being replaced — the coordinate block is 88 bytes, the walk's own is 64, and the kernel routes on the size it is given. ## 6. A region is a seek The operation the address existed for is the region query — the records of a space inside a box — and it landed as a seek rather than a filter. The key fact is about the curve, not the query: Monotonicity. If p ≤ q on every axis, then key(p) ≤ key(q). Under it, a box needs no decomposition at all: its two corner keys bound every key inside it, so the index is binary-searched for the foot of that span and read forward to its head — O(log n + span) instead of O(records). Every candidate is then decoded and tested for membership, because a span is a bound, not the set: keys of points outside the box also fall inside it, and returning them would be wrong. Monotonicity belongs to a curve, not to the trait. Morton and RowMajor have it; Hilbert does not — it transposes and rotates the axes, so its corner keys say nothing about the keys between them, and seeking on them returns wrong answers. The store gates the seek on the curve, and a curve must opt in; it cannot inherit a bound by accident. Measured over a 32,768-record space, asking 512-record questions: curveregionentries examinedrecords returnedover-coverage Mortonaligned 8³ at the origin5125121.00× Mortonthe same 512 points, slid to (5,5,5)3,5785126.99× Hilbertaligned 8³ at the origin32,76851264.00× The 1.00× is exactness worth naming — for an aligned cube at the origin the span is the box's keys. The 6.99× is the honest cost of a bound: an unaligned box's span covers keys of points outside it, and those are examined and rejected. The 64.00× is the gate working — Hilbert has no span, so it walks. The gate kernel/verify-range.sh boots the kernel and diffs its answer against userspace's over an unaligned box holding a deliberate trap — a record at (2,7,7), outside the box but inside the span — and the walk is correct only if it examines that record and rejects it. ## 7. What the gates prove The gate wall, and what each gate proves. The rows marked today were run on 2026-09-23 — the cost, file-store and syscall gates re-run on 2026-09-23 for the #86 change — each in its own VM or file store, so a gate is about the build rather than about what this machine happens to be running — and the box-side rows against whichever kernel was running when they were taken. The 4 µs read and the 8.2 ms write are build #85’s: they were taken before the reboot onto #86, which folds the write’s two fsyncs into one, and the box has not been re-measured since: claimgateresult the box's own store, walked through cube(2)verify-enum-livepass — today, on this machine, after the name table in the gate was completed (§8) the walk answers in the kernelverify-enumpass — today a walk with no store behind it refusesverify-no-storepass — today, and the gate is new: it boots the bench initramfs against /dev/null and against a store that is not there, and requires 0 records, a named error, and a boot that finishes a walk costs what it returns (1.1× across a 40× store)verify-enum-costpass — today a client, through the front-endverify-frontendpass — today a class mask travels with the frameverify-flag-scanpass — today a store that is a FILE, not a deviceverify-file-storepass — today the kill switch, against a throwaway vaultverify-selfdestructpass — today, after the host fingerprint learned to tell a store from its bytes (§8) a region is a seek, not a filterverify-rangepass cube(2) is the same storeverify-syscallpass a fold writes what userspace holdsverify-kernel-checkpointpass acknowledged writes survive a killverify-kernel-appendpass — today, on both store shapes: a store with no control block, where the entry carries its own fsync, and a formatted device, where the count write's fsync carries it. It was the wall's one red until #96 fixed the shape nothing was flushing at all; §8 has the measurement and the wrong first attribution a torn log entry is discardedverify-torn-tailpass the kernel records its own bootverify-boot-recordpass a sealed record is ciphertextverify-encryption + sealed-readpass the kill switch, against a throwaway vaultverify-kill-switchpass the boot chain the box usesverify-efi-bootpass — today; it was the one red gate in the previous record, and re-running it is what retired the claim a reader refuses a device it cannot holdverify-store-readerspass — today: a store device refused in 0 s with the reason and the remedy, byte-identical afterwards; a 16 GB device-shaped file refused under a 2 GB cap rather than mapped; and the readers whose subject is a device still reading it a store on the USB dongle, written and read backverify-donglepass — today, run on its own with the device attached: four records written through cube(2), the machine gone, and a later boot walking 4 space(s), 8 record(s) off the device — the records, the device's own space (0xF9 ‖ SHA-256(serial)) with its identity record, and the portal entered from this machine's root that leads to it, which the userspace decoder reads back off the device. The gate skips with a reason when the stick is not in the machine The board names 28 gates — verify-no-store (the walk defect's own gate), verify-dongle (a store on removable media) and verify-store-readers (a device refused before it is read) are all new today. The whole wall was run for this build — 26 of the 26 it named then: 26 pass, 0 red — and the two added afterwards — verify-dongle, run on its own with the device attached, and verify-store-readers, run on its own on this machine — both pass. A wall run from here on names 28. Every red the day produced is in §8 and none of them survives as a defect: two were gates accusing the kernel of what the live box was doing, one was the walk's own, and one was a store shape whose writes were acknowledged without a single flush on the path. The workspace suite — the crate tests that underpin all of the above — is 218 passed, 0 failed. ## 8. Defects the gates caught Named, because each was found only by running the real thing, and a record that shows only the green is a ledger rather than a record: A walk that stopped at its first batch. A short batch is not the end — only a cursor that stops moving is. Caught at 747 of 3,006 records; now the rule the walk's tests are written around. An index entry written four bytes short — the value length, against the arithmetic that the index is fixed-stride. A store that could be folded exactly once: the second fold read an addressed image with a packed-only reader. A walk that never ended (2026-09-23). The batch's seen counter started at the cursor instead of at zero, and it is compared after being incremented — so nothing was ever skipped: every call re-served the space from its first record while the cursor advanced by the records returned. Since the cursor is the walk's only end signal, the walk never ended. A listing looped inside the front-end until the kernel's OOM killer took that process, twice, at about 6.4 GiB of anonymous memory each time — and while it was wedged, its writes failed. Every other path that builds a batch already started the counter at zero; this one was the outlier, and it only shows on an addressed image whose space has unfolded edits, which is precisely the live store and precisely what the earlier gates' packed test store never exercised. Fixed at the cause, bounded in the client so a future defect of the same shape cannot take the machine, and the live gate now fails fast instead of streaming duplicates forever. A boot record that was silently never written (2026-09-23) — and no gate caught it. With cube_boot_record=1 on the command line, the kernel's first store operation logged could not read the store to record this boot, and the store held no record in space 0xFC at all: the switch was on and the effect was off. The cause is a credential mismatch, not a store fault. The driver opens the store O_RDWR in the calling process's credential context and caches that handle for the whole boot, while every store client on this machine runs as an unprivileged user and the store image was root:root 0664 — readable by its clients, not writable by them. So the first client to touch the store lost that boot its record; once a root-context caller had opened it, the handle was inherited by every later caller and writes began landing normally. Fixed by giving the image the same group the store's other artifacts already use (chgrp cubelinux, mode unchanged), and the record appeared on the next boot. It belongs in this list precisely because it was not in the gate's: verify-boot-record.sh passes and always did, because in a VM the store is a raw device opened by root inside an initramfs — no unprivileged caller, no user services, no stale clock. A gate that opens the store as root cannot see a defect that only an unprivileged caller can produce. It also exposed a second, independent defect, since fixed and in the kernel this machine is running (#86): ensure_boot_record() claimed the boot before it attempted anything, so one transient failure cost a boot its record, with no retry. It now claims one attempt with a compare-exchange — so two callers racing into their first write still cannot both write a record — and that claim is counted whether it succeeds or fails, which is what makes a failure retryable on a later write, up to four attempts, because “a store that will not take it will not take it later either” is not true of the failure it actually had. The retry became affordable only because the record now goes down the same bounded path every other write takes: it used to resolve the whole device for the record and then resolve it a second time for the caller’s own mutation. That it is in this kernel rather than merely intended for it is checked against the image itself: the string the new failure path emits, the store would not take this boot’s record, is in the extracted kernel, and the message it replaced is not. A bench that measured a read it never gave a buffer (2026-09-23) — caught by an impossible pair of numbers. The cost gate timed a coordinate read with a.len = 0: no buffer. On the box that reported 0.000 ms across 200 reads while listing one of the ten records it returns reported 0.015 ms — and a listing is one lookup plus nine more index entries, so it cannot be thirty times slower than the lookup inside it. The reading was an artifact of the call's shape rather than a fast read, and it was flagged instead of published. It also means every read figure quoted from that bench before today was a figure for a call handed no buffer, including the one this record previously carried. Fixed by passing the buffer the loop already had; the corrected box numbers are above. The lesson is the instrument's own: a benchmark that skips part of the operation is a benchmark for the part it skipped. A display fault that left no trace, and then left (2026-09-23) — unexplained, unreproduced, and no longer being tested for. On returning from a boot the external monitor went black and came back with artifacts, and then it levelled out: the effect disappeared on its own, which is what a boot-time transient does and what a memory or hardware fault does not. Nothing was logged that would explain a persistent fault — no i915 error, no atomic-commit failure, no MCE, ECC or bad-page event, no OOM — and the store's canary was unchanged across it. The one trace sits in the settling window: intel_encoder_link_check_work_fn [i915] logged as having hogged a CPU for more than 20 ms, four times inside two seconds, minutes after that boot, and never again, with zero such warnings in the previous eight boots. The box's internal eDP panel is connected but disabled, so i915 link-checking a panel nobody uses was the suspect, and video=eDP-1:d was added to the CUBELinux command line to tell the kernel the connector is not there. It was removed the same day, and the reason is the point. It was in place for exactly one boot — the boot armed for the benchmark — and that boot's display was clean. That is not evidence for the hypothesis, because the fault had already stopped recurring before the token ever ran: a clean boot when nothing was going wrong is equally consistent with the token working, with it doing nothing, and with the transient simply being gone. The only outcome that would have carried information was the blanking coming back with the token in place. It did not come back, so the experiment collected a cost — the internal panel is unavailable to the kernel while that token is set, so undocking means a black screen — and no information. The fault stays in this list as unexplained and unreproduced: not fixed, and not filed as one. The token is one edit away in /etc/grub.d/12_cubelinux if the blanking ever returns, and the note there says which outcome would read as an answer. A walk with no store behind it served invented records forever (2026-09-23) — found by the first benchmark boot, and fixed in two halves. Reproducible in one boot — cube_store= cubelinux.enum=1 — it served roughly two hundred thousand invented records a minute: a garbage space, a zero-length value, and a cursor that kept moving, so the walk never reached an end and the machine never got on with the boot it was making. It is the third time this project has met a loop with no end signal, and the first time the loop was in what the kernel answered rather than in how a client read it. The first half was the store's answer. A caller asking which spaces exist was told success — spaces returned 0, len=0, cursor=1 — so it copied the space it was handed out of a buffer the kernel never wrote, and because the cursor advanced by itself the rule that ends every other walk here, no progress is the only end signal, could never fire. A store_readable() guard now runs before either walk op answers anything, and the driver refuses a store it cannot read. The second half was a sign, and the diagnosis recorded for it was wrong before it was measured. The guard fired and the client was told success anyway, and both of the candidate explanations in the previous record are wrong: the ret < 0 test is on the path, and nothing overwrote the answer. What crossed the boundary was a positive number. kernel::error::Erroris the kernel error code — from_errno(-2) == ENOENT, to_errno() is documented as "the kernel error code", and the API's own conversion of a Result to a C result, kernel::from_result, writes T::from(e.to_errno() as i16) with no negation, as every other driver in this tree does — and the driver negated it a second time. 38 call sites in cubelinux_store.rs were shaped -(e.to_errno()), so every refusal in this driver reported itself as a success to every caller that tests ret < 0. Why it became a loop in the space walk and only there:CUBE_OP_SPACES is the one arm that advances the cursor itself. Every other walk arm leaves the cursor where the caller put it, so a bogus return there ends the walk on the no-progress rule — which is why one defect stayed invisible at every other verb. Both halves are fixed: the 38 conversions return e.to_errno(), and that arm refuses a return that is neither 0 ("here is a space") nor negative (a refusal). Measured against the reproduction, in the guest, on the bench initramfs: cube_store=/dev/null cubelinux.enum=1 prints walk: spaces failed: Invalid argument, serves 0 records, and the boot finishes in 5 seconds — where it used to serve 364,994 invented record lines in the 90 seconds the instrument allowed it. A store whose device is not there at all answers "No such device" rather than the walk's own end signal, so a walk over a store on a disk with no driver cannot read as a walk over an empty store — which is exactly what that first benchmark boot was. The diagnostic prints the hunt needed are gone; the refusal is the return value. The three checks are verify-no-store on the wall now, and the same three inside the benchmark rehearsal, where they were warnings while the defect was open. A durable write that was not durable — and the first attribution of it was wrong (2026-09-23). Fixed in #96.verify-kernel-append asks the question a log exists to answer: four writes are acknowledged by the kernel, the VM is killed with SIGKILL with no shutdown at all, and the log must still hold them. §7 recorded it as a pass, and re-running the wall found it red. What this record first said about it was too broad, and the correction is the interesting part. The change between the passing kernel (18:41) and the failing ones is one commit — e0218ec96, "one fsync per append, not two", which writes the log entry with no flush and lets the control block's fsync carry it — and the entry's own flush is what was lost, so the collapse was named as the cause. It was not. The collapse is sound where the sentence it rests on is true, and that sentence assumes there is a control block to write. A store with no control block has no count to write, so nothing on the append path is flushed at all — and that is not an exotic shape: it is what a store the CLI builds looks like, and it is the shape the gate's own device has. Measured, same device, same four writes, the host's copy of the device read while the guest is still hung, on #95: no control block — the log region holds its header and zeros where the entry should be, the fold returns the base store (records=2), and four writes were acknowledged. a formatted device — the entry is on the device, and folding it reproduces the userspace store exactly: records=6, fnv1a64=6b679d39597a62b3, byte for byte. The pre-18:41-style kernel keeps the entry in both shapes, because the entry's own fsync is what made it durable there. So the fix is not the revert: append now takes the entry's own fsync exactly when no later write in the same operation will carry one — one boolean, and the two branches are the two shapes above. The box's store is a formatted file with a control block, so it keeps the measured win (4.96 ms), and the bare shape pays its entry's flush, which is what it always did. The gate was wrong in the same way the diagnosis was, and is fixed with it: it ran its crash check over one device shape, and it now runs it over both — a store with no control block and a formatted one — folding each the way userspace reads it and comparing both against the same userspace store. An acknowledged write that a crash can lose is not a tuning decision, and each shape's branch is now gated. What is still not measured, and is said rather than implied: the box's own store is a file on ext4, not a block device in a VM. The mechanism the fix relies on there — the control write's fsync flushing the entry beside it in the same file — is the one the formatted-device case measures, and ext4's fsync flushes the inode's own dirty data, so the reasoning is one step from the evidence rather than two. Nobody has killed this machine mid-write to prove it. Two gates that accused the kernel of what the box was doing (2026-09-23) — both found in the same wall run, both fixed.verify-enum-live reported "the kernel's walk is missing records userspace can see (2 of them)" against the running #87, a walk that was answering correctly. The two lines were space boot and a boot:0,0,0 record. The gate translates the names its userspace walk prints into the space ids the kernel prints, and its table had root, keystore, portal and edges but not boot — the name the CLI gives the space the kernel's own boot record is written into (0xFC). An untranslated name can never match, so the gate reported a correct answer as a missing record. It surfaced the day that record was folded into the image, because before that it was only in the log and userspace's listing of the image alone did not show it. The kernel was never wrong: it returns fcfc…:0,0,0 flags=0x0080 [219B], which is exactly the record the name stands for. One line in the gate's table, and the gate passes. verify-selfdestruct reported "the rehearsal changed the host" — and the change was cube.service serving this machine's live store while the rehearsal ran. The gate fingerprinted every file under /var/lib/cubelinux byte for byte, the store the running system is writing included, so any write during the two minutes the rehearsal takes read as damage. It passed on the next run, with nothing writing, which is not a fact about the rehearsal. The fix is the distinction the check was missing: keys and other files are still compared byte for byte, and a store is compared as a store — it must still decode, report no digest errors, and hold no fewer records than it did. That is what damage looks like, and it is immune to its owner's own writes. The rule was tested against all eight cases it can see (unchanged, grown, shrunken, erroring, gone, unreadable, and both directions of a first appearance) before it was trusted. ## 9. What the future holds Said plainly, and separated into what is next, what is a decision, and what is not claimed: ### Next Done 2026-09-25 — the boot record's guarantee, and its epoch.As this record was written, both gaps were in the record rather than in the switch: ensure_boot_record() claimed the boot before it attempted, so one transient failure cost that boot its record silently; and the epoch was whatever the clock said at the first write, which on this machine arrives from a night powered off 40 s out (10h 27m on the boot before that). Both are now built. The claim is a bounded retry that counts attempts rather than a swap that cannot un-claim itself, and the record now carries its own account of its epoch: uptime from the monotonic clock, so boot − uptime is when the boot began whatever the wall clock was doing, and clock=raw|set saying whether the reading predates a correction. The kernel rewrites the record at the next write when it observes the wall clock move without the monotonic clock — a clock correction and nothing else. Gated by verify-boot-record, which now moves the guest's clock forward an hour mid-boot and requires the same coordinate to come back rewritten with the corrected time; measured: boot=1790308025 uptime=3 clock=raw then boot=1790311625 uptime=3 clock=set, exactly the hour the guest moved. Kernel #97. Put the name tier on the same footing. Names, documents and the namespace protocol are a view at the edge; the sampler and its client were brought into the tree today so that the whole stack is built, gated and archived together rather than half of it living in a side workspace. Meet the realtime constraint. The design was re-weighted once already by robotics — the first whitepaper's §4.5 records that a control loop bounds latency in a way a data workload never does — and that is the integration this work is aimed at: DULRobotics.com. Nothing in this record claims that constraint is met yet; it is the requirement the order of the work above is chosen to serve. ### Decisions, not open items The filesystem question is settled. The core interface is the coordinate syscall, not a mount; POSIX, where it is wanted, is an opt-in view at the edge — DESIGN-cube-interface §2 is titled "Why not a mountable filesystem". The write's durability is settled, and it is one fsync where a control block can carry it. A durable write is 4.96 ms measured on this metal, down from 8.2 ms, because e0218ec96 stopped flushing the log entry separately and let the count write — written next, to the same file — carry the flush for both. That was the trade this section used to reserve for the owner, and the owner's answer, on 2026-09-23, was to make it true rather than to take it back: the shape its sentence did not cover (a store with no control block, where the count write never happens and nothing on the append path was flushed at all) is fixed in #96, and an acknowledged write is now durable in both shapes, with the gate measuring both. The one fsync that remains is the price of the contract; group commit is how a future workload amortizes it across a batch, which makes it an optimization rather than a debt. The kill switch is built and rehearsed but deferred. Arming it is a terminal step the owner has put off to a later date, deliberately. ### Not claimed The root filesystem is not coordinate-addressed. The store is; the root fs on this machine is ordinary, and addressing the root as coordinates is a separate question. The store is not yet proven at scale beyond this box. The numbers here are one live store of ~71,600 records (71,586 measured on 2026-09-25; ~70,400 when this section was written) plus gated fixtures; nothing in this record is a claim about a larger deployment. The gate on the doorway is built (2026-09-25); what is not claimed is that everything goes through it. The dongle has a space of its own (0xF9 ‖ SHA-256(serial)), an identity record in it, and a portal in the portal space entered from this machine's root — all of which the kernel's walk and the userspace decoder both find on the device. The cube-edge design (note 124.207.150.253) named the missing gate as its highest-leverage unbuilt piece. It is now built: Portal::reaches asks both halves — standing on the near mouth and arriving in the space the caller named — and cube-command's Session with execute_gated refuses a cross-space command with NoPortal naming both ends, before the store is touched. A connection may say stand to give up the owner's reach, after which it can only touch what it stands in or holds a portal into; the daemon and the front-end both run clients through that path. What is still not claimed: the check is userspace's, so a caller that talks to the kernel's cube(2) directly is not gated by it; a client that never says stand keeps the reach its transport gave it, which for this machine's 0600 socket is the store's own process; and no agent path has been scoped with it yet. Nor is a device a space of this store: the kernel serves one store at a time, so the dongle's space and this machine's spaces have not yet been made one address space by anything but the naming convention. ## 10. Checking this record yourself Every claim above has a command behind it. On the machine that serves this site's store: cube-image digest /var/lib/cubelinux/store.img # version, records, errors cube-image store-info /var/lib/cubelinux/store.img # generation, active slot, log used kernel/run-all-gates.sh verify-enum-live.sh # the box's own store, walked cargo test --workspace --release # the workspace suite The source is public: the tree, the database work and the kernel are three repositories under cubelinux.com/git — see the terms and register for access. The kernel repository is where cube(2) and the store live; the build line above names the commits that changed its shape. (2026-10-07: the git host is offline while it is moved off the one-core testbed, so the repositories are not browsable at this address today; access is granted on request.) How to read this document. It records a state, not an intention: the milestones are dated, the numbers are quoted from commands, and the sections on what is ahead name what is not done. If a claim here is not backed by a gate, a test, or a command whose output is shown, treat it as unproven — that is the standard this record is written to.