§4. Roadmap
planarian @ a924e09 · Spec v4.6 · snapshot main · all versions
Each phase ships something usable on its own. Later phases replace a backend; the contract does not change.
| Phase | Deliverable | Gate to exit |
|---|---|---|
| A · Contract on NixOS 26.05 | planariad: schema, state model (desired/observed/health/graph), policy, executor with hash-chained transaction journal and recovery watchdog, systemd and nixos-rebuild backends, change catalog, deterministic diagnoser and incident manager, intent matcher, ask CLI, read-only visual console, fault-injection gym with lifecycle cases. Attributed overrides and session-aware actors (§8, §11); security floor (§12e); failure-posture mechanism with the Standard posture (§12d); activation scheduling and quiet mode (§12f, §10); boot report (§10); signed external desired-state source and signed health report as hooks (§9, §10). Gym also runs non-gating against an Asterinas NixOS VM and a Firecracker microVM target (allowed to stay red; no engineering time beyond keeping them running). schema, policy, and the transaction kernel in the Verus subset. No model. | GA: (1) the demonstration: inject a fault → repaired; inject a bad configuration → reverted; kill planariad during activation → watchdog recovers; restart the daemon → it reconciles the journal and explains what happened accurately. (2) ≥ 60% of the catalog cleared deterministically; every bad generation reverted; the manifest-weakening fault rejected; zero gamed successes; unnecessary-intervention rate on the intent cases = 0; every posture and security-floor gym case passes. (3) policy proofs pass in CI. (4) Baselines reported: the invisibility budget (§21) and the verification ratio d:a with the trust count (§17a). |
| B · The model | Model service with residency rules (§20); boot-model fine-tune via distillation; summoned only on diagnoser exhaustion; evaluation suite with held-out fault families. Sandbox tier: dry-run and Firecracker-from-snapshot (§12g); a passing sandbox run is required for Tested changes where KVM is available. Non-human principals may hold catalog and model-catalog authority (§11). | GB: diagnoser + model clear ≥ Y% including held-out families; a worse model is rejected by the suite; no model load while Foreground holds; invisibility budget and d:a not degraded; the trust count not increased. |
| C · PlanarianOS | PlanarianOS: a NixOS distribution in which Planarian governs the machine from first boot (§9a), with three profiles: agent host, server / fleet node, personal. Installer selects profile and failure posture; all four postures (§12d); approval broker; snapshot backend; hardware inventory and explain; Flatpak as the user-scope app valve. The personal profile ships the COSMIC reference desktop and the console (a libcosmic app with approvals) as an optional frontend. Planarian also remains a standalone NixOS module and flake. Real users feed the gym. | GC: per-profile gates (§9a); ten external users for a month; every reported fault reproduced as a catalog entry; invisibility budget and d:a not degraded; the trust count not increased. |
| D · Rust system layer | Snix-based evaluator and store; Rust init and supervisor; Rust CoW filesystem. Linux kernel. Backend contracts revised from what A–C taught. | GD: no systemd, no C Nix; full catalog passes; d:a not degraded and the trust count not increased (§17a). |
| E · Asterinas | Kernel swap; reference-laptop drivers; Smithay desktop; secure attention key; Verus on the core. | GE: reference laptop boots, suspends, connects, plays audio, runs the desktop, survives the catalog from cold boot; d:a not degraded and the trust count not increased. |
| F · Acceleration | GPU drivers, model on GPU, COSMIC migration, second machine, ARM64. | GF: accelerated desktop and model on both machines; planner correct under injected accelerator failure. |
Firmware: binary vendor firmware is loaded as data by Rust drivers and is allowed permanently.
Part II — Specification for implementation
Normative unless marked draft. MUST/MUST NOT are requirements; SHOULD is a default the agent may deviate from with a logged reason in docs/deviations.md.