docs: update local driver-manager execution notes

local/docs/CONSOLE-TO-KDE-DESKTOP-PLAN.md

@@ -245,7 +245,7 @@ kirigami blocks plasma-framework, which blocks plasma-workspace, which blocks th
 
 ### 4.1 Wired Networking — Working
 
-- Native Redox net stack present (`pcid-spawner` → NIC daemon → `smolnetd`/`dhcpd`/`netcfg`)
+- Native Redox net stack present (`driver-manager` → NIC daemon → `smolnetd`/`dhcpd`/`netcfg`; `pcid-spawner` remains a compatibility alias)
 - `redbear-netctl` native command shipped
 - RTL8125 autoload wired through Realtek path
 - VirtIO networking in QEMU: `DBUS_SYSTEM_BUS=present`

local/docs/DBUS-INTEGRATION-PLAN.md

@@ -252,7 +252,7 @@ Complete Plasma needs (after re-enabling disabled components):
 │                     Redox Schemes (native IPC)                           │
 │   scheme:input → evdevd → /dev/input/eventX                             │
 │   scheme:drm → redox-drm → DRM/KMS                                      │
-│   scheme:pci → pcid-spawner → PCI device access                         │
+│   scheme:pci → driver-manager → PCI device access                        │
 │   scheme:net → netd → network interfaces                                │
 │   scheme:firmware → firmware-loader → GPU blobs                         │
 │   scheme:acpi → acpid → ACPI/DMI data                                   │
@@ -741,7 +741,7 @@ org.freedesktop.DBus (dbus-daemon — always present)
 ```
 Layer 1: Redox Schemes (kernel-enforced capability security)
   ├── scheme:drm — only accessible to processes with explicit FD
-  ├── scheme:pci — only accessible to pcid-spawner-launched drivers
+  ├── scheme:pci — only accessible to driver-manager-launched drivers
   ├── scheme:input — only accessible to evdevd (which creates /dev/input/)
   └── scheme:net — only accessible to network daemons
 

local/docs/IRQ-AND-LOWLEVEL-CONTROLLERS-ENHANCEMENT-PLAN.md

@@ -9,7 +9,8 @@ This is the **canonical current implementation plan** for PCI interrupt plumbing
 MSI/MSI-X quality, low-level controller runtime proof, and IOMMU/interrupt-remapping follow-up
 work.
 
-When another document discusses PCI, IRQ, MSI/MSI-X, `pcid`, `pcid-spawner`, or low-level
+When another document discusses PCI, IRQ, MSI/MSI-X, `pcid`, `driver-manager`, legacy
+`pcid-spawner`, or low-level
 controller execution order, prefer this file for:
 
 - the current robustness judgment,
@@ -136,7 +137,8 @@ The strongest layers are:
 
 The weakest layers are:
 
-- `pcid` and `pcid-spawner`,
+- `pcid`, the active `driver-manager` handoff path, and the retained `pcid-spawner` compatibility
+  alias,
 - the `pcid` driver-interface helper surface,
 - the shared `virtio-core` MSI-X setup path,
 - and several upstream-owned base drivers that still panic on missing BARs, missing interrupt
@@ -159,8 +161,10 @@ The weakest layers are:
 
 ### What is still fragile today
 
-- `pcid` and `pcid-spawner` still assume a trusted environment too often: launch sequencing,
-  device-enable timing, and several error paths are weaker than the substrate beneath them.
+- `pcid` and the PCI driver orchestration layer still assume a trusted environment too often:
+  launch sequencing, device-enable timing, and several error paths are weaker than the substrate
+  beneath them. The active Red Bear boot path now uses `driver-manager`; historical `pcid-spawner`
+  hardening remains relevant only for compatibility aliases and upstream-owned fallback context.
 - `pcid` helper files such as `driver_interface/{bar,cap,irq_helpers,msi}.rs` still treat several
   malformed-device or unsupported-state cases as invariants rather than recoverable failures.
 - `virtio-core` still hard-requires MSI-X in its active x86 path and uses assert/expect/
@@ -592,14 +596,16 @@ The remaining work should be executed in six waves. The order matters: shared co
 helper hardening comes before broad driver cleanup, and runtime-proof/observability comes before any
  stronger public claim language.
 
-### Wave 1 — Harden `pcid` / `pcid-spawner` orchestration
+### Wave 1 — Harden `pcid` / `pcid-spawner` orchestration, then migrate active launch to `driver-manager`
 
-**Status**: ✅ Complete (Wave 1 hardening applied)
+**Status**: ✅ Complete (Wave 1 hardening applied; Red Bear active launch path is now
+`driver-manager`, with `pcid-spawner` retained as compatibility/fallback context)
 
 **Primary targets**
 
 - `recipes/core/base/source/drivers/pcid/src/{main,scheme,driver_handler}.rs`
 - `recipes/core/base/source/drivers/pcid-spawner/src/main.rs`
+- `local/recipes/system/driver-manager/source/src/`
 
 **Implemented**
 
@@ -609,17 +615,23 @@ helper hardening comes before broad driver cleanup, and runtime-proof/observabil
 - I/O BAR port overflow now logs and skips the BAR instead of panicking
 - MSI message data overflow returns `InvalidBitPattern` error response instead of panicking
 - pcid-spawner now logs interrupt mode, device address, and driver command for each spawned device
+- driver-manager now owns the active Red Bear device-spawn lifecycle, records JSON boot-timeline
+  evidence (`bus_enumerated`, `bus_enumeration_failed`, `probe`), and exposes
+  `scheme:driver-manager` for runtime inspection
 
 **Acceptance**
 
 - ✅ no normal launch/config mismatch path depends on `expect`/`unreachable!` in main.rs/driver_handler.rs
 - ✅ failed driver launch is bounded and observable
 - ✅ enable-before-spawn behavior is explicitly logged with interrupt mode info
+- ✅ active runtime diagnostics consume driver-manager timeline evidence instead of requiring legacy
+  pcid-spawner phase0 log text
 
 **Verification**
 
 - `cargo test -p pcid`
 - `cargo test -p pcid-spawner`
+- `cargo check --manifest-path local/recipes/system/driver-manager/source/Cargo.toml`
 - verify `redbear-info` still reports the expected PCI surfaces after boot
 
 ### Wave 2 — Fix `pcid` helper contract