feat: update agent files

AGENTS.md

@@ -3,37 +3,99 @@
 ## Project Structure & Module Organization
 This repository is a Den-based NixOS flake. `flake.nix` evaluates `./modules` through `import-tree`, so normal `.nix` files under `modules/` are auto-imported.
 
-- `modules/hosts/` contains host-specific composition and hardware data for `polaris` and `orion`.
-- `modules/features/` contains aspects such as desktop, shell, services, and Neovim.
-- `modules/profiles/` holds higher-level bundles such as `workstation.nix`.
-- `modules/users/` defines user metadata and per-user behavior.
+- `modules/den.nix` imports the Den flake module and the `lux` namespace.
+- `modules/defaults.nix` sets repo-wide Den defaults, enables `den._.mutual-provider`, and configures `den.ctx.hm-host`.
+- `modules/schema.nix` defines the custom Den host and user schema used by this repo.
+- `modules/infra.nix` defines `den.hosts.x86_64-linux.<name>`, each host entity's `users` attrset, and the host/user data attached to those entities.
+- `modules/bundles.nix` defines bundle aspects that group other aspects. A bundle aspect may exist only to compose `includes`; `local-session` is an example.
+- `modules/hosts/` contains host-specific composition and hardware data for `orion`, `polaris`, and `zenith`.
+- `modules/features/` contains reusable aspects. In this repo, "feature" is only a directory label, not a Den primitive.
+- `modules/users/` defines per-user aspects.
 - `modules/secrets/` wires `sops-nix` and stores the encrypted `secrets.yaml`.
 - `.agents/den/` is a local checkout of Den with source, docs, and examples.
 
-Keep host files thin. Shared behavior belongs in `modules/features/` or `modules/profiles/`.
-When Den behavior is unclear, read `.agents/den/docs/`, `.agents/den/modules/`, and `.agents/den/templates/ci/` before guessing.
+Keep host files thin. Shared behavior belongs in `modules/features/` or `modules/bundles.nix`.
+When Den behavior is unclear, read `.agents/den/modules/` and `.agents/den/nix/lib/` first. Use `.agents/den/templates/ci/` as example code. Use `.agents/den/docs/` only for design rationale, terminology, and usage guidance.
+Do not infer Den behavior from surface symptoms or from where an aspect is included; reason from the actual context pipeline.
 
-## Build, Test, and Development Commands
+## Den Mental Model
+Den is aspect-first and context-driven.
+
+- Host, user, and home are entity kinds in Den. This repo defines host and user entities; it does not define standalone home entities under `modules/`.
+- An aspect is the unit of behavior. A single aspect may define `nixos`, `homeManager`, `darwin`, `user`, or other class fragments for one concern.
+- A context stage applies a resolved aspect to a context; Den then follows `into.*` and `provides.*`.
+- `homeManager` is a forwarding class.
+
+In practice:
+
+- Including an aspect does not by itself create a forwarding path.
+- Parametric matching does not by itself create a forwarding path.
+- A class fragment reaches its final option path only if a context stage or forwarding class actually puts it there.
+- If you cannot name the context stage and forwarding path, treat the claim as unverified.
+
+## Den Context Stages And Forwarding Mechanisms
+These are the mechanisms most relevant to the context pipeline in this repo.
+
+- `den.ctx.host`: host context stage; applies `fixedTo { host; } host.aspect`
+- `den.ctx.user`: user context stage from `den.ctx.host.into.user`; applies `fixedTo { host; user; } user.aspect`
+- `den._.mutual-provider`: battery included on `den.ctx.user` in this repo; routes host-to-user and user-to-host through `provides.<name>`, host-to-all-users through `provides.to-users`, user-to-hosts through `provides.to-hosts`, and user-to-other-users on the same host through the same user context pipeline. In Den generally it also has standalone-home behavior, but this repo does not use standalone `den.homes`
+- `den.ctx.hm-host` / `den.ctx.hm-user`: derived home-env context stages
+- `den._.define-user`: battery included by `den.default` in this repo; defines base OS user fields and base `homeManager.home.username` / `home.homeDirectory` fields
+- `homeManager`: forwarding class into `home-manager.users.<name>`
+- `den._.os-user`: framework battery forwarding the `user` class into `users.users.<name>`; useful in Den generally, but not used in this repo today
+- `den._.forward`: battery for custom class/path forwarding
+
+## Den Helper Functions
+These are the Den helpers that matter most in this repo.
+
+- `den.lib.perHost`: exact `{ host }` wrapper
+- `den.lib.perUser`: exact `{ host, user }` wrapper
+- `den.lib.perHome`: exact `{ home }` wrapper; not used by this flake today
+- `den.lib.parametric`: explicit parametric wrapper; default matching is `atLeast`
+- `den.lib.parametric.exactly`: explicit exact-match wrapper
+
+## Den Forwarding Proof Obligation
+When making or reviewing any Den forwarding change, do not infer behavior from where code is declared or included.
+
+You must identify all four of these explicitly:
+
+1. Source: which aspect actually owns the class fragment?
+2. Context stage: which `den.ctx.*` stage applies it?
+3. Destination: which final evaluated option path should contain the result?
+4. Mechanism: which `into.*` transition reaches the context stage, and which class application, `provides.*`, forwarding class, or `den._.forward` step places it at the destination?
+
+If any of those answers are missing, unclear, or based on analogy, treat the claim as unverified.
+
+Before presenting a forwarding claim as a recommendation or review finding, verify it at the evaluated destination with `nix eval`.
+
+Minimum checks:
+
+- host-selected `homeManager` behavior: inspect `nixosConfigurations.<host>.config.home-manager.users.<user>`
+- OS user forwarding via `user` class: inspect `nixosConfigurations.<host>.config.users.users.<user>`
+- mutual host/user forwarding through `provides.<name>`, `provides.to-users`, or `provides.to-hosts`: inspect the final destination option, not the declaration site
+- custom forwarding through `den._.forward`: inspect the exact target path created by the forwarder
+
+## Validation And Development Commands
 Run commands from the repository root.
 
