Dezh OS v0.5-review

Release Notes

v0.5-review Candidate

The release where the second ISA stops being a demo target, and where a
secondary hart stops running a task uninterruptibly.

v0.4 shipped with STATUS.md saying the x86 kernel had "no returnable interrupt
path yet — no timer, no device IRQs, no scheduler on x86", and that tasks on
secondary RISC-V harts "run to completion — no preemption or migration there".
Both sentences are why this release exists.

x86_64: from a boot smoke to a kernel that does not trust its tasks

Sixteen commits, each green on both boot paths (QEMU -kernel PVH and the GRUB
Multiboot2 ISO):

• A returnable interrupt path. The IDT grows from 32 exception vectors to
  256, and vectors 32..255 save every register, dispatch, restore and iretq —
  an interrupt now interrupts work and hands control back, rather than ending it.
• Preemption. Three tasks that never yield, and none of them keeps the CPU.
• Per-task address spaces. Every task gets its own cr3 and reads a
  different page from the same address.
• Ring 3. A task runs at CPL3 with one door back into the kernel, and a
  faulting task dies without taking the machine with it.
• Authority derived from intent, not asserted by the caller. x86 had no
  capability check at all — its syscalls served anyone. A task now carries a
  capability word and the syscall path consults the task table, never a register
  the caller set. The derivation is granted = requested ∩ ceiling, computed by
  the same dezh_core::mcap function the RISC-V kernel calls, so a second
  implementation cannot drift from the exhaustive test that pins it. Two CPL3
  tasks run byte-identical code from a byte-identical manifest and end up with
  different authority.

RISC-V: W13 steps 1 and 2

• A secondary hart arms its own timer, so a U-mode task there is interrupted
  and resumed instead of owning the hart until it exits (smp-preempt). The
  demo counts ticks per hart and refuses to claim success if the task landed on
  the boot hart, which has preempted since W9.
• Idle secondary harts sleep. They used to spin, and on an emulated host
  every vCPU shares one budget — so they were taking it from the hart draining
  the console.
• One ticket lock for the whole kernel, which masks the acquiring hart's
  interrupts. Not a performance choice: plic_handle writes scheduler state
  from interrupt context, so without masking a hart can take the lock, take an
  interrupt, and wait for itself.
• The task table is private to the scheduler and its reachable surface is
  under that lock. Six modules used to read and write it directly.

The console stops losing pasted input

UART0 is IRQ 10 on the virt board and had never been enabled at the PLIC,
which routed only the virtio slots — so getc spun on the line-status register
and read the receive register directly. That keeps up with a person typing and
loses bytes to anything faster. It is routed now, with a receive ring both the
handler and getc drain into, and irq-stat reports bytes received plus the
two places a byte could be dropped.

Honest scope

• No migration. The timer interrupt on a secondary resumes the task it
  interrupted; it does not pick a different one, because choosing means reading
  a task table that is still the boot hart's. That is the rest of W13.
• x86 derives authority but does not account for effects. No Ahd token, no
  Sand ledger, no mission there. It has no device IRQs, no storage, no install
  path, and nothing frees a dead task's pages.
• Console input can still be lost, and it is not ours. Six runs sending 204
  bytes measured 204/202/200/188 received with zero drops at every layer, the
  shortfall matching the echoed line exactly each time. The guest is never handed
  those bytes. Single-run paste measurements on a host pipe are noise — the same
  configuration gave 0/10 and 10/10 minutes apart.
• The release workflow no longer publishes a container image. It never
  succeeded in publishing one; see RELEASING.

v0.4-review Candidate

The release where the effect ledger stops being checked against itself, and
where the kernel becomes something a stranger can actually read.

v0.3 could attribute and undo an agent's night — but every effect it attributed
lived inside Dezh's own storage. The ledger was the only witness to its own
claims. That is the gap this release closes.

What a reviewer can now do

