chore: retire consumed specs and tasks, trim CLAUDE.md gotchas

The .claude specs and tasks have been distilled into the notes vault, so remove the 37 consumed files. Trim the CLAUDE.md gotchas to their project-specific residue: drop the entries now captured as general notes, and fix the two references that pointed at the deleted specs.
2026-07-24 21:40:50 -04:00
parent 8885ffae67
commit 582800d548
38 changed files with 15 additions and 2093 deletions
--- a/.claude/spec/firefox.md
+++ b/.claude/spec/firefox.md
@@ -1,122 +0,0 @@
 ## Problem Statement
 Neogaia now boots into the keyboard-driven Hyprland desktop, but the session ships no web browser.
 The operator lives in this desktop daily and needs a browser, yet a stock browser install would arrive un-themed, telemetry-on, cluttered with sponsored surfaces, and requiring a round of manual clicking to reach a usable state.
 That manual state would also be invisible to the flake and would not survive a reimage or transfer to the future desktop Host.
 The operator wants the browser configured the same way as the rest of the system: declared once, hardened and themed by default, and reproduced automatically on any Host that runs the desktop.
 ## Solution
 Add Firefox as a new single-purpose desktop Module, configured entirely through home-manager's `programs.firefox`, and fold it into the desktop aggregator so the browser is part of the daily-drivable session rather than a separate opt-in.
 Ship stock mainline Firefox, hardened and de-monetized through locked enterprise policies, with a small fixed set of extensions force-installed by policy from Mozilla's add-on site.
 Default search to DuckDuckGo over a lean, pruned engine list.
 Theme the browser Nord from the same single Stylix source that themes the rest of the graphical layer, with no hand-maintained browser CSS.
 Register Firefox as the system default handler for web links.
 Leave the most personal, frequently-changing state — bookmarks and container tabs — to Firefox's own runtime management rather than declaring it, keeping the Module lean and avoiding the destructive overwrite those declarative options impose.
 Because the Module joins the aggregator, it comes up on any Host with the desktop enabled: neogaia now, and the future desktop Host for free, with no per-Host browser flag.
 ## User Stories
 1. As the operator, I want a web browser present the moment the desktop comes up, so that a daily-drivable session includes browsing without a separate install step.
 2. As the operator, I want the browser expressed as one more enable in the desktop aggregator, so that any Host running the desktop inherits it and the future desktop Host adopts it without rework.
 3. As the operator, I want the browser configured declaratively alongside every other Module, so that it is reproduced identically on reimage and never depends on manual post-install clicking.
 4. As the operator, I want to stay on current mainline Firefox rather than an older release train, so that I get up-to-date browser features and security without maintaining an unusual package variant.
 5. As the operator, I want a fixed set of extensions installed and actually enabled automatically, so that ad-blocking, password management, and sponsor-skipping work on first launch with no add-on hunting.
 6. As the operator, I want ad and content blocking, so that pages are lighter and less hostile.
 7. As the operator, I want my password manager available in the browser, so that credentials autofill without me reaching for another app.
 8. As the operator, I want sponsor segments skipped in videos, so that watching is uninterrupted.
 9. As the operator, I want telemetry, studies, the read-it-later widget, and the sponsored surfaces on the new-tab and address bar turned off and kept off, so that the browser is quiet, private, and un-monetized without me policing settings.
 10. As the operator, I want the browser to stop offering to save logins and to stop nagging about being the default, so that it does not fight the password manager or interrupt me.
 11. As the operator, I want Firefox accounts and sync disabled, so that no account surface appears for a feature I do not use.
 12. As the operator, I want DuckDuckGo as the default search with only a lean set of engines present, so that search is private and uncluttered.
 13. As the operator, I want the browser themed Nord from the same source as the rest of the desktop, so that it coheres with the bar, launcher, and lock screen without me hand-theming it.
 14. As the operator, I want the browser registered as the system default for web links, so that links opened from the bar, notifications, the launcher, or the terminal land in it.
 15. As the operator, I want bookmarks and container tabs left to the browser itself, so that the things I add in the moment are never wiped by a rebuild.
 16. As the operator, I want the whole Host to still build green under the existing check, so that I gain confidence before switching a live machine.
 ## Implementation Decisions
 **Module and placement**
 - A new single-purpose Module is added under the desktop group, namespaced to mirror its location per the Namespace convention, exposing one `enable` option guarded by the Enable convention.
 - The Module is configured entirely through the primary user's home-manager `programs.firefox`, matching every other user-facing Module in the repo; no NixOS-level Firefox program integration and no manual package override are used.
 - The desktop aggregator turns the Module on at default priority alongside the terminal and the other session pieces, so a single desktop flag brings the browser up while a Host retains the ability to override it.
  The browser is treated as an essential application of the session rather than optional plumbing, following the precedent that the aggregator already enables the terminal.
 **Package variant and extension mechanism**
 - The package is stock mainline Firefox, not ESR, unbranded, or Developer Edition.
 - Extensions are installed through Mozilla's enterprise policy `force_installed`, keyed by add-on id with an install URL, so the browser fetches the signed add-on from Mozilla's add-on site and enables it automatically.
 - Nix-built or hash-pinned add-on packages are not used, because stock Firefox refuses unsigned locally-built add-ons; the trade-off — losing build-time reproducibility of the extension binaries in exchange for current mainline Firefox with add-ons that are actually enabled and no new flake input — is accepted deliberately.
  This decision is the pivotal, hard-to-reverse one and is called out for an ADR in Further Notes.
 **Extensions**
 - Three extensions are force-installed: an ad and content blocker, the operator's password manager, and a video sponsor-skipper.
 - All three are self-contained web extensions, so no native messaging host is wired.
 **Hardening**
 - Hardening is split across two mechanisms by intent: things with a corresponding enterprise policy are set as locked policies so they cannot be toggled back in the UI, and the remainder are set as ordinary profile preferences.
 - Locked policies turn off telemetry and studies and data reporting, turn off the read-it-later widget, stop the browser offering to save logins, stop the default-browser check, strip the sponsored shortcuts, sponsored stories, and snippets from the new-tab page, and disable Firefox accounts and sync.
 - Profile preferences turn off sponsored address-bar suggestions and tidy the new-tab surface.
 - Fingerprinting resistance is deliberately left off, because it breaks enough everyday browsing to be a deliberate per-need choice rather than a baseline.
 **Search**
 - A single profile is declared, named as the default profile.
 - The default engine is DuckDuckGo, and the engine list is pruned to a lean set with the general-purpose commercial engines removed; the removed engines remain reachable through DuckDuckGo's bang syntax.
 - Declaring search requires the module's authoritative-overwrite acknowledgement, so engines added later through the UI are not preserved across a rebuild; this is accepted as the point of declaring search.
 **Theming**
 - The browser is themed by enabling the Stylix Firefox target against the declared profile, driven from the same single Nord scheme that themes the rest of the graphical layer.
 - No hand-written browser chrome CSS is shipped; a small chrome-CSS layer remains a later addition on top of Stylix if deeper chrome restyling is ever wanted.
 - The Firefox Stylix target is enabled from within the browser Module, mirroring how the theming Module already sets per-Module Stylix targets, so the target only takes effect when the browser is enabled.
 **Default browser**
 - Firefox is registered as the default handler for the web-link schemes and HTML through the primary user's home-manager mime-association config, placed in the browser Module.
 **Existing conventions already satisfied**
 - The Waybar workspace indicator already carries a window-rewrite icon mapping for Firefox, so the graphical-application icon convention needs no change.
 ## Testing Decisions
 - A good test asserts externally-observable evaluation and build success of the whole Host, not the internals of the Module.
  This mirrors the desktop and laptop-MVI stance, where the config-merge model makes the whole-Host build the meaningful unit and the highest available seam.
 - Primary seam, required and existing: the neogaia Host evaluates and its system toplevel builds under the flake check.
  Building the toplevel drives the Auto-loader discovering the new Module, the aggregator fan-out, home-manager wrapping the Firefox package with the policies, extensions, search, and preferences baked in, the Stylix Firefox target wiring, and the default-handler association, surfacing nearly all config-authoring errors short of launching the browser.
 - Cheap targeted checks: evaluate specific configuration paths to confirm the aggregator fans the browser enable out, the rendered policies carry the three force-installed extensions, the default search engine resolves to DuckDuckGo, and the Stylix Firefox target is on, reusing the repo's existing lightweight eval-probe pattern.
 - No Module-level unit tests are added; there is no seam below the whole-Host build worth testing here, and the prior art is the desktop and laptop-MVI build-the-toplevel checks.
 - The genuine end-to-end confirmation is manual and irreducible: switch the configuration on neogaia, launch the browser, and confirm the three extensions are present and enabled, the Nord theme is applied, DuckDuckGo is the default search, and a link opened from another application lands in the browser.
  A browser cannot self-test headless, but unlike a reimage this is reversible, so verification is done by living in it with a safety net of a generation rollback or the desktop flag.
 - The build validates that the policy document is well-formed and baked into the package, but not that Firefox accepts every policy key semantically, since the policy document is only text until the browser loads it; that last mile is part of the manual confirmation.
 ## Out of Scope
 - ESR, unbranded, and Developer Edition Firefox variants, and the nix-built or hash-pinned add-on path they would enable; the reproducibility trade-off was weighed and declined.
 - Native messaging hosts of any kind, including a password-manager native connector and desktop browser-integration bridges; none of the chosen extensions need one.
 - Declarative bookmarks and declarative container tabs, both deliberately left to the browser's own runtime state.
 - The Multi-Account Containers extension and the contextual-identity preference it relies on.
 - Multiple Firefox profiles; a single default profile carries everything.
 - Custom or Nix-oriented search engines beyond the lean pruned set.
 - Hand-written browser chrome CSS and any deep chrome-layout restyling such as compact tabs or a hidden title bar.
 - Fingerprinting resistance and any harder privacy posture that routinely breaks everyday browsing.
 - Firefox accounts and sync.
 - Any second browser, and any per-Host browser divergence; the future desktop Host inherits this same Module unchanged.
 - Any Skeleton, Auto-loader, or secret-wiring change; the Module uses the existing plumbing unchanged.
 ## Further Notes
 - The stock-Firefox-plus-policy-extensions decision is hard to reverse — the variant dictates the entire extension mechanism — surprising without context, since a Nix-purist default would expect hash-pinned add-on packages, and the product of a real trade-off between reproducibility and current mainline Firefox with working extensions.
  It should be recorded as an ADR.
 - Home-manager's `programs.firefox` was confirmed to expose a top-level policies option that merges into the wrapper's enterprise policies, which is what lets the whole Module, hardening included, live under home-manager rather than needing the NixOS-level program integration.
 - The declarative search, bookmarks, and containers options all share one authoritative-overwrite model: the browser owns those files at runtime, so declaring them means home-manager overwrites them wholesale and runtime-added entries do not survive a rebuild.
  This is why bookmarks and containers are left out and why declaring search is an explicit acknowledgement.
 - The extension set fetches signed add-ons from Mozilla's add-on site at runtime rather than from the Nix store, so first launch after a fresh build needs network to populate the extensions; this is inherent to the policy-based path chosen over the pinned-package path.
