dotfiles

Imported from rurusasu/dotfiles (AGENTS.md). Install upstream with npx skills add rurusasu/dotfiles. Copyright stays with the author.

dotfiles repository: 実装時の作業基準

最初に決めること

1. 変更対象が nix/, chezmoi/, windows/, scripts/, docker/ のどれかを特定する。
2. パッケージ追加か設定変更かを切り分ける。
3. 反映先が macOS、Linux/WSL/NixOS、Windows のどれかを決める。

変更先の原則

• Unix のパッケージ導入とアプリ設定: nix/modules/。Unix CLI の PATH への導入はすべて tools.nix、Linux / WSLg GUI は desktop.nix、Darwin system GUI は desktop-darwin.nix、個別アプリの設定・連携は各 module にまとめる。
• CLI の programs.*.enable と home.packages は nix/modules/tools.nix に宣言し、各 module は設定・連携・package override を担当する。GUI、OS service、フォント、ビルド用依存はそれぞれの所有先に置く。
• Python のユーザー環境は uv で管理し、interpreter を直接 home.packages に追加しない。公開コマンドは uv 経由で実行する。Nix 内部専用の Python 依存は各 module が管理する。
• ホストは必要な module を import して構成を選択する。Windows のインストール情報は Nix module と分離する。詳細は パッケージ管理。
• Home Manager module の選択・OS 固有設定: nix/hosts/<system>/<environment>/home.nix。nix/home/common.nix は OS 非依存の共有設定を担当する。
• デスクトップの共通キー配列・ユーザー設定: nix/home/keybindings/。OS の service/有効化・競合解除は nix/hosts/<system>/<environment>/ が担当する。純粋な設定生成関数と Home Manager module を区別する（責務と対応範囲・移行状況）。
• Windows manifest: windows/{winget,npm,pnpm}/packages.json（直接管理する独立した正本。通常導入は WinGet の GUI のみ）
• ユーザー設定: Unix は nix/modules/ と nix/home/、Windows は chezmoi/ 以下。Nix 管理のデスクトップキー設定は nix/home/keybindings/ に置き、同じ設定を二重配布しない。
• Windows 実行ロジック: scripts/powershell/
• CLI の実行順序・依存関係・公開コマンドは Taskfile.yml と taskfiles/ に実装する。
• Bash/PowerShell は Taskfile から呼ばれる platform adapter、secret 処理、複雑な検証に限定し、CLI の処理順序を重複定義しない。

テスト責務

• Nix expression、Home Manager option、flake output、Nix package 選択の値テストは nix/tests/unit/ に nix-unit 形式で記載する。ビルド・実行テストの derivation は nix/tests/build/、共有入力は nix/tests/fixtures/ に置く。
• nix/tests/default.nix が単体テストとビルドテストを登録する。nix-unit も flake の checks 経由で実行する。nix flake check --no-build は評価確認であり、テスト実行の代わりにはならない。詳細は Nix テスト。
• Bats は shell、installer、外部コマンド、runtime/integration 契約に限定する。Nix option を nix eval するだけの Bats テストは追加しない。Windows manifest は CI で JSON を直接検証する。テストの分類は nix/tests/README.md に従う。WSL の初回同期は PowerShell ハンドラー、NixOS rebuild は直接コマンドを境界として検証する。

フォーマット・テスト・実行時間の境界

• task fmt は formatter の書き換え、task lint は pre-commit の検査として分離する。task commit は先に fmt を実行するため、後続の lint:no-format では treefmt を再実行しない。
• formatter の対象外は構文が未展開時に成立しない chezmoi テンプレートなど、理由を docs/formatter/AGENTS.md と設定コメントに残せるものだけにする。対象外にしたファイルは展開後の semantic test で検証する。
• テスト runner は CI とローカルで共有し、テスト件数が 0 の実行を成功扱いにしない。skip は実行環境の境界として明示し、必要な契約を削除して時間を短縮しない。
• CanApply は判定専用で外部インストールやネットワークなどの副作用を持たせない。bootstrap は Apply に限定する。重複した preflight、同一 nix eval、同じ Docker build の再実行は、依存関係と成果物を保ったまま一度にまとめる。

実行コマンド

# dotfiles 反映（NixOS + Windows 両方）
dotf chezmoi        # task chezmoi の短縮形

# WSL/NixOS
nrs
sudo nixos-rebuild dry-build --flake ~/.dotfiles --impure
nix fmt

# Windows
dotf chezmoi        # task chezmoi の短縮形
pwsh -File scripts/powershell/install.ps1
task test:powershell
task lint:all

コミット前ルール

• worktree の作成・移動・一覧・削除は gwq を使う。Windows / WSL 共用では同じ Windows ドライブに置き、相対リンクを使う。既存リンクの修復だけは task worktree:repair REPO=... WORKTREE=... を使う（運用手順）。
• Windows から直接 git commit しない。
• task commit -- "message" を使う。
• 必要に応じて pre-commit run --all-files を実行する。

PR / CI の SHA と報告

• CI 状態を確認・報告するときは、GitHub から PR の最新 head SHA をその場で取得する。会話履歴、ローカル HEAD、開いたままの Actions ページにある SHA を最新とみなさない。
• 各 workflow の検証対象は、そのイベントで受け取った head SHA に固定する。push 後は新しい head SHA の必須チェックを取り直し、以前の SHA の成功結果を新しい変更の検証として扱わない。
• PR の検証状況を書く場合は、完全な head SHA と、その SHA に対応する実際の Actions 結果を反映する。「実行中」「成功」は確認時点の状態に合わせ、失敗・未完了の必須チェックがあれば成功と表現しない。

参照先

• docs/architecture.md
• docs/1password/README.md（1Password / op 調査と OS 別運用）
• docs/chezmoi/
• docs/taskfile/lint.md
• docs/git/commit.md