Nomarchy/agent/BACKLOG.md

Backlog — the prioritized task queue

This is the only executable work list for agents. Product themes and v1.0 intent live in docs/VISION.md; design history in docs/ROADMAP.md; map in docs/README.md and agent/README.md.

Rules:

• Agents take the topmost actionable item (see LOOP.md). Finished items are deleted here — the journal + git log are the record; durable design notes get a ✓-entry in docs/ROADMAP.md (and/or a note in VISION) if worth keeping.
• Item numbers are stable IDs — never renumbered or reused. A gap in the sequence means shipped (or dropped) work; new items take the next free number regardless of tier.
• Tags: [blocked:hw] needs real hardware (see HARDWARE-QUEUE.md) · [human] needs Bernardo · [stuck] two failed attempts, needs help · [big] must be split before starting.
• Agents may append to PROPOSED and Decisions freely (include VISION § … or ROADMAP § … when relevant); only Bernardo moves items out of PROPOSED into the tiers.

---

NOW

Live ISO / install hardware findings — Acer Aspire M5-481T + Dell XPS 9350

Bernardo, real installs 2026-07-13–14 (photos of the install end screens and post-boot sessions). Preserve separation: the installer bake failure and the flake pin are different root causes even when they show up on the same machine. (Terminal / Ghostty-on-Acer → shipped as Kitty-only, #95.)

NEXT

151. [human] v1 launch plan — devise with Bernardo (includes the GitHub move)

Bernardo, 2026-07-17: before tagging v1, sit down and devise the launch plan. Known ingredients, so that session starts concrete:

• The repo moves to GitHub. Everything baking the Gitea URL follows: the downstream template's inputs.nomarchy.url, the nomarchy-wallpapers input URL (baked 2026-07-17 — sweep it in the same move), README/docs links, and CI (eval CI runs on Gitea act_runner — decide GitHub Actions vs keeping Gitea CI on a mirror).
• The move is the natural moment for the history-rewrite decision, and it is now measured (2026-07-17): the 107 MiB pack is 94.2 MB wallpaper blobs + 9.9 MB preview generations; all 848 commits of text pack to ~15–20 MiB. So the history is not long-heavy, it is image-heavy. Recommendation on the table: filter, don't reset — git filter-repo stripping only themes/*/backgrounds/ keeps every commit's diffs/blame/log -S (load-bearing: it diagnosed #147) at a ~15–20 MiB clone. Cost: all SHAs change, and ROADMAP/journal cite them — mitigate by freezing the Gitea repo as a read-only archive (old SHAs resolve there; stash filter-repo's commit-map in it) + one ROADMAP note. Argue against a full mirror (ships 94 MB of deleted images to every clone forever) and against fresh-start (burns the archaeology to save ~15 MiB).
• The existing v1 bar (VISION § v1.0): HARDWARE-QUEUE burn-down, install P0 re-verify before the v1 fast-forward, visual ritual. LICENSE shipped (MIT, 2026-07-17).
• Adjacent calls that may fold in: cachix/public binary cache (#120's prerequisite), the netinstall decision itself, release notes/announce.

v1 stays human-only throughout — agents prepare evidence and checklists, never the tag or branch.

LATER

• Pre-built theme variants (ROADMAP § Faster switches follow-on): if home-manager switch itself is still the theme-switch bottleneck now that the wallpapers split shipped (2026-07-17), pre-build each theme's generation so a switch just activates a cached one. Measure first.
• Installer round 2 (ROADMAP § Installer): multi-disk BTRFS RAID, impermanence, BIOS/legacy boot.
• Boot-from-snapshot: a systemd-boot equivalent of grub-btrfs.
• MIPI/IPU software-ISP camera support (no-UVC machines).
• NixOS release bump → v2 [human]: deliberate, hand-edited, never automated; the previous attempt was discarded (2026-06-22) over a Hyprland OOM blocker — see MEMORY.md before retrying.

FUTURE (decided deferred — not the agent queue head)

Work we intend someday but explicitly not NEXT. Agents do not pick these unless Bernardo promotes one into NEXT/NOW.

20. KVM runner → VM suite in CI [human]

Status (2026-07-10): keep eval-only CI on the current Gitea stack (act_runner in docker-compose on the 4c/4 GB IONOS VPS). Nested KVM + RAM headroom on that host are a poor fit next to Gitea; full checks.* VMs stay local / promotion-time until a separate KVM-capable machine exists.

When ready: register a second runner (host-mode nix + /dev/kvm, label nix-kvm — not the existing docker eval runner), then uncomment the vm-checks job in .gitea/workflows/check.yml (runs-on: nix-kvm, nix flake check + toplevel/HM builds). Do not enable the job until that label is online (Gitea queues forever otherwise).

Formatter — adopt later [human]

Intent: add a Nix formatter (likely nixfmt-rfc-style) in a dedicated pass: reformat the tree once, document in CONVENTIONS, optional CI check. Not the queue head — no drive-by reformats until that pass.

PROPOSED (agent suggestions — await human triage)

Agents: append here with a one-paragraph pitch (what/why/cost). Do not implement. Bernardo moves accepted items into a tier.

Open work only. Shipped exam/A–C items (#47–#63, #14, #52 theme high-ROI, etc.) live in the journal + ROADMAP — not here.

Product / day-2

153. Desktop widgets (clock / system stats) as an opt-in per-theme surface

Pitch (filed while shipping the three exclusive theme pairs, 2026-07-18): themed desktop widgets — a clock, calendar, or system-stats panel living on the wallpaper, conky-style — would deepen the identity themes (imagine kiln's copper stats panel or executive-ivory's letterhead clock). No such surface exists today, so it is a NEW theming surface: per CONVENTIONS it must consume the palette from the state JSON (no side pipeline) and ship as an opt-in nomarchy.* toggle with a commented template example. Engine choice is the real decision — conky is X11-era; a Wayland layer-shell widget system (eww or a small QML/GTK layer-shell tool) fits the stack better. Cost: moderate (engine spike + palette bridge + 2–3 widget layouts; start with the exclusive pairs only, not all 28 themes). Value: v1+ polish, not a v1 blocker.

146. [watch] hypridle hangs instead of exiting when its compositor vanishes

Rewritten 2026-07-16, hours after filing: the premise was disproven and almost nothing survives. As filed it said hypridle "dies silently ~2×/week — 19 times in 11 days", with Jul 14 as the clean example ("CRITICAL at 13:08:17, then eleven hours of silence"). Every number there was an artifact of the measurement. 18 of the 19 Disconnected from pollfd id 1 lines are hypridle's noisy goodbye while systemd deliberately stops it — each bracketed by Stopped hypridle / Started hypridle with a healthy replacement seconds later. The "eleven hours of silence" came from grepping one PID: systemd logged Stopped hypridle 13:08:17, Started hypridle 13:09:00, and PID 1678 ran fine all evening where the filter could not see it. Do not re-derive the old rate; it counts normal shutdown noise.

What is real, and it is small. Exactly one genuine zombie has been observed (2026-07-16 17:25:39), verified by process inspection rather than logs — ps (alive 9h36m), ss (48 KB unread on its D-Bus socket, i.e. not reading), NRestarts=0 while systemctl --user is-active said active (running). That is upstream hyprwm/hypridle#171 ("Possible deadlock in pollThr when compositor exits?", open since 2025-09, in neither 0.1.7 nor main) and it is a true bug: hypridle hangs rather than exits, so Restart=always never fires.

A second real one joined it with #127's close (2026-07-17): an inhibit-lock underflow (BUG THIS: inhibit locks < 0: -1, hypridle's own words, Jul 15 10:36:29) left the fired DPMS listener's on-resume permanently dead on 0.1.7 — the incident's actual mechanism (ROADMAP § "The idle brick's CAUSE found"). Reported upstream with the full trace 2026-07-17: https://github.com/hyprwm/hypridle/issues/208 (#74/#104/#128 are the same class, closed before 0.1.7 evidently without killing it). Its impact path here is closed by the compositor-side wake fix (a2151f4); same watch posture — take the upstream fix when a release carries it.

But its impact path is closed, which is why this is [watch] and not work. The zombie only persists if systemd never stops the unit — which needed the user manager to survive logout, i.e. the stray pre-migration linger removed in #147. Without linger, logout tears the manager down and takes any zombie with it; the Jul 14 trace above shows the healthy path (Stopped → Started) doing exactly that. A Hyprland death ends the logind session anyway (2026-07-16: Session 2 logged out → greeter), so there is no known route left to a surviving zombie.

Do before building anything: re-measure. Count only disconnects with no Stopped/Started hypridle around them and no logind session event, and confirm by ps/ss that the process is really wedged — not by grepping a PID. If that count is zero over a few weeks post-linger, close this unbuilt. If it is not, the upstream issue has sat ten months on vaxerski's "that will cause a segfault no?" and a reproducer would be worth more than a local guard.

154. [watch] tools/monitor-fallback.nix is red on main at the #148 reload-mid-dock assertion

Found while verifying #150 (2026-07-20): the dock/undock VM harness fails at the enforce_dock_intent step — after a lid-closed hyprctl reload it waits 15s (generated <string>:75) for the watcher to re-disable Virtual-1 and times out; the panel is never re-disabled and action=re-dock is never logged. Confirmed pre-existing: a clean-HEAD worktree run (fdf9790, before any #150 change) fails at the identical assertion, and the #150 refactor is proven inert here (the built nomarchy-display-transition / nomarchy-keyboard-layout have byte-identical store paths on HEAD vs the #150 branch). The dock transition itself succeeds (result=ok, both workspaces move, internal disabled) — only the post-reload re-dock invariant fails. Likely a harness/environment issue (the enforce_dock_intent tick depends on the watcher reading settings.display.dockMode from the in-flake state, which may not be writable in this NixOS-test sandbox) rather than a product regression — but it means the maintainer V2 dock harness is not a usable gate until re-greened. Do first: reproduce, then check whether set_dock_intent actually persists dockMode=true inside the VM (grep the run journal for dock-intent=…state-write-failed); if the state write is the gap, the fix is in the harness, not the watcher.

149. [watch] Waybar's exec-once workaround may be defending against nothing post-linger

Spun out of #147 (shipped 2026-07-17) so its loose thread survives the entry: modules/home/hyprland.nix runs Waybar from exec-once rather than a systemd unit because the unit "raced Hyprland's IPC on a warm relogin ... never retried, so the bar vanished" — and a warm relogin is exactly what linger created. With the stray linger removed (2026-07-16) that workaround may be defending against nothing. Do not rip it out on this note alone: it works, and the claim needs a real relogin without linger to test (V3 — the same relogin that verifies #148's watcher fix would answer it).

2026-07-18 evidence: the warm relogin is real post-linger. On the dev box the user manager survived a Hyprland logout (the tty1 greetd session keeps it alive — no linger involved) and the teardown broke: graphical-session.target's stop transaction was rejected as destructive (easyeffects had a queued start job), the target stayed active, cliphist/swaync/portals/swayosd crash-looped against the dead Wayland socket into start-limit-hit, and the relogin's plain start was a no-op — doctor red for the whole session. Session bring-up now stops stale targets + reset-failed before starting (hyprland.nix systemd.extraCommands); relogin V3 check queued in HARDWARE-QUEUE. The exec-once posture this entry watches is therefore still earning its keep.

120. A netinstall ISO, next to the fat offline one

Deferred to PROPOSED 2026-07-16 (Bernardo): not now. Nothing below is stale — the measurements stand and the decision it needs is unchanged. It sits here because it is the only genuinely large item left, and because the gotcha at the bottom (no binary cache for our own derivations) probably makes a cachix the real first step, not the ISO.

Bernardo 2026-07-14, after seeing the measured size: keep the current ISO exactly as it is — the guaranteed offline install is the feature it buys — and ship a much lighter netinstall variant alongside it. Two products, one distro: "works on a plane" and "8 GiB is absurd to download" are both true, and a second target settles them without compromising either.

Measured facts (2026-07-14), so this starts from numbers, not vibes. (These stand as measured: #121 would have cut ~0.67 GiB of duplicate chromium from them, but it was reverted — decided against, ROADMAP § one chromium, not two. If a netinstall ships, revisit it: the duplicate is worth ~195 MiB of download, which is this item's whole currency, even though it is worth almost nothing on disk or on the ISO.)

Read this before using the numbers below. They are closure arithmetic, and #121 proved the hard way that closure size is neither disk size nor image size: removing a 687 MiB path shrank the ISO by 8 KiB, because mksquashfs dedupes duplicate files and auto-optimise-store hardlinks them on disk. So a change that looks like it sheds gigabytes of closure can shed nothing off the actual image. Measure the artifact — build the ISO and stat it. The corollary cuts the other way and is the good news for this item: what dedupe cannot help is the wire, so a netinstall's download is the one figure closure/NAR size predicts honestly (nix path-info --store https://cache.nixos.org --json gives the real downloadSize).

• Current ISO 8.078 GiB compressed; 18.03 GiB of store uncompressed (zstd -19, 2.23:1 — compression is already near-max, not the lever).
• The offline pin (system.extraDependencies, 60 roots: a representative installed system + the template HM closure + all flake inputs) is 4.02 GiB uncompressed of that — only ~22%. Dropping it entirely still leaves a ~13.3 GiB desktop → roughly 6 GiB compressed at the same ratio. So "no pin" alone is NOT the lighter ISO — this is the trap to avoid.
• The desktop's own top weights: libreoffice 1457 MiB, initrd 1369, linux-firmware 770, chromium 1391 (two builds — #121, left in), llvm-lib 540, bibata-cursors 322, mesa 264, mbrola-voices 259, nerd-fonts ~420 combined. Note what that list implies: no single lever gets a desktop ISO under ~4 GB — which is the case for (b) below.

So the real decision is what a netinstall ISO IS, and it should be settled first ([human]): (a) the full try-before-install desktop minus the pin (~6.3 GiB — barely lighter, probably not worth a second target); (b) a TUI installer only, no desktop (~1 GiB, the actual "netinstall" in the Debian sense) which drops "try before install" from that medium — the fat ISO still offers it; (c) a middle desktop (no libreoffice/chromium — but note #103 just put those there deliberately, and a demo desktop that can't browse is the bug #103 fixed).

The gotcha that decides feasibility: without the pin, a netinstall target fetches from cache.nixos.org for stock nixpkgs paths — but Nomarchy's own derivations are in no binary cache, so they would build from source on the user's machine during install. That is the same failure tools/vm/gap-analysis.py exists to diagnose (and #113 is a live instance of). So this item probably depends on a public binary cache (cachix) for the flake's own outputs, or it trades an 8 GiB download for a 40-minute install. Establish that before building the target.

Pass = a second, documented ISO target that is substantially smaller (state the measured number, both ISOs built from one tree), installs successfully with a network in a QEMU run, says clearly at boot that it needs one, and leaves the offline ISO's behaviour untouched (checks.* for the offline path stay green).

• NVIDIA first-class options — deferred past v1 (Bernardo 2026-07-10). Keep #59 commented install guidance; no nomarchy.hardware.nvidia.* until a hybrid maintainer + queue.

(#80–#83 + #85–#88 shipped 2026-07-11. Theme A day-2 + neon-glass finish shipped — VISION ✓. Dock/hibernate V3 → HARDWARE-QUEUE. Parallel fingerprint-or-password shipped 2026-07-12 (Bernardo promoted it live; fingerprint.parallel, pam-fprint-grosshack) — reader V3 → HARDWARE-QUEUE.)

v1.0 pointer

See VISION. Open PROPOSED: NVIDIA deferred past v1; IR portal (b)/(c) need T14s (HARDWARE-QUEUE § T14s). Standing calls: browser = Chromium; power = PPD. (Post-install hardware hints shipped 2026-07-17.)

Decisions [human]

Open calls only Bernardo can make; agents add options/evidence but never decide. Resolved entries stay for history; agents treat them as closed.

Resolved (2026-07-17)

• #143 rofi refilter highlight — the 07-16 "wait for upstream" ruling was priced against carrying a patch; the maintainer's reply on rofi#2317 pointed at the inputchange {} config block instead. Adopted same day as pure config (kb-row-first on query edits, generated config.rasi) — no patch, no source build, watch closed (ROADMAP § Rofi highlight).
• #120 netinstall — stays deferred in PROPOSED (re-affirmed). When it is promoted, a public binary cache (cachix) is the likely first step.
• #134 unstable packages — build it: Nomarchy carries the nixpkgs-unstable input, unstable.* via the overlay, home-scope only. Shipped the same day (ROADMAP § unstable.<pkg> in the downstream).
• #114 greeter layouts — document only: a VT has one keymap by design, so tuigreet cannot honour per-device layouts. Shipped as the README "Greeter keyboard layout" note + a RECOVERY.md pointer; entry deleted.

Resolved (2026-07-10)

• Docs site vs Markdown-in-repo — markdown in-repo for now (docs/, README). A rendered docs site is FUTURE if wanted.
• Default browser — ship Chromium in templates/downstream/home.nix; mime → chromium-browser.desktop. Opt out: delete the line / override mime.
• Default power backend — keep PPD (nomarchy.system.power.backend default). TLP remains the one-line opt-in. Rationale: stability + live profile API for menu/Waybar; Omarchy’s TLP experiment reverted.

Resolved (2026-07-10, more)

• Formatter adoption — yes, but not now. Tracked as FUTURE (below). Nix-source style only (nixfmt-rfc-style or similar); one bulk reformat + CI/check when promoted. Until then: hand-aligned style per CONVENTIONS.

• Hibernation — want by default (product intent). Needs a disk-backed swap (file or partition) sized for resume; not zram alone. Shipped as #76; V3 power-cycle PASSED on TuringMachine 2026-07-12 (ROADMAP § Hibernation + zram by default).

Resolved (2026-07-10, #76 design)

• Swap sizing — exactly RAM (installer default, unchanged). Hibernate image ≤ RAM; zram takes day-to-day paging. swapSize=0 stays no-swap.
• Migration — docs runbook (docs/MIGRATION.md), not a tool.
• No-swap Hibernate — keep the menu row; notify on failure.