--- a/.claude/spec/hyprland-desktop.md
+++ b/.claude/spec/hyprland-desktop.md
@@ -1,173 +0,0 @@
 ## Problem Statement
 Neogaia currently boots to a console only.
 The laptop minimum viable install deliberately deferred everything graphical, so the operator works entirely from the terminal (fish, tmux, nvim, Claude Code) with no desktop to live in.
 The operator wants a graphical desktop, and it must be primarily keyboard-driven.
 Their mental model is i3: numbered workspaces, `Super`+number to switch, manual tiling.
 They type on a 60% keyboard where arrow keys and the navigation cluster live behind a layer, so a keyboard-first workflow that never reaches for those keys matters.
 The same desktop has to transfer to the future desktop Host (zeus), which must game well and stay low-friction in general.
 The operator previously ran KDE Plasma 6 bent into an i3 imitation and valued above all that it "just worked", but remembers past i3/Sway minimalism costing hours of fixing random breakage.
 That concern is now largely mitigated: NixOS makes the whole stack declarative, pinned, and reversible, and the agent absorbs the discovery and debugging that used to eat evenings.
 ## Solution
 Add a keyboard-driven Wayland desktop built on Hyprland, expressed as a new grouped set of Modules.
 Enable it on neogaia now, and design it Host-agnostic so zeus adopts the identical desktop later by flipping a single flag.
 Deliver a complete, daily-drivable session in one pass rather than a bare stub, because unlike the reimage this is fully reversible ("edit and rebuild"), so there is no safety reason to under-scope.
 The session covers the compositor, a text login, Nord theming, a status bar, a launcher, notifications, lock and idle, a wallpaper, clipboard history, screenshots, screen recording, and the desktop portals, together with the operator's ported keybinds and input tuning.
 Theme the whole graphical layer Nord from a single source (Stylix), scoped so it owns only the new graphical surface and leaves the existing terminal Modules' hand-themes untouched.
 Leave gaming out entirely; it belongs to a future zeus-oriented Module, and neogaia is not a gaming machine.
 ## User Stories
 1. As the operator, I want neogaia to boot into a keyboard-driven Hyprland session, so that I can live in a graphical desktop without leaving my keyboard-first workflow.
 2. As the operator, I want the desktop expressed as Host-agnostic Modules enabled by a single flag, so that zeus can adopt the identical desktop later without rework.
 3. As the operator, I want a text-based login, so that I log in mouse-free without a heavy graphical display manager.
 4. As the operator, I want the whole graphical layer themed Nord from one source, so that GTK, Qt, the bar, the lock screen, and the launcher cohere without me hand-theming each, while my existing nvim, tmux, and fish themes stay exactly as they are.
 5. As the operator, I want a fast modern terminal launched on `Super+Return`, so that my tmux and nvim stack has a clean frame and my old muscle memory for opening a terminal carries over.
 6. As the operator, I want a status bar showing workspaces with per-application icons, clock, battery, network, audio, media controls, and a do-not-disturb toggle, so that I can read system state at a glance.
 7. As the operator, I want a search-everything launcher covering applications, open windows, math evaluation, and emoji, reused as the frontend for clipboard history and a power menu, so that one keybound tool handles launching and utility menus.
 8. As the operator, I want notification toasts with do-not-disturb and history recall, so that I see notifications and can retrieve ones I missed.
 9. As the operator, I want a secure lock screen and idle management, so that going idle, suspending, or closing the lid always lands me at a locked screen, and the lock survives even if the locker process crashes.
 10. As the operator, I want a single static Nord wallpaper, so that the desktop looks coherent with no extra moving parts and no battery cost.
 11. As the operator, I want clipboard history picked through the launcher, so that I can paste from recent copies entirely by keyboard.
 12. As the operator, I want keyboard-driven screenshots for a region, the active window, or the full screen that open in an annotation editor by default and land in both the clipboard and a file, so that capturing and marking up is a single reflex.
 13. As the operator, I want a keybound screen recorder that selects a region and then toggles recording, so that capturing demos becomes a habit.
 14. As the operator, I want screen sharing to work inside applications, so that video calls and browser screen-share function.
 15. As the operator, I want my keybinds ported from my KDE/i3 scheme but expressed entirely in `hjkl` and letters with no arrow or navigation-cluster keys, so that every binding is reachable on my 60% keyboard.
 16. As the operator, I want numbered-workspace bindings, so that my i3 muscle memory of `Super`+number to switch and `Super`+`Shift`+number to move carries over unchanged.
 17. As the operator, I want Caps mapped to Escape, a US-only layout, snappy key-repeat, and touchpad tap-to-click, natural scroll, and disable-while-typing with flat mouse acceleration, so that input feels like home on the laptop.
 18. As the operator, I want subtle animations with rounding and small gaps but no blur on the laptop, so that the desktop feels modern without draining the battery.
 19. As the operator, I want the desktop built from granular single-purpose Modules grouped together with an explicit aggregator, so that a Host enables the whole desktop with one flag yet can still override any single piece.
 20. As the operator, I want gaming deliberately excluded from this pass, so that neogaia's desktop stays focused and the gaming stack lands with zeus.
 21. As the operator, I want the whole Host to still build green under the existing check, so that I gain confidence before switching a live machine.
 ## Implementation Decisions
 **Direction and compositor**
 - Hyprland is the compositor, on neogaia now and zeus later, chosen as a single keyboard-driven tiler that serves both Hosts.
  It matches the operator's i3 workflow (numbered workspaces, manual tiling) while getting closest to "just works" among true tilers through its cohesive first-party companion tools and large ecosystem.
 - The choice was made over Sway (its minimalism is the very thing that cost the operator evenings), KDE Plasma (mouse-first at heart), and niri (its scrollable-tiling paradigm abandons numbered workspaces and so breaks the operator's core muscle memory).
 - The gaming/driver dimension does not discriminate here: neogaia is Intel and zeus is AMD, both of which drive Wayland flawlessly, so the decision rested on workflow and low-friction rather than on surviving a hostile driver.
  This corrects a stale assumption in the laptop spec (see Further Notes).
 - Hyprland is sourced from nixpkgs rather than the upstream Hyprland flake.
  The NixOS-level program integration owns the session, portals, and polkit, and home-manager owns the user configuration, sharing one Hyprland package so there is never a version split.
  The session is launched through the universal Wayland session manager from the greeter for clean systemd session and environment integration.
  No compositor plugins are adopted this pass, which removes the main reason to take the flake; moving to the flake later is a contained change that mirrors the existing chaotic-nyx pattern (an input that must not follow nixpkgs, with its own binary cache).
 **Session and theming**
 - Login uses greetd with the tuigreet text greeter.
  This is mouse-free and lightweight, avoiding a heavy graphical display manager and its Qt/GTK weight.
 - Theming uses Stylix, scoped to the graphical layer.
  A single Nord base16 scheme drives colors, system fonts, cursor, and the static wallpaper across the new graphical surface (GTK, Qt, bar, lock, launcher, notifications, compositor colors).
  Stylix targets for the existing terminal tools (nvim, tmux, fish) are left off so their established hand-themes stand unchanged.
  The terminal is themed by Stylix where its target is mature, with hand-written Nord as a fallback otherwise.
  This decision is highly reversible: Stylix toggles per target, so the graphical layer can migrate toward or away from manual theming later at low cost.
 **Components**
 - Terminal: Ghostty.
 - Status bar: Waybar, showing workspaces with per-application icons plus clock, battery, network, audio, MPRIS media controls, and a do-not-disturb toggle.
  No overview/exposé plugin is used; the workspace indicators are sufficient.
 - Launcher: rofi (the Wayland fork), combining application-run, binary-run, and window-switch modes into one prompt, plus math-evaluation and emoji modes.
  It is reused as the dmenu-style frontend for clipboard history and a power menu, so one tool serves several jobs.
 - Notifications: mako, with do-not-disturb and history recall.
  Media controls and the do-not-disturb toggle live in the bar rather than in a separate notification center.
 - Lock and idle: hyprlock and hypridle.
  hyprlock uses the compositor session-lock protocol, so the lock surface is owned by the compositor and survives a locker crash.
  hypridle is wired for lock-on-idle, screen-off, lock-before-suspend, and lid-close, with tunable timeouts.
 - Wallpaper: a single static image set by Stylix.
 - Clipboard: cliphist with wl-clipboard, storing text and image history, picked through rofi.
 - Screenshots: grim and slurp wrapped by grimblast, routed through the satty annotation editor so that annotation is the default on region, active-window, and full-screen captures, each exporting to both the clipboard and a file.
 - Screen recording: wf-recorder, region-select-first and video-only (no audio), toggled by a keybind with a bar recording indicator and notifications.
 - Portals: the Hyprland desktop portal (screencast, screenshot, global shortcuts) plus the GTK portal (file dialogs and appearance).
  Screen sharing in applications depends on these regardless of whether the recorder is present.
 **Keybinds**
 The scheme ports the operator's KDE/i3 bindings but is expressed entirely in `hjkl` and letters, with no arrow or navigation-cluster keys, so it is fully reachable on a 60% keyboard.
 Bindings that were quick-tile-to-half on the floating KDE desktop are reclaimed for real tiling actions, because that gesture is meaningless in an automatic tiler.
 | Action | Bind |
 |---|---|
 | Switch to workspace N | `Super`+`1`..`9` |
 | Move window to workspace N | `Super`+`Shift`+`1`..`9` |
 | Move focus | `Super`+`h`/`j`/`k`/`l` |
 | Move window in layout | `Super`+`Shift`+`h`/`j`/`k`/`l` |
 | Resize | `Super`+`Alt`+`h`/`j`/`k`/`l` |
 | Terminal | `Super`+`Return` |
 | Launcher | `Super`+`R` |
 | Lock | `Super`+`X` |
 | Toggle floating | `Super`+`Space` |
 | Fullscreen | `Super`+`F` |
 | Toggle split | `Super`+`T` |
 | Close window | `Super`+`Shift`+`Q` |
 | Force-kill | `Super`+`Ctrl`+`Q` |
 | Screenshot region / window / full (to satty) | `Super`+`L` / `Super`+`Shift`+`L` / `Super`+`Ctrl`+`L` |
 | Clipboard history | `Super`+`Shift`+`V` |
 | Record toggle (region first) | `Super`+`Shift`+`R` |
 | Volume / brightness / media | `XF86` hardware keys |
 **Input**
 - US-only keyboard layout, with no layout switcher.
 - Caps mapped to Escape, with Shift+Caps still producing a real CapsLock.
 - Key-repeat tuned snappy (a short delay before repeat begins, a fast repeat rate).
 - Touchpad with tap-to-click, natural scroll, and disable-while-typing.
 - Mouse with flat acceleration.
 **Feel**
 - Tasteful, subtle animations with modest rounding and small gaps.
 - Blur is off on the laptop, where it is the single biggest battery cost; it remains a knob a Host such as zeus can enable.
 **Module structure**
 - The desktop is a set of granular, single-purpose Modules grouped under a desktop directory, each independently toggleable so pieces stay reusable and the files stay focused.
  The tightly coupled Hyprland-native pieces (compositor, lock, idle) are grouped in a subdirectory within that group.
 - An explicit aggregator Module turns the desktop on.
  Guarded by its own enable, it sets each piece's enable at default priority so that a Host enables the whole desktop with one flag while retaining the ability to override any single piece.
  The aggregator hand-lists the pieces it enables rather than scanning the directory, so a newly added file stays inert until deliberately added to that list; this keeps the whole desktop legible from one file.
 - The desktop's enable options are namespaced under a single desktop group, so a Host's checklist gains one desktop entry and the aggregator itself reads as the sub-checklist of what that entry means.
 - This uses the existing recursive Auto-loader as-is: every file in the group is imported unconditionally (inert until enabled), so no Skeleton change is needed.
  The aggregator/namespaced-group pattern is a deliberate evolution of the flat Module plus Host-as-checklist convention (see Further Notes).
 ## Testing Decisions
 - A good test asserts externally-observable evaluation and build success of the whole Host, not the internals of any individual Module.
  This mirrors the laptop MVI's stance, where the config-merge model makes the whole-Host build the meaningful unit and the highest available seam.
 - Primary seam (required, existing): the neogaia Host evaluates and its system toplevel builds under the flake check.
  Building the toplevel drives the Auto-loader discovering the new Modules, the aggregator fan-out, home-manager integration, the full Stylix wiring, the Hyprland program integration, and package availability, surfacing nearly all config-authoring errors short of rendering a frame.
 - Cheap targeted checks: evaluate specific configuration paths to confirm the desktop aggregator fans out, the Stylix scheme resolves to Nord, and Hyprland is enabled, reusing the repo's existing lightweight eval-probe pattern.
 - No Module-level unit tests are added; there is no seam below the whole-Host build worth testing here, and the prior art is the laptop MVI's build-the-toplevel check.
 - The genuine end-to-end confirmation is manual and irreducible: switch the configuration on neogaia, log in through the greeter, and exercise the live session (keybinds, lock, screenshot, clipboard, launcher).
  A graphical session cannot self-test headless, but unlike the reimage this is reversible, so verification is done by living in it with a safety net (roll back a generation, drop to a console, or disable the desktop flag).
 - VM-based graphical CI (boot assertions under a NixOS test) is deferred, consistent with the laptop MVI's stated stance.
 ## Out of Scope
 - The gaming stack (Steam, gamescope, Proton, replay-buffer recording, OBS), which belongs to a future zeus-oriented Module.
 - The zeus Host itself, and multi-monitor/output configuration, since there is no second display to design against yet; monitor focus and move bindings are deferred with it.
 - Any non-Hyprland desktop; KDE, Sway, and niri were considered and rejected.
 - The upstream Hyprland flake and compositor plugins, including workspace-overview/exposé, which are explicitly not adopted this pass.
 - Migrating the existing nvim, tmux, and fish themes into Stylix; they stay hand-themed.
 - Dynamic, animated, or video wallpaper, and wallpaper cycling.
 - Screen-recording audio and a full-screen recording variant.
 - A slide-out notification-center panel and a batteries-included desktop panel; both were considered and rejected in favor of the minimal, Stylix-coherent stack.
 - Any change to the Skeleton or the Auto-loader; the structure uses them unchanged.
 - Any secret wiring.
 ## Further Notes
 - The compositor decision (Hyprland over Sway, KDE, and niri) is hard to reverse and the result of a real trade-off, so it should be recorded as an ADR.
 - The aggregator plus namespaced-group Module pattern is a deliberate departure from the flat, Host-as-full-checklist convention, and is worth recording as a short ADR or a conventions note so its intent is not relearned.
 - The laptop MVI's out-of-scope line attributing Nvidia to zeus is factually wrong: zeus runs an AMD GPU, and Raichu (a server with no desktop) is the only Nvidia machine.
  The laptop MVI is a historical document and is left unchanged, so the accurate fact is recorded here and in ADR 0003 instead.
 - The ported keybind scheme is derived from the operator's prior KDE Plasma 6 configuration (nine numbered desktops, `Super`+number bindings, a terminal on `Super`+`Return`, Caps mapped to Escape, and custom per-desktop tile layouts), which lives in this repo's git history under the old reference config.
 - Neogaia is Intel and zeus is AMD, both of which drive Wayland without driver caveats; this is what lets one keyboard-first compositor serve both Hosts rather than forcing a per-Host divergence.
--- a/.claude/spec/laptop-mvi.md
+++ b/.claude/spec/laptop-mvi.md
@@ -1,92 +0,0 @@
 ## Problem Statement
 I'm returning to NixOS after ~2 years away, and I want to start by moving my laptop (`neogaia`, a Dell XPS 13 9380 currently running CachyOS) onto it. My old config still exists but is stale and written in a style I no longer want to copy verbatim. Eventually this same config has to grow to cover my desktop and three servers, so whatever I build for the laptop has to be a clean, scalable foundation — not a throwaway.
 Reimaging the laptop is destructive and I only get one machine, so I need a tightly-scoped, well-understood **minimum viable install (MVI)**: the smallest config that boots the laptop into a usable state I can then iterate on live, without risking a half-defined system that strands me at a dead console.
 ## Solution
 Rebuild the `Skeleton` and a single `neogaia` `Host` to the point where the laptop:
 - boots from an encrypted disk (LUKS + btrfs + zram),
 - comes up on wifi,
 - lets me log into a console as my user and run `nixos-rebuild switch`,
 - and already carries my core terminal tooling (fish, tmux, nvim, Claude Code).
 Everything graphical and everything multi-host is deliberately left for later iterative passes, which are safe because a mistake then is "edit and rebuild," not "reimage." The MVI is the one step that must be right *before* reimaging; the rest is reversible.
 The install itself is done from the NixOS live ISO by cloning the repo from my Gitea and running a single `disko-install` against the `neogaia` `Host`, then setting a bootstrap password by hand.
 ## User Stories
 1. As the operator, I want the `Skeleton` rewritten around my old scalable ideas (the `Auto-loader`, the `Enable convention`, per-`Host` layout), so that the config stays legible and shareable across all five future machines without me copying stale code.
 2. As the operator, I want the flake hand-rolled and cleaned up (no framework layer), so that the whole plumbing stays readable in one place for a config that only targets a handful of `x86_64-linux` machines.
 3. As the operator, I want every `Module` auto-discovered and imported but inert until a `Host` sets its `enable` flag, so that each `Host` reads as a checklist of features.
 4. As the operator, I want a `nixos-unstable` base with an `unstable overlay` and a `stable overlay`, so that I can run rolling by default but reach up to bleeding-edge or down to rock-solid on a per-package basis.
 5. As the operator, I want home-manager integrated as a NixOS module with global packages, so that one `nixos-rebuild switch` builds both the system and my user environment atomically.
 6. As the operator, I want my user modelled as an explicit option defaulting to `alexion` (no impure environment lookup), so that the config is reproducible and honest about who the user is.
 7. As the operator, I want the laptop's disk declared with `disko` as encrypted btrfs plus zram swap, so that the install is reproducible and the laptop is encrypted at rest.
 8. As the operator, I want the system to prompt for the LUKS passphrase at boot via systemd-boot and the initrd, so that the encrypted disk unlocks on a normal boot.
 9. As the operator, I want the CachyOS kernel from chaotic-nyx with the chaotic binary cache wired in from the first build, so that I get the performance/feel I'm used to without compiling the kernel from source.
 10. As the operator, I want Intel microcode and the redistributable firmware for the QCA6174 wifi included, so that the laptop's hardware works out of the box.
 11. As the operator, I want NetworkManager enabled, so that I can join wifi easily from the console.
 12. As the operator, I want an SSH daemon running, so that I can drive the rest of the setup remotely if the console is inconvenient.
 13. As the operator, I want my user in `wheel` with a manually-set bootstrap password, so that I can log in and use sudo on first boot without committing any secret to a public repo.
 14. As the operator, I want fish as my default login shell, configured natively via home-manager with my `cachyos-config.fish` translated (greeting, bat-manpager, `done` and bang-bang plugins, helper functions, eza/nav aliases) and all Arch/pacman-specific parts dropped or replaced with NixOS equivalents, so that my shell feels like home but is correct for NixOS.
 15. As the operator, I want tmux configured natively via home-manager using my exact existing `tmux.conf` text, so that my terminal multiplexer is identical to today with no plugin manager needed.
 16. As the operator, I want my nvim config brought in verbatim (lazy.nvim managing its own plugins) via a writable out-of-store symlink, with `git`/`gcc`/`ripgrep`/`fd` provided by Nix, so that my editor is identical to today and lazy.nvim can still update and write its lockfile.
 17. As the operator, I want Claude Code installed declaratively and authenticatable without a browser on the laptop, so that I can use it over the console/SSH via the paste-code flow or an API key.
 18. As the operator, I want timezone `America/New_York`, locale `en_GB.UTF-8`, and console keymap `us` set, so that the base system matches my locale preferences.
 19. As the operator, I want to install by cloning the repo from my Gitea onto the live ISO and running `disko-install` against `neogaia`, so that I avoid self-signed-TLS/auth problems with flake fetching during install.
 20. As the operator, I want the `Skeleton` designed so that per-`Host` disk layouts, per-`Host` kernels, and preserved ZFS pools are all expressible, so that the same foundation extends to the desktop and the three servers later without restructuring.
 ## Implementation Decisions
 **Skeleton**
 - Hand-rolled flake, rewritten and trimmed; no flake-parts.
 - `Auto-loader` rewritten: recursively discovers and imports every `Module` under the modules tree without the old null-placeholder traversal hack; a single discovery helper feeds the `Host` imports. The old `nixosModules` flake output is dropped.
 - Helper lib trimmed to the `Auto-loader`, the host-builder, and the script-from-file helper. `with lib.my` replaced by explicit `inherit`s throughout. `enable` flags use the stdlib enable-option helper rather than bespoke sugar.
 - `nixos-unstable` as the base channel. An `unstable overlay` exposes `nixpkgs-unstable` packages; a `stable overlay` exposes the latest stable release (`nixos-26.05`). chaotic-nyx added as an input with its overlay and binary cache from the start.
 - home-manager sourced from `nix-community`, tracking master with nixpkgs followed, integrated as a NixOS module with global packages and user packages.
 - User modelled as an explicit option defaulting to `alexion`, in `wheel`, driving the system user and the home-manager user in lockstep.
 **neogaia Host**
 - Disk declared via `disko`: LUKS-encrypted btrfs with subvolumes plus zram swap. systemd-boot on an EFI system partition; initrd LUKS unlock.
 - CachyOS kernel selected via a small per-`Host` kernel mechanism; chaotic substituter and trusted key in the Nix settings.
 - Intel microcode; redistributable firmware enabled for the QCA6174 wifi. NetworkManager for networking. A zram toggle `Module` enabled here.
 - SSH daemon enabled. Baseline CLI (git, editor, flakes) present. Claude Code installed declaratively.
 - fish `Module`: native home-manager configuration; translated aliases/functions/plugins/init; set as the default login shell. tmux `Module`: native home-manager, exact existing config text inlined. nvim `Module`: verbatim config placed as a writable out-of-store symlink with runtime dependencies provided by Nix.
 - Locale, timezone, and keymap set to the detected values.
 **Install flow**
 - Repo pushed to Gitea first. From the NixOS live ISO: join wifi, clone the repo locally, run `disko-install` against the `neogaia` `Host` with the chaotic substituter passed to the install-time daemon, set bootstrap passwords via `nixos-enter`, reboot.
 **Secrets (design only in MVI)**
 - Per ADR 0001, secrets use `sops-nix` with age keys derived from each `Host`'s SSH host key. The MVI does not wire any secret, because a `Host`'s age key does not exist until its first install generates the SSH host key. The bootstrap password is set by hand and never committed; moving passwords to a `hashedPasswordFile` backed by a sops secret is the first post-boot task, out of scope here.
 ## Testing Decisions
 - A good test here asserts externally-observable evaluation/build success of the whole `Host`, not the internals of any individual `Module`.
 - **Primary seam (required):** the `neogaia` `Host` evaluates and its system toplevel builds. Building the toplevel drives the entire `Skeleton` — the `Auto-loader` discovering every `Module`, all three overlays resolving, home-manager integration, and every enabled module's config merging without conflict — plus the `disko` layout, which builds from the same tree. Nearly all config-authoring errors surface at this seam short of booting real hardware.
 - No unit-level tests of individual modules; the config-merge model makes the whole-`Host` build the meaningful unit, and it is the highest available seam.
 - Prior art: none in this repo yet (it starts empty); this build-the-toplevel check is the pattern to reuse for every future `Host`.
 - The genuine end-to-end confirmation is the real reimage, which is manual and irreversible by nature and is not automated.
 ## Out of Scope
 - Any graphical environment: Wayland-vs-i3 choice, greeter/display manager, theming (Nord via Stylix or otherwise), fonts, terminal emulator, browser, general desktop apps, gaming (Steam/Lutris/proton-cachyos), emulation.
 - Full `sops-nix` wiring and moving passwords off the bootstrap value (immediate post-boot follow-up, but not MVI).
 - Migrating nvim to a native home-manager configuration with Nix-managed plugins.
 - chaotic-nyx packages beyond the kernel (`mesa-git`, `proton-cachyos`, `scx` schedulers).
 - Flatpak strategy (`nix-flatpak` vs dropping the old imperative helper).
 - The desktop `Host` (`zeus`), including Nvidia.
 - The three servers: deployment model, service migration (plex/arr/kavita/nfs/torrent-through-protonvpn), ZFS wiring and pool import, backups/monitoring, and per-server kernel/channel pinning.
 - VM-based CI (`nixosTest` boot assertions) — explicitly a future addition, not part of this deliverable.
 ## Further Notes
 - **Bootstrap ordering:** the flake must exist on Gitea before the install can consume it, and the manual password step keeps the public repo free of any secret while still yielding a login on first boot.
 - **Gitea is a bootstrap dependency:** every NixOS install pulls the config from self-hosted Gitea, so the Gitea host must stay reachable during any install — relevant when sequencing the servers so the migration never locks the operator out of their own configs.
 - **chaotic cache at install time:** the install-time Nix daemon on the live ISO must have the chaotic substituter configured, or it compiles the CachyOS kernel from source on the USB stick.
 - **Extends to future Hosts by construction:** disk layout, kernel, and channel are all per-`Host` concerns in the `Skeleton`, and existing ZFS pools are preserved by import rather than declared through `disko`. This is what lets the desktop and the three servers join later without reworking the foundation.
 - **Theme target is Nord** (the current CachyOS setup is Nord across terminal, tmux, and nvim), superseding the old repo's Dracula — relevant when the theming branch is grilled.
--- a/.claude/spec/pi-coding-agent.md
+++ b/.claude/spec/pi-coding-agent.md
@@ -1,76 +0,0 @@
 ## Problem Statement
 I run Claude Code as my coding agent on `neogaia`, wired deeply into this flake: skills, a sudo-guard hook, shared agent instructions, and the whole `.claude/` workflow.
 Pi is a young, fast-moving, self-modifying terminal coding agent that I want to evaluate as an alternative harness.
 I need to install it on the laptop in a way that lets me try it honestly — same model, same account — without unpicking any of the Claude Code setup and without committing myself to Pi before it has earned a permanent place.
 The evaluation only means something if the one variable under test is the harness itself, and if backing Pi out later is trivial.
 ## Solution
 Add a new `pi` Module that installs Pi for the primary user on `neogaia`, enabled by the Enable convention like every other feature.
 It flips the home-manager `programs.pi-coding-agent` module on and freezes exactly one file — `settings.json` — pinning the provider and model so Pi runs the same brain as Claude Code (Anthropic, Opus) and disabling analytics so Pi never attempts a runtime write to that frozen file.
 Everything else is left to Pi's own writable state directory (`~/.pi/agent/`): no agent context, no skills, no extensions, no keybindings, no custom model providers.
 Pi authenticates by reusing my existing Claude subscription, and that credential is deliberately left unmanaged by the flake so no secret touches the repo and re-auth survives rebuilds — exactly as the `claude-code` Module already treats its login.
 The result is a minimal, non-disruptive, side-by-side experiment: Claude Code stays the daily driver, Pi sits alongside it, and removing Pi is a one-line `enable` flip.
 ## User Stories
 1. As the operator, I want Pi installed as its own auto-discovered Module that stays inert until a Host enables it, so that Pi reads as one more `enable = true` line on `neogaia` and never rides silently onto future Hosts.
 2. As the operator, I want Pi enabled only on `neogaia`, so that the experiment is contained to the machine I actually drive.
 3. As the operator, I want Pi to run Anthropic's Opus by default, matching Claude Code's model, so that any difference I observe between the two is attributable to the harness and not the model.
 4. As the operator, I want Pi's provider and default model pinned reproducibly in the flake, so that the same Pi configuration would rebuild identically on any Host.
 5. As the operator, I want Pi's analytics disabled in that same pinned configuration, so that Pi never attempts the one runtime write it would otherwise make to the frozen settings file.
 6. As the operator, I want Pi to authenticate by reusing my existing Claude subscription rather than a separate API key, so that the comparison hits the same account at zero marginal cost.
 7. As the operator, I want Pi's credential left unmanaged by the flake, so that no secret is committed to a public repo and my authentication survives rebuilds.
 8. As the operator, I want Pi installed with no agent context, no skills, and no extensions, so that I see Pi's native behaviour rather than a port of the Claude Code setup.
 9. As the operator, I want Pi to keep full ownership of its writable state directory, so that its self-modifying behaviour — generated extensions, skills, prompt templates, installed packages, sessions — works unimpeded.
 10. As the operator, I want Pi sourced from the base package set and bumped with the normal flake update, so that it stays reasonably fresh without a second package set evaluated for one tool.
 11. As the operator, I want the Module laid out as a directory rather than a single file, so that promoting Pi later — adding rendered skills or extensions — is an additive change rather than a restructure.
 12. As the operator, I want backing Pi out to be a single `enable` flip, so that an experiment that does not pan out leaves no residue.
 ## Implementation Decisions
 **pi Module**
 - A new Module under its own directory, following the shape of the existing `claude-code` Module, declaring a single `enable` option under the `modules` tree and guarding its body with the Enable convention.
 - The directory layout (rather than a single file) is chosen so that later rendering of a skills or extensions source is an additive edit, not a move.
 - On enable, the Module turns on the home-manager `programs.pi-coding-agent` module for the primary user. That upstream module ships the `pi-coding-agent` package (base package set) and manages the state directory's declared files.
 - The Module freezes exactly one file through that upstream module's `settings` option: the default provider set to Anthropic, the default model set to Opus (the exact model-id string confirmed against Pi's own model catalogue at build time), and analytics disabled.
 - No other upstream option is set: `context`, `models`, `keybindings`, `extraPackages`, and `configDir` are all left at their defaults, so home-manager renders nothing but `settings.json` into `~/.pi/agent/` and Pi owns every other path there.
 - Rationale for the single frozen file: among the files the upstream module can render, `settings.json` is the only one Pi writes at runtime, and only its analytics keys — disabling analytics removes even that, so freezing it is safe and never fights Pi's self-modification, which targets other paths entirely.
 - Credentials are out of the flake by design. Pi reuses the Claude subscription via its own login, and the resulting token lives under Pi's state directory, which home-manager does not overwrite — mirroring the `claude-code` Module's treatment of its login.
 - Security posture is inherited, not added: the `claude-code` Module already widens the sudo credential cache system-wide for the primary user, so Pi's `bash` tool can spend a warm credential. Pi does not pass through Claude Code's cold-cache sudo guard, and no equivalent guard is added for Pi in this deliverable. This is an accepted, bounded posture for a supervised single-user experiment.
 **neogaia Host**
 - The `neogaia` Host enables the new Module with a single `enable = true`, alongside its existing feature list.
 - No other Host is touched; the desktop and servers do not yet exist in the flake and would each opt in on their own terms.
 ## Testing Decisions
 - A good test here asserts externally-observable evaluation and build success of the whole `neogaia` Host, not the internals of the Module. Installing a Module is config authoring, and the meaningful unit is the Host it composes into.
 - **Primary seam (required, reused):** the `neogaia` Host evaluates and its system toplevel builds via `nix flake check` (the `checks.x86_64-linux.neogaia` target). Building the toplevel drives the Auto-loader discovering the new Module, the `programs.pi-coding-agent` home-manager integration resolving, the frozen `settings.json` rendering, and every enabled Module's config merging without conflict.
 - No new seam is introduced. This is the single high seam that `laptop-mvi.md` established and that every Module in this repo is verified through; an install-a-Module feature does not justify a second one.
 - No unit-level test of the Module in isolation. The config-merge model makes the whole-Host build the highest and most meaningful seam.
 - Prior art: the existing `claude-code`, `gitea-axi`, `fish`, `tmux`, and `nvim` Modules are all verified this way — enabled on `neogaia`, exercised by the toplevel build.
 - The genuine end-to-end confirmation — launching `pi`, authenticating against the Claude subscription, and running the agent — is a manual post-build action on the real machine and is not automated, consistent with how interactive login is handled for Claude Code.
 ## Out of Scope
 - Any harvest/promote pipeline for sharing Pi's self-modifications across machines — rendering a repo-held skills or extensions source into Pi's state directory. Deferred until Pi earns a permanent slot.
 - A shared skill source between Pi and Claude Code for a fairer comparison, exploiting their common `SKILL.md` skill format.
 - A Pi-specific sudo guard (or any tool-permission guard) built as a Pi extension.
 - An `AGENTS.md` context carrying the operator's cross-agent house rules (commit conventions, no attribution trailer, markdown and filename rules). Its absence means Pi's commits will not automatically follow those conventions during the experiment; this is accepted.
 - Custom model providers (`models.json`), custom keybindings, and any non-Anthropic provider.
 - Moving Pi to the `unstable` overlay for head-of-channel freshness.
 - Wiring the credential through a secret store; sops is not yet wired on this Host, and Pi follows the same unmanaged-credential path as Claude Code until it is.
 - Enabling Pi on any Host other than `neogaia`.
 - An ADR recording the "promote agent self-modifications into the flake rather than sync mutable agent state" stance. It is not enacted by this deliverable; if Pi is promoted and the harvest pipeline is built, that becomes a real, repo-wide decision — covering Claude Code too — worth recording then.
 ## Further Notes
 - **Why the single frozen file matters:** Pi's real self-modification surface (generated extensions, skills, prompt templates, installed package code, sessions, trust decisions) lives in paths under `~/.pi/agent/` that the upstream home-manager module never manages, regardless of what the Module declares. Freezing `settings.json` therefore constrains none of it, and disabling analytics removes the only runtime write that file would otherwise receive.
 - **Promotion path is left open by construction:** the directory-shaped Module and the untouched `configDir` mean that, if Pi sticks, a repo-held skills or extensions source can be rendered into the state directory with a writable-directory / read-only-leaf layout — the same mechanism this repo already uses for Claude Code skills — without restructuring anything decided here.
 - **Fair-comparison intent:** matching the model (Opus) and the account (the Claude subscription) is deliberate, so the experiment isolates the harness. Choosing a lighter model or a separate key would introduce a second variable and blur the read.
 - **Reversibility:** because only `settings.json` is frozen and the credential and all self-modification state live outside the flake, disabling the Module removes Pi cleanly, leaving Pi's own state directory as the only residue on disk.
