Container & Storage Strategy

Michael ruling 2026-06-10 (interview, two decisions). Supersedes the implicit "Z2 mounts the Mac" arrangement, which is hereby deprecated.

The Inversion — Z2 is the Storage Master

Before this law: Z2 SSHFS-mounted the Mac (/opt/hinata-sandpit ← Mac Sandpit/hinata, /opt/hinata-vault ← Mac hinata-v2) and 31 systemd units executed on the Mac via ssh nnamdi@100.80.32.32. Mac asleep = BAU dead. That is the dependency inversion this law corrects: Z2 never breaks because its hard drive is its own local disk; the Mac becomes a client.

Plane	Master location	Mechanism
Data	/mnt/data/hinata (1.8T ext4, label hinata-data)	Full mirror of Mac Sandpit/hinata (rsync seeded 2026-06-10). Services read/write here. Mac mounts it back over NFS.
Code	Git (GitHub)	/opt/hinata-sandpit = clone of hinata-sandpit; refreshed by hinata-repo-sync.timer (5-min pull --ff-only). Scripts execute from the clone or from /mnt/data/hinata/scripts during transition.
Vault	Git — /opt/hinata-vault-bare (bare)	Mac origin carries two push URLs (GitHub + root@hinata-z2:/opt/hinata-vault-bare): every vault push lands on Z2 with no GitHub credential on the host. /opt/hinata-vault = local clone, pull-timer refreshed.
Secrets	Vaultwarden (CT103) + per-domain env	Runtime creds: /etc/hinata/*.env inside the owning CT (e.g. CT106 telegram.env). Host units read at send time via pct exec — never cached on host (pattern: hinata-alert.sh). Data-plane token caches (e.g. data/bulma/tokens_truelayer.json) live under /mnt/data/hinata with the service that rotates them.
Backups	/mnt/data/backups	vzdump of CTs + bare-repo bundles. GitHub is the off-site copy for both repos.

Path compatibility rule

Scripts anchor on Path.home()/Sandpit/hinata/.... Z2 carries the symlink /root/Sandpit/hinata → /mnt/data/hinata, so the same script resolves identically on Mac and Z2 with zero code rewrites. New scripts should prefer the HINATA_DATA env var (set per-unit) over home-anchored paths; the symlink exists for the migrated fleet.

Mac as client

• Mac mounts hinata-z2:/mnt/data/hinata via NFS for browsing/editing. Needs network (Tailscale) to see files — accepted trade-off in the ruling.
• NFS export is Tailscale-CIDR-gated only (100.64.0.0/10) per supreme-court/runtime/security-privacy-doctrine — no public ports. Hardening follow-up: replace all_squash → root anon-mapping with a dedicated uid.
• Mac-side Sandpit/hinata is retired only after a verification window (cutover task) — Apple-dependent scripts (FSEvents watchers, OneDrive, iCloud, LaunchAgents) move to the hinata-sandpit repo first per script-location doctrine.

Container Ruling

• Cross-container / cross-cutting services → jimmy-brain-ops, to be promoted from host directory (/opt/jimmy-brain-ops) to its own CT. Host keeps only: mounts, NFS export, pull timers, systemd timers, and pct-mediated alert relay.
• Commander-specific services → the commander's existing CT (mail-poller → CT102, NLP → CT101, audio → CT105, telegram → CT106, transcripts → CT107) or a new CT built for the service if none fits.
• Host-run timer units are transitional — each migrates into jimmy-brain-ops CT or a commander CT in phase 2/3.

Unit Execution Law

• No new unit may ExecStart via ssh to the Mac. The 31 legacy ssh-units migrate in tranches; tranche 1 (bulma cluster + weather) executed 2026-06-10.
• Every migrated unit carries OnFailure=hinata-alert@%n.service (Telegram via CT106).
• Apple-dependent work (FSEvents, OneDrive, iCloud, launchctl) stays on the Mac as LaunchAgents — that is the only sanctioned Mac execution class (supreme-court/runtime/hinata-architecture: Mac is workstation, not runtime dependency).

Naming correction

/opt/hinata-sandpit historically mounted Mac's Sandpit/hinata (not hinata-sandpit) — a standing trap. Post-inversion it is a true clone of the hinata-sandpit repo; the old data payload lives at /mnt/data/hinata.

Container-and-mount discipline (2026-06-14)

Michael ruling 2026-06-14 (verbatim): "nothing should be on root should be in dedicated container and mounts i think."

• No service writes to filesystem root. Every container's code, state, cursors, journals, and data live under its dedicated paths (/opt/[service]/ for code, /[service-name]/ bind for data) or under the canonical Z2 data tree /mnt/data/hinata/[service]/.
• Code and data separate. /opt/[service]/ holds executables only — no state, no journals, no archive content. State and data live under the bind-mounted data path (/mail-archive/, /transcripts/, etc.) which maps to a /mnt/data/hinata/[service]/ subtree on the host.
• State and journals are siblings of data, not orphans on root. Cursors land at [data-root]/_state/ and append-only journals at [data-root]/_journal/ — leading-underscore so they sort above content and never collide with content-namespace dirs.
• No new bind-mounts that surface at /. New container services declare bind targets explicitly under the existing data tree; no /data/, /scratch/, /tmp-archive/ at root level inside any container.
• Scope precedent: mail-poller consolidation (2026-06-14) is the first service hardened against this rule — see the-government/how_to_guides/how-to_mail-poller-consolidation-and-backpop § 0 for the canonical layout pattern.

Transition phases

Phase	Scope	State
1	Storage seed, symlink, zombie purge, bulma+weather tranche, NFS export, clone swap, pull timer	Executed 2026-06-10
2	Remaining ssh-units classified Apple-dep vs migratable; vault-writing units (inbox-clear, normalise-inbox, orochimaru-*) need write+push design; pilates-researcher migration + enable	Ledgered in tasks.json
3	jimmy-brain-ops CT build; commander-CT service placement; Mac Sandpit/hinata cutover after verification window; NFS anon-uid hardening	Ledgered in tasks.json

---

Cross-links: supreme-court/runtime/hinata-architecture · supreme-court/runtime/security-privacy-doctrine · supreme-court/runtime/infrastructure-access · supreme-court/runtime/credential-model