sauron-cli 1.3.0 → 1.4.0

package/OpenSpec-main/openspec/changes/archive/2026-01-09-add-posthog-analytics/specs/telemetry/spec.md

@@ -1,116 +0,0 @@
-## ADDED Requirements
-
-### Requirement: Command execution tracking
-The system SHALL send a `command_executed` event to PostHog when any CLI command executes, including only the command name and OpenSpec version as properties.
-
-#### Scenario: Standard command execution
-- **WHEN** a user runs any openspec command
-- **THEN** the system sends a `command_executed` event with `command` and `version` properties
-
-#### Scenario: Subcommand execution
-- **WHEN** a user runs a nested command like `openspec change apply`
-- **THEN** the system sends a `command_executed` event with the full command path (e.g., `change:apply`)
-
-### Requirement: Privacy-preserving event design
-The system SHALL NOT include command arguments, file paths, project names, spec content, error messages, or IP addresses in telemetry events.
-
-#### Scenario: Command with arguments
-- **WHEN** a user runs `openspec init my-project --force`
-- **THEN** the telemetry event contains only `command: "init"` and `version: "<version>"` without arguments
-
-#### Scenario: IP address exclusion
-- **WHEN** the system sends a telemetry event
-- **THEN** the event explicitly sets `$ip: null` to prevent IP tracking
-
-### Requirement: Environment variable opt-out
-The system SHALL disable telemetry when `OPENSPEC_TELEMETRY=0` or `DO_NOT_TRACK=1` environment variables are set.
-
-#### Scenario: OPENSPEC_TELEMETRY opt-out
-- **WHEN** `OPENSPEC_TELEMETRY=0` is set in the environment
-- **THEN** the system sends no telemetry events
-
-#### Scenario: DO_NOT_TRACK opt-out
-- **WHEN** `DO_NOT_TRACK=1` is set in the environment
-- **THEN** the system sends no telemetry events
-
-#### Scenario: Environment variable takes precedence
-- **WHEN** the user has previously used the CLI (config exists)
-- **AND** the user sets `OPENSPEC_TELEMETRY=0`
-- **THEN** telemetry is disabled regardless of config state
-
-### Requirement: CI environment auto-disable
-The system SHALL automatically disable telemetry when `CI=true` environment variable is detected.
-
-#### Scenario: CI environment detection
-- **WHEN** `CI=true` is set in the environment
-- **THEN** the system sends no telemetry events
-
-#### Scenario: CI with explicit enable
-- **WHEN** `CI=true` is set
-- **AND** `OPENSPEC_TELEMETRY=1` is explicitly set
-- **THEN** telemetry remains disabled (CI takes precedence for privacy)
-
-### Requirement: First-run telemetry notice
-The system SHALL display a one-line telemetry disclosure notice on the first command execution, before any telemetry is sent.
-
-#### Scenario: First command execution
-- **WHEN** a user runs their first openspec command
-- **AND** telemetry is enabled
-- **THEN** the system displays: "Note: OpenSpec collects anonymous usage stats. Opt out: OPENSPEC_TELEMETRY=0"
-
-#### Scenario: Subsequent command execution
-- **WHEN** a user has already seen the notice (noticeSeen: true in config)
-- **THEN** the system does not display the notice
-
-#### Scenario: Notice before telemetry
-- **WHEN** displaying the first-run notice
-- **THEN** the notice appears before any telemetry event is sent
-
-### Requirement: Anonymous user identification
-The system SHALL generate a random UUID as an anonymous identifier on first telemetry send, stored in global config.
-
-#### Scenario: First telemetry event
-- **WHEN** the first telemetry event is sent
-- **AND** no anonymousId exists in config
-- **THEN** the system generates a random UUID v4 and stores it in config
-
-#### Scenario: Persistent identity
-- **WHEN** a user runs multiple commands across sessions
-- **THEN** the same anonymousId is used for all events
-
-#### Scenario: Lazy generation with opt-out
-- **WHEN** a user opts out before running any command
-- **THEN** no anonymousId is ever generated or stored
-
-### Requirement: Immediate event sending
-The system SHALL send telemetry events immediately without batching, using `flushAt: 1` and `flushInterval: 0` configuration.
-
-#### Scenario: Event transmission timing
-- **WHEN** a command executes
-- **THEN** the telemetry event is sent immediately, not queued for batch transmission
-
-### Requirement: Graceful shutdown
-The system SHALL call `posthog.shutdown()` before CLI exit to ensure pending events are flushed.
-
-#### Scenario: Normal exit
-- **WHEN** a command completes successfully
-- **THEN** the system awaits `shutdown()` before exiting
-
-#### Scenario: Error exit
-- **WHEN** a command fails with an error
-- **THEN** the system still awaits `shutdown()` before exiting
-
-### Requirement: Silent failure handling
-The system SHALL silently ignore telemetry failures without affecting CLI functionality.
-
-#### Scenario: Network failure
-- **WHEN** the telemetry request fails due to network error
-- **THEN** the CLI command completes normally without error message
-
-#### Scenario: PostHog outage
-- **WHEN** PostHog service is unavailable
-- **THEN** the CLI command completes normally without error message
-
-#### Scenario: Shutdown failure
-- **WHEN** `shutdown()` fails or times out
-- **THEN** the CLI exits normally without error message