--- a/.claude/spec/sops-secrets.md
+++ b/.claude/spec/sops-secrets.md
@@ -1,148 +0,0 @@
 ## Problem Statement
 `neogaia` is up and running the NixOS it builds, but its login password was set by hand through `nixos-enter` during the install and lives only on that laptop's disk.
 It is the one piece of the machine that is not declared, not reproducible, and not recoverable — a reimage loses it, and no other `Host` can inherit it.
 The same gap blocks everything queued behind it.
 An Anthropic API key cannot be provisioned declaratively, a WireGuard key cannot be committed, and the three planned servers cannot carry service credentials.
 The repo is public and mirrored to GitHub, so none of that material can be committed in plaintext.
 There is a second, subtler cost.
 SSH host keys are currently generated fresh by `sshd` on each install, so reimaging any machine invalidates its host identity and breaks `known_hosts` for every client that ever connected to it.
 `ADR 0001` chose `sops-nix` for this, but its stated mechanism — age keys derived from each `Host`'s SSH host key — turns out to be the wrong topology, and its consequences no longer describe what should be built.
 ## Solution
 Wire `sops-nix` into the `Skeleton` as unconditional plumbing, with a two-tier age identity model.
 An **admin identity** stored outside the repo entirely, in Proton Pass, is a recipient of every secrets file.
 It is the durable recovery path: it outlives every machine, is reachable from any device including a live ISO, and is the credential that authorizes adding a new `Host` as a recipient.
 A **host identity** — a dedicated age key on each machine's encrypted root — is a recipient of only that machine's own secrets plus the shared file.
 It is generated on the machine, never leaves it, and is deliberately not derived from the SSH host key, which is what frees the SSH host keys to become secrets in their own right.
 Secrets are `sops`-encrypted into this same public repo.
 The ciphertext is safe to publish, and the only artifact that would not be — the admin private identity — is never committed at all.
 No second repository is introduced.
 The first pass moves the login password off its hand-set value and makes `neogaia`'s SSH host keys stable across reimages.
 That exercises both decryption paths — the early one that runs before user creation, and the ordinary activation one — proving the machinery end to end on the two secrets that are actually needed today.
 ## User Stories
 1. As the operator, I want my login password declared as an encrypted secret rather than typed into a running machine, so that it is reproducible and survives a reimage like everything else in the flake.
 2. As the operator, I want secrets encrypted into the existing public repo rather than a separate private one, so that there is one repository to clone and no bootstrap credential is needed to reach my own configuration during an install.
 3. As the operator, I want an admin identity held in my password manager and never committed, so that nothing brute-forceable is published and I can recover every machine from a device I have never used before.
 4. As the operator, I want each `Host` to hold its own age identity, so that a compromised server cannot decrypt my laptop's secrets.
 5. As the operator, I want a shared secrets file alongside per-`Host` ones, so that material common to every machine is stored once rather than duplicated five times.
 6. As the operator, I want my workstation to be a recipient of only its own secrets, so that the admin identity stays a break-glass credential rather than something sitting unlocked on a laptop.
 7. As the operator, I want `neogaia`'s SSH host keys stored as secrets and restored at activation, so that reimaging the laptop does not invalidate its host identity or break `known_hosts` for clients.
 8. As the operator, I want the secrets machinery to live in the `Skeleton` rather than behind an `enable` flag, so that it reads as plumbing every `Host` depends on rather than an optional feature.
 9. As the operator, I want individual secrets declared next to the configuration that consumes them, so that a reader finds the secret where they find its use.
 10. As the operator, I want a mistyped secret name or a missing secrets file to fail the build, so that errors surface at `nix flake check` rather than at boot.
 11. As the operator, I want the procedure for provisioning a new `Host`'s identity written down, so that installing the desktop and the servers does not require rederiving the key ceremony under pressure.
 12. As the operator, I want the recovery path documented for a machine whose identity was provisioned wrongly, so that a failed first boot is a known procedure rather than an improvised one.
 13. As the operator, I want the editing workflow documented, so that I know which secrets I can change from my laptop and which require unlocking the admin identity.
 ## Implementation Decisions
 **Identity topology**
 - Two tiers of recipient: one admin identity, plus one identity per `Host`.
  Every secrets file is encrypted to admin and to whichever `Host`s legitimately read it.
 - The admin identity is stored as a secure note in Proton Pass and is never committed in any form.
  Only its public recipient appears in the repo.
  No passphrase-encrypted copy is committed: the vault already provides passphrase protection with rate limiting, whereas a committed copy would be offline-brute-forceable by anyone who clones the repo, indefinitely.
 - Each `Host` identity is a dedicated age key on the LUKS-encrypted root, generated on that machine and never transmitted.
  It is *not* derived from the SSH host key.
  Decoupling them is what allows the SSH host keys to be secrets themselves; deriving one from the other would be circular.
 - An admin recipient on every file is structurally required, not a convenience.
  A file readable only by its own `Host` becomes permanently unrecoverable the moment that machine is wiped, and adding any new recipient must be done by someone who can already decrypt.
 **Repository layout**
 - One repository, public, unchanged.
  A private repository was considered and rejected: cloning it requires credentials that would themselves become bootstrap material at install time, reintroducing the hand-carried secret the design otherwise eliminates, in exchange for protecting content that is already safe to publish.
 - A `sops` configuration file and a secrets directory at the repo root.
 - One secrets file per `Host`, encrypted to admin plus that `Host`.
 - One shared secrets file encrypted to admin plus every `Host`.
 - `neogaia` is a recipient of its own file and the shared file only.
  Editing another machine's secrets requires unlocking the admin identity for that session, which is the intended friction.
 **Secrets in this pass**
 - The primary user's password hash lives in the shared file, consumed through `hashedPasswordFile`.
  It is marked as needed for users, which makes `sops-nix` decrypt it in an earlier activation stage than ordinary secrets, before accounts are created.
  This is the one ordering subtlety in the design and is the reason the `Host` identity must sit on the root filesystem rather than anywhere later-mounted.
 - Storing the password hash in the shared file rather than per-`Host` is deliberate.
  The same password will be used on every machine, so duplicating the identical hash across per-`Host` files would not reduce what an attacker learns — it would only make rotation a five-file edit.
 - `neogaia`'s SSH host **private** keys live in its own `Host` file, with `sshd`'s generated host keys disabled and pointed at the decrypted paths instead.
 - SSH host **public** keys are committed in plaintext.
  They are not secret — publishing them is their function — and encrypting them would impose a re-key cycle every time one changes.
 **Placement in the flake**
 - The machinery goes in the `Skeleton` as unconditional configuration, not behind an `enable` flag.
  This is a deliberate departure from the `Enable convention`, on the same grounds as the overlays and the flakes settings: every `Host` will carry secrets, so the flag would be permanently `true`, and the plumbing is not a feature a `Host` chooses.
 - The `Skeleton` carries only the machinery — the flake input, the identity file location, and the default secrets file.
  Individual secrets are declared wherever they are consumed, so the password secret sits beside the user declaration it feeds and the SSH host keys beside the `sshd` configuration.
 - `sops-nix` is added as a flake input following the base `nixpkgs`.
 **Operational procedures**
 - For `neogaia`, which is already installed and running, provisioning happens live: generate the identity on the machine, add its recipient, re-key the affected files with the admin identity, rebuild.
  No reimage and no live ISO are involved.
 - For a `Host` that does not yet exist, provisioning happens on the live ISO *before* the install: generate the identity, add its recipient, re-key, write the identity onto the target root, then install.
  The first boot then has everything it needs and cannot fail for want of a key.
  The install already builds from a local clone, so no push is required mid-procedure; the recipient change is committed afterward.
 - Both procedures, the editing workflow, and the live-ISO recovery path are documented in the existing install document rather than a new one.
 **Decision record**
 - A new ADR supersedes `ADR 0001`, which is marked superseded.
  `ADR 0001`'s choice of `sops-nix` over `agenix` still holds and carries forward in a sentence, but its key-derivation mechanism is replaced and its stated consequence — that each new `Host` registers its SSH host public key as a recipient — is inverted, since SSH host keys are now secrets rather than the root of trust.
 ## Testing Decisions
 - A good test here asserts externally-observable build and activation behaviour, not the internals of `sops-nix`.
  Nothing in this feature is our own logic to unit-test; it is configuration wiring, and the meaningful assertions are that the whole `Host` still evaluates and that the secrets actually materialize on a real machine.
 - **Primary seam (required):** `nix flake check` building the `neogaia` system toplevel, the same seam the laptop MVI established.
  It carries real weight for this feature rather than merely compiling: `sops-nix` validates secrets files at evaluation time by default, so a missing file, a file that is not valid `sops` output, or a declared secret whose key is absent from it all fail the build.
  Mistyped secret names surface here rather than at boot.
 - **Confirmation (manual):** a real activation on `neogaia`.
  This is what proves decryption itself — that the `Host` identity is readable at the right stage, that secrets appear with the declared ownership and mode, that `sshd` adopts the restored host keys, and that login works against `hashedPasswordFile`.
  It cannot be automated without a machine that holds a real identity, and is treated like the reimage in the laptop MVI: manual by nature.
 - No new seams are introduced.
  The existing whole-`Host` build remains the highest available point, and the config-merge model makes it the meaningful unit.
 - Prior art: the toplevel-build check established by the laptop MVI, already wired as the flake's `checks` output.
 ## Out of Scope
 - The Anthropic API key.
  It is the natural next secret, but it is consumed as an environment variable rather than a file path, and conflating that shape with the bootstrap work would obscure both.
 - The WireGuard/ProtonVPN key, which has no `Module` to consume it yet.
 - Declarative wifi credentials.
  NetworkManager profile secrets are fiddly and joining from the console currently works.
 - Fleet-wide SSH host verification.
  With one `Host` there is nothing to verify against, and the choice of whether to identify machines by name or address should be made when a second machine exists and the answer is known rather than guessed.
 - Provisioning any identity for a `Host` that does not exist yet.
  The procedure is documented; no key is generated for `zeus` or the servers.
 - Rotating the LUKS passphrase or coupling it to secret decryption.
 - Hardware-token identities.
  A YubiKey can be added later as an additional admin recipient without changing any decision here.
 - Any change to how the flake is fetched during an install.
 ## Further Notes
 - **The lockout risk is confined to fresh installs.**
  On `neogaia` the transition is safe: if activation fails, the rebuild fails and the running generation persists with the existing hand-set password intact.
  A machine being installed for the first time has no such fallback, because the password now arrives only from a decrypted secret — which is exactly why its identity is provisioned before the first boot rather than after it.
 - **The admin identity is the single point of recovery**, and its durability is now a property of Proton Pass rather than of any machine or repository.
  Losing the vault without a backup means losing the ability to add recipients or recover a wiped `Host`, even though every currently-running machine keeps working from its own identity.
 - **Stable SSH host keys were nearly given up** in favour of deriving identities from them, and were recovered by inverting the dependency.
  The rule that made it work generalizes: exactly one secret per machine must arrive out of band, and making that one thing a purpose-built key rather than a repurposed one keeps everything else declarable.
 - **Adding a `Host` is a re-key, not a re-encrypt.**
  A `sops` file holds a single data key encrypted once per recipient, so registering a new machine rewrites only that metadata, and the cost stays constant as the fleet grows to five.
 - **This is what `ADR 0001` chose `sops-nix` for.**
  The shared-plus-per-`Host` file split with overlapping recipients is precisely the multi-recipient, grouped-file model that decided against `agenix`; the topology change replaces how identities are obtained, not why the tool was picked.
