The option surface (`enable`, `paths`) lived in core/home/overrides.nix
since 2026-05-18 but didn't do anything — paths was a reserved
attrset that never reached xdg.configFile.
Now wired: every entry in nomarchy.overrides.paths substitutes the
matching xdg.configFile.<key>.source at lib.mkForce priority, beating
Nomarchy's own lib.mkDefault writes. Other fields on the original
entry (recursive, etc.) survive via the standard module-system merge.
nomarchy.overrides.paths = {
"nomarchy/default/hypr/looknfeel.conf" = ./looknfeel.conf;
"waybar/style.css" = ./waybar.css;
};
Picked the attrset model from the row's two options rather than
runtime ~/.config/nomarchy/overrides/ directory discovery — Nix needs
every managed file declared at evaluation time, and the attrset
matches the explicit-config shape used everywhere else in the
Nomarchy surface.
docs/OPTIONS.md updated: both overrides.{enable,paths} entries get
real content + an example, the configOverrides row now contrasts
bulk-vs-per-file accurately, and the "Where these are defined" footer
drops the (reserved) tag.
`nix flake check --no-build` clean.
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.
- Reorganize directory structure into core/, features/, and themes/
- Colocate application Nix logic, configs, scripts, and theme overrides
- Implement 'Inversion of Control' for theming: apps now pull theme-specific layouts
- Update flake.nix and shared library paths to match the new structure
- Document the new Feature-Centric architecture in README.md