-- `nix build .#nixosConfigurations.polaris.config.system.build.toplevel --show-trace`: evaluate and build the Polaris system.
-- `nix build .#nixosConfigurations.orion.config.system.build.toplevel --show-trace`: evaluate and build the Orion system.
-- `nixos-rebuild build --flake .#<host>`: use the standard rebuild path without activating it.
-- `nix fmt`: format Nix files using the flake-provided formatter.
+- `nix build --no-link --show-trace .#nixosConfigurations.<host>.config.system.build.toplevel`: baseline validation for one host without activation and without creating a `result` symlink.
+- `nix build --no-link --show-trace .#nixosConfigurations.orion.config.system.build.toplevel .#nixosConfigurations.polaris.config.system.build.toplevel .#nixosConfigurations.zenith.config.system.build.toplevel`: validate all currently defined hosts in one invocation.
+- `nixos-rebuild build --flake .#<host>`: use the standard rebuild path without activation when you specifically want `nixos-rebuild` semantics.
+- `nix fmt`: format Nix files using the flake-provided `nixfmt` formatter.
 - `nix eval .#nixosConfigurations.<host>.config.<option>`: inspect a single option while iterating.
 
-`nix flake check` is useful for evaluation, but this repo does not define an automated test suite.
+This repo does not define a `checks` output or a first-party test suite. Treat evaluation and build-only checks as the baseline. `nix flake check` is therefore not the baseline validation command here. `nixos-rebuild dry-activate` is not a baseline validation command either: it is activation-oriented, applies to the target system being rebuilt, and its own help text says the reported change set is not guaranteed to be complete.
+
+For Den context-stage or forwarding changes, use the destination checks above.
 
 ## Coding Style & Naming Conventions
 Use two-space indentation and standard Nix attrset formatting. Prefer small `let` bindings, lowerCamelCase local names, and lowercase file names such as `sops-password.nix`. Match the surrounding module style instead of reformatting unrelated code.
 
-Prefer Den composition through `includes`; avoid host-specific duplication when a reusable aspect is clearer.
-
-## Testing Guidelines
-There are no first-party unit tests. Treat evaluation and build-only checks as the baseline. For scoped changes, run the matching `nix build` target first, or `nixos-rebuild build --flake .#<host>` when you want the standard rebuild path without activation. Activation and switching are manual steps and should not be performed by contributors or agents.
+Prefer Den composition through `includes`; avoid host-specific duplication when a reusable aspect or bundle aspect is clearer.
+Keep the configuration aspect-first. When a class fragment must cross context boundaries, express that through an explicit forwarding mechanism instead of relying on implicit host/user propagation.
 
 ## Commit
 Follow the history style: short imperative subjects, optionally with a conventional prefix, for example `refactor: restructure openssh config`. Keep each commit focused on one concern.
 
 ## Security & Configuration Tips