• Run marz-effect <dest> <verb> <arg> and watch an effect leave the
  machine: authorized against a live NIC capability, egress authority for that
  named destination and the DIFC export rule, ARP-resolved, sent on the wire —
  and then the outcome comes back and is ledgered. It records
  compensatable and carries the undo itself, not just the class, so
  sfar-plan names the compensating action rather than promising one exists.
  The reply lowers operator integrity, because bytes off the wire are
  attacker-chosen.
• Check that claim without trusting us. tools/ci/effect_test.py runs twelve
  checks and none of them read Dezh's transcript — every assertion about
  external state is made against the external system itself, including that a
  revoked NIC capability leaves it untouched.
• Read the kernel. main.rs went from 8,776 lines to 724 plus 26 modules,
  across 23 commits that each stayed green.
• Type help and see all 151 commands. In v0.3 it silently listed 111: the
  Intent and Effects groups were missing from a hand-written list, so
  intent-open, sand-log, tbar, why-denied, overnight and redteam
  were absent from the first screen a reviewer reads. The list is now checked
  against the command table when the kernel is built.

The boundary, stated up front

The host gateway that performs the external effect is not in Dezh's TCB. A
compromised gateway can lie about what it did. Dezh proves the parts it owns —
authorized, left the machine, ledgered under an intent, compensation ran — and
not the gateway's honesty. That is a smaller claim than "the OS speaks git",
and it is the true one.

Honest scope

Everything named in the v0.3 notes that is still open stays open: no IOMMU, the
x86 kernel has no scheduler or drivers, Pol is a small syscall subset, the
console's own scheduler is single-hart, and in-flight capability clawback does
not exist. See STATUS.md, which now also lists the three W11 gaps
rather than rounding them away.

One correction to the v0.3 notes: they described intents as having no lease or
revocation. That had already stopped being true when lease-demo shipped, and
STATUS.md said so in one place while denying it in another. The contradiction is
fixed in favour of the accurate half.

v0.3-review Candidate

The milestone where the no-ambient-authority rule stops being a single-core,
single-threaded claim. Two bodies of work land here: an intent-to-effect runtime
that can undo an agent's night honestly, and the hardware work — real device
interrupts, symmetric multiprocessing, and a bidirectional network edge — that
tests whether the rule holds when the machine gets harder.

What a reviewer can now do

• Run overnight — leave a coding agent loose under one intent, then in the
  morning forecast the rollback, retract what is reversible, run and record a
  compensating action for what is compensatable, and watch the system refuse
  the irreversible rather than pretend. The agent's attempt to act outside its
  intent is denied by the kernel, and why-denied names the boundary.
• Boot under -smp 4 and watch U-mode tasks run on several harts at the same
  instant, each in its own address space — then watch an intruder page-fault
  and die on its own hart while its neighbour keeps running.
• Send a real ICMP echo to a destination the caller holds a capability for, and
  see the reply come back through ARP resolution — then watch consuming that
  reply lower integrity, so unvalidated network bytes cannot quietly become
  trusted state.
• Verify a signed .dzp: the Ed25519 envelope binds the authority the package
  asks for, and the kernel checks it.

Flagship demos

Everything from v0.2-review (F1 containment, F2 Cairn, F3 multi-ISA, F4 Pol)
still runs, joined by overnight, smp-sched, smp-isolate, marz-ping,
ingress-demo, taintflow-demo, redteam, sig-demo and lease-demo — all
green in tools/ci/qemu_smoke.py.

Honest scope

Three limitations named in the v0.2 notes are closed: runtime revocation,
package signing, and SMP. Still open, and stated plainly rather than buried:

• No IOMMU. User-space drivers buy fault isolation and least privilege of
  the driver process, not memory safety against a malicious driver that
  programs the device to DMA anywhere. This is core to the story, not polish.
• No formal verification, and no in-flight capability clawback — revocation
  is at the intent-lease and object-generation level, which is coarse but
  honest.
