WIP: feat(user-defaults): implement role-based application defaults

[Bad3r]

Summary

Implements a centralized user defaults system for application role mapping, replacing hardcoded app references scattered across modules.

Status: 🚧 Work in Progress — Documentation complete, implementation pending

What's included

• Implementation Plan: docs/drafts/user-defaults-implementation-plan.md

  • Problem statement and design goals
  • Data structure with Wayland support (appId) and multi-class matching (windowClassAliases)
  • Phase 1: Core infrastructure (data file, injection points, validation)
  • Phase 2: Consumer migration (i3-config.nix refactoring)
  • Resolved architectural questions (separation from module package options)

• Implementation Checklist: docs/drafts/user-defaults-checklist.md

  • Pre-implementation verification tasks
  • Step-by-step implementation tasks with verification commands
  • Post-implementation validation
  • Rollback procedure

Design decisions

• userDefaults is intentionally separate from programs.<name>.extended.package (different concerns)
• Validation module with assertions (package path exists) and warnings (module alignment)
• Follows existing metaOwner injection pattern

Test plan

• Phase 1: Core infrastructure builds successfully
• Phase 2: i3-config.nix migration complete
• Firefox opens on workspace 2
• Geany opens on workspace 1
• Thunar opens on workspace 3
• Terminal keybinding opens Kitty
• Override mechanism (gui.i3.commands) still works

Remaining work

• Implement Phase 1 (data file, injection, validation module)
• Implement Phase 2 (i3-config.nix refactoring)
• Runtime testing
• Remove WIP status

[claude]

Claude finished @Bad3r's task —— View job

---

PR Review: User Defaults Implementation

I've completed a comprehensive review of this WIP pull request. This is a well-planned implementation with excellent documentation. Here's my detailed analysis:

Review Tasks

• Read repository guidelines (CLAUDE.md)
• Review implementation plan documentation
• Review implementation checklist
• Analyze design decisions and architecture
• Check for potential security concerns
• Evaluate test coverage approach
• Provide recommendations for improvement

---

✅ Strengths

Excellent Planning & Documentation:

• Comprehensive implementation plan with clear problem statement and design goals
• Well-structured checklist with verification commands for each step
• Clear separation of concerns between Phase 1 (infrastructure) and Phase 2 (migration)
• Thoughtful workflow documentation in the data file header

Solid Architecture:

• Follows existing repository patterns (mirrors metaOwner injection)
• Pure data structure without package dependencies (evaluation timing is correct)
• Structured data with explicit fields rather than error-prone fallbacks
• Clear separation between user defaults and module package options

Security & Safety:

• Input validation through assertions module
• Package path existence verification
• Alignment warnings to catch configuration drift
• No external dependencies or security risks

Repository Compliance:

• Follows NixOS configuration dendritic pattern
• Adheres to repository style guidelines
• Consistent with existing module authoring patterns
• Uses proper conventional commit format

---

⚠️ Areas for Improvement

1. Documentation Consistency (Minor)

• Line 4 in checklist references non-existent plan document path
• Some verification commands may need adjustment once implementation begins
• Consider adding examples of windowClassAliases usage beyond Firefox

2. Test Coverage Gaps

• Missing test for Wayland appId fallback behavior
• No verification of windowClassAliases regex generation
• Consider adding negative tests (invalid package paths)

3. Implementation Readiness

# These commands in the checklist should be verified:
grep -l "_module.args" flake.nix modules/configurations/nixos.nix modules/system76/imports.nix modules/home-manager/nixos.nix

---

🔍 Potential Issues

1. WM_CLASS Verification Dependencies
The checklist requires manual WM_CLASS verification using xprop, but this assumes:

• X11 environment (not Wayland-only)
• Applications are already installed and can be opened
• User has access to GUI during implementation

Recommendation: Add fallback verification using desktop entry inspection or nixpkgs metadata where available.

2. Home Manager Integration Critical Path
The success heavily depends on correct injection into Home Manager modules. The plan identifies this correctly, but consider:

• Adding intermediate verification after Step 1.5
• Testing Home Manager module access before proceeding to Phase 2

3. Regex Generation Robustness

# Line 506 in plan - ensure special regex characters are escaped
{ class = "(?i)(?:${lib.concatStringsSep "|" allClasses})"; };

Recommendation: Add regex escaping for window class names containing special characters.

---

🎯 Performance Considerations

• Pure data file approach is optimal for evaluation performance
• Lazy evaluation through helpers minimizes overhead
• No runtime performance impacts identified

---

📝 Recommendations

Before Implementation:

1. Verify all injection points exist with the exact structure expected
2. Test the helper functions independently before full integration
3. Add regex escaping for window class patterns

During Implementation:

1. Follow the checklist order strictly - dependencies are critical
2. Commit after each phase for clean rollback points
3. Test Home Manager integration thoroughly at each step

For Future Enhancement:

1. Consider adding validation for desktop entry file existence
2. Add support for per-application workspace preferences
3. Consider integration with XDG portal defaults

---

🏆 Overall Assessment

This is a high-quality implementation plan that demonstrates:

• Deep understanding of the NixOS module system
• Careful consideration of evaluation timing and dependencies
• Excellent documentation and testing strategy
• Clean separation of concerns

The architecture is sound, follows repository patterns well, and the phased approach reduces implementation risk. The documentation quality exceeds typical standards and will be valuable for future maintainers.

Recommendation: Proceed with implementation following the checklist precisely. The plan is solid and ready for execution.

---