-Never commit plaintext secrets. Add or update secrets through `modules/secrets/secrets.yaml` and reference them via `config.sops.secrets.<name>.path`. Be explicit about firewall, SSH, disk, or boot changes; those are the highest-risk edits here.
+Never commit plaintext secrets. Add or update secrets through `modules/secrets/secrets.yaml` and reference them via `config.sops.secrets.<name>.path`. Be explicit about firewall, SSH, disk, boot, or firmware changes; those are the highest-risk edits here.

SESSION_LOG.md

@@ -1,152 +0,0 @@
-# Session Log
-
-## Current Repo State
-- The git worktree is dirty. Many files were already modified before or during this session. Do not revert unrelated changes.
-- New main host/user additions are already in place:
-  - hosts: `polaris`, `zenith`, `orion`
-  - users: `kiri`, `ergon`
-- `zenith` is the Lenovo Yoga Slim 7 ProX 14ARH7 laptop.
-- `ergon` is the work user and is present on `polaris` and `zenith`, not `orion`.
-
-## Naming Decisions
-- Host names chosen:
-  - `polaris` = main machine
-  - `zenith` = laptop
-  - `orion` = VPS
-- Work user chosen:
-  - `ergon`
-
-## Den / Architecture Decisions
-- `kiri` stays on `den._.primary-user`.
-- `ergon` is explicit and should not use `den._.primary-user`.
-- Do not introduce a local `admin-user` battery yet. Keep repeated patterns explicit until they stabilize.
-- Prefer host files thin and move reusable behavior into `modules/features/` or `modules/profiles/`.
-
-## Den Helper Mental Model
-- `perHost` / `perUser` are stage gates, not just readability helpers.
-- `perUser` is not the same as `parametric.exactly`.
-- Actual behavior:
-  - `perUser` gates entry at exact `{ host, user }`, then evaluates the wrapped aspect under fixed `{ host, user }` with normal `atLeast` matching inside.
-  - `parametric.exactly` is an inner include matcher based on exact context shape.
-- Practical rule used in this repo:
-  - use `perHost` for host-owned NixOS config that must apply once per host
-  - use `perUser` for host-user-pair HM or NixOS config
-  - avoid `take.*` unless doing low-level Den plumbing
-
-## Niri / Display Model
-- `lux.niri` was intentionally collapsed back into one conceptual aspect in `modules/features/niri.nix`.
-- It now uses:
-  - `den.lib.perHost` for NixOS-side Niri setup
-  - `den.lib.perUser` for HM-side Niri settings
-- Host monitor layout is a host fact, not a user fact.
-- `den.schema.host.displays` exists and is the source of truth for monitor facts.
-- Current `polaris` display layout lives in `modules/infra.nix`.
-- `programs.niri.settings.outputs` is derived from `host.displays`, so both `kiri` and `ergon` on `polaris` get the same output configuration.
-- `displays` intentionally has no `enabled` flag; omission means absent.
-
-## SOPS / SSH / GPG Decisions
-- Repo-managed GPG was removed from `modules/features/ssh.nix`.
-- If commit signing is added later, prefer SSH signing rather than restoring repo-managed GPG.
-- Secret recipient policy currently is:
-  - one admin age recipient
-  - `orion` SSH host key recipient
-- `.sops.yaml` and `modules/secrets/secrets.yaml` were rekeyed to that policy.
-
-## Current SOPS Model
-- SOPS is now host-owned conceptually.
-- Current host schema fields:
-  - `sopsHostSshKeyPath`
-  - `sopsAdminKeyPath`
-  - `sopsAdminKeyUsers`
-- Current policy:
-  - `orion` uses `sops.age.sshKeyPaths = [ "/etc/ssh/ssh_host_ed25519_key" ]` for host-level NixOS decryption.
-  - local hosts (`polaris`, `zenith`) use `/var/lib/sops-nix/admin-key.txt` for host-level NixOS decryption.
-  - HM SOPS also uses the host-provisioned `/var/lib/sops-nix/admin-key.txt`, but only for users listed in `host.sopsAdminKeyUsers`.
-- Shared reader group:
-  - `sops-users`
-- Current host metadata in `modules/infra.nix`:
-  - `polaris.sopsAdminKeyPath = "/var/lib/sops-nix/admin-key.txt"`
-  - `polaris.sopsAdminKeyUsers = [ "kiri" "ergon" ]`
-  - `zenith.sopsAdminKeyPath = "/var/lib/sops-nix/admin-key.txt"`
-  - `zenith.sopsAdminKeyUsers = [ "kiri" "ergon" ]`
-  - `orion.sopsAdminKeyPath = "/var/lib/sops-nix/admin-key.txt"`
-  - `orion.sopsAdminKeyUsers = [ "kiri" ]`
-  - `orion.sopsHostSshKeyPath = "/etc/ssh/ssh_host_ed25519_key"`
-- Important operational caveat:
-  - the admin key file is expected to be provisioned out-of-band on hosts
-  - config creates `/var/lib/sops-nix` via tmpfiles and adds listed users to `sops-users`, but does not create the private key itself
-
-## SSH Recovery Policy
-- `orion` is treated as the remote recovery-critical host.
-- `modules/features/services/openssh.nix` now owns both:
-  - OpenSSH base config
-  - user `authorizedKeys`
-- Recovery assertions now enforce for `requiresSshRecovery = true`:
-  - OpenSSH enabled
-  - password auth disabled
-  - root login disabled
-  - `sshRecoveryUsers` non-empty
-  - every recovery user exists
-  - every recovery user has plain `authorizedSshKeys`
-  - `sopsHostSshKeyPath` non-null
-  - SSH exposed through firewall
-- `AllowUsers = lib.attrNames host.users` is still the intended model.
-
-## Recent Validation Results
-- Successfully built after the Niri / SOPS / SSH refactors:
-  - `nix build .#nixosConfigurations.polaris.config.system.build.toplevel --show-trace`
-  - `nix build .#nixosConfigurations.orion.config.system.build.toplevel --show-trace`
-  - `nix build .#nixosConfigurations.zenith.config.system.build.toplevel --show-trace`
-- Verified by evaluation:
-  - `polaris` Niri outputs for `kiri` and `ergon` match
-  - local hosts resolve `config.sops.age.keyFile = "/var/lib/sops-nix/admin-key.txt"`
-  - `orion` resolves `config.sops.age.sshKeyPaths = [ "/etc/ssh/ssh_host_ed25519_key" ]`
-  - HM SOPS for allowed users resolves `"/var/lib/sops-nix/admin-key.txt"`
-  - `ergon@polaris` has `["sops-users", "wheel", "networkmanager"]`
-  - tmpfiles includes `d /var/lib/sops-nix 0750 root sops-users -`
-
-## Remaining Warnings / Caveats
-- Builds still emit pre-existing Home Manager default-change warnings:
-  - `gtk.gtk4.theme`
-  - `xdg.userDirs.setSessionVariables`
-  - `programs.git.signing.format`
-- These warnings were not addressed in this session.
-- There is no deployment wrapper or automated bootstrap tooling yet.
-- `nixos-anywhere --copy-host-keys` remains the intended `orion` install approach when preserving the SSH host key for first-boot SOPS decryption.
-
-## Architecture Contract
-- Added `ARCHITECTURE.md` as the single durable reference for the repo's intended 1.0 structure.
-- The contract is grounded in the current codebase:
-  - `schema` and `infra` own facts
-  - `users` own cross-host user baselines
-  - `features` own reusable behavior
-  - `profiles` and `environments` own bundling
-  - `hosts` stay thin and compose the final machine shape
-- Kept the existing Den helper convention explicit:
-  - `perHost` and `perUser` are stage gates
-  - `parametric.exactly` is only for exact inner matching
-  - avoid new local batteries until the pattern is stable
-- No repo redesign was done; this was documentation only.
-- Validation:
-  - doc-only change
-  - no `nix build` run in this session
-- Small open question for later:
-  - whether `ARCHITECTURE.md` should stay standalone or also be linked from `AGENTS.md` / future README if a contributor-facing index is added
-
-## Architecture Simplification
-- Collapsed `environments` into `profiles`.
-- Current rule is now simpler:
-  - `features` are the smallest reusable behavior units
-  - `profiles` are all named bundles larger than a single feature
-  - `hosts` still own final composition and explicit host-specific exceptions
-- `modules/environments.nix` was removed.
-- `graphical` and `development` now live under `lux.profiles._`.
-- Kept the repeated `provides.kiri` / `provides.ergon` host wiring explicit for now. The duplication is intentional until a shared host-composition pattern is clearly stable enough to justify extraction.
-- Validation:
-  - `nix build .#nixosConfigurations.polaris.config.system.build.toplevel --show-trace`
-  - `nix build .#nixosConfigurations.orion.config.system.build.toplevel --show-trace`
-  - `nix build .#nixosConfigurations.zenith.config.system.build.toplevel --show-trace`
-
-## MANUAL INTERVENTION NOTE BY HUMAN USER, NOT AI AGENT
-Removed `ARCHITECTURE.md`. Pinning down the architecture this explicitly feels too rigid and unnecessary.
-Perhaps a more generally applicable Design Philsophy would be more helpful and allow for more flexibility.

