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.
This commit is contained in:
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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`.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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).
|
||||
@@ -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.
|
||||
Reference in New Issue
Block a user