raelldottin/dotfiles v0.2.0-129

About

This repository manages my shell, tmux, and Neovim configuration as a reproducible dotfiles setup. The install scripts are idempotent, work from any current working directory, and avoid touching your real home directory during automated integration tests.

Quick Start

1. Bootstrap optional workstation dependencies:

   make dependencies

2. Enable the shared Git hooks used to keep generated documentation in sync:

   make hooks

3. Install the managed dotfiles into your current HOME:

   make install

4. Verify the installed files match the repo:

   make verify-install

What Gets Managed

• ~/.zshrc
• ~/.tmux.conf
• ~/.config/nvim/**
• ~/.pylintrc

The setup scripts create symlinks for managed files so edits in the repo are reflected immediately in the installed configuration.

Verification

Run the full local quality gate with:

make verify

That executes:

• checkmake
• shellcheck
• luacheck
• pyright
• unit tests
• integration tests

Make Targets

Target	Purpose
make install	Install the managed dotfiles into the current HOME.
make dependencies	Optionally bootstrap Homebrew and Git identity setup.
make hooks	Configure .githooks as the repository hook path.
make clean	Remove the files managed by this repo.
make lint	Run checkmake, shellcheck, luacheck, and pyright.
make test	Run the automated unit and integration test suites.
make verify	Run every linter plus all automated tests.
make verify-install	Compare the installed files in the current HOME with the repo contents.

Testing Strategy

The automated test suite follows the unit/integration split recommended in Unit Testing: Principles, Practices, and Patterns:

• Unit tests focus on pure, deterministic behavior in the README generator and install manifest.
• Integration tests exercise the shell installers and Git hooks end to end in isolated temporary repositories.
• The default verification path keeps fast tests and environment-aware tests separate.

Documentation

• User Guide
• Neovim Guide
• Testing Guide
• Contributor Workflow
• Repository Settings
• Sphinx Landing Page

Branching

This repository uses an integration-friendly branching model:

• main is the stable release branch.
• dev is the shared integration branch.
• short-lived feature branches such as codex/... are the expected place for individual changes.

GitHub Actions are configured to run on main, dev, pull requests, and codex/* push branches so feature work gets CI feedback before merge.

Uninstalling

make clean