Found by driving the menu's observable actions live in a VM with the real
session env imported. All three are also bound to keybindings.
1. nomarchy-hyprland-window-single-square-aspect-toggle (1-Window Ratio,
SUPER CTRL BACKSPACE): read/set layout:single_window_aspect_ratio, which
is "no such option" in Hyprland 0.52.1 — the option lives under dwindle:.
The getoption returned nothing and the keyword set was silently dropped,
so the toggle did nothing. Point it at dwindle:single_window_aspect_ratio.
2. nomarchy-hyprland-workspace-layout-toggle (Workspace Layout, SUPER L):
read .tiledLayout off `hyprctl activeworkspace -j` (no such key → always
null) and switched to "scrolling" (not a built-in layout — hyprctl
layouts lists only dwindle/master), so it silently no-op'd. Rewrite to
toggle the real general:layout between dwindle and master.
3. show_setup_menu offered Power Profile unconditionally, but powerprofilesctl
is absent everywhere (power-profiles-daemon is force-off on laptop in
favour of TLP and never enabled on desktop), so the entry died with
"command not found". Gate it behind `command -v powerprofilesctl`.
Verified (1) and (2) against live Hyprland in the VM: aspect flips
[0,0]<->[1,1], layout flips dwindle<->master.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
All three confirmed real on inspection.
1. nomarchy-refresh-config was dead on every system: it read
/etc/nixos/nomarchy/{core/home/config,features} (the source tree never
lands there — only /etc/nomarchy on VM-guest/live ISO) and fell back to
~/.local/share/nomarchy/config, which nothing deployed despite SKILL.md
documenting it. Deploy the pristine core/home/config tree to
~/.local/share/nomarchy/config via xdg.dataFile and read from there, so it
works without a source checkout; its live caller nomarchy-refresh-fastfetch
now succeeds. Fix two stale SKILL.md examples (waybar/, hypr/) that pointed
at non-existent stock paths.
2. nomarchy-docs-scripts shipped a stale divergent copy in
features/scripts/utils/ (in the user nomarchy-system-scripts package)
beside the canonical bin/utils dev tool — it errored outside the repo.
Grounding it surfaced the identical bug in nomarchy-docs-keybindings.
Delete both duplicates, add them to the generator's self-reference
denylist so they don't show as false `missing`, regenerate docs/SCRIPTS.md.
3. Home ~/.config/nomarchy/state.json was never seeded on non-installer
systems, so nomarchy-installed-summary rendered "—" for theme/font/panel.
Add an idempotent home-manager activation seed in core/home/state.nix that
backfills the resolved values (defaults * existing — user choices and
runtime-only keys like welcome_done always win).
Verified: flake check + full eval matrix clean; refresh-config happy/error
paths and the seed deep-merge proven by hand.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
New pillar to drive the distro running in a VM and verify what actually
works vs. what only looks right in source: run every nomarchy-* command,
walk every menu entry, switch through all 22 palettes and eyeball
rendering, fire every keybinding, drive the installer. Documents the
method (build -> boot headless -> screendump/sendkey) proven in the first
VM-boot pass, the per-component checklist, and the deliverable format. The
old "Pillar 8 runtime verification" Now-board punch-list folds into it.
AGENT.md's verify step now points at the headless VM screenshot flow.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Gitea only scans .gitea/workflows and .github/workflows; it does not scan
.forgejo/workflows (that path is Forgejo-only). The CI was therefore
dormant on a Gitea instance regardless of whether Actions was enabled.
git mv to .gitea/workflows/ (scanned by both Gitea and Forgejo). Updated
the live references in STRUCTURE.md (Gitea + act_runner), AGENT.md, and
today's ROADMAP entry; left the dated historical Shipped entries as the
changelog they are.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
nix flake check --no-build only evaluates the four default configs, so a
bug that only fires when a nomarchy.* toggle is flipped sails through —
exactly how the vscode option rename and the impermanence systemd-stage-1
assertion both reached main undetected.
Add bin/utils/nomarchy-eval-matrix: layers each opt-in scenario (16
toggles, both system and home halves) onto nixosConfigurations.default
via extendModules and forces system.build.toplevel.drvPath (which forces
assertion checks); also forces all 21 palettes through the system-side
Plymouth base00->RGB math that the home-only allThemeVariants never
reaches, plus both standalone homeConfigurations. Per-scenario results
come from builtins.tryEval so one failure doesn't mask the rest; verified
it goes red on a re-injected assertion failure and a bad option ref, green
on the current tree.
Wired into .forgejo/workflows/check.yml after flake check (jq via nix
shell so it doesn't depend on the runner image). AGENT.md §5 now tells
future agents to add a scenario when they add/rename an opt-in option.
nomarchy-docs-scripts: filter systemd-service declarations (.services.
nomarchy-) and denylist the eval-matrix repo tool so neither shows as a
dangling "missing" reference; also retroactively clears the latent
nomarchy-flathub-init drift from the gaming-flathub commit.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
themes/engine/plymouth.nix enables systemd stage-1 initrd
(boot.initrd.systemd.enable) distro-wide, and Plymouth is imported
unconditionally from core/system/default.nix. systemd stage 1 hard-rejects
boot.initrd.postDeviceCommands with a failed assertion, so every config
with nomarchy.system.impermanence.enable = true — including installs that
chose impermanence at the installer prompt — failed to evaluate.
Convert the Erase-Your-Darlings rollback to a boot.initrd.systemd.services
oneshot unit ordered after the LUKS mapping opens and before sysroot.mount,
and add boot.initrd.systemd.initrdBin for btrfs-progs/coreutils/util-linux/
findutils (the systemd initrd doesn't ship them by default). Script body is
unchanged. Verified eval via extendModules on nixosConfigurations.default;
boot-time wipe semantics still need a real wipe-boot cycle (Pillar 8).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Before this fix, only the 6 palettes whose theme extensions ship in
pkgs.vscode-extensions had working VSCode theming. Every other palette
had `workbench.colorTheme` set to a name VSCode couldn't find, so it
silently fell back to its built-in default. Including the DEFAULT
summer-night palette (sainnhe.everforest) — the default install had
broken VSCode theming.
Probed the 13 unique extensions against the VSCode marketplace
extensionquery API:
- 10 exist and are pinnable: sainnhe.everforest,
shadesOfBuntu.flexoki-light, qufiwefefwoyn.kanagawa,
oldjobobo.{lumon,miasma,retro-82}-theme, TahaYVR.matteblack,
jovejonovski.ocean-green, monokai.theme-monokai-pro-vscode,
Bjarne.white-theme.
- 3 don't exist on the marketplace and are unpublished custom
Nomarchy themes: Bjarne.{ethereal,hackerman,vantablack}-nomarchy.
Logged as a new Later row.
For the 10, fetched version + sha256 via:
URL='https://${publisher}.gallery.vsassets.io/_apis/public/gallery/publisher/${publisher}/extension/${name}/${version}/assetbyname/Microsoft.VisualStudio.Services.VSIXPackage'
nix store prefetch-file --hash-type sha256 "$URL"
Added a marketplaceExtensions list to features/apps/vscode.nix that
wraps each in pkgs.vscode-utils.extensionFromVscodeMarketplace and
concatenates with the existing nixpkgs-packaged list — so 10 more
palettes (including the default) now get correct VSCode theming on
first launch. Smoke-built sainnhe.everforest end-to-end. Module
comment documents the version-bump procedure.
docs/OPTIONS.md updated: the nomarchy.vscode.devExtensions entry
drops the "still break" caveat for everything except the three
unpublished Bjarne palettes.
`nix flake check --no-build` clean.
features/apps/chromium/default.nix was deploying a 204-byte static
Default/Preferences via Home Manager symlink into Chromium's mutable
profile directory. The deployment is structurally broken — Chromium
expects to write that file at runtime, so either the symlink is
silently replaced on first save (losing the static defaults) or the
write fails silently.
The contents are also redundant + incorrect:
- `extensions.theme.{use_system,use_custom} = false` — already
superseded by the managed-policy approach (BrowserThemeColor
overrides any user-installed theme extension regardless).
- `browser.theme.{color_scheme,user_color} = 2` — hardcoded "dark"
via Chromium's color_scheme enum, conflicting with the dynamic
BrowserColorScheme = isLightTheme ? "light" : "dark" set by
core/system/browser.nix. A user on flexoki-light / summer-day /
catppuccin-latte / rose-pine / white would have had a static-vs-
policy mismatch every time.
Removed the entire features/apps/chromium/ directory (default.nix +
config/Default/Preferences) and dropped the import from
features/default.nix. Chromium theming continues to flow through the
system-level managed policy, which is the canonical chromium-on-NixOS
path.
`nix flake check --no-build` clean.
Moved the Next-column row → Shipped following commit 474bc16
("feat(plymouth): boot splash background follows the active palette").
Next column is now empty.
New nomarchy.accessibility.enable home option mirroring
nomarchy.system.accessibility.enable. When enabled, core/home/
accessibility.nix contributes a Hyprland extraConfig block via
lib.mkAfter:
- input.repeat_rate = 25 (from 40)
- input.repeat_delay = 1000 ms (from 600)
Holding a key isn't a runaway machine-gun for low-mobility users.
- bindd = SUPER ALT, S, Launch Orca, exec, orca
The system preset already puts orca on PATH.
mkAfter guarantees the slowdown wins over the templated input.conf.
Documented in docs/OPTIONS.md. The third item from the original Next
row — a high-contrast palette — is split into its own Later row
because it's a design task (24-colour WCAG AAA palette + icon family
choice) that wants its own review.
`nix flake check --no-build` clean.
show_setup_config_menu was an Omarchy holdover where users edited
mutable config files at runtime. In Nomarchy:
- hyprland.conf, hypridle.conf, hyprsunset.conf, walker/config.toml,
waybar/config.jsonc are all Home-Manager-generated from declarative
settings — a `home-manager switch` clobbers any edit.
- hyprlock.conf and swayosd/config.toml point at paths the modules
don't deploy at all; open_in_editor created empty files.
- ~/.XCompose is a HM symlink into /nix/store — read-only.
Dropped the entire submenu function and the " Config" item from
show_setup_menu (and the matching *Config*) case branch). Persistent
settings go through the relevant nomarchy.* option in
/etc/nixos/home.nix (or system.nix); when the nomarchy.overrides.*
loader ships, a successor menu can route through
~/.config/nomarchy/overrides/.
Side effect (caught by the SCRIPTS.md regen): nomarchy-restart-xcompose
is now `unused?` — its only caller was the XCompose case I just
removed. Left for a future Pillar 3 cleanup rather than widening
this PR.
`bash -n` clean.
features/desktop/waybar/default.nix previously set
`programs.waybar.{enable,systemd.enable} = lib.mkDefault true`
unconditionally. The toggle script wrote .waybar to state.json and
pkill/exec'd waybar for instant feedback, but the next rebuild
re-enabled it because the Nix module didn't read the toggle. Result:
the bar came back on every rebuild/reboot regardless of the persisted
state — inconsistent with toggles.idle (gates services.hypridle.enable)
and now toggles.nightlight (gates services.hyprsunset.enable).
programs.waybar.{enable,systemd.enable} now follow
config.nomarchy.toggles.waybar. nomarchy-toggle-waybar flips the
running systemd user unit (`systemctl --user start/stop waybar.service`)
for instant feedback and writes .waybar back to state.json so the next
rebuild realigns. Disabled toggle now means no waybar across rebuilds
+ reboots, matching the option's documented meaning ("Whether the top
bar is enabled").
`nix flake check --no-build` + `bash -n` clean.
features/desktop/nightlight.nix previously set
`services.hyprsunset.enable = lib.mkDefault true` unconditionally and
baked the temperature (4000K when toggles.nightlight, 6500K otherwise)
into extraArgs at Nix-eval time. The toggle script bypassed systemd:
pkill on disable, `hyprctl dispatch exec hyprsunset --temperature 4000`
on enable — racing the systemd-managed instance and hardcoding 4000K
regardless of nomarchy.nightlightTemperature. The "Always enabled, we
control via IPC and state" comment was misleading: no IPC, the
temperature was rebuild-time, and the script forked a parallel
process.
Path (b) from the Later row:
- services.hyprsunset.enable now follows config.nomarchy.toggles.
nightlight — symmetric with services.hypridle.enable ← toggles.idle.
Disabled toggle = no process running.
- extraArgs always reads from config.nomarchy.nightlightTemperature.
Drops the 6500K neutralising fork; when off the unit just doesn't
start.
- nomarchy-toggle-nightlight flips the running systemd user unit via
`systemctl --user start/stop hyprsunset.service` for instant
feedback, reads nightlightTemperature from state.json for the
notify-send line, and writes .nightlight back to state.json so the
next rebuild realigns services.hyprsunset.enable.
`nix flake check --no-build` + `bash -n` clean.
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.
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.
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.
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).
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).
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.
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).
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.
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 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.
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>
Pillar 3 Phase B, batch 2. Five `unused?` scripts that either duplicate
NixOS-native facilities or reference infrastructure Nomarchy doesn't
ship. All five had no callers anywhere in the tree.
- `nomarchy-rollback`: ran `nixos-rebuild rollback` after listing
`snapper` snapshots. NixOS already exposes the previous generation in
the boot menu and `nixos-rebuild --rollback`; Nomarchy uses
impermanence, not snapper.
- `nomarchy-snapshot`: wrapped `snapper create/restore`. Same reason —
snapper isn't part of Nomarchy. The script's "nomarchy-update can use
this" comment never came true; nomarchy-update has no reference to it.
- `nomarchy-migrate-state`: one-time migration from old
`~/.config/home-manager/state.json` and `/etc/nixos/state.json` to the
unified `~/.config/nomarchy/state.json`. The installer now seeds the
unified file directly; no current install needs the migration.
- `nomarchy-config-direct-boot`: added an EFI boot entry for a Nomarchy
UKI. We don't build a UKI (no references anywhere in `core/` or
`hosts/`), so the script targeted nonexistent infrastructure.
- `nomarchy-npx-install`: generated npx wrappers in `~/.local/bin/`. An
Arch idiom — on NixOS the path is `nix-shell -p nodejs` or a
declarative `home.packages` entry.
Kept `nomarchy-build-iso` and `nomarchy-build-live-iso` (the user-flagged
useful build wrappers) and surfaced them in README §2 in place of the
raw `nix build` command, which both removes the audit's `unused?` flag
on them and shortens the docs.
Regenerated docs/SCRIPTS.md (171 → 166 scripts; 28 `unused?` → 21).
Logged in docs/ROADMAP.md Shipped.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
