@sebastienrousseau/dotfiles 0.2.511 → 0.2.513

package/docs/operations/REGISTRY.md

@@ -20,7 +20,9 @@ This page documents the JSON contract and the contribution flow. It is the §3 /
 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 install rust-dev-setup # verify and preview changes
+dot registry install rust-dev-setup --yes # verify, persist, and apply
+dot registry installed              # list locally installed modules
 dot registry url                    # show active registry URL
 dot registry set-url <url>          # point at a different registry
 ```
@@ -44,44 +46,43 @@ A registry index is a single JSON document:
       "version": "1.2.0",
       "tags": ["rust", "language", "dev"],
       "maintainer": "alice@example.com",
-      "sha256": "f9a2c1b…",
+      "archive_url": "https://example.com/rust-dev-setup-1.2.0.tar.gz",
+      "sha256": "f9a2c1b0a8d27c41b99c8c93641a0d476a0e54b23161847c47c780025ac7c4a1",
       "license": "MIT"
     }
   ]
 }
 ```
 
-Required keys: `name` (kebab-case, ≤ 32 chars), `description` (≤ 200 chars), `repo` (HTTPS clone URL), `version` (semver).
+Required keys: `name` (kebab-case, no more than 32 characters), `description` (no more than 200 characters), `version` (semver), `archive_url` (immutable HTTPS archive), and `sha256` (64 lowercase hexadecimal characters).
 
-Recommended keys: `tags` (lower-case array), `maintainer`, `sha256` (pinned at publish time so installers can verify), `license` (SPDX identifier).
+Optional keys: `repo` (HTTPS project URL), `tags` (lower-case array), `maintainer`, and `license` (SPDX identifier). The machine-readable contract is [`docs/schema/dot-registry-v1.json`](../schema/dot-registry-v1.json).
 
 ## 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.
+1. Build a gzip-compressed tar archive containing a chezmoi-source-compatible directory. Publish it at an immutable HTTPS URL, such as a versioned GitHub release asset.
 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`.
+   - Runtime contract validity and unique, sorted module names.
+   - Valid JSON for both the index and its published JSON Schema.
+   - A pinned SHA-256 digest for every archive.
 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)
+## Install pipeline
 
-`dot registry install <name>` currently prints what *would* happen. The full pipeline lands as follows:
+`dot registry install <name>` is preview-first and does not mutate the workstation. Pass `--yes` only after reviewing the chezmoi dry-run. The installer:
 
 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.
+2. Download the versioned archive using HTTPS and TLS 1.2 or newer.
+3. Verify the archive against the registry's SHA-256 digest.
+4. Reject absolute paths, parent traversal, symbolic links, and hard links before extraction.
+5. Run `chezmoi apply --dry-run` against the isolated module source.
+6. With `--yes`, persist it at `${XDG_DATA_HOME:-~/.local/share}/dotfiles/modules/<name>/<version>` and apply that exact verified source.
 
 ## 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.
+- Modules execute with the consumer's user privileges via chezmoi scripts. Review the default dry-run and publisher before passing `--yes`.
+- The SHA-256 pin binds installation to the reviewed archive bytes, even if the hosting release later changes.
 - The registry index itself is fetched over HTTPS; the GitHub Pages cert chain provides transport integrity.
 
 ## Why this lives in this repo (for now)

package/docs/operations/ROADMAP.md

@@ -4,163 +4,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.
+The canonical roadmap is [`../../ROADMAP.md`](../../ROADMAP.md).
 
----
-
-## Reproducibility
-
-**Goal:** "Reproducible Shell Environments".
-> *This distribution aims for deterministic rebuilds: the same tag yields the same environment across machines.*
-
-- [ ] **Pinned Formulae**: Strict version locking for Homebrew bundle and Apt packages.
-- [ ] **Binary Locking**: Future versions may replace bootstrap download helpers with checksum-verified artifacts once a portable verification strategy is finalized.
-- [ ] **State Capture**: `chezmoi` templates that capture host-specific state for idempotence.
-- [ ] **Manifests**: Optional `Brewfile.lock` or equivalent for Linux.
-- [ ] **Cloud-Init (Phase 28)**: Generate `user-data` scripts for AWS/GCP bootstrapping.
-- [ ] **Container Native (Phase 28)**: Base Docker image for devcontainers.
-- [ ] **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.*
-
-- [x] **Audit Structuring**: JSON-structured logging for bootstrap and provisioning events.
-- [x] **Debug Modes**: First-class support for `DOTFILES_DEBUG=1` and `DOTFILES_TRACE=1`.
-- [x] **Telemetry (Local)**: Granular startup timing breakdown via `dot perf`.
-- [ ] **Health Dashboard (Phase 39)**: CLI view of system "health" metrics.
-- [ ] **System Status (Phase 39)**: Real-time resource usage, battery, and network stats.
-- [ ] **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.*
-
-- [x] **Secret Driver**: Native integration with 1Password/Bitwarden CLI via `chezmoi`.
-- [x] **Encryption**: Promoted use of `age` encryption for all private config files.
-- [ ] **Leak Prevention (Phase 29)**: Pre-commit hooks (TruffleHog/Gitleaks) for high-entropy detection.
-- [ ] **Vault Integration (Phase 29)**: Native HashiCorp Vault support.
-- [ ] **Hardware Enclaves (Phase 29)**: Support for Secure Enclave/TPM key storage.
-- [ ] **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.*
-
-- [ ] **Core Layer**: XDG, PATH, Safety (`set -euo pipefail`). (Zero external deps).
-- [ ] **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.
-
-## 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.
-
-## 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.
-
-## 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.
-
-## 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.
-- [ ] **Linux Deep Integration (Phase 55)**:
-  - [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.
-- [ ] **Financial Operations (Phase 63)**: Cost CLI, Ledger, Stock Tickers.
-- [ ] **Game Development (Phase 64)**: Unity/Unreal CLI, Godot, Blender.
-- [ ] **Scientific Computing (Phase 68)**: Latex, R/Julia, Pandoc.
-- [ ] **Quantum Computing (Phase 69)**: Qiskit, Simulators.
-- [ ] **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.
-- [ ] **Enterprise Fleet (Phase 30)**: MDM Profiles, Policy as Code.
-- [ ] **Legal & Procurement (Phase 93)**: RFP Templates, Vendor Management.
-- [ ] **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.
-
----
-
-## 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)**
-- [x] **Enterprise Core (Phase 23)**: SLSA, SBOM, Signed Releases.
-- [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.
-- [x] **Predictive Shell (Phase 32)**: Autosuggest, Local LLM.
-- [x] **Visual Layer (Phase 34)**: Yazi, Zellij, Ghostty.
+This file is retained only so existing documentation links continue to resolve.
+Do not add active planning content here.