Architecture Decisions
Relevant source files
ADRs record why major choices were made: status, context, decision, alternatives, consequences and supersession. An accepted ADR may name an implementation gap, but it is not an implementation manual or a substitute for the current architecture docs. In the repository’s authority order, accepted ADRs rank directly below the generated reference tables and above prose architecture docs.
| ADR | Title | Status | Date | One-line summary |
|---|---|---|---|---|
| 0001 | Runtime scheduling, preemption, interrupts and lock ordering | Accepted with implementation gap (reschedule IPI pending) | 2026-07-14 | Per-CPU run queues, bounded stealing, generation-checked waits, strict lock ranks, no logging in hot paths |
| 0002 | Kernel error policy | Accepted | 2026-07-14 | Errors classified by boundary; typed errors only; publish after fallible preparation or roll back |
| 0003 | Supported target and feature matrix | Accepted | 2026-07-14 | x86_64 QEMU supported; Pi 5 and RP2040 supported after HIL; virt and RISC-V experimental; signed-only production |
| 0004 | BPF JIT policy | Accepted | 2026-07-14 | v1.0 is interpreter-only; any future JIT needs a superseding ADR meeting six conditions |
Design documents follow a separate lifecycle under docs/design/: active/ (under discussion or implementation), accepted/ (reasoning retained after implementation), rejected/. At this release accepted/ and rejected/ contain only their README, and active/ holds one design document, v0.5-runtime-evolution.md, alongside its README.
Last updated on