Cross-Platform Parity — OS Atheism to Silicon Atheism

✅ Implemented Phases 1-2 complete. All 14 primals have platform-agnostic transport. 59 depot binaries across 4 architectures.

The Problem

15 primals run on Linux. Most assume Unix domain sockets, Unix signals, and POSIX filesystem semantics. This works on the build server. It does not work on Windows, macOS, iOS, WASM, or bare-metal embedded targets.

The ecosystem claims Silicon Deism — that hardware is a self-revealing substrate, not a platform to depend on. But if the code assumes Linux, that claim is aspirational, not operational. OS Atheism precedes Silicon Atheism: you cannot be agnostic about silicon if you are married to an operating system.

Six Phases

Phase 1: Platform Types (Shipped)

A type system that makes platform differences visible at compile time:

pub enum TargetOs { Linux, Windows, MacOs, Android, Ios, Wasm, FreeBsd }
pub enum CpuArch { X86_64, Aarch64, Riscv64, Wasm32 }
pub enum LinkModel { MuslStatic, Gnu, Msvc, Wasm }

pub struct Platform {
    pub os: TargetOs,
    pub arch: CpuArch,
    pub link: LinkModel,
}

Platform detection is compile-time via cfg attributes. No runtime overhead. Depot layout uses the platform triple as the directory key.

Phase 2: Transport + Signals (Complete — Wave 145a)

All 14 primals shipped platform-agnostic transport abstractions. The raw tokio::net::UnixStream calls that locked the ecosystem to Linux have been replaced with trait + backend patterns across every crate.

Reference implementation: 🎵🐦 Songbird — NamedPipeServer/ NamedPipeClient behind #[cfg(windows)], IpcStream batch across 9 crates.

Result: Windows depot went from 1 binary to 14. All 14 primals cross-compile for all 4 target architectures.

Phase 3: Shell-out + Filesystem

Three primals use platform-specific filesystem APIs:

Phase 4: Gate Bootstrap

The 13-phase NUCLEUS bootstrap pipeline assumes Linux systemd for service management. Phase 4 introduces platform branching: systemd on Linux, Windows Services on Windows, launchd on macOS.

Phase 5: Isomorphic Depot

Platform-aware fetch → install → launch cycle. The depot already serves multi-architecture binaries; Phase 5 makes the client automatically select the correct platform binary and install it appropriately for the local OS.

Phase 6: NUCLEUS Composition

The final phase: a NUCLEUS deploy graph is substrate-independent. The same deploy.toml describes the composition; the platform types determine how each primal is started, how IPC is routed, and how the lifecycle is managed.

Current Depot State

The depot serves 59 signed binaries across 4 architectures:

All binaries are BLAKE3 checksummed and Ed25519 signed. The VPS depot serves them over HTTPS. Phase 2 transport completion is what moved Windows from 1 binary to 14.

Failure Categories (Resolved)

The cross-platform parity audit identified 5 failure categories. Phase 2 resolved the first two, which accounted for 14 of 14 primals:

Each primal adopted trait + backend patterns rather than #[cfg] exclusion fences. The compile-time dispatch means zero runtime overhead.

Glacial Goal: Universal Substrate

Phase 1: Platform Types      → COMPLETE (Wave 142a)
Phase 2: Transport + Signals  → COMPLETE (Wave 145a) — 14/14 primals
Phase 3: Shell-out + FS       → unlocks macOS, FreeBSD
Phase 4: Gate Bootstrap        → isomorphic service management
Phase 5: Isomorphic Depot      → auto-deploy on any platform
Phase 6: NUCLEUS Composition   → substrate-independent deploy graphs

The glacial goal is Universal Substrate Evolution: NUCLEUS deploys on any architecture. Any substrate, any gate, same sovereign infrastructure. The same binary runs on a basement server, a VPS, a phone, a Raspberry Pi, and eventually a sovereign pallet in a cave entrance.

OS Atheism is preceded by Silicon Atheism in the philosophical argument, but precedes it in the engineering path. You earn the right to ignore the silicon by first proving you can ignore the operating system. Phase 2 is the highest leverage work remaining.