• Package signing has no distribution layer yet: no standalone signing CLI,
  no on-disk root-signed trust store.
• QEMU and VirtualBox targets only. Emulated benchmarks are labelled as such.

Full detail, including what reviewers should push on, in docs/STATUS.md.

Artifacts

RISC-V and x86_64 kernels, the bootable dezh-<tag>-x86_64.iso, a .dzp sample
package, a RUN.txt, the docs bundle, a manifest, and SHA256SUMS.

v0.2-review Candidate

The milestone where all four flagship demos are green in CI and a reviewer can
boot Dezh in a VM with no source tree.

What a reviewer can now do

• Boot the x86_64 kernel from a real bootable ISO in VirtualBox / VMware (or
  QEMU -cdrom); it reaches 64-bit long mode, installs and runs a .dzp agent
  package, enforces the print capability, and catches a deliberately-raised CPU
  exception instead of triple-faulting. S...

Dezh OS v0.4-review

Erratum on this release's artifacts. release-manifest.json carries a
container_image field naming ghcr.io/alisalimi77/dezh-review-env:v0.4-review.
That image does not exist. The release workflow's GHCR publish was refused
with denied: permission_denied: write_package, as it also was on v0.3, so no
tag of it has ever been published.

The field is left as-is rather than corrected in place because SHA256SUMS
covers the manifest, and quietly editing a hashed artifact is worse than a
wrong field with a note next to it.

Build the review environment locally instead:
docker build -f Dockerfile.review -t dezh-review-env .

The publish step has since been removed from the release workflow, and the
manifest no longer emits that field.

Release Notes

v0.4-review Candidate

The release where the effect ledger stops being checked against itself, and
where the kernel becomes something a stranger can actually read.

v0.3 could attribute and undo an agent's night — but every effect it attributed
lived inside Dezh's own storage. The ledger was the only witness to its own
claims. That is the gap this release closes.

What a reviewer can now do

• Run marz-effect <dest> <verb> <arg> and watch an effect leave the
  machine: authorized against a live NIC capability, egress authority for that
  named destination and the DIFC export rule, ARP-resolved, sent on the wire —
  and then the outcome comes back and is ledgered. It records
  compensatable and carries the undo itself, not just the class, so
  sfar-plan names the compensating action rather than promising one exists.
  The reply lowers operator integrity, because bytes off the wire are
  attacker-chosen.
• Check that claim without trusting us. tools/ci/effect_test.py runs twelve
  checks and none of them read Dezh's transcript — every assertion about
  external state is made against the external system itself, including that a
  revoked NIC capability leaves it untouched.
• Read the kernel. main.rs went from 8,776 lines to 724 plus 26 modules,
  across 23 commits that each stayed green.
• Type help and see all 151 commands. In v0.3 it silently listed 111: the
  Intent and Effects groups were missing from a hand-written list, so
  intent-open, sand-log, tbar, why-denied, overnight and redteam
  were absent from the first screen a reviewer reads. The list is now checked
  against the command table when the kernel is built.

The boundary, stated up front

The host gateway that performs the external effect is not in Dezh's TCB. A
compromised gateway can lie about what it did. Dezh proves the parts it owns —
authorized, left the machine, ledgered under an intent, compensation ran — and
not the gateway's honesty. That is a smaller claim than "the OS speaks git",
and it is the true one.

Honest scope

Everything named in the v0.3 notes that is still open stays open: no IOMMU, the
x86 kernel has no scheduler or drivers, Pol is a small syscall subset, the
console's own scheduler is single-hart, and in-flight capability clawback does
not exist. See STATUS.md, which now also lists the three W11 gaps
rather than rounding them away.

One correction to the v0.3 notes: they described intents as having no lease or
revocation. That had already stopped being true when lease-demo shipped, and
STATUS.md said so in one place while denying it in another. The contradiction is
fixed in favour of the accurate half.

v0.3-review Candidate