package/OpenSpec-main/openspec/changes/archive/2026-01-09-add-posthog-analytics/tasks.md

@@ -1,47 +0,0 @@
-## 1. Setup
-
-- [x] 1.1 Add `posthog-node` package as a dependency
-- [x] 1.2 Create `src/telemetry/` module directory
-- [x] 1.3 Add PostHog API key configuration (environment variable or embedded)
-
-## 2. Global Config
-
-- [x] 2.1 Create or extend global config module for `~/.config/openspec/config.json`
-- [x] 2.2 Implement read/write functions that preserve existing config fields
-- [x] 2.3 Define telemetry config structure (`anonymousId`, `noticeSeen`)
-
-## 3. Core Telemetry Module
-
-- [x] 3.1 Implement `isTelemetryEnabled()` checking `OPENSPEC_TELEMETRY`, `DO_NOT_TRACK`, and `CI` env vars
-- [x] 3.2 Implement `getOrCreateAnonymousId()` with lazy UUID generation
-- [x] 3.3 Initialize PostHog client with `flushAt: 1` and `flushInterval: 0`
-- [x] 3.4 Implement `trackCommand(commandName, version)` with `$ip: null`
-- [x] 3.5 Implement `shutdown()` with try/catch for silent failure handling
-
-## 4. First-Run Notice
-
-- [x] 4.1 Implement `maybeShowTelemetryNotice()` function
-- [x] 4.2 Check `noticeSeen` flag before displaying notice
-- [x] 4.3 Display notice text: "Note: OpenSpec collects anonymous usage stats. Opt out: OPENSPEC_TELEMETRY=0"
-- [x] 4.4 Update `noticeSeen` in config after first display
-
-## 5. CLI Integration
-
-- [x] 5.1 Add Commander.js `preAction` hook to show notice and track command
-- [x] 5.2 Add Commander.js `postAction` hook to call shutdown
-- [x] 5.3 Handle subcommand path extraction (e.g., `change:apply`)
-
-## 6. Testing
-
-- [x] 6.1 Test opt-out via `OPENSPEC_TELEMETRY=0`
-- [x] 6.2 Test opt-out via `DO_NOT_TRACK=1`
-- [x] 6.3 Test auto-disable in CI environment
-- [x] 6.4 Test first-run notice display and noticeSeen persistence
-- [x] 6.5 Test anonymous ID generation and persistence
-- [x] 6.6 Test silent failure on network error (mock PostHog)
-
-## 7. Documentation
-
-- [x] 7.1 Add telemetry disclosure section to README
-- [x] 7.2 Document opt-out methods (`OPENSPEC_TELEMETRY=0`, `DO_NOT_TRACK=1`)
-- [x] 7.3 Document what data is collected and not collected

package/OpenSpec-main/openspec/changes/archive/2026-01-09-fix-codebuddy-frontmatter-fields/proposal.md

