Files
cubelinux/crates/cube-store-seal
luulu 8d3fab1dd1 the class crosses the socket, and the wrapper forwards both directions
`Reply` carries the record's class, so `CellGet` returns what `cell put flags=` wrote.
The JSON field is additive: a peer that does not send it reads as 0, which is what a
record written before the field existed means — the same answer rather than a wrong
one. `DaemonStore::get_flagged` takes it, so a remote store no longer answers "no
class" for a record that has one.

THE SEALING WRAPPER was the third instance of exactly that, and the front-end gate
found it: `SealedStore` forwarded `put_flagged` and then answered every read from the
trait's default. Worse, fixing `get_flagged` first was not enough — `entries_flagged`
and `range_flagged` were missing too, so a class survived a point read and vanished
from a listing. A wrapper has three read paths, not one, and the trait's default makes
each omission look like an answer.

So the trait now states the rule where it is implemented: a backend that stores masks
must override all three, the default's `flags: 0` is right only for a backend that
genuinely cannot carry one, and a *transport* that has no field for one produces the
same zero — so a backend of that second kind has to say so. `KernelStore` does: `get`
carries the class because `CUBE_OP_GET` fills it, and `entries`/`range` do not because
those frames have no field for it, which is why scanning a kernel store by class is
`CUBE_OP_FLAG_SCAN`'s job.

TWO GATE BUGS, both found while chasing that one. `verify-frontend` watched only
`cube-kernel/src` for changes, so an edit to `cube-store-seal` — exactly where the
class was being dropped — left the front-end binary stale and the gate testing the
previous behaviour: the gate whose own comment says "a stale front-end would test an
interface nobody has, which is how a green gate lies". It watches every crate now. And
it built its front-end-flavoured initramfs over the shared `initramfs.cpio.gz`, so a
gate was silently changing another gate's fixture; it builds to a path of its own.

`verify-flag-scan` now tells a boot that did not finish from a scan that answered
wrongly. That flake has now been seen three times, always inside a sweep and always
silent; two was a pattern, three is worth the distinction even before the cause.
2026-09-22 01:52:49 -04:00
..