The milestone where the no-ambient-authority rule stops being a single-core,
single-threaded claim. Two bodies of work land here: an intent-to-effect runtime
that can undo an agent's night honestly, and the hardware work — real device
interrupts, symmetric multiprocessing, and a bidirectional network edge — that
tests whether the rule holds when the machine gets harder.

What a reviewer can now do

• Run overnight — leave a coding agent loose under one intent, then in the
  morning forecast the rollback, retract what is reversible, run and record a
  compensating action for what is compensatable, and watch the system refuse
  the irreversible rather than pretend. The agent's attempt to act outside its
  intent is denied by the kernel, and why-denied names the boundary.
• Boot under -smp 4 and watch U-mode tasks run on several harts at the same
  instant, each in its own address space — then watch an intruder page-fault
  and die on its own hart while its neighbour keeps running.
• Send a real ICMP echo to a destination the caller holds a capability for, and
  see the reply come back through ARP resolution — then watch consuming that
  reply lower integrity, so unvalidated network bytes cannot quietly become
  trusted state.
• Verify a signed .dzp: the Ed25519 envelope binds the authority the package
  asks for, and the kernel checks it.

Flagship demos

Everything from v0.2-review (F1 containment, F2 Cairn, F3 multi-ISA, F4 Pol)
still runs, joined by overnight, smp-sched, smp-isolate, marz-ping,
ingress-demo, taintflow-demo, redteam, sig-demo and lease-demo — all
green in tools/ci/qemu_smoke.py.

Honest scope

Three limitations named in the v0.2 notes are closed: runtime revocation,
package signing, and SMP. Still open, and stated plainly rather than buried:

• No IOMMU. User-space drivers buy fault isolation and least privilege of
  the driver process, not memory safety against a malicious driver that
  programs the device to DMA anywhere. This is core to the story, not polish.
• No formal verification, and no in-flight capability clawback — revocation
  is at the intent-lease and object-generation level, which is coarse but
  honest.
• Package signing has no distribution layer yet: no standalone signing CLI,
  no on-disk root-signed trust store.
• QEMU and VirtualBox targets only. Emulated benchmarks are labelled as such.

Full detail, including what reviewers should push on, in docs/STATUS.md.

Artifacts

RISC-V and x86_64 kernels, the bootable dezh-<tag>-x86_64.iso, a .dzp sample
package, a RUN.txt, the docs bundle, a manifest, and SHA256SUMS.

v0.2-review Candidate

The milestone where all four flagship demos are green in CI and a reviewer can
boot Dezh in a VM with no source tree.

What a reviewer can now do

• Boot the x86_64 kernel from a real bootable ISO in VirtualBox / VMware (or
  QEMU -cdrom); it reaches 64-bit long mode, installs and runs a .dzp agent
  package, enforces the print capability, and catches a deliberately-raised CPU
  exception instead of triple-faulting. See GETTING_STARTED.md#running-in-a-vm.
• Run the RISC-V capability console — agent containment (F1), Cairn versioned
  storage with rollback across reboot (F2), the same byte-identical Dezh-IR app
  on both ISAs (F3), and a real unmodified Linux ELF under Pol (F4).

Flagship demos

• F1 agent containment — narrow caps, kernel-DENIED beyond grant, attenuated
  IPC delegation, rollback (tools/demo/run_agent_demo.py).
• F2 Cairn v1 — commit log, rollback, reboot-persistent, capability-gated
  namespaces (cairn-demo).
• F3 multi-ISA — byte-identical .dzp runs on RISC-V and x86_64; bytes
  pinned by a test.
• F4 Pol — a stock static Linux/RISC-V ELF runs capability-gated; the same
  bytes run on real Linux; translation overhead measured (bench-pol).

Honest scope

QEMU/VirtualBox targets only; benchmarks that are emulated are labelled as such;
Pol is a small syscall subset; no runtime revocation, IOMMU, package signing, or
SMP yet. Full detail in docs/STATUS.md.

