@sebastienrousseau/dotfiles 0.2.500 → 0.2.502

package/docs/operations/MAINTENANCE.md

@@ -1,3 +1,7 @@
+---
+render_with_liquid: false
+---
+
 # Dotfiles Maintenance Runbook
 
 This runbook captures recovery and release maintenance operations for this repository.
@@ -27,7 +31,7 @@ This runbook captures recovery and release maintenance operations for this repos
 ```bash
 git verify-commit HEAD
 gh run list --workflow ci.yml --branch master --limit 1
-gh release view v0.2.500 --json tagName,targetCommitish,url
+gh release view v0.2.501 --json tagName,targetCommitish,url
 ```
 
 ## Release Closeout Checklist

package/docs/operations/MIGRATION.md

@@ -1,3 +1,7 @@
+---
+render_with_liquid: false
+---
+
 # Migration and Upgrade Guide
 
 ## How to Upgrade
@@ -18,7 +22,8 @@ dot doctor
 
 ## Version History
 
-### v0.2.500 (Current)
+### v0.2.501 (Current)
+
 - **Wallpaper-driven theme engine** — themes auto-generated from wallpapers via K-Means in CIELAB color space (no hand-crafted themes)
 - **Dynamic HEIC support** — custom wallpapers ship as Apple-compatible single-file dynamic HEIC; macOS auto-switches dark/light
 - **System wallpaper discovery** — pulls themes from `/System/Library/Desktop Pictures/` (macOS) and `/usr/share/backgrounds/` (Linux)
@@ -29,7 +34,8 @@ dot doctor
 - **Build artifact redirection** — Cargo, Go, pip, uv, Zig caches → `/tmp/builds/` (cleared on reboot)
 - **CI dedup** — `ci-enforced.yml` reuses `reusable-shell-lint.yml` and `reusable-test-suite.yml`
 
-### v0.2.499
+### v0.2.500
+
 - Added AI CLIs: Autohand Code, Mistral Vibe, Qwen Code, ZAI
 - Removed Cline CLI (broken upstream dependency)
 - Interactive mise installer for missing AI providers
@@ -41,27 +47,29 @@ dot doctor
 - Auto-prewarm after dot apply
 - Expanded Atuin history filters
 
-### v0.2.498
+### v0.2.497
+
 - Theme system with Catppuccin integration
 - Linux desktop parity (Niri, Waybar, Fuzzel)
 - AI tooling expansion (Kiro, OpenCode)
 - Coverage contracts and QA docs
 
-### v0.2.497
+### v0.2.496
+
 - Verified chezmoi installer
 - Shell startup optimization
 - Property-based tests
 
 ## Breaking Changes
 
-If you are upgrading from v0.2.499 or earlier, note these changes:
+If you are upgrading from v0.2.501 or earlier, note these changes:
 
 1. **`themes.toml` is now generated** — do not hand-edit. Run `dot theme rebuild` to regenerate from wallpapers
 2. **Theme names changed** — old hand-crafted names (e.g. `catppuccin-mocha`, `macos-tahoe-dark` with hardcoded palettes) are replaced by wallpaper-derived names. The picker only shows paired wallpaper themes.
 3. **Wallpaper format** — custom wallpapers should be dynamic HEIC (single file, both appearances). Use `bash scripts/theme/merge-wallpaper.sh` to merge separate dark/light pairs.
 4. **Build caches relocated** — Cargo/Go/pip/uv/Zig now write to `/tmp/builds/`. Restart your shell after upgrade so `mise [env]` picks up the new paths.
 
-If you are upgrading from v0.2.498 or earlier:
+If you are upgrading from v0.2.501 or earlier:
 
 1. **Cline CLI removed** — if you used `dot cline`, switch to a different AI CLI
 2. **AI tools now install through mise** — run `mise install` to set up AI providers

package/docs/operations/OPERATIONS.md

@@ -1,3 +1,7 @@
+---
+render_with_liquid: false
+---
+
 # Operations
 
 Core workflows for keeping your dotfiles running across platforms.
@@ -11,9 +15,11 @@ Core workflows for keeping your dotfiles running across platforms.
 **Primary manager**: `Homebrew`
 
 - **Update**:
+
   ```bash
   chezmoi update
   ```
+
   This runs `brew bundle install` behind the scenes to reconcile against the declared Brewfiles.
 - **Permission issues**: `sudo chown -R $(whoami) $(brew --prefix)/*`
 - **Drift**: Run `brew bundle cleanup` to remove unmanaged packages.
