title: Evaluate nixos-configs repo structure

description:
# Research Goal
Evaluate the structure of nixos-configs to identify areas for improvement. The deliverable is a set of child beads—each containing prompts for deeper exploration and actionable improvement plans.

## Research Methodology
Use `/humanlayer:research_codebase_nt` pattern with parallel subagents:
- **codebase-locator**: Find files and components
- **codebase-analyzer**: Understand how code works
- **codebase-pattern-finder**: Find similar implementations and patterns

## Focus Areas (research all 7)

| Area | Questions to Answer |
|------|---------------------|
| **Flake Structure** | Is flake.nix well-organized? Are inputs minimal? Module composition clear? |
| **System Roles** | Roles properly scoped? Duplication? Consistent option patterns? |
| **Home-Manager Roles** | Clean separation from system roles? Reusable across platforms? |
| **Machine Configs** | Are machines DRY? Shared patterns extracted? Hardware abstractions clean? |
| **Custom Packages** | Packages well-structured? Overlay usage optimal? |
| **Cross-Platform** | Darwin/WSL/Steam Deck patterns consistent? Code reuse? |
| **Scripts & Utilities** | Flake apps organized? Automation opportunities? |

## Deliverables
1. **Summary of current state** for each focus area
2. **Child beads** for each area with improvement potential, containing:
   - Prompt: "Use `/humanlayer:research_codebase_nt` to analyze [specific aspect]"
   - Prompt: "Use `/humanlayer:create_plan_nt` to plan [specific improvement]"
3. **Recommended priority order** for addressing improvements

## Key Files to Analyze
- `flake.nix` (9.4KB) - Primary target
- `roles/default.nix` - System role patterns
- `home/roles/default.nix` - Home-manager role patterns
- `machines/*/configuration.nix` - Per-machine patterns
- `packages/default.nix` - Custom package overlay

status: closed

issue_type: task

created_by: johno

close_reason: Completed via detailed sub-evaluations: Flake Structure, System Roles, Home-Manager Roles, Machine Configs, Custom Packages, Cross-Platform Patterns, Scripts & Utilities. Follow-up beads created for identified improvements.

type: blocks

depends_on_id: nixos-configs-auw

depends_on_id: nixos-configs-dew

depends_on_id: nixos-configs-pbk

depends_on_id: nixos-configs-und

depends_on_id: nixos-configs-rrb

depends_on_id: nixos-configs-geh


title: Extract shared NixOS/Darwin base config

description: From Flake Structure evaluation: roles/default.nix and roles/darwin.nix share ~50% duplicated code (timezone, base packages, nix settings, gc config). Create roles/common.nix to reduce duplication.


title: Promote john-endesktop to k3s leader node

description: Migrate the k3s control plane from nucdeb1 to john-endesktop. This involves promoting john-endesktop from worker to leader and demoting/removing nucdeb1 from leader role.

status: open

author: johno

text:
## k3s-upgrade Label Requirement

NixOS nodes must be labeled with `k3s-upgrade=disabled` to exclude them from the system-upgrade-controller:

```bash
kubectl label node <node-name> k3s-upgrade=disabled
```

The system-upgrade-controller tries to upgrade k3s by replacing the binary in-place, which fails on NixOS because /nix/store is immutable. On NixOS, k3s upgrades happen through updating nixpkgs and rebuilding.

The agent-plan has been patched to exclude nodes with this label.


title: Fix conflicting audio role config

description: From System Roles evaluation: The audio role has conflicting services.pulseaudio config present while pipewire is enabled. PipeWire replaces PulseAudio, so the pulseaudio config should be removed.

issue_type: bug


title: When building the USB image, find a way to pre-run doom sync

description: After booting into a live usb, if I want to run emacs I must first run `doom sync` - which also requires internet access. This is time consuming and annoying.

acceptance_criteria: Upon booting into a live usb image, `emacs -nw` opens emacs to the doom splash screen

close_reason: Implemented pre-built Doom Emacs for live USB using nix-doom-emacs-unstraightened. Added new 'prebuiltDoom' option to the emacs role that builds all Doom packages at nix build time, eliminating the need for doom sync after boot.


title: Mu4e emails sending without body content

notes:
Gitea issue #2: https://git.johnogle.info/johno/nixos-configs/issues/2

PR: https://git.johnogle.info/johno/nixos-configs/pulls/4

close_reason: Duplicate of nixos-configs-9l8


title: Enable CI for nixos-configs repo

description:
Set up continuous integration for the nixos-configs repository.

## Goals
- Validate flake.nix syntax and structure on PRs/pushes
- Run `nix flake check` to catch evaluation errors early
- Consider building key configurations to catch build failures

## Considerations
- Choose CI platform (GitHub Actions, etc.)
- Cache nix store for faster builds
- Decide which configurations to build (all vs critical subset)

text: PR created: https://git.johnogle.info/johno/nixos-configs/pulls/17


title: Remove wixos (WSL) configuration

description: WSL is no longer used. Remove the wixos machine configuration entirely from the flake and any associated home-manager config.

text: PR: https://git.johnogle.info/johno/nixos-configs/pulls/20


title: Migrate nucdeb2 from Proxmox+Debian to NixOS