Artifacts

RISC-V and x86_64 kernels, the bootable dezh-<tag>-x86_64.iso, a .dzp sample
package, a RUN.txt, the docs bundle, a manifest, and SHA256SUMS.

v0.1-review Candidate

v0.1-review is the first public review candidate for Dezh OS.

It is intended for architecture, security-model, package-lifecycle, and
prototype-execution review. It is not a production release.

Highlights

• Bare-metal RISC-V QEMU boot through OpenSBI.
• x86_64 smoke target for the shared runtime path.
• U-mode task isolation with contained page faults.
• Explicit capability gates for syscall effects.
• Long-lived user-space virtio-block daemon.
• Typed IPC with status-aware replies and timeout accounting.
• Service registry with stop, restart, and controlled fault demos.
• Reboot-safe package store for SDK-built .dzp packages.
• Transactional install/remove/update/rollback path.
• Journal recovery, quarantine, pin/unpin, explicit GC, and capability
  escalation review.
• Embedded apps for note, lab, calculator, and vault workflows.
• Public demo transcripts and review tooling.

Validation

Recommended validation:

python tools/review/run_full_review.py --quick

Full validation:

python tools/review/run_full_review.py --full

Expected release artifacts are described in
Release Process. GitHub Packages usage is described in
Packages And Releases.

Known Limitations

• QEMU is the primary validation environment.
• The installer initializes a prototype disk layout, not production boot media.
• Package checksums are deterministic v0 checks, not production cryptographic
  signatures.
• DMA isolation is modeled through page-table discipline and grants; real IOMMU
  work is future scope.
• Store sizes and package limits are intentionally small for reviewability.
• Networking, graphics, formal verification, and real hardware bring-up are
  future work.

Review Questions

• Is the no-ambient-authority model visible in the code and tests?
• Is the user-space block driver boundary placed correctly?
• Are package lifecycle states and recovery rules sufficiently explicit?
• Are service failure modes clean enough for long-running operation?
• Which parts should be reduced, split, or for...

Dezh OS v0.3-review

Release Notes

v0.3-review Candidate

The milestone where the no-ambient-authority rule stops being a single-core,
single-threaded claim. Two bodies of work land here: an intent-to-effect runtime
that can undo an agent's night honestly, and the hardware work — real device
interrupts, symmetric multiprocessing, and a bidirectional network edge — that
tests whether the rule holds when the machine gets harder.

What a reviewer can now do

• Run overnight — leave a coding agent loose under one intent, then in the
  morning forecast the rollback, retract what is reversible, run and record a
  compensating action for what is compensatable, and watch the system refuse
  the irreversible rather than pretend. The agent's attempt to act outside its
  intent is denied by the kernel, and why-denied names the boundary.
• Boot under -smp 4 and watch U-mode tasks run on several harts at the same
  instant, each in its own address space — then watch an intruder page-fault
  and die on its own hart while its neighbour keeps running.
• Send a real ICMP echo to a destination the caller holds a capability for, and
  see the reply come back through ARP resolution — then watch consuming that
  reply lower integrity, so unvalidated network bytes cannot quietly become
  trusted state.
• Verify a signed .dzp: the Ed25519 envelope binds the authority the package
  asks for, and the kernel checks it.

Flagship demos

Everything from v0.2-review (F1 containment, F2 Cairn, F3 multi-ISA, F4 Pol)
still runs, joined by overnight, smp-sched, smp-isolate, marz-ping,
ingress-demo, taintflow-demo, redteam, sig-demo and lease-demo — all
green in tools/ci/qemu_smoke.py.

Honest scope

Three limitations named in the v0.2 notes are closed: runtime revocation,
package signing, and SMP. Still open, and stated plainly rather than buried:

• No IOMMU. User-space drivers buy fault isolation and least privilege of
  the driver process, not memory safety against a malicious driver that
  programs the device to DMA anywhere. This is core to the story, not polish.
