Bernardo promoted the PROPOSED item live: with fingerprint PAM on, sudo/login should accept whichever factor comes first instead of pam_fprintd's wait-for-the-reader-then-password. Stock PAM cannot express parallel factors (linux-pam#301), so this packages pam-fprint-grosshack v0.3.0 (pkgs/, pinned from GitLab — the field-standard fprintd fork), source-reviewed before packaging: every failure path (no reader, no prints, fprintd absent/hung, timeout, password typed) returns PAM_AUTHINFO_UNAVAIL and falls through; a typed password is only ferried via PAM_AUTHTOK to the stock `auth sufficient pam_unix.so … try_first_pass` rule — the module never validates passwords itself, so it cannot lock out password login. New option nomarchy.hardware.fingerprint.parallel, default TRUE (the better UX is what opting into fingerprint PAM buys; false = stock sequential). Wiring swaps the modulePath of stock fprintd's rule slot (mkForce) so the sufficient-before-pam_unix ordering is inherited, not recomputed. README + downstream template rows added. Verified: V2 — checks.hardware-toggles extended to three nodes, green: parallel node asserts the grosshack auth line precedes pam_unix in /etc/pam.d/sudo and that with NO reader a correct password still passes sudo while a wrong one fails (the lockout-safety invariant); seqpam node gets stock pam_fprintd and no grosshack; nopam gets neither. flake check + option-docs + template-sot green. V3 pending (HARDWARE-QUEUE, AMD dev box): the real type-or-touch race, fprintd-stopped fallback, hyprlock/greeter after a fingerprint win. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
8.9 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
(empty — NEXT's top item is the queue head)
NEXT
89. Tray icon parity — themed overrides for SNI apps (Bernardo 2026-07-11)
The bar is monochrome; third-party tray icons aren't. EasyEffects 8's Qt
SNI publishes IconName com.github.wwmm.easyeffects → Papirus full-color
blue (T14s V3, 2026-07-11); Signal / Telegram / ZapZap (all flatpaks on
the T14s) likely worse. Goal: every tray icon reads like part of the bar.
Slices:
-
Inventory — DONE (T14s live session, 2026-07-11):
app IconName pixmap? verdict nm-applet nm-signal-*(state-varying)no name-based — override the nm-*familyudiskie drive-removable-media-usb-panelno name-based Telegram org.telegram.desktop[-mute/-attention]-symbolicyes (fallback) name-based — ship all state names Signal Signal_status_icon_1(generated, not a real theme name)yes pixmap — slice 3 ZapZap (empty) yes pixmap — slice 3; check its own tray-style setting first EasyEffects 8 com.github.wwmm.easyeffects(prior T14s finding)— name-based; NB --gapplication-servicealone registers no SNIBernardo's visual verdict (T14s, 2026-07-11): Telegram and ZapZap already read fine on the bar — out of scope. The offenders are EasyEffects (slice 2: name-based override) and Signal (slice 3: pixmap; check for an app-side tray option, else document). Related fix shipped same day: easyeffects.service now waits for a registered tray host before starting (the old After=waybar.service ordering was inert — waybar is supervisor-run, not a unit), so the icon no longer vanishes on unlucky boot order.
-
Override layer — DONE (EasyEffects, 2026-07-12, f9d5e2c…b98248f). Chosen mechanism: a
Nomarchy-iconschild theme (built inmodules/home/theme.nix) thatInheritsthe resolved icon set and becomes the session icon theme; a scalable, palette-text-coloured monochrome override out-resolves the parent's fixed-size icon at every size while all other icons fall through. Single shared layer → holds for every theme (all resolve to Papirus-*), colour regenerated per switch. V3 in Boreal (Bernardo confirmed). Extend to a new name-based offender = one more SVG inscalable/apps. -
Pixmap apps: document (or wire, where a setting exists) per-app monochrome/tray options; what can't be fixed goes in the item's record, not silent scope creep. Signal is the live example (
:1.227, generated pixmap → shows as its full-colour blue round icon on the bar); still open.
V-path: V1 eval + icon file lands in the right lookup dir; V3 screenshot of the tray on a real session (headless VM has no flatpak chat apps).
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.