Board result: PipeWire services active, two real bugs found and fixed

Evidence class: board observation, relayed — the coordinator ran this directly against a flashed/test-activated board (system z3zbk6gx8j5gd2pzamrzg5vapa0bjwnd, this branch’s own commit before the fixes below) and reported the result back; this worktree never touched /dev/ttyACM0 or the board itself (AGENTS.md). What follows is the coordinator’s own report, not a console transcript captured here — a weaker citation than a committed boot log, but still a tier-1 board observation, not an inference.

What was confirmed working

pipewire, wireplumber, and pipewire-pulse are all reported active on the board (task 1.4’s first half).

Bug 1: only a “Dummy Output” sink

The shell user was not in the audio group (id shell showed shell, video, input, seat only), and /dev/snd/* ships root:audio 0660 — WirePlumber’s ALSA monitor could not open card 0 (K230_I2S_ INNO) at all. The coordinator confirmed the diagnosis directly: a temporary chmod o+rw /dev/snd/* plus restarting the three services produced Built-in Audio Stereo as the real default sink/source; that chmod does not survive a reboot.

Fix: nix/shell.nix’s users.users.shell.extraGroups now includes "audio", declaratively — the same group /dev/snd/*’s own udev rule already grants access to, with no per-unit SupplementaryGroups override needed since every PipeWire-adjacent process already runs as User = "shell".

Bug 2: `wpctl`/`pw-dump`/`pw-cli` unreachable from the running client

wpctl was on neither the system PATH nor the Rust client’s own PATH (its /proc/<pid>/environ had no wireplumber path) — every mute tap, drag-release commit, and device-picker pick would have failed silently on the board. Checked directly (not just assumed) against the exact built unit file for system z3zbk6gx: shell-ui.service’s own generated Environment=PATH=... line did already include both wireplumberLean and pipewireLean’s bin/ directories (this change’s earlier path = [...] addition to that unit). Why the live process still did not see this is not resolved here — rather than keep depending on PATH search working end to end for something this important, wpctl/pw-dump/ pw-cli are now also passed as absolute store paths via their own K230_WPCTL/K230_PW_DUMP/K230_PW_CLI environment variables (the same “substitute the real path at build time” convention K230_SETTINGS/ K230_SWAYMSG already use in this file), which is what main.rs’s own std::env::var_os("K230_WPCTL")-style reads already preferred over a bare PATH lookup. path is left in place as a fallback, not removed.

Separately: this shell’s own persistent pw-dump --monitor/pw-cli children were spawned with .ok() swallowing any spawn error with no log line at all — exactly the kind of silent failure that makes “is the persistent helper actually starting?” unanswerable from a journal alone. Both spawns now eprintln! (captured into this unit’s own journal, the same convention every other early-startup failure in main.rs::serve already uses) before discarding into .ok().

The rtkit/session-bus warnings

module-rt logged that it could not reach a session bus at all (not just “no RTKit registered on one”), because none of the three units set DBUS_SESSION_BUS_ADDRESS. All three now connect to the same shell-session-bus every other per-session daemon in this file already uses. security.rtkit.enable remains deliberately unset (design.md); the expected outcome after this fix is module-rt reaching a real bus and getting a clean “no such service” from it, not “no bus at all” — still harmless, per the coordinator’s own acceptance of that outcome. No other WirePlumber module this image actually enables (ALSA monitor, default policy/routing) needs D-Bus for basic sink/source management; only the optional Bluetooth and MPRIS-style modules would, and neither is enabled here (pipewireLean’s bluezSupport = false; no MPRIS module configured).

What this file does not establish