Treat the picker-only (none) row as an empty XKB variant at the shared input boundary and again in the template patcher. Guard the real downstream output and console keymap, and carry the sentinel through the offline installer VM. Verified: V0 full flake evaluation plus shell/Python/Nix/diff checks; V1 installer-keyboard, installer-safety, and template-SoT builds; V2 full KVM offline LUKS+swap install and themed first boot. No V3 required.
9.8 KiB
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 § …orROADMAP § …when relevant); only Bernardo moves items out of PROPOSED into the tiers.
NOW
Live ISO hardware findings — Acer Aspire M5-481T (Bernardo, 2026-07-13)
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.
92. Installer: keyboard selection is confusing
Make the layout/variant relationship and the “no variant” choice explicit; show a human-readable preview/current choice before confirmation. Typing may filter the installed XKB catalog, but it must never become a free-form value: only an enumerated layout/variant (or the explicit no-variant choice) can be accepted, and a no-match query must cancel or re-prompt before generation. Keep the simple default path short. Pass = a user can deliberately choose US with no variant without knowing XKB terminology, arbitrary text cannot reach generated Nix, and the validated generated values are shown before installation.
93. Installer: swap-size field lacks a clear prompt/explanation
The partition value appears prefilled without a caption explaining that it is swap size. Keep the resolved product default (swap exactly equal to RAM), but label the field, state its unit/default, and explain the no-swap value. Pass = the summary makes the resulting swap allocation unambiguous before disk changes begin.
94. Live ISO/install: no default browser observed
Chromium is the resolved default-browser decision and is present in the
downstream template, but this hardware pass found no usable default browser.
Trace the live-to-installed Home Manager path rather than merely checking the
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
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.
96. Live ISO/install: battery charge-threshold menu is absent
On this Acer the charge-threshold menu could not be found. Audit the hardware capability gate and menu discoverability: unsupported hardware must get a clear explanation instead of looking like a missing feature; supported hardware must expose the control. Pass = the System/Power route communicates the correct state and never silently disappears.
97. Live ISO/install: Bluetooth menu reports Connection to BlueZ failed
Verify that BlueZ is enabled/running and that the live and installed user sessions can reach it before launching the picker. Pass = the Bluetooth menu opens normally on supported hardware; when the adapter/service is genuinely unavailable it shows a useful Nomarchy message rather than the raw failure.
98. Boreal: button text renders black and is difficult to read
Audit GTK button foreground/background contrast under Boreal, including the installer surface where it was observed. Follow THEME-DESIGN's two-theme visual protocol. Pass = normal, hover, focused, and disabled button labels remain legible and palette-consistent.
99. Doctor/Waybar reports theme.json is not git-tracked
The live-installed checkout shows a doctor/Waybar warning that theme.json
is not tracked. Determine whether the warning targets the generated alias or
the canonical theme-state.json, then align the check with the in-flake state
contract. Pass = a fresh install has no false warning while a genuinely
untracked canonical state file is still detected.
NEXT
(empty — NEXT's top item is the queue head)
LATER
- Wallpapers artifact split (ROADMAP § Faster switches — decided,
deferred): pinned
Nomarchy-wallpapersinput so a state write stops re-copying 86 MB. Follow-on: pre-built theme variants if switches are still slow after. - 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 (NOW#3 should also soften that blocker class).
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
-
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. -
Post-install hardware hints (
VISION § B) — After the general “you're set” card (#81), optionally fire one additional self-gated notify when the machine actually has the hardware: (a)fwupdmgron PATH → “System › Firmware to check LVFS updates”; (b)fprintd-liston PATH → “System › Fingerprint to enroll”. One-shot markers insettings.*(same in-checkout discipline asfirstBootShown); never a permanent MOTD nag. Cost: small — extendnomarchy-first-bootor a sibling oneshot +checks.first-bootfixture. Control-center / MOTD already mention these; the gap is the silent first graphical session for people who never open those.
(#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: post-install hardware hints; NVIDIA deferred past v1; IR portal (b)/(c) need T14s (HARDWARE-QUEUE § T14s). Standing calls: browser = Chromium; power = PPD.
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-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.backenddefault). 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-styleor 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=0stays no-swap. - Migration — docs runbook (
docs/MIGRATION.md), not a tool. - No-swap Hibernate — keep the menu row; notify on failure.