@@ -23,10 +29,12 @@ Core workflows for keeping your dotfiles running across platforms.
 **Primary manager**: `apt-get` / `snap`
 
 - **Update**:
+
   ```bash
   sudo apt update && sudo apt upgrade -y
   chezmoi update
   ```
+
   On Linux, `chezmoi` focuses on configuration. Package updates work best through the OS package manager to avoid `sudo` conflicts.
 - **Font issues**: If icons are missing, run `./install/provision/run_onchange_50-install-fonts.sh.tmpl` manually via `chezmoi apply` or source directly with `bash`.
 
@@ -61,6 +69,7 @@ dot doctor
 ```
 
 `dot apply` includes post-apply checks that:
+
 - Remove stale read-only zsh cache files (`~/.config/shell/*.zwc`, `~/.config/zsh/**/*.zwc`)
 - Validate that `dot` resolves to `~/.local/bin/dot` in a fresh login shell
 
@@ -109,38 +118,53 @@ dot prewarm
 If something's slow or broken:
 
 1. **Check health**:
+
    ```bash
    dot doctor
    dot health --fix
    ```
+
 2. **Smoke test**:
+
    ```bash
    dot smoke-test
    ```
+
 3. **Scorecard**:
+
    ```bash
    dot scorecard
    ```
+
 4. **Chaos testing (self-healing)**:
+
    ```bash
    dot chaos --force
    dot heal --force
    ```
+
 5. **Startup profiling**:
+
    ```bash
    dot perf --profile
    ```
+
 6. **Post-merge verification**:
+
    ```bash
    dot verify
    ```
+
 7. **Inspect alias behavior**:
+
    ```bash
    dot aliases list
    dot aliases why dprune
    DOTFILES_ALIAS_POLICY=strict bash ~/.dotfiles/scripts/diagnostics/alias-governance.sh
    ```
+
 8. **Verbose mode**:
+
    ```bash
    DOTFILES_DEBUG=1 dot apply
    ```

package/docs/operations/PERFORMANCE.md

@@ -0,0 +1,133 @@
+---
+render_with_liquid: false
+---
+
+# Performance — Budgets, Baselines, Regression Detection
+
+This page documents the per-shell startup budget, the baseline
+lifecycle, and the regression-alert pipeline. Managed under
+[#863](https://github.com/sebastienrousseau/dotfiles/issues/863).
+
+## Targets
+
+| Shell | Target (mean ms) | Override env var |
+|---|---|---|
+| **zsh** | 250 | `DOTFILES_PERF_TARGET_ZSH_MS` |
+| **bash** | 60 | `DOTFILES_PERF_TARGET_BASH_MS` |
+| **fish** | 200 | `DOTFILES_PERF_TARGET_FISH_MS` |
+| **nu** | 500 | `DOTFILES_PERF_TARGET_NU_MS` |
+| **pwsh** | 600 | `DOTFILES_PERF_TARGET_PWSH_MS` |
+
+`dot perf` measures every installed shell and flags any whose mean
+exceeds its target. The numbers come from
+[`scripts/diagnostics/perf.sh`](../../scripts/diagnostics/perf.sh) —
+warm-up + 3 runs by default.
+
+## The baseline
+
+`$XDG_CACHE_HOME/dotfiles/perf-baseline.json` records the per-shell
+means at a known-good point in time. The file is a JSON object:
+
+```json
+{
+  "recorded_at": "2026-05-13T00:00:00Z",
+  "regression_pct": 10,
+  "shells": {
+    "zsh": 41,
+    "bash": 28,
+    "fish": 190
+  }
+}
+```
+
+### Recording a baseline
+
+```bash
+dot perf --baseline                 # all installed shells
+dot perf --baseline --shell zsh     # just one shell
+```
+
+Do this after:
+
+- A fresh chezmoi apply on a new machine.
+- Any deliberate startup-cost change (deferred-load PRs, new plugin).
+- A `mise install` that bumps a hot-path tool's version.
+
+### Regression detection
+
+Every subsequent `dot perf` invocation compares the current
+measurement against the baseline. When any shell exceeds the
+baseline by more than `DOTFILES_PERF_REGRESSION_PCT` (default 10%),
+the run reports under a "Baseline regressions" section. JSON output
+includes a `regressions: [...]` array and a `regression_count`
+counter so dashboards can alert.
+
+```bash
+dot perf                            # warns on regression
+dot perf --no-baseline-check        # skip the comparison entirely
+DOTFILES_PERF_REGRESSION_PCT=5 dot perf   # tighter threshold
+```
+
+## Per-tool timings
+
+`_cached_eval` (the zsh/fish primitive that caches expensive tool
+init like `starship init zsh`) writes one JSONL row per call to
+`$XDG_STATE_HOME/dotfiles/eval-timings.jsonl` when
+`EVALCACHE_TIMING=1` is set in the environment. Aggregating that log
+gives a per-tool breakdown of where startup time goes.
+
+```bash
+EVALCACHE_TIMING=1 zsh -i -c exit    # generate data
+dot perf --by-tool                   # see the aggregation
+dot perf --reset                     # clear the log
+```
+
+The aggregator reports `count / total / mean / p50 / p95 / p99`
+per `_cached_eval` label. P95 + P99 surface the tail-latency cases
+that mean alone misses (e.g. a cache miss after a tool upgrade
+spiking from 5ms steady-state to 200ms once).
+
+## `dot doctor` Performance section
+
+`dot doctor` surfaces (when each data source is available):
+
+- Whether `_cached_eval`'s on-disk tool caches are fresh vs stale
+  for mise, starship, zoxide, atuin, fzf, direnv.
+- Any installed slow-init tools NOT yet wrapped in `_cached_eval`
+  (nvm, fnm, pyenv, pnpm, …).
+- Hyperfine-measured startup latency vs target.
+- Baseline age + top-3 slowest tools from the EVALCACHE_TIMING log.
+
+## CI workflow
+
+[`.github/workflows/perf-baseline.yml`](../../.github/workflows/perf-baseline.yml)
+runs weekly on Sunday at 03:00 UTC on `ubuntu-latest`. It:
+
+1. Restores the previous week's baseline from a workflow artifact.
+2. Runs `dot perf --json` against the freshly-applied dotfiles.
+3. Compares current vs restored baseline; opens (or comments on) a
+   tracking issue if any shell regressed by >10%.
+4. Uploads the new measurement as the next week's restore source.
+
+The CI workflow always runs against the same `ubuntu-latest` image
+so the comparison is machine-stable; per-developer baselines live on
+each developer's box and aren't synced.
+
+## Adjusting the budget
+
+Per-shell targets live in
+[`scripts/diagnostics/perf.sh`](../../scripts/diagnostics/perf.sh)
+under `shell_target_for()`. Bumping a target should always come with:
+
+- A commit-message rationale explaining why slower is acceptable
+  (e.g. "added a required Carapace completion at startup").
+- A new baseline recording (`dot perf --baseline`).
+- A note here under "Targets" with the new value.
+
+## References
+
+- [`scripts/diagnostics/perf.sh`](../../scripts/diagnostics/perf.sh)
+- [`tests/unit/diagnostics/test_perf_percentiles.sh`](../../tests/unit/diagnostics/test_perf_percentiles.sh) — percentile math contract
+- [`.github/workflows/perf-baseline.yml`](../../.github/workflows/perf-baseline.yml)
+- ADR-002 (Shell Performance Optimization)
+- Issue [#863](https://github.com/sebastienrousseau/dotfiles/issues/863)

package/docs/operations/REGISTRY.md

@@ -0,0 +1,89 @@
+---
+render_with_liquid: false
+title: "Dot Module Registry"
+description: "How to publish and consume reusable dotfile modules."
+---
+
+# Dot Module Registry
+
+The `dot registry` command discovers reusable dotfile modules from a JSON index published over HTTPS. The default registry is hosted by this repo at:
+
+```
+https://sebastienrousseau.github.io/dotfiles/registry.json
+```
+
+This page documents the JSON contract and the contribution flow. It is the §3 / Months 12-18 deliverable from [HARD_AUDIT_2026.md](./HARD_AUDIT_2026.md) — the registry is the network-effect feature that turns the framework into a category, not just one person's setup.
+
+## Quick start (consumer side)
+
+```sh
+dot registry list                   # list every published module
+dot registry search rust            # filter by keyword
+dot registry info rust-dev-setup    # full metadata for one module
+dot registry install rust-dev-setup # apply to this workstation (scaffold)
+dot registry url                    # show active registry URL
+dot registry set-url <url>          # point at a different registry
+```
+
+The registry index is cached locally at `${XDG_CACHE_HOME:-~/.cache}/dotfiles/registry/index.json` with a 6 hour TTL. Override the URL one-off via `DOTFILES_REGISTRY_URL=<url> dot registry list`.
+
+## JSON contract
+
+A registry index is a single JSON document:
+
+```json
+{
+  "version": 1,
+  "updated": "2026-05-15T16:30:00Z",
+  "registry": "sebastienrousseau/dotfiles",
+  "modules": [
+    {
+      "name": "rust-dev-setup",
+      "description": "Rust toolchain + cargo plugins + Helix/Neovim editor config",
+      "repo": "https://github.com/example/rust-dev-setup",
+      "version": "1.2.0",
+      "tags": ["rust", "language", "dev"],
+      "maintainer": "alice@example.com",
+      "sha256": "f9a2c1b…",
+      "license": "MIT"
+    }
+  ]
+}
+```
+
+Required keys: `name` (kebab-case, ≤ 32 chars), `description` (≤ 200 chars), `repo` (HTTPS clone URL), `version` (semver).
+
+Recommended keys: `tags` (lower-case array), `maintainer`, `sha256` (pinned at publish time so installers can verify), `license` (SPDX identifier).
+
+## Contributing a module
+
+1. Build your module as a chezmoi-source-compatible directory at `https://github.com/<you>/<module>.git`. The contents are overlaid onto the consumer's chezmoi source dir during install.
+2. Open a PR against `sebastienrousseau/dotfiles` adding one entry to `docs/registry.json` (alphabetical by `name`).
+3. The PR runs CI checks for:
+   - Schema validity (`jq` against the JSON contract).
+   - `repo` URL resolves and is a public git repo.
+   - `sha256` matches the latest tag at `repo`.
+4. Once merged, the GitHub Pages workflow re-deploys the registry; `dot registry list` picks it up within 6 hours (or immediately if the consumer purges the cache).
+
+## Install pipeline (scaffold today, full in Phase 2)
+
+`dot registry install <name>` currently prints what *would* happen. The full pipeline lands as follows:
+
+1. Resolve the module entry from the registry index.
+2. Clone the module to `$XDG_DATA_HOME/dotfiles/modules/<name>/<version>`.
+3. Verify the clone's HEAD matches `sha256` from the registry.
+4. Source the module's `module.toml` (if present) for declared profiles + feature flags.
+5. Merge the module's chezmoi source into the consumer's chezmoi source dir under a namespaced subtree (`/registry/<name>/...`).
+6. Run `chezmoi apply --include /registry/<name>/**` so only the module's files are written.
+
+The sandboxed apply (point 6) requires changes to `dot sync` to accept an include filter — that is its own roadmap issue and tracked separately.
+
+## Security model
+
+- Modules execute with the consumer's user privileges via chezmoi `run_onchange_*` scripts. The trust contract is identical to consuming any third-party dotfiles repo.
+- Pinning `sha256` lets a consumer verify the registry entry hasn't been tampered with between publish and install.
+- The registry index itself is fetched over HTTPS; the GitHub Pages cert chain provides transport integrity.
+
+## Why this lives in this repo (for now)
+
+A vendor-neutral registry would be ideal but adds operations cost. Hosting `registry.json` under this repo's `docs/` directory and serving it via GitHub Pages keeps the maintenance burden near zero while the registry is small. If/when the registry outgrows GitHub Pages, the JSON contract is stable and the index can move to a dedicated subdomain.