TASKS.md

@@ -1,188 +0,0 @@
-# Tasks
-
-This file is an execution queue for independent Codex sessions.
-
-Rules for every task:
-- Work in `/home/kiri/.config/nixos`.
-- Read `SESSION_LOG.md` first.
-- Preserve current architecture unless the task explicitly asks to refine it.
-- Keep unrelated changes out of scope.
-- Validate your work with the relevant `nix build` commands whenever possible.
-- Do not revert unrelated dirty-worktree changes.
-- Append a short entry to `SESSION_LOG.md` at the end of the task. The entry should record:
-  - important decisions made
-  - short reasoning behind those decisions
-  - important structural code changes
-  - validation results
-  Keep it concise and useful for the next independent session.
-
-## Task 1
-
-```text
-Work in /home/kiri/.config/nixos.
-
-Read AGENTS.md and SESSION_LOG.md first.
-
-Task: remove the remaining Home Manager default-change warnings without changing intended behavior.
-
-Known warnings from the previous session:
-- gtk.gtk4.theme
-- xdg.userDirs.setSessionVariables
-- programs.git.signing.format
-
-Likely files:
-- modules/features/theme.nix
-- modules/features/xdg.nix
-- modules/features/dev.nix
-
-Requirements:
-- Keep changes minimal and explicit.
-- Match surrounding Nix style.
-- Do not restructure unrelated parts of the repo.
-- Validate by building all three hosts:
-  - nix build .#nixosConfigurations.polaris.config.system.build.toplevel --show-trace
-  - nix build .#nixosConfigurations.orion.config.system.build.toplevel --show-trace
-  - nix build .#nixosConfigurations.zenith.config.system.build.toplevel --show-trace
-
-Done when:
-- the known warning set above no longer appears
-- all three builds succeed
-
-Expected output:
-- the code changes
-- the validation results
-- a short explanation of the final choices
-- a short appended entry in SESSION_LOG.md for the next session
-```
-
-## Task 2
-
-```text
-Work in /home/kiri/.config/nixos.
-
-Read AGENTS.md and SESSION_LOG.md first, then inspect the current module structure.
-
-Task: define a short architecture contract for the repo's intended 1.0 state.
-
-The goal is not to redesign the repo. The goal is to document the structure and philosophy that should remain stable after the current cleanup phase.
-
-The document should cover:
-- the layering model of the repo
-- where things should go
-- how to think about hosts vs users vs features vs profiles vs environments
-- the practical mental model for Den helper usage
-- the abstraction bar for introducing new batteries
-- how to add or remove a host, user, or feature cleanly
-
-Requirements:
-- Keep it concise and operational.
-- Ground it in the current codebase, not wishful architecture.
-- Use the existing decisions in SESSION_LOG.md, especially the Den helper mental model.
-- Prefer one clear reference document over scattered notes.
-
-Done when:
-- there is one short durable architecture reference in the repo
-- it reflects the actual current repo structure
-- it is specific enough to guide future changes
-
-Expected output:
-- the new or updated doc
-- a short summary of the principles it establishes
-- any small open questions that should be decided later
-- a short appended entry in SESSION_LOG.md for the next session
-```
-
-## Task 3
-
-```text
-Work in /home/kiri/.config/nixos.
-
-Read AGENTS.md and SESSION_LOG.md first.
-
-Task: audit the service composition and recovery behavior for the orion host, and make the ownership model clearer where needed.
-
-Important context:
-- orion is the remote recovery-critical host
-- modules/features/services/openssh.nix currently owns the base SSH and recovery assertions
-- modules/features/services/gitea.nix also writes services.openssh.settings.AllowUsers
-- the previous session intentionally tightened SSH recovery requirements
-
-Focus on:
-- modules/hosts/orion/default.nix
-- modules/features/services/openssh.nix
-- modules/features/services/caddy.nix
-- modules/features/services/gitea.nix
-- modules/features/services/vaultwarden.nix
-- modules/features/services/actual.nix
-- modules/features/services/radicale.nix
-- any other file directly involved in orion service composition
-
-Requirements:
-- Do not do broad architectural refactors outside this scope.
-- Prefer making ownership explicit over adding clever abstraction.
-- If a cross-module write is acceptable, document why.
-- If it is not acceptable, simplify it.
-- Validate with:
-  - nix build .#nixosConfigurations.orion.config.system.build.toplevel --show-trace
-
-Done when:
-- SSH policy ownership is clear
-- cross-module writes that affect recovery or exposure are removed, consolidated, or explicitly justified
-- orion still builds successfully
-- the final state is easier to explain than the starting state
-
-Expected output:
-- the code changes
-- what was ambiguous before
-- how the final ownership model works
-- validation results
-- a short appended entry in SESSION_LOG.md for the next session
-```
-
-## Task 4
-
-```text
-Work in /home/kiri/.config/nixos.
-
-Read AGENTS.md and SESSION_LOG.md first. Treat the "Den Helper Mental Model" section as the current convention baseline.
-
-Task: do a final structural audit and cleanup pass aimed at preparing the repo for an initial 1.0 state.
-
-This task has four parts:
-1. Validate every aspect/helper usage against the current Den helper conventions.
-2. Fix helper mismatches or explicitly justify them.
-3. Remove dead, stale, empty, or misleading scaffolding where safe.
-4. Scan the repo for patterns that might deserve extraction into reusable batteries, and produce a small decision list: introduce / defer / reject.
-
-The helper validation must review usage of:
-- den.lib.perHost
-- den.lib.perUser
-- den.lib.parametric.exactly
-- den.lib.parametric.atLeast
-- avoid take.* unless truly needed
-
-Important constraints:
-- The goal is repo clarity, not abstraction for its own sake.
-- A battery should only be introduced if it makes the repo simpler and reflects one stable underlying idea.
-- One explicit candidate to evaluate is a possible lux.admin-user battery, but do not assume it should exist.
-- Keep the repo grounded in the conventions already established by the previous session.
-
-Suggested approach:
-- inventory aspect/helper usage first
-- review mismatches and repeated patterns
-- decide what should remain explicit
-- make only the cleanup/refactor changes that are justified by that review
-
-Done when:
-- every aspect/helper use has been reviewed against the stated conventions
-- any mismatches are fixed or explicitly justified
-- the repo is simpler or clearer afterward
-- there is a short decision list for abstraction candidates, including lux.admin-user
-
-Expected output:
-- any code cleanup or helper-fix changes
-- a short audit summary
-- a decision list for abstraction candidates, including lux.admin-user
-- any residual risks or open questions
-- a short appended entry in SESSION_LOG.md for the next session
-```

modules/hosts/orion/default.nix

@@ -1,21 +1,24 @@
-{ lux, ... }:
+{ den, lib, lux, ... }:
 let
-  lingerForUsers = {
-    user.linger = true;
-  };
+  lingerForUsers = den.lib.perHost (
+    { host, ... }:
+    {
+      nixos.users.users = lib.mapAttrs (_: _: {
+        linger = true;
+      }) host.users;
+    }
+  );
 in
 {
   den.aspects.orion = {
-    provides.to-users = lingerForUsers;
-
-    includes = with lux.services._; [
+    includes = (with lux.services._; [
       caddy
       openssh
       vaultwarden
       radicale
       actual
       gitea
-    ];
+    ]) ++ [ lingerForUsers ];
 
     nixos =
       { pkgs, ... }:

modules/hosts/polaris/default.nix

@@ -15,6 +15,12 @@
       ];
     };
 
+    provides.ergon = {
+      includes = with lux; [
+        sops-password
+      ];
+    };
+
     nixos =
       {
         config,

modules/hosts/zenith/default.nix

@@ -14,6 +14,12 @@
       ];
     };
 
+    provides.ergon = {
+      includes = with lux; [
+        sops-password
+      ];
+    };
+
     nixos =
       { pkgs, ... }:
       {