@@ -1,16 +0,0 @@
-## Why
-
-CodeBuddy slash command configurator currently uses inconsistent frontmatter fields compared to other tools. It uses `category` and `tags` fields (like Crush) but should use `argument-hint` field (like Factory, Auggie, and Codex) for better consistency. Additionally, the `proposal` command is missing frontmatter fields entirely. After reviewing CodeBuddy's official documentation, the correct format should use `description` and `argument-hint` fields with square bracket parameter format.
-
-## What Changes
-
-- Replace `category` and `tags` fields with `argument-hint` field in CodeBuddy frontmatter
-- Add missing frontmatter fields to the `proposal` command
-- Use correct square bracket format for `argument-hint` parameters (e.g., `[change-id]`)
-- Ensure consistency with CodeBuddy's official documentation
-
-## Impact
-
-- Affected specs: cli-init, cli-update
-- Affected code: `src/core/configurators/slash/codebuddy.ts`
-- CodeBuddy users will get proper argument hints in the correct format for slash commands

package/OpenSpec-main/openspec/changes/archive/2026-01-09-fix-codebuddy-frontmatter-fields/specs/cli-init/spec.md

@@ -1,75 +0,0 @@
-## MODIFIED Requirements
-
-### Requirement: Slash Command Configuration
-
-The init command SHALL generate slash command files for supported editors using shared templates.
-
-#### Scenario: Generating slash commands for Antigravity
-- **WHEN** the user selects Antigravity during initialization
-- **THEN** create `.agent/workflows/openspec-proposal.md`, `.agent/workflows/openspec-apply.md`, and `.agent/workflows/openspec-archive.md`
-- **AND** ensure each file begins with YAML frontmatter that contains only a `description: <stage summary>` field followed by the shared OpenSpec workflow instructions wrapped in managed markers
-- **AND** populate the workflow body with the same proposal/apply/archive guidance used for other tools so Antigravity behaves like Windsurf while pointing to the `.agent/workflows/` directory
-
-#### Scenario: Generating slash commands for Claude Code
-- **WHEN** the user selects Claude Code during initialization
-- **THEN** create `.claude/commands/openspec/proposal.md`, `.claude/commands/openspec/apply.md`, and `.claude/commands/openspec/archive.md`
-- **AND** populate each file from shared templates so command text matches other tools
-- **AND** each template includes instructions for the relevant OpenSpec workflow stage
-
-#### Scenario: Generating slash commands for CodeBuddy Code
-- **WHEN** the user selects CodeBuddy Code during initialization
-- **THEN** create `.codebuddy/commands/openspec/proposal.md`, `.codebuddy/commands/openspec/apply.md`, and `.codebuddy/commands/openspec/archive.md`
-- **AND** populate each file from shared templates that include CodeBuddy-compatible YAML frontmatter for the `description` and `argument-hint` fields
-- **AND** use square bracket format for `argument-hint` parameters (e.g., `[change-id]`)
-- **AND** each template includes instructions for the relevant OpenSpec workflow stage
-
-#### Scenario: Generating slash commands for Cline
-- **WHEN** the user selects Cline during initialization
-- **THEN** create `.clinerules/workflows/openspec-proposal.md`, `.clinerules/workflows/openspec-apply.md`, and `.clinerules/workflows/openspec-archive.md`
-- **AND** populate each file from shared templates so command text matches other tools
-- **AND** include Cline-specific Markdown heading frontmatter
-- **AND** each template includes instructions for the relevant OpenSpec workflow stage
-
-#### Scenario: Generating slash commands for Crush
-- **WHEN** the user selects Crush during initialization
-- **THEN** create `.crush/commands/openspec/proposal.md`, `.crush/commands/openspec/apply.md`, and `.crush/commands/openspec/archive.md`
-- **AND** populate each file from shared templates so command text matches other tools
-- **AND** include Crush-specific frontmatter with OpenSpec category and tags
-- **AND** each template includes instructions for the relevant OpenSpec workflow stage
-
-#### Scenario: Generating slash commands for Cursor
-- **WHEN** the user selects Cursor during initialization
-- **THEN** create `.cursor/commands/openspec-proposal.md`, `.cursor/commands/openspec-apply.md`, and `.cursor/commands/openspec-archive.md`
-- **AND** populate each file from shared templates so command text matches other tools
-- **AND** each template includes instructions for the relevant OpenSpec workflow stage
-
-#### Scenario: Generating slash commands for Factory Droid
-- **WHEN** the user selects Factory Droid during initialization
-- **THEN** create `.factory/commands/openspec-proposal.md`, `.factory/commands/openspec-apply.md`, and `.factory/commands/openspec-archive.md`
-- **AND** populate each file from shared templates that include Factory-compatible YAML frontmatter for the `description` and `argument-hint` fields
-- **AND** include the `$ARGUMENTS` placeholder in the template body so droid receives any user-supplied input
-- **AND** wrap the generated content in OpenSpec managed markers so `openspec update` can safely refresh the commands
-
-#### Scenario: Generating slash commands for OpenCode
-- **WHEN** the user selects OpenCode during initialization
-- **THEN** create `.opencode/commands/openspec-proposal.md`, `.opencode/commands/openspec-apply.md`, and `.opencode/commands/openspec-archive.md`
-- **AND** populate each file from shared templates so command text matches other tools
-- **AND** each template includes instructions for the relevant OpenSpec workflow stage
-
-#### Scenario: Generating slash commands for Windsurf
-- **WHEN** the user selects Windsurf during initialization
-- **THEN** create `.windsurf/workflows/openspec-proposal.md`, `.windsurf/workflows/openspec-apply.md`, and `.windsurf/workflows/openspec-archive.md`
-- **AND** populate each file from shared templates (wrapped in OpenSpec markers) so workflow text matches other tools
-- **AND** each template includes instructions for the relevant OpenSpec workflow stage
-
-#### Scenario: Generating slash commands for Kilo Code
-- **WHEN** the user selects Kilo Code during initialization
-- **THEN** create `.kilocode/workflows/openspec-proposal.md`, `.kilocode/workflows/openspec-apply.md`, and `.kilocode/workflows/openspec-archive.md`
-- **AND** populate each file from shared templates (wrapped in OpenSpec markers) so workflow text matches other tools
-- **AND** each template includes instructions for the relevant OpenSpec workflow stage
-
-#### Scenario: Generating slash commands for Codex
-- **WHEN** the user selects Codex during initialization
-- **THEN** create global prompt files at `~/.codex/prompts/openspec-proposal.md`, `~/.codex/prompts/openspec-apply.md`, and `~/.codex/prompts/openspec-archive.md` (or under `$CODEX_HOME/prompts` if set)
-- **AND** populate each file from shared templates that map the first numbered placeholder (`$1`) to the primary user input (e.g., change identifier or question text)
-- **AND** wrap the generated content in OpenSpec markers so `openspec update` can refresh the prompts without touching surrounding custom notes