package/docs/operations/RELIABILITY.md

@@ -1,3 +1,8 @@
+---
+render_with_liquid: false
+---
+{% raw %}
+
 # Reliability
 
 ## Reliability scorecard
@@ -114,3 +119,4 @@ jobs:
 For a lightweight repository-wide snapshot, run `bash ./scripts/qa/coverage-baseline.sh --with-module-coverage`.
 
 Core internal behaviors are traced through `bash ./scripts/qa/traceability-coverage.sh`.
+{% endraw %}

package/docs/operations/ROADMAP.md

@@ -1,3 +1,7 @@
+---
+render_with_liquid: false
+---
+
 # Roadmap
 
 This roadmap steers the project from a "feature-rich dotfiles repo" to an **Enterprise-Grade Shell Distribution**. The structure is organized by strategic pillars (**Trust**, **Predictability**, **Observability**) rather than linear phases, though the original 100-Phase vision is preserved within these categories.
@@ -5,6 +9,7 @@ This roadmap steers the project from a "feature-rich dotfiles repo" to an **Ente
 ---
 
 ## Reproducibility
+
 **Goal:** "Reproducible Shell Environments".
 > *This distribution aims for deterministic rebuilds: the same tag yields the same environment across machines.*
 
@@ -17,6 +22,7 @@ This roadmap steers the project from a "feature-rich dotfiles repo" to an **Ente
 - [ ] **Terraform Provider (Phase 28)**: Custom provider to provision dotfiles state.
 
 ## Observability