• No formal verification, and no in-flight capability clawback — revocation
  is at the intent-lease and object-generation level, which is coarse but
  honest.
• Package signing has no distribution layer yet: no standalone signing CLI,
  no on-disk root-signed trust store.
• QEMU and VirtualBox targets only. Emulated benchmarks are labelled as such.

Full detail, including what reviewers should push on, in docs/STATUS.md.

Artifacts

RISC-V and x86_64 kernels, the bootable dezh-<tag>-x86_64.iso, a .dzp sample
package, a RUN.txt, the docs bundle, a manifest, and SHA256SUMS.

v0.2-review Candidate

The milestone where all four flagship demos are green in CI and a reviewer can
boot Dezh in a VM with no source tree.

What a reviewer can now do

• Boot the x86_64 kernel from a real bootable ISO in VirtualBox / VMware (or
  QEMU -cdrom); it reaches 64-bit long mode, installs and runs a .dzp agent
  package, enforces the print capability, and catches a deliberately-raised CPU
  exception instead of triple-faulting. See GETTING_STARTED.md#running-in-a-vm.
• Run the RISC-V capability console — agent containment (F1), Cairn versioned
  storage with rollback across reboot (F2), the same byte-identical Dezh-IR app
  on both ISAs (F3), and a real unmodified Linux ELF under Pol (F4).

Flagship demos

• F1 agent containment — narrow caps, kernel-DENIED beyond grant, attenuated
  IPC delegation, rollback (tools/demo/run_agent_demo.py).
• F2 Cairn v1 — commit log, rollback, reboot-persistent, capability-gated
  namespaces (cairn-demo).
• F3 multi-ISA — byte-identical .dzp runs on RISC-V and x86_64; bytes
  pinned by a test.
• F4 Pol — a stock static Linux/RISC-V ELF runs capability-gated; the same
  bytes run on real Linux; translation overhead measured (bench-pol).

Honest scope

QEMU/VirtualBox targets only; benchmarks that are emulated are labelled as such;
Pol is a small syscall subset; no runtime revocation, IOMMU, package signing, or
SMP yet. Full detail in docs/STATUS.md.

Artifacts

RISC-V and x86_64 kernels, the bootable dezh-<tag>-x86_64.iso, a .dzp sample
package, a RUN.txt, the docs bundle, a manifest, and SHA256SUMS.

v0.1-review Candidate

v0.1-review is the first public review candidate for Dezh OS.

It is intended for architecture, security-model, package-lifecycle, and
prototype-execution review. It is not a production release.

Highlights

• Bare-metal RISC-V QEMU boot through OpenSBI.
• x86_64 smoke target for the shared runtime path.
• U-mode task isolation with contained page faults.
• Explicit capability gates for syscall effects.
• Long-lived user-space virtio-block daemon.
• Typed IPC with status-aware replies and timeout accounting.
• Service registry with stop, restart, and controlled fault demos.
• Reboot-safe package store for SDK-built .dzp packages.
• Transactional install/remove/update/rollback path.
• Journal recovery, quarantine, pin/unpin, explicit GC, and capability
  escalation review.
• Embedded apps for note, lab, calculator, and vault workflows.
• Public demo transcripts and review tooling.

Validation

Recommended validation:

python tools/review/run_full_review.py --quick

Full validation:

python tools/review/run_full_review.py --full

Expected release artifacts are described in
Release Process. GitHub Packages usage is described in
Packages And Releases.

Known Limitations

• QEMU is the primary validation environment.
• The installer initializes a prototype disk layout, not production boot media.
• Package checksums are deterministic v0 checks, not production cryptographic
  signatures.
• DMA isolation is modeled through page-table discipline and grants; real IOMMU
  work is future scope.
• Store sizes and package limits are intentionally small for reviewability.
• Networking, graphics, formal verification, and real hardware bring-up are
  future work.