package/OpenSpec-main/openspec/changes/archive/2026-01-09-fix-codebuddy-frontmatter-fields/specs/cli-update/spec.md

@@ -1,56 +0,0 @@
-## MODIFIED Requirements
-
-### Requirement: Slash Command Updates
-
-The update command SHALL refresh existing slash command files for configured tools without creating new ones, and ensure the OpenCode archive command accepts change ID arguments.
-
-#### Scenario: Updating slash commands for Antigravity
-- **WHEN** `.agent/workflows/` contains `openspec-proposal.md`, `openspec-apply.md`, and `openspec-archive.md`
-- **THEN** refresh the OpenSpec-managed portion of each file so the workflow copy matches other tools while preserving the existing single-field `description` frontmatter
-- **AND** skip creating any missing workflow files during update, mirroring the behavior for Windsurf and other IDEs
-
-#### Scenario: Updating slash commands for Claude Code
-- **WHEN** `.claude/commands/openspec/` contains `proposal.md`, `apply.md`, and `archive.md`
-- **THEN** refresh each file using shared templates
-- **AND** ensure templates include instructions for the relevant workflow stage
-
-#### Scenario: Updating slash commands for CodeBuddy Code
-- **WHEN** `.codebuddy/commands/openspec/` contains `proposal.md`, `apply.md`, and `archive.md`
-- **THEN** refresh each file using the shared CodeBuddy templates that include YAML frontmatter for the `description` and `argument-hint` fields
-- **AND** use square bracket format for `argument-hint` parameters (e.g., `[change-id]`)
-- **AND** preserve any user customizations outside the OpenSpec managed markers
-
-#### Scenario: Updating slash commands for Cline
-- **WHEN** `.clinerules/workflows/` contains `openspec-proposal.md`, `openspec-apply.md`, and `openspec-archive.md`
-- **THEN** refresh each file using shared templates
-- **AND** include Cline-specific Markdown heading frontmatter
-- **AND** ensure templates include instructions for the relevant workflow stage
-
-#### Scenario: Updating slash commands for Crush
-- **WHEN** `.crush/commands/` contains `openspec/proposal.md`, `openspec/apply.md`, and `openspec/archive.md`
-- **THEN** refresh each file using shared templates
-- **AND** include Crush-specific frontmatter with OpenSpec category and tags
-- **AND** ensure templates include instructions for the relevant workflow stage
-
-#### Scenario: Updating slash commands for Cursor
-- **WHEN** `.cursor/commands/` contains `openspec-proposal.md`, `openspec-apply.md`, and `openspec-archive.md`
-- **THEN** refresh each file using shared templates
-- **AND** ensure templates include instructions for the relevant workflow stage
-
-#### Scenario: Updating slash commands for Factory Droid
-- **WHEN** `.factory/commands/` contains `openspec-proposal.md`, `openspec-apply.md`, and `openspec-archive.md`
-- **THEN** refresh each file using the shared Factory templates that include YAML frontmatter for the `description` and `argument-hint` fields
-- **AND** ensure the template body retains the `$ARGUMENTS` placeholder so user input keeps flowing into droid
-- **AND** update only the content inside the OpenSpec managed markers, leaving any unmanaged notes untouched
-- **AND** skip creating missing files during update
-
-#### Scenario: Updating slash commands for OpenCode
-- **WHEN** `.opencode/command/` contains `openspec-proposal.md`, `openspec-apply.md`, and `openspec-archive.md`
-- **THEN** refresh each file using shared templates
-- **AND** ensure templates include instructions for the relevant workflow stage
-- **AND** ensure the archive command includes `$ARGUMENTS` placeholder in frontmatter for accepting change ID arguments
-
-#### Scenario: Updating slash commands for Windsurf
-- **WHEN** `.windsurf/workflows/` contains `openspec-proposal.md`, `openspec-apply.md`, and `openspec-archive.md`
-- **THEN** refresh each file using shared templates
-- **AND** ensure templates include instructions for the relevant workflow stage