+
 **Goal:** "Observable Shell Lifecycle".
 > *The shell is instrumented: failures, timing, and lifecycle events are visible by design.*
 
@@ -28,6 +34,7 @@ This roadmap steers the project from a "feature-rich dotfiles repo" to an **Ente
 - [ ] **Update Manager (Phase 39)**: Visual interface for tool updates and migration.
 
 ## Secrets
+
 **Goal:** "Explicit Secrets Model".
 > *Secrets are never committed; sensitive state is encrypted or host-local by default.*
 
@@ -39,6 +46,7 @@ This roadmap steers the project from a "feature-rich dotfiles repo" to an **Ente
 - [ ] **OIDC Auth (Phase 29)**: Keyless authentication via GitHub OIDC.
 
 ## Toolchain
+
 **Goal:** "Composable Shell Layers".
 > *The distribution is layered: core safety is mandatory, advanced features are opt-in.*
 
@@ -46,62 +54,67 @@ This roadmap steers the project from a "feature-rich dotfiles repo" to an **Ente
 - [ ] **UX Layer**: Prompt (Starship), Aliases, Completions.
 - [ ] **Toolchain Layer**: Rust replacements (`eza`, `bat`, `ripgrep`).
 - [ ] **Cross-Compiler Toolchain (Phase 34)**:
-    - [ ] **Multi-Arch**: `qemu-user-static` for ARM64/AMD64.
-    - [ ] **Wasm Target**: WebAssembly toolchain setup.
-    - [ ] **Embedded Dev**: Presets for Arduino/ESP32.
+  - [ ] **Multi-Arch**: `qemu-user-static` for ARM64/AMD64.
+  - [ ] **Wasm Target**: WebAssembly toolchain setup.
+  - [ ] **Embedded Dev**: Presets for Arduino/ESP32.
 
 ## Opt-in features
+
 **Goal:** "Explicit Feature Flags".
 > *Advanced features are gated behind explicit opt-in flags.*
 
 - [ ] **Feature Toggles**: Environment variables (e.g., `ENABLE_AI=0`, `ENABLE_HISTORY_SYNC=0`).
 - [ ] **Lazy Loading**: Strict lazy-loading for all non-core plugins.
 - [ ] **Plugin Ecosystem (Phase 35)**:
-    - [ ] **Module Registry**: Public index of dotfiles modules.
-    - [ ] **Dependency Solving**: Semantic versioning for modules.
-    - [ ] **Verified Publishers**: Cryptographic signing for "Official" modules.
+  - [ ] **Module Registry**: Public index of dotfiles modules.
+  - [ ] **Dependency Solving**: Semantic versioning for modules.
+  - [ ] **Verified Publishers**: Cryptographic signing for "Official" modules.
 
 ## Safety
+
 **Goal:** "Documented Threat Model".
 > *Security decisions are driven by an explicit, documented threat model.*
 
 - [x] **Threat Model Doc**: A lightweight document defining the trust boundary (Local Machine). See `docs/security/THREAT_MODEL.md`.
 - [ ] **Supply Chain**: Verification steps for upstream dependencies.
 - [ ] **Identity & Access (Phase 40)**:
-    - [ ] **SSH Certs**: Short-lived SSH Certificates.
-    - [ ] **YubiKey Bio**: Biometric enforcement for `sudo`.
-    - [ ] **PAM Modules**: Custom auth modules.
-    - [ ] **Auditd Rules**: Pre-configured audit rules.
+  - [ ] **SSH Certs**: Short-lived SSH Certificates.
+  - [ ] **YubiKey Bio**: Biometric enforcement for `sudo`.
+  - [ ] **PAM Modules**: Custom auth modules.
+  - [ ] **Auditd Rules**: Pre-configured audit rules.
 
 ## Validation
