path: root/TODO.org

#+TITLE: ArchSetup V2MOM
#+AUTHOR: Craig Jennings
#+DATE: 2025-11-06
#+FILETAGS: :v2mom:strategy:archsetup:

* URGENT Package Installation Fixes
** TODO [#B] Add Rust installation via rustup instead of pacman package
The =rust= package has been removed from archsetup. Need to add Rust installation using =rustup= (the official Rust toolchain manager) instead of the Arch package.

Steps:
- Install rustup: =pacman -S rustup=
- Initialize default toolchain: =rustup default stable=
- Consider adding to archsetup or post-install script

Reference: Removed from archsetup on 2025-11-15

** DONE [#A] Replace nitrogen with feh for wallpaper management
CLOSED: [2025-12-01 Sun]
Nitrogen is no longer in the official Arch repos.
RESOLVED: Migrated to feh in commit 0601d39:
- Added feh to archsetup pacman installs
- Updated .xinitrc, lf/lfrc, ranger/rc.conf, monitor script
- feh auto-creates ~/.fehbg for wallpaper restore on login

** DONE [#A] Disable or fix adwaita-color-schemes AUR package
CLOSED: [2025-12-01 Sun]
adwaita-color-schemes is failing to build due to CMake version incompatibility
in qgnomeplatform dependency (CMake < 3.5 compatibility removed).
RESOLVED: Package removed from archsetup. Will re-evaluate when upstream fixes the build.

* What is V2MOM?

V2MOM is a strategic framework that provides clarity for decision-making, ruthless prioritization, and measuring progress. It transforms vague intentions into concrete action plans.

The framework consists of five components:
- *Vision:* What you want to achieve (aspirational, clear picture of success)
- *Values:* Principles that guide decisions (2-4 values, defined concretely)
- *Methods:* How you'll achieve the vision (4-7 approaches, ordered by priority)
- *Obstacles:* What's in your way (honest, personal, specific)
- *Metrics:* How you'll measure success (objective, not vanity metrics)

* Vision

The archsetup script provides a reliable, up-to-date way of restoring my workstation on any computer whenever I need it. When I run archsetup, it never fails. If it did fail, it provides clear actionable error messages with the information I need to resolve the issue on the running machine post-install. The software it installs is always up-to-date with my current software stack. I don't have to think about it often because it's continually tested on every change.

**What "restored workstation" means:**
When archsetup completes successfully, I have a system that is:
- **Intuitive** - Everything works the way I expect, muscle memory from years of use just works
- **Beautiful** - Clean aesthetics, no visual clutter, everything has its place
- **Fast** - Enables me to work at the speed of thinking, no friction between intention and action

With the environment fully configured:
- My complete DWM desktop environment with all customizations
- All 50+ dotfiles and custom scripts in place and working
- Emacs fully configured and ready to use
- All development tools, media players, productivity apps installed
- Framework Laptop-specific optimizations (TLP, sleep/suspend working)
- Everything I need to immediately start working—no manual configuration required

**The end state:**
I can lose my laptop, borrow any computer, install Arch minimal, run archsetup, and within a few hours have my complete working environment back—a system that empowers me to get things done at the speed of thinking. Then I clone my git projects and resume work exactly where I left off.

* Values

** Resilient

The script handles edge cases, degrades gracefully, and provides actionable recovery steps when problems occur.

*What this means in practice:*
- Script doesn't silently fail—every critical operation is verified
- Error messages include line numbers, context, and next steps to fix
- Can re-run after failure without breaking already-completed steps
- Handles common failure modes: network issues, missing packages, permission problems
- Falls back to alternatives when preferred packages unavailable

*Examples:*
- If yay install fails, error message shows: exact package name, error code, log file location, and command to retry manually
- If dotfiles stow fails, script reports which files conflicted and provides stow command to fix
- If a package is deprecated, script logs it clearly and suggests alternatives

*What breaks this value:*
- Silent failures that leave system in unknown state
- Generic error messages like "something went wrong"
- Requiring complete reinstall after any failure
- No recovery path—just "it broke, start over"

** Frictionless

The restored system enables working at the speed of thinking—intuitive, beautiful, fast, and empowering.

*What this means in practice:*
- Muscle memory from years of use just works (keybindings, workflows)
- Visual aesthetics are clean and distraction-free
- No waiting—applications launch instantly, operations complete quickly
- Everything needed is present; nothing unnecessary is installed
- The system gets out of the way and lets you focus on work

*Examples:*
- DWM keybindings are exactly what I expect—no surprises
- Emacs starts in under 3 seconds, org-agenda rebuilds in under 5 seconds
- All 50+ custom scripts in ~/.local/bin work as expected
- Clean, minimal interface—no notification spam, no visual clutter
- Framework Laptop suspend/wake works instantly

*What breaks this value:*
- Installing bloated alternatives "just in case" (adds friction)
- Broken keybindings or missing configurations
- Slow startup times or laggy operations
- Missing tools that require manual post-install setup
- Visual clutter, unnecessary services running in background

** Trustworthy

Every change is automatically tested, so I trust the script because it's proven to work, not just hoped to work.

*What this means in practice:*
- Changes are tested in containers/VMs before being committed
- Script has been successfully run multiple times in clean environments
- Package lists are validated against current repos
- Critical functionality is verified after each run
- I don't worry "will it work this time?"—I know it will

*Examples:*
- CI/CD pipeline runs archsetup in container on every commit
- Test results show: packages installed successfully, dotfiles in place, services running
- Failed tests block merging changes to main branch
- Regular test runs catch deprecated packages before I need the script
- I can confidently recommend archsetup to others

*What breaks this value:*
- Only testing on my current system (not a fresh install)
- Committing changes without validation
- "It worked last time" without recent test
- Discovering broken packages during emergency restore
- Relying on manual memory of what to fix post-install

* Methods

** Method 1: Achieve Fail-Proof Execution

I can start archsetup and walk away without worry. When I return, either the installation completed successfully, or I have clear, actionable information about what failed and how to recover. Even if the network fails two-thirds through the install, I know exactly how to either restore and rerun from the minimal install, or install just the few packages that failed. No silent failures. No guessing. No anxiety about whether it worked.

The script handles edge cases gracefully, provides detailed error messages with recovery steps, and can be safely re-run after failures. Every critical operation is verified. I trust the script because it's proven reliable through testing on fresh Arch minimal installs.

*Why this is Method 1:* Can't build testing infrastructure or maintain packages if the script doesn't work. This is the foundation—everything else depends on reliable execution.

*** DONE [#A] Fix: no dotfiles were set up on last run
CLOSED: [2025-11-13 Wed]
RESOLVED - VM test confirms dotfiles are properly stowed as symlinks; all configs and scripts in place

*** TODO [#A] Add root check at script start
Prevents running with wrong permissions that cause silent failures
Script will fail if not run as root but doesn't check until first privileged command
Add at top of script: ~[ "$EUID" -ne 0 ] && echo "Must run as root" && exit 1~

*** TODO [#A] Fix git pull --force data loss risk
Could destroy user's uncommitted changes in repos during dotfile setup
Using ~git pull --force origin master~ can destroy local modifications without warning (archsetup:128)
Should use ~git pull~ or ~git fetch && git reset --hard origin/master~ with user confirmation

*** TODO [#A] Add pre-flight checks before installation starts
Validate system requirements: disk space, network connectivity, Arch version, tool dependencies (curl, stow, git, make)

*** TODO [#A] Implement state tracking for install progress
Track what completed vs failed mid-run to enable targeted recovery and resume capability

*** TODO [#A] Fix sleep/suspend on Framework Laptop
Critical functionality for laptop use - current battery drain unacceptable
Add kernel parameter: ~rtc_cmos.use_acpi_alarm=1~ (will become systemd default)
Consider: ~acpi_mask_gpe=0x1A~ for battery drain, suspend-then-hibernate config
See Framework community notes on logind.conf and sleep.conf settings

*** TODO [#A] Disable installing -debug packages
Currently archsetup downloads a -debug package for every package installed, doubling install time
Add ~!debug~ to OPTIONS in /etc/makepkg.conf or create ~/.config/pacman/makepkg.conf with the setting
Critical performance issue - cuts install time in half

*** TODO [#B] Review slow and failed packages from 8GB RAM test
See [[file:docs/slow-failed-packages.org][Slow and Failed Packages Analysis]]

Test run from 2025-11-09 with 8GB RAM, 50GB disk identified:
- 2 packages that hang indefinitely (anki, tageditor)
- 4 packages that fail to install (nitrogen, gtk-engine-murrine, adwaita-color-schemes, vagrant)
- Several slow but successful packages (multimarkdown, ptyxis, thunderbird, etc.)

High priority actions:
- Remove or make optional: anki (hangs 98 min), tageditor (hangs on qt5-webengine)
- Investigate repository/build issues for failing packages

*** TODO [#B] Resolve all 8 failed packages from last run
**** DONE [#B] adwaita-color-schemes (CMake compatibility issue)
CLOSED: [2025-11-13 Wed]
REMOVED from archsetup - package removed due to CMake build issues
**** DONE [#B] geoclue (service doesn't exist)
CLOSED: [2025-11-13 Wed]
FIXED - Added geoclue package to archsetup and enabled correct service name: geoclue.service (was incorrectly trying geoclue-agent@cjennings.service)
**** DONE [#B] tor-browser (PGP key import failure)
CLOSED: [2025-11-13 Wed]
PGP key issue resolved - tor-browser-bin 15.0-1 successfully installs in VM test
**** DONE [#B] multimarkdown (CMake compatibility issue)
CLOSED: [2025-11-13 Wed]
CMake issue resolved - multimarkdown 6.7.0-2 successfully installs in VM test
**** DONE [#B] vagrant (deprecated/not found in repos)
CLOSED: [2025-11-13 Wed]
vagrant 2.4.9-1 now available and successfully installs in VM test
**** DONE [#B] anki (missing .gitconfig during build)
CLOSED: [2025-11-13 Wed]
REMOVED from archsetup - package removed due to build issues (hangs 98+ minutes, missing .gitconfig during cargo build)
**** DONE [#B] figlet-fonts (FTP download with curl error)
CLOSED: [2025-11-13 Wed]
FTP download issue resolved - figlet-fonts 1.1-1 successfully installs in VM test

*** TODO [#B] Improve error handling: UFW firewall, rmmod pcspkr, mkdir missing quotes
**** TODO [#B] Fix UFW firewall error handling (archsetup:395,410)
Firewall failures use ~|| error "error"~ which logs but continues - system may be left exposed
Should use ~|| error "crash"~ or validate rules were applied successfully
**** TODO [#B] Fix rmmod pcspkr error (archsetup:588)
~rmmod pcspkr~ doesn't check if module is loaded, produces error if already unloaded
Should use ~rmmod pcspkr 2>/dev/null || true~ or check with ~lsmod~
**** TODO [#B] Fix mkdir missing quotes (archsetup:247)
Line 247: ~mkdir -p $source_dir~ should be ~mkdir -p "$source_dir"~ - fails if path contains spaces

*** TODO [#B] Test complete end-to-end run on fresh VM
Validates the script actually works in a clean environment (blocks claiming Method 1 complete)

*** TODO [#B] Make all error messages actionable with recovery steps
Currently just reports errors without guidance on how to fix them

*** TODO [#B] Improve progress indicators throughout install
Enhance existing indicators to show what's happening in real-time

*** TODO [#B] Check that full install logs have timestamps
Verify timestamps exist for debugging failures

*** TODO [#B] Add retry logic to git_install function
pacman_install and aur_install have retry logic, but git_install doesn't

*** TODO [#B] Add input validation for username and paths
Variables like ~$username~, ~$source_dir~, and paths are not validated
Special characters or malicious input could break the script or cause security issues
Should validate inputs match expected patterns (alphanumeric, valid paths, etc.)

*** TODO [#B] Enable TLP power management for Framework Laptop
TLP manages power-saving modes for Wi-Fi, USB, PCIe, Bluetooth, CPU scheduler
Install tlp, enable service, add custom Framework 13 config to /etc/tlp.d/01-custom.conf
Improves battery life and prevents power-related issues during install/post-install

*** TODO [#B] Fix "at" error during install
Package fails with yay - appears to be in extra repository, may need to change to AUR install or verify correct source

*** TODO [#B] Ensure locale is set properly
Errors during install: "setlocale: LC_ALL: cannot change locale (en_US.UTF-8): No such file or directory"
Perl warnings about locale settings not supported/installed on system
Need to properly configure locale generation and LC_* environment variables

*** TODO [#B] Add opus codec to archsetup
All music is in opus format - system needs opus codec to play music files
Install opus package to prevent audio playback issues

*** TODO [#B] Improve logging consistency
Some operations log to ~$logfile~, others don't - standardize logging
All package installs should log, all system modifications should log, all errors should log with context
Makes debugging failed installations easier

*** DONE [#B] Complete Rofi integration
CLOSED: [2025-12-01 Sun]
Rofi installed but needs testing and polish to ensure no friction
RESOLVED: Standardized rofi configuration in commit 590aa02:
- Created ~/.config/rofi/config.rasi and themes/rounded-gray-dark.rasi
- Removed external ~/code/rofi-themes-collection/ dependency
- Simplified sxhkd keybindings (settings now in config.rasi)
- Removed phantom rofi/scripts PATH entry
**** DONE [#B] Match Rofi CSS style to notification CSS and move into proper place
CLOSED: [2025-12-01 Sun]
Rofi theme now matches dunst notifications (colors, border-radius, font)
**** TODO [#C] Consider rofi-wayland for future Wayland migration
~rofi~ doesn't support Wayland - evaluate ~rofi-wayland~, ~wofi~, or ~fuzzel~ for future

*** TODO [#B] Complete Warpinator setup for file transfers
Exploring Warp/Packet/Warpinator for file transfers with Christine (Linux Mint user)
Starting with Warpinator - needs testing and integration into archsetup

*** TODO [#B] Install desktop files using proper utility
Some packages expect desktop files installed with ~desktop-file-install --dir=$HOME/.local/share/applications~/app.desktop~
Ensure picked up with ~update-desktop-database ~/.local.share/applications~
Prevents friction from packages that don't recognize improperly installed desktop files

*** TODO [#B] Add Proton Mail Bridge and setup mail to Emacs
Bridge is how mu4e connects to Proton mail - essential for email workflow
Install and configure Proton Mail Bridge, integrate with mu4e in Emacs

*** TODO [#C] Fix duplicate package installations (mediainfo, obsidian)
Wastes time and could mask package issues

*** TODO [#C] Add backup before system file modifications
Safety net for /etc/X11/xorg.conf.d and other system file edits
Files like ~/etc/sudoers~, ~/etc/pacman.conf~, ~/etc/default/grub~ modified without backup
If modifications fail or are incorrect, difficult to recover - should backup files to ~.backup~ before modifying

*** TODO [#C] Parse and improve AUR error reporting
Parse yay errors and provide specific, actionable fixes instead of generic error messages

*** VERIFY [#C] FZF works everywhere
Especially the ** expander for all files - may already be fixed, needs verification

*** VERIFY [#C] All mail secrets files added to dotfiles
Verify mail configuration and secrets are properly tracked in dotfiles

*** TODO [#D] Add cpupower installation and enabling to archsetup
cpupower service configures the default CPU scheduler (powersave or performance)
Install cpupower, configure /etc/default/cpupower, enable service: ~systemctl enable --now cpupower.service~

** Method 2: Establish Continuous Validation

Every change to archsetup is automatically tested in a fresh environment. CI/CD runs the full install, captures logs, and reports what succeeded and what failed—with actionable recovery information. When packages fail to install (which will happen—that's outside my control), the test reports exactly which packages failed and provides a recovery script I can run post-install. Success isn't zero failures; success is clear, accurate reporting of failures.

I can toggle automation on/off depending on whether I'm actively working on archsetup. When automation is off, I can manually trigger a test run whenever I want validation. I commit changes with confidence because I know they've been tested in a clean environment, not just on my current system.

The testing infrastructure catches regressions, deprecated packages, and broken installations before I need the script in an emergency. I trust the script because it's continuously proven to work, not just hoped to work.

*Why this is Method 2:* Once script works, lock in that reliability with automated testing. Prevents regressions and catches deprecated packages early.

*** TODO [#A] Research container-based testing approaches
Evaluate Docker, systemd-nspawn, Distrobox for fresh Arch install simulation

*** TODO [#A] Create minimal test environment that mimics fresh Arch install
Foundation for all automated testing - must accurately replicate target environment

*** TODO [#A] Define test assertions for validation
**** TODO [#A] All packages install successfully
**** TODO [#A] Dotfiles are stowed correctly (verify symlinks exist)
**** TODO [#A] Critical services start (X11, networking, audio)
**** TODO [#A] Custom scripts are executable and in PATH

*** TODO [#A] Build CI/CD pipeline that runs archsetup on every commit
Core automation infrastructure - enables continuous validation

*** TODO [#A] Generate recovery scripts from test failures
Auto-create post-install fix scripts for failed packages - makes failures actionable

*** TODO [#B] Implement Testinfra test suite for archsetup
Create comprehensive integration tests using Testinfra (Python + pytest) to validate archsetup installations

See complete documentation: [[file:docs/testing-strategy.org::*Test Automation Framework][Testing Strategy - Test Automation Framework]]

Tests should cover:
- Smoke tests: user created, key packages installed, dotfiles present
- Integration tests: services running, configs valid, X11 starts, apps launch
- End-to-end tests: login as user, startx, open terminal, run emacs, verify workflows

Framework: Testinfra with pytest (SSH-native, built-in modules for files/packages/services/commands)
Location: scripts/testing/tests/ directory
Integration: Run via pytest against test VMs after archsetup completes
Benefits: Expressive Python tests, excellent reporting, can test interactive scenarios

The testing-strategy.org document includes:
- Complete example test suite (test_integration.py)
- Tiered testing strategy (smoke/integration/end-to-end)
- How to run tests and integrate with run-test.sh
- Comparison with alternatives (Goss)

*** TODO [#B] Set up automated test schedule
Weekly full run to catch deprecated packages even without commits

*** TODO [#B] Implement manual test trigger capability
Allow on-demand test runs when automation is toggled off

*** TODO [#B] Create test results dashboard/reporting
Make test outcomes visible and actionable

*** TODO [#B] Block merges to main if tests fail
Enforce quality gate - broken changes don't enter main branch

*** TODO [#B] Add network failure testing to test suite
Simulate network disconnect mid-install to verify resilience

*** TODO [#B] Keep container base images up to date
Regular updates to Arch base image with review process and schedule

*** TODO [#B] Persist test logs for historical analysis
Archive logs with review process and schedule to identify failure patterns and trends

*** TODO [#B] Implement automated deprecation detection
Parse package warnings and repo metadata to catch upcoming deprecations proactively

*** TODO [#C] Document testing process in README
Help future maintainers understand and modify test infrastructure

*** TODO [#C] Monitor and optimize test execution time
Keep test runs performant as installs and post-install tests grow (target < 2 hours)

** Method 3: Maintain System Hygiene

My system stays lean and intentional. I have a clear inventory of what archsetup installs versus what's actually on my live system. When I run the comparison, I immediately see: packages I accidentally removed that should be restored, and more commonly, packages accumulated on my system that either need to be added to archsetup or deleted as bloat.

The review process is straightforward—I don't have to manually hunt through installed packages or wonder "do I still use this?" The system tells me what's diverged. I make decisions: add to archsetup, remove from system, or document why it's intentionally different.

My dotfiles are equally clean and purposeful. I have a clear audit process for the 50+ scripts in ~/.local/bin and all the configs in dotfiles/system. I can identify which scripts I haven't used in months, which dotfiles belong to packages no longer installed, and which configurations are stale. The dotfile audit process is repeatable—not a manual archaeology expedition each time.

The system remains as intentional and minimal as the day archsetup first installed it. No cruft accumulates. Every package, script, and configuration serves a purpose I can articulate.

*Why this is Method 3:* Depends on Method 2's automation to generate accurate package inventories. With reliable execution and testing in place, now maintain quality. Prevent accumulation of cruft that slows system and complicates maintenance.

*** TODO [#A] Create package inventory system
**** TODO [#A] List all packages archsetup would install (including dependencies)
**** TODO [#A] List all packages currently installed on live system
**** TODO [#A] Generate diff showing what's in archsetup vs what's on system

*** TODO [#A] Establish monthly review workflow
**** TODO [#A] For packages in archsetup but not on system: determine if still needed
**** TODO [#A] For packages on system but not in archsetup: decide add or remove
**** TODO [#A] Schedule monthly package diff review

*** TODO [#A] Automate the inventory comparison
Make package diff a runnable script instead of manual process

*** TODO [#B] Audit dotfiles/system directory
**** TODO [#B] Review all 50+ scripts in ~/.local/bin - remove unused scripts
**** TODO [#B] Check dotfiles for uninstalled packages - remove orphaned configs
**** TODO [#B] Verify all stowed files are actually used

*** TODO [#B] Remove unnecessary linux-firmware packages
Remove firmware packages for hardware not present on Framework laptop.

Only needed:
- linux-firmware-intel (CPU/GPU/Audio)
- linux-firmware-atheros (WiFi)

Can remove:
- linux-firmware (meta-package)
- linux-firmware-amdgpu
- linux-firmware-broadcom
- linux-firmware-cirrus
- linux-firmware-mediatek
- linux-firmware-nvidia
- linux-firmware-other
- linux-firmware-radeon
- linux-firmware-realtek

Disk space savings: ~600 MB

See [[file:docs/firmware-cleanup.org][docs/firmware-cleanup.org]] for full analysis and removal commands.

After removal, update archsetup script to install only needed firmware packages.

*** TODO [#C] Review and reorganize dotfiles for unused applications
Review all dotfiles by application and remove unused application configurations.

Options:
1. Move to new =dotfiles/unused/= directory (next to =dotfiles/system/=)
2. Design better restowing mechanism (perhaps with Makefile)
   - Selective stowing of only active applications
   - Track which configs are actually in use
   - Make it easy to enable/disable application dotfiles

Benefits:
- Cleaner dotfiles directory with only actively used configs
- Faster stow operations (fewer files to process)
- Clear separation between active and archived configurations
- Easier to maintain and understand what's actually being used

Current state:
- Many application configs for apps removed from archsetup (mpd, ncmpcpp, mopidy, obs-studio, obsidian)
- Unclear which dotfiles correspond to currently installed applications
- No easy way to selectively stow/unstow configs

Reference: Identified on 2025-11-15 during package cleanup session

*** TODO [#B] Replace deprecated ntp with chrony
~ntp~ and ~ntpdate~ are deprecated - modern alternatives:
- ~chrony~: More accurate, better for laptops (handles sleep/wake)
- ~systemd-timesyncd~: Built into systemd, simpler for desktop use
Recommendation: Use ~chrony~ for better accuracy and laptop compatibility

*** TODO [#B] Identify and replace packages no longer in repos
Systematic check for availability issues

*** TODO [#B] Verify package origin for all packages
Ensure packages are installed from correct source (official repos vs AUR) - prevent installing from wrong place

*** TODO [#B] Automate script usage tracking
Parse shell history files for ~/.local/bin script names to identify last usage date and unused scripts

*** TODO [#B] Automate dotfile validation
Parse config files for binary/command references and verify those binaries exist - catch orphaned references

*** TODO [#C] Set up alerts for deprecated packages
Proactive monitoring integrated with Method 2 testing

*** TODO [#C] Cleanup dotfiles repository
The .dotfiles repo has configuration for applications no longer used - remove stale configs

** Method 4: Ensure Secure AND Functional System

I understand my laptop's security posture and trust it's properly protected. The firewall is enabled with correct rules—ports are open only for services I actually use, and everything I need works without fighting the security. When I enable Proton Mail Bridge, it works. When I connect to my remote server via SSH, it works. When I'm working in a cafe on public wifi, I'm confident I'm protected from casual attackers on the same network.

My disk is encrypted—if someone steals my laptop, they can't access my data. I know what attack vectors are mitigated and what threats remain. The system is tested to ensure both security measures are in place AND all functionality works with those measures enabled. No more discovering the firewall was off for weeks, or enabling it only to find it blocks services I depend on.

I have visibility into the security state: I can verify encryption is working, firewall rules are active, and there are no unexpected open ports or services. If someone did compromise my system, I'd have some way to detect it. The security configuration is part of archsetup—not something I manually configure afterward and hope I got right.

I work in cafes without anxiety about whether my laptop is an easy target.

*Why this is Method 4:* Security is foundational, but requires working functionality first (Methods 1-2). With reliable execution and testing (Methods 1-2) and system hygiene (Method 3), now ensure the system is properly secured without breaking workflow.

*** TODO [#A] Implement full disk encryption in archsetup
If laptop is stolen, data remains protected

*** TODO [#A] Review and fix UFW firewall configuration
**** TODO [#A] Ensure firewall is enabled by default
**** TODO [#A] Document which ports need to be open (SSH, Proton Bridge, etc.)
**** TODO [#A] Test that all needed services work with firewall enabled

*** TODO [#C] Fix VM cloning machine-ID conflicts for parallel testing
Currently using snapshot-based testing which works but limits to sequential test runs
Cloned VMs fail to get DHCP/network even with machine-ID manipulation (truncate/remove)
Root cause: Truncating /etc/machine-id breaks systemd/NetworkManager startup
Need to investigate proper machine-ID regeneration that doesn't break networking
Would enable parallel test execution in CI/CD (Method 2)
Priority C because snapshot-based testing meets current needs

*** TODO [#A] Complete security education within 3 months
Read recommended resources to make informed security decisions (see metrics for Claude suggestions)

*** TODO [#A] Prevent X termination and VT switching (security risk)
If someone grabs laptop at cafe and hits ctrl+alt+backspace, they kill screensaver/X and get console access
Need to disable: ctrl+alt+backspace (zap X) and ctrl+alt+F# (VT switching)
Previous attempts to configure in xorg.conf.d failed - need to investigate what's overriding the settings
Tried: /etc/X11/xorg.conf.d/00-no-vt-or-zap.conf with DontVTSwitch and DontZap options
Removed conflicting setxkbmap statements, gdm, and keyd configs - still didn't work

*** TODO [#B] Test security + functionality together
**** TODO [#B] Verify SSH to remote server works
**** TODO [#B] Verify Proton Mail Bridge retrieves email
**** TODO [#B] Verify no unexpected open ports or services

*** TODO [#B] Security audit tooling
**** TODO [#B] Implement port scanning check
**** TODO [#B] Create security posture verification script
**** TODO [#B] Set up intrusion detection monitoring

*** TODO [#B] Document threat model and mitigations within 6 months
Identify attack vectors, what's mitigated, what remains

*** TODO [#B] Add net-tools to archsetup for network connection monitoring
Install net-tools package to enable ~netstat -nlp~ for checking open network connections
Useful for security auditing and verifying no unexpected services are listening

*** TODO [#B] Verify package signature verification not bypassed by --noconfirm
Packages installed with ~--noconfirm~ may skip signature checks
AUR had issues previously requiring --noconfirm workaround - verify this doesn't compromise security
Ensure package signatures are still verified despite --noconfirm flag

*** TODO [#C] Create security checklist for cafe/public wifi scenarios
Practical guidelines for working in public spaces

*** TODO [#C] Build security dashboard command
Single command shows: encryption status, firewall status, open ports, running services

** Method 5: Modernize Software Stack

My software stack evolves naturally as I discover better alternatives. When I see a tool being used elsewhere that solves a problem more elegantly, or when I identify a deficiency in what I'm currently using (like lack of ligature support in my terminal), I have a clear process to evaluate whether the new tool is worth adopting.

"Better" means either more frictionless (aligns with my workflow, reduces friction) or addresses a real deficiency I'm experiencing. I'm not chasing new tools for their own sake, but I'm not stuck with suboptimal tools out of inertia either. The evaluation process is straightforward: does this fit within my DWM-centric system? Does it solve a real problem or reduce friction? Is the improvement worth the switching cost?

When I decide to adopt a new tool, it's thoroughly tested and integrated into archsetup so the improvement becomes part of every future install. My stack stays modern and effective without constant churn.

*Why this is Method 5:* With secure, reliable, tested, and maintained system in place (Methods 1-4), now enhance it opportunistically. Better tools = more frictionless workflow. This is lowest priority because it's about improvement, not fixing what's broken.

*** TODO [#B] Document evaluation criteria and trade-offs
Establish clear process for tool evaluation decisions

*** TODO [#B] Test each modernization thoroughly before replacing
Ensure new tools integrate with DWM environment and don't break workflow

*** TODO [#C] Evaluate modern CLI tool replacements
bat, eza, zoxide, dust, ripgrep-all - only adopt if clear friction reduction

*** TODO [#C] Consider paru instead of yay
Evaluate if paru offers meaningful improvements for AUR management

*** TODO [#C] Evaluate terminal emulator alternatives
ghostty for ligature support - addresses known deficiency

*** TODO [#C] Review file manager options alongside ranger
lf, nnn, yazi - evaluate if any reduce friction vs current ranger setup

*** TODO [#C] Review current tool pain points annually
Once-yearly systematic inventory of known deficiencies and friction points in current toolset

*** TODO [#C] Install Zoxide and dotfiles in archsetup
Modern replacement for ~cd~ with frecency-based directory jumping
Install: ~pacman_install zoxide~ - remembers frequently used directories, faster navigation
**** TODO [#C] Install Zoxide integration into Ranger
https://github.com/jchook/ranger-zoxide - enables zoxide jumping within ranger file manager

* Obstacles

** Limited Security Knowledge

I don't have deep security expertise. I know enough to be worried about working in cafes on public wifi, but not enough to know what specific mitigations are effective or how to implement them properly. Encryption, firewall rules, intrusion detection—these are areas where I'm operating on partial knowledge and best guesses, not expertise.

*Stakes:* Could implement security theater that doesn't actually protect me, or could over-engineer security that breaks functionality. Need to learn enough to make informed decisions, but security is a deep domain.

** Distraction and Prioritization

I get distracted by interesting ideas and don't always work on the right things. It's easy to spend time evaluating shiny new tools (Method 5) when I should be fixing critical bugs (Method 1) or securing the system (Method 4). The V2MOM helps with prioritization, but I still need discipline to follow it instead of chasing whatever seems interesting today.

*Stakes:* Could spend months on Method 5 modernizations while Method 1 bugs remain unfixed. When I need archsetup in an emergency, those distractions mean it still doesn't work reliably.

** No CI/CD or Container Experience

I've never set up a CI/CD system before and don't know containers well. Docker, systemd-nspawn, GitHub Actions, building test environments—these are all areas where I'll be learning as I go. Method 2 (Continuous Validation) is entirely in unfamiliar territory.

*Stakes:* Could build a flaky test system that gives false confidence. Or could get stuck in analysis paralysis trying to learn "the right way" instead of building something that works. Need to learn enough to be effective without perfect knowledge.

** Limited Time

I'm quite busy and don't always have time to work on archsetup. This is a side project that competes with other priorities. Long gaps between sessions mean I forget context and have to re-familiarize myself with what I was doing.

*Stakes:* Archsetup could slowly bit-rot without regular attention. The worry is that it will eventually fail when I need it most—during an actual emergency when my laptop dies and I need to restore quickly.

** Broken AUR Packages Beyond My Control

Package maintainers sometimes release broken packages to the AUR, especially when dependencies break. When a key dependency fails to install, it cascades—many packages that depend on it also fail. This is completely outside my control.

*Stakes:* Even with perfect testing, archsetup could work one week and break the next due to upstream package issues. Can't prevent this, but can mitigate with better error reporting and recovery mechanisms (Method 1). Testing (Method 2) helps catch these issues before I need the script in an emergency.

* Metrics

** Method 1: Achieve Fail-Proof Execution

*** Clean Install Success Rate
- *Current:* Unknown (not tested regularly)
- *Target:* 95%+ successful installs in test environment
- *Measure:* Track test runs - how many complete successfully vs fail
- *Frequency:* After Method 2 automation is in place

*** Critical Bug Resolution Time
- *Current:* 4-5 critical bugs unfixed (some for months)
- *Target:* All current critical bugs fixed within 1 month; no new critical bugs remain unfixed longer than 1 week
- *Measure:* Track date bug identified → date bug fixed
- *Frequency:* Review weekly

*** Failed Package Count
- *Current:* 8 failed packages on last run
- *Target:* 0-2 package failures (accounting for transient AUR issues)
- *Measure:* Count packages that fail to install on test runs
- *Frequency:* Each test run

*** Time to Test After Changes
- *Current:* Weeks or months between testing
- *Target:* Within 1 week before automation; within 2 days after automation
- *Measure:* Time between commit and test run
- *Frequency:* Track for each change

*** Recovery Documentation Coverage
- *Current:* Generic error messages, no recovery steps
- *Target:* 100% of critical failures include actionable recovery steps
- *Measure:* Review error messages - do they tell user how to fix?
- *Frequency:* Audit during Method 1 work, validate in testing

** Method 2: Establish Continuous Validation

*** Test Automation Exists
- *Current:* No automated testing
- *Target:* CI/CD pipeline running within 2 months
- *Measure:* Yes/No - is automation actively running?
- *Frequency:* Check at end of 2 months

*** Test Frequency
- *Current:* Manual testing only, infrequent
- *Target:* Automated test on every commit + weekly scheduled run
- *Measure:* Count test runs per week
- *Frequency:* Weekly review

*** Test Pass Rate Trend
- *Current:* Unknown baseline
- *Target:* Improving or stable week-over-week (accounting for AUR volatility)
- *Measure:* Compare failures this week vs last week - should decrease or stay stable
- *Frequency:* Weekly comparison

*** Manual Test Trigger Capability
- *Current:* No automation to trigger
- *Target:* Manual trigger available by end of year
- *Measure:* Yes/No - can I trigger a test run on demand?
- *Frequency:* Check at end of year

*** Time from Commit to Test Results
- *Current:* N/A (no automation)
- *Target:* < 2 hours for automated test feedback
- *Measure:* Time from git push to test results available
- *Frequency:* Track for each automated test run

*** Test Coverage of Critical Functionality
- *Current:* No automated testing
- *Target:* All critical areas covered: packages install, dotfiles stowed, critical services start (X11, networking, audio), custom scripts executable and in PATH
- *Measure:* Checklist - which areas have test assertions?
- *Frequency:* Review when building automation, audit quarterly

*** Actionable Test Output for All Failure Types
- *Current:* N/A
- *Target:* Every failure type produces clear error report or recovery script
- *Measure:* Review test output - does it tell user what failed and how to fix?
- *Frequency:* Validate when building tests, spot-check monthly

*** Network Resilience Testing
- *Current:* No testing of network failure scenarios
- *Target:* Test handles network outage gracefully (disconnect container mid-install)
- *Measure:* Does test simulate network failure? Does script report it clearly?
- *Frequency:* Include in automated test suite
- *Note:* Task to remember: Test network outage by disconnecting container from network

*** Bare Metal Validation
- *Current:* Only testing in containers, unknown if container accurately mimics bare metal
- *Target:* Run archsetup on actual bare metal fresh Arch install quarterly
- *Measure:* Date of last bare metal validation - should be within 3 months
- *Frequency:* Quarterly (every 3 months)
- *Note:* Validates container test environment accurately represents real fresh installs

** Method 3: Maintain System Hygiene

*** Monthly Hygiene Review
- *Current:* No regular review process; unknown drift
- *Target:* Run monthly comparison between archsetup packages and live system with < 20 package differences and 0 orphaned configs
- *Measure:* Count packages that differ + count orphaned dotfiles (configs for uninstalled packages)
- *Frequency:* Monthly review

*** Time to Resolve Package Issues
- *Current:* Broken packages linger indefinitely
- *Target:* Within 1 week of identifying broken package, either: fix it, install from git repo as alternative, or replace with feature-comparable substitute
- *Measure:* Track time from "package identified as broken" to "resolution implemented"
- *Frequency:* Each time package issue identified

** Method 4: Ensure Secure AND Functional System

*** Disk Encryption Enabled
- *Current:* Not using encrypted partitions
- *Target:* Full disk encryption implemented in archsetup
- *Measure:* Yes/No - does archsetup set up encrypted partitions?
- *Frequency:* Verify once implemented, test in automation

*** Firewall Enabled by Default
- *Current:* Firewall often disabled or misconfigured
- *Target:* UFW firewall enabled with correct rules by default
- *Measure:* Yes/No - does archsetup enable and configure UFW?
- *Frequency:* Verify in every test run

*** Open Ports Documented and Minimal
- *Current:* Unknown what's open, ports opened and forgotten
- *Target:* Only necessary ports open, each documented with reason
- *Measure:* Run port scan, compare to documented list of required ports
- *Frequency:* Include in automated tests, manual audit quarterly

*** Critical Services Functional with Security
- *Current:* Discover breakage through usage (too late)
- *Target:* All critical services tested: SSH to remote server, Proton Mail Bridge, etc.
- *Measure:* Automated tests verify each critical service works with security enabled
- *Frequency:* Include in test suite, verify on every run
- *Note:* Build tests for: SSH connection, email retrieval, remote git push

*** Security Education Completed
- *Current:* Limited security knowledge
- *Target:* Complete security reading/learning to make informed decisions
- *Measure:* Finish recommended security book/articles within 3 months
- *Frequency:* One-time (though ongoing learning)
- *Note:* Claude to suggest security resources for Linux laptop security

*** Threat Model and Security Risks Documented
- *Current:* No formal threat model
- *Target:* Written threat model with identified risks and mitigations
- *Measure:* Yes/No - does documentation exist covering: threat model, attack vectors, what's mitigated, what remains
- *Frequency:* Create within 6 months, review quarterly

*** Security Posture Visibility
- *Current:* Can't easily check security status
- *Target:* Single command shows security dashboard (encryption status, firewall status, open ports, running services)
- *Measure:* Does such a command/script exist? Does it show accurate status?
- *Frequency:* Build during Method 4, verify it stays accurate
- *Note:* Feasibility TBD - may evolve as we learn more

** Method 5: Modernize Software Stack

*** Evaluation Criteria Documented
- *Current:* No documentation of why tools chosen/rejected
- *Target:* 100% of tool evaluations documented with decision rationale
- *Measure:* When evaluating a tool, did we document: what problem it solves, how it compares to current tool, why adopted/rejected?
- *Frequency:* Each tool evaluation (tracked together with Claude)

*** Time Budget: Method 5 vs Method 1
- *Current:* Easy to get distracted by shiny tools
- *Target:* < 20% of archsetup time spent on Method 5 until Method 1 is complete
- *Measure:* Track hours spent on Method 5 work vs Method 1 work
- *Frequency:* Weekly review - am I working on the right priority?

*** Frictionless Improvement Validation
- *Current:* Don't retrospect on tool changes
- *Target:* Regular retrospective on adopted tools - did they actually reduce friction?
- *Measure:* Post-install assessment: is the new tool better? Did it solve the problem? Worth the switching cost?
- *Frequency:* Quarterly retrospective on tools adopted in past 3 months

* Resolved Tasks

Tasks that have been completed and closed.

** Method 1: Achieve Fail-Proof Execution

*** DONE [#A] Fix critical bug: typo in yay installation (archsetup:336)
CLOSED: [2025-11-08 Sat 15:28]
BLOCKS all AUR installs - script cannot install any AUR packages until this is fixed
Line 336 has ~sudo -u "$username" -D "$build_dir"~ which is invalid - the -D flag doesn't exist for sudo in this context
Should be ~cd "$build_dir" && sudo -u "$username"~ or similar

*Resolution:* Fixed line 336 to use ~cd "$build_dir" && sudo -u "$username"~ pattern (same as line 341). Now properly changes directories before running git pull. Unblocks all AUR package installations.

* ArchSetup Inbox
** TODO Add Lexend font to archsetup install
SCHEDULED: <2025-11-12 Tue>
Add lexend-fonts-git package to archsetup font installation.
Package: =yay -S lexend-fonts-git=
Captured On: [2025-11-12 Tue 13:52]