doc: confirm davinci is working

davinci/CLAUDE.md

@@ -159,6 +159,50 @@ not an actual GUI launch.
   compute on real AMD/Intel hardware, audio, the app-menu-entry steps,
   Studio+dongle path. All of that needs a real Linux host with distrobox.
 
+## Real GUI launch test (2026-09-09)
+
+Simon ran `distrobox create` + `davinci-run` for real, `amd` target, on
+actual Linux/GPU hardware (AMD Radeon 680M integrated GPU, `rocm-opencl` +
+`intel-compute-runtime` both present as installed by the `amd` stage) —
+the one thing the Docker Desktop/WSL2 build test above explicitly could not
+cover. Result: **it works.** `davinci-run` launched `/opt/resolve/bin/resolve`,
+which went through the v21 "what's new" popup → Project Manager → Create
+New Project → a Transcode window, all mapped and focused normally under
+Hyprland (XWayland, confirmed via `hyprctl clients`). This is the first
+confirmation of the full stack (distrobox create → box → `davinci-run` →
+real GPU) actually working end to end, not just the image build.
+
+- **False alarm during my own debugging, worth recording so it isn't
+  re-chased:** my first few attempts ran `davinci-run | head -N` to inspect
+  output, which reproduced `Failed to create application support
+  directories` every time (plus `log4cxx: No appender could be found`).
+  This looked exactly like a real startup bug and cost real debugging time
+  (strace, permission checks, `getpwuid`/nsswitch checks, `QT_PLUGIN_PATH`
+  host-env-leak theory — all dead ends). The actual cause: `head -N` closes
+  its end of the pipe after N lines, sending Resolve's process group a
+  SIGPIPE that kills a startup helper before it finishes setting up its
+  app-support directories. Piping through `tail` instead (which reads to
+  EOF, no early close) or not piping at all made the error disappear
+  immediately, every time. **Lesson: never pipe `davinci-run`'s stdout
+  through something that can close its read end early (`head`, `sed -q`,
+  etc.) when diagnosing a "failed to start" report — redirect to a file or
+  use `tail` instead, or the pipe itself becomes the bug.**
+- Real host environment leaking into the box (Nix/home-manager: `QT_PLUGIN_PATH`,
+  `PATH`, `XDG_DATA_DIRS` all full of `/nix/store/...` entries) turned out
+  to be harmless for Resolve itself — it uses its own bundled Qt5 via
+  `DT_RPATH` regardless of `QT_PLUGIN_PATH`. Not something `davinci-run`
+  needs to guard against.
+- **No audio confirmed for real, as predicted in the README's "Known
+  gotchas":** `ResolveDebug.txt` is full of `ALSA lib dlmisc.c:339:
+  (snd_dlobj_cache_get0) [error.core] Cannot open shared library
+  libasound_module_pcm_pipewire.so` — the host's PipeWire ALSA plugin is a
+  Nix store path the box can't see. Not investigated further since the
+  README already documents the fix (swap to `alsa-plugins-pulseaudio`
+  inside the box); this just confirms the gotcha is real, not hypothetical.
+- Not covered by this test: actually opening/editing a real project,
+  playback, OpenCL compute correctness, NVIDIA path (this host is AMD),
+  Studio+dongle, app-menu-entry end-to-end.
+
 ## What's still unverified after this build test
 
 | Area | Confidence | Note |
@@ -168,10 +212,12 @@ not an actual GUI launch.
 | patchelf fix (paths, not sonames) | High | Build-confirmed: ran without failing the build, `--print-needed` shows the entries landed on `resolve` and siblings. |
 | Dependency sufficiency for the actual entry point (`ldd /opt/resolve/bin/resolve`) | High | Build-confirmed: zero missing libraries. |
 | AppImage magic-bytes workaround (fat-tire's Arch/Manjaro-specific issue) | Not ported | Not hit with the 21.1 `.run` tested here; add back from fat-tire/resolve's Dockerfile if a future version's `--appimage-extract` fails on it. |
-| `amd` variant (ROCm + Intel packages install) | High | Build-confirmed: `dnf install intel-compute-runtime rocm-opencl` succeeded with no extra repos needed. Actual GPU compute correctness (OpenCL kernels running right) still unverified — needs real hardware. |
-| `nvidia` variant / `--nvidia` vs CDI | Low | Still a real open question — see "NVIDIA gotcha" in README. Image builds fine either way; only the *runtime* GPU passthrough method is unverified. |
+| `amd` variant (ROCm + Intel packages install) | High | Build-confirmed at Docker-build time, and now real-hardware-confirmed: `davinci-run` launched successfully on an AMD Radeon 680M host with `rocm-opencl`/`intel-compute-runtime` installed, 2026-09-09. OpenCL kernel *compute correctness* (actual color-science rendering) still not specifically checked — only that Resolve starts and its windows render normally. |
+| `nvidia` variant / `--nvidia` vs CDI | Low | Still a real open question — see "NVIDIA gotcha" in README. Image builds fine either way; only the *runtime* GPU passthrough method is unverified. The 2026-09-09 real-hardware test above was AMD, not NVIDIA. |
 | App menu entry steps | Medium | Directly adapted from a working upstream script, simplified; confirmed the `.desktop` files exist at the documented paths (`/opt/resolve/share/*.desktop`), not run end-to-end. |
-| Actual GUI launch / rendering / audio / licensing | Untested | Needs a real Linux host with distrobox + GPU — impossible to test from this Windows/Docker Desktop environment. |
+| Actual GUI launch (`distrobox create` + `davinci-run`) | High | Real-hardware-confirmed 2026-09-09 on AMD/Hyprland: reached Project Manager → Create New Project → Transcode window, all mapped/focused normally. See "Real GUI launch test" above. |
+| Audio | Low (confirmed broken as predicted) | `ResolveDebug.txt` shows the exact `libasound_module_pcm_pipewire.so` failure the README's "Known gotchas" section already predicted. Fix documented there, not yet applied/tested. |
+| Rendering correctness / playback / licensing / project work | Untested | The 2026-09-09 test only confirmed the app starts and its dialogs render — no project was opened, no clip played back, no license flow exercised. |
 
 ## Repo-wide conventions