# Backlog — the prioritized task queue

The forward-looking half of the old docs/ROADMAP.md, reworked as a queue
agents can execute. Detailed design notes and decision records stay in
`docs/ROADMAP.md` (referenced as "ROADMAP § <item>"); this file is *what's
next, in what order*.

**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 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; only
  Bernardo moves items *out* of PROPOSED into the tiers.

---

## NOW

*(empty — NEXT's top item is the queue head)*

## NEXT



### 14. Automated lock bumps — confirm the first real run
Slices b+c shipped 2026-07-05 (`.gitea/workflows/bump.yml`): weekly
schedule (Mon 05:17 UTC) + `workflow_dispatch` as the security
fast-lane; `nix flake update` → eval gate → pathspec-limited lock
commit pushed to `main` on green (that push triggers check.yml as the
second net). Update/commit/push logic simulated locally end-to-end in
a scratch clone, incl. a real update; today's bumped lock evals green.
Remaining (not confirmable from a session): the first scheduled or
dispatched run must land — watch that the runner picks up the cron and
that the Actions token can push. Then delete this item. Item 20's KVM
runner later upgrades the gate from eval-only to the VM suite.

### 20. KVM runner → VM suite in CI `[human]`
The remaining stretch of the CI item — checks-on-push is live and
**green** (run #58; runner = gitea/act_runner docker, eval tier).
Register a second runner on a host with `/dev/kvm` + nix (host-mode
label `nix-kvm`), then an agent uncomments the workflow's `vm-checks`
job: the `checks.*` VM suite + real toplevel/HM builds on every push
that later upgrades item 14's bump gate from eval-only to the full suite.

### 33. rofi page-overflow hint (scrollbar)
(Raised by Bernardo, 2026-07-07 — item 3.) When a list/grid overflows
onto another page, nothing signals there's more below. Add a scrollbar
(rofi's `scrollbar` element) or a "more ↓" hint, themed to the palette,
on the launcher grid and the long text menus. Check rofi 2.0.0's
scrollbar support/theming.
_Scoped 2026-07-07:_ rofi only draws the scrollbar when the list actually
overflows (`lines < rows`), so enabling it self-hides on short menus —
the right primitive. But it's a **visual, ~10-file slice**: the generated
palette theme (`rofi.nix`, `scrollbar = false`) **plus every authored
`.rasi`** (boreal/nord/lumon/kanagawa/retro-82/neon-glass/executive-slate/
summer-day/summer-night) — all deliberately set `scrollbar { width:0 }`
today, each needs a per-theme handle width/colour. Payoff is V3-only
(rendering), so it wants a themed session, not a headless edit.

### 41. Floating-window audit — remaining (needs hardware class checks)
(Raised by Bernardo, 2026-07-07 — item 11.) Broaden the `windowrule`
float set beyond the conservative first cut.
_Conservative cut shipped 2026-07-07 (iteration #63, on Bernardo's "take a
conservative approach"):_ float + center the mixer (item 35), **blueman**
(manager/adapters) and **system-config-printer** — the only shipped,
unambiguous config dialogs whose classes are confident. **Remaining
candidates, deliberately deferred because their window class can't be
verified headlessly** (a guessed class = dead rule): the polkit auth
prompt (hyprpolkitagent — no discoverable class in the package), GTK
file-chooser portals (`xdg-desktop-portal-gtk`), and any pinentry dialog.
Next slice: on hardware, run `hyprctl clients` while each is open, read
the real `class`, then append rules. Also revisit whether blueman/s-c-p
actually float once seen (regex tolerance for the `.…-wrapped` form).

## LATER

- **Wallpapers artifact split** (ROADMAP § Faster switches — decided,
  deferred): pinned `Nomarchy-wallpapers` input 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.
- **Night-light geo mode**: lat/long auto sunset/sunrise (means wlsunset).
- **Per-theme icon overrides** / more icon packs (ROADMAP § Icon themes).
- **MIPI/IPU software-ISP camera** support (no-UVC machines).
- **VPN exit-node richer display** (country/city) (optional).
- **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).

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



- **Battery charge-limit — make the toggle instant** `[blocked:hw]`
  (follow-up to the preset toggle shipped 2026-07-07, iteration #55).
  The control-center now has a proper toggle (Off / 80% / 90% / 60% /
  Custom…) writing `settings.power.batteryChargeLimit` — but that's a
  baked NixOS option, so it only lands on the next `sys-rebuild`. To make
  it instant (no rebuild): add a udev rule making
  `/sys/class/power_supply/BAT*/charge_control_end_threshold`
  group-writable (`MODE`/`GROUP`) so the menu can `echo N >` it live
  alongside persisting state (the sysfs oneshot in power.nix still owns
  boot + AC-replug re-apply), and/or surface a rofi-menu quick row or a
  Waybar action. `[blocked:hw]`: the sysfs write + no-rebuild effect can
  only be confirmed on a laptop exposing the threshold. Decide first
  whether the small privilege grant (a local user can set the charge cap)
  is acceptable.

- **Portal/Flatpak camera picker still lists the internal IR sensor**
  (ROADMAP § Webcam follow-up). The shipped IR-hide is a *WirePlumber
  v4l2* rule, but Flatpak/portal apps consume cameras via the
  **libcamera** path, where both sensors remain visible — a Flatpak
  Zoom user can still pick the black IR "camera". Options, roughly
  ascending cost: (a) do nothing — document it (portal camera support
  is still rare in practice); (b) a WirePlumber *libcamera* monitor
  rule disabling GREY-only nodes — needs verifying that libcamera
  monitor rules can match early enough (the v4l2 investigation found
  only `device.api` binds pre-rule, which is why surgical scoping
  failed before — same wall likely applies); (c) a libcamera
  configuration/udev quirk hiding the IR sensor at the libcamera layer
  itself. Cost: (b)/(c) need a T14s-style RGB+IR machine to verify →
  pairs with a hardware-queue session. Recommend (a) now, (b)
  investigated when the T14s is next available.








## Decisions `[human]`

Open calls only Bernardo can make; agents add options/evidence but never
decide.

- **Formatter adoption:** repo deliberately has none; `nixfmt-rfc-style`
  would flatten the aligned hand-formatting of ~33 files. Adopt or
  declare never?
- **Docs site vs Markdown-in-repo** (from the docs-review item).

- **zram swap:** faster under pressure and pairs with NOW#3, but it
  interacts with the hibernation-swapfile story (resume device/priority
  ordering) — adopt, adopt-with-hibernation-guard, or skip?
- **Default browser:** the template comments Firefox out. The shipped
  mime defaults (item 8, done) point `text/html`/http(s) at
  `firefox.desktop` as *inert* entries — they activate the moment
  Firefox is installed and are skipped otherwise, so the remaining call
  is only: ship a browser active in the suite, or stay
  browserless-by-default?

- **Default power backend — PPD vs TLP:** (raised by Bernardo 2026-07-08:
  would TLP be more power-efficient, and should it be the default?)
  TLP does get more *idle* battery life, but only from device-level knobs
  PPD deliberately omits — PCIe ASPM, disk/NVMe link PM, USB autosuspend,
  runtime PM — which are the same knobs behind NVMe/USB flakiness that
  pillar 1 (rock-stable, never fight your machine) guards against.
  **Evidence (2026-07-08):** no credible hard-watt benchmarks exist — TLP's
  own maintainer declines to quote any ("measure on your hardware") and says
  PPD's power-saver gives *similar* savings under load; TLP's edge is
  idle-only (linrunner.de/tlp/faq/ppd.html — PPD covers a *subset* of TLP,
  "no settings to reduce consumption when the CPU is idle"). Our sibling
  distro **Omarchy** ran this exact experiment — a "replace Power Profiles
  with TLP for battery" guide — and the author **reverted to PPD** ("more
  headaches and weird issues"); Omarchy shipped PPD auto-switching instead
  (basecamp/omarchy#3907). PPD 3.4.0 now does AC/battery auto-switching,
  closing part of TLP's UX gap. **Cost of TLP-default:** TLP has no live
  D-Bus profile API, so the `powermgmt` menu + Waybar profile indicator +
  low-battery auto power-saver (all `powerprofilesctl`) would need a rework —
  it's not a one-line backend swap. **Agent rec (evidence, not a decision):
  keep PPD default;** chase battery via targeted low-risk tweaks (PCIe ASPM
  policy, battery-side EPP, the charge *start* threshold, PPD auto-switching)
  and keep TLP the documented one-line opt-in it already is
  (`nomarchy.system.power.backend = "tlp"`). Options: (i) status quo +
  targeted tweaks [rec]; (ii) TLP default (reworks the profile UX);
  (iii) nothing.