Update local plans, status docs, and governance notes

Ultraworked with [Sisyphus](https://github.com/code-yeongyu/oh-my-openagent) Co-authored-by: Sisyphus <clio-agent@sisyphuslabs.ai>
2026-04-18 17:58:38 +01:00
parent 8c3fac8e84
commit d4f6268854
22 changed files with 1411 additions and 697 deletions
@@ -13,8 +13,8 @@ Red Bear OS relates to Redox OS in the same way Ubuntu relates to Debian:

 Build flow:
 ```
-make all CONFIG_NAME=redbear-desktop
-  → mk/config.mk resolves to config/redbear-desktop.toml
+make all CONFIG_NAME=redbear-kde
+  → mk/config.mk resolves to config/redbear-kde.toml
  → Config includes desktop.toml (mainline) + Red Bear packages
  → repo cook builds all packages including our custom ones
  → mk/disk.mk creates harddrive.img with Red Bear branding
@@ -23,7 +23,7 @@ make all CONFIG_NAME=redbear-desktop
 Update flow:
 ```
 ./local/scripts/sync-upstream.sh          # Rebase onto upstream Redox + verify symlinks
-make all CONFIG_NAME=redbear-full          # Rebuild with latest
+make all CONFIG_NAME=redbear-kde           # Rebuild with latest
 ```

 ## TRACKING UPSTREAM (SYNC WITH REDOX OS)
@@ -163,9 +163,10 @@ redox-master/                  ← git pull updates mainline Redox
 │   ├── scripts/
 │   │   ├── sync-upstream.sh   ← Sync with upstream Redox OS
 │   │   ├── build-redbear.sh   ← Unified Red Bear OS build script
-│   │   ├── fetch-firmware.sh  ← Download AMD firmware
-│   │   ├── build-amd.sh       ← Legacy AMD-specific build (use build-redbear.sh)
-│   │   ├── test-amd-gpu.sh    ← AMD GPU test script
+│   │   ├── fetch-firmware.sh  ← Download bounded AMD or Intel firmware subsets from linux-firmware
+│   │   ├── test-drm-display-runtime.sh ← Shared bounded DRM/KMS display validation harness
+│   │   ├── test-amd-gpu.sh    ← AMD wrapper for the DRM display validation harness
+│   │   ├── test-intel-gpu.sh  ← Intel wrapper for the DRM display validation harness
 │   │   ├── test-baremetal.sh  ← Bare metal test script
 │   │   ├── build-redbear-wifictl-redox.sh ← Build redbear-wifictl for the Redox target with the repo toolchain
 │   │   ├── test-iwlwifi-driver-runtime.sh ← Bounded Intel driver lifecycle check inside a target runtime
@@ -187,8 +188,8 @@ redox-master/                  ← git pull updates mainline Redox
 ## HOW TO BUILD RED BEAR OS

 ```bash
-# Full desktop with GPU drivers + branding
-./local/scripts/build-redbear.sh redbear-desktop
+# Tracked KWin Wayland desktop target
+./local/scripts/build-redbear.sh redbear-kde

 # Minimal server variant
 ./local/scripts/build-redbear.sh redbear-minimal
@@ -207,7 +208,7 @@ redox-master/                  ← git pull updates mainline Redox
 ./local/scripts/test-phase1-desktop-substrate.sh --qemu redbear-wayland

 # Legacy Phase 3 runtime-substrate validation (historical P0-P6 numbering; script still works)
-./local/scripts/test-phase3-runtime-substrate.sh --qemu redbear-desktop
+./local/scripts/test-phase3-runtime-substrate.sh --qemu redbear-kde

 # Low-level controller validation
 ./local/scripts/test-xhci-irq-qemu.sh --check
@@ -259,7 +260,7 @@ redox-master/                  ← git pull updates mainline Redox
 redbear-netctl --help

 # Or manually:
-make all CONFIG_NAME=redbear-desktop
+make all CONFIG_NAME=redbear-kde

 # Single custom recipe:
 ./target/release/repo cook local/recipes/branding/redbear-release
@@ -286,7 +287,7 @@ When mainline updates affect our work:
 | Kernel | ACPI, scheme, memory API changes | `recipes/core/kernel/source/src/` |
 | relibc | New POSIX functions added upstream | `recipes/core/relibc/source/src/header/` |
 | Base drivers | Driver API changes | `recipes/core/base/source/drivers/` |
-| libdrm | DRM API updates | `recipes/wip/x11/libdrm/` or `recipes/libs/` |
+| libdrm | DRM API updates | `recipes/libs/libdrm/` or the current in-tree libdrm location |
 | Mesa | OpenGL/Vulkan backend changes | `recipes/libs/mesa/` |
 | Build system | Makefile/config changes | `mk/`, `src/` |
 | rsext4 | ext4 crate API changes | `local/recipes/core/ext4d/source/` Cargo.toml |
@@ -298,10 +299,18 @@ When mainline updates affect our work:
 - `docs/07-RED-BEAR-OS-IMPLEMENTATION-PLAN.md` is the canonical public execution plan.
 - `local/docs/CONSOLE-TO-KDE-DESKTOP-PLAN.md` (v2.0) is the canonical desktop path plan from console to
  hardware-accelerated KDE Plasma on Wayland, using a three-track Phase 1–5 model.
+- `local/docs/DRM-MODERNIZATION-EXECUTION-PLAN.md` is the current DRM-focused execution plan beneath
+  the canonical desktop path. It keeps Intel and AMD at the same evidence bar while separating
+  display/KMS maturity from render/3D maturity.
+- Older GPU-specific docs such as `local/docs/AMD-FIRST-INTEGRATION.md`,
+  `local/docs/P2-AMD-GPU-DISPLAY.md`, `local/docs/HARDWARE-3D-ASSESSMENT.md`, and
+  `local/docs/DMA-BUF-IMPROVEMENT-PLAN.md` remain useful reference material, but they are not the
+  planning authority when sequencing or acceptance criteria differ.
 - `local/docs/AMD-FIRST-INTEGRATION.md` remains the deeper AMD-specific technical roadmap, but AMD
  and Intel machines are now equal-priority Red Bear OS targets.
- `local/docs/PHASE-0-3-REASSESSMENT.md` is deprecated — its reconciliation role is now covered by the
-  updated CONSOLE-TO-KDE-DESKTOP-PLAN.md and docs/07.
+- The earlier Phase 0–3 reassessment bridge has been retired. Its reconciliation role is now
+  covered by `local/docs/CONSOLE-TO-KDE-DESKTOP-PLAN.md`,
+  `local/docs/DESKTOP-STACK-CURRENT-STATUS.md`, and `docs/07-RED-BEAR-OS-IMPLEMENTATION-PLAN.md`.
 - `local/docs/WIFI-IMPLEMENTATION-PLAN.md` is the current Wi-Fi architecture and rollout plan,
  including the bounded role of `linux-kpi` and the native wireless control-plane direction.
 - `local/docs/USB-IMPLEMENTATION-PLAN.md` and `local/docs/BLUETOOTH-IMPLEMENTATION-PLAN.md` should
@@ -470,9 +479,9 @@ local/Assets/
 |-------|--------|-----|
 | icon.png | Bootloader logo | Convert to BMP, embed via bootloader config |
 | icon.png | Desktop icon | Install to `/usr/share/icons/hicolor/` via redbear-release recipe |
-| icon.png | About dialog | COSMIC desktop reads from icon theme |
-| loading background.png | Boot splash | Convert to framebuffer-compatible format, display before orbital starts |
-| loading background.png | Login screen | Set as orblogin/orbital background |
+| icon.png | About dialog | Install through the active icon/theme surface |
+| loading background.png | Boot splash | Convert to framebuffer-compatible format, display during startup |
+| loading background.png | Login screen | Set as the display-session background |

 **Current status**: Assets are committed to git. Not yet integrated into the build — requires bootloader and display server integration (P2 hardware validation).

@@ -490,10 +499,11 @@ local/Assets/

 ```
 redbear-live.toml
-  └── redbear-desktop.toml
-        ├── redbear-legacy-base.toml   ← Neutralize broken base legacy init scripts
+  └── redbear-kde.toml
+        ├── redbear-legacy-base.toml     ← Neutralize broken base legacy init scripts
+        ├── redbear-legacy-desktop.toml  ← Neutralize broken desktop legacy init scripts
        ├── redbear-device-services.toml ← Shared firmware-loader / evdevd / udev service wiring
-        ├── redbear-netctl.toml        ← Shared Red Bear network profile files + netctl boot service
+        ├── redbear-netctl.toml          ← Shared Red Bear network profile files + netctl boot service
        ├── desktop.toml (mainline)
        │     ├── desktop-minimal.toml
        │     │     └── minimal.toml
@@ -513,7 +523,7 @@ redbear-live.toml
              in /etc/netctl and a boot-time `netctl --boot` service.
        NOTE: redbear-info is the canonical runtime integration report. Keep it updated when
              Red Bear adds new tools, schemes, services, or hardware integration paths.
-        NOTE: redbear-live inherits cub through redbear-desktop.toml.
+        NOTE: redbear-live inherits cub through redbear-kde.toml.
        NOTE: redbear-meta is explicitly included in redbear-full.toml. Keep any broader inclusion
              deliberate because its dependency surface is much heavier than the core utility layer.

@@ -526,7 +536,7 @@ redbear-full.toml

 redbear-wayland.toml
  └── wayland.toml (mainline-derived Wayland profile)
-  └── runtime surface: orbital-wayland → smallvil
+  └── bounded validation runtime surface
  └── validation entrypoints: test-phase4-wayland-qemu.sh + redbear-phase4-wayland-check

 redbear-kde.toml
@@ -549,9 +559,9 @@ redbear-minimal.toml
 Config comparison:
 | Config | GPU Stack | Desktop | Branding | ext4d | filesystem_size |
 |--------|-----------|---------|----------|-------|-----------------|
-| redbear-desktop | Full | COSMIC | Yes | ✅ (via desktop.toml) | 10240 MiB |
+| redbear-desktop | Full | Supplementary integration support | Yes | ✅ (via desktop.toml) | 10240 MiB |
 | redbear-minimal | None | None | Yes | ❌ | 512 MiB |
-| redbear-live | Full | COSMIC | Yes | ✅ (via desktop.toml) | 12288 MiB |
+| redbear-live | Full | KWin Wayland target | Yes | ✅ (via desktop.toml) | 12288 MiB |

 ## ANTI-PATTERNS (COMMIT POLICY)

@@ -6,14 +6,18 @@
 Status of ACPI fixes for AMD bare metal boot. Cross-referenced with
 `HARDWARE.md` crash reports and kernel/acpid source TODOs.

-P0 ACPI work is **complete**. Kernel patch is 574 lines, base/acpid patch is 558 lines.
+This file is the **historical P0 bring-up ledger**. The forward-looking ownership, robustness, and
+validation plan now lives in `local/docs/ACPI-IMPROVEMENT-PLAN.md`.
+
+P0 ACPI boot-baseline work is **materially complete**. Kernel patch is 574 lines, base/acpid patch
+is 558 lines.

 ## Crash Reports

 | Hardware | Symptom | Root Cause | Status |
 |----------|---------|------------|--------|
-| Framework Laptop 16 (AMD 7040) | Crash on boot | Unimplemented ACPI function (jackpot51/acpi#3) | ✅ Fixed (RSDP/SDT checksums, MADT NMI types, FADT parse) |
-| Lenovo ThinkCentre M83 | `Aml(NoCurrentOp)` panic at acpid acpi.rs:256 | AML interpreter encounters unsupported opcode | Under investigation (upstream AML issue) |
+| Framework Laptop 16 (AMD 7040) | Crash on boot | Unimplemented ACPI function (jackpot51/acpi#3) | ✅ Fixed (RSDP/SDT checksums, MADT NMI types, FADT parse, ACPI init typed errors) |
+| Lenovo ThinkCentre M83 | `Aml(NoCurrentOp)` panic at acpid acpi.rs:256 | AML interpreter encounters unsupported opcode | Under investigation (upstream AML issue; not resolved by P0 work) |
 | HP Compaq nc6120 | Crash after `kernel::acpi` prints APIC info | xAPIC APIC ID read returned raw value, caused page fault on Intel | ✅ Fixed (xAPIC `id()` now shifts `read(0x20) >> 24`) |

 ## Known Missing ACPI Table Parsers
@@ -42,11 +46,14 @@ access.
 | RSDT/XSDT | `acpi/rsdt.rs`, `acpi/xsdt.rs` | N/A | Root table pointer iteration + SDT checksum validation |
 | MADT (APIC) | `acpi/madt/` | N/A | xAPIC + x2APIC (type 0x9) + NMI (0x4, 0xA) + address override (0x5) |
 | HPET | `acpi/hpet.rs` | N/A | Assumes single HPET |
-| DMAR (Intel VT-d) | N/A | `acpi/dmar/` | Iterator bug fixed, re-enabled, safe on AMD (early return) |
+| DMAR (Intel VT-d) | N/A | `acpi/dmar/` (present, not wired) | DMAR table parsing present in `dmar/mod.rs` but not initialized at acpid startup; effectively owned by `iommu` daemon. Iterator bug fixed, re-enabled, safe on AMD (early return) |
 | FADT | N/A | `acpi.rs` | Full: PM1a/b CNT, reset register, `\_S5` sleep types, GenericAddress I/O |
 | Power Methods | N/A | `acpi.rs` | `\_PS0`/`\_PS3`/`\_PPC` AML evaluation for device power control |
 | SPCR | `acpi/spcr.rs` | N/A | ARM64 serial console |
 | GTDT | `acpi/gtdt.rs` | N/A | ARM64 timers |
+| Embedded Controller (EC) | N/A | `ec.rs` | Byte-wide and widened accesses (u16/u32/u64) via byte-transaction sequences; timeout on each byte |
+| AML Mutexes | N/A | `aml_physmem.rs` | Real tracked state with handle-based acquire/release; not a placeholder |
+| Shutdown via `kstop` | `scheme/acpi.rs` registers `/scheme/kernel.acpi/kstop` | `main.rs` opens kstop and subscribes via `RawEventQueue` | Kernel-to-userspace shutdown signal; `redbear-sessiond` listens on kstop for D-Bus `PrepareForShutdown` |

 ## ACPI MADT Entry Types

@@ -91,13 +98,14 @@ These are pre-existing upstream acpid issues. They are NOT part of the
 AMD-first P0/P1 scope. They exist in mainline Redox acpid and affect all
 platforms, not just AMD.

-| File | Line | TODO | Priority | Scope |
-|------|------|------|----------|-------|
-| `acpi.rs` | 266 | Use parsed tables for rest of acpid | Upstream | Mainline acpid improvement |
-| `acpi.rs` | 643 | Handle SLP_TYPb for sleep states | Upstream | Mainline power management |
-| `aml_physmem.rs` | 418,423,428 | Mutex create/acquire/release | Upstream | Mainline AML interpreter |
-| `ec.rs` | 193+ (8 occurrences) | Proper error types | Upstream | Mainline EC handler |
-| `dmar/mod.rs` | 7 | Move DMAR to separate driver | Upstream | Mainline driver refactor |
+| File | Line | TODO | Priority | Scope | Status |
+|------|------|------|----------|-------|--------|
+| `acpi.rs` | 266 | Use parsed tables for rest of acpid | Upstream | Mainline acpid improvement | Open |
+| `acpi.rs` | 643 | Handle SLP_TYPb for sleep states | Upstream | Mainline power management | Open (known gap) |
+| `aml_physmem.rs` | 418,423,428 | Mutex create/acquire/release | Upstream | Mainline AML interpreter | **Partially addressed** — real tracked state implemented, not placeholder |
+| `ec.rs` | 193+ (8 occurrences) | Proper error types | Upstream | Mainline EC handler | **Partially addressed** — widened accesses implemented via byte transactions |
+| `dmar/mod.rs` | 7 | Move DMAR to separate driver | Upstream | Mainline driver refactor | **Partially addressed** — DMAR module present but not wired into startup; effectively deferred to `iommu` daemon |
+| `main.rs` | — | Startup panic/expect handling | Local | Boot-path hardening | **Addressed** — typed `StartupError` enum with explicit error messages and clean exit paths |

 ## P0 Fixes Applied

@@ -129,10 +137,15 @@ platforms, not just AMD.
 |---|-----|-------------|
 | 1 | DMAR iterator fix | `type_bytes` renamed to `len_bytes` bug fix + `len < 4` guard |
 | 2 | DMAR init re-enabled | Safe on AMD (no DMAR table = early return, no crash) |
-| 3 | FADT shutdown | `acpi_shutdown()` using PM1a/PM1b CNT_BLK writes with `\_S5` sleep types |
-| 4 | FADT reboot | `acpi_reboot()` using ACPI reset register via GenericAddress |
-| 5 | Keyboard controller fallback | `Pio::<u8>::new(0x64).write(0xFE)` when reset_reg unavailable |
-| 6 | Power methods | `evaluate_acpi_method()`, `device_power_on()` (`\_PS0`), `device_power_off()` (`\_PS3`), `device_get_performance()` (`\_PPC`) |
-| 7 | GenericAddress rename | `GenericAddressStructure` renamed to `GenericAddress` with `is_empty()`, `write_u8()` |
-| 8 | Reboot wiring | `reboot_requested` flag in main.rs, scheme path detection |
-| 9 | ivrs/mcfg removed | Broken stub references eliminated (deferred to P2+, handled by pcid) |
+| 3 | DMAR not wired into acpid startup | DMAR module present in `dmar/mod.rs` but not imported or called from `main.rs`; effectively deferred to `iommu` daemon ownership |
+| 4 | FADT shutdown | `acpi_shutdown()` using PM1a/PM1b CNT_BLK writes with `\_S5` sleep types |
+| 5 | FADT reboot | `acpi_reboot()` using ACPI reset register via GenericAddress |
+| 6 | Keyboard controller fallback | `Pio::<u8>::new(0x64).write(0xFE)` when reset_reg unavailable |
+| 7 | Power methods | `evaluate_acpi_method()`, `device_power_on()` (`\_PS0`), `device_power_off()` (`\_PS3`), `device_get_performance()` (`\_PPC`) |
+| 8 | GenericAddress rename | `GenericAddressStructure` renamed to `GenericAddress` with `is_empty()`, `write_u8()` |
+| 9 | Reboot wiring | `reboot_requested` flag in main.rs, scheme path detection |
+| 10 | ivrs/mcfg removed | Broken stub references eliminated (deferred to P2+, handled by pcid) |
+| 11 | Typed startup errors | `StartupError` enum covers all startup failure paths; no `panic!` on firmware-origin paths; ACPI-absent causes clean `exit(0)` |
+| 12 | AML mutex real state | `AmlMutexState` with handle-based create/acquire/release; `FxHashMap<Handle, bool>` tracking; poisoned-state recovery |
+| 13 | EC widened accesses | `read_bytes`/`write_bytes` implement u16/u32/u64 via per-byte transactions; `ensure_access` bounds-checks against u8 addressable range |
+| 14 | kstop shutdown eventing | `main.rs` opens `/scheme/kernel.acpi/kstop` and subscribes via `RawEventQueue`; `redbear-sessiond` reads kstop and emits D-Bus `PrepareForShutdown` signal |
@@ -0,0 +1,587 @@
+# Red Bear OS ACPI Improvement Plan
+
+## Purpose
+
+This document turns the current ACPI assessment into a concrete execution plan.
+
+It does **not** replace `local/docs/ACPI-FIXES.md`. That file remains the historical record for the
+P0 bring-up work and the current table-by-table status snapshot. This document is the forward-looking
+plan for improving **completeness**, **robustness**, **ownership clarity**, **consumer integration**,
+and **validation quality**.
+
+The goal is not to treat ACPI as a generic checklist of table parsers. The goal is to make the Red
+Bear ACPI stack:
+
+- correct enough to survive bad firmware,
+- clear enough that ownership boundaries stay maintainable,
+- observable enough that failures are diagnosable,
+- and validated enough that "complete" means more than "boots on one machine".
+
+## Scope
+
+This plan covers the Red Bear ACPI stack and its direct dependency chain:
+
+- kernel ACPI discovery and early table handling,
+- `acpid` as the main ACPI/AML/FADT/DMI/power daemon,
+- `iommu` as the IVRS/AMD-Vi runtime owner,
+- `pcid` / `/config` as the MCFG replacement path,
+- DMI-backed quirks flowing through `acpid` and `redox-driver-sys`,
+- ACPI-consuming services such as `redbear-sessiond` and `redbear-info`.
+
+Primary focus is the current x86_64 path, because that is the active Red Bear hardware target and the
+area where the current implementation and validation debt is concentrated. ARM64 ACPI support remains
+in scope only where kernel ownership decisions or generic parser quality would affect it.
+
+## Evidence Model
+
+This plan uses five evidence buckets and does **not** treat them as equivalent:
+
+- **source-visible** — behavior is visible in the current checked-in source tree
+- **patch-carried** — behavior exists through `local/patches/*` rather than plain upstream source
+- **build-visible** — code compiles and stages successfully in the current build
+- **runtime-validated** — behavior has been exercised successfully in real boot/runtime paths
+- **negative-result-documented** — failure modes and platform gaps are recorded explicitly
+
+This matters because the current ACPI stack has already crossed the bring-up threshold, but still has
+meaningful gaps between **implemented**, **robust**, and **trusted**.
+
+## Ownership Model
+
+The long-term ownership split should be:
+
+- **Kernel ACPI** — minimum early discovery and unavoidable early platform setup
+- **`acpid`** — ACPI table serving, AML execution, FADT power/reboot logic, DMI exposure,
+  power-state exposure, ACPI table quirk filtering
+- **`iommu` daemon** — IVRS runtime parsing and AMD-Vi controller ownership
+- **future Intel IOMMU owner** — DMAR runtime handling, not `acpid`
+- **`pcid`** — PCI config space access replacing broken MCFG-in-acpid stubs
+- **consumers** — query ACPI-exposed services; do not parse ACPI firmware directly unless they are
+  the designated owner
+
+This ownership split is **not fully enforced today**. The plan below is designed to move the current
+tree from transitional ownership to explicit ownership without destabilizing the working bring-up
+path.
+
+## Current State Summary
+
+### What is strong today
+
+- Kernel RSDP/RSDT/XSDT/MADT handling exists and is sufficient for current boot bring-up.
+- `acpid` owns FADT parsing, AML integration, DMI exposure, and ACPI-backed power state exposure.
+- IVRS was correctly removed from the broken `acpid` stub path and moved to the `iommu` daemon.
+- MCFG ownership was correctly removed from `acpid` and replaced with the `pcid /config` path.
+- DMI-backed quirks are integrated through `/scheme/acpi/dmi` and `redox-driver-sys`.
+- `acpid` startup uses typed `StartupError` with explicit error messages and clean exit paths (Wave 1
+  boot-path hardening partially complete).
+- AML mutex state has real tracked implementation with handle-based acquire/release semantics in
+  `aml_physmem.rs` (Wave 2 AML mutex work partially complete).
+- EC access width is handled via `read_bytes`/`write_bytes` byte-transaction sequences for u16/u32/u64
+  accesses (Wave 2 EC width work partially complete).
+- DMAR table parsing module exists in `acpid` but is not wired into the startup path; DMAR ownership
+  is effectively deferred to the `iommu` daemon (Wave 3 DMAR separation partially complete).
+- Shutdown eventing uses `/scheme/kernel.acpi/kstop` as the kernel-to-userspace shutdown signal;
+  `redbear-sessiond` listens on this path for `PrepareForShutdown` D-Bus signals.
+- Kernel registers the `kstop` scheme at boot and ACPI subsystem shutdown uses PM1a/PM1b CNT writes
+  with `\_S5` sleep types.
+
+### What is still weak today
+
+- Sleep state transitions (`\_Sx` methods beyond `\_S5`) and sleep eventing remain unsupported; there is
+  no `/scheme/acpi/sleep` or event-driven sleep contract.
+- AML opregion error propagation still has some silent failure paths; not all correctness-critical
+  reads return error to caller.
+- `AmlSymbols` initialization order is still tied to PCI FD registration timing; AML initialization
+  is not fully deterministic.
+- `SLP_TYPb` handling remains unimplemented for sleep states beyond `\_S5`.
+- DMAR table parsing module is present but unused; the module itself has not been removed, creating
+  latent confusion about ownership.
+- Docs still risk equating "implemented" with "validated" without explicit evidence qualification.
+
+### Honest status statement
+
+Red Bear ACPI is **materially complete for the historical P0 boot goal**, but it is **not yet complete
+for robustness, ownership cleanliness, sleep state support, or broad platform confidence**. Sleep
+state eventing is a known gap. The shutdown eventing contract via `kstop` is implemented but only
+validated in QEMU; bare-metal validation is still outstanding.
+
+## Canonical Related Documents
+
+Read these alongside this plan:
+
+- `local/docs/ACPI-FIXES.md` — current status ledger and historical P0 fixes
+- `local/docs/IRQ-AND-LOWLEVEL-CONTROLLERS-ENHANCEMENT-PLAN.md` — controller-level validation and
+  quality context
+- `local/docs/IOMMU-SPEC-REFERENCE.md` — IVRS/DMAR technical reference
+- `local/docs/QUIRKS-SYSTEM.md` — DMI-backed quirks and ACPI table blacklist behavior
+- `local/docs/AMD-FIRST-INTEGRATION.md` — historical AMD-first framing and hardware context
+- `local/docs/BAREMETAL-LOG.md` — real-machine failure notes and negative results
+
+## Work Classification
+
+Every task in this plan is tagged by its main purpose:
+
+- **Completeness** — functionality exists but is still missing or partial
+- **Robustness** — behavior exists but is too fragile under bad firmware or runtime stress
+- **Quality** — ownership, observability, maintainability, or docs are below target
+
+## Wave 0 — Contracts, truthfulness, and degraded-mode policy
+
+### Goal
+
+Stop treating ACPI as a loose cluster of working code and instead define:
+
+1. who owns what,
+2. which failures are fatal versus degradable,
+3. and what status words in the docs actually mean.
+
+### Why this wave is first
+
+Without an explicit contract, later hardening work turns into hidden rewrites and docs drift.
+
+### Scope
+
+- `local/docs/ACPI-FIXES.md`
+- `local/docs/IRQ-AND-LOWLEVEL-CONTROLLERS-ENHANCEMENT-PLAN.md`
+- this file
+- related references in `README.md`, `docs/02-GAP-ANALYSIS.md`, and `AGENTS.md` if needed
+
+### Status: Wave 0 execution partially complete
+
+Tasks 0.1, 0.2, and 0.3 are partially executed in this documentation pass. The degraded-mode matrix
+and normalized vocabulary are new in this pass. Ownership boundaries are partially documented below;
+the canonical statement still lives in `local/docs/ACPI-FIXES.md`.
+
+### Vocabulary normalization (Task 0.2 — partially executed)
+
+Replace ambiguous wording such as "complete" with one of:
+
+- **implemented** — behavior exists in the current source tree
+- **validated in QEMU** — behavior has been exercised in QEMU/OVMF but not on real hardware
+- **validated on bounded real hardware** — behavior verified on specific hardware that was tested
+- **still transitional** — behavior exists but ownership or robustness is not yet clean
+- **known gap** — functionality is absent or broken; the gap is documented
+
+### ACPI degraded-mode matrix (Task 0.1 — new)
+
+This matrix documents the expected system behavior for ACPI failure cases. All entries reflect
+implemented behavior visible in the current source tree.
+
+| Condition | Kernel behavior | Userspace (`acpid`) behavior | Session impact |
+|-----------|----------------|----------------------------|----------------|
+| Bad RSDP checksum | Warns, continues with best-effort RSDP parse | No ACPI init if RSDT/XSDT unreadable; exits cleanly | No ACPI services |
+| Bad SDT checksum | Logs warning per table, continues | Table skipped; other tables still served | Reduced ACPI surface |
+| Truncated FADT | FADT fields fall back to zero defaults | Uses zero defaults for PM registers; `acpi_shutdown` may not fire | Shutdown may fall back to keyboard controller |
+| Truncated DMAR | N/A (DMAR not used by kernel) | Logs error, continues without DMAR; `iommu` daemon not started | No Intel IOMMU via DMAR |
+| Truncated IVRS | N/A (IVRS not used by kernel) | No effect on `acpid` (IVRS owned by `iommu` daemon) | No AMD-Vi via IVRS |
+| AML interpreter init failure | N/A | `acpid` exits with typed error; no ACPI scheme | No AML, no power methods |
+| EC timeout | N/A | Returns `AmlError::MutexAcquireTimeout` to AML interpreter | AML opregion access fails gracefully |
+| EC unsupported width access | N/A | Wider accesses split into byte transactions via `read_bytes`/`write_bytes` | Works on byte-access ECs only |
+| Missing DMAR on Intel | N/A | `acpid` logs DMAR absent; `iommu` daemon not started | No Intel VT-d |
+| Missing IVRS on AMD | N/A | No effect (IVRS owned by `iommu` daemon) | No AMD-Vi |
+| Missing `\_S5` sleep types | N/A | `acpi_shutdown` logs error and returns without writing PM registers | Shutdown may fall back to keyboard controller |
+| Missing `/scheme/kernel.acpi/kstop` | Kernel does not register kstop scheme | `acpid` exits with error on startup | No kernel-orchestrated shutdown |
+| Sleep state transition (`\_Sx`) | N/A | Not implemented; no event-driven sleep contract | Sleep states not available |
+| `redbear-sessiond` shutdown watcher | Kernel signals `kstop` on shutdown | `acpi_watcher.rs` reads kstop and emits D-Bus `PrepareForShutdown` | Login1 session manager informed |
+
+### Ownership boundaries (Task 0.3 — partially documented)
+
+This section documents the current ownership split as visible in the source tree. Items marked
+**transitional** indicate the ownership boundary is not yet fully enforced by code.
+
+| Component | Owner | Status |
+|-----------|-------|--------|
+| Early table discovery (RSDP, RSDT, XSDT) | Kernel | implemented |
+| MADT, HPET, SPCR, GTDT parsing | Kernel | implemented |
+| FADT parsing, `\_S5` sleep types, PM registers | `acpid` | implemented |
+| AML interpreter initialization and execution | `acpid` | implemented |
+| EC access (byte-wide and widened via byte transactions) | `acpid` | implemented |
+| AML mutex state tracking | `acpid` (`aml_physmem.rs`) | implemented (real tracked state, not placeholder) |
+| FADT shutdown/reboot via PM1a/PM1b CNT | `acpid` | implemented |
+| Keyboard controller fallback reboot | `acpid` | implemented |
+| DMAR table parsing | `acpid` (module present) | **transitional** — module not wired; effectively owned by `iommu` daemon |
+| IVRS ownership | `iommu` daemon | implemented |
+| MCFG/PCI config space | `pcid` `/config` endpoint | implemented |
+| DMI exposure and quirks | `acpid` via `/scheme/acpi/dmi` | implemented |
+| Power methods (`\_PS0`/`\_PS3`/`\_PPC`) | `acpid` | implemented |
+| Sleep state transitions (`\_Sx` beyond `\_S5`) | none | **known gap** |
+| Sleep eventing | none | **known gap** |
+| Shutdown event via `kstop` | Kernel + `acpid` + `redbear-sessiond` | implemented (QEMU-validated; bare-metal validation outstanding) |
+| DMAR runtime ownership (Intel VT-d) | `iommu` daemon | **transitional** — not yet fully separated from `acpid` DMAR module |
+
+### Acceptance criteria
+
+- one canonical ownership statement exists — **partially met** (this table, plus `ACPI-FIXES.md`)
+- one degraded-mode matrix exists — **met** (this pass)
+- all high-level ACPI status claims use the same vocabulary — **partially met** (normalized in this pass)
+
+### Validation
+
+- doc review only,
+- no code changes required for vocabulary and matrix,
+- Wave 0 should be treated as ongoing; new evidence may require matrix updates
+
+## Wave 1 — Boot-path hardening and parser strictness
+
+### Goal
+
+Remove catastrophic or silent failure behavior from the boot-critical ACPI path.
+
+### Main files
+
+- `recipes/core/base/source/drivers/acpid/src/main.rs`
+- `recipes/core/base/source/drivers/acpid/src/acpi.rs`
+- `recipes/core/base/source/drivers/acpid/src/scheme.rs`
+- `recipes/core/kernel/source/src/acpi/mod.rs`
+- kernel ACPI submodules for RSDP/RSDT/XSDT/MADT/HPET/SPCR/GTDT
+
+### Status: Task 1.1 partially executed
+
+`acpid` main.rs now uses a typed `StartupError` enum covering:
+
+- `ReadRootTable` — failed to read `/scheme/kernel.acpi/rxsdt`
+- `ParseRootTable` — failed to parse `[R|X]SDT`
+- `UnexpectedRootTableSignature` — wrong root table signature
+- `MalformedRootTableEntries` — malformed entry area
+- `InitializeAcpi` — failed ACPI context init
+- port I/O rights acquisition failure
+- shutdown pipe open failure (`/scheme/kernel.acpi/kstop`)
+- event queue creation failure
+- scheme socket creation failure
+- event queue subscription failure
+- scheme registration failure
+
+Each failure path logs a human-readable error and calls `std::process::exit(1)`. No `panic!`
+remains on these paths. Empty RSDT (no ACPI) causes a clean `exit(0)` after `daemon.ready()`.
+
+Tasks 1.2 and 1.3 remain open.
+
+### Tasks
+
+#### Task 1.1 — Replace panic-grade startup failures in `acpid` — **partially done**
+
+Typed `StartupError` enum is implemented in `main.rs`. The following failure classes are now handled:
+
+- hard fail with typed error message and exit code 1,
+- soft fail with degraded behavior (ACPI absent → clean exit 0),
+- or early clean exit when `/scheme/kernel.acpi/rxsdt` is empty.
+
+#### Task 1.2 — Make table rejection policy explicit — **open**
+
+For kernel and `acpid` table use, define when a bad length/checksum/revision:
+
+- is logged and ignored,
+- is logged and downgraded,
+- or is fatal.
+
+This policy must be table-specific, not one global "warn and continue" convention.
+
+#### Task 1.3 — Improve parser observability — **open**
+
+Every accepted or rejected table should leave enough evidence to reconstruct why:
+
+- table signature,
+- physical address if known,
+- length/revision/checksum status,
+- consumer that requested it,
+- fallback path chosen.
+
+### Acceptance criteria
+
+- no `panic!/expect()` remains on firmware-origin or optional-service startup paths in `acpid` — **partially met** (Tasks 1.2 and 1.3 still open),
+- malformed-table decisions are deterministic and documented — **open**,
+- degraded boot still succeeds in all cases classified as degradable by Wave 0 — **open**.
+
+### Validation
+
+- negative tests for malformed checksums and table lengths,
+- QEMU validation with intentionally damaged tables if feasible,
+- one AMD and one Intel bounded hardware boot recheck,
+- evidence captured in `local/docs/BAREMETAL-LOG.md` or a successor log.
+
+## Wave 2 — AML, opregions, EC, and power-state correctness
+
+### Goal
+
+Close the biggest runtime-correctness gaps in the ACPI stack.
+
+### Main files
+
+- `recipes/core/base/source/drivers/acpid/src/acpi.rs`
+- `recipes/core/base/source/drivers/acpid/src/aml_physmem.rs`
+- `recipes/core/base/source/drivers/acpid/src/ec.rs`
+
+### Status: Tasks 2.1, 2.2, and 2.5 partially executed
+
+#### Task 2.1 — Remove placeholder AML mutex behavior — **partially done**
+
+`AmlMutexState` in `aml_physmem.rs` implements real tracked state:
+
+- `AmlMutexState::create_handle()` generates unique handles via incrementing `next_handle`
+- `AmlMutexState::states` is a `FxHashMap<Handle, bool>` tracking locked/unlocked state
+- `lock_aml_mutexes()` wraps the state map with proper `Mutex` guard and poisoned-state recovery
+- The `acquire()` method looks up the handle in the map, sets it to `true` on success, and returns
+  `AmlError::MutexAcquireTimeout` on timeout or unknown handle
+
+This is no longer a placeholder implementation. Remaining work: timeout semantics documentation
+and concurrent acquire/release stress testing.
+
+#### Task 2.2 — Eliminate silent zero-on-failure physical reads — **partially done**
+
+EC reads via `read_bytes` now propagate `AmlError::MutexAcquireTimeout` on EC timeout rather than
+returning zero. Kernel-physmem reads still have some silent failure paths; this task is not fully
+closed.
+
+#### Task 2.5 — Decide and validate EC width behavior — **partially done**
+
+`ec.rs` now implements `read_u16`, `read_u32`, `read_u64`, `write_u16`, `write_u32`, and `write_u64`
+on `Ec` via byte-transaction sequences in `read_bytes`/`write_bytes`:
+
+- `ensure_access()` validates the access fits in a u8 addressable range
+- `read_bytes<const N: usize>` loops over individual byte reads with timeout per byte
+- `write_bytes()` loops over individual byte writes with timeout per byte
+
+Wider accesses are emulated through byte transactions rather than being rejected. This is implemented
+behavior, not a placeholder. Validation on real EC hardware remains outstanding.
+
+### Tasks still open
+
+#### Task 2.3 — Finish `AmlSymbols` initialization contract — **open**
+
+`AmlSymbols` initialization order is still tied to PCI FD registration timing. AML initialization
+is not fully deterministic. The upstream TODO to "use these parsed tables for the rest of acpid"
+remains.
+
+#### Task 2.4 — Fix power-state completeness gaps — **open**
+
+`SLP_TYPb` handling remains unimplemented. Sleep state transitions beyond `\_S5` are not supported.
+Sleep eventing is not implemented. These are documented as known gaps.
+
+### Acceptance criteria
+
+- AML synchronization is no longer placeholder-driven — **partially met** (2.1 done; 2.3 open),
+- physmem failures do not silently fabricate correctness-critical values — **partially met** (EC done; kernel-physmem still open),
+- AML initialization order is reproducible and documented — **open** (Task 2.3),
+- sleep-state handling is explicit for both implemented and out-of-scope states — **open** (Task 2.4),
+- EC behavior is either implemented or honestly bounded — **met** (byte transactions for wider widths)
+
+### Validation
+
+- targeted AML method execution tests,
+- shutdown/reboot proof on QEMU and bounded real hardware,
+- EC timeout/error-path tests where possible,
+- concurrent ACPI scheme reads while AML methods run.
+
+## Wave 3 — Ownership cleanup: reduce kernel ACPI scope and remove DMAR from `acpid`
+
+### Goal
+
+Move from transitional ownership to architecture that is easier to maintain.
+
+### Main files
+
+- `recipes/core/kernel/source/src/acpi/mod.rs`
+- kernel ACPI submodules as needed
+- `recipes/core/base/source/drivers/acpid/src/acpi/dmar/mod.rs`
+- `recipes/core/base/source/drivers/acpid/src/scheme.rs`
+- `local/recipes/system/iommu/source/src/*`
+
+### Status: Tasks 3.1 and 3.2 partially executed
+
+#### Task 3.1 — Define the minimum kernel ACPI surface — **open**
+
+The kernel still carries TODOs for kernel ACPI scope reduction. No staged migration contract has
+been written yet.
+
+#### Task 3.2 — Move DMAR to the correct owner — **partially done**
+
+The `acpi/dmar/mod.rs` module remains present in `acpid` source but is not imported or called from
+`main.rs` startup. The DMAR parsing code itself is not executed at daemon startup. However, the
+module has not been removed from the source tree, creating latent confusion about ownership.
+
+The `iommu` daemon is responsible for IVRS/DMAR runtime handling. DMAR is not initialized by
+`acpid`. The exit path from `acpid` for DMAR is therefore effectively achieved, but the cleanup
+(task: remove the unused module or move it to the `iommu` crate) is not complete.
+
+#### Task 3.3 — Ensure handoff paths are explicit — **open**
+
+Handoff paths for table discovery and CPU/topology are not yet documented as a staged migration
+contract.
+
+### Acceptance criteria
+
+- the minimal kernel ACPI contract is written down — **open**,
+- DMAR has a concrete exit path from `acpid` — **partially met** (not wired; module still present),
+- ownership reductions are staged and do not break current bring-up — **open**
+
+### Validation
+
+- before/after boot regressions,
+- Intel-specific validation for DMAR path changes,
+- AMD regression checks proving IVRS ownership remains isolated in `iommu`.
+
+## Wave 4 — Consumer integration and eventing quality
+
+### Goal
+
+Make ACPI consumers correct and low-friction, not just functional.
+
+### Main files
+
+- `local/recipes/system/redbear-sessiond/source/src/acpi_watcher.rs`
+- `recipes/core/base/source/drivers/acpid/src/scheme.rs`
+- DMI/quirk consumers under `redox-driver-sys` and reporting surfaces
+
+### Status: Task 4.1 partially executed; sleep eventing still a gap
+
+#### Task 4.1 — Replace polling-based ACPI state consumption — **partially done**
+
+Shutdown eventing is now event-driven via `/scheme/kernel.acpi/kstop`:
+
+- `acpid` opens `kstop` at startup and subscribes to it via `RawEventQueue`
+- When the kernel triggers shutdown, `acpid` receives an event on the `kstop` file descriptor
+- `redbear-sessiond`'s `acpi_watcher.rs` opens `kstop` and reads one byte in a blocking
+  `spawn_blocking` call, then emits D-Bus `PrepareForShutdown(true)` signal
+
+Sleep eventing (`\_Sx` transitions) remains unsupported. There is no `/scheme/acpi/sleep` surface
+and no event-driven sleep contract. This is a known gap.
+
+#### Task 4.2 — Bound DMI quirk authority — **open**
+
+#### Task 4.3 — Improve operator-facing observability — **open**
+
+### Acceptance criteria
+
+- no periodic polling remains for core ACPI power/session transitions if eventing is feasible — **partially met** (shutdown done; sleep still polling/absent),
+- quirk precedence is documented — **open**,
+- consumer-visible behavior is diagnosable from logs and status outputs — **open**
+
+### Validation
+
+- repeated shutdown/sleep edge tests,
+- DMI quirk application checks on known systems,
+- race checks with multiple simultaneous consumers of `/scheme/acpi/*`.
+
+## Wave 5 — Validation closure and release gate
+
+### Goal
+
+Convert the current implementation from bring-up evidence into release-grade trust.
+
+### Validation matrix
+
+At minimum, require:
+
+- QEMU/OVMF boot with ACPI active,
+- modern AMD hardware,
+- modern Intel hardware,
+- one platform that exercises EC-backed AML behavior,
+- malformed-table or degraded-mode evidence where feasible.
+
+### Tasks
+
+#### Task 5.1 — Publish a platform matrix
+
+For each validated platform, record:
+
+- firmware mode,
+- key ACPI tables detected,
+- APIC mode,
+- whether shutdown/reboot worked,
+- whether DMI and power exposure worked,
+- whether any AML/EC failure was observed.
+
+#### Task 5.2 — Capture negative results
+
+Do not hide unsupported AML opcodes, partial EC behavior, or platform-specific regressions behind a
+generic "works on tested hardware" label.
+
+#### Task 5.3 — Define the ACPI release gate
+
+Before calling ACPI complete for current Red Bear goals, require:
+
+- clean boot on the bounded matrix,
+- explicit degraded-mode behavior for known bad firmware cases,
+- documented ownership state,
+- and current docs that distinguish implemented vs validated.
+
+### Acceptance criteria
+
+- one bounded but honest validation matrix exists,
+- negative results are documented,
+- ACPI status claims are tied to explicit evidence rather than inference.
+
+## Upstream vs Red Bear Work Split
+
+### Upstream-first work
+
+These are generic ACPI correctness or architecture issues and should be solved upstream whenever
+possible, with temporary Red Bear patch carriers only if necessary:
+
+- `acpid` startup hardening
+- AML mutex semantics in `aml_physmem.rs`
+- `SLP_TYPb` completion
+- EC error typing and possibly EC access-width handling
+- using parsed tables for the rest of `acpid`
+- DMAR leaving `acpid`
+- kernel ACPI scope reduction TODOs
+- generic parser quality for kernel ACPI modules
+
+### Red Bear-owned work
+
+These remain Red Bear responsibilities even if upstream code improves:
+
+- honest status/phase documentation
+- bounded validation matrix and operator runbooks
+- `redbear-sessiond` event consumption quality
+- DMI quirk governance and integration policy
+- temporary durable patch carriers in `local/patches/*`
+- coordination between `acpid`, `iommu`, `pcid`, and downstream consumers
+
+## Sequencing Constraints
+
+1. **Wave 0 must come first** so later changes do not drift architecturally.
+2. **Wave 1 must come before Wave 2** so runtime correctness sits on a hardened startup path.
+3. **Wave 2 should come before Wave 4** because consumer contracts should depend on correct AML and
+   power behavior.
+4. **Wave 3 should not start until Waves 1 and 2 are at least partially complete**; ownership moves
+   are dangerous if the runtime behavior is still fragile.
+5. **Wave 5 closes the work**; it must not be used as a substitute for architecture.
+
+## Main Risks
+
+- stricter parser/error handling may expose machines that currently boot only by luck,
+- AML/EC changes may uncover hidden ordering assumptions with PCI registration,
+- reducing kernel ownership too early may regress early platform bring-up,
+- moving DMAR out of `acpid` may create Intel-only regressions if the replacement contract is vague,
+- DMI quirks can become a crutch if they are allowed to override runtime facts indiscriminately.
+
+## Deliverable Order
+
+If work from this plan is executed, the recommended order is:
+
+1. documentation and degraded-mode contract,
+2. startup hardening,
+3. AML/EC correctness,
+4. ownership cleanup,
+5. consumer/eventing quality,
+6. validation closure.
+
+## Definition of Done for the Current ACPI Plan
+
+This plan can be considered substantially complete only when:
+
+- ownership boundaries are explicit — **partially met** (this doc; module-level cleanup still needed)
+- boot-critical panic/silent-fallback paths are removed or justified — **partially met** (Task 1.1 done; Tasks 1.2 and 1.3 open)
+- AML and EC behavior are no longer TODO-grade — **partially met** (mutex state and EC width done; AML init order and SLP_TYPb open)
+- DMAR and IVRS ownership are cleanly separated — **partially met** (DMAR not wired; module still present in acpid)
+- ACPI consumers are event-driven or explicitly bounded — **partially met** (shutdown done via kstop; sleep not implemented)
+- sleep state transitions and eventing are implemented or explicitly documented as known gaps — **open**
+- the repo contains platform evidence that supports its status claims — **open** (QEMU validated; bare-metal evidence still needed)
+
+Current truthful status for Red Bear ACPI:
+
+> materially complete for historical bring-up, but still under active robustness, ownership,
+> sleep-state, and validation improvement. Shutdown eventing is implemented via kstop. Sleep state
+> transitions are a known gap. EC width support is implemented via byte transactions. AML mutex
+> state is real-tracked, not placeholder. DMAR is not initialized by acpid. Bare-metal validation
+> for the full ACPI surface is still outstanding.
@@ -7,7 +7,7 @@ Fill one section per test run. Date is ISO 8601.

 ```bash
 # 1. Build the image
-./local/scripts/build-amd.sh
+./local/scripts/build-redbear.sh redbear-desktop

 # 2. Burn to USB (DANGEROUS — verify target device!)
 ./local/scripts/test-baremetal.sh --device /dev/sdX
@@ -14,10 +14,13 @@ It consolidates and replaces the planning role previously held by:
 - `docs/03-WAYLAND-ON-REDOX.md` (historical Wayland rationale)
 - `docs/05-KDE-PLASMA-ON-REDOX.md` (historical KDE rationale)
 - `local/docs/AMD-FIRST-INTEGRATION.md` (AMD-specific hardware detail)
- `local/docs/PHASE-0-3-REASSESSMENT.md` (deprecated reconciliation doc)
 - Prior revisions of this document (v1, which used a different Phase 1–5 breakdown)

 Those documents remain useful for subsystem detail, porting history, and design rationale.
+The earlier reassessment bridge is now retired, and its reconciliation role is covered here together
+with `local/docs/DESKTOP-STACK-CURRENT-STATUS.md` and `docs/07-RED-BEAR-OS-IMPLEMENTATION-PLAN.md`.
+The DRM-specific execution detail beneath this desktop path now lives in
+`local/docs/DRM-MODERNIZATION-EXECUTION-PLAN.md`.
 This document answers the higher-level question: **what must happen, in what order, before
 Red Bear OS can honestly claim a usable KDE Plasma desktop on Wayland — first in software,
 then with real hardware acceleration.**
@@ -32,6 +35,10 @@ hardware GPU validation → KWin session bring-up → KDE Plasma session bring-u

 Out of scope: USB, Wi-Fi, Bluetooth (covered by their own subsystem plans).

+Tracked-default truth: this document is the canonical desktop-path plan, and the tracked default
+build now resolves to `CONFIG_NAME?=redbear-kde`. Runtime/session support claims still follow the
+evidence model below.
+
 ---

 ## Evidence Model
@@ -90,9 +97,9 @@ Rules:
 | kf6-kwayland | builds | | |
 | kf6-kcmutils | builds | Widget-only build (QML stripped) | |
 | `redbear-wayland` profile | builds, boots | Bounded Wayland runtime profile | |
-| `redbear-full` profile | builds, boots | Broader desktop plumbing profile | |
-| `redbear-kde` profile | builds | KDE session-surface profile | KWin only, not plasma-workspace/desktop yet |
-| smallvil compositor path | experimental | Reaches xkbcommon init + EGL platform selection in QEMU | No complete session |
+| `redbear-full` profile | builds, boots | Broader desktop plumbing profile | Session/network/runtime integration slice |
+| `redbear-kde` profile | builds | KDE session-surface profile | Tracked default KWin direction; KWin only, not plasma-workspace/desktop yet |
+| bounded compositor validation path | experimental | Reaches xkbcommon init + EGL platform selection in QEMU | No complete session |
 | qt6-wayland-smoke | builds, partial | Creates QWindow with colored background, runs 3 seconds | |
 | QEMU graphics | usable (bounded) | Renderer is llvmpipe | Not hardware acceleration |
 | D-Bus system bus (redbear-full) | usable (bounded) | Not full session integration | |
@@ -101,7 +108,13 @@ Rules:
 | plasma-workspace | experimental | Recipe exists, incomplete deps | |
 | plasma-desktop | experimental | Recipe exists, incomplete deps | |
 | QtNetwork | blocked | Intentionally disabled — relibc networking too narrow | |
-| Hardware GPU acceleration | blocked | PRIME/DMA-BUF scheme ioctls implemented, no GPU CS ioctl | |
+| Hardware GPU acceleration | blocked | PRIME/DMA-BUF scheme ioctls and a bounded private CS surface exist, but no real vendor GPU render CS/fence path | |
+
+The current bounded runtime entrypoint for display-path evidence is the in-guest
+`redbear-drm-display-check` tool, with shell wrappers in `local/scripts/test-drm-display-runtime.sh`,
+`local/scripts/test-amd-gpu.sh`, and `local/scripts/test-intel-gpu.sh`. It now covers direct
+connector/mode enumeration and bounded direct modeset proof, but successful runs from that surface are
+still display-only evidence, not render proof.
 | Working Wayland compositor session | blocked | Runtime not proven | |
 | KWin compositor runtime | blocked | Runtime not proven | |
 | KDE Plasma session | blocked | Runtime not proven | |
@@ -120,7 +133,7 @@ The repo has crossed major build-side gates:
 ### What is runtime-proven (limited scope)

 - AMD bare-metal boot with ACPI, SMP, x2APIC
- `redbear-wayland` boots in QEMU, smallvil reaches early init
+- the bounded runtime validation surface boots in QEMU and reaches early initialization
 - QEMU graphics via llvmpipe (software)
 - D-Bus system bus wired in `redbear-full`
 - VirtIO networking in QEMU
@@ -163,9 +176,8 @@ hardware validation, and KWin/Plasma session assembly**. That is the real starti
 │       Qt6 Widgets, QtWayland, QtDBus, QML, KF6, KDE support libs            │
 ├──────────────────────────────────────────┬───────────────────────────────────┤
 │              Wayland compositor and protocols                                │
-│        smallvil first, then KWin, plus libwayland                            │
-│        NOTE: KWin replaces smallvil as the compositor in Phase 3,            │
-│        spanning both the compositor layer and the session layer.             │
+│      bounded validation compositor work, then KWin as the desktop path       │
+│        NOTE: KWin owns the compositor and session layers in Phase 3.         │
 ├──────────────────────────────────────────┬───────────────────────────────────┤
 │             Mesa, GBM, EGL, GLES2, libdrm                                   │
 │       software path first, hardware path after DMA-BUF                       │
@@ -189,7 +201,7 @@ hardware validation, and KWin/Plasma session assembly**. That is the real starti
 | Kernel + libc | strong build-side, runtime incomplete | relibc surfaces, driver substrate | Real Wayland/Qt event-loop pressure, GPU CS ioctl |
 | DRM/firmware/input | build + boot visible, not runtime-trusted | Scheme registration at boot | Real firmware loading, real input flow, real DRM/KMS queries |
 | Graphics userland | software builds, hardware blocked | Mesa EGL/GBM/GLES2, libdrm, Qt6 OpenGL | Hardware renderer path, GBM/EGL on hardware |
-| Wayland compositor | partial runtime, not complete | smallvil reaches early init in QEMU | Complete compositor session, input routing, Qt6 client display |
+| Wayland compositor | partial runtime, not complete | bounded compositor initialization reached in QEMU | Complete compositor session, input routing, Qt6 client display |
 | Qt6 + KF6 | build milestone, runtime thin | All packages build | Real Qt6 Wayland client behavior, QML without JIT |
 | KWin session | experimental, blocked | Recipes exist, some features re-enabled | Honest deps, KWin runtime, session services |
 | KDE Plasma | not yet proven | Recipe surfaces exist | plasma-workspace, plasma-desktop, shell, panel, apps |
@@ -198,7 +210,7 @@ hardware validation, and KWin/Plasma session assembly**. That is the real starti

 The shortest honest path is not "port more packages". It is:
 1. **Validate the substrate** (turn builds into runtime trust)
-2. **Finish one software compositor path** (smallvil)
+2. **Finish one software compositor validation path**
 3. **Finish one KWin session path** (on software renderer)
 4. **Finish one Plasma session path** (on software renderer)
 5. **Land real hardware acceleration** (in parallel with steps 3–4)
@@ -264,27 +276,27 @@ Track C (parallel): Hardware GPU Enablement

 **Duration:** 4–6 weeks
 **Goal:** Produce the first working Wayland compositor session using software rendering.
-**Profile target:** `redbear-wayland`
+**Profile target:** tracked validation profile
 **Renderer:** LLVMpipe (software) — acceptable for correctness proof.

-#### Why smallvil first
+#### Why a bounded validation compositor comes before full session bring-up

-Jumping straight to KWin combines too many unknowns: compositor runtime, input, QML,
-session services, dependency scaffolding. smallvil is smaller, easier to debug, already
-present. It isolates compositor + input + Qt client issues before session-shell complexity.
+Jumping straight to full session bring-up combines too many unknowns: compositor runtime, input,
+QML, session services, and dependency scaffolding. A bounded validation compositor isolates
+compositor + input + Qt client issues before session-shell complexity.

 #### Work items

 | # | Task | Acceptance criteria |
 |---|---|---|
-| 2.1 | Complete smallvil runtime path to usable session | smallvil launches, creates a Wayland surface, and does not crash for at least 60 seconds in QEMU; `WAYLAND_DISPLAY` is set and a client can connect |
+| 2.1 | Complete bounded runtime path to usable session | The compositor launches, creates a Wayland surface, and does not crash for at least 60 seconds in QEMU; `WAYLAND_DISPLAY` is set and a client can connect |
 | 2.2 | Wire evdevd input into compositor | Keyboard + mouse work through Redox input stack |
 | 2.3 | Wire Mesa software rendering through GBM + EGL | Software rendering works through Mesa/GBM/EGL |
 | 2.4 | Get Qt6 widget app to display through compositor | `qt6-wayland-smoke` shows a window inside compositor in QEMU |

 #### Exit criteria

- [ ] smallvil launches into a working session in QEMU
+- [ ] the compositor launches into a working session in QEMU
 - [ ] Keyboard and mouse work through the current input stack
 - [ ] Mesa software rendering works through GBM and EGL
 - [ ] `qt6-wayland-smoke` shows a window inside the compositor in QEMU
@@ -305,14 +317,14 @@ present. It isolates compositor + input + Qt client issues before session-shell

 #### Blocked dependency set that must be closed

-**Stub dependencies** (INTERFACE IMPORTED cmake targets without real implementations):
+**Honest reduced-build dependency state** in the current KWin path:

-| Stub | Must become | Path |
+| Dependency | Current state | Remaining limit |
 |---|---|---|
-| libepoxy-stub | Real libepoxy build | Port or find minimal GL dispatch alternative |
-| libudev-stub | Real libudev or enhanced udev-shim lib | Extend udev-shim to provide libudev API |
-| lcms2-stub | Real lcms2 build | Port lcms2 color management library |
-| libdisplay-info-stub | Real libdisplay-info build | Port or find alternative |
+| libepoxy | Real dependency | none in this slice |
+| lcms2 | Real dependency | none in this slice |
+| libudev | Honest scheme-backed provider | hotplug monitoring remains bounded |
+| libdisplay-info | Honest bounded provider | base-EDID only; CTA / DisplayID / HDR metadata still unsupported |

 **Stub-only/heavily shimmed packages:**

@@ -321,7 +333,7 @@ present. It isolates compositor + input + Qt client issues before session-shell
 | kirigami | Stub-only for dep resolution | Real build needed for QML-dependent Plasma shell |
 | kf6-kio | Heavy shim build | Must become honest build for session claims |

-**KWin feature switches** (9 still disabled):
+**KWin feature switches** (11 still disabled in the current reduced path):

 | Switch | Why disabled | Re-enable condition |
 |---|---|---|
@@ -329,20 +341,21 @@ present. It isolates compositor + input + Qt client issues before session-shell
 | KWIN_BUILD_KCMS=OFF | Requires QML | After BUILD_WITH_QML |
 | KWIN_BUILD_EFFECTS=OFF | Desktop effects | After basic compositor works |
 | KWIN_BUILD_TABBOX=OFF | Alt-tab switcher | After basic window management works |
+| KWIN_BUILD_GLOBALSHORTCUTS=OFF | Global shortcut integration | After the reduced KWin path is otherwise honest |
+| KWIN_BUILD_NOTIFICATIONS=OFF | Notification integration | After the reduced KWin path is otherwise honest |
 | KWIN_BUILD_SCREENLOCKING=OFF | Screen locking | Late session polish |
 | KWIN_BUILD_SCREENLOCKER=OFF | Screenlocker binary | Late session polish |
-| KWIN_BUILD_X11=OFF | X11 windowing | Intentional: Wayland-only |
+| legacy windowing backend disabled | legacy windowing backend | Intentional: Wayland-only |
 | KWIN_BUILD_RUNNING_IN_KDE=OFF | KDE runtime detection | After KWin runs as compositor |
 | KWIN_BUILD_ELECTRONICALLY_SIGNING_DOCS=OFF | Document signing | Low priority |

-**5 switches already re-enabled** (deps verified built): DECORATIONS, GLOBALSHORTCUTS,
-RUNNERS, NOTIFICATIONS, USE_DBUS.
+**3 switches already re-enabled** in the current reduced path: DECORATIONS, RUNNERS, USE_DBUS.

 #### Work items

 | # | Task | Acceptance criteria |
 |---|---|---|
-| 3.1 | Resolve KWin stubbed blockers (libepoxy, libudev, lcms2, libdisplay-info) | KWin cmake configure succeeds without any `-stub` INTERFACE IMPORTED targets; `ldd` on the KWin binary shows real `.so` links for all four libraries |
+| 3.1 | Keep the KWin reduced path dependency-honest | KWin cmake configure succeeds without any fake `-stub` imported fallbacks; the built KWin binary links `libepoxy`, `libudev`, `lcms2`, and `libdisplay-info` as real shared-library dependencies |
 | 3.2 | Launch KWin as Wayland compositor | KWin process starts, registers `WAYLAND_DISPLAY`, and owns the display output for at least 60 seconds without crash |
 | 3.3 | Validate libinput backend behavior | Keyboard keypress and mouse motion events arrive at a KWin-managed window via libinput + evdevd chain |
 | 3.4 | Validate D-Bus session behavior | `dbus-send --session --dest=org.kde.KWin /KWin org.kde.KWin.supportInformation` returns a non-empty string |
@@ -481,10 +494,10 @@ Phase 5 + Phase 3 + Phase 4
 Phase 1 converts lower-layer package progress into runtime trust. Without it, Phase 2+ failures
 will be misdiagnosed as compositor bugs when they're actually substrate bugs.

-### Why smallvil before KWin
+### Why bounded validation comes before KWin session proof

-Smallest environment to isolate compositor + input + Qt client issues. KWin adds session
-services, QML, dependency scaffolding, and desktop-shell behavior on top.
+This is the smallest environment to isolate compositor + input + Qt client issues. KWin adds
+session services, QML, dependency scaffolding, and desktop-shell behavior on top.

 ### Why hardware doesn't block session assembly

@@ -500,7 +513,7 @@ integration). Those can be solved on software renderer while hardware path matur
 | R1 | relibc runtime gaps worse than build evidence suggests | Medium | High | Validate with real consumers in Phase 1 |
 | R2 | GPU CS ioctl scope is uncertain | High | High | Isolate design + proof early in Phase 5 |
 | R3 | Real-hardware validation reveals fundamental driver issues | High | High | Validate AMD and Intel separately |
-| R4 | KWin needs significantly more patches than estimated | Medium | High | Finish smallvil proof first for cleaner lower-layer evidence |
+| R4 | KWin needs significantly more patches than estimated | Medium | High | Finish the bounded validation proof first for cleaner lower-layer evidence |
 | R5 | QML-heavy pieces behave badly with JIT disabled | Medium | Medium-High | Keep QML runtime proof explicit in Phases 3–4 |
 | R6 | Mesa hardware rendering needs Redox-specific winsys work | Medium | High | Separate display proof from renderer proof |
 | R7 | linux-kpi gaps only surface during real-hardware execution | High | Medium-High | Budget for hardware-driven compat fixes in Phase 5 |
@@ -585,7 +598,7 @@ continuity, not as future work.

 | Work | Status | When |
 |---|---|---|
-| AMD bare-metal boot (ACPI, SMP, x2APIC) | ✅ Complete | Prior to this plan |
+| AMD bare-metal boot (ACPI, SMP, x2APIC) | ✅ Boot-baseline complete | Prior to this plan; see `local/docs/ACPI-IMPROVEMENT-PLAN.md` for ongoing ownership and robustness work |
 | Driver infrastructure (redox-driver-sys, linux-kpi, firmware-loader) | ✅ Builds complete | Prior to this plan |
 | AMD GPU display (redox-drm, amdgpu C port) | ✅ Builds complete | Prior to this plan |
 | relibc POSIX unblockers (signalfd, timerfd, eventfd, etc.) | ✅ Builds complete | Prior to this plan |
@@ -125,7 +125,7 @@ specific schemes it needs. This keeps the architecture honest and avoids a leaky
 | **QtDBus** | `recipes/wip/qt/qtbase/` | ✅ Enabled | `FEATURE_dbus=ON` for target build, Qt6DBus module present |
 | **kf6-kdbusaddons** | `local/recipes/kde/kf6-kdbusaddons/` | ✅ Builds | KF6 D-Bus convenience wrappers, provides qdbus tool integration |
 | **D-Bus system bus** | `config/redbear-full.toml`, `redbear-kde.toml` | ✅ Wired | `12_dbus.service` launches `dbus-daemon --system`, `messagebus` user (uid=100), `/var/lib/dbus` + `/run/dbus` directories |
-| **D-Bus session bus** | `config/redbear-kde.toml` | ✅ Scripted | `orbital-kde` launches `dbus-launch --sh-syntax` before KWin |
+| **D-Bus session bus** | `config/redbear-kde.toml` | ✅ Scripted | `redbear-kde-session` launches `dbus-launch --sh-syntax` before KWin |
 | **seatd** | `config/redbear-kde.toml` | ✅ Wired | `13_seatd.service`, `LIBSEAT_BACKEND=seatd`, `SEATD_SOCK=/run/seatd.sock` |
 | **kf6-kservice** | `local/recipes/kde/kf6-kservice/` | ✅ Builds | Depends on kf6-kdbusaddons |
 | **kf6-kglobalaccel** | `local/recipes/kde/kf6-kglobalaccel/` | ✅ Builds | Depends on kf6-kdbusaddons |
@@ -167,7 +167,7 @@ specific schemes it needs. This keeps the architecture honest and avoids a leaky
 ```
 KWin needs:
  dbus-daemon --system          ✅ exists, wired
-  dbus-daemon --session         ✅ exists, wired in orbital-kde
+  dbus-daemon --session         ✅ exists, wired in redbear-kde-session
  org.freedesktop.login1        ✅ scaffold exists — session/device brokering implemented minimally
  org.kde.KWin (self-register)  ✅ KWin does this itself (dbusinterface.cpp)
 ```
@@ -231,7 +231,7 @@ Complete Plasma needs (after re-enabling disabled components):
 │   plasmashell, kwin_wayland, kded6, kglobalaccel, plasma applets        │
 ├──────────────────────────────────────────────────────────────────────────┤
 │                     Session Bus (per-user)                               │
-│   Started by: orbital-kde via dbus-launch or dbus-run-session           │
+│   Started by: redbear-kde-session via dbus-launch or dbus-run-session   │
 │   Policy: /etc/dbus-1/session.conf                                      │
 │   Services: /usr/share/dbus-1/session-services/                         │
 │   ┌──────────────────────────────────────────────────────────────────┐  │
@@ -258,7 +258,7 @@ Complete Plasma needs (after re-enabling disabled components):
 ├──────────────────────────────────────────────────────────────────────────┤
 │                     dbus-daemon 1.16.2                                   │
 │   C reference implementation, redox.patch for epoll + socketpair         │
-│   systemd disabled, x11_autolaunch disabled                              │
+│   systemd disabled, legacy GUI autolaunch disabled                       │
 │   Classic .service file activation                                       │
 ├──────────────────────────────────────────────────────────────────────────┤
 │                     Redox Schemes (native IPC)                           │
@@ -281,7 +281,7 @@ Boot:
     (registers org.freedesktop.login1 on system bus)
  3. Redox init starts 13_seatd.service → seatd

-Session launch (orbital-kde):
+Session launch (redbear-kde-session):
  4. dbus-daemon --system already running
  5. eval $(dbus-launch --sh-syntax)  →  session bus started
  6. export DBUS_SESSION_BUS_ADDRESS, XDG_SESSION_ID, XDG_SEAT, XDG_RUNTIME_DIR
@@ -296,7 +296,7 @@ Session launch (orbital-kde):
 | System bus core (login1) | **Redox init** | Must be running before any desktop session |
 | System bus compat (UPower, NM) | **Redox init** or **D-Bus activation** | Can be started lazily, but init is simpler |
 | Session bus KDE services (kglobalaccel, kded6) | **D-Bus activation** (classic `.service` files) | KDE expects this, standard pattern |
-| Session bus KDE shell (KWin, plasmashell) | **Explicit launch** in `orbital-kde` | Must start in specific order with env vars |
+| Session bus KDE shell (KWin, plasmashell) | **Explicit launch** in `redbear-kde-session` | Must start in specific order with env vars |
 | Session bus compat (notifications, tray) | **D-Bus activation** | Standard freedesktop pattern |

 ---
@@ -538,7 +538,7 @@ APIs, which relibc provides.
 | 1.5 | Create D-Bus policy files for login1 | Policy allows session compositor to call login1 methods |
 | 1.6 | Create D-Bus activation `.service` file for login1 | `redbear-sessiond` can be activated or init-started |
 | 1.7 | Add `redbear-sessiond` to `redbear-kde.toml` init services | Service starts before KWin in boot sequence |
-| 1.8 | Wire `XDG_SESSION_ID`, `XDG_SEAT`, `XDG_RUNTIME_DIR` in `orbital-kde` | KWin sees a valid session environment |
+| 1.8 | Wire `XDG_SESSION_ID`, `XDG_SEAT`, `XDG_RUNTIME_DIR` in the KDE session launcher | KWin sees a valid session environment |
 | 1.9 | Validate: `dbus-send --system --dest=org.freedesktop.login1 --print-reply /org/freedesktop/login1 org.freedesktop.login1.Manager.ListSessions` | Returns non-empty session list |
 | 1.10 | Validate: `dbus-send --session --dest=org.kde.KWin /KWin org.kde.KWin.supportInformation` | Returns non-empty KWin info string |

@@ -597,7 +597,7 @@ APIs, which relibc provides.
 - [ ] kf6-solid uses UPower backend for power queries
 - [ ] Sleep/shutdown signals flow through login1 D-Bus interface

-**Dependencies:** Phase DB-2 complete, ACPI integration working
+**Dependencies:** Phase DB-2 complete, ACPI boot-baseline integration working; see `local/docs/ACPI-IMPROVEMENT-PLAN.md` for the remaining ownership, robustness, and validation work

 ### Phase DB-4: Policy and Access Control (2–3 weeks)

@@ -875,7 +875,7 @@ type = "oneshot_async"
 """
 ```

-**`orbital-kde` script updates:**
+**KDE session launcher updates:**

 ```bash
 # After dbus-launch, set session variables
@@ -1,6 +1,6 @@
 # Red Bear OS Desktop Stack — Current Status

-**Last updated:** 2026-04-16
+**Last updated:** 2026-04-18
 **Canonical plan:** `local/docs/CONSOLE-TO-KDE-DESKTOP-PLAN.md` (v2.0)

 ## Purpose
@@ -28,6 +28,13 @@ The canonical desktop plan uses a three-track model:
 **Current position:** Build-side gates are crossed. Phase 1 (Runtime Substrate Validation) is the
 next work target. The repo has not yet started systematic runtime validation.

+## Tracked Default and Evidence Boundary
+
+- The tracked default build now resolves to `CONFIG_NAME?=redbear-kde`.
+- the bounded Phase 2 validation profile remains available.
+- `redbear-kde` is the tracked KWin Wayland desktop direction, but runtime-proven compositor/
+  session claims still remain incomplete.
+
 ## Status Matrix

 | Area | Evidence class | Detail |
@@ -35,7 +42,7 @@ next work target. The repo has not yet started systematic runtime validation.
 | `libwayland` | **builds** | relibc/Wayland-facing compatibility is materially better than before |
 | Qt6 core stack | **builds** | `qtbase` (7 libs + 12 plugins), `qtdeclarative`, `qtsvg`, `qtwayland` |
 | KF6 frameworks | **builds** | All 32/32; some higher-level pieces use bounded/reduced recipes (kf6-kio heavy shim, kirigami stub-only) |
-| KWin | **experimental** | Recipe exists; 5 features re-enabled; 4 stub deps block honest build; 9 feature switches still disabled |
+| KWin | **experimental** | Recipe exists; current reduced path now links honest `libudev.so` and `libdisplay-info.so` provider paths alongside real `libepoxy` and `lcms2`; 11 feature switches remain disabled and runtime/session proof is still missing |
 | plasma-workspace | **experimental** | Recipe exists; stub deps (kf6-knewstuff, kf6-kwallet) unresolved |
 | plasma-desktop | **experimental** | Recipe exists; depends on plasma-workspace |
 | Mesa EGL+GBM+GLES2 | **builds** | Software path via LLVMpipe proven in QEMU; hardware path not proven |
@@ -50,19 +57,20 @@ next work target. The repo has not yet started systematic runtime validation.
 | Phase 6 Solid readiness proof | ✅ implemented, blocked | `redbear-phase6-kde-check` + `test-phase6-kde-qemu.sh` now distinguish real Solid validation from blocked states; `kf6-solid` remains disabled until runtime proof + tooling are present |
 | redbear-polkit | ✅ Scaffold | org.freedesktop.PolicyKit1 — always-permit authorization; KAuth still uses FAKE backend because PolkitQt6-1 is not packaged yet |
 | redbear-dbus-services | ✅ Created | D-Bus activation files + policies staged |
-| DRM/KMS | **builds** | redox-drm scheme daemon; no hardware runtime validation |
-| GPU acceleration | **blocked** | PRIME/DMA-BUF ioctls implemented; GPU CS ioctl missing |
-| smallvil compositor | **experimental** | Reaches early init in QEMU; no complete session |
-| `redbear-wayland` profile | **builds, boots** | Bounded Wayland runtime profile |
+| DRM/KMS | **builds** | redox-drm scheme daemon; shared contract hardened (GEM, PRIME, bounded private CS surface, honest fsync, shared driver-event groundwork for B3 across Intel and AMD); no hardware runtime validation |
+| GPU acceleration | **blocked** | PRIME/DMA-BUF ioctls and bounded private CS surface implemented; real vendor render CS/fence path still missing |
+| validation compositor runtime | **experimental** | Reaches early init in QEMU; no complete session |
+| validation profile | **builds, boots** | Bounded Wayland runtime profile |
 | `redbear-full` profile | **builds, boots** | Broader desktop plumbing profile |
-| `redbear-kde` profile | **builds** | KDE session-surface profile |
+| `redbear-kde` profile | **builds** | Tracked KWin desktop-direction profile |
+| `redbear-live` profile | **builds** | Live image following the tracked KWin desktop target |

 ## Profile View

-### `redbear-wayland`
+### Validation profile

 - **Role:** Phase 2 Wayland compositor validation target
- **Current truth:** Builds and boots in QEMU; smallvil reaches early init but no complete session
+- **Current truth:** Builds and boots in QEMU; bounded compositor initialization reaches early init but no complete session
 - **Use for:** Compositor/runtime regression testing, not broad desktop claims

 ### `redbear-full`
@@ -75,9 +83,15 @@ next work target. The repo has not yet started systematic runtime validation.
 ### `redbear-kde`

 - **Role:** Phase 3–4 KDE/Plasma session bring-up
- **Current truth:** Carries KWin/session wiring and KDE-facing package set; experimental
+- **Current truth:** Carries KWin/session wiring and KDE-facing package set; experimental but selected as the tracked default desktop target
 - **Use for:** KDE session surface testing once Phase 2 completes

+### `redbear-live`
+
+- **Role:** Live/demo/recovery image layered on the tracked desktop profile
+- **Current truth:** Inherits `redbear-kde`, so live media now follows the tracked KWin desktop target
+- **Use for:** Demo, install, and recovery workflows based on the current shipped desktop surface
+
 ## Current Blockers

 ### 1. Runtime trust trails build success (Phase 1 gate)
@@ -87,26 +101,37 @@ Phase 1 exists specifically to close this gap.

 ### 2. No complete compositor session (Phase 2 gate)

-smallvil reaches early initialization but does not complete a usable Wayland compositor session.
+A bounded compositor initialization reaches early startup but does not complete a usable Wayland compositor session.
 This blocks all desktop session work.

-### 3. KWin blocked by stub dependencies (Phase 3 gate)
+### 3. KWin reduced build is now dependency-honest, but runtime proof is still missing (Phase 3 gate)

-Four stub cmake targets must become real builds:
+The reduced KWin path now builds with honest provider linkage for `libepoxy`, `lcms2`, `libudev`,
+and `libdisplay-info`.

-| Stub | Real library exists? | Path to resolve | Difficulty |
-|---|---|---|---|
-| `libepoxy-stub` | Yes — `recipes/wip/libs/gnome/libepoxy/` (meson, has redox.patch) | Port real libepoxy; currently needs full X11/GLX stack | Medium |
-| `libudev-stub` | Partial — `recipes/wip/services/eudev/` (broken: POSIX headers missing) | Fix eudev compilation; `udev-shim` is a binary not a C library | Medium-Hard |
-| `lcms2-stub` | Yes — `recipes/wip/libs/other/liblcms/` (compiled, untested) | Test and integrate real lcms2; depends on libtiff | Low |
-| `libdisplay-info-stub` | **No** — not in recipe tree at all | New port from freedesktop.org; full EDID/CTA/DisplayID parser | Hard |
+Current truth for that slice:

-Additionally, two packages need honest builds: kirigami (stub-only), kf6-kio (heavy shim).
+| Dependency | Current state | Remaining limitation |
+|---|---|---|
+| `libepoxy` | Real dependency | No blocker in this slice |
+| `lcms2` | Real dependency | No blocker in this slice |
+| `libudev` | Honest scheme-backed provider (`libudev.so`) | Hotplug monitoring remains bounded rather than full eudev parity |
+| `libdisplay-info` | Honest bounded provider (`libdisplay-info.so`) | Base-EDID parsing only; CTA / DisplayID / HDR metadata remain unsupported |
+
+Additionally, two packages still need more honest session-ready treatment: kirigami (stub-only),
+kf6-kio (heavy shim).

 ### 4. Hardware acceleration missing GPU CS ioctl (Phase 5 gate)

-PRIME/DMA-BUF buffer sharing is implemented at the scheme level, but GPU command submission
-does not exist. This blocks hardware-accelerated rendering.
+PRIME/DMA-BUF buffer sharing is implemented at the scheme level, and a bounded private CS
+surface now exists for shared-contract work. Real vendor render command submission and shared
+fence semantics still do not exist. This still blocks hardware-accelerated rendering.
+
+The repo now also carries a bounded in-guest display checker, `redbear-drm-display-check`, with
+shell wrappers at `local/scripts/test-drm-display-runtime.sh`, `test-amd-gpu.sh`, and
+`test-intel-gpu.sh`. It now covers direct connector/mode enumeration and bounded direct modeset
+proof over the Red Bear DRM ioctl surface, but it is still only a runtime evidence tool until it is
+exercised on real Intel and AMD hardware.

 ## Canonical Document Roles

@@ -127,5 +152,5 @@ The Red Bear desktop stack has crossed major build-side gates:
 - Three tracked desktop profiles exist and at least boot in QEMU
 - relibc compatibility is materially stronger than before

-The remaining work is **runtime validation and session assembly**, not more package porting.
-Phase 1 (Runtime Substrate Validation) is the immediate next target.
+The remaining work is **runtime validation, session assembly, and the remaining KDE session/runtime proof work**.
+Phase 1 (Runtime Substrate Validation) remains the immediate next target, while the KWin reduced path still lacks runtime compositor/session proof.
@@ -1,7 +1,11 @@
 # Red Bear OS: DMA-BUF Improvement Plan

 **Date**: 2026-04-16
-**Status**: v1 COMPLETE (Steps 1-6a implemented, Oracle-verified through 8 rounds). Step 6b blocked on GPU command submission. Stale token cleanup verified across all GEM destruction paths.
+**Status**: historical DMA-BUF bring-up plan, partially superseded by the current DRM shared-core work. PRIME import/export and bounded private-CS groundwork are now implemented; real vendor render/fence completion is still blocked.
+
+> **Planning authority note (2026-04-18):** this file remains the detailed DMA-BUF/PRIME reference,
+> not the canonical GPU/DRM execution plan. Use `local/docs/DRM-MODERNIZATION-EXECUTION-PLAN.md`
+> for current sequencing and acceptance criteria.
 **Scope**: Cross-process GPU buffer sharing for hardware-accelerated KDE Plasma on Wayland

 ## Bottom Line
@@ -52,8 +56,9 @@ Process B (compositor, e.g. KWin)
  8. Both processes see same physical pages                   ← ZERO-COPY
 ```

-Steps 1-2 are already working. Steps 3-6 require redox-drm changes. Steps 4-5 and 7-8 use
-existing kernel mechanisms.
+Steps 1-2 are already working. PRIME import/export is also now implemented in `redox-drm`, and
+the shared DRM core now includes a bounded private command-submission surface for contract
+hardening. Real vendor render/fence completion is still missing.

 ## Current State

@@ -78,28 +83,32 @@ existing kernel mechanisms.
 | PRIME_FD_TO_HANDLE | ✅ Implemented | Token lookup via prime_exports, adds to owned_gems |
 | libdrm PRIME/GEM dispatch | ✅ Implemented | __redox__ wrappers in drmPrimeHandleToFD/drmPrimeFDToHandle |
 | Mesa Redox winsys | 🚧 Scaffolding | Stubs compile but do not render — blocked on GPU CS |
-| GPU command submission | ❌ Not implemented | No CS ioctl, no ring buffer programming |
+| GPU command submission | ⚠️ Bounded shared surface only | Shared private-CS contract exists; no real vendor render ioctl/ring programming yet |
 | GPU fence/signaling | ❌ Not implemented | No GPU completion notification |

-### What Was Cleaned Up (Previous Session)
+### What Was Cleaned Up (Historical Session)

 The old fake PRIME implementation used synthetic fd numbers starting at 10,000 that were not real
 kernel file descriptors. Other processes could not resolve them. Oracle caught this across 4
-verification rounds. The cleanup:
+verification rounds. The cleanup and follow-up hardening:

 - Removed `exported_dmafds` tracking from Handle struct
- Removed `imported_gems` from Handle
+- Removed the old fake PRIME synthetic-fd bookkeeping. Imported GEM tracking still exists in the current honest PRIME path.
 - Removed DMA-BUF methods from `GpuDriver` trait and AMD/Intel driver impls
 - Removed `DmabufManager` from `GemManager`
 - Removed `mod dmabuf` from `main.rs`
 - Removed PRIME wire structs (`DrmPrimeHandleToFdWire`, `DrmPrimeFdToHandleWire`)
- PRIME handlers → EOPNOTSUPP (honest, not fake)
+- PRIME handlers are now implemented in the current scheme path with non-guessable export tokens; only unsupported fake sync/render paths return `EOPNOTSUPP`.
 - Removed all `#[allow(dead_code)]` from fake bookkeeping

 ## Phased Implementation

 ### v1: System RAM, Linear, Single GPU (Target: working PRIME)

+**Current note:** the PRIME/export-import milestones in this section are largely complete in the
+live `redox-drm` scheme. The remaining value of this document is the dependency narrative and the
+later DMA-BUF / winsys / fencing roadmap, not the claim that PRIME is still unimplemented.
+
 **Goal**: A compositor (KWin) can import a buffer rendered by a GPU client (Mesa) and display it.
 All buffers in system RAM, linear layout, single GPU.

@@ -125,7 +134,7 @@ The client then opens `/scheme/drm/card0/dmabuf/{token}` to get a real scheme fd
 handler validates the token against `prime_exports`, creates a `NodeKind::DmaBuf` scheme handle,
 and bumps the GEM export refcount. When that scheme fd is closed, the refcount is dropped.

-Key design: export tokens are opaque identifiers, not synthetic fd numbers or raw GEM handles.
+Key design: export tokens are opaque, non-guessable identifiers, not synthetic fd numbers or raw GEM handles.
 The `prime_exports` map resolves tokens to GEM handles. Tokens are cleaned up when the last
 export ref for a GEM handle is dropped.

@@ -315,7 +324,7 @@ struct DrmPrimeHandleToFdResponseWire {

 The scheme internally:
 1. Validates handle ownership
-2. Generates an opaque export token (monotonically increasing counter)
+2. Generates an opaque non-guessable export token
 3. Stores `prime_exports[token] = gem_handle`
 4. Returns the token as `fd`

@@ -416,8 +425,8 @@ in `maybe_close_gem()`, explicit cleanup in `GEM_CLOSE`/`DESTROY_DUMB`, liveness
 `PRIME_FD_TO_HANDLE` and `open("dmabuf/{token}")` that remove stale tokens on failure.
 Verified by Oracle across 8 rounds.

-**Protocol note**: PRIME uses opaque export tokens. PRIME_HANDLE_TO_FD returns a monotonically-
-increasing token stored in `prime_exports`. The client opens `/scheme/drm/card0/dmabuf/{token}`
+**Protocol note**: PRIME uses opaque export tokens. PRIME_HANDLE_TO_FD returns a non-guessable
+token stored in `prime_exports`. The client opens `/scheme/drm/card0/dmabuf/{token}`
 to get a real scheme fd. `redox_fpath()` on that fd reveals the token. PRIME_FD_TO_HANDLE
 accepts the export token and resolves it via `prime_exports`. Tokens are cleaned up when the
 last export ref is dropped.
@@ -0,0 +1,495 @@
+# Red Bear OS DRM Modernization Execution Plan
+
+**Date:** 2026-04-18
+**Scope:** Shared DRM substrate, shared DRM core, Intel and AMD vendor backends, userland DRM integration, and validation needed to move Red Bear OS from build-visible DRM progress to evidence-backed modern GPU support.
+**Position in the doc set:** This is the single comprehensive GPU/DRM execution plan beneath `local/docs/CONSOLE-TO-KDE-DESKTOP-PLAN.md`. It does not replace the canonical desktop path. It is the canonical GPU/DRM plan and should be preferred over older GPU-specific planning docs when execution order, acceptance criteria, or claim language conflict.
+
+**Supersedes as planning authority:**
+
+- `local/docs/AMD-FIRST-INTEGRATION.md` for forward execution order
+- `local/docs/P2-AMD-GPU-DISPLAY.md` for future-task sequencing
+- `local/docs/HARDWARE-3D-ASSESSMENT.md` for roadmap ordering
+- `local/docs/DMA-BUF-IMPROVEMENT-PLAN.md` for PRIME/render dependency ordering
+
+Those documents remain useful as implementation detail, status, and historical/reference material, but this file is the single planning source of truth for GPU/DRM work.
+
+## Title and intent
+
+Red Bear OS already has meaningful DRM build-side progress. The next step is not to overclaim hardware support. The next step is to turn the current stack into an evidence-driven execution plan that treats modern Intel and AMD support at the same acceptance bar.
+
+Equal priority here does **not** mean equal code volume, equal driver complexity, or identical sequencing inside each backend. It means Red Bear should require the same evidence quality, the same runtime gates, and the same acceptance standards before claiming modern Intel or AMD support.
+
+## Scope boundaries
+
+This plan covers:
+
+- shared GPU substrate from `redox-driver-sys` through `linux-kpi`
+- firmware delivery and GPU-facing runtime service readiness
+- `redox-drm` shared DRM/KMS, GEM, PRIME, IRQ, and bounded command-submission surfaces
+- Intel and AMD backend maturation inside `local/recipes/gpu/redox-drm/source/src/drivers/`
+- userland handoff to `libdrm`, Mesa, GBM, EGL, and compositor/session layers
+- runtime validation and claim discipline
+
+This plan does **not** claim:
+
+- completed hardware rendering on either vendor
+- completed hardware validation on either vendor
+- that display/KMS maturity implies render/3D maturity
+- that Track C in the canonical desktop plan can bypass Track A runtime trust work
+
+## Current-state summary
+
+### Bottom line
+
+The repo has real progress in shared DRM/KMS, GEM, PRIME, firmware plumbing, interrupt plumbing, and vendor backend structure. That is enough to justify a modernization plan. It is not enough to claim modern Intel or AMD GPU support yet.
+
+### Current strengths
+
+| Area | Current evidence | Repo grounding |
+|---|---|---|
+| GPU substrate | Present and build-visible | `local/recipes/drivers/redox-driver-sys/source/src/`, `local/recipes/drivers/linux-kpi/source/src/lib.rs` |
+| Quirk-aware device policy | Present, data-driven, shared across drivers | `local/recipes/drivers/redox-driver-sys/source/src/quirks/mod.rs` |
+| Firmware service | Present as real Redox daemon | `local/recipes/system/firmware-loader/source/src/main.rs` |
+| DRM scheme daemon | Present and scheme-backed | `local/recipes/gpu/redox-drm/source/src/main.rs` |
+| KMS ioctl surface | Implemented in shared scheme layer | `local/recipes/gpu/redox-drm/source/src/scheme.rs` |
+| GEM allocation and mapping | Implemented in shared scheme and GEM manager | `local/recipes/gpu/redox-drm/source/src/gem.rs`, `local/recipes/gpu/redox-drm/source/src/scheme.rs` |
+| PRIME and DMA-BUF style sharing | Implemented at scheme level | `local/docs/HARDWARE-3D-ASSESSMENT.md`, `local/docs/DMA-BUF-IMPROVEMENT-PLAN.md`, `local/recipes/gpu/redox-drm/source/src/scheme.rs` |
+| AMD display backend | Build-visible, firmware-aware, interrupt-aware | `local/recipes/gpu/redox-drm/source/src/drivers/amd/mod.rs`, `local/recipes/gpu/amdgpu/source/amdgpu_redox_main.c` |
+| Intel display backend | Build-visible, GGTT and ring scaffolding present | `local/recipes/gpu/redox-drm/source/src/drivers/intel/mod.rs`, `.../intel/ring.rs` |
+| Mesa userland base | Builds with EGL, GBM, OSMesa, software Gallium path | `recipes/libs/mesa/recipe.toml` |
+
+### Hard blockers
+
+| Blocker | Why it matters | Current evidence |
+|---|---|---|
+| General GPU command submission | Modern rendering cannot ship without it | `local/docs/HARDWARE-3D-ASSESSMENT.md` says render CS is still missing |
+| GPU fence and completion signaling | Rendering correctness and sync depend on it | Same assessment calls out missing fences and sync |
+| Runtime validation on real Intel and AMD hardware | Build-only status is not enough for support claims | Canonical desktop plan and desktop current-status doc both say hardware runtime validation is still missing |
+| Mesa hardware winsys and renderer enablement | Hardware 3D path is blocked without it | `recipes/libs/mesa/recipe.toml` still builds `-Dgallium-drivers=swrast` |
+| Imported-buffer GPU mapping and real render path maturity | PRIME sharing alone is not hardware rendering | `local/docs/HARDWARE-3D-ASSESSMENT.md` separates buffer sharing from actual rendering |
+
+## Assessment findings
+
+### 1. Shared substrate is real enough to build on
+
+Red Bear already has the correct architectural layers for modern DRM work:
+
+`redox-driver-sys -> linux-kpi -> firmware-loader -> redox-drm -> vendor backends -> libdrm/Mesa -> compositor/session`
+
+That matters because the repo is not starting from a blank page. The modernization task is mainly about closing runtime and render-path gaps, not replacing the architecture.
+
+Relevant files:
+
+- `local/recipes/drivers/redox-driver-sys/source/src/quirks/mod.rs`
+- `local/recipes/drivers/linux-kpi/source/src/lib.rs`
+- `local/recipes/system/firmware-loader/source/src/main.rs`
+- `local/recipes/gpu/redox-drm/source/src/main.rs`
+
+### 2. Display/KMS maturity is ahead of render/3D maturity
+
+This distinction must stay explicit in all future status claims.
+
+Current evidence shows:
+
+- shared KMS ioctls exist in `scheme.rs`
+- shared GEM create, close, and mmap exist in `gem.rs` and `scheme.rs`
+- PRIME export and import are implemented in `scheme.rs`
+- AMD and Intel display backends both have connector, CRTC, and IRQ-facing structure
+
+Current evidence does **not** show:
+
+- general vendor-usable GPU CS ioctls for modern rendering
+- fence objects or reliable completion waits at production quality
+- Mesa hardware winsys closure and real hardware renderer proof
+
+So the honest state is:
+
+- **Display/KMS:** meaningful build-side maturity, bounded runtime validation still needed
+- **Render/3D:** not mature, blocked on CS, fences, Mesa hardware path, and runtime proof
+
+### 3. Shared DRM core is now a major leverage point
+
+`local/recipes/gpu/redox-drm/source/src/scheme.rs` already centralizes the most important common control plane:
+
+- mode resource queries
+- connector and mode queries
+- CRTC set and page flip
+- dumb buffer and framebuffer lifecycle
+- GEM lifecycle
+- PRIME handle export and import
+- bounded private CS submit and wait entry points
+
+That means shared DRM core work can unblock both vendors, even when vendor-specific render work diverges later.
+
+### 4. Vendor parity must be measured by evidence, not by line count
+
+AMD and Intel are both first-class targets, but they are not symmetric engineering tasks. AMD has heavier firmware and backend complexity. Intel has a smaller stack but still needs the same support bar. The parity rule for this plan is therefore:
+
+> No vendor is considered modern and supported until it clears the same evidence classes for display, render, userland integration, and runtime validation.
+
+## Dependency graph
+
+```text
+Shared substrate
+  redox-driver-sys
+  linux-kpi
+  firmware-loader
+  PCI, IRQ, memory, quirks, firmware runtime
+        |
+        v
+Shared DRM core
+  redox-drm main/scheme/driver/gem
+  KMS, GEM, PRIME, IRQ dispatch, bounded CS surface
+        |
+   +----+-------------------+
+   |                        |
+   v                        v
+Intel track              AMD track
+  display/gtt/ring         display/gtt/ring + amdgpu port
+  connector runtime        firmware-backed display runtime
+  GGTT mapping             GTT and VM programming
+  render path closure      render path closure
+   |                        |
+   +-----------+------------+
+               |
+               v
+Userland integration
+  libdrm
+  Mesa winsys
+  GBM/EGL
+  compositor/session
+               |
+               v
+Validation and acceptance
+  QEMU bounded checks
+  real Intel hardware checks
+  real AMD hardware checks
+  renderer proof
+  regression coverage
+```
+
+## Workstreams
+
+### Workstream A, shared substrate hardening
+
+**Goal:** Make the shared GPU-facing runtime substrate trustworthy enough that later failures are clearly DRM or backend bugs, not basic device-service failures.
+
+**Primary dependencies:** none beyond current repo state.
+
+**Tasks:**
+
+| ID | Task | Why it matters | Repo references |
+|---|---|---|---|
+| A1 | Lock down quirk-source ownership and usage in GPU paths | AMD and Intel need one shared policy source for IRQ, IOMMU, firmware, and accel-disable decisions | `local/recipes/drivers/redox-driver-sys/source/src/quirks/mod.rs` |
+| A2 | Validate runtime firmware service with real GPU-facing requests | AMD display path depends on honest firmware loading behavior | `local/recipes/system/firmware-loader/source/src/main.rs`, `local/recipes/gpu/redox-drm/source/src/main.rs`, `local/recipes/gpu/amdgpu/source/amdgpu_redox_main.c` |
+| A3 | Validate interrupt delivery quality for both vendor paths | Display events, vblank flow, and later fence work depend on this | `local/recipes/gpu/redox-drm/source/src/drivers/interrupt.rs` |
+| A4 | Keep shared substrate acceptance vendor-neutral | Prevent AMD-only or Intel-only claim drift | this plan + `local/docs/CONSOLE-TO-KDE-DESKTOP-PLAN.md` |
+
+**Exit gate:** both Intel and AMD can rely on the same substrate contracts for device discovery, quirks, IRQ policy, and firmware service behavior.
+
+**Current implementation status for A1:**
+
+- `redox-drm` shared-core and Intel init now consume canonical GPU quirk policy at the Rust driver boundary.
+- imported DMA-BUF handles are explicitly kept outside the bounded private CS path in `scheme.rs`.
+- `fsync` no longer pretends to be a successful render-fence contract when no shared sync contract exists.
+- the AMD C backend still logs linux-kpi quirk-informed IRQ expectations, but firmware gating is no longer duplicated there.
+- the PCI quirk extractor foundation has been upgraded so future reviewed GPU quirk imports can rely on explicit handler-body evidence instead of handler-name guessing.
+
+**What A1 does not mean yet:** reviewed Linux 7.0 PCI extraction has not produced enough high-confidence modern Intel/AMD DRM GPU entries to replace the existing hand-authored GPU quirk set. Additional DRM-focused mining and review are still required before quirk-table expansion claims, and Intel-side quirk expansion remains deferred until the Intel runtime policy surface can consume those flags honestly.
+
+**Current PCI ID naming policy:** human-readable PCI vendor/device naming now comes from the shipped
+canonical `pciids` database, while DRM quirk policy remains on the reviewed Red Bear/Linux-backed
+quirk path. Do not use the Linux quirk extractor as a substitute for PCI naming coverage.
+
+**Current implementation status for A2:**
+
+- `redox-drm` now makes Rust-side firmware preload expectations explicit before backend construction.
+- preload policy is now explicit at the Rust DRM startup boundary: AMD still uses the canonical `NEED_FIRMWARE` signal, while the bounded Intel startup path uses a device-manifest-driven DMC requirement for the first covered Intel families.
+- vendors with no Rust-side preload manifest are logged honestly rather than being treated as if firmware had been validated.
+- AMD firmware preload errors now report the checked candidate set and summarize missing blobs, which makes the firmware service evidence surface more useful for runtime validation.
+- both the Rust preload path and the AMD C firmware bridge now reject oversized firmware blobs before allocation, keeping firmware honesty from turning into unbounded memory requests.
+- this is still preload honesty, not final real-hardware firmware-service proof; the runtime validation work in Stage 1 remains required.
+
+**Required Intel follow-up under A2:**
+
+- Red Bear must not treat Intel firmware as an afterthought. When an Intel platform actually needs firmware, the import/preload policy must run from startup at the same Rust-side boundary used for AMD.
+- The Intel firmware classes that matter are distinct and should stay distinct in policy and docs:
+- **DMC** — display-path firmware; required for modern display power management on Gen9+ style platforms
+- **GuC** — scheduler / power-management firmware; important for render/runtime maturity
+- **HuC** — media-offload firmware; optional for some features
+- **GSC** — newer security/authentication controller needed for some modern Intel firmware flows
+- Red Bear now has a bounded Intel-side startup manifest for display-critical **DMC** blobs at the Rust preload boundary.
+- The first bounded implementation currently covers TGL, ADLP, DG2, and MTL DMC startup candidates and treats them as required from startup for the covered device families.
+- Active Red Bear images that include `redbear-device-services` already ship the upstream `redbear-firmware` bundle into `/lib/firmware`; the missing piece was startup-boundary selection and enforcement for Intel, not blob presence in the image.
+- `local/scripts/fetch-firmware.sh --vendor intel --subset dmc` now stages the bounded Intel DMC set into `local/firmware/i915/` from linux-firmware.
+- Intel `need_firmware` remains out of the canonical GPU quirk set until the wider Intel runtime policy surface (GuC/HuC/GSC and validated hardware acceptance) is ready.
+- Future Intel firmware import still expands in this order:
+  1. keep the DMC startup manifest honest and validated,
+  2. add GuC/HuC/GSC only when their runtime consumers exist,
+  3. only then reintroduce any broader Intel `NEED_FIRMWARE` quirk policy.
+
+### Workstream B, shared DRM core completion
+
+**Goal:** Finish the common DRM control plane before pushing more vendor-specific divergence.
+
+**Tasks:**
+
+| ID | Task | Why it matters | Repo references |
+|---|---|---|---|
+| B1 | Audit and stabilize KMS, GEM, and PRIME interfaces as the shared baseline | Both vendors consume the same scheme surface | `local/recipes/gpu/redox-drm/source/src/scheme.rs`, `driver.rs`, `gem.rs` |
+| B2 | Keep command-submission entry points honest and bounded until real backend support exists | Avoid fake hardware-rendering claims | `local/recipes/gpu/redox-drm/source/src/driver.rs`, `scheme.rs` |
+| B3 | Define fence and wait semantics in the shared layer before backend claims expand | Prevent each backend from inventing incompatible completion models | `driver.rs`, IRQ handling in `main.rs` and vendor modules |
+| B4 | Separate display acceptance from render acceptance in all docs and tests | Prevent status inflation | this plan, `local/docs/HARDWARE-3D-ASSESSMENT.md` |
+
+**Exit gate:** Red Bear has one clear shared DRM contract for display and one explicit, evidence-backed roadmap for render completion.
+
+**Current implementation status for B2:**
+
+- `driver.rs` now exposes explicit bounded private CS submit/wait contract types with unsupported backends rejecting them honestly by default.
+- `scheme.rs` validates handle ownership for private CS paths, rejects imported DMA-BUF handles in the bounded path, bounds source/destination ranges against GEM sizes, and returns `EOPNOTSUPP` for fake or unsupported synchronization paths instead of silently succeeding.
+- `scheme.rs` also caps `GEM_CREATE` and `CREATE_DUMB` at a shared-core trusted size limit, and `GemManager` enforces the same cap as a second line of defense.
+- unit tests now cover the shared contract for unsupported waits, imported-buffer rejection, out-of-bounds rejection, local-buffer submission reachability, and `fsync` honesty.
+
+**Current implementation status for B3 groundwork:**
+
+- the raw `(crtc_id, vblank_count)` IRQ tuple path has been replaced with a small shared driver-event model for internal driver → main loop → scheme transport.
+- `scheme.rs` now owns event ingestion through a shared helper, so page-flip retirement remains tied to explicit vblank events while non-vblank events do not pretend to be render completion.
+- both Intel and AMD now forward shared hotplug events through the same internal event path instead of backend-specific side handling.
+- this is structural groundwork only; real fence objects, sync waits, and backend-proven render completion semantics are still not implemented.
+
+### Workstream C, Intel backend maturation
+
+**Goal:** Turn the Intel path from build-visible DRM code into an evidence-backed modern Intel track.
+
+**Tasks:**
+
+| ID | Task | Why it matters | Repo references |
+|---|---|---|---|
+| C1 | Validate connector discovery, modes, and bounded modeset on real Intel hardware | First honest Intel display bar | `local/recipes/gpu/redox-drm/source/src/drivers/intel/mod.rs` |
+| C2 | Add real Intel firmware manifest + startup preload policy at the Rust driver boundary | Intel firmware must be imported from the start when the platform needs it | `local/recipes/gpu/redox-drm/source/src/main.rs`, `.../drivers/intel/mod.rs`, `local/docs/QUIRKS-IMPROVEMENT-PLAN.md` |
+| C3 | Validate GGTT-backed GEM mapping at runtime | Render-path groundwork depends on this | `.../intel/mod.rs`, `.../intel/gtt.rs` |
+| C4 | Close Intel render-ring submission path from bounded proof to usable DRM backend work | Modern rendering needs real command submission | `.../intel/ring.rs`, `.../intel/mod.rs` |
+| C5 | Connect Intel backend completion signaling to shared fence semantics | Render correctness depends on it | `.../intel/mod.rs`, `driver.rs` |
+| C6 | Prove Intel path in userland with Mesa and compositor evidence | Support claims must reach user-visible surfaces | `recipes/libs/mesa/recipe.toml`, compositor/session docs |
+
+**Exit gate:** Intel clears both display acceptance and render acceptance criteria, not just code compilation.
+
+### Workstream D, AMD backend maturation
+
+**Goal:** Turn the AMD path from code-complete display work plus amdgpu port scaffolding into an evidence-backed modern AMD track.
+
+**Tasks:**
+
+| ID | Task | Why it matters | Repo references |
+|---|---|---|---|
+| D1 | Validate firmware-backed connector discovery, modes, and bounded modeset on real AMD hardware | AMD display path is firmware-sensitive | `local/recipes/gpu/redox-drm/source/src/drivers/amd/mod.rs`, `local/recipes/gpu/amdgpu/source/amdgpu_redox_main.c` |
+| D2 | Validate GTT and VM programming against real runtime behavior | Imported and local buffer mapping depend on it | `.../amd/gtt.rs`, `.../amd/mod.rs` |
+| D3 | Expand AMD ring work from bounded copy and page-flip support toward real render submission | PRIME and page flip alone do not produce hardware rendering | `.../amd/ring.rs`, `scheme.rs`, `driver.rs` |
+| D4 | Connect AMD interrupt and completion behavior to shared fence semantics | Stable render completion needs it | `.../amd/mod.rs`, `main.rs` |
+| D5 | Prove AMD path in userland with Mesa and compositor evidence | Support claims must reach user-visible surfaces | `recipes/libs/mesa/recipe.toml`, compositor/session docs |
+
+**Exit gate:** AMD clears both display acceptance and render acceptance criteria, not just backend compilation.
+
+**Current bounded validation tooling:**
+
+- `redbear-drm-display-check` is now the in-guest bounded DRM display checker for Stage 3 entry evidence.
+- `local/scripts/test-drm-display-runtime.sh` provides the shared shell wrapper around that checker.
+- `local/scripts/test-amd-gpu.sh` and `local/scripts/test-intel-gpu.sh` are thin vendor wrappers over that shared harness.
+- The checker now proves connector/mode enumeration directly against the Red Bear DRM ioctl surface and can perform a bounded direct modeset proof. This remains display-only evidence, not render proof.
+
+### Workstream E, userland DRM integration
+
+**Goal:** Turn the working DRM scheme and vendor backends into a userland path that real graphics stacks can use honestly.
+
+**Tasks:**
+
+| ID | Task | Why it matters | Repo references |
+|---|---|---|---|
+| E1 | Keep libdrm aligned with Redox DRM node and PRIME behavior | It is the first userland contract above the scheme | referenced by `local/docs/HARDWARE-3D-ASSESSMENT.md` |
+| E2 | Add real Mesa Redox winsys work for hardware drivers | Hardware rendering is blocked without it | `local/docs/HARDWARE-3D-ASSESSMENT.md`, `local/docs/DMA-BUF-IMPROVEMENT-PLAN.md` |
+| E3 | Move Mesa recipe from software-only evidence to dual software plus hardware candidate builds | Current recipe still proves software only | `recipes/libs/mesa/recipe.toml` |
+| E4 | Keep compositor and session integration downstream from honest DRM evidence | Avoid blaming KWin or Plasma for missing GPU core work | `local/docs/CONSOLE-TO-KDE-DESKTOP-PLAN.md` |
+
+**Exit gate:** userland can distinguish software fallback from true hardware-backed renderers, and the repo has evidence for both cases.
+
+### Workstream F, validation and claims discipline
+
+**Goal:** Make support claims depend on repeatable evidence instead of code presence.
+
+**Tasks:**
+
+| ID | Task | Why it matters |
+|---|---|---|
+| F1 | Maintain separate validation tracks for shared core, Intel, AMD, and userland integration | One passing path must not mask another failing path |
+| F2 | Keep QEMU checks bounded and honest | QEMU is useful for shared control-plane checks, not final hardware claims |
+| F3 | Require real Intel and real AMD evidence before modern support claims | Equal acceptance bar is the heart of this plan |
+| F4 | Treat display and render as separate acceptance surfaces | Avoid overclaiming based on modeset-only proof |
+
+## Milestones and phases
+
+This plan does not reuse the old historical P0-P6 numbering.
+
+### Stage 1, substrate trust for DRM work
+
+**Goal:** Shared device-service and runtime prerequisites are trustworthy enough for GPU validation.
+
+**Must complete:** A1, A2, A3.
+
+**Exit statement:** Shared GPU substrate is credible enough to support vendor DRM validation.
+
+### Stage 2, shared DRM core trust
+
+**Goal:** Shared DRM/KMS, GEM, PRIME, and bounded CS surfaces are stable and honestly documented.
+
+**Must complete:** B1, B2, B3, B4.
+
+**Exit statement:** Red Bear has a stable shared DRM control plane and an explicit line between display proof and render proof.
+
+### Stage 3, vendor display acceptance
+
+**Goal:** Intel and AMD both achieve bounded, evidence-backed display/KMS validation.
+
+**Must complete:** C1 and D1.
+
+**Exit statement:** Both vendors can clear the same display acceptance bar on real hardware.
+
+### Stage 4, vendor render-path closure
+
+**Goal:** Intel and AMD both close their backend-specific command submission and fence gaps enough to support hardware render claims.
+
+**Must complete:** C2, C3, C4, D2, D3, D4, plus shared fence model work from B3.
+
+**Exit statement:** Both vendors have a real render path, not just display and buffer-sharing support.
+
+### Stage 5, userland hardware rendering proof
+
+**Goal:** Mesa, GBM, EGL, and compositor/session layers can exercise the hardware path honestly.
+
+**Must complete:** E1, E2, E3, E4, plus at least one bounded compositor proof on each vendor.
+
+**Exit statement:** The Red Bear desktop path can consume real hardware rendering rather than software fallback.
+
+### Stage 6, support-language cleanup and maintenance mode
+
+**Goal:** Remove temporary shims, stale claims, duplicated policy, and documentation drift left over from bring-up.
+
+**Must complete:** cleanup priorities below.
+
+**Exit statement:** Support claims, code ownership, and docs all describe the same reality.
+
+## Validation matrix
+
+### Evidence classes
+
+| Evidence class | Meaning | Can it support a support claim? |
+|---|---|---|
+| Builds | code compiles and links | No |
+| Bounded runtime | daemon or backend starts and answers limited queries | Not by itself |
+| Real display proof | real hardware modes, connectors, and bounded modeset evidence | Yes, for display only |
+| Real render proof | real hardware renderer path, command submission, completion, visible client rendering | Yes, for render |
+| Regression coverage | repeatable validation that protects the claim | Required to keep the claim |
+
+### Acceptance matrix
+
+| Surface | Shared core | Intel | AMD | Userland |
+|---|---|---|---|---|
+| Scheme registration | required | inherits | inherits | n/a |
+| Connector and mode queries | required | real hardware proof required | real hardware proof required | consumed through libdrm |
+| Modeset | required | real hardware proof required | real hardware proof required | compositor-visible proof required |
+| GEM lifecycle | required | runtime proof required | runtime proof required | Mesa/libdrm use must match |
+| PRIME import/export | required | runtime proof required | runtime proof required | zero-copy handoff proof required |
+| Command submission | shared contract required | real backend proof required | real backend proof required | hardware renderer proof required |
+| Fence and wait semantics | shared contract required | runtime proof required | runtime proof required | compositor and client sync proof required |
+| Hardware-backed renderer | n/a | required for Intel render claim | required for AMD render claim | must be visible as non-LLVMpipe |
+
+## Explicit Intel and AMD parity criteria
+
+Modern Intel and AMD support are at parity only when **both** vendors satisfy all of the following.
+
+### Display parity criteria
+
+- real hardware device detection on the vendor path
+- real connector discovery and stable mode enumeration
+- bounded modeset proof on real hardware
+- bounded post-modeset framebuffer transition evidence on real hardware
+- no dependence on unsupported or fake runtime shortcuts for the claim
+
+### Render parity criteria
+
+- real backend command submission path exists and is exercised
+- completion and wait semantics are real, not stubbed
+- imported and local buffers follow the same lifetime rules the shared DRM core documents
+- Mesa or equivalent userland path can reach a hardware-backed renderer on that vendor
+- compositor or graphics client proof shows hardware path, not LLVMpipe fallback
+
+### Evidence parity criteria
+
+- same evidence class on both vendors for each claim surface
+- same claim discipline in docs and status files
+- same requirement for repeatable validation artifacts before broad support language is used
+
+### Non-goals for parity
+
+Parity does **not** require:
+
+- equal line counts
+- equal implementation strategy
+- equal schedule length
+- identical hardware-family coverage on day one
+
+It does require equal honesty.
+
+## Cleanup priorities
+
+### Priority 1, remove claim drift
+
+- update status language anywhere display progress might be read as hardware render support
+- keep `local/docs/HARDWARE-3D-ASSESSMENT.md`, this plan, and `local/docs/DESKTOP-STACK-CURRENT-STATUS.md` aligned
+- keep Track C language in `local/docs/CONSOLE-TO-KDE-DESKTOP-PLAN.md` aligned with this DRM plan
+
+### Priority 2, converge on one shared policy source
+
+- keep quirk policy centered in `redox-driver-sys`
+- avoid per-driver policy drift for IRQ, firmware, and accel-disable behavior
+- keep `linux-kpi` as a compatibility layer, not a second policy authority
+
+### Priority 3, retire bring-up-only abstractions once real ones exist
+
+- remove temporary bounded CS paths once real backend submission paths replace them
+- remove any stale support wording attached to compile-only features
+- collapse duplicate validation helpers once vendor/runtime coverage is real and stable
+
+### Priority 4, keep userland truth honest
+
+- only expand Mesa driver enablement when the winsys and backend contracts are ready
+- do not treat PRIME completion alone as hardware rendering completion
+- keep compositor and session failures separate from missing DRM core work
+
+## Recommended execution order
+
+1. complete shared substrate trust work
+2. stabilize shared DRM core contracts
+3. validate display/KMS on real Intel and AMD hardware at the same acceptance bar
+4. close backend-specific render submission and fence gaps
+5. enable userland hardware rendering path honestly
+6. clean up temporary bring-up surfaces and support language
+
+## Relationship to existing docs
+
+| Document | Role relative to this plan |
+|---|---|
+| `local/docs/CONSOLE-TO-KDE-DESKTOP-PLAN.md` | Canonical desktop execution plan. This DRM plan is a lower-level execution plan for its hardware GPU track. |
+| `local/docs/HARDWARE-3D-ASSESSMENT.md` | Current factual assessment of the render-path gap. |
+| `local/docs/DMA-BUF-IMPROVEMENT-PLAN.md` | Detailed buffer-sharing and PRIME work beneath the render path. |
+| `local/docs/DESKTOP-STACK-CURRENT-STATUS.md` | Current truth summary for package, runtime, and session state. |
+
+## Final operating rule
+
+Red Bear should speak about Intel and AMD modern DRM support in the same way it speaks about any other first-class subsystem.
+
+Code presence is not support.
+Build success is not support.
+Modeset proof is not render proof.
+One vendor passing does not cover the other.
+
+The claim bar is shared. The implementation paths can differ. The evidence bar cannot.
@@ -1,8 +1,12 @@
 # Red Bear OS: Hardware-Accelerated 3D Assessment

-**Date**: 2026-04-16
+**Date**: 2026-04-18
 **Scope**: AMD + Intel GPU hardware OpenGL/Vulkan for KDE Plasma desktop

+> **Planning authority note (2026-04-18):** this file is the current render-gap assessment and
+> dependency reference. It is no longer the canonical GPU/DRM execution plan; use
+> `local/docs/DRM-MODERNIZATION-EXECUTION-PLAN.md` for sequencing and acceptance criteria.
+
 ## Bottom Line

 PRIME/DMA-BUF cross-process buffer sharing is **now implemented** at the scheme level. GEM
@@ -22,7 +26,7 @@ Mesa (Gallium state tracker → hardware driver)        ← ONLY swrast (CPU), R
        ↓
 libdrm (userspace DRM wrapper)                         ← __redox__ PRIME dispatch ✅, opens /scheme/drm
        ↓
-DRM scheme ioctls (GEM, PRIME, render)                 ← GEM ✅, PRIME ✅ (DmaBuf nodes), render ❌
+DRM scheme ioctls (GEM, PRIME, render)                 ← GEM ✅, PRIME ✅ (DmaBuf nodes), bounded private CS surface ✅, real render path ❌
        ↓
 redox-drm (userspace DRM/KMS daemon)                   ← display ✅, buffer sharing ✅, render ❌
        ↓
@@ -45,9 +49,9 @@ GPU hardware (AMD RDNA / Intel Gen)
 | PRIME scheme ioctls | ✅ Implemented | ~120 | PRIME_HANDLE_TO_FD + PRIME_FD_TO_HANDLE via DmaBuf nodes + export refcounting |
 | libdrm PRIME dispatch | ✅ Implemented | ~30 | __redox__ wrappers: open dmabuf path + fpath-based GEM handle extraction |
 | Mesa Redox winsys | 🚧 Scaffolding | ~4 files | Directory structure + stubs in src/gallium/winsys/redox/drm/ |
-| Render command submission | ❌ Missing | 0 | No CS ioctl, no ring buffer programming |
+| Render command submission | ⚠️ Bounded shared surface only | small shared slice | private CS contract exists, but no vendor-usable render ioctl or ring programming |
 | GPU context management | ❌ Missing | 0 | No context create/destroy |
-| Fence/sync objects | ❌ Missing | 0 | No GPU fence signaling |
+| Fence/sync objects | ❌ Missing | 0 | No shared backend-complete GPU fence signaling |
 | AMD ring buffer | ⚠️ Partial | ~100 | Page flip only, no general command submission |

 ### 2. Mesa Build Configuration
@@ -60,7 +64,7 @@ GPU hardware (AMD RDNA / Intel Gen)
 | EGL | enabled | enabled (same) |
 | GBM | enabled | enabled (same) |
 | `gallium-winsys` | none (swrast doesn't need one) | New Redox winsys for radeonsi/iris |
-| `egl/platform_redox.c` | 540 lines, Orbital-backed | Needs DRM backend for HW buffers |
+| `egl/platform_redox.c` | 540 lines, legacy display-backed | Needs DRM backend for HW buffers |

 ### 3. Kernel Infrastructure

@@ -70,7 +74,7 @@ GPU hardware (AMD RDNA / Intel Gen)
 | Memory scheme (phys mmap) | ✅ | GPU register access works |
 | IRQ scheme (MSI-X) | ✅ | GPU interrupts can be delivered |
 | DMA-BUF fd passing | ✅ Scheme-level | FmapBorrowed + sendfd + DmaBuf nodes enable zero-copy cross-process sharing |
-| GPU fence/wait | ❌ | No GPU completion signaling |
+| GPU fence/wait | ❌ | No shared backend-complete GPU completion signaling |
 | IOMMU/GPU page tables for imports | ❌ | Imported buffers can't be mapped into GPU GTT |

 ## The Render Path Gap
@@ -82,15 +86,19 @@ Mesa Gallium (radeonsi)
  → libdrm open("drm:card0")
  → DRM_IOCTL_GEM_CREATE (allocate GPU buffer)          ← EXISTS
  → DRM_IOCTL_PRIME_HANDLE_TO_FD (export for sharing)   ← ✅ IMPLEMENTED (DmaBuf node + scheme fd)
-  → DRM_IOCTL_AMDGPU_CS (submit commands to GPU)        ← DOES NOT EXIST
+  → bounded private CS submit surface                    ← EXISTS, but not a real vendor render path
+  → DRM_IOCTL_AMDGPU_CS (submit commands to GPU)         ← DOES NOT EXIST
  → fence wait (GPU completion)                          ← DOES NOT EXIST
  → present via KMS (PAGE_FLIP)                          ← EXISTS
 ```

 Steps 1-2 now have full scheme ioctl support with cross-process buffer sharing via DmaBuf scheme
-nodes, sendfd, and FmapBorrowed. Steps 3-4 (command submission, fencing) remain the critical
-gaps. The buffer sharing foundation is in place — compositors and clients can share GPU buffers
-zero-copy. The missing piece is GPU command submission for actual rendering.
+nodes, sendfd, and FmapBorrowed. There is now also a bounded private CS contract used to harden
+shared DRM semantics, but steps 3-4 (real vendor command submission, fencing) remain the critical
+gaps. The shared-core path now also applies explicit allocation caps for GEM and dumb-buffer
+creation. The buffer sharing foundation is in place — compositors and clients can share GPU buffers
+zero-copy. PRIME export now uses opaque non-guessable tokens rather than synthetic fd numbers.
+The missing piece is still GPU command submission for actual rendering.

 ## What Was Implemented

@@ -138,7 +146,7 @@ zero-copy. The missing piece is GPU command submission for actual rendering.
   the buffer's physical pages must be mapped into the GPU's address space. Currently only
   internally-allocated GEM objects get GTT mappings.

-8. **Mesa EGL platform extension** — `platform_redox.c` currently uses Orbital for buffer
+8. **Mesa EGL platform extension** — `platform_redox.c` currently uses the legacy display backend for buffer
   management. It needs an alternative path that uses DRM GEM for hardware-accelerated
   surfaces.

@@ -216,7 +216,7 @@ Input written to `/scheme/input/producer` follows the current legacy route:
 Input written to `/scheme/input/producer/{name}` must be fanned out to:

 1. the matching `DeviceConsumer` handles where `device_name == name`
-2. the existing legacy consumer path used by Orbital and other old clients
+2. the existing legacy consumer path used by older display/input clients

 That means named producers are **supersets** of legacy routing, not replacements.

@@ -535,7 +535,7 @@ Another developer implementing this design should be able to proceed in this ord

 After this enhancement:

- Orbital and any other legacy consumer continue to work as-is.
+- Legacy consumers continue to work as-is.
 - `ps2d` and future drivers can publish stable device names.
 - `evdevd` and similar services can subscribe to exactly one device stream.
 - userspace can enumerate live input devices and react to hotplug events.
@@ -15,6 +15,7 @@ It is grounded in the current repository state, especially:
 - `recipes/core/base/source/drivers/acpid/`
 - `local/docs/IOMMU-SPEC-REFERENCE.md`
 - `local/docs/ACPI-FIXES.md`
+- `local/docs/ACPI-IMPROVEMENT-PLAN.md`
 - `docs/04-LINUX-DRIVER-COMPAT.md`

 The goal is not to restate that these pieces compile, but to separate:
@@ -1,272 +0,0 @@
-# Red Bear OS Phase 0–3 Reassessment
-
-> **DEPRECATED (2026-04-16):** This one-time reconciliation document has been absorbed into the
-> updated `CONSOLE-TO-KDE-DESKTOP-PLAN.md` and `docs/07-RED-BEAR-OS-IMPLEMENTATION-PLAN.md`. It is
-> retained for historical reference only. Do not use it as a current planning source.
-
-## Purpose
-
-This document reconciles the current public execution plan in `docs/07-RED-BEAR-OS-IMPLEMENTATION-PLAN.md`
-with the older hardware-oriented roadmap in `local/docs/AMD-FIRST-INTEGRATION.md`.
-
-The goal is to make Phase 0 through Phase 3 readable in terms of **what is built**, **what is
-boot/runtime wired**, and **what is actually validated**.
-
-## Validation States
-
- **builds** — code or profile compiles successfully
- **boots** — image or service path reaches a usable boot/runtime state
- **validated** — behavior has been exercised with real evidence for the claimed scope
- **experimental** — available for bring-up but not support-promised
-
-This repo should not treat “compiles” as equivalent to “validated”.
-
-## Why this reassessment exists
-
-Two active documents describe the early Red Bear roadmap differently:
-
- `docs/07-RED-BEAR-OS-IMPLEMENTATION-PLAN.md` is the canonical public execution plan.
- `local/docs/AMD-FIRST-INTEGRATION.md` is the older AMD-first technical roadmap.
-
-They are both useful, but they number phases differently:
-
- `docs/07` uses a product-enablement framing (`Phase 1` repository/profile structure, `Phase 2`
-  minimal-system baseline, `Phase 3` driver/runtime substrate).
- `AMD-FIRST` uses a hardware-enablement framing (`P0` ACPI boot, `P1` driver infrastructure,
-  `P2` AMD display, `P3` input + POSIX).
-
-This document is the bridge for Phase 0–3 discussions.
-
-## Phase 0 — Bare-metal boot and ACPI baseline
-
-### Source of truth
-
- `local/docs/AMD-FIRST-INTEGRATION.md`
- Root `AGENTS.md` status summary
-
-### Scope
-
- AMD bare-metal bootability
- ACPI checksums and table handling
- shutdown/reboot/power-method support
- SMP/x2APIC-era platform readiness
-
-### Current status
-
- **builds** — yes
- **boots** — yes
- **validated** — yes, at the platform/boot level described in the AMD-first notes
-
-### Notes
-
-Phase 0 is not part of the public `docs/07` numbering, but it remains a real prerequisite in the
-AMD-first implementation history and should stay visible when discussing early Red Bear progress.
-
-## Phase 1 — Repository discipline and profile reproducibility
-
-### Source of truth
-
- `docs/07-RED-BEAR-OS-IMPLEMENTATION-PLAN.md`
- `local/docs/repo-governance.md`
- `local/docs/PROFILE-MATRIX.md`
-
-### Scope
-
- tracked profile definitions
- shared config fragments instead of duplicated wiring
- helper scripts aligned with tracked profiles
- support-language and validation-language rules
-
-### Current status
-
- **builds** — yes
- **boots** — indirectly supported by later profile builds
- **validated** — partially, in the sense that `redbear-minimal` and `redbear-desktop` were used as
-  reproducibility targets during the Phase 1 cleanup
-
-### Implemented evidence
-
- `config/redbear-*.toml` shared fragment refactor
- `local/docs/repo-governance.md`
- `local/docs/PROFILE-MATRIX.md`
- `local/scripts/build-redbear.sh` profile coverage updates
-
-### Remaining caution
-
-Phase 1 is structurally in good shape, but support labels still need to be used consistently in
-phase-level docs.
-
-## Phase 2 — Minimal-system baseline
-
-### Source of truth
-
- `docs/07-RED-BEAR-OS-IMPLEMENTATION-PLAN.md`
- `local/docs/NETWORKING-RTL8125-NETCTL.md`
- `local/docs/REDBEAR-INFO-RUNTIME-REPORT.md`
-
-### Scope
-
- bootable minimal profile
- package-management baseline
- VM networking baseline
-
-### Current status
-
- **builds** — yes
- **boots** — helper and validation surfaces now exist for the VM path
- **validated** — partially; the repo now has explicit validation helpers, but this still needs
-  continued real runtime use to graduate from baseline bring-up to stronger support claims
-
-### Implemented evidence
-
- `redbear-minimal` enables `wired-dhcp` by default
- `redbear-info` reports VirtIO VM networking visibility
- `local/scripts/validate-vm-network-baseline.sh`
- `local/scripts/test-vm-network-qemu.sh`
- `local/scripts/test-vm-network-runtime.sh`
-
-### Remaining caution
-
-Phase 2 should continue to be described as a **baseline**. It now has build-time, launch-time, and
-runtime check paths, but that is still not the same as broad hardware validation.
-
-## Phase 3 — Driver and runtime substrate
-
-### Source of truth
-
- `docs/07-RED-BEAR-OS-IMPLEMENTATION-PLAN.md`
- `local/docs/AMD-FIRST-INTEGRATION.md`
-
-### Correct framing
-
-The public plan's wording is the correct top-level framing:
-
-> **Driver and runtime substrate**
-
-The AMD-first wording remains useful as a lower-level technical breakdown:
-
-> **Input + POSIX**
-
-These are not competing scopes. The second explains the concrete components that fulfill the first.
-
-### Scope
-
- shared driver substrate already built in-tree
- firmware loading available as runtime infrastructure
- input/runtime prerequisites such as `evdevd` and `udev-shim`
- relibc POSIX surfaces required by downstream consumers
-
-### Current status
-
- **builds** — yes for the major in-tree Phase 3 components
- **boots** — partially wired via profile/service configuration
- **validated** — not yet at the level needed to call the substrate runtime-proven end to end
-
-### Built evidence already in tree
-
- `local/recipes/drivers/redox-driver-sys/`
- `local/recipes/drivers/linux-kpi/`
- `local/recipes/system/firmware-loader/`
- `local/recipes/system/evdevd/`
- `local/recipes/system/udev-shim/`
- `local/patches/relibc/P3-*.patch`
-
-### Real remaining work
-
-The main remaining Phase 3 task is not “invent the substrate” — it already exists in-tree. The
-real gap is **runtime and downstream-consumer validation**:
-
- prove the relibc POSIX surfaces against actual consumers
- prove the input path from Redox input sources through `evdevd` and `udev-shim`
- keep Phase 3 distinct from later graphics/Wayland/KDE work
-
-### Current runtime-validation helpers
-
- `./local/scripts/test-phase3-runtime-substrate.sh` — in-guest runtime check for
-  `firmware-loader`, `udev-shim`, `evdevd`, and their scheme surfaces
- `redbear-info --verbose` — passive runtime evidence for installed/active integrations
-
-### Runtime evidence gathered during reassessment
-
- `redbear-desktop` was booted successfully in QEMU with x86_64 UEFI firmware and reached a real
-  login prompt over the serial console.
- `pcid-spawner` successfully spawned `virtio-netd` during the guest boot sequence.
- `firmware-loader` registered `scheme:firmware` without crashing, even with an empty
-`/lib/firmware/` directory.
- `evdevd` registered `scheme:evdev` and `udev-shim` registered `scheme:udev` during the same
-  guest boot.
- `redbear-info --json` inside the guest reported `virtio_net_present: true`, a configured
-  `eth0` address, and live firmware/udev integration evidence.
-
-## Recommended interpretation going forward
-
-When discussing the roadmap publicly:
-
- use `docs/07` phase numbering as canonical
- treat `AMD-FIRST` phase numbering as historical hardware-roadmap context
- always attach validation language (`builds`, `boots`, `validated`, `experimental`) to claims
-
-## Summary
-
-Phase 0 is the AMD-first bare-metal boot foundation.
-
-Phase 1 is structurally implemented and largely cleaned up.
-
-Phase 2 now has an actual VM-network baseline with repo, launch, and in-guest validation helpers.
-
-One practical caveat surfaced during reassessment: the QEMU launch helper also depends on usable
-x86_64 UEFI firmware on the host. When that firmware is missing, the failure mode is a host-side
-SeaBIOS/iPXE fallback rather than a guest-side Red Bear runtime failure, so the helper now checks
-for that prerequisite explicitly.
-
-Phase 3 should be understood as **runtime-substrate validation and wiring**, not as a brand-new
-infrastructure buildout from zero.
-
-## Quality Assessment
-
-### Planning quality
-
-**Strong points**
-
- The public plan in `docs/07` is clearer and more execution-oriented than the older roadmap.
- Phase 1 and Phase 2 now have concrete helper scripts and docs instead of relying on implicit
-  operator knowledge.
- The profile matrix and governance docs substantially reduce ambiguity about what each tracked
-  profile is supposed to represent.
-
-**Weak points**
-
- Historical phase numbering from `AMD-FIRST-INTEGRATION.md` still differs from the newer public
-  plan, which can confuse progress reporting if the bridge document is not consulted.
- Some status language across the repo still tends to overvalue “builds” relative to “validated”.
-
-### Implementation quality
-
-**Strong points**
-
- Shared Red Bear config fragments reduced duplication in tracked profiles.
- The VM-network baseline now has layered validation surfaces: repo-level, launcher-level, and
-  in-guest runtime checks.
- `redbear-info` remains aligned with real integration changes instead of becoming stale.
-
-**Weak points**
-
- Runtime validation is still thinner than build validation across the early phases.
- Some local operating docs needed follow-up cleanup to reflect the newer scripts and profile set.
-
-### Recommendation
-
-For Phase 0–3 work, prefer closing validation gaps and documentation drift before adding new scope.
-The early-phase codebase is in a much better structural state now; the main quality risk is no
-longer missing packages, but overstating readiness before runtime evidence exists.
-
-## Phase 4 Handoff Note (historical P0–P6 numbering)
-
-> This section uses the old P0–P6 phase numbering. In the v2.0 desktop plan
-> (`local/docs/CONSOLE-TO-KDE-DESKTOP-PLAN.md`), the "Phase 4" below corresponds to Phase 2
-> (Wayland Compositor Proof).
-
-Phase 4 should begin from the existing `wayland.toml` profile, not by jumping straight to KWin.
-The current repo already contains the `smallvil`, `cosmic-comp`, `qtwayland`, and Mesa software
- rendering pieces; the highest-value next work is validating the `orbital-wayland` → `smallvil`
- runtime path on QEMU/VirtIO and only then widening to heavier compositor/session stacks.
@@ -29,11 +29,11 @@ USB plan uses:
 | `redbear-minimal` | Console + storage + wired-network baseline | `minimal.toml`, `redbear-legacy-base.toml`, `redbear-device-services.toml`, `redbear-netctl.toml` | builds / primary validation baseline / DHCP boot profile enabled / input-runtime substrate wired / USB: daemons built via base but not validated or support-scoped for this profile |
 | `redbear-bluetooth-experimental` | First bounded Bluetooth validation profile | `redbear-bluetooth-experimental.toml`, `redbear-bluetooth-services.toml`, `redbear-minimal.toml` | builds / boots in QEMU / packaged Battery Level checker + QEMU harness present / QEMU validation still in progress / explicit-startup USB BLE-first only / not generic GATT / not USB-class-autospawn |
 | `redbear-wifi-experimental` | First bounded Intel Wi-Fi validation profile | `redbear-wifi-experimental.toml`, `redbear-device-services.toml`, `redbear-netctl.toml` | builds / experimental bounded Intel Wi-Fi slice / driver + control/profile/reporting stack present / packaged in-target validation and capture commands available / real hardware connectivity still unproven |
-| `redbear-desktop` | Main Red Bear desktop integration profile without KDE-specific session wiring | `desktop.toml`, `redbear-legacy-base.toml`, `redbear-legacy-desktop.toml`, `redbear-device-services.toml`, `redbear-netctl.toml` | builds / input-runtime substrate wired / runtime reporting installed / USB: xHCI host present + HID keyboard/mouse usable + mass storage autospawns in QEMU / QEMU-validated only / no real hardware USB claim |
-| `redbear-wayland` | v2.0 Phase 2 Wayland compositor validation profile | `wayland.toml` | builds / boots in QEMU / experimental software-path graphics-runtime slice / not QEMU hardware-acceleration proof |
+| `redbear-desktop` | Supplementary Red Bear integration support profile without KDE-specific session wiring | `desktop.toml`, `redbear-legacy-base.toml`, `redbear-legacy-desktop.toml`, `redbear-device-services.toml`, `redbear-netctl.toml` | builds / input-runtime substrate wired / runtime reporting installed / USB: xHCI host present + HID keyboard/mouse usable + mass storage autospawns in QEMU / QEMU-validated only / no real hardware USB claim |
+| `redbear-wayland` | v2.0 Phase 2 Wayland compositor validation profile | `wayland.toml` | builds / boots in QEMU / experimental software-path graphics-runtime slice / validation-only |
 | `redbear-full` | Broader desktop/network/session plumbing (spans v2.0 Phases 2–3) | `desktop.toml`, `redbear-legacy-base.toml`, `redbear-legacy-desktop.toml`, `redbear-device-services.toml`, `redbear-netctl.toml` | builds / boots in QEMU / D-Bus system bus wired / experimental runtime path |
-| `redbear-kde` | v2.0 Phases 3–4 KDE Plasma session-surface profile | `desktop.toml`, `redbear-legacy-base.toml`, `redbear-legacy-desktop.toml`, `redbear-device-services.toml`, `redbear-netctl.toml` | builds / experimental desktop path / D-Bus+seatd+sessiond+KWin session surface wired |
-| `redbear-live` | Live and recovery image layered on desktop | `redbear-desktop.toml` | builds |
+| `redbear-kde` | v2.0 Phases 3–4 KWin Wayland target desktop profile | `desktop.toml`, `redbear-legacy-base.toml`, `redbear-legacy-desktop.toml`, `redbear-device-services.toml`, `redbear-netctl.toml` | builds / tracked KWin desktop direction / D-Bus+seatd+sessiond+KWin session surface wired |
+| `redbear-live` | Live and recovery image layered on desktop | `redbear-kde.toml` | builds / follows the tracked KWin desktop target |

 ## Profile Notes

@@ -69,18 +69,20 @@ USB plan uses:

 ### `redbear-desktop`

- Carries the standard Red Bear desktop-facing package additions.
- Inherits desktop behavior but avoids the heavier KDE session-specific wiring.
+- Carries the standard Red Bear integration package additions.
+- Inherits shared behavior while avoiding the heavier KDE session-specific wiring.
 - Now includes the shared firmware/input runtime service fragment used by the wider desktop bring-up path.
- Also includes `redbear-info`, making the desktop profile the main runtime-reporting integration environment.
+- Also includes `redbear-info`, making this profile a main runtime-reporting integration environment.
+- This remains available as a supplementary integration support profile.

 ### `redbear-wayland`

- Wraps the repo's existing `wayland.toml` into a first-class Red Bear build target.
- Serves as the v2.0 Phase 2 compositor validation surface for `orbital-wayland` and `smallvil`.
- Current verified path: QEMU/UEFI boot to login prompt plus guest-side `redbear-phase4-wayland-check`, with `smallvil` reaching xkbcommon initialization and EGL platform selection on Redox.
+- Wraps the repo's existing `wayland.toml` into a tracked Red Bear validation target.
+- Serves as the v2.0 Phase 2 compositor validation surface.
+- Current verified path: QEMU/UEFI boot to login prompt plus guest-side `redbear-phase4-wayland-check`, with the compositor reaching xkbcommon initialization and EGL platform selection on Redox.
 - Current QEMU renderer evidence is still software-based (`llvmpipe` on the current `-vga std` harness), so this profile must not be described as a hardware-accelerated desktop proof yet.
- Treat this profile as the bounded Wayland/Qt regression harness; the final hardware-desktop claim still belongs to the bare-metal accelerated graphics path.
+- Treat this profile as the bounded Wayland/Qt regression harness.
+- The intended desktop direction is `redbear-kde` with KWin Wayland.

 ### `redbear-full`

@@ -92,14 +94,16 @@ USB plan uses:

 ### `redbear-kde`

- Dedicated profile for Plasma/KWin session bring-up.
+- Dedicated profile for the intended KWin Wayland desktop path.
 - Keep KDE-specific service wiring here instead of leaking it into the generic desktop profile.
 - Current role: carry the KWin session launch surface and its D-Bus/seatd dependencies in one image (v2.0 Phases 3–4).
+- This is the tracked compositor/session direction.

 ### `redbear-live`

 - Intended for install, demo, and recovery workflows.
 - Should inherit only stable desktop-profile assumptions unless explicitly documented.
+- It now inherits `redbear-kde` so the live image follows the tracked desktop direction.

 ## Bluetooth Note

@@ -1,239 +0,0 @@
-# Project Documentation Assessment
-
-> **DEPRECATED (2026-04-16):** This one-time assessment was completed and its findings applied to the
-> documentation set. It is retained for historical reference only. For current documentation status,
-> see `docs/README.md` and the document-status matrix there.
-
-## Purpose
-
-This document assesses the current Red Bear OS documentation set after the repository-model and WIP
-ownership policy updates.
-
-The goal is not only to list documents. The goal is to answer:
-
- which docs are canonical and current
- which docs are still useful but historical
- which areas are well-covered
- which areas still have duplication, stale wording, or split ownership
-
-## Executive Summary
-
-The documentation set is now **directionally strong** and much clearer than before about Red Bear’s
-relationship to upstream Redox. The repository-level model is now visible in the root docs,
-implementation plan, overlay guide, and relibc-specific planning notes.
-
-The strongest documentation theme is now the **overlay discipline**:
-
- RedBearOS is documented as an overlay distribution on top of Redox
- upstream-owned sources are documented as refreshable working copies
- durable Red Bear state is documented as living in `local/patches/`, `local/recipes/`,
-  `local/docs/`, and tracked Red Bear configs
- fast-moving upstream components such as relibc are documented with an upstream-first rule
- upstream WIP is now documented as a local-project trigger for Red Bear until upstream promotes it
-
-That is the right long-term maintenance model.
-
-The main remaining weakness is **documentation fragmentation**. There is now enough good material,
-but some topics are spread across too many files, and some older public docs still speak in a more
-fork-oriented or historically WIP-oriented voice than the newer overlay model.
-
-## Strong Areas
-
-### 1. Repository ownership model
-
-This is now one of the strongest-documented parts of the project.
-
-The model is visible in:
-
- `AGENTS.md`
- `local/AGENTS.md`
- `docs/07-RED-BEAR-OS-IMPLEMENTATION-PLAN.md`
- `docs/README.md`
-
-The key message is now consistent: Red Bear is an overlay on top of Redox, not a permanent fork of
-every upstream-owned source tree.
-
-### 2. relibc maintenance logic
-
-The relibc docs are much stronger than before because they now document both:
-
- the **technical completeness** story
- the **preservation/reapply** story
-
-The most important improvement is that relibc work is no longer described only as source changes in
-`recipes/core/relibc/source/`. It is now also described as a patch-carrier workflow under
-`local/patches/relibc/`, which is the right long-term maintenance framing.
-
-### 3. Subsystem planning depth
-
-USB, Wi-Fi, Bluetooth, IRQ/low-level controller work, relibc IPC, and AMD/graphics all have
-substantial focused planning material under `local/docs/`.
-
-This is good. These are the areas where Red Bear differs most strongly from upstream, so deep local
-planning documents are appropriate.
-
-### 4. Public implementation plan
-
-`docs/07-RED-BEAR-OS-IMPLEMENTATION-PLAN.md` is now doing the right job as the canonical public
-execution-order and repository-model document. It no longer reads like only a historical hardware
-roadmap.
-
-## Weak Areas
-
-### 1. Historical docs still bleed into current-state reading
-
-The older `docs/01`–`docs/05` files still contain valuable architecture and rationale, but some of
-them still carry old assumptions such as:
-
- “WIP means upstream ownership is good enough”
- “missing / not started” wording for areas that are now partially or substantially implemented
- public-facing framing that predates the current overlay-policy language
-
-They are no longer wrong in all details, but they are not all equally safe as current-state guides.
-
-### 2. WIP ownership policy is newly documented, but not yet propagated everywhere
-
-The new WIP rule is now present in the repository model and WIP-specific guide, but there are still
-older docs and notes that talk about `recipes/wip/` as if it were simply the place where future
-shipping work lives.
-
-That is no longer the full policy. For Red Bear, upstream WIP should now be read as:
-
- useful upstream input
- not yet a stable shipping source of truth
- candidate for local takeover until upstream promotes it
-
-This wording should be propagated further over time, especially in older public roadmap docs.
-
-### 3. Script awareness is documented more than enforced
-
-The scripts now explain the overlay/WIP model better, but some of them are still operationally
-neutral. They do not yet encode every policy distinction automatically.
-
-Examples:
-
- `fetch-all-sources.sh` documents the rule, but still fetches upstream WIP sources as raw inputs
- `sync-upstream.sh` documents the rule, but its conflict checks are still strongest for build-system
-  patches, not all subsystem overlays
- `apply-patches.sh` documents the rule, but its actual symlink/application logic is still strongest
-  for the established overlay paths and not for all possible future WIP-local migrations
-
-This is acceptable for now, but it means “policy-aware” is currently stronger in docs than in full
-automation.
-
-### 4. No single canonical doc-index for current-vs-historical status
-
-`docs/README.md` helps, but there is still no one-page matrix saying, for every major document:
-
- canonical current-state source
- architectural rationale only
- historical plan
- Red Bear overlay-specific supplement
-
-That would reduce confusion significantly.
-
-## Canonicality Assessment
-
-### Canonical current-state / policy docs
-
- `AGENTS.md`
- `local/AGENTS.md`
- `docs/07-RED-BEAR-OS-IMPLEMENTATION-PLAN.md`
- `docs/README.md`
- subsystem plans under `local/docs/` that cover active Red Bear-owned workstreams
-
-### Canonical technical local overlays for active subsystems
-
- `local/docs/RELIBC-COMPLETENESS-AND-ENHANCEMENT-PLAN.md`
- `local/docs/RELIBC-IPC-ASSESSMENT-AND-IMPROVEMENT-PLAN.md`
- `local/docs/QT6-PORT-STATUS.md`
- `local/docs/USB-IMPLEMENTATION-PLAN.md`
- `local/docs/WIFI-IMPLEMENTATION-PLAN.md`
- `local/docs/BLUETOOTH-IMPLEMENTATION-PLAN.md`
- `local/docs/IRQ-AND-LOWLEVEL-CONTROLLERS-ENHANCEMENT-PLAN.md`
-
-### Valuable but partially historical docs
-
- `docs/01-REDOX-ARCHITECTURE.md`
- `docs/02-GAP-ANALYSIS.md`
- `docs/03-WAYLAND-ON-REDOX.md`
- `docs/04-LINUX-DRIVER-COMPAT.md`
- `docs/05-KDE-PLASMA-ON-REDOX.md`
-
-These should still be treated as useful references, but their top-level status notes must continue to
-warn readers when current implementation has moved ahead of the original text.
-
-## Documentation Gaps Still Worth Fixing
-
-### Gap 1 — Canonical document-status matrix
-
-**Status:** addressed.
-
-The repo now has a visible document-status matrix in `docs/README.md` that marks the major docs as:
-
- current policy
- current subsystem plan
- architecture reference
- historical roadmap
-
-### Gap 2 — WIP migration ledger
-
-**Status:** addressed.
-
-The repo now has a compact WIP ownership ledger in `local/docs/WIP-MIGRATION-LEDGER.md` that tracks
-which major areas are currently in which state:
-
- still consumed directly from upstream WIP
- mirrored locally and shipped from `local/recipes/`
- promoted upstream again, so Red Bear prefers upstream
-
-This is especially useful for Qt/KDE/Wayland-adjacent work.
-
-### Gap 3 — Script behavior matrix
-
-**Status:** addressed.
-
-The repo now has a concise script behavior matrix in `local/docs/SCRIPT-BEHAVIOR-MATRIX.md`
-covering:
-
- what `sync-upstream.sh` does and does not handle
- what `apply-patches.sh` applies and what it only symlinks
- what `build-redbear.sh` assumes about local overlays
- what `fetch-all-sources.sh` means for upstream WIP versus local recipes
-
-This behavior is now centralized instead of being only inferable from scripts.
-
-### Gap 4 — Public/current Qt and Wayland split
-
-**Status:** addressed.
-
-Qt and Wayland status is still spread across multiple detailed docs, but the repo now has a
-canonical current-state summary in `local/docs/DESKTOP-STACK-CURRENT-STATUS.md` to anchor the
-current build/runtime truth while the older public docs remain useful as history/rationale:
-
- `docs/03-WAYLAND-ON-REDOX.md`
- `docs/05-KDE-PLASMA-ON-REDOX.md`
- `local/docs/QT6-PORT-STATUS.md`
- recipe-local notes
-
-## Recommended Next Documentation Moves
-
-1. Continue pruning local relibc overlays when upstream truly covers them — but only after the
-   fresh-source reapply + rebuild path proves it.
-2. Keep the WIP migration ledger current as upstream WIP areas are promoted or replaced.
-3. Extend the same upstream-first cleanup discipline to other fast-moving system packages,
-   especially the desktop stack.
-4. Periodically re-check older public roadmap docs to ensure their historical notes remain visible
-   and accurate.
-
-## Bottom Line
-
-The project documentation is now fundamentally pointed in the right direction.
-
-Its strongest improvement is conceptual clarity: Red Bear is now documented as an overlay on top of
-Redox, not as a permanently hand-maintained fork of every moving part. The relibc work in
-particular now has both a technical story and a preservation story.
-
-The biggest remaining weakness is not missing information; it is **distribution of information**.
-There is enough good documentation now, but some of it still needs a cleaner canonical index and a
-more explicit split between current policy, current subsystem plans, and historical roadmaps.
@@ -1,6 +1,6 @@
 # Qt6 Port — Red Bear OS

-**Last updated:** 2026-04-16
+**Last updated:** 2026-04-18
 **Qt version:** 6.11.0
 **Target:** x86_64-unknown-redox (cross-compiled from Linux x86_64 host)

@@ -40,7 +40,7 @@
 | **libinput** | ✅ | 1.30.2 with comprehensive redox.patch |
 | **D-Bus** | ✅ | 1.16.2, libdbus-1.so |
 | **KF6 Frameworks** | ✅ 32/32 | All frameworks built |
-| **KWin** | 🔄 | Recipe ready, now using real `libxcvt`, but still blocked by remaining shimmed/stubbed deps and incomplete runtime path |
+| **KWin** | 🔄 | Reduced recipe path now uses real `libxcvt`, `libepoxy`, `lcms2`, and honest `libudev.so` / `libdisplay-info.so` provider linkage, but runtime/session proof is still incomplete |
 | **Hardware acceleration** | ❌ | PRIME/DMA-BUF scheme ioctls implemented; blocked on GPU command submission (CS ioctl) |

 ---
@@ -166,7 +166,7 @@ Plus: QML debug plugins, QtQuick/QML modules staged.

 | Feature | CMake Flag | Status | Notes |
 |---------|-----------|--------|-------|
-| XCB/Xlib | `-DFEATURE_xcb=OFF -DFEATURE_xlib=OFF` | ❌ Disabled | Not applicable — Redox uses Wayland, not X11 |
+| XCB/Xlib | `-DFEATURE_xcb=OFF -DFEATURE_xlib=OFF` | ❌ Disabled | Not applicable — Redox uses Wayland |
 | Vulkan | `-DFEATURE_vulkan=OFF` | ❌ Disabled | No Vulkan runtime on Redox |
 | OpenSSL | `-DFEATURE_openssl=OFF` | ❌ Disabled | OpenSSL3 port in WIP but not validated |
 | qmake | `-DFEATURE_qmake=OFF` | ❌ Disabled | Build tool, not needed with CMake |
@@ -362,7 +362,7 @@ Current truth for Phase 4:

 - the graphics stack now builds end to end: Mesa EGL+GBM+GLES2, libdrm amdgpu, Qt6 OpenGL/EGL,
  and qtwayland all stage successfully
- the current `redbear-wayland` validation profile is still a bounded smallvil-first runtime path,
+- the current `redbear-wayland` validation profile is still a bounded runtime-validation path,
  not proof of a hardware-accelerated desktop session
 - the current QEMU validation harness is still software-rendered (`llvmpipe`) and should be treated
  as a bounded regression/test path, not as the final acceleration proof target
@@ -397,22 +397,21 @@ qt6-wayland-smoke improved to create a visible QWindow:
 - Runs for 3 seconds (previously 1 second, no window)
 - This turns the smoke test from a bootstrap check into a real Wayland surface proof target

-KWin recipe updated — features re-enabled where deps are satisfied:
+KWin recipe updated — features re-enabled where deps are satisfied in the current reduced path:
 - KWIN_BUILD_DECORATIONS=ON (kdecoration builds ✅)
- KWIN_BUILD_GLOBALSHORTCUTS=ON (kglobalaccel builds ✅)
 - KWIN_BUILD_RUNNERS=ON (kf6-kio builds ✅)
- KWIN_BUILD_NOTIFICATIONS=ON (knotifications builds ✅)
 - USE_DBUS=ON (D-Bus 1.16.2 builds ✅)
- Still disabled (9): KCMS, screen locking, tabbox, effects, X11, QML, running-in-kde,
-  signing docs, screenlocker
- Stub deps remaining: libepoxy-stub, libudev-stub, lcms2-stub, libdisplay-info-stub
+- Still disabled (11): global shortcuts, notifications, KCMS, screen locking, tabbox,
+  effects, legacy windowing backend, QML, running-in-kde, signing docs, screenlocker
+- Honest reduced-path providers now integrated into the current recipe: libepoxy, lcms2, libudev, libdisplay-info
+- Remaining limitation in that dependency slice: `libudev` hotplug monitoring is bounded, and `libdisplay-info` is currently base-EDID only (CTA / DisplayID / HDR metadata still unsupported)

 New dependency library:
 - libqrencode 4.1.1 ✅ BUILT (QR code encoder, dependency of kf6-prison)
 - kf6-kwayland ✅
 - seatd builds separately (runtime dependency, not needed for compilation)

-### Phase 6 — KWin (🔄 BUILDING)
+### Phase 6 — KWin (✅ reduced build verifies, 🚧 runtime incomplete)

 ## Dependency Graph

@@ -443,16 +442,16 @@ Phase 1 ✅ (qtbase + qtdeclarative + qtsvg)
   PRIME/DMA-BUF cross-process buffer sharing is implemented at the scheme level.

 4. **relibc / graphics surface still incomplete for runtime** — the build-side `open_memstream` and Wayland-facing header export path now work,
-   but DMA-BUF ioctls, sync objects, and broader graphics runtime validation are still unavailable.
+   and DMA-BUF ioctls plus a bounded private CS surface now exist, but real sync objects/shared fence semantics and broader graphics runtime validation are still unavailable.

 5. **KDE Plasma does NOT compile or run end-to-end** — KWin, plasma-workspace, plasma-desktop recipes exist,
-   but are still blocked on shimmed/stubbed dependencies, runtime integration, and compositor validation.
+   and KWin’s reduced build now verifies with honest `libudev.so` / `libdisplay-info.so` linkage, but runtime integration, compositor validation, and broader Plasma session proof are still missing.

 ## Honest Status Assessment

 The Qt6/KF6 build stack is substantially further along than the earlier "~50%" estimate implied:
 - Qt6, QtWayland, Mesa EGL+GBM, Qt6 OpenGL, libdrm amdgpu, and all 32 KF6 frameworks now build
- the remaining blockers are concentrated in KWin/Plasma runtime integration and in the still-shimmed or stub-only packages such as Kirigami, libepoxy, libudev, lcms2, and libdisplay-info
+- the remaining blockers are concentrated in KWin/Plasma runtime integration and in the still-shimmed or stub-only packages such as Kirigami, plus the bounded-not-full provider behavior of `libudev` and `libdisplay-info` in the current reduced KWin path
 - hardware acceleration still requires GPU command submission and real hardware validation (PRIME/DMA-BUF buffer sharing is implemented)
 - a successful build stack is not yet the same thing as a working KDE Plasma session

@@ -18,11 +18,24 @@ Completed from this plan:
 - shipped DMI TOML overrides in the brokered `pcid-spawner` env-var path,
 - direct canonical `redox-driver-sys` quirk lookup from `pcid-spawner` instead of a separate in-tree PCI quirk engine,
 - real USB device quirk consumption in `xhcid`,
- first real linux-kpi quirk consumption in the Red Bear amdgpu path.
+- first real linux-kpi quirk consumption in the Red Bear amdgpu path,
+- canonical GPU quirk policy moved to the Rust driver boundary in `redox-drm`, so Intel and AMD now consume one shared quirk source for init-time policy,
+- PCI quirk extraction upgraded from handler-name guessing to explicit handler-body evidence in `local/scripts/extract-linux-quirks.py`.

 Still open after this implementation wave:

- no remaining implementation items in the current quirks scope.
+- document the provenance of existing AMD `need_firmware` entries in `quirks.d/10-gpu.toml`,
+- keep AMD device-specific GPU quirk growth review-gated on Linux-backed evidence,
+- keep Intel GPU quirk expansion deferred until Red Bear has a real Intel-side firmware/runtime
+  policy surface that can honestly consume additional flags.
+
+Current naming/source split:
+
+- PCI vendor/device **names** now come from the shipped `pciids` database (`/usr/share/misc/pci.ids`).
+- PCI/USB/storage **quirk flags** still come from Red Bear’s canonical quirk path: compiled tables,
+  shipped TOML files, and conservative Linux-source extraction where applicable.
+- The `extract-linux-quirks.py` script remains a quirk-mining tool, not the source of human-readable
+  PCI device names.

 The runtime-behavior milestone from this plan is now implemented. The remaining work is
 maintenance, validation depth, and future refinement rather than missing quirks behavior for the
@@ -49,7 +62,7 @@ It is based on the current in-tree state of:
 ### What is still weak

 - USB quirks now have a first real runtime consumer in `xhcid`, but broader USB-driver adoption is still missing.
- The `linux-kpi` bridge now has a first real in-tree C consumer: amdgpu uses it for firmware gating and quirk-aware IRQ expectation logging. Broader C-driver adoption is still missing.
+- The `linux-kpi` bridge now has a first real in-tree C consumer: amdgpu uses it for quirk-aware IRQ expectation logging. Broader C-driver adoption is still missing.
 - `pcid-spawner` still synthesizes a partial `PciDeviceInfo` instead of reusing a richer canonical PCI object, because it operates as an upstream-owned broker with a narrow interface.

 ### What should not be “fixed” in the wrong layer
@@ -120,13 +133,33 @@ Scope:
 Goals:

 - avoid mapping Linux flags to incorrect Red Bear flags,
- clearly mark heuristic extraction limits for PCI handler-name mode.
+- clearly mark the supported explicit PCI extraction patterns and the limits of unsupported handlers.

 QA:

 - run the script on a small synthetic USB/PXI input sample,
 - confirm output omits unsupported PCI flag mappings instead of inventing equivalents.

+Current state:
+
+- `local/scripts/extract-linux-quirks.py` no longer guesses PCI quirks from handler names.
+- PCI extraction now maps only explicit handler-body evidence for supported `PCI_DEV_FLAGS_*`
+  assignments plus `pci_d3cold_disable(...)`.
+- Running the upgraded extractor on Linux 7.0 `drivers/pci/quirks.c` currently yields only a
+  very small high-confidence PCI subset and no directly usable modern Intel/AMD DRM GPU entries.
+- This is intentional: false negatives are preferred over wrong GPU quirk claims.
+- The existing AMD `need_firmware` entries in `quirks.d/10-gpu.toml` are manually reviewed policy
+  entries, not extractor-produced Linux facts. Future extraction runs will not refresh those flags
+  automatically.
+- Intel firmware classes should be treated explicitly: DMC for display power management, GuC for
+  scheduling/power, HuC for media offload, and GSC for newer authentication flows.
+- Red Bear now has a bounded Intel DMC startup manifest/preload path for the first supported Intel
+  device families, but Intel `need_firmware` must still stay out of the canonical GPU quirk set
+  until the broader Intel runtime policy surface is real and validated.
+- AMD device-specific GPU quirk growth remains review-gated on explicit Linux-backed evidence.
+- Intel GPU quirk expansion is deferred until Red Bear has a real Intel-side firmware/runtime
+  policy surface that can honestly consume additional flags.
+
 ### Wave 2 — Unify PCI quirk semantics

 #### Task 2.1: Eliminate semantic drift between `pcid-spawner` and `redox-driver-sys`
@@ -229,8 +262,9 @@ Success criteria:
 Current state:

 - `local/recipes/gpu/amdgpu/source/amdgpu_redox_main.c` now queries linux-kpi PCI quirks in the real Redox runtime path,
- `PCI_QUIRK_NEED_FIRMWARE` turns missing DMCUB firmware into an init failure instead of a warning-only fallback,
- logs now show the active quirk bitmask plus the implied IRQ fallback policy.
+- logs now show the active quirk bitmask plus the implied IRQ fallback policy,
+- firmware policy has been pulled back to the Rust-side driver boundary so the C backend does not
+  re-enforce `NEED_FIRMWARE` independently.

 QA:

@@ -253,6 +287,17 @@ QA:

 - driver code path shows firmware gating tied to quirks or explicit device rules.

+Current state:
+
+- `local/recipes/gpu/redox-drm/source/src/drivers/intel/mod.rs` now reads the canonical
+  `info.quirks()` policy during init, rejects `DISABLE_ACCEL`, and explicitly warns if
+  `NEED_FIRMWARE` appears on Intel instead of silently ignoring quirk policy.
+- `local/recipes/gpu/redox-drm/source/src/main.rs` now makes firmware preload expectations explicit
+  at the Rust-side driver boundary, reports whether preload is quirk-required, and summarizes
+  missing candidate blobs when preload cannot satisfy the current policy.
+- `local/recipes/gpu/amdgpu/source/amdgpu_redox_main.c` still consumes linux-kpi quirks for
+  runtime expectations, but it no longer owns the final firmware gating decision.
+
 ### Wave 4 — DMI completion

 #### Task 4.1: DMI TOML runtime loading
@@ -358,7 +358,7 @@ the honest breakdown.
 - redox-drm: `NO_MSIX`, `NO_MSI`, `FORCE_LEGACY_IRQ`, `DISABLE_ACCEL` (interrupt setup + driver probe)
 - xhcid: `RESET_DELAY_MS`, `NO_MSI`, `NO_MSIX`, `FORCE_LEGACY_IRQ` (interrupt selection + port reset delay)
 - xhcid (USB device path): `NO_STRING_FETCH`, `BAD_DESCRIPTOR`, `RESET_DELAY`, `HUB_SLOW_RESET`, `NO_BOS`, `SHORT_SET_ADDR_TIMEOUT`, `FORCE_ONE_CONFIG`, `HONOR_BNUMINTERFACES`, `DELAY_CTRL_MSG`, `NO_SET_CONFIG`, `NO_SET_INTF`, `NEED_RESET`, `NO_SUSPEND` (enumeration/configuration/BOS/runtime recovery plus suspend gating)
- amdgpu: `NEED_FIRMWARE` (hard firmware gate), with real quirk-aware logging for `NO_ASPM`, `NEED_IOMMU`, `NO_MSI`, `NO_MSIX`
+- amdgpu: startup firmware requirement enforced at the Rust DRM boundary, with real quirk-aware runtime logging for `NO_ASPM`, `NEED_IOMMU`, `NO_MSI`, `NO_MSIX`

 **Infrastructure (data flows, reporting, and partial integration):**
 - pcid-spawner: computes `PCI_QUIRK_FLAGS` by calling the canonical `redox-driver-sys` lookup on synthesized `PciDeviceInfo`, then passes the env var onward
@@ -375,7 +375,12 @@ the honest breakdown.
 **Defined but not yet consumed by any real driver path:**
 - `NO_PM`, `NO_D3COLD`, `DMA_32BIT_ONLY`, `BUS_MASTER_DELAY`, `NO_IOMMU`, etc.

-`firmware-loader` itself does not interpret `NEED_FIRMWARE`; that policy is now enforced in the amdgpu driver path instead.
+`firmware-loader` itself does not interpret `NEED_FIRMWARE`; that policy is now enforced at the Rust-side DRM startup boundary instead.
+
+Active Red Bear images that include `redbear-device-services` already ship the upstream
+`redbear-firmware` bundle into `/lib/firmware`. The bounded Intel DMC work therefore selects and
+requires the right startup blobs from that shipped firmware set, rather than depending on the user
+to fetch firmware at runtime.

 For early xhcid timing quirks, `[[usb_quirk]]` entries may also carry `port = "1.2.3"` selectors.
 Those selectors are used only for pre-descriptor timing flags (`RESET_DELAY`, `HUB_SLOW_RESET`,
@@ -13,9 +13,9 @@ The goal is to remove guesswork from the sync/fetch/apply/build workflow.
 |---|---|---|---|
 | `local/scripts/sync-upstream.sh` | Refresh top-level upstream repo state | fetches upstream, reports conflict risk, rebases repo commits, reapplies build-system overlays via `apply-patches.sh` | does not automatically solve every subsystem overlay conflict; does not by itself make upstream WIP recipes safe shipping inputs |
 | `local/scripts/apply-patches.sh` | Reapply durable Red Bear overlays | applies build-system patches, relinks recipe patch symlinks, relinks local recipe overlays into `recipes/` | does not fully rebase stale patch carriers; does not validate runtime behavior; does not decide WIP ownership for you |
-| `local/scripts/build-redbear.sh` | Build Red Bear profiles from upstream base + local overlay | applies overlays, builds cookbook if needed, validates profile naming, launches the actual image build | does not guarantee every nested upstream source tree is fresh; does not replace explicit subsystem/runtime validation |
-| `scripts/fetch-all-sources.sh` | Fetch recipe source inputs for builds | downloads recipe sources for upstream and local recipes, reports status/preflight, supports config-scoped fetches | does not mean fetched upstream WIP source is the durable shipping source of truth |
-| `local/scripts/fetch-sources.sh` | Fetch local overlay source inputs | fetches local overlay recipe sources and keeps the local side ready for build work | does not decide whether upstream should replace the local overlay |
+| `local/scripts/build-redbear.sh` | Build Red Bear profiles from upstream base + local overlay | applies overlays, builds cookbook if needed, validates profile naming, launches the actual image build; only allows upstream recipe refresh when passed `--upstream` | does not guarantee every nested upstream source tree is fresh; does not replace explicit subsystem/runtime validation |
+| `scripts/fetch-all-sources.sh` | Fetch mainline recipe source inputs for builds | downloads mainline/upstream recipe sources, reports status/preflight, and supports config-scoped fetches while leaving local overlays in place | does not mean fetched upstream WIP source is the durable shipping source of truth |
+| `local/scripts/fetch-sources.sh` | Fetch mainline recipe sources for browsing and patching | when passed `--upstream`, fetches `recipes/*` source trees so the upstream-managed side is locally available for reading, editing, and patch preparation | does not decide whether upstream should replace the local overlay |
 | `local/scripts/build-redbear-wifictl-redox.sh` | Build `redbear-wifictl` for the Redox target with the repo toolchain | prepends `prefix/x86_64-unknown-redox/sysroot/bin` to `PATH` and runs `cargo build --target x86_64-unknown-redox` in the `redbear-wifictl` crate | does not prove runtime Wi-Fi behavior; only closes the target-build environment gap for this crate |
 | `local/scripts/test-iwlwifi-driver-runtime.sh` | Exercise the bounded Intel driver lifecycle inside a target runtime | validates bounded probe/prepare/init/activate/scan/connect/disconnect/retry surfaces for `redbear-iwlwifi` on a live target runtime | does not prove real AP association, packet flow, DHCP success over Wi-Fi, or end-to-end connectivity |
 | `local/scripts/test-wifi-control-runtime.sh` | Exercise the bounded Wi-Fi control/profile lifecycle inside a target runtime | validates `/scheme/wifictl` control nodes, bounded connect/disconnect behavior, and profile-manager/runtime reporting surfaces on a live target runtime | does not prove real AP association or end-to-end connectivity |
@@ -23,6 +23,9 @@ The goal is to remove guesswork from the sync/fetch/apply/build workflow.
 | `local/scripts/test-wifi-passthrough-qemu.sh` | Launch Red Bear with VFIO-passed Intel Wi-Fi hardware | boots a Red Bear guest with a passed-through Intel Wi-Fi PCI function, auto-runs the in-guest bounded Wi-Fi validation command, and can copy the packaged capture bundle back to a host-side file during `--check` | depends on host VFIO setup and still does not by itself guarantee real AP association or end-to-end Wi-Fi connectivity |
 | `local/scripts/test-bluetooth-runtime.sh` | Compatibility guest entrypoint for the bounded Bluetooth Battery Level slice | runs the packaged `redbear-bluetooth-battery-check` helper inside a Redox guest or target runtime | does not run on the host and does not expand the Bluetooth support claim beyond the packaged checker’s bounded scope |
 | `local/scripts/test-bluetooth-qemu.sh` | Launch or validate the bounded Bluetooth Battery Level slice in QEMU | boots `redbear-bluetooth-experimental`, auto-runs the packaged checker during `--check`, reruns it in one boot, and reruns it again after a clean reboot | does not by itself guarantee that the current QEMU proof passes; does not prove real controller bring-up, generic BLE/GATT maturity, write/notify support, or real hardware Bluetooth behavior |
+| `local/scripts/test-drm-display-runtime.sh` | Run the bounded DRM/KMS display checker in a target runtime | invokes the packaged `redbear-drm-display-check` helper for AMD or Intel, proving scheme/card reachability, connector/mode enumeration, and bounded direct modeset proof over the Red Bear DRM ioctl surface when requested | does not prove render command submission, fence semantics, or hardware rendering |
+| `local/scripts/test-amd-gpu.sh` | AMD wrapper for the bounded DRM/KMS display checker | runs `test-drm-display-runtime.sh --vendor amd` | still only display-path evidence |
+| `local/scripts/test-intel-gpu.sh` | Intel wrapper for the bounded DRM/KMS display checker | runs `test-drm-display-runtime.sh --vendor intel` | still only display-path evidence |
 | `local/scripts/prepare-wifi-vfio.sh` | Prepare or restore an Intel Wi-Fi PCI function for passthrough | binds a chosen PCI function to `vfio-pci` or restores it to a specified host driver | does not verify guest Wi-Fi functionality and must be used carefully on a host with a safe detachable target device |
 | `local/scripts/validate-wifi-vfio-host.sh` | Check whether a host looks ready for Wi-Fi VFIO testing | validates PCI presence, current driver, UEFI firmware, Red Bear image presence, QEMU/expect availability, VFIO module state, and IOMMU group visibility; exits non-zero when blockers are found | does not bind devices or prove the guest Wi-Fi stack works |
 | `local/scripts/run-wifi-passthrough-validation.sh` | End-to-end host-side passthrough validation wrapper | prepares VFIO, runs the packaged in-guest Wi-Fi validation path, captures the guest JSON artifact to the host, writes a host-side metadata sidecar, and restores the host driver afterwards | still depends on real VFIO/hardware support and does not itself guarantee end-to-end Wi-Fi connectivity |
@@ -38,6 +41,11 @@ perform the bounded Bluetooth Battery Level checks from inside the guest/runtime
 repeated helper runs, daemon-restart coverage, failure-path honesty checks, and stale-state cleanup
 checks within the current slice boundary.

+The packaged DRM display companion command is `redbear-drm-display-check`, which is intended to
+perform bounded DRM/KMS display-side checks from inside the guest/runtime itself. It now covers
+direct connector/mode enumeration and bounded direct modeset proof over the Red Bear DRM ioctl
+surface, and explicitly does not claim render or hardware-accelerated graphics completion.
+
 The packaged evidence companion is `redbear-phase5-wifi-capture`, which collects the bounded driver,
 control, profile-manager, reporting, interface-listing, and scheme-state surfaces — plus `lspci`
 and active-profile contents — into a single JSON artifact.
@@ -69,19 +77,22 @@ This is the core durable-state recovery path.
 ### Build execution

 Use `local/scripts/build-redbear.sh` when the goal is to build a tracked Red Bear profile from the
-current upstream base plus local overlay.
+current upstream base plus local overlay. Add `--upstream` only when you explicitly want Redox/upstream
+recipe sources refreshed during that build.

 ### Source refresh

-Use `scripts/fetch-all-sources.sh` and `local/scripts/fetch-sources.sh` when the goal is to refresh
-recipe source inputs, but do not confuse fetched upstream WIP source with a trusted shipping source.
+Use `scripts/fetch-all-sources.sh` and `local/scripts/fetch-sources.sh --upstream` when the goal is to
+refresh recipe source inputs, but do not confuse fetched upstream WIP source with a trusted shipping
+source.

 ## WIP Rule in Script Terms

 If a subsystem is still upstream WIP, the scripts should be interpreted this way:

- fetching upstream WIP source is allowed and useful,
- syncing upstream WIP source is allowed and useful,
+- fetching upstream WIP source is allowed and useful through the explicit upstream fetch commands or
+  `--upstream` where a wrapper requires it,
+- syncing upstream WIP source is allowed and useful through the explicit upstream sync command,
 - but shipping decisions should still prefer the local overlay until upstream promotion and reevaluation happen.

 That means “script fetched it successfully” is not the same as “Red Bear should now ship upstream’s
@@ -435,10 +435,10 @@ tar xf build/linux-kernel-cache/linux-7.0.tar.xz -C build/linux-kernel-cache/
 quirk entries. Handles three source formats:
 - `drivers/usb/core/quirks.c` → `[[usb_quirk]]` TOML entries (146 entries from Linux 7.0)
 - `drivers/usb/storage/unusual_devs.h` → `[[usb_storage_quirk]]` TOML entries (214 entries from Linux 7.0)
- `drivers/pci/quirks.c` → `[[pci_quirk]]` TOML entries (heuristic flag mapping, requires review)
+- `drivers/pci/quirks.c` → `[[pci_quirk]]` TOML entries (explicit high-confidence handler-body mappings only, requires review)

-USB quirk extraction is direct and does not require review. PCI quirk extraction is heuristic and
-requires manual review before committing.
+USB quirk extraction is direct and does not require review. PCI quirk extraction now emits only
+explicit high-confidence handler-body mappings and still requires manual review before committing.

 The extraction script needs extension to also handle `drivers/usb/storage/unusual_devs.h` for mass
 storage device entries (323 entries, different macro format `UNUSUAL_DEV`).
@@ -232,13 +232,13 @@ command = ["usbhidd", "$SCHEME", "$PORT", "$IF_NUM"]
 | Device Class | Daemon | Scheme Path | Integration |
 |---|---|---|---|
 | **Hub** (class 9) | `usbhubd` | Manages child ports via xhci scheme | Triggers nested device enumeration |
-| **HID** (class 3) | `usbhidd` | Writes to `/scheme/input/producer` via inputd | Orbital consumes `/scheme/input` |
+| **HID** (class 3) | `usbhidd` | Writes to `/scheme/input/producer` via inputd | Legacy display/input consumers read `/scheme/input` |
 | **Mass Storage** (class 8) | `usbscsid` | Registers `disk.usb-{scheme}+{port}-scsi` | Filesystems mount via scheme path |

 ### HID Integration Detail

 ```
-USB keyboard/mouse → xhcid → usbhidd → inputd (scheme:input) → Orbital (display server)
+USB keyboard/mouse → xhcid → usbhidd → inputd (scheme:input) → display/input consumer
                                                      ↑
                                           /scheme/input/producer  (drivers write here)
                                           /scheme/input/consumer  (display server reads here)
@@ -63,23 +63,23 @@ experimental only.

 ### `redbear-desktop`

-Main integration profile for desktop-oriented Red Bear services without making KDE the default.
+Supplementary integration support profile for shared Red Bear runtime services beneath the tracked KWin target.

 ### `redbear-full`

-Expanded desktop/integration target that includes more runtime pieces and graphics-path bring-up.
+Expanded integration slice that includes more runtime pieces and graphics-path bring-up beneath the tracked KWin target.

 ### `redbear-wayland`

-Dedicated Wayland runtime validation profile layered above the current Red Bear service baseline.
+Dedicated Wayland runtime validation profile layered above the current Red Bear service baseline and subordinate to the tracked KWin direction.

 ### `redbear-kde`

-Dedicated KDE/Plasma bring-up profile.
+Dedicated KDE/Plasma bring-up profile and tracked forward desktop target.

 ### `redbear-live`

-Live and recovery variant layered on top of the Red Bear desktop path.
+Live and recovery variant layered on top of the tracked KWin desktop target.

 ## Change Checklist