ITISYOU_OS

System Roadmap

Milestones are sequenced by dependency, not calendar — this page carries no dates on purpose. A milestone is reached when its verification gates pass, never before. The latest release is v1.0.0. Everything after it is planned direction, not delivered work; the 2026-09-13 amendment that re-sequenced it is recorded in the roadmap document.

  1. MILESTONE V0.1

    Kernel Foundation

    VERIFIED

    Independently bootable x86_64 kernel in QEMU: serial diagnostics, physical + virtual memory, heap, exceptions/interrupts/timer, kernel tasks + scheduler, VFS/initramfs, interactive shell, automated boot/regression testing, reproducible builds.

    • COMPONENT_01

      Boot path (BIOS/UEFI via bootloader crate)

    • COMPONENT_02

      Memory management (PMM, paging, heap)

    • COMPONENT_03

      Interrupts, timer, scheduler, VFS, shell

  2. MILESTONE V0.2

    Userspace Foundation

    VERIFIED

    Ring 3 execution of real ELF64 programs, strict loader (W^X, window, overlap policy), syscall ABI (write/exit/yield/getpid), kernel/user MMU isolation, crash containment, clean process teardown.

    • COMPONENT_01

      Ring 3 + strict ELF64 loader (W^X)

    • COMPONENT_02

      Syscall ABI

    • COMPONENT_03

      Crash containment

  3. MILESTONE V0.3

    Process Isolation + Storage Foundation

    VERIFIED

    Per-process page tables with verified cross-process isolation; concurrent Ring 3 processes (cooperative), spawn/wait/exit; strict user-buffer validation; a minimal IPC channel; PCI enumeration; a block-device abstraction; a read-only NVMe driver.

    • COMPONENT_01

      Per-process address spaces

    • COMPONENT_02

      Concurrency + IPC

    • COMPONENT_03

      PCI, block device, NVMe (read)

  4. MILESTONE V0.4

    Preemptive Multitasking + Persistent Storage

    VERIFIED

    Timer-driven preemptive scheduling (non-yielding processes cannot monopolize; registers + address spaces preserved across preemption); NVMe write + flush; ITFS, a minimal persistent filesystem with double-buffered CRC-committed superblocks and verified reboot persistence.

    • COMPONENT_01

      Preemptive scheduler

    • COMPONENT_02

      NVMe write + flush

    • COMPONENT_03

      ITFS + reboot persistence

  5. MILESTONE V0.5

    Graphics + Input + Basic Desktop/Compositor

    VERIFIED

    A real graphical environment produced by the OS inside QEMU: a bootloader framebuffer with a back buffer + bitmap font; a window compositor with per-window backing stores and ownership/bounds isolation; GUI syscalls so Ring 3 renders a window with no direct framebuffer access; PS/2 keyboard (IRQ1) + mouse (IRQ12); and an interactive desktop that reacts to real input. Proven by in-kernel pixel read-backs and a QEMU-monitor input-injection test that screendumps the OS-rendered desktop.

    • COMPONENT_01

      Framebuffer + compositor (ownership-isolated windows)

    • COMPONENT_02

      GUI syscalls (Ring 3 rendering, no direct FB)

    • COMPONENT_03

      PS/2 keyboard + mouse; interactive desktop

  6. MILESTONE V0.6

    Hardware Expansion

    VERIFIED

    A generic device/driver model over an enriched PCI foundation (BAR sizing, capability-list walking with MSI/MSI-X/PCIe/PM detection); a USB UHCI host controller with full device enumeration over control transfers and verified HID keyboard input; an AC97 audio driver whose generated PCM samples are proven to traverse driver -> codec -> output (captured to a WAV); a unified input subsystem (PS/2 + USB HID behind one event stream, delivered to the GUI); and a devinfo syscall giving userspace device access without hardware authority. Drivers are polled, keeping the verified PIC timer/PS-2 interrupt path intact.

    • COMPONENT_01

      Device/driver model + PCI depth (BARs, capabilities)

    • COMPONENT_02

      USB UHCI + HID keyboard; AC97 audio (samples verified)

    • COMPONENT_03

      Unified input; userspace device access (least authority)

  7. MILESTONE V0.7

    System Platform

    VERIFIED

    A coherent platform over the kernel: an explicit capability model enforced default-deny at the syscall boundary (delegation only narrows - a child can never hold what its parent lacked); a traversal-proof filesystem sandbox; a service supervisor over ordinary Ring 3 processes (deterministic cycle-checked startup order, crash containment, bounded restart policy - no hidden privileged daemons); applications as SHA-256-verified ITPKG packages launched with manifest-requested capabilities only; atomic updates with rollback and reboot-proven recovery (an interrupted update can never activate); and an audit trail recording every privileged action and every denial. Future AI agents can only request through this same capability/policy/service path.

    • COMPONENT_01

      Capabilities: default deny, no amplification (adversarially proven)

    • COMPONENT_02

      Services, packages, atomic update/rollback/recovery

    • COMPONENT_03

      Sandboxing + audit/provenance trail

  8. MILESTONE V0.8

    Networking, Authenticity & Hardening

    VERIFIED

    The first milestone whose inputs come from somewhere other than this machine. An e1000 driver with polled descriptor rings; ARP, IPv4, ICMP echo (answered as well as sent), UDP and DNS; Ring 3 sockets behind a capability scoped to a port. Packages are now authenticated as well as integrity-checked: Ed25519 signatures over a context, the declared lengths and the content digest, against a compiled-in trust root - an unsigned package, one signed by a stranger and one with a forged signature are three DIFFERENT refusals. Userspace can write to the persistent store under the write right and its sandbox, with an overwrite that is one crash-atomic commit. The local APIC, I/O APIC and MSI-X are up with real delivery evidence, xHCI enumerates and reads HID input, the audit trail is hash-chained and survives reboots, and SMEP/SMAP/UMIP now enforce kernel/user separation in the CPU rather than only in the page tables. NOT delivered, and said so: TCP, IPv6 and DHCP. v0.8.1 closed the release out: its kernel now names the version the tag does, and the build fails if the two ever drift again.

    • COMPONENT_01

      e1000 + ARP/IPv4/ICMP/UDP/DNS; port-scoped socket capability

    • COMPONENT_02

      Ed25519 package signatures; userspace filesystem writes

    • COMPONENT_03

      APIC/MSI-X, xHCI, hash-chained persistent audit, SMEP/SMAP/UMIP

  9. MILESTONE V0.9

    Transport, Interrupt Cutover & Trust

    VERIFIED

    Released as v0.9.0. TCP from Ring 3: a host-tested RFC 9293 state machine with a retransmission timer and a receive window; programs connect and listen (one connection per listen) under a network capability scoped to the port; verified against the host operating system’s own TCP stack, including two deliberately dropped segments recovered by retransmission. A DHCP client, and IPv6 foundations: link-local and SLAAC addresses, neighbour discovery, ICMPv6 echo in both directions. ACPI table discovery and the I/O APIC cutover that retires the 8259 PIC, plus ACPI S5 power-off. A package-signing key hierarchy: only an offline root is compiled in, signing keys are trusted through root-signed certificates limited by package-name scope and a release-epoch validity window, a root-signed revocation list retires them, and the private keys stay outside the source tree. The audit head anchored with a witness off the audited disk, and guard pages under the kernel’s Ring 3 interrupt stack (RSP0) and double-fault stack, so an overflow of either faults instead of silently corrupting kernel data (not yet under the separate syscall stack — the one the TCP bug overflowed; found after the release, fix planned for V0.10). Also fixed on the way: a program’s sockets and connections are released on every exit path, broadcast UDP is checksummed against its real destination, and a zero-length copy never touches the user pointer — before that fix any program could panic the kernel with cap_list(NULL, 0). Stated limits: no TCP over IPv6 and no IPv6 sockets, no TCP congestion control beyond an in-flight cap, ACPI tables without an AML interpreter, and no guard pages yet for the syscall stack or heap-allocated kernel task stacks.

    • COMPONENT_01

      TCP from Ring 3 (connect + listen), DHCP, IPv6 foundations

    • COMPONENT_02

      ACPI + I/O APIC cutover (PIC retired), ACPI S5 power-off

    • COMPONENT_03

      Offline-root signing-key hierarchy; audit anchoring; kernel stack guards

  10. MILESTONE V0.10

    Userspace System

    VERIFIED

    Released as v0.10.0. Background programs keep running whatever the console is doing: bounded slices at audited safe points (the kernel stays non-preemptible), measured per command. A process tree — only a parent collects its child, non-blocking wait_nohang, sleep, orphans handed on, ps and kill. /sbin/init runs as pid 1, starts and supervises the services named in /etc/init.conf with exactly the capabilities the file gives them, reports them through a kernel-checked record, and is restarted by the kernel if it dies. Program arguments, a Ring 3 shell that borrows the console’s input, filesystem space reclamation, and persistent Ring 3 applications on the live desktop with click-to-focus and keys routed to the focused window. Found and fixed on the way, each shown against a negative control: a denial of service in every earlier release (the kernel wrote through user pages the program could not write), the syscall stack V0.9 left unguarded, Ring 3 DF/AC flags reaching kernel code, a mouse-packet framing bug, and an interrupt-unsafe input queue. Stated limits: no kernel preemption (non-schedulable regions are measured and listed), configuration only in the boot image, a shell without pipes or job control, one app per desktop session.

    • COMPONENT_01

      Always-on scheduler + process tree

    • COMPONENT_02

      /sbin/init from /etc/init.conf

    • COMPONENT_03

      Ring 3 shell; desktop apps with focus

  11. MILESTONE V0.11

    AI-Native System Layer

    VERIFIED

    Implemented and verified, and shipped as part of v1.0.0 (it was not tagged on its own). The agent has intelligence, not authority. The audit trail came first: three defects present since v0.8.0 were fixed before any agent code (a stored trail that read as TAMPERED once a later boot had saved it, a trail and package store that a program holding fs_write without a sandbox could rewrite, file names that could print forged kernel markers). Then the layer: a fixed, read-only view of the kernel’s own tables (sys_view, syscall 42), served only to a process the console grants a console-only capability; a small diagnostic model — three integer yes/no detectors trained at build time from SYNTHETIC scenarios and pinned by digest — whose held-out accuracy equals a one-rule baseline, so it shows the designed cases are separable, not that it diagnoses real machines; inferd, a Ring 3 service under /sbin/init that runs the model; one runbook per condition; and a diagnostic agent that can file proposals (propose, syscall 43) and do nothing else. The kernel checks every proposal against what it knows itself — the shipped model, the view it served that process, its own recomputation of the diagnosis, the system as it is now — and only the console can approve one. Two actions exist, both kernel code, each verified afterwards and rolled back if the check fails: resume-scheduler, and retry-service through a kernel→init mailbox (init_ctl, syscall 44). Process output can no longer drive the operator’s terminal. Stated limits: synthetic training data, three conditions and two actions, unauthenticated IPC (inferd’s answers are claims the kernel re-checks), proposals held only in memory.

    RELEASE // Shipped inside v1.0.0 (2026-09-14). The V0.11 AI-native layer was never tagged on its own — the CI window for a separate v0.11.0 did not open — so its work was folded into the V1.0 release. Every V0.11 requirement is implemented and verified with a negative control, and it is part of the downloadable v1.0.0 images.

    • COMPONENT_01

      Read-only system view; pinned diagnostic model; inferd in Ring 3

    • COMPONENT_02

      Diagnostic agent with runbooks; kernel-checked proposals

    • COMPONENT_03

      Console-only approval; kernel execution, verification, rollback

  12. MILESTONE V1.0 // CURRENT

    Experimental Personal OS

    VERIFIED

    Declared against acceptance criteria written in advance (docs/V1_ACCEPTANCE.md): reliability, security, recovery, update safety, boot safety and supported environment. Ships as reproducible, checksummed, downloadable UEFI and BIOS boot images for virtual machines; physical hardware is explicitly unsupported. On top of everything through V0.10 and the V0.11 AI-native layer, V1.0 is reliability and security: IPC authority scoped to named channels; a Ring 3 syscall fuzzer and a decoder mutation fuzzer that found and fixed real panics; long-use leak accounting; and a whole-attack-surface adversarial review — 37 findings, each checked by an independent refuter — that fixed every high-severity defect and 18 findings in all, with seven documented, accepted, fail-closed availability limits remaining. Verified by the full local QEMU matrix, two-clean-build reproducibility and boot-tests.

    RELEASE // Released as v1.0.0 (2026-09-14), locally verified. GitHub CI could not run — the repository is private with no Actions minutes — so this release carries no CI run id; it is verified by the full local gate (74 QEMU legs), two-clean-build bit-for-bit reproducibility, UEFI+BIOS boot-tests, and the adversarial review, and published with SHA-256 through the authenticated deploy path. The CI-dependent acceptance rows (V1-REL-001/002, V1-REP-004) are recorded BLOCKED on the CI window, none security-relevant; CI evidence will be stamped when the window opens.

    • COMPONENT_01

      Declared by criteria, never by calendar

    • COMPONENT_02

      Reproducible, checksummed VM boot images

    • COMPONENT_03

      Syscall + decoder fuzzing; whole-surface adversarial review

  13. MILESTONE Post-1.0

    Daily-Driver Research

    CONCEPT

    Moved after V1.0 by the 2026-09-13 amendment: Wi-Fi, Bluetooth, GPU acceleration, power management and suspend/resume need physical hardware that QEMU cannot stand in for, and physical hardware needs an explicit per-device authorization gate. A requirement that cannot be verified cannot gate V1.0.

    • COMPONENT_01

      Wi-Fi & Bluetooth

    • COMPONENT_02

      Power management, suspend/resume, SMP

    • COMPONENT_03

      Sacrificial-device hardware research only

Source: docs/ROADMAP.md — “Roadmap — no fabricated dates.”