core/home/config/nomarchy/default/hypr/input.conf hardcoded
`kb_layout = us`, so the installer's services.xserver.xkb.layout and
console.keyMap writes (both set from the installer's KEYMAP_LAYOUT
prompt) only reached XWayland apps and the TTY console. Native-Wayland
apps — i.e. almost everything in a Nomarchy desktop — fell back to US
regardless of what the user picked. Surprising for any non-US user.
Path (a) from the Later row:
- Added nomarchy.keymap.{layout,variant} to core/home/options.nix
(defaults "us" / "").
- Deleted the static input.conf from the bulk nomarchy/ deploy.
- Replaced it with an explicit
xdg.configFile."nomarchy/default/hypr/input.conf".text in
core/home/configs.nix that interpolates the option values into
kb_layout / kb_variant.
- Installer's home.nix heredoc now writes
nomarchy.keymap = { layout = "$KEYMAP_LAYOUT"; variant = "$KEYMAP_VARIANT"; };
alongside nomarchy.formFactor, so the layout reaches Hyprland
consistently with system.nix's xkb.layout / console.keyMap.
Documented in docs/OPTIONS.md (new `nomarchy.keymap.layout` /
`nomarchy.keymap.variant` entry). `nix flake check --no-build` clean.
flake.nix was re-importing ./themes/palettes and recomputing
themeNames via builtins.attrNames in its outputs `let`, even though
lib/default.nix already exports both. Two evaluations of the same
data, same result today — drift risk tomorrow as soon as one
computation grows extra logic the other doesn't.
Added `nomarchyLib = import ./lib { inherit lib; }` once and reused
it via `inherit (nomarchyLib) themeNames;` for the allThemeVariants
linkFarm. The local `palettes` binding wasn't read by anything else in
the outputs so it goes away with the rewrite. lib/default.nix is now
the single source of truth for the theme list; modules under core/
and themes/engine/ already import ../../lib the same way and resolve
to the identical evaluation.
`nix flake check --no-build` clean.
The session-manager wiring (uwsm + the Hyprland Wayland-compositor
entry that gives Hyprland a proper graphical-session.target so user
services like nomarchy-wallpaper, walker, and elephant chain off it)
had lived in core/system/virtualization.nix by historical accident —
loaded unconditionally on every install, nothing to do with libvirt
or docker.
Lifted into a dedicated core/system/session.nix and imported from
core/system/default.nix between systemd.nix and virtualization.nix.
virtualization.nix now contains only the libvirt + docker branches
its filename implies.
`nix flake check --no-build` clean. No behaviour change.
themes/templates/ shipped 11 mustache templates, but
nomarchy-theme-set-templates only writes to a path when no file is
already there — and a careful trace shows 9 of the 11 outputs are
either preempted by an earlier write or never read at all:
- kitty.conf.tpl, ghostty.conf.tpl
→ shadowed by the per-palette generators in
themes/engine/files.nix added in 8d3ce2d.
- hyprland.conf.tpl
→ shadowed by files.nix:100, which always writes
~/.config/nomarchy/current/theme/hyprland.conf from the
palette/feature/nord fallback chain.
- hyprlock.conf.tpl, alacritty.toml.tpl, btop.theme.tpl,
chromium.theme.tpl, swayosd.css.tpl
→ output paths nothing reads. alacritty + swayosd are themed
via Stylix / declarative HM options inline. btop reads from
~/.config/btop/themes/nomarchy.theme (loader.nix:72), not
from the theme symlink. chromium is themed via the managed-
policy module in core/system/browser.nix. hyprlock has no
consumer of theme/hyprlock.conf anywhere in the tree.
- hyprland-preview-share-picker.css.tpl
→ orphaned when the share-picker dir was deleted in 20de3d4.
obsidian.css.tpl and keyboard.rgb.tpl stay: the first is consumed by
nomarchy-theme-set-obsidian (copied into every Obsidian vault), the
second by nomarchy-theme-set-keyboard-asus-rog (sets the ROG
keyboard tint via asusctl).
Rewrote Step 6 of docs/creating-themes.md to describe the two live
templates by name and corrected a path bug ("~/.config/nomarchy/themed/"
→ "~/.config/nomarchy/themes/templates/" — the script actually reads
the latter).
`nix flake check --no-build` clean.
Per user decision: not supporting a non-LUKS install path. Removed
the Now-column entry and the Pillar 4 bullet that tracked it. FDE
stays the only supported install shape.
New nomarchy-installed-summary script renders a markdown table via
gum format with the install shape the user should verify before they
start customising:
- theme / font / panel position (~/.config/nomarchy/state.json)
- timezone / DNS / hybrid GPU (/etc/nixos/state.json)
- form factor (BAT* sysfs presence)
- software profiles (presence of marker packages)
- FDE (any crypt entry in lsblk)
- drives (lsblk filtered to disk/part/crypt)
nomarchy-welcome calls it as Step 0 — before the theme/font/panel
pickers — and gates progression on a gum input prompt so the user has
to acknowledge before customisation rewrites anything. The script is
also callable standalone from any terminal: `nomarchy-installed-summary`.
Self-contained — no installer-side changes. Software profiles are
detected heuristically (the installer bakes the user's pick into the
generated home.nix as concrete home.packages rather than persisting a
profile list), which is good enough for verification but won't catch
manually-removed profile packages. gum is in the existing categoryDeps
so no new tools are needed; falls back to plain markdown when gum
isn't on PATH (recovery contexts).
Closes the "Installer: What's installed? summary on first boot"
Now-column item from Pillar 4.
Component 9 (ISOs) closeout entry covers the two inline cleanups
(unreachable else branches in nomarchy-build-{iso,live-iso}) and the
regression-class verification: every tool install.sh calls is provided
by either the explicit host packages, the upstream profiles/base.nix
chain (gptfdisk, util-linux, kbd, systemd), or the nrun nix-run
fallback.
With Components 1–10 all shipped, the "Full QA audit" Now-column item
has done its job. Replaced it with a runtime-verification punch-list
entry that consolidates the "needs runtime verification" notes carried
forward by each component's closeout — boot the live ISO and walk
through waybar/menu/option-toggle paths on real hardware.
nomarchy-build-iso and nomarchy-build-live-iso both ran under set -e
but then wrapped nix build in an if [ \$? -eq 0 ] block with an else
that printed "Error: ISO build failed." and exit 1. set -e aborts the
script the instant nix build returns non-zero, so the else branch was
never reached — the user saw nix build's own error output and the
script exited.
Removed the dead conditional. Behaviour is identical.
Component 8 (Scripts runtime behavior) closeout entry summarises the
four inline fixes: omacom URL in nomarchy-menu "Learn → Nomarchy",
looknfeel.conf path drift, unreachable Overrides case branch, and
schema-vs-script default drift for the theme fallback in
nomarchy-theme-bg-next.
New Later row tracks an interaction-pattern bug in
show_setup_config_menu: five of nine entries edit files that Home
Manager generates from declarative options, so the next rebuild
clobbers the edit. Two more open paths the modules don't deploy.
Either rewire the menu or surface the ephemerality.
The script's jq fallback for .theme was hardcoded to "nord", which
drifted from the lib/state-schema.nix default of "summer-night". With
no state.json (or a blank one), nomarchy-theme-bg-next would look up
backgrounds under themes/palettes/nord/ while the rest of the system
treated summer-night as active — a quiet inconsistency that produced
"no backgrounds found" errors on a system that hadn't yet written a
theme to state.
Matched it to the schema default. lib/state-schema.nix remains the
single source of truth.
Three issues in features/scripts/utils/nomarchy-menu:
(1) "Learn → Nomarchy" called nomarchy-launch-webapp on
https://learn.omacom.io/2/the-nomarchy-manual — an upstream Omarchy
URL, the same one fixed in nomarchy-manual on 2026-05-18. Now calls
nomarchy-manual, which opens the local ~/.local/share/nomarchy/
README.md (or notifies if the source tree isn't synced).
(2) "Style → Hyprland" tried to open ~/.config/hypr/looknfeel.conf,
which is not the path looknfeel.conf is deployed to. The actual file
lives at ~/.config/nomarchy/default/hypr/looknfeel.conf (sourced by
nomarchy.conf via the chain). Updated the path.
(3) The setup-config case statement had an *Overrides* branch but no
matching menu option, so it was unreachable. The overrides loader
(nomarchy.overrides.*) is still in the Next column of the roadmap;
when it ships, both the option AND the case will get added together.
Component 7 (Theme engine + palettes) closeout entry summarises the
three inline fixes (theme-set early-exit on missing dir; bg-set
state.json persistence + path validation; palette dead-surface
cleanup) plus the script-comment correction.
Updated the existing `themes/templates/*.tpl` Later row: the original
claim "no script in the tree consumes them" was wrong —
nomarchy-theme-set-templates does. Replaced with a concrete
categorisation: (a) functionally dead (alacritty/btop/chromium/swayosd
write to paths nothing reads), (b) superseded by Nix-side generators
(kitty/ghostty after 8d3ce2d), (c) still relevant
(hyprland/hyprlock/obsidian/keyboard.rgb plus the now-orphan
share-picker tpl to verify).
The header said "Run once after install (the installer wires this
up)". The installer doesn't actually wire it up — install.sh:1848
prints a final-screen tip telling the user to run it, but doesn't
invoke it (pre-realising every theme adds significant install time
and the user can opt in later). Corrected the comment to match.
Two clusters of palette-tree dead surface:
(1) themes/palettes/{flexoki-light,lumon,retro-82,rose-pine}/apps/
chromium.theme — 9-byte comma-separated RGB strings that no script
or Nix module reads. Chromium theming is driven by managed policies
in core/system/browser.nix (BrowserThemeColor / BrowserColorScheme
derived from the active palette's base00 + light-mode flag), not by
per-palette files. The chromium.theme files were vestigial from an
earlier chromium-theming mechanism.
(2) themes/palettes/summer-day/apps/kitty/{kitty.conf,everforest-
light.conf} — a 76KB stray kitty config in a nested apps/kitty/
subdirectory. features/apps/kitty/config/kitty.conf includes
~/.config/nomarchy/current/theme/kitty.conf (root of theme dir, not
under apps/), and themes/engine/files.nix now generates that file
from the active palette's base16 colors (commit 8d3ce2d). So the
summer-day file was at the wrong path AND superseded by the
generator.
`nix flake check --no-build` passes.
Two related bugs in the theme switcher scripts:
(1) nomarchy-theme-set printed a warning when the theme directory didn't
exist but kept going — it wrote the bad name into state.json and ran
nomarchy-env-update on a broken state. Added an exit 1 after the
warning.
(2) nomarchy-theme-bg-set updated the live ~/.config/nomarchy/current/
background symlink + restarted swaybg but never wrote state.json. The
script is called by the walker background-selector menu
(elephant/nomarchy_background_selector.lua) and by the nomarchy-
wallpaper CLI wrapper, so every wallpaper picked via either path
silently reverted to the active theme's default on the next
home-manager switch — themes/engine/files.nix re-resolves
config.nomarchy.wallpaper at every rebuild. Now writes the chosen path
into state.json's wallpaper field, mirroring nomarchy-theme-bg-next.
Also added a file-exists check so a bogus path fails loudly instead of
leaving a dangling symlink + a failed swaybg process.
Component 6 (Apps) closeout entry covers the three inline theming
fixes (kitty/ghostty per-palette colors, btop color_theme name match,
VSCode theme extensions split). One new Later row tracks the 15
palettes — including the default summer-night (sainnhe.everforest) —
whose theme extensions aren't in nixpkgs and need
pkgs.vscode-utils.extensionFromVscodeMarketplace per-palette pinning.
Chromium's static Default/Preferences symlink was confirmed redundant
with the managed-policy intent in core/system/browser.nix, but left
under the existing Later entry (the user already hedged on deletion
without chromium-internals confirmation).
programs.vscode.profiles.default.userSettings.workbench.colorTheme is
set unconditionally to the active palette's theme name (read from
themes/palettes/<theme>/apps/vscode.json), but the matching theme
extensions were bundled with devExtensions — which defaults to false.
So out of the box, VSCode silently fell back to the built-in dark
theme on every palette.
Split themeExtensions out as always-installed and devExtensions as
opt-in via nomarchy.vscode.devExtensions. themeExtensions covers the 6
palettes whose VSCode theme is packaged in nixpkgs (catppuccin,
catppuccin-latte, nord, tokyo-night, rose-pine, gruvbox).
The other 15 palettes (including the default summer-night, which uses
sainnhe.everforest) still break because their theme extensions are on
the VSCode marketplace but not yet in nixpkgs — handling that needs
pkgs.vscode-utils.extensionFromVscodeMarketplace plus per-palette
publisher/name/version/sha256 metadata. Logged separately.
themes/engine/loader.nix:72 deploys the active palette's btop theme to
~/.config/btop/themes/nomarchy.theme, but btop.conf had
color_theme = "current" — btop looked for themes/current.theme, didn't
find it, and silently fell back to the built-in Default theme. So every
palette rendered btop in the same default colors regardless of the
selected Nomarchy theme.
Renamed the config reference to match the deployed file name.
lazygit and tmux both inherit terminal ANSI colors (verified: the tmux
status bar config uses blue/brightblack/etc., not hex), so the kitty +
ghostty + alacritty theming changes from 8d3ce2d cover them
transitively — no module fix needed.
features/apps/kitty/config/kitty.conf:1 contains
include ~/.config/nomarchy/current/theme/kitty.conf
and features/apps/ghostty/config/config:2 contains
config-file = ?"~/.config/nomarchy/current/theme/ghostty.conf"
Neither file existed for any of the 22 palettes. The kitty include
failed silently and the ghostty include is optional (?-prefix), so both
terminals rendered with built-in default colors regardless of the
active Nomarchy theme.
Stylix has kitty.enable = true in themes/engine/stylix.nix but the
kitty module uses xdg.configFile rather than programs.kitty, so the
Stylix target had nothing to hook into. ghostty has no Stylix target at
all.
Generated both files from the active palette's base16 colors in
themes/engine/files.nix, mirroring the waybar.css pattern already there.
Color mapping reproduces the original colors.toml fields (background,
foreground, cursor, selection_*, color0..15) via base16 indices —
verified against the inverse mapping in themes/palettes/default.nix.
themes/palettes/summer-day/apps/kitty/kitty.conf (a 76KB stray file in
the wrong tree location) is unaffected by this fix — it was already
dead surface since the include path never resolved to it.
Pillar 8 Component 5 (Desktop stack) closeout entry covers the five inline
fixes from this sweep (hyprland apps.conf wiring, NNOMARCHY typo pair,
broken waybar palette overrides, dead bindings files, mako post-fix verify)
plus the doc reconciles (SCRIPTS.md, KEYBINDINGS.md). One new Later row
captures the nightlight/hyprsunset toggle-vs-systemd inconsistency — Nix
always enables the systemd unit with a rebuild-time temperature while the
toggle script pkills/exec's hyprsunset directly and hardcodes 4000K
instead of reading nightlightTemperature.
Runtime verification (boot live ISO; eyeball waybar across panel
positions × form factors × all 22 palettes, walker launcher modes, the
screensaver at idle) remains on the user before declaring Component 5
fully closed.
nomarchy-menu:330 and nomarchy-launch-screensaver:16 referenced
\$NNOMARCHY_TOGGLE_SUSPEND and \$NNOMARCHY_TOGGLE_SCREENSAVER with a
double-N. The real env vars injected by features/scripts/default.nix:69-73
are single-N. Both reads always resolved to the empty string, so:
- nomarchy.toggles.suspend = false; still showed "Suspend" in the
system menu (the condition is "!= false", so empty != false → true).
- nomarchy.toggles.screensaver = false; still launched the screensaver
on hypridle's 150s timeout (the gate "== false" never hit on empty,
so the early-exit was skipped).
Both toggles documented in docs/OPTIONS.md were vacuous in practice.
themes/{catppuccin,lumon,nord,retro-82}/style.css fully replaced the
default style.css (no @import) but defined only 2–14 lines — just
@define-color declarations and, for nord, a minimal window#waybar block.
The default style ships ~110 lines covering #workspaces, #tray, #cpu,
#custom-nomarchy's Nomarchy-font override, margins/padding, the indicator
.active states, etc. So picking any of those four palettes produced a
waybar with zero structural styling.
The default style at features/desktop/waybar/config/style.css already
@imports ../nomarchy/current/theme/waybar.css — which themes/engine/
files.nix:30-34 generates with @background/@foreground/@accent from the
active palette. So removing the broken overrides restores per-palette
colors via the default-style path. summer-day and summer-night are kept
because their 100+-line style.css files are intentional, self-contained
visual redesigns (the case the themes/engine/loader.nix:76-79 comment
explicitly carves out for "themes that need significantly different
styling").
bindings.conf was explicitly labeled "Deprecated bindings file. New
installations include everything directly." and was sourced by nothing.
plain-bindings.conf referenced \$terminal/\$browser/\$fileManager/\$music/
\$messenger/\$passwordManager — Hyprland variables that aren't defined
anywhere in the loaded config tree — and was likewise sourced by nothing.
Both files have been superseded by features/desktop/hyprland/config/
bindings.conf (the user-overrideable, mkDefault-deployed one at
~/.config/hypr/bindings.conf) and the entries already inside
default/hypr/bindings/{utilities,media,clipboard,tiling-v2}.conf.
Regenerated docs/SCRIPTS.md; the diff drops the stale plain-bindings.conf
callers and incidentally corrects four scripts whose Origin column was
out of date after they moved from core/system/scripts/ to
features/scripts/utils/ (nomarchy-env-update, nomarchy-pkg-add,
nomarchy-pkg-remove, nomarchy-preflight-migration).
9 of the 17 .conf files under core/home/config/nomarchy/default/hypr/apps/
were deployed but never sourced. apps/system.conf carried the load-bearing
"tag +floating-window" rule that the bluetui/impala/btop/satty/screensaver
classes rely on, plus the "fullscreen, class:org.nomarchy.screensaver" rule
hypridle's 150s on-timeout depends on. apps/pip.conf carried the picture-
in-picture pin/float/size rules. Neither set of rules fired today — the
screensaver came up tiled, PiP windows didn't pin, and the floating-window
helpers shipped degraded.
Sourcing all 17 unconditionally; every rule is class- or title-gated so
the conditional ones (steam, qemu, 1password, etc.) no-op cleanly when the
app isn't installed — same pattern as the already-sourced telegram /
retroarch / localsend entries.
Two behavioral wrinkles found during the Pillar 8 desktop-stack sweep
that need a design decision before they can be fixed. Logged as Later
rows so the audit doesn't lose them.
1. The Hyprland Wayland keymap is hardcoded to `us` in
`core/home/config/nomarchy/default/hypr/input.conf:3`, ignoring the
installer-chosen layout for native Wayland apps. Fix needs either a
templated input.conf driven by a new home option, or session-level
`XKB_DEFAULT_LAYOUT` propagation. Either path touches the installer
heredoc and the home modules, so not a same-PR fix.
2. `nomarchy.toggles.waybar` is exported only as an env var consumed
by the runtime toggle script. The Nix module always sets
`programs.waybar.enable = lib.mkDefault true`, so the toggle is
session-only — waybar comes back on every rebuild/reboot.
Inconsistent with `toggles.idle` which correctly gates
`services.hypridle.enable`. Needs a behavioral call (persistent
gate vs intentional runtime-only with a clearer name).
Six unreferenced files surfaced under features/desktop/hyprland/config/
during the Pillar 8 sweep:
- `looknfeel.conf` and `autostart.conf` were deployed to ~/.config/hypr/
but never sourced by nomarchy.conf. The substantive versions live in
core/home/config/nomarchy/default/hypr/ and are sourced from there.
Removed the deployment lines in features/desktop/hyprland/default.nix
alongside the file deletes.
- `hyprlock.conf`, `hyprsunset.conf`, `xdph.conf` weren't deployed at
all and weren't referenced anywhere. Pure leftovers.
The entire `features/desktop/hyprland-preview-share-picker/` directory
was also orphan: no `default.nix`, no Nix module imports the
`config.yaml`. Only mention was inside the (now-deleted) `xdph.conf`.
Deleted the directory.
No behavioral change — these files weren't being used. Just removes
dead surface that confuses contributors looking for the "real" config
location.
`core/home/config/nomarchy/default/mako/core.ini` defines the Nomarchy
notification UX — urgency rules, app filters (Spotify silenced),
do-not-disturb mode, and button handlers for "Setup Wi-Fi" / "Update
System" / "Learn Keybindings" notifications. The file was deployed via
the bulk `nomarchy/` dir to
`~/.config/nomarchy/default/mako/core.ini`, but mako reads
`~/.config/mako/config` by default and `autostart.conf` launches it
without `--config`. So mako ran with stock defaults and the entire
themed UX was inert.
Added an explicit `xdg.configFile."mako/config".source` line in
core/home/configs.nix pointing at the existing themed file. mako now
picks up the Nomarchy rules out of the box.
Found during Pillar 8 audit of the desktop stack.
core/system/virtualization.nix wires `programs.uwsm` + the Hyprland
session config at the top of the file — loaded unconditionally on every
install, with no actual relationship to libvirt/docker. Cosmetic
mislocation, not a behavior bug; logged as a Later row so it can be
fixed in a dedicated session module without growing this audit PR.
Found during Pillar 8 audit of core/system modules.
These three settings.Login fields were set at default priority, so a
downstream system.nix that wrote (e.g.) `services.logind.settings.Login.HandlePowerKey = "poweroff"`
would collide with Nomarchy's value instead of overriding it. Same
mkDefault treatment as the other lid-switch settings in this block.
Found during Pillar 8 audit of core/system modules.
`lib/state-schema.nix` declared `system.features.makima = false` but
the field was never wired anywhere: no matching option in
core/system/options.nix, no consumer in core/system/state.nix, no
references in the wider tree. Schema-only ghost — removed.
Found during Pillar 8 audit of core/system modules.
The persistence block at core/system/impermanence.nix:75 read
`users.nomarchy = { directories = [...]; }` — the username was a
literal, not a reference. For any user not literally named "nomarchy"
the block was silently inert and ~/.ssh, ~/.gnupg, ~/.local/share/keyrings,
Documents, Downloads, Pictures, Videos, Projects were wiped on every boot.
Adds `nomarchy.system.impermanence.user` (str, default "nomarchy") and
uses it via `users.${cfg.user}`. The installer now writes the chosen
username alongside `enable` and `mainLuksName` so impermanence installs
with non-default usernames are correct out of the box.
docs/OPTIONS.md: fixes the wrong path on the impermanence row
(documented `impermanence.enable`, real option is
`nomarchy.system.impermanence.enable`) and adds entries for
`mainLuksName` and `user`.
Found during Pillar 8 audit of core/system modules.
Two unreferenced asset files removed; two larger concerns deferred to
roadmap rows because they need more thought than a focused audit
allows.
Deleted:
- `features/apps/alacritty/config/alacritty.toml` — the alacritty
module uses `programs.alacritty.settings` (Nix attrset) exclusively;
nothing references the on-disk file. The neighbouring (already-empty)
`themes/` directory goes with it.
- `themes/templates/mako.ini.tpl` — no script reads it.
Deferred to ROADMAP "Later":
- `features/apps/chromium/Default/Preferences` is deployed as a Home
Manager symlink into chromium's mutable profile directory. Either
silently replaced on first save or silently failing to write —
either way the static defaults don't survive. The actual chromium
theming work happens via managed policies in
core/system/browser.nix. Needs chromium-internals knowledge to
decide whether to remove or rework, so flagged rather than
unilaterally deleted.
- `themes/templates/*.tpl` (the remaining 10 templates) are also
apparently orphan — deployed via xdg.dataFile but unconsumed by any
script. Likely vestigial from a pre-stylix templating system.
Logged as a separate row to decide deletion vs documentation as
user-reference assets.
Found during Pillar 8 audit of features/apps.
Two clusters of documented-but-non-functional options surfaced during
the Pillar 8 audit, both setting toggles that have zero runtime effect.
1. `nomarchy.toggles.skipVsCodeTheme` was declared in
core/home/options.nix, defaulted from lib/state-schema.nix, and
surfaced as `NOMARCHY_TOGGLE_SKIP_VSCODE_THEME` env var in
features/scripts/default.nix — but `features/apps/vscode.nix` always
sets `workbench.colorTheme` unconditionally, and no script reads the
env var. Setting the toggle to true did nothing. Removed from
options, schema, state, env-var export, and OPTIONS.md.
2. `nomarchy.themeLoader.apps.{waybar,mako,kitty,alacritty}` were
declared in themes/engine/loader.nix but only `btop` is actually
wired (line 87 gates the per-theme btop.theme deploy). The other
four had no consumer. The actual theming pipeline for those apps is
elsewhere: waybar themes inline from `colorScheme` in waybar.nix;
kitty and alacritty are themed by stylix targets in
themes/engine/stylix.nix; mako has no theme integration at all.
Removed the four dead options + updated OPTIONS.md to list only
btop with a note about where the other apps' theming lives.
`features/default.nix` had a let-block that read
`~/.config/home-manager/user-packages.json` at eval time via
`builtins.pathExists` + `builtins.readFile`, parsed it as JSON, and
filtered to valid pkgs — then never appended the result to
`home.packages` or anywhere else. The `userPackages` variable was
completely orphan.
Two problems with the dead code: (1) it was an undocumented hidden
mechanism (no docs mentioned `user-packages.json`), (2) it made flake
evaluation impurely depend on a user's home directory for no payoff —
flake outputs would silently differ between machines depending on the
presence of that file, even though nothing in the build used it.
Removed the let-block entirely. The nomarchyLib import stays.
Found during Pillar 8 audit of features/apps.
`themes/engine/sddm.nix` defaulted `services.displayManager.autoLogin`
to `enable = true; user = "nomarchy";` (both mkDefault). The installer
flow overrode both with the real username at normal priority, so this
was invisible there — but a hand-migrated user (per docs/MIGRATION.md)
who imported `nomarchy.nixosModules.system` without setting
`autoLogin.user` would auto-login as a nonexistent "nomarchy" user and
SDDM would error. `docs/MIGRATION.md` even documented the override as a
post-import chore.
Flipped the default to `enable = lib.mkDefault false`. Installer
generates `enable = true` directly so its flow is unchanged. Migration
flow now gets the safe default — opt-in instead of opt-out — and the
docs row is updated to reflect the new shape.
The hardcoded "nomarchy" username fallback for `autoLogin.user` is the
same class of bug as the impermanence persistence block was. A future
roadmap row to consolidate "primary user" across impermanence,
autoLogin, and any future modules might be worthwhile, but it's
deferred — this commit is the immediate fix.
Found during Pillar 8 audit of first-boot UX.
`nomarchy-welcome` wrote a "starter" `~/.config/home-manager/home.nix`
for users without one. Two problems:
1. Wrong path. The installer-generated canonical home.nix lives at
`/etc/nixos/home.nix` and is imported via the flake (both
home-manager.users and the standalone homeConfigurations). Nothing
in the installer flow ever reads `~/.config/home-manager/home.nix`
— it's a dead file.
2. Broken content. The starter is missing `home.username`,
`home.homeDirectory`, `home.stateVersion`, and doesn't import
`nomarchy.nixosModules.home`. Even on a hand-migration path it
wouldn't evaluate as a standalone HM config.
So in the installer flow it's dead, and in the migration flow it's
broken. Removed Step 4 entirely. The git-init step (was Step 5) is
now Step 4. Hand-migrated users follow `docs/MIGRATION.md`, which has
the correct home.nix template.
Found during Pillar 8 audit of first-boot UX.
Two unused helpers and a missing comment in the lib/ surface, found
during the Pillar 8 sweep.
- `readState` in `lib/default.nix` was exported but has no external
callers — only `readHomeState` and `readSystemState` use it
internally. Removed from the export list; the function stays in the
let-block (still wraps the two public readers).
- `getWithDefault` in `lib/state-schema.nix` was a complete dead
function: declared as a path-walking fallback helper but never called
anywhere in the tree. core/{system,home}/state.nix use inline
`togglesState.<key> or schema.<scope>.<key>` instead. Removed.
- Added a header comment to `lib/state-schema.nix` explaining the
schema's boundary — it lists every state.json field consumed by a
Nix option, but state.json may also hold runtime-only fields
(`welcome_done` from `nomarchy-welcome`) that are intentionally
off-schema because no Nix option reads them. Future readers will
otherwise think welcome_done is an orphan.
Logged a Later-column roadmap row for consolidating `flake.nix`'s
palette/themeNames re-imports with `nomarchyLib` so the theme list has
one source of truth instead of two.
Two declared-but-non-functional option subsystems in core/home were
documented in OPTIONS.md and actively misleading users.
1. `nomarchy.behavior.hyprland.{bindings,input,windowRules,autostart}`
were declared in core/home/behavior.nix with a `behaviorConfigs`
mapping let-binding — both completely unread elsewhere in the tree.
The actual hypr/*.conf files are deployed by
features/desktop/hyprland/default.nix with `lib.mkDefault`,
unconditionally. Setting `behavior.hyprland.bindings = false` had
zero effect. OPTIONS.md's "Disable Nomarchy's default Hyprland
keybindings" example was a lie. Removed the four dead options,
deleted behavior.nix entirely, dropped the import from
core/home/default.nix, and rewrote the OPTIONS.md example to use
`xdg.configFile."hypr/bindings.conf".source = ./mine` (which
actually works against the existing `lib.mkDefault` priority).
2. `nomarchy.overrides.{enable,paths}` advertised a file-based override
loader that doesn't exist. The module created
`~/.config/nomarchy/overrides/{hypr,waybar,apps}` directories and
wrote a README claiming "place files here to override upstream
defaults" — but `getOverrideOrDefault` was never called and `paths`
was never populated. Rewrote core/home/overrides.nix to keep just
the option declarations (so configs that already set these still
evaluate) and marked them clearly as reserved/no-op in OPTIONS.md.
Removed the misleading README write and dir-creation. Logged a
Next-column roadmap row for implementing the loader properly.
While here:
- Clarified `nomarchy.configOverrides` (the *working* bulk-redirect
mechanism) vs `nomarchy.overrides.*` (the reserved one) in OPTIONS.md
— they're different things and the "See Overrides below" link was
pointing at the broken subsystem.
- Fixed OPTIONS.md `nomarchy.iconsTheme` / `nomarchy.isLightMode`
default text — both are derived from the active theme in
core/home/state.nix, not the static literals the docs claimed.
- Updated docs/AGENT.md §2 and docs/STRUCTURE.md to reflect the
behavior.nix removal and the overrides.nix reservation.
Found during Pillar 8 audit of core/home modules.
Laptop, Desktop, Accessibility, and Gaming presets all shipped on
2026-04-26 but were still tagged (Next). Reorders the pillar so the
two genuinely open items (dGPU auto-detect, Surface support) lead.
Pillar 3 audited script existence; Pillar 8 audits feature behavior.
Adds a per-component sweep methodology (10 components, one PR each on
wave/qa-<component>) and lists it on the Now board so the next session
can pick it up without re-deriving scope.
Cleanup pass on Pillar 4: removes two "(Now)" entries (software-profile
multi-select, form-factor → laptop preset) already in the Shipped log,
and promotes the two remaining open items ("What's installed?" summary,
non-LUKS branch) to the Now board.
- Update lib/state-schema.nix to default both home and system themes to 'summer-night'.
- Fix 'nomarchy-theme-list' and 'nomarchy-theme-set-templates' to resolve themes and templates from '~/.local/share/nomarchy' instead of the obsolete '$NOMARCHY_PATH' (fixing failures on Live ISO).
- Update 'nomarchy-welcome' to properly convert Title Case theme display names back to kebab-case identifiers and add input validation to prevent crashes.
- Fix installer impermanence symlink by using a relative path ('../persist/etc/nixos'), ensuring it resolves during 'nixos-install' both inside and outside the chroot.
- Deploy '~/.XCompose' symlink via Home Manager and add 'nomarchy-restart-xcompose' to the menu.
- Relocate 'Nomarchy.ttf' to 'core/branding/' and move user-level scripts ('pkg-add', 'pkg-remove', 'env-update', 'preflight-migration') to 'features/scripts/utils/' to align with the distro architecture.
- Remove obsolete '$NOMARCHY_PATH' exports and redundant 'bashrc' template.
- Export theme templates via 'xdg.dataFile' for script accessibility.
Audited every entry in `installer/hardware-db.sh` against
`inputs.nixos-hardware.nixosModules` and found **21 of 43 entries (49%)
referenced modules that don't exist** in the upstream attribute set —
those installs would fail at eval time with "attribute not found"
errors on real hardware. Specifically:
- Framework 13 per-gen: nixos-hardware uses `framework-11th-gen-intel`,
not `framework-13-11th-gen-intel`. Fixed all four generations.
- Framework 13 AMD AI 300: `framework-amd-ai-300-series` (no "13-").
- Framework Intel Core Ultra: added `framework-intel-core-ultra-series1`.
- Framework 16 AMD AI 300: added `framework-16-amd-ai-300-series`.
- Framework generic fallback now uses the `framework` umbrella module.
- ThinkPad X1 Carbon: modules are `lenovo-thinkpad-x1-Nth-gen`,
not `-x1-carbon-genN`. Fixed gens 6/7/9/10/11; added X1 Nano.
- ThinkPad P14s: requires arch+gen suffix; switched to the AMD gen3/4/5
modules (the prior `lenovo-thinkpad-p14s` had no attribute).
- Surface Pro 6/7/8/10: all share `microsoft-surface-pro-intel`. Pro 9
keeps its dedicated module. Pro 3 fixed to `-pro-3`. Surface Book
2/3 and Intel-based Surface Laptop 3/4/5: no nixos-hardware module
— rows dropped; generic chassis+cpu+gpu detection still emits
sensible `common-pc-laptop`.
- ASUS ROG Strix G513 → `asus-rog-strix-g513im` (correct attr name).
- ASUS ROG Zephyrus GA403 didn't exist — dropped. Added `ga402x`,
`gu603h`, `g533zw`.
- ASUS Zenbook generic `asus-zenbook-ux` was non-existent — dropped
(too vague; available modules are per-model like `asus-zenbook-ux481`).
- Dell Latitude 5400 / 7480: no modules — replaced with the existing
`dell-latitude-7420`, `7430`, `7490`.
Added:
- ROG Ally / Ally X support (`asus-ally-rc71l` for `RC71L`,
`RC72LA`, and the "ROG Ally" product string). nixos-hardware
currently ships one module for both revisions.
Documented (in a footer comment) the devices nixos-hardware doesn't
cover so they're known-unsupported rather than accidentally missing:
- Valve Steam Deck → Jovian-NixOS as a separate flake input.
- Snapdragon X laptops → aarch64 only; Nomarchy installer is x86_64.
- Raspberry Pi → same as above.
Bug discovered along the way: the DB's pipe-separated row format
collides with bash regex alternation. A row like
`Microsoft|Surface Pro (10|8|7|6)|_|module` parses as 7 fields, with
"7" extracted as the module name. Surface Pro variants are now one
row per version.
CI gate added (`.forgejo/workflows/check.yml`): a new step extracts
every 4th-pipe-field from `HARDWARE_DB` and `comm -23`s it against
`inputs.nixos-hardware.nixosModules`. Any future entry pointing at a
non-existent module fails CI with a clear error. Closes the regression
class entirely.
Verified locally: bash -n + shellcheck --severity=error pass on
hardware-db.sh; the CI step's exact commands pass against the new DB.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
The script hardcoded `xdg-open https://learn.omacom.io/2/the-nomarchy-manual`
— an upstream Omarchy page. Users hitting "Help → Manual" in nomarchy-menu
were sent to an unrelated site, and there's no nomarchy.org canonical
docs URL to point at instead.
Now opens `$HOME/.local/share/nomarchy/README.md`, which lives on every
installed system (per SKILL.md's "Out of Scope" note about
`~/.local/share/nomarchy/`) and links every doc in `docs/`. Falls back
to a notify-send "run nomarchy-update?" message if the source tree
isn't synced.
Pillar 6 entry in docs/ROADMAP.md updated to (Shipped).
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Two stale-doc cleanups in one commit. Both surfaced during the
post-Phase-B audit pass.
1. `docs/STRUCTURE.md` "Root Directory" listed three files that don't
exist anywhere in the tree:
- `GEMINI.md` (replaced long ago by `docs/AGENT.md`)
- root-level `STRUCTURE.md` (this file actually lives in `docs/`)
- `TODO.md` (long since replaced by `docs/ROADMAP.md`)
Replaced with the actual root layout (flake.nix, flake.lock,
README.md, .forgejo/, .githooks/) plus a `docs/` sub-tree that
names every doc in the directory — the missing pieces the deleted
bullets were trying to point at, now correctly located.
2. `docs/ROADMAP.md` Pillar 6 had three "Next" bullets that already
shipped on 2026-04-26 (the welcome wizard, TROUBLESHOOTING.md, and
the docs-index goal — README.md now links every doc in `docs/`).
Moved all three to `(Shipped)`.
Also rewrote the `nomarchy-manual` bullet — "orphaned reference
today" was stale (the script is called from nomarchy-menu and
nomarchy-theme-install per docs/SCRIPTS.md). The real remaining
issue is its hardcoded `xdg-open https://learn.omacom.io/...` —
an Omarchy URL that opens an unrelated upstream page when a user
triggers the menu's Help entry. The bullet now names that
specifically.
No code touched; doc-only.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