description: Replace the Proxmox+Debian installation on nucdeb2 with NixOS. Document the migration process thoroughly to serve as a guide for migrating nucdeb1 and nucdeb3.


title: Migrate k3s cluster nodes to NixOS

issue_type: epic

depends_on_id: nixos-configs-uje


title: Create k3s-node role and apply to john-endesktop as worker

description: Create a reusable k3s-node NixOS role/module. Apply it to john-endesktop configured as a worker node joining the existing cluster.

notes:
## Research Notes (2026-01-10)

### Current State
- No k3s service configuration exists in codebase
- john-endesktop is currently NFS server providing storage to external k3s cluster
- kubectl home role exists at `home/roles/kubectl/`
- origin/k3s branch has prior work using SOPS (not wanted)

### Implementation Requirements
1. Create `roles/k3s-node/default.nix` with options:
   - `enable` - Enable k3s
   - `role` - "server" or "agent" (default: agent)
   - `serverAddr` - URL to join (default for agent: https://10.0.0.222:6443)
   - `tokenFile` - Path to token (default: /etc/k3s/token)
   - `extraFlags` - Additional k3s flags
   - `gracefulNodeShutdown` - Enable graceful shutdown

2. Add firewall rules:
   - TCP: 6443 (API), 2379-2380 (etcd HA)
   - UDP: 8472 (flannel VXLAN)

3. Import in `roles/default.nix`

4. Enable on john-endesktop as agent

### Token Storage
Use Bitwarden + bootstrap script (consistent with kubectl role):
```bash
sudo mkdir -p /etc/k3s
rbw get k3s-cluster-token | sudo tee /etc/k3s/token > /dev/null
sudo chmod 600 /etc/k3s/token
```

### Key Files
- `roles/bluetooth/default.nix` - Simple role pattern
- `roles/nvidia/default.nix` - Complex role pattern
- `machines/john-endesktop/configuration.nix` - Host to update

### Research Doc
`thoughts/shared/research/2026-01-10-k3s-node-role-requirements.md`

close_reason: Implemented k3s-node role and enabled on john-endesktop as agent. Node joined cluster successfully.


title: Add Claude skill for parallel bead processing workflow

description:
## Summary
Add a Claude skill to the home development role that orchestrates parallel bead processing using subagents.

## Workflow

### Phase 1: Selection
1. Run `bd ready` to get list of all ready beads
2. Prompt user to select which beads they want to work on (multi-select)

### Phase 2: Parallel Implementation (subagents)
For each selected bead, spin up a subagent responsible for:
1. Creating a branch/worktree for the bead (e.g., `git worktree add`)
2. Working on the bead until its acceptance criteria are met
3. Committing and pushing the changes to the branch
4. Opening a PR to merge those changes
   - PR description must reference the bead ID
   - If the bead references an external issue number (e.g., GitHub issue), include that in the PR description as well

### Phase 3: Parallel Review (subagents)
Spin up another set of subagents to:
1. Read each PR and its changes
2. Leave review comments on the PR

### Phase 4: Cleanup & Summary
1. Clean up the worktrees
2. Provide links and summaries to each PR
3. Include failure status if any subagent was unable to make progress

## Acceptance Criteria
- [ ] Skill is added to home development role configuration
- [ ] Skill prompts user with multi-select for bead selection
- [ ] Subagents create isolated worktrees for each bead
- [ ] Subagents work until acceptance criteria met or report blockers
- [ ] Changes are committed and pushed
- [ ] PRs are opened automatically
- [ ] PR descriptions reference the bead ID
- [ ] PR descriptions include linked external issue numbers from the bead
- [ ] Review subagents provide meaningful feedback
- [ ] Worktrees are cleaned up after completion
- [ ] Final summary includes PR links, status, and any failures

## Location
`home/roles/development/` or appropriate skill location for Claude skills

## Notes
- Consider error handling for subagent failures
- Consider parallelism limits to avoid overwhelming resources
- Should integrate with existing beads workflow (`bd` commands)

issue_type: feature


title: Iterate parallel beads skill

notes:
Gitea issue #12: https://git.johnogle.info/johno/nixos-configs/issues/12

After opening a PR, instead of closing the bead we should mark it with 'in review' status. The PR should be included in the bead notes.

Also want an additional skill to reconcile beads with PRs - if a PR is merged then the bead should be closed.

PR: https://git.johnogle.info/johno/nixos-configs/pulls/14


title: Mu4e emails aren't sending body content

description:
I tried to send an email to Anthony from The Springs and the to, cc, subject all worked as expected. But the body I wrote was totally missing.

Source: Gitea issue #2

notes:
Source: Gitea issue #2

PR: https://git.johnogle.info/johno/nixos-configs/pulls/4


title: Remove duplicate home-manager imports in wixos/zix790prors

description: From Flake Structure evaluation: wixos and zix790prors configurations include inputs.home-manager.nixosModules.home-manager redundantly (already in nixosModules).


title: Evaluate System Roles

description:
# Investigation: System Roles

## Questions to Answer
- Are roles properly scoped?
- Is there duplication between roles?
- Are option patterns consistent?

## Key Files
- `roles/default.nix` - System role patterns
- `roles/*/default.nix` - Individual role definitions

## Approach
1. Use `/humanlayer:research_codebase_nt` to analyze role structure
2. Identify duplication or inconsistencies
3. Use `/humanlayer:create_plan_nt` to plan consolidation if needed

close_reason:
# System Roles Evaluation - Complete

## Overview

The NixOS configuration uses a role-based architecture at `/home/johno/nixos-configs/roles/` with 12 distinct roles for NixOS systems plus a separate Darwin configuration.

## Role Structure Summary

### Top-Level Roles
| Role | Pattern | Options | Description |
|------|---------|---------|-------------|
| audio | mkEnableOption | enable | PipeWire/PulseAudio with audio tools |
| bluetooth | mkEnableOption | enable | Bluetooth with Blueman |
| btrfs | Comprehensive | enable, filesystems (nested) | BTRFS management with scrub/dedup/balance |
| desktop | Composite | enable + suboptions | Desktop environment with X11/Wayland/KDE |
| kodi | Comprehensive | enable, autologin, wayland, jellyfinScaleFactor, appLauncherServer | Media center setup |
| nfs-mounts | mkEnableOption | enable, requireMount (TODO) | NFS client mounts |
| nvidia | mkEnableOption | enable | NVIDIA driver utilities |
| printing | mkEnableOption | enable | CUPS with Avahi/network printing |
| remote-build | Multi-config | enableBuilder, builders[], fallbackToLocalBuild | Distributed build client/server |
| spotifyd | mkEnableOption | enable | Spotify Connect daemon |
| users | Mixed | enable, extraGroups, kids | User account management |
| virtualisation | mkEnableOption | enable | Docker + libvirt |

### Desktop Sub-Roles
- x11.nix - i3 window manager with DDC/CI monitor control
- wayland.nix - Sway compositor with Wayland tools
- kde.nix - Plasma 6 desktop
- sddm.nix - SDDM display manager
- gaming.nix - Steam, Lutris, emulators
- programs.nix - Common desktop programs (always enabled when desktop.enable=true)
- steamos.nix - Jovian/SteamOS for Steam Deck

## Findings

### Strengths

1. **Consistent Option Pattern**: Most roles follow `roles.<name>.enable` with `mkIf cfg.enable` guards
2. **Proper Scoping**: Each role is self-contained in its own directory/file
3. **Composability**: Roles can be combined without conflicts (e.g., spotifyd enables audio role)
4. **Sophisticated Features**: btrfs and remote-build roles have well-designed nested option structures

### Issues and Inconsistencies

1. **Option Pattern Variance**:
   - Most use `mkEnableOption` (audio, bluetooth, etc.)
   - remote-build uses `mkOption` for `enableBuilder` (different naming)
   - desktop suboptions use `mkOption type=bool` instead of mkEnableOption
   - kodi options lack proper type definitions for some options

2. **Duplication Between roles/default.nix and roles/darwin.nix**:
   - Both define identical `environment.systemPackages` (git, glances, pciutils, tree, usbutils, vim)
   - Both have identical nix settings (experimental-features, max-jobs, trusted-users, etc.)
   - Both have identical gc settings
   - Both have `nixpkgs.config.allowUnfree = true`
   - darwin.nix duplicates timezone and commented buildMachines config

3. **Hardcoded Values**:
   - printing role has hardcoded printer URI (ipp://brother.oglehome/ipp/print)
   - nfs-mounts hardcodes NFS server IP (10.0.0.43)
   - virtualisation role hardcodes "johno" for docker group

4. **Incomplete Implementations**:
   - nfs-mounts has TODO: implement requireMount
   - audio role has conflicting services.pulseaudio config while pipewire is enabled
   - nvidia role only adds packages, no driver configuration

5. **Missing Type Definitions**:
   - users.extraGroups and kodi.autologin/wayland lack type annotations

## Role Usage Across Machines

| Machine | Roles Used |
|---------|------------|
| zix790prors | audio, bluetooth, desktop (full), nfs-mounts, nvidia, printing, remote-build (builder), users, virtualisation |
| nix-book | audio, bluetooth, desktop (wayland+kde), nfs-mounts, printing, remote-build (client), spotifyd, users, virtualisation |
| nix-deck | audio, bluetooth, desktop (wayland+kde+steamos), remote-build (client), users |
| boxy | audio, bluetooth, desktop (wayland+kde), kodi, nfs-mounts, users |
| wixos (WSL) | audio, desktop (wayland), users |
| live-usb | audio, bluetooth, desktop (kde+x11+wayland) |
| john-endesktop | users only (ZFS server, minimal) |

## Recommendations

1. **Extract common config**: Create a base role for shared NixOS/Darwin settings (packages, nix config, locale, timezone)

2. **Standardize option patterns**:
   - Use mkEnableOption consistently for boolean enables
   - Add proper type annotations to all options

3. **Parameterize hardcoded values**:
   - Make printer URI configurable in printing role
   - Make NFS server configurable in nfs-mounts role
   - Make user for docker group configurable

4. **Fix audio role**: Remove conflicting pulseaudio config (pipewire replaces it)

5. **Complete nvidia role**: Should configure hardware.nvidia or reference machine-specific config

6. **Consider steamos.nix location**: Currently requires manual import, could be auto-imported in desktop/default.nix


title: Move bootstrap/build-liveusb scripts to flake apps

description: From Scripts & Utilities evaluation: bootstrap.sh and build-liveusb.sh are standalone scripts at the repo root. Consider moving them to flake apps for consistency with update-doomemacs, update-claude-code, etc.

issue_id: nixos-configs-bli

text: PR: https://git.johnogle.info/johno/nixos-configs/pulls/23


title: Evaluate Home-Manager Roles

description:
# Investigation: Home-Manager Roles

## Questions to Answer
- Is there clean separation from system roles?
- Are roles reusable across platforms (Darwin/Linux/WSL)?
- Are option patterns consistent?

## Key Files
- `home/roles/default.nix` - Home-manager role patterns
- `home/roles/*/default.nix` - Individual home role definitions

## Approach
1. Use `/humanlayer:research_codebase_nt` to analyze home role structure
2. Check for platform-specific vs shared patterns
3. Use `/humanlayer:create_plan_nt` to plan improvements if needed

close_reason:
# Home-Manager Roles Evaluation Complete

## Overview
The home-manager roles structure is well-organized with 21 distinct roles providing modular user configuration management across Linux and Darwin platforms.

## Structure Analysis

### Role Directory Layout
- home/roles/default.nix - Shared role imports (cross-platform)
- 21 role subdirectories covering: base, development, desktop, emacs, aerospace, i3+sway, etc.
- Platform-specific base roles: base-darwin/, base-linux/

## Key Findings

### 1. Clean Separation from System Roles: GOOD
- Clear namespace: home.roles.* vs roles.*
- Home roles manage user packages/services, system roles manage OS-level config
- No duplication of concerns between home and system levels

### 2. Platform Reusability: EXCELLENT
- Platform segregation via base-* roles
- base-darwin/ imports: aerospace (macOS tiling)
- base-linux/ imports: plasma-manager, i3+sway
- 15 cross-platform shared roles in default.nix
- Platform guards in aerospace role with isDarwin assertion
- Conditional config in emacs using stdenv.isDarwin

### 3. Option Patterns: CONSISTENT
All roles follow pattern:
  options.home.roles.<name>.enable = mkEnableOption
  config = mkIf cfg.enable { ... }

Notable option extensions:
- aerospace: leader key, autoraise, ctrlShortcuts, sketchybar
- i3_sway: browser, extraSharedConfig, extraI3Config, extraSwayConfig
- development: allowArbitraryClaudeCodeModelSelection
- launchers: packages list for dynamic wrapper generation

## Strengths
1. Consistent patterns across all 21 roles
2. Excellent platform separation via base-linux/base-darwin
3. Flexible composition with enable flags
4. Rich options for complex roles (aerospace: 700+ lines, i3_sway: 500+ lines)
5. Clever solutions: kubectl Bitwarden integration, launchers role

## Minor Observations
- Gaming role is placeholder
- openscad-unstable in both office and 3d-printing
- kubectl duplicates shell functions for bash/zsh

## Conclusion
The home-manager roles system demonstrates excellent separation of concerns, cross-platform support, and consistent patterns. No major changes needed - structure is well-designed and maintainable.


title: Consolidate flake overlay configurations

description: From Cross-Platform evaluation: The overlay configuration is repeated 3x in flake.nix (nixosModules, nixosModulesUnstable, darwinModules). Could extract to a shared function to reduce duplication.

text: PR: https://git.johnogle.info/johno/nixos-configs/pulls/21


title: Parameterize hardcoded values in roles

description:
From System Roles evaluation: Several roles have hardcoded values that should be configurable:
- printing role: hardcoded printer URI (ipp://brother.oglehome/ipp/print)
- nfs-mounts: hardcoded NFS server IP (10.0.0.43)
- virtualisation: hardcoded 'johno' for docker group

issue_id: nixos-configs-fkt

text: PR: https://git.johnogle.info/johno/nixos-configs/pulls/19


title: Evaluate Scripts & Utilities

description:
# Investigation: Scripts & Utilities

## Questions to Answer
- Are flake apps organized?
- Are there automation opportunities?
- Are scripts discoverable and documented?

## Key Files
- Flake apps definitions
- Shell scripts in the repo
- Utility modules

## Approach
1. Use `/humanlayer:research_codebase_nt` to analyze scripts and utilities
2. Identify missing automation opportunities
3. Use `/humanlayer:create_plan_nt` to plan improvements

close_reason:
# Scripts & Utilities Evaluation

## Summary
The NixOS config repository has a well-organized scripts and utilities system with good practices in place.

## Flake Apps (4 available apps)
All apps defined in flake.nix, cross-platform (x86_64-linux, aarch64-linux, aarch64-darwin):
- update-doomemacs: Updates DoomEmacs to latest commit with SHA256 refresh
- update-claude-code: Updates claude-code package from Homebrew cask (supports --dry-run)
- rotate-wallpaper: Cycles through wallpaper index
- upgrade: Meta-script updating flake + doom + claude + wallpaper

### Architecture Strengths
- Uses writeShellScriptBin with explicit dependency paths via makeBinPath
- Common dependencies (curl, jq, nix, git, sed, grep, coreutils, gawk) properly managed
- All scripts use set -euo pipefail for safety

## Standalone Scripts (2 root-level)
- bootstrap.sh: Initial system setup from remote flake
- build-liveusb.sh: Builds live USB ISO

## Custom Packages (/packages/) - 5 packages
1. claude-code - Multi-platform binary distribution with GCS URLs
2. tea-rbw - Wrapper around tea integrating with rbw for auth
3. app-launcher-server - Python HTTP server for launching allowlisted apps
4. vulkan-hdr-layer - HDR graphics layer
5. perles - Go-based TUI for Beads issue tracking

## Recommendations
Medium Priority:
- Add help flags to all flake apps for consistency
- Consider adding nix run .#help app listing all available apps

Low Priority:
- Move bootstrap.sh and build-liveusb.sh to flake apps
- Add comments to packages/default.nix describing each package

## Missing Automation Opportunities
1. No auto-update mechanism (could add CI job or systemd timer)
2. No pre-commit hooks for Nix syntax validation
3. No flake.lock update notifications

## Conclusion
Well-designed scripts/utilities system using good Nix idioms. The flake apps pattern provides cross-platform consistency. Main gap is documentation/discoverability (minor for personal config). No blocking issues.


title: Extend nvidia role to include driver configuration

description: From System Roles evaluation: The current roles.nvidia only handles packages, not driver configuration. The hardware.nvidia block is duplicated in zix790prors and wixos. Extend the role to include driver config with options for open driver, power management, etc.


title: Evaluate Flake Structure

description:
# Investigation: Flake Structure

## Questions to Answer
- Is flake.nix well-organized?
- Are inputs minimal and up-to-date?
- Is module composition clear?

## Key Files
- `flake.nix` (9.4KB) - Primary target

## Approach
1. Use `/humanlayer:research_codebase_nt` to analyze flake.nix organization
2. Identify unnecessary inputs or outdated patterns
3. Use `/humanlayer:create_plan_nt` to plan improvements if needed

close_reason:
## Flake Structure Evaluation Summary

### Overall Assessment: Well-Organized

The flake.nix is reasonably well-organized for a personal NixOS configuration managing multiple machines across different platforms (NixOS, Darwin, Steam Deck).

---

### Inputs Analysis (11 inputs)

**Essential Inputs (correctly configured):**
- `nixpkgs` (25.11 stable) - Primary nixpkgs
- `nixpkgs-unstable` - For bleeding-edge packages
- `home-manager` / `home-manager-unstable` - Properly follows respective nixpkgs
- `nix-darwin` - For macOS support, follows nixpkgs
- `nixos-wsl` - For WSL support

**Specialized Inputs (justified):**
- `plasma-manager` / `plasma-manager-unstable` - KDE configuration
- `jovian` - Steam Deck support (follows nixpkgs-unstable)
- `beads` - Task management tooling

**Custom/Private Inputs:**
- `google-cookie-retrieval` - Personal tool from git.johnogle.info

**Note:** All inputs properly use `follows` for nixpkgs deduplication - this is a best practice.

---

### Module Composition

**Good Patterns:**
1. **Role-based architecture** - Both system (`roles/`) and home-manager (`home/roles/`) use a role pattern with `mkEnableOption`
2. **Machine separation** - Each machine has its own `configuration.nix` under `machines/<name>/`
3. **Stable/Unstable separation** - `nixosModules` vs `nixosModulesUnstable` for different base systems
4. **Platform separation** - `darwinModules` for macOS-specific configuration
5. **Overlay pattern** - Clean overlay providing `pkgs.unstable` and `pkgs.custom`

**Machine Coverage:**
- 7 NixOS systems: nix-book, boxy, wixos, zix790prors, live-usb, nix-deck, john-endesktop
- 1 Darwin system: johno-macbookpro

---

### Observations

**Strengths:**
1. Consistent structure across all machine definitions
2. Home-manager properly integrated with `useGlobalPkgs = true`
3. Custom packages accessible via `pkgs.custom`
4. Flake apps for common maintenance tasks (update-doomemacs, upgrade, etc.)
5. Compatibility shim for bitwarden->bitwarden-desktop rename

**Minor Issues:**
1. `wixos` and `zix790prors` include `inputs.home-manager.nixosModules.home-manager` twice (already in nixosModules)
2. Description is generic ("A very basic flake") - could be more descriptive
3. Some code duplication between nixosModules and nixosModulesUnstable overlays

**Not Issues:**
- Duplicate plasma-manager inputs (stable/unstable) are intentional for different nixpkgs bases

---

### Recommendations (Optional)

1. **Low priority:** Remove duplicate home-manager imports in wixos/zix790prors
2. **Low priority:** Update flake description to be more meaningful
3. **Low priority:** Could extract common overlay logic to reduce duplication

No blocking issues found. The flake is well-structured for its purpose.


title: Evaluate Machine Configs

description:
# Investigation: Machine Configs

## Questions to Answer
- Are machine configs DRY (Don't Repeat Yourself)?
- Are shared patterns extracted to roles?
- Are hardware abstractions clean?

## Key Files
- `machines/*/configuration.nix` - Per-machine patterns
- `machines/*/hardware-configuration.nix` - Hardware specifics

## Approach
1. Use `/humanlayer:research_codebase_nt` to analyze machine config patterns
2. Identify repeated config across machines
3. Use `/humanlayer:create_plan_nt` to plan extraction of shared patterns

close_reason:
## Machine Configuration Analysis Complete

### Summary
Analyzed 8 machine configurations across different platform types:
- **NixOS Desktop/Laptop**: nix-book, zix790prors, boxy, nix-deck, wixos
- **NixOS Server**: john-endesktop (ZFS/NFS)
- **NixOS Live USB**: live-usb
- **Darwin/macOS**: johno-macbookpro

### DRY Assessment: GOOD
The configuration is already well-factored with an extensive roles system covering:
- `audio`, `bluetooth`, `btrfs`, `desktop`, `kodi`, `nfs-mounts`, `nvidia`, `printing`, `remote-build`, `spotifyd`, `users`, `virtualisation`
- Desktop sub-roles: `x11`, `wayland`, `kde`, `sddm`, `gaming`, `steamos`

Machine configs are concise (40-115 lines) and focus on machine-specific settings only.

### DRY Violations Identified

**Minor (Low Priority)**:
1. **Boot loader** - `boot.loader.systemd-boot.enable = true` repeated in 5 machines. Could be a role option, but these are one-liners and machine-specific.

2. **NetworkManager** - `networking.networkmanager.enable = true` in 4 machines. Could be part of desktop role default.

3. **NVIDIA config duplication** - `hardware.nvidia` block duplicated in `zix790prors` and `wixos` with different values. The existing `roles.nvidia` only handles packages, not driver config.

4. **Graphics enable** - `hardware.graphics.enable = true` in 2 machines with manual `enable32Bit`. Could be part of gaming role.

### Hardware Configuration Assessment: CLEAN
Hardware configs properly use `nixos-generate-config` patterns. Notable improvements:
- `nix-book` and `zix790prors` use the new `roles.btrfs` abstraction for filesystem management with deduplication and scrubbing
- `nix-deck` uses Jovian modules for Steam Deck hardware

### Recommendations

1. **Extend nvidia role** - Move `hardware.nvidia` and `services.xserver.videoDrivers` config into `roles.nvidia` with options for open driver, power management, etc.

2. **Add AMD GPU role** - Create `roles.amdgpu` for machines like boxy with AMD graphics config.

3. **Consider boot role** - Could add `roles.boot` with common systemd-boot config, but benefit is marginal.

4. **Network role optional** - Could add `roles.network` but current per-machine network config is appropriate for flexibility.

5. **No action needed** - The current structure is already well-organized. The identified duplications are minimal and don't justify immediate refactoring.

### Architecture Quality: HIGH
- Clean separation: machine-specific vs shared roles
- Roles are composable with sensible options
- Hardware configs are properly isolated
- Flake structure is well-organized with stable/unstable variants
- Home-manager integration is consistent across machines


title: Consider removing unused vulkan-hdr-layer package

description: From Custom Packages evaluation: vulkan-hdr-layer in packages/ appears to be unused anywhere in the configuration. Decide whether to remove it or document its intended use.

issue_id: nixos-configs-pea

text: PR created: https://git.johnogle.info/johno/nixos-configs/pulls/22


title: Evaluate Cross-Platform Patterns

description:
# Investigation: Cross-Platform Patterns

## Questions to Answer
- Are Darwin/WSL/Steam Deck patterns consistent?
- Is code reuse maximized across platforms?
- Are platform-specific concerns properly isolated?

## Key Files
- Darwin machine configs
- WSL machine configs
- Steam Deck configs
- Platform-conditional role patterns

## Approach
1. Use `/humanlayer:research_codebase_nt` to analyze cross-platform patterns
2. Identify platform-specific vs shared code
3. Use `/humanlayer:create_plan_nt` to plan better code sharing

close_reason:
## Cross-Platform Pattern Evaluation

### Platform Overview

The repository supports **4 distinct platforms**:
1. **NixOS** (primary): 6 machines (zix790prors, nix-book, boxy, wixos, nix-deck, john-endesktop)
2. **Darwin/macOS**: 1 machine (johno-macbookpro/blkfv4yf49kt7)
3. **WSL (NixOS-WSL)**: 1 machine (wixos)
4. **Steam Deck**: 1 machine (nix-deck, using Jovian-NixOS)

### Architecture Analysis

#### Are Darwin/WSL/Steam Deck Patterns Consistent?

**MIXED**: The patterns are partially consistent but have notable differences:

**Consistent patterns:**
- All platforms use home-manager for user configuration
- All home configs import `./roles` (shared) + platform-specific base role
- Use of `home.roles` option system across all platforms
- Common `home.stateVersion = "24.05"` across all configs

**Inconsistent patterns:**
- WSL config embeds NVIDIA/graphics config directly rather than using a role
- Steam Deck uses `nixosModulesUnstable` (different module set) vs stable for others
- Darwin uses completely separate `darwinModules` with different role structure

#### Is Code Reuse Maximized?

**PARTIALLY - Rating: 7/10**

**Good reuse:**
- Home roles are well-factored - most roles work cross-platform
- `base` role uses `pkgs.stdenv.isLinux` for conditional behavior
- `emacs` role uses `pkgs.stdenv.isDarwin` to select macport vs standard emacs
- `aerospace` role properly guards Darwin-only features with assertion
- Shared wallpaper config across i3, sway, plasma-manager, sketchybar

**Duplication found:**
1. **roles/default.nix vs roles/darwin.nix**: ~50% duplicated code
   - Both define: time.timeZone, environment.systemPackages, nix.* settings
   - Darwin lacks: i18n settings, xserver.xkb, openssh, emergency mode config

2. **Flake module lists**: nixosModules/nixosModulesUnstable/darwinModules have overlapping overlay configs

3. **Home paths**: Darwin uses `/Users/johno` vs Linux `/home/johno` - handled correctly with mkForce

#### Are Platform-Specific Concerns Properly Isolated?

**GOOD - Rating: 8/10**

**Well isolated:**
- `home/roles/base-darwin` imports aerospace (Darwin-only)
- `home/roles/base-linux` imports plasma-manager, i3+sway (Linux-only)
- `aerospace` role has explicit Darwin assertion
- System roles (audio, bluetooth, desktop, etc.) are NixOS-only in roles/default.nix
- Steam Deck config imports `roles/desktop/steamos.nix` for Jovian integration

**Could improve:**
- WSL-specific config inline in machine config rather than a `wsl` role
- NVIDIA config duplicated in wixos vs using roles.nvidia

### Key Findings

#### Cross-Platform Role Structure
```
home/roles/
  default.nix          -- Shared roles (imported by all)
  base-darwin/         -- Darwin-specific (aerospace)
  base-linux/          -- Linux-specific (plasma-manager, i3+sway)
  aerospace/           -- Darwin-only with assertion
  plasma-manager/      -- Linux-only (imported via base-linux)
  i3+sway/            -- Linux-only (imported via base-linux)
  [other roles]        -- Cross-platform
```

#### Platform Conditionals Found (4 instances)
1. `packages/claude-code/default.nix:42` - autoPatchelfHook for Linux
2. `home/roles/emacs/default.nix:23` - emacs-macport vs emacs
3. `home/roles/base/default.nix:34` - randomizedDelaySec only on Linux
4. `home/roles/aerospace/default.nix:116` - Darwin-only assertion

### Recommendations

1. **Extract shared system config**: Create `roles/common.nix` for settings shared between NixOS and Darwin (timezone, nix settings, base packages)

2. **Create WSL role**: Move wixos NVIDIA/graphics config to `roles/wsl.nix` for reusability

3. **Consolidate flake overlays**: The overlay configuration is repeated 3x - could extract to a function

4. **Document platform matrix**: Add comments in flake.nix explaining which modules support which platforms

5. **Consider conditional imports**: Some roles (desktop, communication) have Linux-only packages but no guards - could add `lib.optionals pkgs.stdenv.isLinux`


title: Add platform compatibility guards to cross-platform roles

description: From Cross-Platform evaluation: Some roles like desktop and communication contain Linux-only packages but no guards. Add lib.optionals pkgs.stdenv.isLinux where appropriate to prevent issues on Darwin.

issue_id: nixos-configs-tcu

text: PR created: https://git.johnogle.info/johno/nixos-configs/pulls/25


title: Add skill to import Gitea issues as beads

description: Create a skill that imports open Gitea issues as beads, skipping those already imported

notes:
Technique from session:

1. Use `tea issues` to list open issues (not curl)
2. Use `tea issue N` to get full details
3. Check existing beads with `bd list` to find already-imported issues
4. Skip PRs that have bead IDs in title (e.g. '[nixos-configs-xxx]') or body ('Bead ID: xxx')
5. For new issues, create bead with:
   - Appropriate type (bug/feature/task based on issue content)
   - Priority P2 default
   - Notes containing Gitea issue URL
   - Description from issue body
6. Report what was imported vs skipped

PR: https://git.johnogle.info/johno/nixos-configs/pulls/15


title: Add --help flags to all flake apps

description: From Scripts & Utilities evaluation: Some flake apps (like update-claude-code) have --help, others don't. Add --help flags to all apps for consistency and discoverability.

text: PR: https://git.johnogle.info/johno/nixos-configs/pulls/24


title: Migrate nucdeb1 and nucdeb3 to NixOS

description: Follow the documented process from nucdeb2 migration to migrate nucdeb1 and nucdeb3 from their current Debian-based setups to NixOS with the k3s-node role.

issue_id: nixos-configs-uje


title: Add and use starship.rs

close_reason: Closed


title: Evaluate Custom Packages

description:
# Investigation: Custom Packages

## Questions to Answer
- Are packages well-structured?
- Is overlay usage optimal?
- Are packages up-to-date with nixpkgs conventions?

## Key Files
- `packages/default.nix` - Custom package overlay
- `packages/*/default.nix` - Individual package definitions

## Approach
1. Use `/humanlayer:research_codebase_nt` to analyze package structure
2. Check overlay patterns and composition
3. Use `/humanlayer:create_plan_nt` to plan improvements if needed

close_reason:
# Custom Packages Evaluation Complete

## Overview
The nixos-configs repository contains 5 custom packages, all managed through a single `packages/default.nix` file that exposes them via `pkgs.custom.*` overlay.

## Package-by-Package Analysis

### 1. claude-code (Well-Structured)
- **Purpose**: Fetches Claude Code CLI directly from Google Cloud Storage, bypassing npm registry (needed for corporate network restrictions)
- **Structure**: Excellent - uses `stdenv.mkDerivation` with proper multi-platform support (4 platforms)
- **Update mechanism**: Has automated `update.sh` script that fetches version/hashes from Homebrew cask - very well designed
- **Documentation**: Includes comprehensive README.md
- **Usage**: Exposed via overlay to `pkgs.unstable.claude-code` for Darwin machines
- **Note**: Also has an unused `npm.nix` with placeholder hash - appears to be abandoned attempt

### 2. vulkan-hdr-layer (Well-Structured)
- **Purpose**: Vulkan layer for HDR support
- **Structure**: Proper `stdenv.mkDerivation` with meson build system
- **Issue**: Uses commit hash version `63d2eec` (unstable version) - consider using tagged releases
- **Note**: Not currently used anywhere in the configuration (orphaned package?)

### 3. tea-rbw (Simple Wrapper)
- **Purpose**: Wrapper around `tea` (Gitea CLI) that integrates with rbw (Bitwarden CLI) for authentication
- **Structure**: Simple `writeShellScriptBin` - appropriate for this use case
- **Usage**: Used in `home/roles/development/default.nix`

### 4. app-launcher-server (Simple Wrapper)
- **Purpose**: HTTP server for launching allowlisted applications (Firefox, Kodi)
- **Structure**: Python script with `writeShellScriptBin` wrapper - clean design
- **Usage**: Used in `roles/kodi/default.nix` for media center control

### 5. perles (Well-Structured)
- **Purpose**: TUI for Beads issue tracking system
- **Structure**: Proper `buildGoModule` with GitHub fetch
- **Issue**: Uses `rev = "main"` instead of pinned commit - can cause reproducibility issues
- **Usage**: Used in `home/roles/development/default.nix`

## Overlay Integration
Packages are exposed via overlay in flake.nix:
```nix
custom = prev.callPackage ./packages {};
```
This is a clean, standard pattern.

## Observations

### Strengths
1. Single entry point (`packages/default.nix`) for all custom packages
2. Proper use of `callPackage` idiom
3. Good variety of build patterns (stdenv, buildGoModule, writeShellScriptBin)
4. Excellent automated update script for claude-code
5. Proper meta attributes on most packages

### Issues/Recommendations
1. **vulkan-hdr-layer appears unused** - consider removing if not needed
2. **perles uses `rev = "main"`** - should pin to specific commit for reproducibility
3. **npm.nix is unused** - leftover file in claude-code directory
4. **Missing maintainers** - all packages have empty maintainers list
5. **vulkan-hdr-layer uses unstable version** - uses commit hash, not tagged release

## Nixpkgs Convention Compliance
- Package naming follows conventions
- Meta attributes present
- Uses appropriate build helpers
- Overlay pattern is idiomatic
- Could benefit from adding tests for some packages


title: Pin perles package to specific commit

description: From Custom Packages evaluation: perles in packages/perles/default.nix uses rev = 'main' instead of a pinned commit. This breaks reproducibility. Should pin to a specific commit hash.


title: Add skill for responding to Gitea PR review comments

description:
## Problem

When responding to PR review comments on Gitea/Forgejo, the REST API (`/api/v1/...`) does not support replying directly to review comment threads. Using `tea comment` or the API creates new top-level comments instead of inline thread replies.

## Discovery

The web UI uses a different endpoint that supports replies:

```
POST /pulls/{id}/files/reviews/comments
Content-Type: multipart/form-data
```

Key form fields:
- `reply`: Review ID to reply to (e.g., `2`)
- `content`: The reply message
- `path`: File path (e.g., `home/roles/development/default.nix`)
- `line`: Line number
- `side`: `proposed` or `original`
- `single_review`: `true`
- `origin`: `timeline`
- `_csrf`: CSRF token (required)

Authentication requires session cookies, not API token.

## Proposed Solution

Create a Claude skill that can:
1. Fetch PR review comments via the REST API
2. Authenticate via browser session or find alternative auth method
3. Post inline replies to review comment threads using the web endpoint

### Options to explore:
1. **Session extraction**: Get cookies from browser or `tea` config
2. **Headless browser**: Use playwright/puppeteer to automate web UI
3. **CSRF flow**: Login via API, get CSRF token, then use web endpoint
4. **tea enhancement**: Check if `tea` CLI has undocumented reply support

## API Reference

Get reviews:
```bash
curl -H "Authorization: token $TOKEN" \
  "https://git.johnogle.info/api/v1/repos/{owner}/{repo}/pulls/{id}/reviews"
```

Get review comments:
```bash
curl -H "Authorization: token $TOKEN" \
  "https://git.johnogle.info/api/v1/repos/{owner}/{repo}/pulls/{id}/reviews/{review_id}/comments"
```

## Acceptance Criteria

- [ ] Skill can read PR review comments given a PR number
- [ ] Skill can post inline replies to specific review comment threads
- [ ] Works with Gitea/Forgejo instances (git.johnogle.info)
- [ ] Handles authentication securely