# Roadmap and current status

Development reference and historical context. For current operating instructions, use the [user manual](../README.md). Acceptance applies only to the source and artifacts identified in each record.


[Documentation index](README.md) · [Master plan](master-plan.md) · [M0 evidence](m0-validation.md)

**M0–M12 software acceptance is complete. Physical Pi testing is deferred.**
The user has additionally authorized [Dasung base integration](dasung.md): an
imported daemon, ARM package, mandatory base selection, and s6 service sources.
M2 starts it under native s6 in a booted ARM virtual machine.
This is a sequence of acceptance milestones, not a release-date schedule.
The user authorized continued implementation through M12, deferring physical Pi
testing. Work proceeds in order with software/VM evidence recorded in the
[implementation ledger](implementation-status.md).

Current development additionally implements [workstation software cartridges
and QEMU hotplug tooling](workstation.md). Its [acceptance record](workstation-validation.md)
is separate from the frozen 0.1.0 artifacts below.

## Milestones and acceptance boundaries

| Milestone | Status | Deliverable and acceptance |
| --- | --- | --- |
| **M0 — Build host** | **Verified** | On x86_64 Arch, bootstrap the pinned Void build environment, cross-build an aarch64 glibc package, and build/inspect a static-musl Rust executable. See the recorded skips below. |
| **M1 — Base rootfs** | **Implemented** | `fds-base`, `fds-base-files`, and `out/rootfs-aarch64.tar` with glibc, GNU tools, XBPS and Dasung; no BusyBox, systemd, runit or musl runtime package. [Usage](rootfs.md) · [Evidence](m1-validation.md). |
| **M2 — Native s6** | **Verified in ARM VM** | Native s6 PID 1, read-only root, eudev/getty/Dasung supervision, test-service control, and orderly power-off. [Usage](init.md) · [Evidence](m2-validation.md). |
| M3 — FDS tooling foundations | Verified | Add shared Rust code and CLI/stage0 skeletons; verify static-musl AArch64 artifacts without a glibc runtime dependency. |
| M4 — Pi boot | Software verified; hardware deferred | Kernel/initramfs/SYSTEM/boot-volume builds and nine VM boot cases passed. The ordinary-user prompt follows in M5; physical NVMe/RP1/display acceptance is deferred. [Evidence](m4-validation.md). |
| M5 — Fast console | Software verified; physical timing deferred | Ordinary-user console, boot tracing and regression checks passed. [Evidence](m5-validation.md). Physical performance targets remain unmeasured. |
| M6 — Cartridge daemon | Software verified; physical calibration deferred | Handle events, configured 12-bay topology, metadata, mounting, and eject; virtual hotplug checks passed. Twelve-device stress follows in M11 and physical calibration remains deferred. |
| M7 — DATA integration | Software verified; physical media behavior deferred | Integrate data/home mounts and safe eject; leave the filesystem clean after sustained writes and ejection. |
| M8 — WindowMaker | Software verified; physical display deferred | Xorg/WindowMaker, grayscale theme, ENVIRONMENT activation, managed PROGRAMs and Ethernet passed virtual display/network tests. [Usage](desktop.md) · [Evidence](m8-validation.md). |
| M9 — Media tools | Software verified; physical media behavior deferred | ARM image creation, protected and confirmed writes, readback verification, and boot of a newly written SYSTEM passed. [Usage](media-tools.md) · [Evidence](m9-validation.md). |
| M10 — Shutdown | Software verified; physical timing/durability deferred | Ordered native halt/reboot, busy refusal, persistent DATA faults and independent filesystem checks passed. [Usage](power.md) · [Evidence](m10-validation.md). |
| M11 — Hardware stress | Software verified; physical tests deferred | Twelve-device cold/hotplug and I/O stress, native reboot/halt, readiness independence and six media failure cases passed. [Usage](stress-testing.md) · [Evidence](m11-validation.md). |
| M12 — Production hardening | Software verified; hardware deferred | Signed local FDS/OS 0.1.0, exact frozen inputs, two matching offline builds, recovery/internal settings, documentation and reversible EEPROM previews. [Final evidence](m12-validation.md#final-local-release-acceptance). |

Detailed requirements remain in sections 53–65 of the [master plan](master-plan.md).
The ledger distinguishes implemented software, remaining work, and tests that
still require physical hardware.

## What M0 completion means

The initial validation successfully ran `make bootstrap`, `make smoke-test`, and
`make check`. It produced and inspected an actual ARM glibc GNU hello package and
an actual static-musl ARM Rust executable. It also checked failure cases for ELF
validation, source pin drift, modified upstream files, and overlay conflicts.

It did **not** run the ARM program in QEMU, boot a Pi, test a physical bay map, or
measure boot/shutdown performance. QEMU was absent and was explicitly reported
as an optional skip. The later snapshot and offline-build work belongs to M12.
See [M0 validation](m0-validation.md) for the exact environment, outputs, and hashes.

## From native init to cartridge boot

M1 changes the output from isolated test artifacts to a base operating-system
filesystem. Its first result is a rootfs archive with an explicit package set
and exclusions. That archive alone will not establish native init or Pi boot;
those are M2 and M4 acceptance boundaries.

M2 now boots that filesystem with a generic ARM kernel and exercises native
s6 supervision. `make init-test` automates the acceptance test; `make vm` opens
a temporary development shell. Neither supplies a Pi boot image or measures
physical boot performance. M3 adds verified FDS Rust foundations;
[tooling usage](tooling.md) explains its commands. M4's [boot guide](boot.md)
covers the Pi kernel, initramfs, SYSTEM image, boot volume, and full stage0 tests.

## Find the current command interface

The master plan includes a design directory sketch as well as runtime commands.
The checkout now implements the complete build interface, cartridge inspection
and media management, and native power-off/reboot. A few script locations and
configuration formats differ from the original sketch; the
[implementation ledger](implementation-status.md#interface-and-policy-decisions)
maps those entries to the actual interfaces. Use [Development](development.md)
for targeted rebuilds and the project overview for the complete build/VM path.

Use `make help` to inspect the current build entry points. Follow
[Your first build](getting-started.md) for the complete usable workflow today.