# RESUME — Cube as OS substrate (CZYX-call model)

Date: 2026-08-13  (session after RESUME-cubefs-daemon; Level A of item 3)

## Decision (user-directed)
"Everything writes as a CZYX call to the daemon — the cube-backed storage should
be coordinate calls, not writes to /cubefs. Why are we writing to cubefs?"

This REVERSES the earlier FUSE-path substrate design. Confirmed against
CUBELinux.pdf:
  - Phase 1: user-space Cube OS on Linux, using existing kernels + filesystems.
  - Phase 2: cubefs FUSE maps POSIX→CZYX for *testing semantics under real
    workloads* — explicitly a probe, not the substrate itself.
  - Phase 3: fork/extend kernel so VFS/accounting/LSM talk directly to the cube
    store; new syscalls expose cube-native ops ("open by CZYX + flags").
  - Package 3 (cubefs): "optional FUSE filesystem view so cube records appear as
    files/directories for existing tools." → FUSE is OPTIONAL, not the substrate.

So: the coordinate store IS the persistence. POSIX/FUSE is a convenience view.

## What changed
1. `cube-os-state.sh` / `cube-os-snapshot.sh` / `cube-os-klog.sh` rewritten to
   write via `cubec --socket /run/cube/cube.sock rawput/get` (CZYX calls), not
   `/cubefs/...`. hex encoding uses python3 (xxd is absent in the VM image).
   Coordinate layout (C=200):
     c200/z001/y001/x001  boot manifest (overwrite each boot)
     c200/z002/y001/x001  kernel boot line history (append)
     c200/z003/y001/x001  machine/identity record
     c200/z004/y001/x001  kernel log stream (klog appends lines)
     c200/z010/y001/xNNN operational snapshot body (rolling counter)
     c200/z010/y002/x001  rolling snapshot counter (persisted in cube, hex)
2. The three `cube-os-*` systemd units had `cubefs.service` REMOVED from
   Requires/After — they now depend ONLY on `cube-server.service`. A FUSE mount
   failure can no longer wedge OS bring-up.
3. `cubefs.service` hardened (ExecStartPre unmounts any stale mountpoint; BindsTo
   cube-server) so it survives a daemon restart instead of crash-looping on
   "Transport endpoint is not connected". This was the bug that broke the live
   VM at the start of this session.
4. build_vm.sh updated to match (inline script bodies + unit edges). A fresh
   bake now produces the CZYX-call substrate. NOT re-baked this session
   (heavy ~24G, off-peak per user policy).

## Verified live (VM localhost:2222)
- Boot manifest reads: "CUBELINUX-VM boot manifest v3 / backing-store:
  cube-server @ /run/cube/cube.sock (CZYX coordinate calls, no FUSE)".
- Snapshot #001 contains real OS state (running units, network, resources,
  journal) — not a demo.
- Manifest + snapshot survive `systemctl restart cube-server` (durable across
  daemon restart).
- `cube-os-state` + `cube-os-snapshot.timer` active; manual snapshot writes.

## Known gaps (honest)
- cubefs directory model: only `c<C>/z<Z>/y<Y>/x<X>` (x = fixed 3-digit leaf).
  Arbitrary POSIX filenames (syslog, wtmp) and nested dirs are NOT addressable.
  overlayfs on cubefs fails (EINVAL — missing RENAME_WHITEOUT/opaque-dir). So a
  *real OS tree* on the cube is blocked until cubefs grows nested-dir support
  (Level-B crate work).
- root fs / PID 1 (cube daemon as init, pivot_root into cubefs) = Phase 3 kernel
  work, image-bake, off-peak only.

## Items left (from earlier list)
1. / 2. → done in prior sessions.
3. Cube as OS substrate: Level A DONE (CZYX-call OS state, this session).
   Levels B (cube-backed block device) / C (rootfs+PID1) pending, not started.
4. society workspace: not started; git dubious ownership on
   /home/cubelinux/society (needs safe.directory).

## Key files
- /root/build_vm.sh  (authoritative bake template; all unit + script bodies live here)
- /home/CUBELinux/CUBELinux-2/STARTUP-README.md  (updated §4 + provisioning note)
- VM guest: /opt/cube/bin/cube-os-*.sh, /etc/systemd/system/cube-os-*.{service,timer}