docs(agent): queue #123–#124 + diagnose #95 from Acer/XPS install photos

Real installs on Acer Aspire M5-481T and Dell XPS 9350 (2026-07-14):

- #123: HM pre-activate dies at dconf without XDG_RUNTIME_DIR on both
  machines — partial first boot (weird GTK + missing nm-applet are
  symptoms of the incomplete bake).
- #124: install seeds ?ref=v1 while writing main-era nomarchy.hardware.*,
  and v1 lags hard enough that rebuilds die with "option does not exist".
- #95: Ghostty on the Acer is OpenGL 4.2 < required 4.3 (OpenGLOutdated);
  XPS starts Ghostty fine.

HARDWARE-QUEUE V3 rows; photos stay local (.gitignore WhatsApp Image*).

agent/BACKLOG.md

@@ -24,11 +24,100 @@ in [`docs/ROADMAP.md`](../docs/ROADMAP.md); map in
 
 ## NOW
 
-### Live ISO hardware findings — Acer Aspire M5-481T (Bernardo, 2026-07-13)
+### Live ISO / install hardware findings — Acer Aspire M5-481T + Dell XPS 9350
 
-These are separate queue items from one real install/session pass. Preserve
-that separation when fixing them: the installer blocker, unclear installer
-copy, and post-install desktop failures have different verification paths.
+Bernardo, real installs 2026-07-13–14 (photos of the install end screens and
+post-boot sessions). Preserve separation: the installer bake failure, the
+flake pin, and the Ghostty GL floor are different root causes even when they
+show up on the same machine.
+
+### 123. Installer HM pre-activate aborts on dconf / missing XDG_RUNTIME_DIR
+
+**Seen on both machines** (Dell XPS 9350 and Acer M5-481T), same log shape at
+the end of `nomarchy-install` after "✓ System installed":
+
+```
+— Baking the desktop —
+Building the desktop generation...
+▲ Desktop pre-activation failed (see /var/log/nomarchy-hm-preactivate.log
+  on the installed system); after first login run:
+  home-manager switch --flake ~/.nomarchy -b bak
+Activating dconfSettings
+dconf-CRITICAL **: Unable to create directory '/run/user/1001/dconf':
+  Permission denied. dconf will not work properly.
+error: Could not connect: No such file or directory
+```
+
+Install still reports success and offers reboot — so first boot lands on a
+**partial** Home Manager activation. That matches the post-boot pain Bernardo
+had to fix by hand on both boxes: **GTK theme looking wrong** (Stylix/dconf
+color-scheme never landed) and **missing nm-applet tray icon**
+(`services.network-manager-applet` is on in `modules/home/default.nix`, but
+only after a complete HM generation/activation). Do **not** file those as
+separate product bugs until this bake succeeds; re-check them as acceptance
+criteria of the fix.
+
+**Root cause (code path):** `pkgs/nomarchy-install/nomarchy-install.sh`
+"Baking the desktop" runs `$out/activate` via `runuser` inside `nixos-enter`.
+There is no user session: `/run/user/$UID` is missing or unwritable, so the
+dconf activation step dies and the scripted activate aborts mid-way. #83
+already surfaces the recovery one-liner; the *bake itself* is what is broken.
+
+**Fix direction:** before `runuser … activate`, create a private runtime dir
+the target user owns (`mkdir -p /run/user/$UID && chown`, export
+`XDG_RUNTIME_DIR`), and/or give activate a session bus if dconf still needs
+one. Prefer making pre-activate succeed over papering over dconf. Keep the
+existing failure hint for genuine failures.
+
+**Pass:** a `tools/test-install.sh` (or equivalent) run ends with
+"Desktop pre-activated — first boot is fully themed", **not** the dconf
+CRITICAL; `/var/log/nomarchy-hm-preactivate.log` is absent or clean; first
+graphical login has Stylix GTK theming + nm-applet in the tray **without** a
+manual `home-manager switch`. V3: same on at least one of the two boxes that
+regressed (HARDWARE-QUEUE).
+
+### 124. Install seeds `?ref=v1` while writing main-era config (and v1 lags hard)
+
+**Seen on Acer after install** (and inherent in every current install):
+
+- ISO was built from **main**.
+- Generated `~/.nomarchy/flake.nix` still has
+  `inputs.nomarchy.url = "…?ref=v1"` (`templates/downstream/flake.nix` +
+  `flake.nix` `flakeUrl` / `originalNode.ref = "v1"`).
+- Installer **also** writes live `nomarchy.hardware.*` lines into
+  `system.nix` (`patch-template.py` — e.g. `nomarchy.hardware.intel.enable`).
+- `v1` is far behind main (hundreds of commits; currently lacks the modern
+  `nomarchy.hardware` surface). After a pull / lock re-resolve to the forge,
+  rebuild dies with:
+
+```
+error: The option 'nomarchy.hardware' does not exist.
+  … intel = { enable = true; };
+Did you mean 'nomarchy.services' or 'nomarchy.system'?
+```
+
+So a main-built ISO writes config that **only main understands**, then points
+the machine at a release branch that does not have those options. Offline
+compose-lock papers over first boot (path-locked to the ISO store), but the
+first intentional update re-resolves to ancient v1 and the machine breaks.
+
+**Product tension:** the standing branch model is "downstreams pin `v1`"
+(ROADMAP / CONVENTIONS) — correct once `v1` is a real release pointer. While
+`v1` lags development this hard, **installs from a main ISO must not leave
+users on that lagging ref**.
+
+**Fix direction (pick one and document):** (a) ISO build injects the ref the
+image was built from (`main` or `v1`) into the template + `flakeUrl`; (b) pin
+`original` to the exact ISO `rev` and only advance on explicit
+`nomarchy-pull`; (c) stop writing options that do not exist on the pinned
+ref (worse — loses hardware enablement). Prefer (a) or (b).
+
+**Pass:** a machine installed from a main-built ISO has a flake whose nomarchy
+input evaluates the same option surface the installer wrote (no
+`nomarchy.hardware does not exist` on `nomarchy-rebuild` / first pull policy
+as documented); a release ISO built from `v1` still pins `v1`. Guard: install
+safety / template check that written options ⊆ pinned module surface, or that
+the seeded ref matches the ISO source ref.
 
 ### 94. Live ISO/install: no default browser observed
 