Review Questions

• Is the no-ambient-authority model visible in the code and tests?
• Is the user-space block driver boundary placed correctly?
• Are package lifecycle states and recovery rules sufficiently explicit?
• Are service failure modes clean enough for long-running operation?
• Which parts should be reduced, split, or formalized before the next review
  candidate?

Dezh OS v0.2-review

Release Notes

v0.2-review Candidate

The milestone where all four flagship demos are green in CI and a reviewer can
boot Dezh in a VM with no source tree.

What a reviewer can now do

• Boot the x86_64 kernel from a real bootable ISO in VirtualBox / VMware (or
  QEMU -cdrom); it reaches 64-bit long mode, installs and runs a .dzp agent
  package, enforces the print capability, and catches a deliberately-raised CPU
  exception instead of triple-faulting. See QUICKSTART_VM.md.
• Run the RISC-V capability console — agent containment (F1), Cairn versioned
  storage with rollback across reboot (F2), the same byte-identical Dezh-IR app
  on both ISAs (F3), and a real unmodified Linux ELF under Pol (F4).

Flagship demos

• F1 agent containment — narrow caps, kernel-DENIED beyond grant, attenuated
  IPC delegation, rollback (tools/demo/run_agent_demo.py).
• F2 Cairn v1 — commit log, rollback, reboot-persistent, capability-gated
  namespaces (cairn-demo).
• F3 multi-ISA — byte-identical .dzp runs on RISC-V and x86_64; bytes
  pinned by a test.
• F4 Pol — a stock static Linux/RISC-V ELF runs capability-gated; the same
  bytes run on real Linux; translation overhead measured (bench-pol).

Honest scope

QEMU/VirtualBox targets only; benchmarks that are emulated are labelled as such;
Pol is a small syscall subset; no runtime revocation, IOMMU, package signing, or
SMP yet. Full detail in docs/STATUS.md.

Artifacts

RISC-V and x86_64 kernels, the bootable dezh-<tag>-x86_64.iso, a .dzp sample
package, a RUN.txt, the docs bundle, a manifest, and SHA256SUMS.

v0.1-review Candidate

v0.1-review is the first public review candidate for Dezh OS.

It is intended for architecture, security-model, package-lifecycle, and
prototype-execution review. It is not a production release.

Highlights

• Bare-metal RISC-V QEMU boot through OpenSBI.
• x86_64 smoke target for the shared runtime path.
• U-mode task isolation with contained page faults.
• Explicit capability gates for syscall effects.
• Long-lived user-space virtio-block daemon.
• Typed IPC with status-aware replies and timeout accounting.
• Service registry with stop, restart, and controlled fault demos.
• Reboot-safe package store for SDK-built .dzp packages.
• Transactional install/remove/update/rollback path.
• Journal recovery, quarantine, pin/unpin, explicit GC, and capability
  escalation review.
• Embedded apps for note, lab, calculator, and vault workflows.
• Public demo transcripts and review tooling.

Validation

Recommended validation:

python tools/review/run_full_review.py --quick

Full validation:

python tools/review/run_full_review.py --full

Expected release artifacts are described in
Release Process. GitHub Packages usage is described in
Packages And Releases.

Known Limitations

• QEMU is the primary validation environment.
• The installer initializes a prototype disk layout, not production boot media.
• Package checksums are deterministic v0 checks, not production cryptographic
  signatures.
• DMA isolation is modeled through page-table discipline and grants; real IOMMU
  work is future scope.
• Store sizes and package limits are intentionally small for reviewability.
• Networking, graphics, formal verification, and real hardware bring-up are
  future work.

Review Questions

• Is the no-ambient-authority model visible in the code and tests?
• Is the user-space block driver boundary placed correctly?
• Are package lifecycle states and recovery rules sufficiently explicit?
• Are service failure modes clean enough for long-running operation?
• Which parts should be reduced, split, or formalized before the next review
  candidate?