lux/TASKS.md

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

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

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

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

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