@@ -55,11 +144,35 @@ template source. Pass = Chromium launches after installation and HTTP/HTTPS
 mime defaults resolve to `chromium-browser.desktop` (and the intended live-ISO
 browser posture is explicit).
 
-### 95. Live ISO/install: Ghostty does not open
+### 95. Live ISO/install: Ghostty does not open on old OpenGL
 
-Reproduce from the launcher and a terminal, capture its stderr/journal, and
-fix the packaging/session/runtime cause. Pass = the default terminal opens in
-the installed graphical session and the SUPER+Return path works.
+**Diagnosed 2026-07-14 on Acer Aspire M5-481T** (Dell XPS 9350 starts Ghostty
+fine — machine-specific). From a working shell:
+
+```
+info: renderer=renderer.generic.Renderer(renderer.OpenGL)
+info(opengl): loaded OpenGL 4.2
+warning(opengl): OpenGL version is too old. Ghostty requires OpenGL 4.3
+warning(gtk_ghostty_surface): failed to initialize surface
+  err=error.OpenGLOutdated
+warning(gtk_ghostty_surface): surface failed to initialize
+  err=error.SurfaceError
+```
+
+Not a packaging/missing-binary bug: Ghostty 1.3.1 runs, reads config, then
+refuses the GPU. Default terminal is Ghostty (`nomarchy.terminal`), so
+SUPER+Return and the launcher entry are dead on anything ≤ GL 4.2 (Ivy Bridge
+era and similar).
+
+**Fix direction:** detect/soft-fallback — e.g. Ghostty config for a software
+GL path if one exists and works; or auto-pick a second terminal (kitty is what
+Bernardo added by hand on the Acer) when `glxinfo`/EGL reports < 4.3; or
+document + installer/hardware probe that swaps the default. Do not silently
+leave SUPER+Return bound to a terminal that cannot map a surface.
+
+**Pass:** on a GL 4.2 (or softGL) guest/host, SUPER+Return opens a usable
+terminal; on modern GL, Ghostty remains default and themed. V2 softGL/QEMU is
+acceptable for the fallback path; V3 on the Acer confirms the real iGPU.
 
 ### 98. Boreal: button text renders black and is difficult to read