--- a/.claude/tasks/0001-skeleton-and-building-host.md
+++ b/.claude/tasks/0001-skeleton-and-building-host.md
@@ -1,37 +0,0 @@
 ---
 spec: laptop-mvi
 ---
 ## What to build
 Stand up the `Skeleton` and a minimal `neogaia` `Host` that evaluates and whose system toplevel builds — the walking skeleton every later slice extends and re-verifies against.
 The `Skeleton` is a hand-rolled flake (no flake-parts): `nixos-unstable` base channel, an `unstable overlay` exposing `nixpkgs-unstable` as `unstable.<name>`, a `stable overlay` exposing `nixos-26.05` as `stable.<name>`, and chaotic-nyx wired as an input with its overlay and binary cache.
 The helper lib is trimmed to three pieces: the `Auto-loader` (recursively discovers and imports every `Module` under `modules/` and every `Host` under `hosts/` with no null-placeholder traversal hack), the host-builder, and the script-from-file helper.
 `with lib.my` is not used — dependencies are `inherit`ed explicitly.
 The `Enable convention` uses the stdlib enable-option helper; every `Module` is imported unconditionally and guards its body with `mkIf config.modules.<path>.enable`.
 home-manager is sourced from `nix-community` (master, nixpkgs followed) and integrated as a NixOS module with global packages and user packages.
 The `user` is an explicit option defaulting to `alexion` (no impure environment lookup), placed in `wheel`, driving the system user and the home-manager user in lockstep.
 The `neogaia` `Host` carries only enough (placeholder `hardware-configuration.nix`, filesystems/bootloader stubs, `stateVersion`) to make `nixosConfigurations.neogaia.config.system.build.toplevel` evaluate and build; real disk/kernel/networking arrive in later slices.
 Design the per-`Host` layout so disk layout, kernel, and channel are all per-`Host` concerns from the start (story 20), so the desktop and servers extend this foundation without restructuring.
 ## Acceptance criteria
 - [x] `nix flake check` succeeds and the flake exposes `nixosConfigurations.neogaia`.
 - [x] `nixosConfigurations.neogaia.config.system.build.toplevel` builds.
 - [x] Adding a new `.nix` file under `modules/` is auto-discovered and imported without editing any `imports` list, and stays inert until its `enable` flag is set.
 - [x] All three overlays resolve: `unstable.<pkg>`, `stable.<pkg>`, and a chaotic-nyx package are each reachable in a `Host`.
 - [x] home-manager builds as part of the same `nixos-rebuild switch` toplevel (system + user environment atomic).
 - [x] The `user` option defaults to `alexion`, has no impure environment lookup, places the user in `wheel`, and drives both the system and home-manager user.
 - [x] The old `nixosModules` flake output and the `with lib.my` idiom are absent.
 ## Implementation Notes
 - **Verification.** `nix flake check` builds `checks.x86_64-linux.neogaia` = the Host toplevel (the spec's primary seam). Overlays confirmed via `nix eval` of `pkgs.unstable.hello` (2.12.3), `pkgs.stable.hello` (2.12.1), and `pkgs.linuxPackages_cachyos.kernel` (7.1.3, from chaotic). Auto-loader inertness confirmed both ways: the reference `modules/example.nix` is off by default, and `extendModules` with `modules.example.enable = true` activates its body.
 - **chaotic binary cache.** Wired via `inputs.chaotic.nixosModules.default`, which puts both the `nyx-cache.chaotic.cx` substituter and its trusted public key into the built config (verified by evaluating `config.nix.settings.substituters`/`trusted-public-keys`). chaotic deliberately does **not** follow our nixpkgs, so the cache stays usable. Making the substituter/key explicit is task 0003's concern; here it is inherited from the module.
 - **Shared base lives in `system/`.** The Skeleton's shared base config (overlays, `user`, flakes, home-manager wiring) is a `system/` module always imported by the host-builder, kept separate from the auto-loaded feature `Module`s under `modules/` so the base is never gated by an `enable` flag.
 - **`modules/example.nix` kept intentionally.** It is the Auto-loader / Enable-convention reference every real Module copies; remove it once a real Module supersedes its teaching value.
 - **`scriptFromFile` present but unused.** The task mandates the helper lib carry it ("the script-from-file helper"); its first caller lands with a later Module.
 - **Home-manager base user only.** The base sets `home.username`/`homeDirectory`/`stateVersion` for the `user`; `extraSpecialArgs` passes both `inputs` and `my` (the flake lib) so upcoming HM Modules (fish/tmux/nvim) can reach `scriptFromFile`.
 - **Deviations from plan.** Added an `options.user.description` (GECOS) alongside `user.name` — small and expected for a real account. Baseline `git` + global `allowUnfree` are set in the base (git is required for flakes; unfree is needed by chaotic/home-manager and later Claude Code). Placeholder `fileSystems`/bootloader and `hardware-configuration.nix` in `neogaia` are stubs that task 0002 (disko) replaces.
--- a/.claude/tasks/0002-neogaia-disk-and-boot.md
+++ b/.claude/tasks/0002-neogaia-disk-and-boot.md
@@ -1,31 +0,0 @@
 ---
 spec: laptop-mvi
 blocked-by: 0001-skeleton-and-building-host
 ---
 ## What to build
 Declare the `neogaia` laptop's disk with `disko` and make it unlock and boot on real hardware: a LUKS-encrypted btrfs volume with subvolumes plus zram swap, on an EFI system partition using systemd-boot, with the LUKS passphrase prompted at boot via the initrd.
 The layout must build from the same tree as the `Host` toplevel (so the whole-`Host` build exercises it), and must be expressed as a per-`Host` disk concern so other machines can declare their own layouts later.
 ## Acceptance criteria
 - [x] `neogaia` declares a `disko` layout: LUKS-encrypted btrfs with subvolumes plus zram swap on an EFI system partition.
 - [x] systemd-boot is the bootloader; the initrd prompts for the LUKS passphrase so a normal boot unlocks the encrypted disk.
 - [x] The `disko` layout builds as part of the `neogaia` toplevel build (no separate invocation needed to catch layout errors).
 - [x] The disk layout is a per-`Host` concern, expressible differently for future `Host`s without restructuring the `Skeleton`.
 ## Implementation Notes
 - **Layout.** One GPT disk at `/dev/nvme0n1`: a 512M EF00 ESP (vfat, `umask=0077`) mounted at `/boot`, and a 100%-fill LUKS partition (`cryptroot`, `allowDiscards`) holding a btrfs filesystem with three subvolumes — `@root` → `/`, `@home` → `/home`, `@nix` → `/nix` — each mounted `compress=zstd,noatime`.
  There is deliberately no on-disk swap partition; swap is RAM-backed zram.
 - **Skeleton vs. per-Host split.** The disko *module* (`inputs.disko.nixosModules.disko`) is wired into the host-builder in `lib/default.nix`, so every `Host` can interpret a `disko.devices` declaration; the *layout itself* lives in `hosts/neogaia/disk.nix`.
  A future `Host` declares a different layout, or none at all (an undeclared `disko.devices` is a no-op), so servers that preserve an existing pool by import need no `Skeleton` change.
 - **disko input follows nixpkgs.** Unlike chaotic (which must not), disko follows our `nixpkgs` so it builds against the same base.
 - **Boot unlock.** disko's `type = "luks"` (no key file) generates `boot.initrd.luks.devices.cryptroot`, so the classic initrd prompts for the passphrase on a normal boot; the `nvme` initrd module was already present in `hardware-configuration.nix`.
 - **zram enabled directly, not yet a Module.** Criterion 1 requires "plus zram swap," so `zramSwap.enable = true` is set on the `Host` now.
  Task 0003 owns the reusable zram toggle `Module` and will lift this line into it; the placeholder `fileSystems`/bootloader stubs from task 0001 are removed here since disko now derives `fileSystems`.
 - **Verification.** `nix flake check` (the `checks.x86_64-linux.neogaia` toplevel) builds green.
  Confirmed via `nix eval`: disko-derived `fileSystems` = `/`,`/home`,`/nix` on btrfs `/dev/mapper/cryptroot` + `/boot` on the ESP; `boot.initrd.luks.devices` = `["cryptroot"]`; `systemd-boot.enable` and `zramSwap.enable` both true; `swapDevices` empty.
  The genuine end-to-end confirmation is the manual `disko-install` reimage, which is irreversible by nature and not automated.
--- a/.claude/tasks/0003-kernel-and-hardware.md
+++ b/.claude/tasks/0003-kernel-and-hardware.md
@@ -1,26 +0,0 @@
 ---
 spec: laptop-mvi
 blocked-by: 0001-skeleton-and-building-host
 ---
 ## What to build
 Give `neogaia` the kernel and hardware enablement it needs to run well on the Dell XPS 13 9380: the CachyOS kernel pulled as a binary from chaotic-nyx (not compiled from source), Intel microcode, and the redistributable firmware for the QCA6174 wifi. Add a zram toggle `Module` and enable it here.
 The kernel is selected through a small per-`Host` kernel mechanism so other `Host`s can choose different kernels. The chaotic substituter and its trusted public key are added to the Nix settings so the kernel is fetched from the binary cache from the first build.
 ## Acceptance criteria
 - [x] `neogaia` runs the CachyOS kernel selected via a per-`Host` kernel mechanism, sourced from chaotic-nyx.
 - [x] The chaotic substituter and trusted public key are in the Nix settings, so the kernel is fetched from cache rather than compiled.
 - [x] Intel microcode is enabled.
 - [x] Redistributable firmware is enabled so the QCA6174 wifi hardware is available.
 - [-] A zram toggle `Module` exists (following the `Enable convention`) and is enabled on `neogaia`. — Module dropped in PR review; zram is enabled inline on `neogaia` instead (see notes).
 - [x] The `neogaia` toplevel still builds with all of the above.
 ## Implementation Notes
 - **Per-`Host` kernel mechanism = native `boot.kernelPackages`.** neogaia sets `boot.kernelPackages = pkgs.linuxPackages_cachyos` directly in its Host directory (`hosts/neogaia/default.nix`). No custom wrapper option was added: `boot.kernelPackages` is already a per-`Host` setting, so other `Host`s pick their own kernel the same way. A string→package wrapper would have been premature abstraction with one `Host` and one kernel, so it was deliberately left out; the "mechanism" is the per-`Host` placement of the native option.
 - **Substituter/key live in the shared base, via the `extra-` options.** They were added to `system/default.nix` (shared by every `Host`), not just neogaia, because the chaotic module is wired for all `Host`s and the cache is general plumbing. `nix.settings.extra-substituters` / `extra-trusted-public-keys` are used rather than the replacing `substituters` / `trusted-public-keys`, so `cache.nixos.org` (and any other substituter) is only appended to, never dropped. chaotic's own module also provides these entries; the explicit declaration is belt-and-suspenders and keeps the built system's cache config visible and independent of that module.
 - **Dev-host build needed a daemon-level cache.** Building the toplevel here first compiled the CachyOS kernel (and rustc bootstrap) from source, because the build daemon's `/etc/nix/nix.conf` had no `nyx-cache` substituter — the built system's `nix.settings` do not govern the daemon doing the build, and the dev user is a non-trusted client that cannot add substituters from the CLI. Adding `extra-substituters`/`extra-trusted-public-keys` for `nyx-cache` to `/etc/nix/nix.conf` (sudo) and restarting `nix-daemon` fixed it; the build then fetched the kernel (7.1.3) from the cache. Recorded as a gotcha in `CLAUDE.md`.
 - **zram is enabled inline, not as a `Module` (criterion 5 dropped).** The task asked for a zram toggle `Module`, and one was built first (`modules/zram.nix`), but PR review rejected it as a single-line abstraction that wraps the native `zramSwap.enable` toggle without adding anything. It was removed, and `neogaia` sets `zramSwap.enable = true` directly, as it did before task 0003. The `Enable convention` reference remains `modules/example.nix`; real feature `Module`s arrive with fish/tmux/nvim/Claude Code in later tasks.
--- a/.claude/tasks/0004-networking-and-base-system.md
+++ b/.claude/tasks/0004-networking-and-base-system.md
@@ -1,28 +0,0 @@
 ---
 spec: laptop-mvi
 blocked-by: 0001-skeleton-and-building-host
 ---
 ## What to build
 Make the booted laptop a usable console I can log into and reach remotely: NetworkManager for joining wifi, an SSH daemon for driving the rest of the setup over the network, and the base locale settings.
 Set timezone `America/New_York`, locale `en_GB.UTF-8`, and console keymap `us`.
 ## Acceptance criteria
 - [x] NetworkManager is enabled so wifi can be joined from the console.
 - [x] An SSH daemon is enabled so the machine can be driven remotely.
 - [x] Timezone is `America/New_York`, locale is `en_GB.UTF-8`, console keymap is `us`.
 - [x] The `neogaia` toplevel still builds with all of the above.
 ## Implementation Notes
 - **Placement in the Host, not a Module.** NetworkManager, the SSH daemon, and the locale/timezone/keymap settings all live directly in `hosts/neogaia/default.nix`, alongside the kernel/hardware/zram lines from task 0003.
  This follows the precedent set in that task, where a speculative enable-gated Module was dropped in review in favour of inlining for the single-Host MVI.
  A shared locale Module or a networking Module can be extracted later when a second Host actually needs the same settings; extracting now would be speculative generality.
 - **SSH left unhardened deliberately.** `services.openssh.enable = true` keeps NixOS's default password authentication on.
  This is required by the install flow: first-boot access is over SSH with the hand-set bootstrap password, and no SSH keys or sops-derived age key exist until the install generates the Host's SSH host key.
  Moving to key-only auth / `hashedPasswordFile` is the first post-boot follow-up per the spec's Secrets section, out of scope for the MVI.
 - **Locale/timezone mix is as specified.** `i18n.defaultLocale = "en_GB.UTF-8"` with `time.timeZone = "America/New_York"` and `console.keyMap = "us"` mixes region and locale; this matches the operator's stated preferences verbatim and is intentional.
 - **Verification.** Built the primary seam — `nix build .#checks.x86_64-linux.neogaia` (the Host toplevel) — to exit 0; the systemd units for `wpa_supplicant` (NetworkManager's backend) and openssh appear in the build. The five option values were also confirmed via `nix eval`.
--- a/.claude/tasks/0005-fish-shell-module.md
+++ b/.claude/tasks/0005-fish-shell-module.md
@@ -1,44 +0,0 @@
 ---
 spec: laptop-mvi
 blocked-by: 0001-skeleton-and-building-host
 ---
 ## What to build
 A fish `Module`, configured natively via home-manager, that makes the shell feel like the current CachyOS setup but is correct for NixOS. Translate the existing `cachyos-config.fish` and the rest of the fish snapshot under `reference/home/.config/fish/`: the greeting, the bat-manpager, the `done` and bang-bang plugins, the helper functions, and the eza/nav aliases. Drop or replace every Arch/pacman-specific part with its NixOS equivalent. Set fish as the default login shell.
 Configure the plugins natively through home-manager rather than a fish plugin manager.
 ## Acceptance criteria
 - [x] A fish `Module` (following the `Enable convention`) is enabled on `neogaia` and configured natively via home-manager.
 - [x] The greeting, bat-manpager, `done` and bang-bang plugins, helper functions, and eza/nav aliases from the reference config are reproduced.
 - [x] All Arch/pacman-specific parts are dropped or replaced with NixOS equivalents.
 - [x] fish is the user's default login shell.
 - [x] The `neogaia` toplevel still builds with the fish `Module` enabled.
 ## Implementation Notes
 - **Plugins are native, not inlined.** `done` and `bang-bang` come from `pkgs.fishPlugins.*` via `programs.fish.plugins`; home-manager drops them into `~/.config/fish/conf.d/` where fish auto-sources them.
  The reference config inlined the bang-bang `__history_previous_command` functions and binds by hand; the plugin supplies those, so they are not re-inlined.
 - **`done` tuning uses `set -g`, not `set -U`.** The reference set `__done_min_cmd_duration`/`__done_notification_urgency_level` as universal variables, which persist to the universal-variable file and then ignore config changes.
  A declarative config must own these each session, so they are set global (`set -g`) in `interactiveShellInit`.
 - **Arch/pacman aliases dropped:** `grubup`, `fixpacman`, `mirror` (`cachyos-rate-mirrors`), `apt`/`apt-get` (`man pacman`), `big` (`expac`), `gitpkg`, `rip` (`expac`).
  **Replaced with NixOS equivalents:** `update` → `sudo nixos-rebuild switch` (was `pacman -Syu`), `cleanup` → `sudo nix-collect-garbage -d` (was `pacman -Rns`).
 - **Machine-specific PATH hacks dropped, per spec story 6 ("no impure environment lookup").** The hardcoded `BUN_INSTALL`, the `node-v24...` tarball path, and `~/Applications/depot_tools` from `config.fish` are absolute/impure and are not reproduced; such tooling should be Nix-provided when its own Module arrives.
  The portable bits are kept: `~/.local/bin` on PATH (guarded) and sourcing `~/.fish_profile`.
 - **`env.fish` and `rustup.fish` deliberately not carried over.** `ANDROID_HOME`/platform-tools (Android SDK) and `source ~/.cargo/env.fish` (rust) are dev-toolchain integrations outside the MVI's core tooling (fish/tmux/nvim/Claude Code); they belong to future per-toolchain Modules that provide those tools through Nix rather than sourcing an impure env file.
 - **`hw` (`hwinfo --short`) and `tb` (`nc termbin.com 9999`) dropped.** These are generic rather than pacman-specific, but each needs an extra package (`hwinfo`, a `netcat`) that the minimal install does not otherwise pull in; left out of the MVI and easy to add later.
 - **`copy` kept verbatim** (including the upstream `trim-right` call) to preserve exact parity with the current shell.
 - **Verification.** The `neogaia` system toplevel builds (the spec's primary seam).
  The rendered `~/.config/fish/` was inspected in the build output: aliases, the three helper functions, the `fastfetch` greeting, the bat manpager, the `done` tuning vars, and the `conf.d/plugin-done.fish` + `conf.d/plugin-bang-bang.fish` plugin files are all present; `users.users.alexion.shell` resolves to `pkgs.fish`.
 ### Post-review adjustments
 - **`defaultShell` option.** Setting fish as the login shell moved behind `modules.fish.defaultShell` (default `false`, gated with `mkIf`); `neogaia` opts in explicitly. Enabling the Module alone no longer changes the login shell.
 - **Abbreviation-first.** Every non-eza alias is now a `shellAbbr` (the eza `ls` family stays an alias), `preferAbbrs = true`, and `generateCompletions = true` is pinned rather than left to the upstream default.
 - **vi command-line editing.** `interactiveShellInit` sets `fish_key_bindings fish_vi_key_bindings`; the `bang-bang` plugin re-binds `!`/`$` in insert mode via its own `--on-variable fish_key_bindings` handler, so the switch keeps them working.
 - **Trimmed aliases.** Navigation capped at four dots (`.....`/`......` dropped); `psmem`, `psmem10`, `dir`, `vdir`, and `please` removed.
 - **Interactive init lives in a real fish file.** The Module lives at `modules/fish/fish.nix`; its `interactiveShellInit` is `builtins.readFile ./config.fish`, so the interactive init is written as one editable fish file (vi editing, `EDITOR`/`VISUAL`, the bat manpager, the done plugin tuning, and `~/.local/bin`/`~/.fish_profile`) that home-manager renders into `~/.config/fish/config.fish`. The file is small enough that splitting it into fragments was not worth the indirection; Nix inlines it at build time, so nothing of ours is autoloaded from a separate runtime file.
 - **`copy` stays a function file.** `functions/copy.fish` holds the non-trivial `copy` body, read into the `functions` option; fish autoloads function files lazily, so that is the idiomatic home for a function. Trivial one-liner functions stay inline in `fish.nix`.
 - The Auto-loader only collects `.nix`, so every `.fish` file under `modules/fish/` is inert to it.
--- a/.claude/tasks/0006-tmux-module.md
+++ b/.claude/tasks/0006-tmux-module.md
@@ -1,43 +0,0 @@
 ---
 spec: laptop-mvi
 blocked-by: 0001-skeleton-and-building-host
 ---
 ## What to build
 A tmux `Module`, configured natively via home-manager, that reproduces the current terminal multiplexer exactly: the existing `tmux.conf` text (under `reference/home/.config/tmux/`) inlined verbatim, with no plugin manager needed.
 ## Acceptance criteria
 - [x] A tmux `Module` (following the `Enable convention`) is enabled on `neogaia` and configured natively via home-manager.
 - [x] The existing `tmux.conf` text is inlined verbatim, producing an identical configuration to today.
 - [x] No tmux plugin manager is used.
 - [x] The `neogaia` toplevel still builds with the tmux `Module` enabled.
 ## Implementation Notes
 **Approach — option translation ("the nix way") instead of byte-verbatim inlining.**
 On the operator's explicit call ("I would prefer to do things the nix way. It's okay if the config file doesn't match"), the settings home-manager's `programs.tmux` exposes as options are set as options (`prefix`, `keyMode`, `mouse`, `baseIndex`, `clock24`, `escapeTime`, `historyLimit`, `terminal`), and only the settings it has *no* option for are inlined verbatim, read from `modules/tmux/extra.conf` via `builtins.readFile`.
 The generated `~/.config/tmux/tmux.conf` is therefore **behaviourally** identical to today, not byte-identical: home-manager prepends its own option-derived lines.
 This was preferred over `xdg.configFile.source = ./tmux.conf` (which would have been byte-identical) after weighing both.
 Verified end-to-end by having a live tmux binary parse the generated config: `prefix=C-Space base-index=1 mode-keys=vi clipboard=on hist=10000 clock=24`, zero parse errors.
 **`clock24 = true` is required, not cosmetic.**
 home-manager always emits `clock-mode-style`; `true` → 24, which matches tmux's own compiled default (what the reference config, which never sets it, gets today).
 Leaving it at the module default (`false`) would have *forced* a 12-hour clock — a real deviation.
 **Pane navigation stays in `extra.conf`.**
 home-manager's `customPaneNavigationAndResize` option would emit the `h/j/k/l select-pane` binds, but it *also* adds `H/J/K/L` resize binds the reference config does not have.
 To stay faithful, the `h/j/k/l` binds are inlined in `extra.conf` and the option is left off.
 **`secureSocket` left at the home-manager default (`true`).**
 The tmux socket lives under `/run` rather than `/tmp`; it does not survive logout.
 This differs from stock tmux behaviour and was accepted deliberately.
 **Comments in `extra.conf` rewritten to the project convention.**
 The reference `tmux.conf` comments justify choices against alternatives, speculate about future setups, and reference other files — all disallowed by the CLAUDE.md comment convention.
 Since `extra.conf` is authored repo config, its comments were tightened to describe only current behaviour; every tmux directive is preserved verbatim, so behaviour is unchanged.
 **Version-sensitivity (not a defect today).**
 `programs.tmux.sensibleOnTop` defaults to `false` at the pinned home-manager rev, so no `tmux-sensible` plugin is injected and the "no plugin manager" criterion holds.
 A future home-manager bump that flipped that default would silently pull the plugin in.
--- a/.claude/tasks/0007-nvim-module.md
+++ b/.claude/tasks/0007-nvim-module.md
@@ -1,24 +0,0 @@
 ---
 spec: laptop-mvi
 blocked-by: 0001-skeleton-and-building-host
 ---
 ## What to build
 An nvim `Module` that gives the primary user Neovim configured declaratively through **nixvim**, with **functional parity** to the operator's existing config.
 Parity is about the "what" — the same plugins, keymaps, options, colorscheme, and behaviour — not the "how".
 The mechanism is deliberately free to follow NixOS's declarative paradigm rather than transplanting the imperative lazy.nvim setup: plugins are managed by Nix (no plugin manager, no runtime cloning, no lockfile), and as much of the config as possible is expressed as typed Nix, with raw Lua kept only as an escape hatch.
 ## Acceptance criteria
 - [x] An nvim `Module` (following the `Enable convention`) is enabled on `neogaia`.
 - [x] Neovim is configured via **nixvim**, wired as a flake input (`nixvim.inputs.nixpkgs.follows = "nixpkgs"`), consumed as its home-manager module under `home-manager.users.<user>.programs.nixvim`.
 - [x] Functional parity with the previous config: the same plugins (neogit, diffview, gitsigns, oil, snacks, gbprod-nord, render-markdown, which-key, treesitter), keymaps, `vim` options, the `nord` colorscheme, the Neogit blame-toggle autocmd, and markdown concealment — verified headless against the generated config.
 - [x] Runtime dependencies `git`, `ripgrep`, and `fd` are provided by Nix; `gcc` is not needed because Nix builds the treesitter grammars.
 - [x] The `neogaia` toplevel still builds with the nvim `Module` enabled.
 ## Implementation Notes
 - **nixvim, typed Nix first.** `modules/nvim/nvim.nix` enables `programs.nixvim` with `opts`, `globals`, `keymaps`, and typed `plugins.*` settings. Treesitter uses `plugins.treesitter` (`highlight.enable`, `indent.enable`, `grammarPackages` from the module's own `builtGrammars`) covering nix, lua, bash, fish, markdown, rust, python, java, kotlin, c, cpp, html, css, javascript, typescript, go.
 - **The imperative remainder** — the `gbprod/nord.nvim` setup + colorscheme call, the markdown `conceallevel` autocmd, and the Neogit blame-toggle `BufUnload` autocmd — lives in `modules/nvim/config.lua`, pulled in via `extraConfigLua = builtins.readFile ./config.lua`. `gbprod-nord` comes in through `extraPlugins` because nixvim's `colorschemes.nord` is a different plugin.
 - **Verification.** `nix build .#…programs.nixvim.build.package` exits 0 and the whole toplevel evaluates. The generated config was exercised headless (launched with `-u` the generated init and a scratch `HOME`, since the wrapper otherwise loads the dev host's real `~/.config/nvim`): all options, keymaps, plugins, the `nord` colorscheme, treesitter highlight + indent, and markdown conceal load with no errors.
--- a/.claude/tasks/0008-claude-code-module.md
+++ b/.claude/tasks/0008-claude-code-module.md
@@ -1,23 +0,0 @@
 ---
 spec: laptop-mvi
 blocked-by: 0001-skeleton-and-building-host
 ---
 ## What to build
 Install Claude Code declaratively on `neogaia`, and make it authenticatable without a browser on the laptop so it can be used over the console/SSH via the paste-code flow or an API key.
 ## Acceptance criteria
 - [x] Claude Code is installed declaratively (following the `Enable convention` if expressed as a `Module`) and enabled on `neogaia`.
 - [x] The browserless authentication path (paste-code flow or API key) is documented so it works over console/SSH.
 - [x] The `neogaia` toplevel still builds with Claude Code included.
 ## Implementation Notes
 - **Native home-manager module, not a raw package.** Claude Code is enabled through home-manager's own `programs.claude-code` module (`home-manager.users.<user>.programs.claude-code.enable = true`), mirroring how `tmux`/`fish` use their native home-manager options rather than dropping a package into `home.packages`. The module ships within home-manager itself, so — unlike `nvim`/nixvim — no new flake input is needed. Per the invocation's steer to prefer the tmux/nvim conventions over the task wording, the feature `Module` at `modules/claude-code/claude-code.nix` is kept as thin as the `tmux` module: just the `enable` option and the delegation.
 - **No settings written.** The module manages no `~/.claude` contents and writes no `settings.json`, so login and first-run configuration stay interactive. This keeps auth material (subscription token or API key) out of the repo.
 - **Auth docs co-located with the module.** The browserless authentication guide lives at `modules/claude-code/authentication.md`, next to the module, following the repo pattern where each module directory holds its own supporting files. It covers both the paste-code OAuth flow (open the printed URL on another device, paste the code back — works unchanged over SSH) and the `ANTHROPIC_API_KEY` path. This is distinct from task 0009's OS-install docs, which cover `disko-install`, not the CLI login.
 - **Verification.** `nix build .#checks.x86_64-linux.neogaia` (the primary Host seam) builds the toplevel with `claude-code-2.1.209` included; `config.modules.claude-code.enable` and the home-manager `programs.claude-code.enable` both evaluate `true`.
 - **Note on flake evaluation.** The new module file had to be `git add`ed before the flake could see it — flakes evaluate the git tree, so an untracked Module is invisible to the Auto-loader and the host errors with "option does not exist".
 - **Personal config ported into the Module (beyond the acceptance criteria).** At the operator's request the declarative half of `~/.claude` now lives in the Module and is applied when it is enabled: the global agent instructions (`context = ./CLAUDE.md`), the skills tree (`skills = ./skills`, 15 skills), the attention-bell hook (`hooks."attention-bell.sh"`), and `settings.json` (`model = "opus"` plus the Stop/Notification/SessionStart hook wiring). Runtime state (`projects/`, `plugins/`, `cache/`, `history.jsonl`, sessions) and the `~/.claude/.credentials.json` secret are deliberately left out, so login survives rebuilds and no secret enters the repo. Stale `agents`/`commands` symlinks (into an outdated `~/wrk/claude`) were skipped. Verified against the built `home-files`: `~/.claude/{CLAUDE.md,settings.json,skills/,hooks/attention-bell.sh}` are all generated, with the hook executable. The `gitea-axi` SessionStart hook depends on that binary being on `PATH`; the flake does not yet provide it, so the hook is a no-op on a host until it is installed.
--- a/.claude/tasks/0009-install-flow-docs.md
+++ b/.claude/tasks/0009-install-flow-docs.md
@@ -1,36 +0,0 @@
 ---
 spec: laptop-mvi
 blocked-by: [0002-neogaia-disk-and-boot, 0003-kernel-and-hardware, 0004-networking-and-base-system, 0005-fish-shell-module, 0006-tmux-module, 0007-nvim-module, 0008-claude-code-module]
 ---
 ## What to build
 Document the one-shot install procedure that turns the completed `neogaia` `Host` into a running encrypted laptop from the NixOS live ISO — the capstone, written once every functional slice is in place so it describes the actually-complete `Host`.
 The procedure: push the repo to Gitea first; from the live ISO, join wifi, clone the repo locally (avoiding self-signed-TLS/auth problems with flake fetching during install), and run `disko-install` against the `neogaia` `Host` with the chaotic substituter passed to the install-time Nix daemon (or it compiles the CachyOS kernel from source on the USB stick). Then set the bootstrap password by hand via `nixos-enter` — never committed to the public repo — and reboot.
 Note the bootstrap ordering (the flake must exist on Gitea before the install can consume it) and that moving the password to a `hashedPasswordFile` backed by a sops secret is the first post-boot task, out of scope here (per ADR 0001, an age key does not exist until the first install generates the SSH host key).
 ## Acceptance criteria
 - [x] The install procedure is documented end to end: push to Gitea → join wifi on the live ISO → clone locally → `disko-install` against `neogaia` → set bootstrap password via `nixos-enter` → reboot.
 - [x] The docs state that the install-time Nix daemon must have the chaotic substituter configured, or the kernel compiles from source on the USB stick.
 - [x] The docs explain that the local clone avoids self-signed-TLS/auth problems with flake fetching during install.
 - [x] The bootstrap password is set by hand and never committed; the docs flag the sops-backed `hashedPasswordFile` migration as the first post-boot follow-up.
 ## Implementation Notes
 The runbook lives at `docs/install.md`.
 Every documented command was checked against the actual pinned tooling rather than written from memory:
 - The `disko-install` and `disko` flags (`--flake`, `--disk NAME DEVICE`, `--write-efi-boot-entries`, `--option`, `--mode mount`) were read out of the pinned disko revision's wrapped scripts (the disko rev in `flake.lock`).
 - A consequence surfaced there and shaped the doc: `disko-install` traps `EXIT` and **unmounts** the target, so the "set the bootstrap password" step must first remount with `disko --mode mount` before `nixos-enter`.
  A naive `nixos-enter --root /mnt` straight after the install would have found nothing mounted.
 - The chaotic substituter URL and trusted key are quoted verbatim from `system/default.nix`, and `--disk main /dev/nvme0n1` matches `hosts/neogaia/disk.nix`.
 Two secrets are set by hand at install time, not one: the doc distinguishes the **LUKS passphrase** (prompted by disko at format, typed at every boot) from the **bootstrap login password** (set via `nixos-enter passwd`).
 The task named only the login password; the LUKS passphrase is an unavoidable part of the same by-hand flow, so it is documented alongside for a complete runbook.
 Beyond the task's terse list, the doc adds: a minimal-vs-graphical ISO split for joining wifi, and — from review — an SSH-key caveat for the clone plus an HTTPS-with-`sslVerify=false` fallback (which also reinforces the "git can skip verification where the flake fetcher can't" point behind the local-clone requirement).
 No criteria were dropped.
--- a/.claude/tasks/0010-sops-skeleton-and-password.md
+++ b/.claude/tasks/0010-sops-skeleton-and-password.md
@@ -1,62 +0,0 @@
 ---
 spec: sops-secrets
 ---
 ## What to build
 The tracer bullet for encrypted secrets: a working two-tier age identity model, with the primary user's login password arriving as a decrypted secret rather than a value typed into a running machine.
 Establish the two identities the model rests on.
 An admin identity is generated and stored as a secure note in the operator's password manager; only its public recipient ever appears in the repo, and no copy of the private half is committed in any form.
 A host identity is generated on `neogaia` itself, onto its encrypted root, never transmitted, and deliberately not derived from the machine's SSH host key.
 Commit a sops configuration naming both recipients and a shared secrets file encrypted to admin plus `neogaia`, holding the primary user's password hash.
 The hash lives in the shared file rather than a per-host one because the same password is used on every machine, so per-host copies would only make rotation a multi-file edit.
 Wire the tooling into the flake as unconditional plumbing in the shared base config — not behind an enable flag, on the same grounds as the overlays and the flakes settings.
 The base config carries only the machinery: the flake input, the identity file location, and the default secrets file.
 The password secret itself is declared beside the user declaration it feeds, so a reader finds the secret where they find its use.
 The password secret must be marked as needed for user creation, which decrypts it in an earlier activation stage than ordinary secrets.
 That ordering is why the host identity has to sit on the root filesystem rather than anywhere mounted later.
 The transition is safe on `neogaia`: if activation fails the rebuild fails and the running generation persists with its existing hand-set password intact.
 ## Acceptance criteria
 - [x] An admin age identity exists in the operator's password manager; its private half is committed nowhere, in no form
 - [x] A host age identity exists on `neogaia`'s encrypted root and was generated on the machine
 - [x] The sops configuration in the repo names the admin recipient and the `neogaia` recipient
 - [x] A shared secrets file, encrypted to admin plus `neogaia`, holds the primary user's password hash
 - [x] The secrets flake input is added, following the base nixpkgs
 - [x] The shared base config carries the machinery unconditionally — identity file location and default secrets file — with no enable flag
 - [x] The password secret is declared beside the user declaration, consumed through `hashedPasswordFile`, and marked as needed for user creation
 - [x] `nix flake check` builds the `neogaia` toplevel; a mistyped secret name or missing secrets file fails it
 - [x] Manual confirmation: `neogaia` activates, and console login succeeds against the decrypted password hash
 ## Implementation Notes
 **`users.mutableUsers = false` was required and is not in the plan.**
 NixOS applies a declared password hash to an account that already exists in `/etc/shadow` only when `mutableUsers` is false — `update-users-groups.pl` guards both assignments on it.
 At the default of true, `alexion` already existed, so `hashedPasswordFile` would have been ignored and the hand-set password kept, silently.
 The final acceptance criterion would then have passed while proving nothing, because the login being tested would still have been the old one.
 Two consequences follow, neither sanctioned by the spec.
 `passwd` no longer works, so rotating the password means re-running `mkpasswd`, re-encrypting the shared file, and rebuilding.
 Root has no declared password and is therefore locked (`!`), which blocks direct root login and the systemd emergency shell's `sulogin` prompt.
 `sudo` from the wheel group is unaffected, and generation rollback or `init=/bin/sh` remains available for recovery.
 Leaving root locked was chosen over declaring a root password, on the grounds that the recovery paths that survive a locked root do not depend on `/etc/shadow` at all.
 This is worth folding back into the parent spec before the servers exist, where a locked root and no SSH key would be a harder corner.
 **The negative half of the build criterion was exercised, not assumed.**
 A mistyped secret name fails with `the key 'alexion-passwrd' cannot be found`.
 A missing secrets file fails with `Path 'secrets/absent.yaml' does not exist in Git repository`.
 Both were tested by temporary edits that were reverted.
 **Identity handling.**
 The admin identity was generated by the operator in a terminal outside this session, so no copy of its private half ever reached the agent or the repo.
 The host identity was generated on `neogaia` into `/var/lib/sops-nix/key.txt` (mode 0400, root) on the `@root` subvolume of the LUKS-encrypted `cryptroot`, and never transmitted.
 **Follow-up worth flagging for 0011.**
 `services.openssh.enable` is true on `neogaia` with no declared `authorizedKeys`, so SSH is not a fallback route in if a future decryption failure locks the console.
 The task that makes the SSH host keys secrets is the natural place to settle that.
--- a/.claude/tasks/0011-neogaia-ssh-host-keys.md
+++ b/.claude/tasks/0011-neogaia-ssh-host-keys.md
@@ -1,60 +0,0 @@
 ---
 spec: sops-secrets
 blocked-by: 0010-sops-skeleton-and-password
 ---
 ## What to build
 `neogaia`'s SSH host keys become secrets, so reimaging the laptop no longer invalidates its host identity or breaks `known_hosts` for every client that has ever connected to it.
 Introduce a per-host secrets file for `neogaia`, encrypted to the admin identity plus `neogaia` alone — the first file in the repo that is not readable by the whole fleet, and the thing that keeps a compromised machine from decrypting another's material.
 The host's SSH **private** keys go in it.
 The host **public** keys are committed in plaintext.
 Publishing them is their function, and encrypting them would impose a re-key cycle every time one changes.
 Stop the SSH daemon generating its own host keys and point it at the decrypted paths instead.
 These secrets decrypt in the ordinary activation stage rather than the early pre-user one, so this slice exercises the second of the two decryption paths.
 ## Acceptance criteria
 - [x] A secrets file for `neogaia` exists, encrypted to the admin identity and `neogaia` only — not to any other recipient
 - [x] `neogaia`'s SSH host private keys are stored in it
 - [x] The corresponding host public keys are committed in plaintext
 - [x] The SSH daemon no longer generates its own host keys and reads the decrypted paths
 - [x] The host key secrets are declared beside the SSH daemon configuration that consumes them
 - [x] `nix flake check` builds the `neogaia` toplevel
 - [x] Manual confirmation: after activation the secrets materialize with the declared ownership and mode, the daemon adopts the restored keys, and the host fingerprint presented to a client is unchanged
 ## Implementation Notes
 **Both key types were preserved, not just ed25519.**
 The running daemon served an ed25519 and an RSA host key, and a client that pinned either would break if only one were carried over.
 Both private halves are in `secrets/neogaia.yaml`.
 **The decrypted keys stay at their default `/run/secrets/` paths.**
 The first attempt set each secret's `path` to the conventional `/etc/ssh/ssh_host_*_key`, which has sops plant a symlink inside a directory NixOS otherwise manages through `setup-etc`.
 It worked, but it buys nothing: `sshd` reads whatever `HostKey` names, and the extra `/etc` interaction depends on activation ordering that nothing in the config pins.
 The `HostKey` lines now interpolate `config.sops.secrets.<name>.path`, so the daemon and the secret cannot disagree about where the key is.
 `/etc/ssh` ends up holding no key material at all.
 **`restartUnits = [ "sshd.service" ]` is not in the plan and is needed.**
 `sshd` reads its host keys once at startup.
 Without this, re-keying the host would rewrite the decrypted files while the daemon kept serving the old keys from memory until some unrelated restart — silently, and precisely the identity drift this task exists to prevent.
 The plan's manual criterion would not have caught it, since it was verified on a switch where the keys had not changed.
 **The committed public keys have no consumer yet.**
 An intermediate version deployed them to `/etc/ssh` via `environment.etc`.
 That was dropped as scope the task did not ask for: `sshd` derives the public half from the private key at load, so nothing read them.
 They are committed, per the criterion, and the task that distributes `known_hosts` to clients is where they acquire a use.
 **Verification was stronger than a before/after comparison.**
 After activation the leftover `/etc/ssh/ssh_host_*_key` symlinks from the first attempt were removed and `sshd` restarted with no key material anywhere in `/etc/ssh`.
 It came back active and presented `SHA256:2ysuBX0+Z6GbdCTujz5JHX6rqnJzIyWhYNrxdhhGwEM` (ed25519) and `SHA256:y6Tl3P/FvfufblfG059BfCsSkMYX8Zk2EpFQvWzCAew` (RSA) — identical to the pre-change fingerprints.
 The generated `sshd-keygen.service` has no `ExecStart` at all, which is what confirms generation is off rather than merely idle.
 Separately, the encrypted file was decrypted with the host identity and diffed against the live private keys before anything was changed.
 **Task 0010's handoff about `authorizedKeys` is deliberately left open.**
 That note proposed settling it here, on the grounds that SSH is not a recovery route while no key is authorized.
 It is not an acceptance criterion of this task, and choosing which public key to trust is the operator's call rather than one to infer.
 It wants its own task, and remains a real gap: a decryption failure that locks the console still has no network fallback.
--- a/.claude/tasks/0012-secrets-operations-docs.md
+++ b/.claude/tasks/0012-secrets-operations-docs.md
@@ -1,68 +0,0 @@
 ---
 spec: sops-secrets
 blocked-by: [0010-sops-skeleton-and-password, 0011-neogaia-ssh-host-keys]
 ---
 ## What to build
 A thorough revision of the install document, not an appendix to it.
 The existing procedure is built around a login password set by hand through `nixos-enter` after the install and never committed.
 That step no longer exists, so the parts of the document that describe it are wrong rather than merely incomplete: the framing that names two hand-entered secrets, the step that sets the bootstrap password, the reboot step's instruction to log in with it, and the closing follow-up section — which additionally describes the superseded key-derivation mechanism as the reason sops wiring cannot happen during an install.
 The LUKS passphrase remains the one secret genuinely entered by hand, and the revised document should say so plainly.
 The install ordering inverts.
 A host's identity is now provisioned and registered *before* its first boot, because the login password arrives only from a decrypted secret and there is no fallback credential — a first boot without a registered identity has no way in.
 The document should carry that as the reason, since it is the whole point of the reordering.
 Cover four procedures:
 - Provisioning a host that is already installed and running, done live on the machine: generate the identity, add its recipient, re-key the affected files with the admin identity, rebuild. No reimage, no live ISO.
 - Provisioning a host that does not yet exist, done on the live ISO before the install: generate the identity, add its recipient, re-key, write the identity onto the target root, then install. The install builds from a local clone, so no push is required mid-procedure; the recipient change is committed afterward.
 - The editing workflow: which secrets the workstation can change on its own, and which require unlocking the admin identity for the session. That friction is intended, not an oversight.
 - Recovery from a live ISO for a machine whose identity was provisioned wrongly, so a failed first boot is a known procedure rather than an improvised one.
 Everything goes in the existing install document; no new document is introduced.
 ## Acceptance criteria
 - [x] No step remains that sets a login password by hand, and nothing instructs the operator to log in with one
 - [x] The document's framing names the LUKS passphrase as the only hand-entered secret
 - [x] The install ordering places identity provisioning before first boot, and states why there is no fallback credential
 - [x] The closing section no longer describes deriving identities from SSH host keys or defers sops wiring to a post-boot follow-up
 - [x] Live provisioning for an already-running host is documented
 - [x] Pre-install provisioning on the live ISO for a not-yet-existing host is documented, including that the recipient change is committed after the install
 - [x] The editing workflow is documented, distinguishing what the workstation can re-key alone from what needs the admin identity
 - [x] The live-ISO recovery path for a wrongly-provisioned machine is documented
 - [x] The document reads end to end as one coherent procedure for a reader who has never seen the previous version
 ## Implementation Notes
 **The document was retitled and given a table of contents.**
 Three of the four procedures are not installs, so "Installing `neogaia`" no longer described the contents.
 It is now "Installing and provisioning a host", and the install procedure is one section among four rather than the whole document.
 The install steps stay concrete about `neogaia` and its NVMe device, since that is the only machine the flake installs today and a generic example would be less useful than a real one.
 **Commands were verified against the running system rather than written from memory.**
 Neither `sops` nor `age` is packaged by this flake, so every invocation goes through `nix run nixpkgs#sops` or `nix shell nixpkgs#age -c age-keygen`, and the document says so up front.
 `sops updatekeys`, `age-keygen -y`, and `nixos-install --root/--flake/--no-root-password` were each confirmed to exist.
 The identity file's `0400 root:root` and `/var/lib/sops-nix/key.txt` were read off the live machine, and `/var` was confirmed to sit on the `@root` subvolume, which is what makes the path valid before user creation.
 **Review caught four factual errors, all corrected.**
 The most consequential: the post-provisioning check said `ls -l /run/secrets/`, but `neededForUsers` puts the password hash in `/run/secrets-for-users/` — confirmed by `nix eval`, which returns `/run/secrets-for-users/alexion-password`.
 The one secret whose failure causes the lockout the document exists to prevent was the one the reader was told not to look at.
 Also fixed: the `.sops.yaml` example added a new host to the shared rule but not a rule for its own file, which makes `sops` refuse it with `no matching creation rules found`; step 8's `updatekeys` omitted `SOPS_AGE_KEY_FILE`, so it would have looked in `~/.config/sops/age/keys.txt` rather than the root-owned identity; and "create its file now" did not say that a host enabling the SSH daemon needs `ssh-host-<type>-key` entries or the build fails at evaluation.
 **Deliberate redundancy in the recovery path.**
 Review flagged the disko remount block and the re-key sequence as duplicated between the install and recovery sections.
 They are left duplicated on purpose: an operator running the recovery procedure is locked out of the machine, and sending them to page back into the install steps mid-recovery is worse than the maintenance cost of two copies.
 The already-running-host procedure does cross-reference step 4, because that reader has a working machine and can follow a link.
 **The recovery procedure is documented but unexercised.**
 Both branches follow from verified facts — `nixos-install` is idempotent and reuses the formatted disk, and the secrets file is baked into the closure at build time, which is why one branch needs a rebuild and the other does not.
 Neither has been run, because doing so requires deliberately locking out the only machine.
 The claim that no fallback credential exists was checked rather than assumed: there is no `authorizedKeys`, no root password, and `mutableUsers = false`.
 **Follow-up.**
 Task 0019 adds user SSH keys, which will make "no authorized SSH key" in the no-fallback paragraph stale.
 That paragraph is the place to revisit when it lands, since an authorized key would become a genuine second way in.
--- a/.claude/tasks/0013-nixos-hardware-profile.md
+++ b/.claude/tasks/0013-nixos-hardware-profile.md
@@ -1,40 +0,0 @@
 ## What to build
 Hand ownership of `neogaia`'s hardware facts to the upstream `nixos-hardware` profile for the Dell XPS 13 9380, replacing settings this repo currently guesses or omits.
 The profile is adopted wholesale, including the Intel GPU support it pulls in. Those packages are inert on a machine with no display server, and trimming them would mean diverging from upstream for no present benefit.
 Adopting it makes four things true that are false on the running machine today: the laptop suspends into deep S3 rather than s2idle, the redundant PS/2 mouse driver stops loading over the i2c touchpad, thermal management runs, and firmware updates become possible.
 The microcode setting the `Host` currently declares is dropped, because the profile provides it as a default keyed off the redistributable firmware setting already enabled here.
 ## Acceptance criteria
 - [x] `nixos-hardware` is a flake input
 - [x] The Dell XPS 13 9380 profile is imported by the `neogaia` `Host`
 - [x] The `Host`'s own Intel microcode setting is removed, now that the profile supplies it
 - [x] `nix flake check` builds the `neogaia` toplevel
 - [x] Manual confirmation after a rebuild: the default sleep mode is deep rather than s2idle
 - [x] Manual confirmation after a rebuild: the thermal and power management services are active, and the PS/2 mouse driver is no longer loaded
 ## Implementation Notes
 Both manual criteria were confirmed on the rebooted machine. The selected sleep
 mode moved from s2idle to deep, with the kernel parameter visible on the boot
 command line; the thermal and power management services came up active; and the
 PS/2 mouse module is no longer loaded. The booted system, the running system and
 the freshly built toplevel are all the same store path, so these readings come
 from this configuration rather than a surviving older generation.
 The firmware update service reads as inactive, which is correct rather than a
 failure: it is activated on demand over D-Bus. Its unit is present, its refresh
 timer is enabled, and its command-line tool is on the path.
 The input follows the base nixpkgs. Locking it without that pulled a second
 nixpkgs into the lock file, which nothing evaluates — only the NixOS modules are
 consumed — and which would drift silently. Following matches every other input
 here except chaotic, whose separate pin is deliberate.
 Intel microcode updates now rest on the profile's default rather than an explicit
 setting here. The default is overridable, so a `Host` that disables redistributable
 firmware would silently lose microcode updates too.
--- a/.claude/tasks/0014-nix-store-housekeeping.md
+++ b/.claude/tasks/0014-nix-store-housekeeping.md
@@ -1,30 +0,0 @@
 ## What to build
 Bound the three things on this machine that currently grow without any limit: the Nix store, the set of retained system generations, and the boot menu.
 Garbage collection runs weekly, deleting generations older than 30 days. That window is the point of the setting — on a rolling channel with a third-party kernel, the value of an old generation is having a known-good system to boot when an update breaks something, and disk space is not scarce here: the store is under 5 GiB against 473 GiB free.
 Store optimisation runs weekly on its own schedule rather than at build time, so deduplication never adds latency to a rebuild.
 Retained boot configurations are capped at 15. Each generation stores a kernel and an initrd on the EFI system partition at roughly 70 MiB apiece, and that partition is small and fixed. An exhausted one fails at bootloader installation — after the build has already succeeded, which is a confusing place to get stuck. The cap assumes the enlarged partition; on the current 512 MiB one only about seven fit.
 ## Acceptance criteria
 - [x] Automatic garbage collection is enabled weekly, deleting generations older than 30 days
 - [x] Store optimisation is scheduled weekly, rather than performed at build time
 - [x] Retained boot configurations are capped at 15
 - [x] These are declared as plumbing in the shared base config, so every future `Host` inherits them
 - [x] `nix flake check` builds the `neogaia` toplevel
 - [x] Manual confirmation after a rebuild: the collection and optimisation timers exist and are scheduled
 ## Implementation Notes
 The two schedules are named days rather than the bare `weekly` keyword.
 systemd expands `weekly` to `Mon *-*-* 00:00:00`, which would have started collection and deduplication at the same instant every week, leaving `nix-optimise` hard-linking paths `nix-gc` was concurrently deleting.
 Collection now runs `Mon 03:15` and optimisation `Thu 03:45`, which keeps both weekly and keeps them apart.
 The boot configuration cap sits in the shared base as the task asks, and is inert rather than an error on a host that does not use systemd-boot.
 A future host on another bootloader therefore inherits no cap, which is the one place the "every future host inherits them" promise does not reach.
 Confirmed on `neogaia` after a switch: `systemctl list-timers 'nix-*'` lists both units, `nix-optimise` next on Thursday and `nix-gc` next on Monday, each `Persistent=true` so a suspended laptop catches up on a missed firing.
 `/boot` reports 2 GiB with 113 MiB used, so the cap of 15 sits against the enlarged partition it assumes.
--- a/.claude/tasks/0015-git-module.md
+++ b/.claude/tasks/0015-git-module.md
@@ -1,42 +0,0 @@
 ## What to build
 A git `Module`, following the `Enable convention` and configured natively through home-manager, that carries the operator's commit identity — enabled on `neogaia`.
 Today that identity exists only in one repository's local configuration on one machine. It is therefore invisible to every other checkout, absent from any future `Host`, and lost on a reimage. Declaring it makes committing work anywhere, reproducibly, like everything else in the flake.
 The identity matches the one already present throughout this repository's history, so existing commits and future ones agree. Committing it is not a disclosure: it appears in every commit this repository has ever published.
 It is a `Module` rather than base plumbing because a `Host` that should not carry a personal commit identity is easy to imagine once the servers exist.
 ## Acceptance criteria
 - [x] A git `Module` following the `Enable convention` exists and is enabled on `neogaia`
 - [x] The commit identity is configured through home-manager and matches the one used in existing history
 - [x] `nix flake check` builds the `neogaia` toplevel
 - [x] Manual confirmation: committing in a repository outside this checkout succeeds with no per-command identity override
 - [x] The stale note in the project's agent instructions claiming git identity is unconfigured is corrected, since commits already work here through repository-local configuration
 ## Implementation Notes
 `programs.git.userName`/`userEmail` are renamed in this home-manager pin and emit an obsolete-option trace.
 The module uses `settings.user.name`/`settings.user.email`.
 Do not "fix" it back.
 Review on the pull request asked for the module on every host, which was first built by defaulting `enable` to true and dropping the per-host line.
 The operator then chose the opposite: `enable` defaults to false and each host enables it explicitly, so a host keeps reading as a full checklist of what it carries rather than hiding a default-on module.
 Enabling it is therefore a step when adding a host.
 The commit name is the literal `"alexion"` rather than `config.user.name`, which review raised as duplication.
 A Unix login and a commit display name are separate concepts that merely coincide here, so binding them would let a host overriding its login silently rewrite the operator's commit identity.
 The manual confirmation is met on the running machine.
 The operator rebuilt `neogaia`, `~/.config/git/config` is now a home-manager symlink, and a commit in a repository outside this checkout was authored `alexion <contact@alexion.dev>` in the real environment with no per-command override and no identity in the test repository's own config.
 Review surfaced an unanticipated hazard that proved harmless.
 Home-manager writes `~/.config/git/config`, while an undeclared `~/.gitconfig` also exists and outranks it on any key set in both.
 It holds only a `tea` credential helper and no `user.*`, so it does not shadow the identity, confirmed against the deployed configuration.
 Declaring that credential helper is a reasonable follow-up, since it will not survive a reimage.
 This checkout's `.git/config` still sets the same identity, now redundant.
 Removing it would let the module govern here too, so a future breakage surfaces instead of being masked.
 It is local, untracked state, so it is left alone rather than changed as part of this task.
--- a/.claude/tasks/0016-esp-resize-and-reimage.md
+++ b/.claude/tasks/0016-esp-resize-and-reimage.md
@@ -1,59 +0,0 @@
 ---
 blocked-by: 0013-nixos-hardware-profile
 ---
 ## What to build
 Grow `neogaia`'s EFI system partition and reimage the laptop from the finished configuration.
 The partition is 512 MiB today, holding about seven generations at roughly 70 MiB of kernel and initrd apiece, and this `Host` runs a large third-party kernel. It grows to 2 GiB, which holds around 28 — comfortably past the 15 that are retained, at a cost of 0.3% of a 512 GB disk.
 It cannot be grown in place: it sits first on the disk, starting at sector 2048 with the encrypted container immediately behind it, so enlarging it means moving that container's start offset. An encrypted volume's start cannot be relocated without rewriting its entire payload, which here is over 500 GiB. A reimage is the only practical route, and it is cheapest now — the machine is days old and holds around 3 GiB, of which 136 MiB is user data.
 The hardware profile blocks this because it is the one boot-affecting change queued: it adds a kernel parameter and blacklists a module. Proving it boots while a known-good generation still exists to roll back to means the reimage installs a configuration already known to work on this hardware. A freshly imaged machine has one generation and no rollback target, which is the wrong place to discover a bad kernel parameter.
 Nothing else blocks it. The housekeeping and commit-identity changes carry no boot risk and apply in seconds on either side of the wipe, so they must not be allowed to delay it — the case for reimaging now rests on the machine still holding almost nothing, and that erodes with every day of use.
 This reimage is also the reproducibility test of the install documentation. The first install was performed while writing it; performing it a second time against the current configuration is what proves it is a procedure rather than a record of one improvised session.
 One thing must be true before the disk is erased: every branch worth keeping has to exist on the remote, because work that lives only on this disk dies with it.
 ## Acceptance criteria
 - [x] The `Host`'s disk layout declares a 2 GiB EFI system partition
 - [x] Every local branch worth keeping exists on the remote before the disk is erased
 - [x] The reimage is performed from a configuration carrying the hardware profile, following the existing install documentation
 - [x] The install documentation is corrected wherever the procedure diverged from what it describes
 - [x] Manual confirmation: the machine boots, the encrypted root unlocks, and console login succeeds
 - [x] Manual confirmation: reported free space on the boot partition is consistent with its 2 GiB size, resolving the discrepancy observed before the reimage — where a 512 MiB partition reported 1022 MiB
 - [x] The project's agent instructions record that a flake only sees git-tracked files, so an untracked file is invisible to evaluation
 ## Implementation Notes
 Done. The reimage was performed by the operator and the machine now runs the
 configuration this repository declares.
 The install ran clean: the operator reports no step diverged from
 `docs/install.md`, so criterion 4 is satisfied with no further corrections. The
 four corrections that landed earlier came from reading the procedure; the run
 itself found nothing to add. That is the reproducibility evidence the task was
 after — the document is a procedure, not a record of one improvised session.
 Verified on the running machine rather than assumed:
 - `/dev/nvme0n1p1` is 2.0 GiB and `df` reports 2.0 GiB. The pre-reimage
  discrepancy, where a 512 MiB partition reported 1022 MiB, is gone.
 - The hardware profile is live — `mem_sleep_default=deep` is on the kernel
  command line and `psmouse` is blacklisted and not loaded.
 - `cryptroot` is open on `nvme0n1p2` with btrfs mounted, reached through a
  console login, so the boot-unlock-login path is exercised end to end.
 - One generation exists (`system-1-link`), confirming a fresh install rather
  than a rebuild of the prior system.
 The ordering hazard closed favourably: the declaration and the install landed
 close enough together that the repository never asserted a layout the disk
 lacked for long.
 Two items outside the repo did not survive the wipe, as anticipated, and neither
 is covered by a criterion: the wifi credentials, and the agent memory directory
 — confirmed empty after the reimage.
--- a/.claude/tasks/0017-hardware-detection-refresh.md
+++ b/.claude/tasks/0017-hardware-detection-refresh.md
@@ -1,40 +0,0 @@
 ---
 blocked-by: 0016-esp-resize-and-reimage
 ---
 ## What to build
 Replace `neogaia`'s hand-written hardware detection file with a real scan of the machine it describes.
 The file was written before the laptop ran NixOS, as an educated guess at what a Dell XPS 13 9380 needs, and still says so. The guess turned out to be adequate — the module required to reach the encrypted root is present and working — so this is honesty maintenance rather than a fix. It matters because the next person to read the file, including a future reader of this repo, should be able to trust that it describes measured hardware.
 Only the detection results are kept: the modules the initrd needs, the modules the kernel loads, and the platform. The generated output also contains filesystem and swap declarations, which are dropped — the declarative disk layout owns those, produces them on every evaluation, and a second stale definition would either conflict outright or silently disagree.
 Generating the scan requires root on the target machine.
 ## Acceptance criteria
 - [x] The detection file's contents come from a scan of the running machine rather than a guess
 - [x] Filesystem and swap declarations are absent from it, leaving the disk layout as the sole source of those
 - [x] The file no longer describes itself as a placeholder, and says plainly what it holds
 - [x] `nix flake check` builds the `neogaia` toplevel
 ## Implementation Notes
 **The guess was wider than the measurement, not narrower.**
 It named `thunderbolt`, `usb_storage`, and `sd_mod`, none of which the scan reports; the scan adds `rtsx_pci_sdmmc` for the card reader.
 Nothing needed to reach the root device was missing, so the guess was adequate as the task assumed, but it was not accurate.
 `sd_mod` survives in the resolved list regardless, supplied by nixpkgs' own defaults; `thunderbolt` and `usb_storage` now genuinely go, and they matter only for booting from external media, which this machine does not do.
 **Two further lines from the scan were dropped beyond the filesystem and swap declarations the task named.**
 `boot.initrd.luks.devices."cryptroot".device` is derived by the disk layout, which the layout file already states, so keeping it would have created the same duplicate definition the task drops the filesystems to avoid.
 `hardware.cpu.intel.updateMicrocode` falls outside the three things the task keeps, and the hardware profile supplies it anyway.
 Both were checked rather than assumed: after the change the LUKS device, all four filesystems, and microcode all still resolve.
 **The header was rewritten twice.**
 Its first form enumerated the file's three attributes, which the repo's comment convention names as a feature inventory and forbids in a file-top header.
 It now carries provenance and the absence pointer only.
 **Verified by a boot.**
 `nix flake check` proves only that the configuration evaluates and builds, so the reduced initrd was exercised on the machine: it unlocked LUKS and mounted the btrfs root unaided.
 The running system's store path matches this configuration's build exactly, confirming the boot used it rather than an earlier generation.
--- a/.claude/tasks/0018-agent-sudo-credential-caching.md
+++ b/.claude/tasks/0018-agent-sudo-credential-caching.md
@@ -1,64 +0,0 @@
 ## What to build
 Make root-requiring work reachable from an agent session without waiving the password, by sharing sudo's credential cache across sessions and failing loudly when it is cold.
 Sudo caches an authentication for a timeout window, but keys that cache by terminal under its default `timestamp_type=tty`.
 An agent's commands run in subprocesses on a different terminal, so a `sudo -v` typed in the operator's shell is invisible to them and every privileged command fails.
 Setting `timestamp_type=global` keys the cache per user instead, so one authentication covers the whole machine for the window.
 The timeout is raised to 60 minutes so a session needing root authenticates once rather than every five.
 No `NOPASSWD` rule is introduced, and this is the point of the design.
 The password remains genuinely required; only its cache is shared.
 A `NOPASSWD` entry for `nixos-rebuild` would be indistinguishable from blanket root on this machine, since anything able to edit the flake and then rebuild it owns the system.
 The tradeoff is real and bounded: during the window, any process running as the operator can use the cached credential, not only the agent.
 That is acceptable on a single-user personal laptop where the agent already runs as that user, and it is the reason this belongs to a laptop rather than to any future server `Host`.
 The second half is failure behaviour.
 A cold cache today surfaces as a bare non-zero exit with no output, which reads as an unexplained stall: the operator has to notice the agent is stuck and then work out what it wanted.
 A `PreToolUse` hook probing `sudo -n true` turns that into an immediate, actionable refusal naming the command to run.
 ## Acceptance criteria
 - [-] `timestamp_type=global` and a 60-minute timeout are declared as plumbing in the shared base config
 - [x] No `NOPASSWD` rule is introduced, and the wheel group still requires a password
 - [x] Confirmed that NixOS does not already set `timestamp_type` elsewhere, so the declaration is not silently overridden
 - [x] A `PreToolUse` hook in the claude-code `Module` denies a privileged command when the cache is cold, naming `sudo -v` in its message
 - [x] The hook's behaviour is correct when the harness sandbox, rather than a cold cache, is what blocks the command
 - [x] `nix flake check` builds the `neogaia` toplevel
 - [x] Manual confirmation after a rebuild: `sudo -v` in one terminal lets a privileged command succeed from an agent session, and that command fails with the hook's message once the window lapses
 ## Implementation Notes
 **The sudo settings are declared in the claude-code module, not in the shared base config.**
 The criterion asking for the shared base contradicted this task's own rationale, which argues the widened cache suits a single-user machine and should not reach a future server.
 Neither placement was right, though: the setting and the hook that depends on it belong together.
 The hook reads the credential cache from a process of its own, which only works under `timestamp_type=global`, so a host enabling the module without the sudo half would get a hook that never sees a cached credential and refuses every privileged command permanently.
 Declaring both under the module's `enable` makes that impossible to get wrong, and carries the setting to any future host that runs the agent.
 The cost is that enabling a developer tool now changes the machine's sudo posture, which a reader auditing sudo policy would not expect to find there.
 The enable option's description carries the warning so it surfaces in generated documentation.
 Should a host ever need the agent without the widened cache, that is when a separate sub-option earns its place; adding one now would be speculative.
 **Verified against the running system, in both cache states.**
 Cold, the hook refuses with its message; warm, it permits and the command uses a credential authenticated in a different terminal.
 The hook process is not itself sandboxed, so it reads the real cache rather than refusing unconditionally — the failure mode that would have required it to fail open instead.
 One residual is worth knowing.
 The hook governs whether a privileged command is attempted, not whether it can run: the agent's own sandbox blocks `sudo` separately, and swallows it into a bare exit with no output.
 A permitted command can therefore still fail for that unrelated reason, and needs the sandbox disabled.
 The two are distinguishable in practice, since only one of them produces the hook's message.
 **The operator must authenticate from a real terminal.**
 Warming the cache from inside an agent session does not work: that shell has no controlling terminal, so sudo cannot prompt and reports `a terminal is required to read the password`.
 Feeding the password by another route was rejected rather than unexplored.
 Reading it from the agent's stdin would route it through the agent, and an askpass helper on this console-only machine could only prompt on the pane the agent already draws to, which trains the operator to type a password into an agent-controlled surface.
 A separate terminal is the only safe channel, which is precisely what the global cache keying exists to make useful.
 **`jq` is now a home package.**
 The hook parses the tool input handed to it on stdin, and nothing on the profile provided a JSON parser.
 Matching on the raw JSON text with `grep` was rejected: a command containing quotes or newlines would break it, and this hook fails closed, so a parsing mistake blocks real work.
 **The sudo detection is anchored to command position.**
 `grep sudo /etc/passwd` and `echo "run sudo -v"` are allowed; `sudo x`, `cd /tmp && sudo x`, and `true; sudo x` are blocked.
 A `sudo` inside a quoted string that happens to sit in command position will still trip the guard, which errs toward asking rather than stalling.
--- a/.claude/tasks/0019-user-ssh-keys-and-access-policy.md
+++ b/.claude/tasks/0019-user-ssh-keys-and-access-policy.md
@@ -1,87 +0,0 @@
 ---
 blocked-by: 0011-neogaia-ssh-host-keys
 ---
 ## What to build
 The operator's SSH client key becomes a secret, and which machines may reach which becomes a declared policy rather than a hand-edited list.
 Today the key that authenticates pushes to the remote exists only as a file created by hand on one laptop.
 It is in no secrets file and no module, so a reimage destroys it.
 That is worse than losing a host key: a lost host key makes clients complain about `known_hosts`, whereas a lost client key locks the operator out of the remote until a new one is generated and registered through the forge's web interface.
 Each machine gets its **own** client identity rather than one shared across the fleet.
 The private half lives in that machine's own secrets file, so it is readable by that machine and the admin identity alone.
 A compromised machine therefore surrenders only its own key, and withdrawing a machine's access means removing one public key rather than re-keying every other machine.
 The public halves are committed in plaintext, as the host public keys are, since publishing them is their function.
 The private half decrypts at activation and is readable only by the primary user.
 Following the host keys, the client is pointed at the decrypted path rather than having a copy written into the user's home, so there is one authoritative location for the key and no copy to drift.
 Access is expressed as a policy over machine roles, not as a per-host list of authorized keys.
 A **workstation** may reach every machine in the fleet.
 A **server** may reach other servers only.
 Consequently every machine authorizes the workstation keys, and servers additionally authorize the server keys, while a workstation never authorizes a server's key — so a compromised server cannot reach the operator's own machines.
 This wants a single declaration of the fleet, naming each machine's role and its client public key, from which every host derives the set it authorizes.
 Registering a new machine is then declaring its role in one place, rather than an edit to every other host's configuration.
 Only `neogaia` exists today, so the server half of the policy has nothing to act on and cannot be exercised.
 It is built and recorded now so that the desktop and the three planned servers are a role declaration rather than a redesign.
 Adopt the key already present on `neogaia` rather than generating a fresh one.
 It is already registered with the remote, so adopting it keeps pushes working, whereas replacing it would require registering the new key through the web interface before the old one stops being used — an ordering that locks the operator out if it goes wrong.
 Machines that do not exist yet generate their own key during provisioning, alongside the age identity.
 This also settles the gap left open by task 0010, where the daemon accepts connections but authorizes no key, so a failed decryption that locks the console has no network fallback.
 Note that the fallback only becomes real once a second machine exists to connect from.
 ## Acceptance criteria
 - [x] `neogaia` has its own client SSH identity, distinct from its host keys, adopted from the key already on the machine
 - [x] Its private half is stored in `neogaia`'s own secrets file, encrypted to the admin identity and `neogaia` alone
 - [x] Its public half is committed in plaintext
 - [x] The private half decrypts at activation, readable only by the primary user and not by other accounts
 - [x] The SSH client uses the decrypted key with no hand-placed copy in the user's home directory
 - [x] Each machine declares a role, and the keys it authorizes follow from that role rather than from a per-host list
 - [x] Workstation keys are authorized on every machine
 - [x] Server keys are authorized on servers only, and on no workstation
 - [x] Registering a new machine is a role declaration in one place, requiring no edit to any other host
 - [x] `nix flake check` builds the `neogaia` toplevel
 - [x] Manual confirmation: the key materializes with the declared ownership and mode, an authenticated push to the remote still succeeds, and `neogaia` accepts an SSH connection offering the adopted key
 ## Implementation Notes
 The whole policy is three options on the ssh module.
 Two are the lists of client public keys, one for the machines the operator works from and one for the machines that serve.
 The third is the set a machine admits, which a host declares in its own file by naming the lists it draws from.
 Two earlier designs were discarded as more machinery than the problem has.
 The first was a separate fleet declaration mapping each machine to a role and a key, which the module looked up by hostname.
 The second kept the two lists but derived the admitted set from a role enum.
 Authorizing a key needs the key text and nothing else, so the per-machine names, the hostname lookup and the role all existed to reconstruct a grouping that the two lists simply are.
 A host now states what it admits rather than stating a category that something else maps to keys.
 `authorizedKeys` defaults to the workstation keys.
 An option of a list type is not required in the way a scalar one is: leaving it undeclared yields the empty list rather than an evaluation error, and a machine admitting no key is unreachable over SSH.
 The default makes the safe case the silent one.
 Only `neogaia` exists, so the server half has nothing to act on.
 It was verified by temporarily adding a synthetic server key and declaring both lists on the host, then reverting.
 A host drawing on the workstation keys alone excluded the server key, and one drawing on both admitted it.
 Omitting the declaration entirely was confirmed to fall back to the workstation keys rather than to none.
 Home-manager's `matchBlocks` is deprecated in favour of `settings`, so the client uses the latter.
 `enableDefaultConfig = false` drops home-manager's own default directives, leaving the generated `~/.ssh/config` at two lines and every other directive at the value OpenSSH itself ships.
 The committed public key carries the comment `alexion@neogaia` rather than the adopted key's own `contact@alexion.dev`, so the list says which machine each key belongs to.
 An authorized-keys comment is free text and independent of the private key.
 Manual confirmation was performed after a `nixos-rebuild switch`.
 The secret materialized as `-r--------` owned by the primary user, and the public half derived from it matches the committed fleet entry.
 The hand-placed `~/.ssh/id_ed25519` was moved aside for the test, so both directions were exercised against the decrypted secret alone: `ssh -v` to the remote reported `Server accepts key: /run/secrets/ssh-user-ed25519-key`, and an inbound connection to `neogaia` authenticated and returned a shell.
 One follow-up is outstanding.
 Deleting the now-redundant `~/.ssh/id_ed25519` and its public half was refused by the agent's permission layer, so both files remain on the machine.
 They are superseded rather than needed: the same key is in `secrets/neogaia.yaml`, and the client is pointed at the decrypted path.
 Removing them is a one-line manual step, and the key is recoverable from the secrets file if it is ever wanted back.
--- a/.claude/tasks/0020-pi-coding-agent-module.md
+++ b/.claude/tasks/0020-pi-coding-agent-module.md
@@ -1,27 +0,0 @@
 ---
 spec: pi-coding-agent
 ---
 ## What to build
 Add a `pi` module, auto-discovered like every other feature and inert until a host enables it, that installs Pi for the primary user through the home-manager `programs.pi-coding-agent` module.
 On enable it freezes exactly one file — `settings.json` — pinning the default provider to Anthropic and the default model to Opus (the exact model-id string confirmed against Pi's own model catalogue), and disabling analytics.
 Everything else — agent context, skills, extensions, keybindings, custom providers — is left at its default, so home-manager renders nothing but `settings.json` and Pi owns the rest of `~/.pi/agent/`.
 Pi authenticates by reusing the existing Claude subscription, and that credential is left unmanaged by the flake so no secret enters the repo and re-auth survives rebuilds, mirroring how the `claude-code` module treats its login.
 Lay the module out as a directory (not a single file), and enable it on `neogaia` alone with a single `enable = true`.
 ## Acceptance criteria
 - [x] A `pi` module exists as its own directory, declares a single `enable` option under the `modules` tree, guards its body with the Enable convention, and stays inert until a host enables it.
 - [x] On enable, the module turns on `programs.pi-coding-agent` for the primary user from the base package set, with no other host affected.
 - [x] The frozen `settings.json` sets the default provider to Anthropic, the default model to Opus (exact model-id verified against Pi's catalogue), and disables analytics — and no other upstream option (`context`, `models`, `keybindings`, `extraPackages`, `configDir`) is set.
 - [x] Pi's credential and all of its writable state (`~/.pi/agent/` beyond `settings.json`) are left unmanaged by the flake.
 - [x] `neogaia` enables the module with a single `enable = true` and its system toplevel still builds via `nix flake check` (the `checks.x86_64-linux.neogaia` target).
 - [x] Disabling the module is a one-line `enable` flip that leaves no flake-managed residue.
 ## Implementation Notes
 - **Model-id and analytics key confirmed against Pi 0.80.7 at build time.** The `pi-coding-agent` package pins `0.80.7`; its `dist/core/model-resolver.js` defaults the `anthropic` provider to `claude-opus-4-8`, which is the Opus id used. The analytics key is `enableAnalytics` (boolean, default `false`), per the package's own `docs/settings.md`. Both were read from the built store path, not guessed.
 - **Verified through the primary seam.** `config.modules.pi.enable` and `programs.pi-coding-agent.enable` both evaluate `true` on `neogaia`; the rendered `settings.json` is exactly `{"defaultModel":"claude-opus-4-8","defaultProvider":"anthropic","enableAnalytics":false}`; only one file (`settings.json`) is rendered under `~/.pi/agent`; and `checks.x86_64-linux.neogaia` builds green with `pi-coding-agent-0.80.7` included.
 - **No deviations from the spec.** The diff is the module plus one `enable = true` line — every "Out of Scope" item (agent context/`AGENTS.md`, skills, extensions, keybindings, custom providers, Pi-specific sudo guard) is left out.
 - **Review follow-through.** `/review-uncommitted` rated Risk **Low** and Spec **clean**. Standards flagged four comment-convention issues on the new module (a semicolon in a comment, an overloaded file-top header duplicating the inline rationale, and a cross-file clause on the model-id comment); all were fixed in the diff, so the header is now a two-sentence purpose line mirroring the sibling `claude-code` module and the frozen-settings rationale lives only at its inline site. No findings left unaddressed.
--- a/.claude/tasks/0021-desktop-group-and-hyprland-session.md
+++ b/.claude/tasks/0021-desktop-group-and-hyprland-session.md
@@ -1,67 +0,0 @@
 ---
 spec: hyprland-desktop
 ---
 ## What to build
 The tracer bullet for the whole desktop: a keyboard-driven Hyprland session that neogaia can log into and open a terminal in.
 Create the `modules/desktop/` group with an explicit aggregator, guarded by its own `modules.desktop.enable`, that hand-lists and turns on each piece at default priority so a host enables the whole desktop with one flag yet can still override any single piece.
 Namespace every desktop enable under one desktop group so a host's checklist gains one entry.
 Place the tightly coupled Hyprland-native pieces (starting with the compositor) in a subdirectory within the group.
 Wire Hyprland from nixpkgs: the NixOS program integration owns the session and polkit, home-manager owns the user configuration, and both share one Hyprland package so there is never a version split.
 The session is launched through the universal Wayland session manager from the greeter.
 Login is greetd with the tuigreet text greeter, mouse-free and lightweight.
 Port the operator's KDE/i3 keybinds expressed entirely in `hjkl` and letters with no arrow or navigation-cluster keys: numbered-workspace switch and move, focus and window movement, resize, terminal, floating, fullscreen, split, close, and force-kill, per the spec's keybind table.
 Tune input: US-only layout with no switcher, Caps mapped to Escape with Shift+Caps still producing CapsLock, snappy key-repeat, touchpad tap-to-click plus natural scroll plus disable-while-typing, and flat mouse acceleration.
 Set the feel: subtle animations, modest rounding, small gaps, and blur off (left as a knob a host such as zeus can enable).
 Install Ghostty as the terminal on `Super+Return`.
 Enable the desktop on neogaia.
 ## Acceptance criteria
 - [x] `modules/desktop/` exists with an aggregator exposing `modules.desktop.enable` that hand-lists and enables its pieces at default priority, each piece independently overridable.
 - [x] Desktop enable options are namespaced under a single desktop group; the Hyprland-native compositor lives in a subdirectory of the group.
 - [x] Hyprland is sourced from nixpkgs; the NixOS integration and the home-manager user config share one Hyprland package.
 - [x] The session launches through the universal Wayland session manager from a greetd/tuigreet text login.
 - [x] Keybinds match the spec's table, using only `hjkl`, letters, and number rows — no arrow or navigation-cluster keys.
 - [x] Input is tuned: US-only layout, Caps→Escape (Shift+Caps = CapsLock), snappy key-repeat, touchpad tap-to-click + natural scroll + disable-while-typing, flat mouse acceleration.
 - [x] Animations, rounding, and small gaps are on; blur is off and remains host-overridable.
 - [x] Ghostty opens on `Super+Return`.
 - [x] neogaia enables `modules.desktop` and builds green under `nix flake check`.
 ## Implementation Notes
 - **Keybind scope.**
  This task ports only the enumerated compositor-native bindings (workspace switch/move, focus, window move, resize, terminal, floating, fullscreen, split, close, force-kill).
  The spec table's launcher, lock, screenshot, clipboard, and record bindings depend on tools installed by later tasks (0024–0029), so each of those tasks adds its own binding rather than this one binding to a missing binary.
  Force-kill uses Hyprland's `forcekillactive` dispatcher, keeping it keyboard-only.
 - **Shared Hyprland package.**
  The NixOS `programs.hyprland` installs the single package and the portal system-wide, and the home-manager module sets `package = null` and `portalPackage = null` so it writes only the config against that one package.
  This is the "never a version split" guarantee, read as one package total rather than two identical derivations.
 - **hyprlang, not Lua.**
  The home-manager `wayland.windowManager.hyprland` module now defaults `configType` to `"lua"` at `home.stateVersion` ≥ 26.05, which serialises `$mod`-style variables and INI `bind=` strings into invalid Lua without failing the build.
  The module pins `configType = "hyprlang"` to emit the native `hyprland.conf`.
  Recorded as a gotcha in `CLAUDE.md`.
 - **Greeter session command.**
  greetd's `default_session` runs `uwsm start -e -D Hyprland hyprland.desktop`, mirroring the Exec line of the uwsm session the Hyprland package itself ships, so the session goes through the universal Wayland session manager deterministically.
 - **Terminal: Alacritty, not Ghostty.**
  The spec named Ghostty, but on neogaia's integrated graphics its GTK4 window construction made every launch feel sluggish (~440 ms to map, versus a lightweight terminal's near-instant open), which a head-to-head comparison confirmed.
  The terminal is therefore Alacritty, whose OpenGL renderer opens fast on the iGPU.
  The choice is easily reversible per host, so a capable host such as zeus could still adopt Ghostty later.
 - **Dropped from the plan.**
  Mouse drag-to-move and drag-to-resize (`bindm`) were removed: they fall outside the task's enumerated keyboard bindings, and `resizeactive`/`movewindow` already cover floating windows from the keyboard.
  Hardware media/brightness keys (the spec table's `XF86` row) are likewise deferred, since they depend on audio and backlight tooling not yet in scope.
 - **Added beyond the plan.**
  `Super+Shift+T` toggles the tiling strategy between the dwindle and master layouts, added at the operator's request during review.
  Neither a dispatcher nor a keyword flips the layout on its own, so a small script reads the current layout and sets the other through `hyprctl keyword`.
  It is not in the spec keybind table.
--- a/.claude/tasks/0022-stylix-nord-theming.md
+++ b/.claude/tasks/0022-stylix-nord-theming.md
@@ -1,49 +0,0 @@
 ---
 spec: hyprland-desktop
 blocked-by: 0021-desktop-group-and-hyprland-session
 ---
 ## What to build
 Theme the whole new graphical layer Nord from a single source, and set the wallpaper.
 Add Stylix as a flake input and a desktop theming module that drives colors, system fonts, and cursor from one Nord base16 scheme across the graphical surface (GTK, Qt, and the compositor colors), plus a single static Nord wallpaper set by Stylix.
 Scope Stylix to the graphical layer only: leave its targets for the existing terminal tools (nvim, tmux, fish) off so their established hand-themes stand unchanged.
 The theming is reversible per target, so individual surfaces can migrate toward or away from manual theming later.
 ## Acceptance criteria
 - [x] Stylix is a flake input, wired into the host build.
 - [x] A desktop theming module resolves a single Nord base16 scheme and applies it to GTK, Qt, cursor, and system fonts.
 - [x] A single static Nord wallpaper is set by Stylix; no dynamic, animated, or cycling wallpaper.
 - [x] The Stylix target for nvim is off, leaving its existing theme untouched (narrowed from nvim + tmux + fish during review, see notes).
 - [x] neogaia builds green under `nix flake check`, and an eval probe confirms the resolved scheme is Nord.
 ## Implementation Notes
 - **Wallpaper is a generated Nord gradient, not a shipped image.**
  Stylix requires an `image`, and the spec asks only for "a single static Nord wallpaper".
  Rather than commit a binary blob or fetch one over the network at build time, the module draws a vertical gradient across the Nord Polar Night shades (`#2E3440` → `#3B4252`) with ImageMagick.
  It is static, genuinely Nord, and fully reproducible with no external dependency beyond a cached build tool.
  Swapping in a picture later is a one-line change to `image`.
 - **The nvim target is `nixvim`, not `neovim`.**
  nvim here is configured through nixvim, so the Stylix target that would theme it is `nixvim`.
  Disabling `neovim` would have been a no-op and left nvim themed.
 - **Only nvim is excluded from Stylix (narrowed during review).**
  The task first turned the nvim, tmux, and fish targets all off.
  In review the operator narrowed that to nvim alone, so tmux and fish are now Stylix-managed.
  nvim stays off because its `gbprod/nord.nvim` colorscheme is a purpose-built, treesitter-aware theme, richer than the generic base16 mapping Stylix's neovim target would apply.
  fish had no colour theme of its own, so handing it to Stylix is a clean addition.
  tmux carried a hand-written Nord status bar, so its colour lines are removed from `extra.conf` and Stylix now themes the status and pane styles, while the operator's minimal layout (session name plus window list, empty right side) is kept and reapplied after Stylix so it still wins.
 - **Cursor generation switched on explicitly.**
  home-manager now wants `home.pointerCursor.enable` set explicitly rather than inferring it from the presence of cursor settings, so the module sets it to silence the deprecation and keep the build warning-clean (bar the pre-existing benign nixvim `nixpkgs.follows` notice).
 - **System font pinned to JetBrains Mono.**
  The acceptance criterion asks for "system fonts" without naming one, so the monospace is pinned to JetBrains Mono and the serif/sans/emoji families are left at Stylix's Nord-coherent defaults.
 - **Stylix module imported unconditionally.**
  `lib.nix` adds `inputs.stylix.nixosModules.stylix` to every host's module set, matching how the other input modules are wired.
  It stays inert until `stylix.enable` is set, which only the theming module does, only when the desktop is on.
--- a/.claude/tasks/0023-waybar-status-bar.md
+++ b/.claude/tasks/0023-waybar-status-bar.md
@@ -1,40 +0,0 @@
 ---
 spec: hyprland-desktop
 blocked-by: 0021-desktop-group-and-hyprland-session
 ---
 ## What to build
 A Waybar status bar that reads system state at a glance.
 Add a Waybar module to the desktop group, enabled through the aggregator, showing workspaces with per-application icons plus a clock, battery, network, audio, MPRIS media controls, and a do-not-disturb toggle.
 No overview/exposé plugin: the workspace indicators are sufficient.
 The do-not-disturb toggle and media controls live in the bar rather than in a separate notification center.
 ## Acceptance criteria
 - [x] A Waybar module exists in the desktop group and is enabled by the aggregator.
 - [x] The bar shows workspaces with per-application icons, a clock, battery, network, audio, MPRIS media controls, and a do-not-disturb toggle.
 - [x] No overview/exposé plugin is used.
 - [x] neogaia builds green under `nix flake check`.
 ## Implementation Notes
 - **Audio server added beyond the plan.**
  The task asked only for the bar's audio *widget*, but nothing in the epic provisions an audio server, and a `wireplumber` widget over a machine with no running sink is inert.
  A small `modules/desktop/audio.nix` therefore enables PipeWire (with the ALSA and PulseAudio compatibility shims and rtkit) under its own `modules.desktop.audio.enable`, wired into the aggregator at default priority like every other piece.
  It is a distinct concern that could equally live in its own task, so it is flagged here and in the PR for the operator to split out or keep.
 - **Do-not-disturb depends on mako, which lands later.**
  The `custom/dnd` widget shells out to `makoctl`, whose daemon arrives with the notifications task (0025).
  The status script pins mako's store path and degrades to "notifications on" whenever no daemon answers, so the widget is inert rather than broken before 0025 and reflects real state the moment mako runs.
 - **Glyphs decoded, not pasted.**
  Nerd-font module icons are Private-Use-Area codepoints that do not survive an editor paste, so a `g = code: builtins.fromJSON ''"\u${code}"''` helper decodes each one to real bytes.
  `nerd-fonts.symbols-only` is installed system-wide as the pango fallback for those codepoints, since Stylix's monospace font does not carry them.
 - **Bar launch.**
  The bar runs as a home-manager systemd user service bound to `graphical-session.target`, which uwsm activates, so it comes up with the session without a compositor `exec-once`.
 - **Runtime checks deferred to the machine.**
  `nix flake check` proves the config evaluates and the host builds, but the rendered bar, the MPRIS widget, and the audio widget can only be exercised in a live Wayland session on neogaia.
--- a/.claude/tasks/0024-rofi-launcher.md
+++ b/.claude/tasks/0024-rofi-launcher.md
@@ -1,36 +0,0 @@
 ---
 spec: hyprland-desktop
 blocked-by: 0021-desktop-group-and-hyprland-session
 ---
 ## What to build
 A search-everything launcher, so one keybound tool handles launching and utility menus.
 Add a rofi (Wayland fork) module to the desktop group, enabled through the aggregator, combining application-run, binary-run, and window-switch into one prompt, plus math-evaluation and emoji modes.
 Bind it on `Super+R`.
 Structure it so it is reusable as the dmenu-style frontend for later utility menus (clipboard history, power menu), and provide a power menu that uses it.
 ## Acceptance criteria
 - [x] A rofi module exists in the desktop group and is enabled by the aggregator.
 - [-] rofi combines application-run, binary-run, and window-switch modes, plus math evaluation and emoji.
 - [x] rofi opens on `Super+R`.
 - [x] rofi is usable as a dmenu-style frontend for utility menus, and a power menu is provided through it.
 - [x] neogaia builds green under `nix flake check`.
 ## Implementation Notes
 - `rofi-wayland` no longer exists as a separate package: nixpkgs merged the Wayland fork into `pkgs.rofi` (now 2.0.0).
  The module uses the plain `pkgs.rofi`, which is the Wayland-capable build.
 - Criterion 2 is deliberately reduced (`[-]`): the launcher is application-launch only, `modi = "drun"`, opened with `rofi -show drun` on `Super+R`.
  Binary-run, window-switch, math (`rofi-calc`) and emoji (`rofi-emoji`) were all dropped at the operator's direction, and the two plugins removed with them, to keep the prompt as fast and uncluttered as possible.
  This narrows the parent spec's "search-everything launcher" (user story 7) to a plain application launcher — a reversible choice, since any mode or plugin can be added back later.
  Application icons are disabled too (`show-icons = false`), since resolving an icon per entry is the largest part of drun's per-launch startup and rofi runs no resident daemon to amortise it.
 - The dmenu-style reuse is the themed rofi itself, not a separate abstraction: any `rofi -dmenu` invocation reads the same config and Stylix theme, so the power menu — and later clipboard/utility menus — look uniform for free.
 - The launcher and power-menu keybinds live in this module rather than in `hyprland.nix`, contributed through `settings.bind`, which the module system concatenates with the compositor's own binds in the single `hyprland.conf`.
  This keeps each command next to its binding and referenced by store path, so a rename cannot silently break the bind.
 - The power menu is bound to `Super+Shift+X`, chosen by the operator.
  It pairs with lock on `Super+X` (a key the spec's table does list), while the parent spec's table has no power-menu key of its own.
 - No Waybar `window-rewrite` icon mapping was added: rofi renders as a Wayland layer-shell overlay, not a tiled window with a class on a workspace, so it never appears on the workspace indicator the convention governs.
 - The launcher's quick appearance is a Hyprland change, not a rofi one: layer surfaces get their own `layersIn`/`fadeLayersIn` fade at `2`, a step quicker than the `3` windows use, so the launcher fades in without feeling laggy.
--- a/.claude/tasks/0025-mako-notifications.md
+++ b/.claude/tasks/0025-mako-notifications.md
@@ -1,42 +0,0 @@
 ---
 spec: hyprland-desktop
 blocked-by: 0021-desktop-group-and-hyprland-session
 ---
 ## What to build
 Notification toasts with do-not-disturb and history recall, so missed notifications can be retrieved.
 Add a mako module to the desktop group, enabled through the aggregator, rendering notification toasts with a do-not-disturb mode and history recall.
 The do-not-disturb toggle and media controls live in the bar, not in a separate notification-center panel.
 ## Acceptance criteria
 - [x] A mako module exists in the desktop group and is enabled by the aggregator.
 - [x] Notification toasts appear, with do-not-disturb and history recall.
 - [x] No separate slide-out notification-center panel is added.
 - [x] neogaia builds green under `nix flake check`.
 ## Implementation Notes
 - **Bar side already in place.**
  The do-not-disturb toggle (`custom/dnd`, calling `makoctl mode -t dnd`) and the MPRIS media controls already live in `modules/desktop/waybar.nix` from task 0024.
  This task therefore adds only the daemon: `modules/desktop/mako.nix` enables `services.mako` through home-manager and is turned on by the aggregator.
  The mode name is `dnd` on both sides, so the bar's toggle and the daemon's `[mode=dnd]` section agree.
 - **Colors from Stylix.**
  Stylix ships a mako target that drives the background, border, text, and progress colors plus the popup font from the one Nord base16 scheme, so the module sets no colors — only behaviour.
  This mirrors how `rofi.nix` and `theming.nix` defer their palettes to Stylix.
 - **Do-not-disturb keeps history.**
  The `[mode=dnd]` section sets `invisible=true`, which hides toasts while still recording them, so notifications missed during do-not-disturb remain retrievable.
 - **History recall keybind.**
  `Super+N` runs `makoctl restore`, popping the last notification back from history keyboard-only, consistent with the rest of the session.
  `N` is unused by the spec keybind table, and task 0021 established that each later task adds its own binding rather than 0021 binding to a then-missing tool.
 - **No Waybar icon mapping.**
  The window-rewrite convention covers graphical apps whose windows appear on the workspace indicator; mako renders toasts as a layer-shell overlay with no tiled window and no `hyprctl clients` entry, so there is nothing to match on.
 - **Dropped from the plan.**
  A `Super+Shift+N` dismiss-all binding was drafted alongside the recall bind but removed as unrequested scope: the acceptance criteria call for history recall, which `restore` alone serves.
--- a/.claude/tasks/0026-hyprlock-and-hypridle.md
+++ b/.claude/tasks/0026-hyprlock-and-hypridle.md
@@ -1,46 +0,0 @@
 ---
 spec: hyprland-desktop
 blocked-by: 0021-desktop-group-and-hyprland-session
 ---
 ## What to build
 A secure lock screen and idle management, so going idle, suspending, or closing the lid always lands at a locked screen.
 Add hyprlock and hypridle modules in the Hyprland-native subdirectory of the desktop group, enabled through the aggregator.
 hyprlock uses the compositor session-lock protocol so the lock surface is owned by the compositor and survives a locker crash.
 hypridle is wired for lock-on-idle, screen-off, lock-before-suspend, and lid-close, with tunable timeouts.
 Bind lock on `Super+X`.
 ## Acceptance criteria
 - [x] hyprlock and hypridle modules exist in the Hyprland-native subdirectory and are enabled by the aggregator.
 - [x] hyprlock uses the compositor session-lock protocol.
 - [x] hypridle triggers lock-on-idle, screen-off, lock-before-suspend, and lid-close, with tunable timeouts.
 - [x] Lock is bound on `Super+X`.
 - [x] neogaia builds green under `nix flake check`.
 ## Implementation Notes
 - **hyprlock is inherently the session-lock client.**
  Criterion 2 needs no option: hyprlock draws its surface through the ext-session-lock protocol, so the compositor owns the surface and it survives a crash of the locker.
  The module therefore carries only geometry and behaviour.
 - **Stylix themes the lock screen.**
  Colors and the lock background come from Stylix's hyprlock target, which merges into the same `background` and `input-field` blocks, so the module sets only field geometry and a `$TIME` label.
 - **lid-close is wired through logind, not a hypridle listener.**
  hypridle cannot observe lid events, so the module sets `services.logind.settings.Login.HandleLidSwitch = "suspend"`, and the shared `before_sleep_cmd` locks ahead of the suspend.
  The lid therefore lands at a locked screen, satisfying the criterion by outcome even though the trigger is logind's.
 - **`Super+X` is self-contained.**
  The keybind execs a guarded hyprlock launch directly (`pidof hyprlock || hyprlock`) rather than `loginctl lock-session`, so the lock key works whenever hyprlock is enabled, without depending on hypridle being the running lock handler.
  hypridle's own idle and suspend paths still funnel through `loginctl lock-session` so logind tracks the locked state on those paths.
 - **Idle-suspend was left out.**
  The spec enumerates lock-on-idle, screen-off, lock-before-suspend, and lid-close, so hypridle does not itself suspend on idle.
  `before_sleep_cmd` handles lock-before-suspend for the lid and any manual or externally configured suspend.
  Adding an idle-suspend stage is a reasonable future knob but was not requested here.
 - **One hyprlock package.**
  Both the keybind and hypridle's `lock_cmd` reference `programs.hyprlock.package`, so the locker never splits versions between the two call sites.
--- a/.claude/tasks/0027-cliphist-clipboard-history.md
+++ b/.claude/tasks/0027-cliphist-clipboard-history.md
@@ -1,32 +0,0 @@
 ---
 spec: hyprland-desktop
 blocked-by: 0024-rofi-launcher
 ---
 ## What to build
 Clipboard history picked entirely by keyboard.
 Add a cliphist module (with wl-clipboard) to the desktop group, enabled through the aggregator, storing both text and image history and picked through rofi.
 Bind the picker on `Super+Shift+V`.
 ## Acceptance criteria
 - [x] A cliphist module (with wl-clipboard) exists in the desktop group and is enabled by the aggregator.
 - [x] Text and image copies are recorded to history.
 - [x] The history is picked through rofi and bound on `Super+Shift+V`.
 - [x] neogaia builds green under `nix flake check`.
 ## Implementation Notes
 - The module is named `clipboard`, not `cliphist`: cliphist is the tool it is built on, but the option a host enables names the capability.
 - The two clipboard watchers are not hand-written: home-manager's `services.cliphist` module runs them as a pair of systemd user services, one for text and one for `--type image`.
  `allowImages` defaults true, so enabling the service alone records both kinds.
 - That module installs only `cliphist` on PATH and reaches `wl-clipboard` by store path, so `wl-copy`/`wl-paste` are added to `home.packages` here.
  The spec asks for the module "with wl-clipboard", and a keyboard-driven session wants the two commands for piping to and from the clipboard.
 - The services bind to `graphical-session.target`, which uwsm starts, matching how mako and hypridle attach to the session on this host.
  No `systemdTargets` override is needed, since the module's default already resolves to that target.
 - The picker is a small shell script over the same themed rofi the launcher uses (`cliphist list | rofi -dmenu | cliphist decode | wl-copy`), so history looks like every other menu.
  Its keybind lives in this module rather than in `hyprland.nix`, contributed through `settings.bind`, keeping the command next to its binding and referenced by store path.
 - No Waybar `window-rewrite` icon mapping was added: the watchers are headless daemons and the picker is a rofi layer surface, so nothing new ever appears as a tiled window on the workspace indicator the convention governs.
 - Image entries render as a `[[ binary data … ]]` placeholder line in the rofi list rather than a thumbnail, but selecting one still decodes and re-copies the real image, so both kinds are retrievable.
--- a/.claude/tasks/0028-screenshot-capture.md
+++ b/.claude/tasks/0028-screenshot-capture.md
@@ -1,35 +0,0 @@
 ---
 spec: hyprland-desktop
 blocked-by: 0021-desktop-group-and-hyprland-session
 ---
 ## What to build
 Keyboard-driven screenshots that open in an annotation editor by default and land in both the clipboard and a file.
 Add a screenshot module to the desktop group, enabled through the aggregator, using grim and slurp wrapped by grimblast and routed through the satty annotation editor so annotation is the default.
 Cover region, active-window, and full-screen captures, each exporting to both the clipboard and a file.
 Bind region on `Super+L`, active window on `Super+Shift+L`, and full screen on `Super+Ctrl+L`.
 ## Acceptance criteria
 - [x] A screenshot module exists in the desktop group and is enabled by the aggregator.
 - [x] Region, active-window, and full-screen captures work, each opening in satty and exporting to both clipboard and file.
 - [-] Captures are bound on `Super+L`, `Super+Shift+L`, and `Super+Ctrl+L`.
 - [x] neogaia builds green under `nix flake check`.
 ## Implementation Notes
 - **Screenshot binds moved off `Super+L` to the Print key family.**
  Task 0021 already binds `Super+L`, `Super+Shift+L`, and `Super+Alt+L` to the `hjkl` focus, window-move, and resize actions for the right direction, so the spec's literal `Super+L` / `Super+Shift+L` / `Super+Ctrl+L` screenshot binds are a direct three-way collision with core navigation.
  Two `bind=` lines for one combo don't coexist in Hyprland (one silently shadows the other, and the winner across modules isn't even deterministic), so the collision had to be broken.
  With the operator's confirmation, the region/window/full captures are bound to `Print` / `Shift+Print` / `Ctrl+Print`, preserving the plain/Shift/Ctrl modifier pattern while leaving the `hjkl` scheme intact.
  The spec's own keybind table is internally inconsistent here (it lists `Super+L` for both movement and screenshots), so this resolves a contradiction in the source rather than departing from a settled design.
 - **Capture pipeline.**
  `grimblast save <area|active|screen> -` captures to stdout and pipes into satty, whose copy action is configured with `--copy-command wl-copy --save-after-copy`, so one confirmation lands the shot in both the clipboard and a dated file under `~/Pictures/Screenshots`.
  `--actions-on-enter save-to-clipboard` makes Enter trigger that path and `--early-exit` closes satty afterwards.
  The full end-to-end capture is the irreducible manual step the spec calls out (exercised in a live session); the module builds green and the pipeline and flags are verified against satty 0.21.1.
 - **No waybar icon for satty.**
  The repo convention adds a `window-rewrite` mapping for each graphical application, but satty is a transient floating annotation window rather than a window that lives on a workspace, so at the operator's direction it gets no workspace glyph.
--- a/.claude/tasks/0029-screen-recording.md
+++ b/.claude/tasks/0029-screen-recording.md
@@ -1,42 +0,0 @@
 ---
 spec: hyprland-desktop
 blocked-by: [0023-waybar-status-bar, 0025-mako-notifications]
 ---
 ## What to build
 A keybound screen recorder that selects a region and then toggles recording.
 Add a wf-recorder module to the desktop group, enabled through the aggregator, that selects a region first and then toggles video-only recording (no audio), bound on `Super+Shift+R`.
 Surface a recording indicator in the Waybar bar and notification toasts on start and stop.
 No audio capture and no full-screen recording variant.
 ## Acceptance criteria
 - [x] A wf-recorder module exists in the desktop group and is enabled by the aggregator.
 - [x] The recorder selects a region first, then toggles video-only recording on `Super+Shift+R`.
 - [x] A recording indicator appears in the bar, and notifications fire on start and stop.
 - [x] No audio is captured and no full-screen variant is provided.
 - [x] neogaia builds green under `nix flake check`.
 ## Implementation Notes
 - **Toggle design.**
  One key both starts and stops.
  A running capture is stopped with SIGINT so wf-recorder finalises the file; otherwise slurp picks a region and wf-recorder runs in the foreground for the whole recording, so the same invocation fires the "saved" notification once the file is written.
  Region-first and video-only (no `-a`, so no audio) satisfy the spec directly, and no full-screen variant is offered.
 - **Bar indicator polls rather than signals.**
  The Waybar `custom/recording` widget samples the wf-recorder process with `pgrep` on a one-second interval, showing a video glyph while a capture runs and collapsing to nothing when idle.
  An earlier draft signalled Waybar (`pkill -RTMIN+9`) from the toggle, but the start path raised the signal before wf-recorder had launched, so `pgrep` saw nothing and the indicator never lit during a recording — caught in review.
  Polling is race-free, removes the signal number shared across two files, and is adequate for a status glyph.
 - **No waybar `window-rewrite` icon.**
  wf-recorder is headless and slurp is a transient selection overlay, so neither owns a workspace window and the per-application icon convention does not apply.
 - **Output paths follow XDG user-dirs.**
  A new `modules.desktop.userdirs` declares the XDG user directories (home-manager `xdg.userDirs`), and the recorder resolves its base with `xdg-user-dir VIDEOS`, writing timestamped `recording-<date>.mp4` under `<Videos>/Recordings` (created on first capture).
  The screenshot module (task 0028) was aligned to the same convention (`xdg-user-dir PICTURES` → `<Pictures>/Screenshots`), so relocating a directory is a one-line change to `xdg.userDirs` rather than an edit in each tool.
 - **Live capture is the irreducible manual step.**
  The build is green, the config parses under `Hyprland --verify-config`, and the indicator's idle/recording transitions are verified against a stand-in process; exercising a real slurp selection and wf-recorder capture needs a running session.
--- a/.claude/tasks/0030-desktop-portals.md
+++ b/.claude/tasks/0030-desktop-portals.md
@@ -1,35 +0,0 @@
 ---
 spec: hyprland-desktop
 blocked-by: 0021-desktop-group-and-hyprland-session
 ---
 ## What to build
 Screen sharing that works inside applications, so video calls and browser screen-share function.
 Add a portals module to the desktop group, enabled through the aggregator, wiring the Hyprland desktop portal (screencast, screenshot, global shortcuts) plus the GTK portal (file dialogs and appearance).
 In-app screen sharing depends on these regardless of whether the recorder is present.
 ## Acceptance criteria
 - [x] A portals module exists in the desktop group and is enabled by the aggregator.
 - [x] The Hyprland desktop portal (screencast, screenshot, global shortcuts) and the GTK portal (file dialogs, appearance) are both configured.
 - [x] In-app screen sharing is available independent of the screen recorder.
 - [x] neogaia builds green under `nix flake check`.
 ## Implementation Notes
 - **The module owns routing, not the backend packages.**
  The Hyprland compositor integration (`programs.hyprland`) already forces both portal backends into `xdg.portal.extraPortals` — `xdg-desktop-portal-hyprland` through its `portalPackage`, and `xdg-desktop-portal-gtk` through nixpkgs' `wayland-session.nix` (`enableGtkPortal` defaults on) — and turns `xdg.portal.enable` on.
  A portal backend only answers while its compositor runs, so those packages belong with the compositor and cannot be removed there; re-declaring them here would only duplicate them.
  The genuinely-missing, first-class piece was the routing: `xdg.portal.config` was empty, and which backend answered each request rode on a config file the Hyprland package happens to ship (`hyprland-portals.conf`, `default=hyprland;gtk`).
  This module makes that routing explicit and declarative.
 - **Per-interface routing, not a preference list.**
  Rather than `default = [ "hyprland" "gtk" ]` (which tries Hyprland first for every interface and falls through to GTK), the three interfaces the Hyprland portal actually implements — `ScreenCast`, `Screenshot`, `GlobalShortcuts`, confirmed from its `hyprland.portal` file — are routed to Hyprland explicitly, and GTK is the default for everything else.
  This directly encodes the spec's split (Hyprland for the screen-facing requests, GTK for file dialogs and appearance) and keeps appearance on GTK even if a future Hyprland portal starts implementing `org.freedesktop.impl.portal.Settings`.
 - **Already functional, now first-class.**
  Because the compositor integration already supplied both backends and a working shipped route, in-app screen sharing was effectively working before this task as an implicit side-effect.
  The deliverable is the explicit, aggregator-enabled `modules.desktop.portals` module, so the desktop's checklist reads completely and screen sharing no longer depends on a package's incidental default.
  Verified: the built config emits `/etc/xdg/xdg-desktop-portal/portals.conf` with `default=gtk` plus the three Hyprland routes, and neogaia's toplevel builds green.
--- a/.claude/tasks/0031-module-namespace-tidy.md
+++ b/.claude/tasks/0031-module-namespace-tidy.md
@@ -1,29 +0,0 @@
 ## What to build
 Tidy the module tree so a Module's option namespace mirrors its directory under `modules/`, adopt that as a documented convention, group the agent-related Modules under a new `agents/` directory, bring `desktop/hyprland/` into conformance, and drop the obsolete reference Module.
 The convention: a Module's option path mirrors its directory path, and a file whose name matches its directory is that directory's index node — it declares the directory's own segment (its `enable`/aggregator) rather than a doubled segment. A file `foo.nix` in directory `d/` declares `modules.<…>.d.foo`. A group directory with no matching index file contributes a namespace segment but no aggregate `enable`.
 Applying it:
 - **Agents grouping.** Relocate the agent Modules under `modules.agents.*`: `claude-code` (its whole directory, assets included) → `modules.agents.claude-code`; `pi` flattened from its directory to a single file → `modules.agents.pi`; the skills Module renamed from `agent-skills` → `agents/skills.nix`; and `gitea-axi` into an `agents/tools/` subgroup → `modules.agents.tools.gitea-axi`. `tools/` is a real namespace segment, not a cosmetic folder.
 - **No aggregators.** `agents/` and `tools/` are pure namespace prefixes — no `modules.agents.enable` or `modules.agents.tools.enable`. Agents are enabled à la carte.
 - **Skills stays enable-less.** The skills Module keeps its current behaviour (unconditionally wires `programs.agents.skills`, empty list); it is the one deliberate exception to the Enable convention, marked as intentional by a self-contained comment in the file.
 - **Desktop conformance.** Nest `hypridle` and `hyprlock` under `modules.desktop.hyprland.*` (matching the index-file rule, `hyprland.nix` being the index), and update `desktop.nix`'s aggregator to the new paths. The 13 flat `desktop/*.nix` Modules keep their `modules.desktop.<name>` names — broader semantic regrouping is explicitly out of scope for this task.
 - **Remove the example Module.** Delete `modules/example.nix`; the documented convention and the many real Modules supersede its teaching role.
 Also update the one Host that carries these Modules and the live documentation, and record the convention in the domain model.
 ## Acceptance criteria
 - [x] `CONTEXT.md` gains a `Namespace convention` glossary entry stating the directory-mirrors-namespace rule and the index-file rule, in glossary style (no implementation detail).
 - [x] An ADR (next number: `0004`) records the decision — nested-mirrors-directory over flat names, a subfolder as a real namespace segment, the index-file rule, and no `agents` aggregator — following the ADR format.
 - [x] Agent Modules resolve under `modules.agents.*`: `modules.agents.claude-code.enable`, `modules.agents.pi.enable`, and `modules.agents.tools.gitea-axi.enable` exist; `modules.claude-code`, `modules.pi`, and `modules.gitea-axi` no longer resolve.
 - [x] The skills Module lives at `agents/skills.nix` (renamed from `agent-skills.nix`), stays enable-less, still wires `programs.agents.skills`, and carries an in-file comment marking the Enable-convention exception as intentional.
 - [x] Neither `modules.agents.enable` nor `modules.agents.tools.enable` exists (pure namespace prefixes, no aggregator).
 - [x] `claude-code`'s assets (`CLAUDE.md`, `authentication.md`, `hooks/`, `skills/`) travel with the move and its relative references still resolve.
 - [x] `desktop/hyprland/`: `modules.desktop.hyprland.hypridle` and `modules.desktop.hyprland.hyprlock` resolve; the old `modules.desktop.hypridle`/`modules.desktop.hyprlock` no longer exist; `desktop.nix` enables the new paths; `modules.desktop.enable` still brings up the whole session.
 - [x] `modules/example.nix` is removed and `modules.example` no longer resolves.
 - [x] `hosts/neogaia/default.nix` uses the new option paths for claude-code, pi, and gitea-axi.
 - [x] The two live `CLAUDE.md` gotchas — the `gitea-axi` install line and the `claude-code` skill-source path — are updated to the new option/path; `.claude/tasks/*` are left unchanged as historical record.
 - [x] `nix flake check` builds `checks.x86_64-linux.neogaia` green (moved files staged so evaluation sees them).
--- a/.claude/tasks/0032-firefox-browser.md
+++ b/.claude/tasks/0032-firefox-browser.md
@@ -1,71 +0,0 @@
 ---
 spec: firefox
 ---
 ## What to build
 Add Firefox as a new single-purpose Module under the desktop group, configured entirely through the primary user's home-manager `programs.firefox`, and fold it into the desktop aggregator so the browser comes up as part of the daily-drivable session on any Host that enables the desktop.
 The browser is stock mainline Firefox, hardened and de-monetized through locked enterprise policies, carrying a small fixed set of extensions force-installed by policy from Mozilla's add-on site.
 Search defaults to DuckDuckGo over a lean, pruned engine list.
 The browser is themed Nord from the same single Stylix source as the rest of the graphical layer, and registered as the system default handler for web links.
 Bookmarks and container tabs are deliberately not declared, leaving that state to the browser's own runtime management.
 The end-to-end result: a Host with the desktop enabled boots into a session where the browser is present, launchable, themed to match, telemetry-quiet, has its extensions installed and enabled on first launch, uses DuckDuckGo, and receives links opened from other applications.
 Scope details, all following the domain conventions (Namespace convention, Enable convention, aggregator fan-out):
 - **Module and placement.** One `enable` option namespaced to mirror the file's location under the desktop group, guarded by the Enable convention. Configured only through home-manager `programs.firefox`; no NixOS-level Firefox program integration and no manual package override. The desktop aggregator turns it on at default priority alongside the terminal, so the single desktop flag brings it up while a Host can still override it.
 - **Package and extensions.** Stock mainline Firefox, not ESR/unbranded/Developer Edition. The three extensions — an ad and content blocker, the operator's password manager, and a video sponsor-skipper — are installed through the enterprise `force_installed` policy keyed by add-on id with an install URL, so Firefox fetches the signed add-on and enables it automatically. No Nix-built or hash-pinned add-on packages, and no native messaging host.
 - **Hardening.** Split by intent: policy-backed items are set as locked policies (telemetry, studies, and data reporting off; read-it-later widget off; offer-to-save-logins off; default-browser check off; sponsored shortcuts, stories, and snippets stripped from the new-tab page; Firefox accounts and sync disabled), and the rest as ordinary profile preferences (sponsored address-bar suggestions off, new-tab surface tidied). Fingerprinting resistance stays off.
 - **Search.** A single profile, named the default. DuckDuckGo as the default engine, the engine list pruned to a lean set with the general-purpose commercial engines removed, using the module's authoritative-overwrite acknowledgement.
 - **Theming.** Enable the Stylix Firefox target against the declared profile, driven from the shared Nord scheme, set from within this Module (mirroring how the theming Module already sets per-Module Stylix targets). No hand-written browser chrome CSS.
 - **Default browser.** Register Firefox as the default handler for the web-link schemes and HTML through the user's home-manager mime-association config, placed in this Module.
 Record the pivotal, hard-to-reverse decision — stock Firefox plus policy-installed extensions over an ESR/unbranded build with hash-pinned add-on packages — as an ADR, following the ADR format and the next ADR number.
 ## Acceptance criteria
 - [x] A new Firefox Module exists under the desktop group with a single `enable` option, namespaced to mirror its directory per the Namespace convention and guarded per the Enable convention; `modules.desktop.firefox.enable` resolves.
 - [x] The Module is configured only through the primary user's home-manager `programs.firefox`; there is no NixOS-level Firefox program integration and no manual package override.
 - [x] The desktop aggregator enables the Module at default priority, so `modules.desktop.enable` brings the browser up and a Host can still override the single flag; neogaia carries it through the desktop flag with no per-Host browser line.
 - [x] The package is stock mainline Firefox (not ESR, unbranded, or Developer Edition).
 - [x] The three extensions are force-installed via enterprise policy keyed by add-on id with an install URL: the ad and content blocker, the password manager, and the video sponsor-skipper; no native messaging host is declared.
 - [x] Locked policies turn off telemetry, studies, and data reporting; turn off the read-it-later widget; stop offer-to-save-logins; stop the default-browser check; strip sponsored shortcuts, stories, and snippets from the new-tab page; and disable Firefox accounts and sync.
 - [x] Profile preferences turn off sponsored address-bar suggestions and tidy the new-tab surface; fingerprinting resistance is left off.
 - [x] A single default profile is declared with DuckDuckGo as the default search engine and the engine list pruned to a lean set (general-purpose commercial engines removed), using the search authoritative-overwrite acknowledgement.
 - [x] The Stylix Firefox target is enabled against the declared profile from within this Module, driven from the shared Nord scheme; no hand-written browser chrome CSS is shipped.
 - [x] Firefox is registered as the default handler for the web-link schemes and HTML through the user's home-manager mime-association config.
 - [x] An ADR (next number) records the stock-Firefox-plus-policy-extensions decision over an ESR/unbranded build with hash-pinned add-on packages, following the ADR format.
 - [x] `nix flake check` builds `checks.x86_64-linux.neogaia` green, with the new file staged so evaluation sees it.
 - [-] Manual confirmation on neogaia: after switching, the browser launches with the three extensions present and enabled, the Nord theme applied, DuckDuckGo as default search, and a link opened from another application lands in it.
 ## Implementation Notes
 The module lives at `modules/desktop/firefox.nix`, declares `modules.desktop.firefox.enable`, and is fanned out by the desktop aggregator at `lib.mkDefault true`.
 Everything is configured through `home-manager.users.<user>.programs.firefox`, with no NixOS-level program integration and no `package` override, so it stays on stock `pkgs.firefox` (built as `firefox-152.0.6`, the mainline release train).
 The three force-installed extensions are keyed by their real add-on ids, verified against Mozilla's AMO API rather than guessed: uBlock Origin (`uBlock0@raymondhill.net`), Proton Pass (`78272b6fa58f4a1abaac99321d503a20@proton.me`), and SponsorBlock (`sponsorBlocker@ajay.app`).
 Proton Pass is the operator's password manager, per ADR 0002 and the sops spec.
 Search pruning deviated from a first pass that merely omitted the commercial engines.
 Omission does not remove them: home-manager's search module writes `search.json.mozlz4`, but Firefox reconciles its locale's app-provided engines back in for any not present in the file, so the general-purpose commercial engines would reappear.
 The lean set is instead reached by explicitly hiding them with `<engine>.metaData.hidden = true` (the module's documented builtin-hiding idiom), confirmed by decoding the built `search.json.mozlz4`: it carries `_metaData.hidden` on google, bing, ebay, and amazon, with `defaultEngineId = "ddg"`.
 DuckDuckGo and Wikipedia remain visible; the hidden engines stay reachable through DuckDuckGo bangs.
 Engines are referenced by their current id form (`ddg`, `google`, …), which the module maps from the old display names — `default = "ddg"` is correct, not `"DuckDuckGo"`.
 The decision to ship stock Firefox with policy-installed extensions over an ESR/unbranded build with hash-pinned add-ons is recorded as ADR 0005.
 The final acceptance criterion is marked `[-]` rather than `[x]`: it is the irreducible manual confirmation the spec calls out (a browser cannot self-test headless), deferred to the operator on the live machine after switching, not dropped work.
 Every automatable check — the whole-Host toplevel build, and eval probes for the aggregator fan-out, the three force-installed ids, the DuckDuckGo default, the hidden commercial engines, the Stylix Firefox target, and the mime handlers — passes.
 ### Follow-ups from the manual confirmation
 The manual launch surfaced two runtime problems the build could not, both since fixed and verified by deploying the home generation.
 Home-manager activation was failing outright: Firefox writes `~/.config/mozilla/firefox/profiles.ini` itself on first launch, and home-manager refuses to clobber the pre-existing file, so the whole generation failed and the declarative profile never deployed — search and theming were absent while the policy-driven extensions and mime handlers, which do not touch the profile, still worked.
 Fixed by setting `force = true` on the generated `profiles.ini` home.file entry so home-manager owns it and deploys the `default` profile.
 The base Stylix Firefox target themes only fonts and the reader view, not the toolbar and tabs, so the chrome did not look Nord.
 Fixed by enabling `stylix.targets.firefox.colorTheme`, which recolours the chrome from the shared scheme through the Stylix-managed Firefox Color add-on, with `profiles.default.extensions.force = true` to acknowledge the managed extension-settings store.
 ADR 0005 is updated to scope its no-pinned-add-on rule to the functional extensions and record the signed theming add-on as a deliberate exception.
--- a/CLAUDE.md
+++ b/CLAUDE.md
@@ -2,7 +2,6 @@
 One flake that builds every machine the user owns.
 The domain model (Host, Module, Skeleton, Auto-loader, Enable convention, overlays) lives in `.claude/CONTEXT.md`.
 The current deliverable's spec is `.claude/spec/laptop-mvi.md`.
 ## Conventions
@@ -22,25 +21,13 @@ The current deliverable's spec is `.claude/spec/laptop-mvi.md`.
 - This repo is developed on `neogaia`, which now runs the NixOS it builds.
  Flakes and the chaotic substituter come from this flake's own `nix.settings`, so no `NIX_CONFIG` export or per-command `--extra-experimental-features` is needed, and building a toplevel with `boot.kernelPackages = linuxPackages_cachyos` fetches the kernel from `nyx-cache` rather than compiling it.
  Both were true only while the machine still ran CachyOS against a distro Nix daemon.
 - The substituters a `nix build` fetches from are the **daemon's** (`/etc/nix/nix.conf`), *not* the `nix.settings` of the config being built — those only govern the built system.
  The two coincide here because the dev host runs this flake.
  They diverge on any machine that does not.
 - Git identity is declared in the flake by `modules/git.nix`, which writes `alexion <contact@alexion.dev>` — the identity all history uses — on any host enabling `modules.git`.
  Every new host has to enable it, so that a host reads as a full checklist of what it carries.
  It is deployed on `neogaia` and verified: a commit in a repository outside this checkout is authored `alexion <contact@alexion.dev>` with no override.
  Verify it that way rather than from this checkout, whose `.git/config` carries the same identity and would mask a broken module.
-  Home-manager writes `~/.config/git/config`, and `~/.gitconfig` is a second global file that git also reads, outranking it on any key set in both.
+  `~/.gitconfig` (a second global file that outranks the flake-managed `~/.config/git/config`) currently holds only a `tea` credential helper and no `user.*`, so it does not shadow the identity, but it is undeclared and will not survive a reimage.
  `~/.gitconfig` currently holds only a `tea` credential helper and no `user.*`, so it does not shadow the identity, but it is undeclared and will not survive a reimage.
 - `git config --global` is a listing and writing filter over `~/.gitconfig` alone, **not** a view of what git resolves.
  With both global files present it prints only `~/.gitconfig`, which reads as proof that `~/.config/git/config` is being ignored entirely.
  It is not: drop `--global` and both files appear, each key resolving to the last file that sets it.
  A `git config --global <key> <value>` write also lands in `~/.gitconfig`, the file that outranks the flake-managed one.
 - The primary build/verify seam for any Host is `nix flake check`, which builds `checks.x86_64-linux.<host>` (the system toplevel).
  Cheap targeted checks use `nix eval .#nixosConfigurations.<host>.config...`.
 - A flake only sees **git-tracked** files, so a new file that has not been `git add`ed is invisible to evaluation even though it exists on disk.
  The failure names the path and reads as if the file were missing: `error: Path 'secrets/shared.yaml' does not exist in Git repository`.
  Staging is enough.
  The file need not be committed.
 - chaotic-nyx must **not** follow our `nixpkgs`, and its packages are built against chaotic's own pinned nixpkgs (its overlay defaults to `onTopOf = "flake-nixpkgs"`, the cache-friendly path).
  That is what lets the `nyx-cache.chaotic.cx` binary cache hit instead of compiling the CachyOS kernel from source.
  The tradeoff is that chaotic packages do not see our `unstable`/`stable` overlays.
@@ -55,79 +42,20 @@ The current deliverable's spec is `.claude/spec/laptop-mvi.md`.
  Review comments are **not** at `/issues/<n>/comments` — that endpoint holds only top-level discussion and is usually empty.
  Inline comments need two calls: `/pulls/<n>/reviews` for the review ids, then `/pulls/<n>/reviews/<id>/comments` for the bodies, whose `path` and `diff_hunk` fields say what each one is attached to.
  A review row with an empty `body` is the normal shape when the operator left only inline comments.
- SSH **host** keys (`ssh_host_<type>_key`, served by the daemon from `/etc/ssh` or a secret) are not user authentication keys (`~/.ssh/id_ed25519`, offered to a remote server).
+- `~/.claude/skills` is home-manager-generated (`recursive = true`), so editing a skill in place fails and a new file created there silently escapes the repo.
-  The `ssh_host_` prefix is OpenSSH's own name for the former, and the `root@<host>` trailing field in a `.pub` is a free-text comment stamped by `ssh-keygen` at generation time, not a claim about which account uses the key.
+  Its real source is `modules/agents/claude-code/skills/<name>/`, applied by a rebuild.
  On this machine the two are provably distinct: the daemon presents `SHA256:2ysuBX0+Z6GbdCTujz5JHX6rqnJzIyWhYNrxdhhGwEM`, while pushes to `git.alexion.dev` authenticate with `SHA256:nEhHwtHDnLlsuFxyfp+cETgHUZ8xDMxaPVmYM5vuCkA`.
  Renaming host keys after user keys, or vice versa, is therefore always wrong.
 - `~/.claude/skills` is generated by home-manager with `recursive = true`, so the directories are real and writable but every leaf file is a read-only symlink into the store.
  Editing a skill in place fails.
  Its source is `modules/agents/claude-code/skills/<name>/` here, applied by a rebuild.
  Creating a new file under `~/.claude/skills/` succeeds silently and is the trap — it stays outside the repo and reaches no other machine.
  Copying out of that tree needs `cp -rL` plus `chmod -R u+w`: a plain `cp -r` copies the symlinks, putting store paths into the destination, and dereferenced files keep the store's read-only mode.
 - `home-manager.users.<user>.home.file` is keyed by whatever path string the **defining module wrote**, absolute or relative, not by one canonical form.
  A module that writes `home.file."/home/alexion/.claude/CLAUDE.md"` is reachable only at that absolute key, while `programs.firefox` writes relative keys such as `home.file.".config/mozilla/firefox/profiles.ini"` reachable only at the relative form.
  The other form fails with "does not provide attribute", so overriding an entry (e.g. setting `.force = true` on it) requires matching the writer's exact key.
  List the real keys with `nix eval --json .#nixosConfigurations.<host>.config.home-manager.users.<user>.home.file --apply builtins.attrNames` rather than guessing one.
  A key's `.source` is the input file, whose store path differs from the deployed symlink's target (home-manager copies it to a `hm_`-prefixed path) even though the contents match.
 - nixpkgs `vimPlugins.nord-nvim` is `shaunsingh/nord.nvim` (no `require("nord").setup()`).
  The config wants `gbprod/nord.nvim`, which is packaged as `vimPlugins.gbprod-nord`.
- nixpkgs `vimPlugins.nvim-treesitter` tracks the rewritten `main` branch: there is no `require("nvim-treesitter.configs").setup{ensure_installed,highlight,indent}`.
+- `nixos-generate-config --show-hardware-config` needs root on this machine even just to print: unprivileged it dies at `Failed to retrieve subvolume info for /`, because the root filesystem is btrfs.
-  Under nixvim, use `plugins.treesitter` with `highlight.enable`/`indent.enable` and `grammarPackages = with config.programs.nixvim.plugins.treesitter.package.builtGrammars; [ ... ]` — the module's own `package.builtGrammars`, **not** `pkgs.vimPlugins.nvim-treesitter.*` (whose query files can mismatch).
+- This repo's claude-code module sets sudo's credential cache to per-user (`timestamp_type=global`, 60-minute window), so an authentication made in one real terminal counts for the agent's commands.
  The module targets the main branch and enables features via neovim-native APIs (`vim.treesitter.start()`, `require'nvim-treesitter'.indentexpr()`).
 - Neovim is configured via **nixvim** (flake input `nixvim`, consumed as `inputs.nixvim.homeModules.nixvim` added to `home-manager.sharedModules`, config under `home-manager.users.<user>.programs.nixvim`).
  `nixvim.inputs.nixpkgs.follows = "nixpkgs"` is set.
  nixvim then emits a benign eval warning that its pinned nixpkgs differs from the followed one — builds and runs fine, do not "fix" it by dropping the follows.
 - To reference the nixvim-built package's own attrs (e.g. treesitter `builtGrammars`) inside our NixOS module, give `home-manager.users.<user>` the module-function form (`hm: { programs.nixvim = { ... hm.config.programs.nixvim... }; }`), since the outer `config` is the NixOS config, not the home-manager one.
 - The agent's Bash sandbox blocks `sudo` and swallows it into a bare exit 1 with **no stderr**, which looks identical to the command itself failing.
  Re-run with the sandbox disabled to see the real error (`sudo: a password is required`) before diagnosing anything else.
  Separately, `nixos-generate-config --show-hardware-config` needs root on this machine even just to print: unprivileged it dies at `Failed to retrieve subvolume info for /`, because the root filesystem is btrfs.
 - Sudo's credential cache is keyed per user rather than per terminal (`timestamp_type=global`, 60-minute window, declared by the claude-code module), so an authentication made in one terminal counts for commands the agent runs.
  Warming it with `sudo -v` through the agent's own shell — including the `!` prefix — never works: that shell has no controlling terminal, and sudo reports `a terminal is required to read the password`.
  It has to be a separate terminal.
  A `PreToolUse` hook refuses privileged commands while the cache is cold, so a cold cache announces itself instead of stalling.
-  A failure *without* that message is the sandbox, not the cache.
+  A privileged-command failure *without* that message is the sandbox, not the cache.
- An `mkOption` of a list or attribute-set type is **not** mandatory the way a scalar one is.
+- Host GPUs: `neogaia` is Intel, `zeus` (the desktop) is **AMD**, and `raichu` (a headless server) is the only Nvidia machine.
-  Those types carry an `emptyValue`, so an option declared with no `default` and never set evaluates to `[ ]` or `{ }` instead of failing with "option used but not defined".
+  The corrected fact also lives in ADR 0003.
-  A declaration that is genuinely required cannot be expressed by omitting the default — it needs an assertion, or a default chosen so that the silent case is the safe one.
+- This repo's `programs.firefox` `search` (with `force = true`) writes `search.json.mozlz4`.
-  This bites hardest where the empty value is itself dangerous, such as a list of authorized SSH keys, where it means a machine nobody can reach.
+  Omission alone does not prune a built-in engine, since Firefox reconciles its app-provided engines back in, so remove one by listing it with `<engine>.metaData.hidden = true`.
- `home-manager.users.<user>` cannot be assigned twice at the same level in one module: `home-manager.users.${user}.home.packages` alongside `home-manager.users.${user}.programs.x` fails with `error: dynamic attribute 'alexion' already defined`.
+  Engines are referenced by their current id, so the default is `default = "ddg"`, not `"DuckDuckGo"`.
-  The interpolated key makes it a dynamic attribute, which nix will not merge the way it merges static paths.
+  Decode the built file with `mozlz4a -d <search.json.mozlz4>` to check the result.
-  Nest both under a single `home-manager.users.${user} = { ... }`.
+- `home.sessionVariables` do **not** reach the Hyprland session, since UWSM does not source `hm-session-vars.sh`.
- **Verifying a nixvim change headless:** `programs.nixvim.build.package`'s wrapper has **no `-u`**, so running `$OUT/bin/nvim` loads the caller's `~/.config/nvim` (the dev host's real config), *not* the built config — silently.
+  The cursor is therefore set through Hyprland's own `env = KEY,VALUE` in `modules/desktop/hyprland/hyprland.nix`, sourced from `config.stylix.cursor`.
-  To exercise the built config, launch with `-u "$(nix build --no-link --print-out-paths .#…programs.nixvim.build.initFile)"` and a scratch `HOME`/`XDG_CONFIG_HOME`.
+  Bibata ships XCursor format only (no `hyprcursor/` dir), rendered through Hyprland's XCursor fallback, so `XCURSOR_*` and `HYPRCURSOR_*` naming the same theme are both safe.
  `conceallevel` is window-local: set it with `opt_local`/`vim.wo`, never `vim.bo[buf]` (which errors).
 - Host GPUs: `neogaia` is Intel and `zeus` (the desktop) is **AMD**.
  `raichu`, a server with no desktop, is the only Nvidia machine.
  `laptop-mvi.md`'s out-of-scope line calls zeus Nvidia, but that is stale and the document is kept historical and unchanged, so do not infer any host's GPU from it.
  The corrected fact lives in ADR 0003 and the `hyprland-desktop` spec.
 - The home-manager `wayland.windowManager.hyprland` module defaults `configType` to `"lua"` at `home.stateVersion` >= 26.05, writing `hyprland.lua` through an `hl.*` Lua API instead of the native `hyprland.conf`.
  The Lua backend mangles `$mod`-style variables and INI `bind=` strings into invalid Lua (`hl.$mod("SUPER")`), and does not fail the build, since the config is only text.
  Set `configType = "hyprlang"` to get the native `hyprland.conf` whose variable and bind syntax the usual settings are written in.
  Render the file to check which format is in effect: `nix build --print-out-paths .#nixosConfigurations.<host>.config.home-manager.users.<user>.xdg.configFile.\"hypr/hyprland.conf\".source` (only the enabled `configType`'s key exists).
 - An invalid Hyprland dispatcher or config-option name never fails the nix build, since `hyprland.conf` is only text, so it surfaces only when the compositor loads the file at login.
  The build/render check is therefore blind to it, and the real test is a running session (or reading `~/.config/hypr/hyprland.conf` against the running package's own names).
  Two that bit on 0.55.4: the dwindle split actions `togglesplit`, `swapsplit`, and `pseudo` are layout messages reached through the `layoutmsg` dispatcher (`bind = $mod, T, layoutmsg, togglesplit`), not top-level dispatchers, and the old `dwindle:pseudotile` option is gone.
  Confirm names against the pinned package rather than the wiki, whose "latest" drifts from it.
  The config can in fact be checked offline: `Hyprland --verify-config -c <rendered-conf>` parses the file and prints `config ok` or the exact `line N:` error without a running compositor, so a rule change is provable before login rather than only at it.
 - Hyprland 0.55.4 uses windowrule v3 syntax, which is not the `windowrule = float, class:^(re)$` form the wiki still shows.
  A flat `windowrule =` entry is a comma-separated list of `field value` tokens, each of which **must** carry a value: matchers take a `match:` prefix and effects are bare, so floating one app is `windowrule = float 1, match:class ^(com\.gabm\.satty)$`.
  The old form fails at load with `invalid field float: missing a value`, because the effect token has no value.
  `windowrulev2` is removed and errors as deprecated.
 - A multi-path `git add a b c` aborts entirely and stages **nothing** when any one pathspec matches no file, so a stale path in the list silently drops every other file from the commit.
  This bit here: a path already removed by `git rm` was passed to a later `git add`, which failed with `fatal: pathspec ... did not match any files` and staged none of the real edits beside it, landing a commit that moved files but kept the old option paths.
  Stage in separate `git add` calls, or `git status` the result before committing rather than trusting the add.
 - A `nix build` or `nix flake check` on a **dirty** tree evaluates the working-copy content of tracked files, not what is committed, and only warns `Git tree ... is dirty`.
  A green check on a dirty tree therefore proves nothing about the commit.
  To verify a commit, build once on a clean tree (nothing uncommitted), where the absence of the dirty warning confirms the build reflects `HEAD`.
 - home-manager's `programs.firefox` declarative `search` with `force = true` does **not** prune Firefox's built-in engines by omission.
  The overwrite writes `search.json.mozlz4` with only the engines listed, but Firefox reconciles its locale's app-provided engines back in for any not present in the file, so Google, Bing, and the rest reappear.
  To actually remove a builtin, list it explicitly with `<engine>.metaData.hidden = true` — an engine entry carrying only `metaData` is treated as a builtin rather than a custom engine.
  Engines are referenced by their current id, which the module maps from the old display names, so the default is `default = "ddg"`, not `"DuckDuckGo"` (the latter only warns and migrates).
  Prove the result by decoding the built file: `mozlz4a -d <search.json.mozlz4>` shows the `_metaData.hidden` flags and `defaultEngineId`.
 - `home.sessionVariables` do **not** reach the Hyprland session, so anything the compositor reads from its environment (cursor theme, toolkit hints) has to be declared elsewhere.
  home-manager writes those variables to `hm-session-vars.sh`, which only a login shell sources.
  UWSM starts the graphical session without it, so the compositor's environment never gains them.
  This is why a Stylix cursor (`XCURSOR_THEME`/`XCURSOR_SIZE` via `home.pointerCursor`) silently fails to apply and Hyprland draws its built-in cursor: the variables exist in `sessionVariables` but not in the running session (`tr '\0' '\n' < /proc/$(pgrep -x Hyprland)/environ` shows them absent).
  The fix is Hyprland's own `env = KEY,VALUE` directive in `settings`, read at compositor startup regardless of the shell profile.
  `modules/desktop/hyprland/hyprland.nix` sets the cursor that way, sourced from `config.stylix.cursor`.
  Bibata ships XCursor format only (no `hyprcursor/` dir), which Hyprland renders through its XCursor fallback, so both `XCURSOR_*` and `HYPRCURSOR_*` naming the same theme are safe.