package/OpenSpec-main/openspec/changes/archive/2026-01-09-fix-codebuddy-frontmatter-fields/tasks.md

@@ -1,6 +0,0 @@
-## 1. Implementation
-
-- [x] 1.1 Update CodeBuddy frontmatter to use `argument-hint` instead of `category` and `tags`
-- [x] 1.2 Add missing frontmatter fields to the `proposal` command
-- [x] 1.3 Ensure all three commands (proposal, apply, archive) have consistent frontmatter structure
-- [x] 1.4 Test the changes by running `openspec init` and `openspec update`

package/OpenSpec-main/openspec/changes/archive/2026-01-15-add-nix-ci-validation/design.md

@@ -1,206 +0,0 @@
-# Design: Nix CI Validation
-
-## Context
-
-OpenSpec recently added Nix flake support to enable Nix users to install the tool. This includes:
-- `flake.nix`: Nix package definition with pnpm dependency fetching
-- `scripts/update-flake.sh`: Automation script to update version and hash when releasing
-
-Currently, there is no CI validation ensuring these Nix artifacts remain functional. The existing CI workflow (.github/workflows/ci.yml) validates Node.js builds, tests, and linting across multiple platforms (Linux, macOS, Windows) but does not validate Nix builds.
-
-**Stakeholders**: Nix users, maintainers, contributors who need confidence that Nix support works.
-
-**Constraints**:
-- Must work in GitHub Actions Linux runners
-- Should minimize CI runtime impact (<5 minutes added)
-- Should support local testing with `act` for rapid iteration
-- Must integrate with existing required checks
-
-## Goals / Non-Goals
-
-**Goals**:
-- Validate `nix build` succeeds on every PR/push
-- Validate `scripts/update-flake.sh` executes without errors
-- Ensure Nix support doesn't regress silently
-- Support local testing with `act`
-- Optimize with caching to minimize CI time
-
-**Non-Goals**:
-- Testing on macOS (GitHub-hosted macOS runners are slower and more expensive; Nix flake already declares macOS support)
-- Building for all declared systems (x86_64-linux, aarch64-linux, x86_64-darwin, aarch64-darwin) - focus on most common platform
-- Validating Nix flake quality/style (nixpkgs-fmt, etc.) - can be added later if needed
-- Running OpenSpec's full test suite through Nix build - existing CI already does this
-
-## Decisions
-
-### Decision 1: Use DeterminateSystems nix-installer-action
-
-**What**: Use `determinatesystems/nix-installer-action` for installing Nix in CI.
-
-**Why**:
-- Official GitHub Action maintained by Determinate Systems (Nix experts)
-- Handles GitHub Actions environment quirks automatically
-- Includes automatic caching configuration
-- More reliable than curl | sh installation script
-- Better error messages and diagnostics
-
-**Alternatives considered**:
-- Official Nix installer (`curl -L https://nixos.org/nix/install | sh`): Works but requires manual setup of flakes, caching, and CI-specific configuration
-- `cachix/install-nix-action`: Popular alternative but determinatesystems is more actively maintained and has better GHA integration
-
-### Decision 2: Use Magic Nix Cache for performance
-
-**What**: Use `determinatesystems/magic-nix-cache-action` for automatic binary caching.
-
-**Why**:
-- Zero-configuration caching for Nix store
-- Significantly reduces CI time on subsequent runs (from ~5min to ~1-2min)
-- Free for public repositories
-- Handles cache keys automatically
-
-**Alternatives considered**:
-- Manual Nix store caching with GitHub Actions cache: More complex, requires manual cache key management
-- Cachix: Excellent tool but requires account setup and token management
-- No caching: Acceptable for initial implementation, but poor developer experience
-
-### Decision 3: Separate job for Nix validation
-
-**What**: Create a dedicated `nix-validate` job in .github/workflows/ci.yml that runs in parallel with other jobs.
-
-**Why**:
-- Keeps Nix validation isolated from Node.js validation
-- Allows parallel execution for faster CI
-- Easier to debug when Nix-specific issues occur
-- Can be marked as required check independently
-
-**Alternatives considered**:
-- Add Nix steps to existing jobs: Creates coupling between Node.js and Nix validation, harder to maintain
-- Separate workflow file: Overkill for a single job, harder to manage required checks
-
-### Decision 4: Validate update script by executing it
-
-**What**: Run `scripts/update-flake.sh` as part of CI validation.
-
-**Why**:
-- Ensures the script doesn't break due to changes in package.json format, nix build output, or dependencies
-- Tests the full workflow users will follow when releasing
-- Catches errors early
-
-**Implementation approach**:
-- Execute script in a way that doesn't modify git state (or discard changes after)
-- Verify script exits with code 0
-- Optionally validate that flake.nix contains expected patterns after execution
-
-**Alternatives considered**:
-- Mock/dry-run mode: Would require modifying the script significantly
-- Skip validation: Risky - script could break and only be discovered at release time
-- Only run on release branches: Misses issues early in development
-
-### Decision 5: Run on pull_request and push to main
-
-**What**: Configure Nix validation job to run on:
-- `pull_request` events (any PR to main)
-- `push` events (direct pushes to main)
-- `workflow_dispatch` (manual trigger for testing)
-
-**Why**:
-- Catches issues before merge (pull_request)
-- Validates main branch stays healthy (push)
-- Allows manual testing without creating PRs (workflow_dispatch)
-
-### Decision 6: Support act for local testing
-
-**What**: Ensure workflow is compatible with `act` tool for local CI testing.
-
-**Why**:
-- Faster iteration when developing CI changes
-- Allows testing without pushing to GitHub
-- Reduces commit noise from CI debugging
-
-**Requirements**:
-- Use standard GitHub Actions syntax
-- Document any act-specific configuration needed
-- Test that Nix can be installed in act's Docker containers
-
-**Limitations**:
-- act may not perfectly replicate GitHub's runners, but close enough for validation
-
-## Risks / Trade-offs
-
-### Risk: CI runtime increase
-
-**Impact**: Adding Nix validation will increase total CI time by 2-5 minutes per run.
-
-**Mitigation**:
-- Run Nix job in parallel with existing jobs (no blocking delay)
-- Use magic-nix-cache for subsequent runs (~1-2 min with cache)
-- Configure appropriate timeout (10 minutes max)
-
-**Acceptance**: The benefit of preventing Nix regressions outweighs the cost.
-
-### Risk: Nix installer failures in CI
-
-**Impact**: Transient failures in Nix installation could block PRs.
-
-**Mitigation**:
-- Use determinatesystems action which has retry logic
-- Monitor for flaky failures and adjust if needed
-- Document troubleshooting steps
-
-**Acceptance**: Nix installation is generally stable in GHA; this is low risk.
-
-### Risk: Update script modifies git state
-
-**Impact**: Running update-flake.sh modifies flake.nix, which could cause CI to fail if git state is checked.
-
-**Mitigation**:
-- Run script in isolation without committing changes
-- Add `git checkout -- flake.nix` after validation
-- Or accept dirty git state in CI (doesn't affect build validation)
-
-**Acceptance**: Script validation is important enough to handle this carefully.
-
-### Risk: act compatibility issues
-
-**Impact**: Workflow might not work perfectly with act due to Docker environment differences.
-
-**Mitigation**:
-- Document known limitations
-- Focus on GitHub Actions as primary validation target
-- Use act as best-effort local testing
-
-**Acceptance**: act support is nice-to-have, not required.
-
-## Migration Plan
-
-### Phase 1: Add Nix job (new, non-required)
-1. Add `nix-validate` job to .github/workflows/ci.yml
-2. Configure to run in parallel with existing jobs
-3. Do NOT mark as required check initially
-4. Monitor for ~1 week to ensure stability
-
-### Phase 2: Make required
-1. After validation is stable, add to required checks
-2. Update branch protection rules in GitHub settings
-3. Document in CONTRIBUTING.md or README
-
-### Rollback Plan
-If Nix validation causes issues:
-1. Remove job from required checks in GitHub settings (immediate)
-2. Comment out or remove job from workflow (permanent fix)
-3. Investigate and fix issues
-4. Re-enable following same phased approach
-
-## Open Questions
-
-- **Q**: Should we test update-flake.sh on every CI run, or only when package.json or pnpm-lock.yaml changes?
-  - **A**: Test on every run for simplicity. The script is fast (<30 seconds) and catching regressions is valuable.
-
-- **Q**: Should we validate on macOS as well?
-  - **A**: No for initial implementation. Linux validation is sufficient and macOS runners are slower/more expensive. Can add later if users report macOS-specific issues.
-
-- **Q**: Should we run full OpenSpec tests through the Nix build?
-  - **A**: No. The Nix build already runs `pnpm test` as part of its build phase. Existing CI jobs cover testing thoroughly. Nix validation focuses on build success.
-
-- **Q**: What timeout should we use for the Nix validation job?
-  - **A**: Start with 10 minutes. With caching, jobs should complete in 1-3 minutes. Without cache (first run), 5-7 minutes is expected.

package/OpenSpec-main/openspec/changes/archive/2026-01-15-add-nix-ci-validation/proposal.md

@@ -1,21 +0,0 @@
-# Add Nix CI Validation
-
-## Why
-
-The project recently added Nix flake support (flake.nix) and an automated update script (scripts/update-flake.sh) to enable Nix users to install OpenSpec. However, there is no CI validation ensuring these Nix artifacts continue to work as the project evolves. This creates risk that breaking changes could be merged without detection.
-
-## What Changes
-
-- Add a new GitHub Actions workflow job to validate Nix flake builds successfully
-- Add validation that the update-flake.sh script executes without errors
-- Test on Linux (where Nix support is most common)
-- Ensure CI fails if Nix build or update script breaks
-- Enable local testing with `act` for developers
-
-## Impact
-
-- Affected specs: New capability `ci-nix-validation`
-- Affected code: `.github/workflows/ci.yml` (add new job)
-- Affected infrastructure: GitHub Actions runners with Nix installed
-- Benefits: Prevents regressions in Nix support, gives confidence to Nix users
-- Trade-offs: Adds ~2-3 minutes to CI runtime

package/OpenSpec-main/openspec/changes/archive/2026-01-15-add-nix-ci-validation/specs/ci-nix-validation/spec.md

@@ -1,104 +0,0 @@
-# CI Nix Validation Specification
-
-## ADDED Requirements
-
-### Requirement: Nix Flake Build Validation
-
-The CI system SHALL validate that the Nix flake builds successfully on every pull request and push to main.
-
-#### Scenario: Successful flake build
-
-- **WHEN** a pull request or push to main is made
-- **THEN** the CI SHALL execute `nix build` and verify it completes with exit code 0
-- **AND** the build output SHALL contain the openspec binary
-
-#### Scenario: Flake build failure
-
-- **WHEN** the Nix flake configuration is broken
-- **THEN** the CI job SHALL fail with a non-zero exit code
-- **AND** the CI SHALL prevent merging of the pull request
-
-#### Scenario: Multi-platform support check
-
-- **WHEN** the flake declares support for multiple systems
-- **THEN** the CI SHALL validate the flake builds on at least Linux (x86_64-linux)
-
-### Requirement: Update Script Validation
-
-The CI system SHALL validate that the update-flake.sh script executes successfully and produces valid output.
-
-#### Scenario: Update script execution
-
-- **WHEN** the CI runs the update script validation
-- **THEN** the script SHALL execute without errors
-- **AND** the script SHALL correctly extract the version from package.json
-- **AND** the script SHALL update flake.nix with the correct version
-
-#### Scenario: Update script with mock hash
-
-- **WHEN** validating the update script in CI
-- **THEN** the script SHALL be able to detect and extract the correct pnpm dependency hash
-- **AND** the flake.nix SHALL be updated with a valid sha256 hash
-
-### Requirement: CI Job Integration
-
-The Nix validation jobs SHALL be integrated into the existing GitHub Actions workflow and required for merge.
-
-#### Scenario: PR merge requirements
-
-- **WHEN** a pull request is created
-- **THEN** the Nix validation job SHALL be included in required checks
-- **AND** the PR SHALL NOT be mergeable until Nix validation passes
-
-#### Scenario: Job execution triggers
-
-- **WHEN** code is pushed to a pull request OR pushed to main OR manually triggered
-- **THEN** the Nix validation job SHALL execute automatically
-
-### Requirement: Local Testing Support
-
-The CI workflow SHALL be testable locally using the `act` tool to enable rapid iteration.
-
-#### Scenario: Local CI execution with act
-
-- **WHEN** a developer runs `act` with the Nix validation workflow
-- **THEN** the workflow SHALL execute in the local Docker environment
-- **AND** the developer SHALL receive feedback on Nix build status without pushing to GitHub
-
-#### Scenario: Act configuration compatibility
-
-- **WHEN** the workflow is designed
-- **THEN** it SHALL use standard GitHub Actions syntax compatible with `act`
-- **AND** any Nix-specific setup SHALL work in the act Docker environment
-
-### Requirement: Nix Installation in CI
-
-The CI environment SHALL have Nix properly installed and configured before running validation.
-
-#### Scenario: Nix installation step
-
-- **WHEN** the Nix validation job starts
-- **THEN** Nix SHALL be installed using the official Nix installer or determinatesystems/nix-installer-action
-- **AND** the Nix installation SHALL be cached for subsequent runs to improve performance
-
-#### Scenario: Nix configuration for CI
-
-- **WHEN** Nix is installed in CI
-- **THEN** it SHALL be configured to work in the GitHub Actions environment
-- **AND** experimental features (flakes, nix-command) SHALL be enabled
-
-### Requirement: CI Performance Optimization
-
-The Nix validation SHALL be optimized to minimize CI runtime impact.
-
-#### Scenario: Acceptable runtime
-
-- **WHEN** the Nix validation job runs
-- **THEN** it SHALL complete in under 5 minutes on a clean run
-- **AND** with caching, it SHALL complete in under 3 minutes on subsequent runs
-
-#### Scenario: Parallel execution
-
-- **WHEN** multiple CI jobs are running
-- **THEN** the Nix validation job SHALL run in parallel with other validation jobs (tests, lint)
-- **AND** SHALL NOT block other independent checks