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*).

.gitignore

@@ -5,6 +5,9 @@ result-*
 __pycache__/
 .DS_Store
 
+# Ad-hoc hardware evidence photos dropped in the tree (not repo content)
+WhatsApp Image*.jpeg
+
 # Claude Code machine-local settings (permissions etc.)
 .claude/settings.local.json
 .claude/settings.local.json.tmp.*

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
+Bernardo, real installs 2026-07-13–14 (photos of the install end screens and
-that separation when fixing them: the installer blocker, unclear installer
+post-boot sessions). Preserve separation: the installer bake failure, the
-copy, and post-install desktop failures have different verification paths.
+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
+**Diagnosed 2026-07-14 on Acer Aspire M5-481T** (Dell XPS 9350 starts Ghostty
-fix the packaging/session/runtime cause. Pass = the default terminal opens in
+fine — machine-specific). From a working shell:
-the installed graphical session and the SUPER+Return path works.
+
+```
+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
 

agent/HARDWARE-QUEUE.md

@@ -426,6 +426,26 @@ the **T14s** (webcam case).
       `org.gnome.TextEditor.desktop` after #119; vscode remains preferred on
       template installs). Firefox is deliberately absent; its absence is
       correct, not a miss.
+- [ ] **#123 install bake: first boot fully themed without manual HM switch**
+      — after a fix for the dconf / XDG_RUNTIME_DIR abort lands, re-install
+      (or re-run bake) on **either** the Acer M5-481T or the Dell XPS 9350.
+      **Pass:** install ends with "Desktop pre-activated", no
+      `dconf-CRITICAL` / `Permission denied` in
+      `/var/log/nomarchy-hm-preactivate.log`, first graphical login has
+      coherent Stylix GTK theming **and** nm-applet in the Waybar tray
+      **without** running `home-manager switch` by hand. **Fail** = still
+      need the recovery one-liner, or GTK/nm-applet still wrong until a
+      manual switch (then the bake is still incomplete).
+- [ ] **#95 Ghostty on Acer M5-481T (OpenGL 4.2)** — after a software-GL
+      or alternate-terminal fallback ships: SUPER+Return opens a usable
+      terminal on the Acer. On a modern-GL machine Ghostty remains the
+      default. Capture one screenshot of the open terminal on the Acer.
+- [ ] **#124 flake pin after main-ISO install** — on a machine installed
+      from a **main-built** ISO (post-fix): `~/.nomarchy/flake.nix`
+      nomarchy input must not re-resolve to a lagging `v1` that lacks
+      options the installer wrote. **Pass:** `nomarchy-rebuild` (and a
+      deliberate pull policy as documented by the fix) does **not** die
+      with `The option 'nomarchy.hardware' does not exist`.
 
 ## AMD dev box only
 - [ ] **#118 smartd still runs where drives DO have SMART** (this commit) — the

agent/JOURNAL.md

@@ -19,6 +19,26 @@ Template:
 
 ---
 
+## 2026-07-15 — File install findings from Acer + XPS photos (no code)
+- **Task:** Bernardo: real installs on Acer Aspire M5-481T + Dell XPS 9350;
+  photos of the install end screens and post-boot sessions. Figure out
+  issues and queue them — do not implement in this iteration.
+- **Did:** Read the six photos. Three distinct root causes (not one vague
+  "home didn't build"):
+  1. **#123** — HM pre-activate dies on both machines at dconf
+     (`/run/user/1001/dconf: Permission denied`) → partial first boot
+     (weird GTK + missing nm-applet are *symptoms*, not separate bugs).
+  2. **#124** — seeded flake hardcodes `?ref=v1` while installer writes
+     main-era `nomarchy.hardware.*`; v1 lags (~hundreds of commits) →
+     `nomarchy.hardware does not exist` on Acer rebuild/pull.
+  3. **#95** enriched — Ghostty on Acer is OpenGL 4.2 < required 4.3
+     (`error.OpenGLOutdated`); XPS starts Ghostty fine.
+  HARDWARE-QUEUE V3 rows for all three. Photos stay local (not committed).
+- **Verified:** V0 (docs/agent only).
+- **Pending:** implement #123 first (unblocks first-boot polish); then
+  #124; #95 is independent (old-GPU floor).
+- **Next suggestion:** #123 (installer bake) — highest blast radius.
+
 ## 2026-07-15 — #119: mime defaults must name a present .desktop (this commit)
 - **Task:** BACKLOG #119 — `text/plain` named vscode, which the live ISO never
   ships (same GIO-skip trap as #94, one key over).