+
 **Goal:** "Self-Validating Environment".
 > *The environment can validate itself after installation or update.*
 
 - [x] **Smoke Tests**: Automated verification of key aliases (`ls`, `git`, `docker`).
 - [x] **CI Validation**: GitHub Actions workflow to boot and verify the shell syntax.
 - [x] **Chaos Engineering (Phase 41)**:
-    - [ ] **Config Chaos**: Randomly corrupt config files to test recovery.
-    - [ ] **Network Simulation**: Simulate high latency/packet loss.
-    - [ ] **Permission Fuzzing**: Verify strict umask behavior.
+  - [ ] **Config Chaos**: Randomly corrupt config files to test recovery.
+  - [ ] **Network Simulation**: Simulate high latency/packet loss.
+  - [ ] **Permission Fuzzing**: Verify strict umask behavior.
 
 ## Distribution
+
 **Goal:** "Supported Platforms Matrix".
 > *Only listed platforms are guaranteed to work; others are best-effort.*
 
 - [x] **Support Matrix**: Explicit table of OS/Version support. See `docs/reference/SUPPORT_MATRIX.md`.
 - [ ] **Windows Deep Integration (Phase 53)**:
-    - [ ] **PowerShell Profile**: Mirror Zsh functionality.
-    - [ ] **WinGet**: Declarative package management.
-    - [ ] **WSL Bridge**: Seamless interop.
+  - [ ] **PowerShell Profile**: Mirror Zsh functionality.
+  - [ ] **WinGet**: Declarative package management.
+  - [ ] **WSL Bridge**: Seamless interop.
 - [ ] **Linux Deep Integration (Phase 55)**:
-    - [x] **Systemd User Units**: User service management.
-    - [ ] **Desktop Envs**: GNOME/KDE/Sway configs.
+  - [x] **Systemd User Units**: User service management.
+  - [ ] **Desktop Envs**: GNOME/KDE/Sway configs.
 
 ---
 
 ## Future
 
 ### Domain-Specific Environments
+
 - [ ] **Data Science (Phase 38)**: Conda/Mamba, GPU Config, Jupyter.
 - [ ] **Network Topologies (Phase 56)**: Mesh Networks, Tor, Private VPNs.
 - [ ] **Build Systems (Phase 57)**: Bazel, Maven/Gradle, CMake.
@@ -112,6 +125,7 @@ This roadmap steers the project from a "feature-rich dotfiles repo" to an **Ente
 - [ ] **Bio-Informatics (Phase 70)**: Genomics, PDB, FASTA.
 
 ### Enterprise & Operations
+
 - [ ] **Collaborations (Phase 45)**: Pair Programming, Team Sync, ChatOps.
 - [ ] **Database DevOps (Phase 46)**: DB Clients, Local Docker DBs, Migrations.
 - [ ] **Serverless (Phase 47)**: Lambda, Edge Workers, Wasm.
@@ -120,6 +134,7 @@ This roadmap steers the project from a "feature-rich dotfiles repo" to an **Ente
 - [ ] **Recruiting & HR (Phase 94)**: Resume Generators, coding interview sets.
 
 ### Accessibility & Legacy
+
 - [ ] **Accessibility (Phase 36)**: Screen Reader optimization, High Contrast.
 - [ ] **Legacy Modernization (Phase 42)**: Mainframe/Unix support, PowerShell Core.
 
@@ -128,12 +143,14 @@ This roadmap steers the project from a "feature-rich dotfiles repo" to an **Ente
 ## Completed
 
 ### Core Foundations
+
 - [x] **Universal Config (Chezmoi) (Phase 1)**
 - [x] **Shell Environment (Phase 2)**
 - [x] **Tool Modernization (Phase 3)**
 - [x] **Performance Optimization (Phase 4)**
 
 ### Hardened Security
+
 - [x] **Security & Validation (Phase 5)**
 - [x] **Package Management (Phase 6)**
 - [x] **Hardened Security (Phase 21)**
@@ -141,6 +158,7 @@ This roadmap steers the project from a "feature-rich dotfiles repo" to an **Ente
 - [x] **Legal & Licensing (Phase 92)**: FOSSology, Headers, CLA.
 
 ### Experience
+
 - [x] **Documentation (Phase 25)**: DocSite, Interactive Tour.
 - [x] **Self-Healing (Phase 27)**: Doctor, Auto-Repair.
 - [x] **OS Bundling (Phase 26)**: XDG Compliance, Vendor Hooks.