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>
Closes the last source-of-truth split after the state-defaults
centralization batches. The installer's heredoc was the only remaining
place that hardcoded the state.json literal — adding a default to the
schema previously required a parallel edit here, and silent drift was
exactly the bug class we kept fixing.
Before:
cat > /mnt/etc/nixos/state.json <<JSON_EOF
{
"theme": "nord",
"timezone": "${_state_tz}",
"dns": "DHCP",
...
}
JSON_EOF
After:
nix eval --impure --raw --expr "
let
flake = builtins.getFlake \"$NOMARCHY_REPO\";
lib = flake.inputs.nixpkgs.lib;
schema = import \"$NOMARCHY_REPO/lib/state-schema.nix\"
{ inherit lib; };
state = schema.system // { timezone = \"$_state_tz\"; };
in builtins.toJSON state
" | nrun jq '.' > /mnt/etc/nixos/state.json
Uses the flake's own pinned `inputs.nixpkgs` (matching what the rest of
Nomarchy resolves against), so the schema evaluates with the same `lib`
the consumer modules see. `nrun jq` pretty-prints for human inspection.
Behavioural notes:
- Output is identical to the old heredoc modulo alphabetical key
ordering — `builtins.toJSON` sorts keys, the heredoc was in
declaration order. Toggle scripts read/write via `jq` so it's
invisible to them.
- Dry-run path unchanged. `execute_dry_run` already bind-mounts a fake
/mnt for the generator; the generator's absolute paths still resolve.
- New schema fields show up automatically on the next install; no
parallel edit needed.
- `bash -n` + `shellcheck --severity=error` clean.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Two related fixes that together close the "minimal wiring" gap behind
`nomarchy.system.features.hybridGPU`.
1. Complete the NVIDIA driver stack inside hardware.nix's hybridGPU
mkIf block.
Before: `hybridGPU = true` enabled supergfxd and... that was it.
supergfxd manages mode switching by black/unblacklisting the nvidia
kernel module, but without the rest of the NVIDIA stack actually
loaded the dGPU has no driver to drive. Hyprland/Wayland silently
stayed on the iGPU regardless of mode.
After: hybridGPU=true also wires
services.xserver.videoDrivers = ["nvidia"] (loads the driver
under Wayland too)
hardware.graphics.{enable,enable32Bit}
hardware.nvidia.modesetting.enable (required for
Wayland)
hardware.nvidia.powerManagement.enable
hardware.nvidia.package = config.boot.kernelPackages
.nvidiaPackages.stable
boot.kernelParams += "nvidia-drm.modeset=1"
All wired with lib.mkDefault so a downstream system.nix can pin a
beta driver, flip to the open kernel module, or set
`hardware.nvidia.prime.{offload.enable, intelBusId, nvidiaBusId}`
for render-offload. The bus IDs are per-machine (find via
`lspci -D`) so they stay user-supplied; docs/OPTIONS.md has the
full recipe.
2. Add lib.mkDefault to every state.json-derived assignment in
core/system/state.nix and core/home/state.nix.
Same priority bug on both sides: assignments like
`features.hybridGPU = systemState.features.hybridGPU or false`
landed at default priority. A downstream system.nix saying
`nomarchy.system.features.hybridGPU = true` would then conflict
with the state-derived value at the same priority, and Nix would
refuse the merge with "conflicting definition values" — the
user's override couldn't take effect.
Verified by an explicit eval: extending the default nixosConfig
with `nomarchy.system.features.hybridGPU = true` now resolves
cleanly and the full driver stack engages.
Side-effect: core/system/state.nix now reads from
lib/state-schema.nix like the home side does, completing the
schema-centralization started two batches ago.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Four resume-flow papercuts in `installer/install.sh` that hurt the
"interrupted install" path the most.
1. `--resume` with no state file is no longer silent.
The most common operator confusion: reboot the live ISO, forget
/tmp/ is tmpfs, re-run with --resume, watch the installer start
over from scratch without saying anything. Now: loud error, tmpfs
explanation, exit 1.
2. Validate the saved TARGET_DRIVE still exists on resume.
Live ISO USB sticks get unplugged between sessions, dev hosts
sometimes have non-deterministic /dev/sdX numbering. Without the
guard the install proceeds and fails with cryptic disko / mount
errors deep in execute_installation. Now we fail at load_state
with the actual reason and a clean recovery path.
3. Resume now shows what's being resumed.
`save_state` stamps an ISO-8601 timestamp; `load_state` prints
"Resumed from <path> (saved Xm ago)" plus a "Target: /dev/X → user
@ host" summary line. Lets the user Ctrl-C before any destructive
prompt fires if they're resuming onto the wrong machine.
4. `--help` documents the tmpfs limitation.
Saved state lives in /tmp/ which is tmpfs on the live ISO; --resume
only works within the same boot. The man-page now says so instead
of letting users discover it the hard way.
`format_age` is the one new helper — pretty-prints "Xs/Xm/Xh Ym/Xd"
relative to now, falls back to the raw timestamp if `date -d` can't
parse the input. shellcheck --severity=error passes.
Out of scope (potential future work):
- Persistent state across reboots (would need a writable USB / external
drive — chicken/egg with the installer setting up the only persistent
storage in the first place).
- `--show-state` flag to inspect a saved file without running.
- State-file schema versioning.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Kills a recurring bug class: state defaults previously lived in three
parallel places that drifted apart over time.
- lib/state-schema.nix (the canonical schema, referenced
nowhere except a description string)
- core/system/options.nix (default = "..." clauses on options)
- core/home/options.nix (same, on home options)
- core/home/state.nix (`or "..."` fallbacks for state.json reads)
When `state.json` is missing a key, three files have to agree on the
fallback. They keep silently drifting:
- The OOTB QA audit shipped fixes for this pattern.
- Earlier this session, `chore: switch default theme summer-night → nord`
fixed core/system/options.nix and core/home/state.nix — but missed
core/home/options.nix, which still defaulted nomarchy.theme to
"summer-night". Every consumer of the home option
(features/default.nix, vscode.nix, waybar, hyprland, theme engine)
resolved to the wrong theme when state.json was blank.
This change:
- Imports lib/state-schema.nix into all three consumers and replaces
every hardcoded default with `schema.<scope>.<key>`.
- Fixes the lingering nomarchy.theme = "summer-night" home-side bug as
a side-effect.
- Touches roughly 25 literals across the three files.
Verified `nix flake check --no-build` passes and every centralized value
evaluates to the exact literal it previously had. Off-schema option-only
defaults (isLightMode, formFactor, cursor.*, iconsTheme, keyring.enable,
etc.) are left hardcoded — they have no state.json counterpart, so
there's no source-of-truth split to resolve.
Out of scope (follow-up):
- Have installer/install.sh generate /mnt/etc/nixos/state.json from
the schema instead of hardcoded JSON — would close the last
split-brain surface (the installer can still drift from schema).
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Pillar 7 first step. `.forgejo/workflows/check.yml` runs on every push
to main and every PR. Three sequential checks in one job:
1. `nix flake check --no-build`
Catches eval regressions: broken option references, missing imports,
stale module argument shapes. The same command AGENT.md tells humans
to run by hand before declaring a change done.
2. `bash -n` + `shellcheck --severity=error` over every `nomarchy-*`
bash script.
Mirrors what `.githooks/pre-commit` does locally, but across the
whole tree on every push — so a branch that bypasses the hook (via
`--no-verify` or a fresh clone without `core.hooksPath` set) still
gets gated. Severity is capped at error to match the hook; the long
tail of style/info warnings can be cleaned up incrementally.
3. `docs/SCRIPTS.md` drift check.
Regenerates the audit doc to a temp file and `diff`s against the
committed version. Fails loudly with the fix command if a script
add/remove/rename didn't include the regeneration step.
Dry-run results on the current tree:
- `nix flake check --no-build`: pass (only pre-existing warnings).
- shellcheck across 159 scripts at severity=error: pass.
- SCRIPTS.md drift: clean.
Activation:
Forgejo Actions isn't enabled on the repo yet, so the workflow lands
dormant. To activate: enable Actions on the repo in Forgejo's settings
and register a `forgejo-runner` on any Docker-capable Linux host. The
workflow uses `ubuntu-latest` and installs Nix itself via
`DeterminateSystems/nix-installer-action`, so no special runner image
is needed.
Deferred to a follow-up batch (needs binary cache infra):
- Building ISOs in CI (`nomarchy-installer`, `nomarchy-live`, default).
- Release pipeline (`vYY.MM.x` tags publishing ISOs as artifacts).
- `nixosTest` per palette with golden-image screenshot diffs.
`docs/STRUCTURE.md` now documents `.forgejo/` and `.githooks/` so future
agents and contributors can find both.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Pillar 3 Phase B, batch 4 (final). Triages the last 13 `unused?` rows:
five deletes and eight SKILL.md surfacings.
Deleted (no callers anywhere, work duplicated inline or marginal value):
- `nomarchy-restart-hyprctl` and `nomarchy-restart-mako`: stale comments
claimed "used by theme switching" but no Nomarchy script calls them.
Theme-set and refresh paths call `hyprctl reload` / `makoctl reload`
directly (see nomarchy-refresh-hyprland).
- `nomarchy-restart-tmux`: 3-line pgrep+source-file wrapper. Users can
`tmux source-file ~/.config/tmux/tmux.conf` themselves.
- `nomarchy-battery-present`: the battery monitor reads
`/sys/class/power_supply/BAT*` inline; the helper never got wired in.
- `nomarchy-sudo-keepalive`: intended to be `source`d from longer-running
scripts (nomarchy-update, etc.) but nothing sources it. Resurrect from
git history if a future caller actually needs it.
Surfaced in SKILL.md (now tagged `kept` by the audit):
- Themes: `nomarchy-theme-{remove,refresh,bg-install}`
- System: `nomarchy-sudo-{passwordless-toggle,reset}`,
`nomarchy-restart-trackpad` (intel_quicki2c THC reload — a real laptop
bug fix worth documenting)
- New Virtualization section: `nomarchy-windows-vm {install,launch,stop,status}`
- Enriched Troubleshooting's generic `nomarchy-refresh-<app>` example with
literal `nomarchy-refresh-fastfetch` so the audit catches it.
Verified `nix flake check --no-build` still passes and zero callers
reference the deleted scripts.
**Phase B is now complete.** Final audit state: 164 → 159 scripts, all
tagged `kept`, `unused?` = 0, missing references = 0. The audit table is
now a clean reference of what Nomarchy ships, not a triage backlog.
Logged in `docs/ROADMAP.md` Shipped.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Pillar 3 Phase B, batch 3 — Batch A of the unused? clusters.
Deleted two dead webapp URI handlers:
- `nomarchy-webapp-handler-hey`
- `nomarchy-webapp-handler-zoom`
Neither was registered as a MimeType handler anywhere — a grep across
`*.desktop` files in `core/`, `features/`, `themes/`, `installer/`, and
`hosts/` returned zero matches. Without a `.desktop` registration the
system never routes `mailto:`/`zoom:`/`zoomus:` URIs to them, so the
handlers were unreachable code.
Kept the six remaining install/remove pairs (they're real CLI tools, just
unwired into any menu) and surfaced them in `SKILL.md` "Common Tasks" so
AI assistants can discover them on user request and the audit tags them
`kept`:
- Custom App Launchers: webapp-{install,remove,remove-all},
tui-{install,remove,remove-all}
- Voice dictation: voxtype-{install,remove,status}
Menu-wiring these (e.g. a "Setup → Apps" submenu in nomarchy-menu) is a
separate Pillar 6 onboarding job, not scoped here.
Regenerated `docs/SCRIPTS.md` — script count 166 → 164, `unused?` 21 → 13.
Logged in `docs/ROADMAP.md` Shipped.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
