sauron-cli 1.3.0 → 1.4.1

package/OpenSpec-main/openspec/changes/archive/2025-11-06-add-shell-completions/specs/cli-completion/spec.md

@@ -1,300 +0,0 @@
-# CLI Completion Specification
-
-## Purpose
-
-The `openspec completion` command SHALL provide shell completion functionality for all OpenSpec CLI commands, flags, and dynamic values (change IDs, spec IDs), with support for Zsh (including Oh My Zsh) and a scalable architecture ready for future shells (bash, fish, PowerShell). The completion system SHALL integrate with Zsh's native completion behavior rather than attempting to customize the user experience.
-
-## ADDED Requirements
-
-### Requirement: Native Shell Behavior Integration
-
-The completion system SHALL respect and integrate with Zsh's native completion patterns and user interaction model.
-
-#### Scenario: Zsh native completion
-
-- **WHEN** generating Zsh completion scripts
-- **THEN** use Zsh completion system with `_arguments`, `_describe`, and `compadd`
-- **AND** completions SHALL trigger on single TAB (standard Zsh behavior)
-- **AND** display as an interactive menu that users navigate with TAB/arrow keys
-- **AND** support Oh My Zsh's enhanced menu styling automatically
-
-#### Scenario: No custom UX patterns
-
-- **WHEN** implementing Zsh completion
-- **THEN** do NOT attempt to customize completion trigger behavior
-- **AND** do NOT override Zsh-specific navigation patterns
-- **AND** ensure completions feel native to experienced Zsh users
-
-### Requirement: Command Structure
-
-The completion command SHALL follow a subcommand pattern for generating and managing completion scripts.
-
-#### Scenario: Available subcommands
-
-- **WHEN** user executes `openspec completion --help`
-- **THEN** display available subcommands:
-  - `zsh` - Generate Zsh completion script
-  - `install [shell]` - Install completion for Zsh (auto-detects or requires explicit shell)
-  - `uninstall [shell]` - Remove completion for Zsh (auto-detects or requires explicit shell)
-
-### Requirement: Shell Detection
-
-The completion system SHALL automatically detect the user's current shell environment.
-
-#### Scenario: Detecting Zsh from environment
-
-- **WHEN** no shell is explicitly specified
-- **THEN** read the `$SHELL` environment variable
-- **AND** extract the shell name from the path (e.g., `/bin/zsh` → `zsh`)
-- **AND** validate the shell is `zsh`
-- **AND** throw an error if the shell is not `zsh`, with message indicating only Zsh is currently supported
-
-#### Scenario: Non-Zsh shell detection
-
-- **WHEN** shell path indicates bash, fish, powershell, or other non-Zsh shell
-- **THEN** throw error: "Shell '<name>' is not supported yet. Currently supported: zsh"
-
-### Requirement: Completion Generation
-
-The completion command SHALL generate Zsh completion scripts on demand.
-
-#### Scenario: Generating Zsh completion
-
-- **WHEN** user executes `openspec completion zsh`
-- **THEN** output a complete Zsh completion script to stdout
-- **AND** include completions for all commands: init, list, show, validate, archive, view, update, change, spec, completion
-- **AND** include all command-specific flags and options
-- **AND** use Zsh's `_arguments` and `_describe` built-in functions
-- **AND** support dynamic completion for change and spec IDs
-
-### Requirement: Dynamic Completions
-
-The completion system SHALL provide context-aware dynamic completions for project-specific values.
-
-#### Scenario: Completing change IDs
-
-- **WHEN** completing arguments for commands that accept change names (show, validate, archive)
-- **THEN** discover active changes from `openspec/changes/` directory
-- **AND** exclude archived changes in `openspec/changes/archive/`
-- **AND** return change IDs as completion suggestions
-- **AND** only provide suggestions when inside an OpenSpec-enabled project
-
-#### Scenario: Completing spec IDs
-
-- **WHEN** completing arguments for commands that accept spec names (show, validate)
-- **THEN** discover specs from `openspec/specs/` directory
-- **AND** return spec IDs as completion suggestions
-- **AND** only provide suggestions when inside an OpenSpec-enabled project
-
-#### Scenario: Completion caching
-
-- **WHEN** dynamic completions are requested
-- **THEN** cache discovered change and spec IDs for 2 seconds
-- **AND** reuse cached values for subsequent requests within cache window
-- **AND** automatically refresh cache after expiration
-
-#### Scenario: Project detection
-
-- **WHEN** user requests completions outside an OpenSpec project
-- **THEN** skip dynamic change/spec ID completions
-- **AND** only suggest static commands and flags
-
-### Requirement: Installation Automation
-
-The completion command SHALL automatically install completion scripts into shell configuration files.
-
-#### Scenario: Installing for Oh My Zsh
-
-- **WHEN** user executes `openspec completion install zsh`
-- **THEN** detect if Oh My Zsh is installed by checking for `$ZSH` environment variable or `~/.oh-my-zsh/` directory
-- **AND** create custom completions directory at `~/.oh-my-zsh/custom/completions/` if it doesn't exist
-- **AND** write completion script to `~/.oh-my-zsh/custom/completions/_openspec`
-- **AND** ensure `~/.oh-my-zsh/custom/completions` is in `$fpath` by updating `~/.zshrc` if needed
-- **AND** display success message with instruction to run `exec zsh` or restart terminal
-
-#### Scenario: Installing for standard Zsh
-
-- **WHEN** user executes `openspec completion install zsh` and Oh My Zsh is not detected
-- **THEN** create completions directory at `~/.zsh/completions/` if it doesn't exist
-- **AND** write completion script to `~/.zsh/completions/_openspec`
-- **AND** add `fpath=(~/.zsh/completions $fpath)` to `~/.zshrc` if not already present
-- **AND** add `autoload -Uz compinit && compinit` to `~/.zshrc` if not already present
-- **AND** display success message with instruction to run `exec zsh` or restart terminal
-
-#### Scenario: Auto-detecting Zsh for installation
-
-- **WHEN** user executes `openspec completion install` without specifying a shell
-- **THEN** detect current shell using shell detection logic
-- **AND** install completion if detected shell is Zsh
-- **AND** throw error if detected shell is not Zsh
-- **AND** display which shell was detected
-
-#### Scenario: Already installed
-
-- **WHEN** completion is already installed for the target shell
-- **THEN** display message indicating completion is already installed
-- **AND** offer to reinstall/update by overwriting existing files
-- **AND** exit with code 0
-
-### Requirement: Uninstallation
-
-The completion command SHALL remove installed completion scripts and configuration.
-
-#### Scenario: Uninstalling Oh My Zsh completion
-
-- **WHEN** user executes `openspec completion uninstall zsh`
-- **THEN** remove `~/.oh-my-zsh/custom/completions/_openspec` if Oh My Zsh is detected
-- **AND** remove `~/.zsh/completions/_openspec` if standard Zsh setup is detected
-- **AND** optionally remove fpath modifications from `~/.zshrc` (with confirmation)
-- **AND** display success message
-
-#### Scenario: Auto-detecting Zsh for uninstallation
-
-- **WHEN** user executes `openspec completion uninstall` without specifying a shell
-- **THEN** detect current shell and uninstall completion if shell is Zsh
-- **AND** throw error if detected shell is not Zsh
-
-#### Scenario: Not installed
-
-- **WHEN** attempting to uninstall completion that isn't installed
-- **THEN** display message indicating completion is not installed
-- **AND** exit with code 0
-
-### Requirement: Architecture Patterns
-
-The completion implementation SHALL follow clean architecture principles with TypeScript best practices.
-
-#### Scenario: Shell-specific generators
-
-- **WHEN** implementing completion generators
-- **THEN** create `ZshCompletionGenerator` class for Zsh
-- **AND** implement a common `CompletionGenerator` interface with methods:
-  - `generate(): string` - Returns complete shell script
-  - `getInstallPath(): string` - Returns target installation path
-  - `getConfigFile(): string` - Returns shell configuration file path
-- **AND** design interface to be extensible for future shells (bash, fish, powershell)
-
-#### Scenario: Dynamic completion providers
-
-- **WHEN** implementing dynamic completions
-- **THEN** create a `CompletionProvider` class that encapsulates project discovery logic
-- **AND** implement methods:
-  - `getChangeIds(): Promise<string[]>` - Discovers active change IDs
-  - `getSpecIds(): Promise<string[]>` - Discovers spec IDs
-  - `isOpenSpecProject(): boolean` - Checks if current directory is OpenSpec-enabled
-- **AND** implement caching with 2-second TTL using class properties
-
-#### Scenario: Command registry
-
-- **WHEN** defining completable commands
-- **THEN** create a centralized `CommandDefinition` type with properties:
-  - `name: string` - Command name
-  - `description: string` - Help text
-  - `flags: FlagDefinition[]` - Available flags
-  - `acceptsChangeId: boolean` - Whether command takes change ID argument
-  - `acceptsSpecId: boolean` - Whether command takes spec ID argument
-  - `subcommands?: CommandDefinition[]` - Nested subcommands
-- **AND** export a `COMMAND_REGISTRY` constant with all command definitions
-- **AND** generators consume this registry to ensure consistency
-
-#### Scenario: Type-safe shell detection
-
-- **WHEN** implementing shell detection
-- **THEN** define a `SupportedShell` type as literal type: `'zsh'`
-- **AND** implement `detectShell()` function that returns 'zsh' or throws error
-- **AND** design type to be extensible (e.g., future: `'bash' | 'zsh' | 'fish' | 'powershell'`)
-
-### Requirement: Error Handling
-
-The completion command SHALL provide clear error messages for common failure scenarios.
-
-#### Scenario: Unsupported shell
-
-- **WHEN** user requests completion for unsupported shell (bash, fish, powershell, etc.)
-- **THEN** display error message: "Shell '<name>' is not supported yet. Currently supported: zsh"
-- **AND** exit with code 1
-
-#### Scenario: Permission errors during installation
-
-- **WHEN** installation fails due to file permission issues
-- **THEN** display clear error message indicating permission problem
-- **AND** suggest using appropriate permissions or alternative installation method
-- **AND** exit with code 1
-
-#### Scenario: Missing shell configuration directory
-
-- **WHEN** expected shell configuration directory doesn't exist
-- **THEN** create the directory automatically (with user notification)
-- **AND** proceed with installation
-
-#### Scenario: Shell not detected
-
-- **WHEN** `openspec completion install` cannot detect current shell or detects non-Zsh shell
-- **THEN** display error: "Could not detect Zsh. Please specify explicitly: openspec completion install zsh"
-- **AND** exit with code 1
-
-### Requirement: Output Format
-
-The completion command SHALL provide machine-parseable and human-readable output.
-
-#### Scenario: Script generation output
-
-- **WHEN** generating completion script to stdout
-- **THEN** output only the completion script content (no extra messages)
-- **AND** allow redirection to files: `openspec completion zsh > /path/to/_openspec`
-
-#### Scenario: Installation success output
-
-- **WHEN** installation completes successfully
-- **THEN** display formatted success message with:
-  - Checkmark indicator
-  - Installation location
-  - Next steps (shell reload instructions)
-- **AND** use colors when terminal supports it (unless `--no-color` is set)
-
-#### Scenario: Verbose installation output
-
-- **WHEN** user provides `--verbose` flag during installation
-- **THEN** display detailed steps:
-  - Shell detection result
-  - Target file paths
-  - Configuration modifications
-  - File creation confirmations
-
-### Requirement: Testing Support
-
-The completion implementation SHALL be testable with unit and integration tests.
-
-#### Scenario: Mock shell environment
-
-- **WHEN** writing tests for shell detection
-- **THEN** allow overriding `$SHELL` environment variable
-- **AND** use dependency injection for file system operations
-
-#### Scenario: Generator output verification
-
-- **WHEN** testing completion generators
-- **THEN** verify generated scripts contain expected patterns
-- **AND** test that command registry is properly consumed
-- **AND** ensure dynamic completion placeholders are present
-
-#### Scenario: Installation simulation
-
-- **WHEN** testing installation logic
-- **THEN** use temporary test directories instead of actual home directories
-- **AND** verify file creation without modifying real shell configurations
-- **AND** test path resolution logic independently
-
-## Not in Scope
-
-The following shells are **architecturally documented but not implemented** in this proposal. They will be added in future proposals:
-
-- **Bash completion** - Will use bash-completion framework with `_init_completion`, `compgen`, and `COMPREPLY`
-- **Fish completion** - Will use Fish's declarative `complete -c` syntax
-- **PowerShell completion** - Will use `Register-ArgumentCompleter` with completion result objects
-
-The plugin-based architecture (CompletionGenerator interface, command registry, dynamic providers) is designed to make adding these shells straightforward in follow-up changes.
-
-## Why
-
-Shell completions are essential for professional CLI tools and significantly improve developer experience by reducing friction, errors, and cognitive load during daily workflows.

package/OpenSpec-main/openspec/changes/archive/2025-11-06-add-shell-completions/tasks.md

@@ -1,81 +0,0 @@
-# Implementation Tasks
-
-## Phase 1: Foundation & Architecture
-
-- [x] Create `src/utils/shell-detection.ts` with `SupportedShell` type and `detectShell()` function
-- [x] Create `src/core/completions/types.ts` with interfaces: `CompletionGenerator`, `CommandDefinition`, `FlagDefinition`
-- [x] Create `src/core/completions/command-registry.ts` with `COMMAND_REGISTRY` constant defining all OpenSpec commands, flags, and metadata
-- [x] Create `src/core/completions/completion-provider.ts` with `CompletionProvider` class for dynamic change/spec ID discovery with 2-second caching
-- [x] Write tests for shell detection (`test/utils/shell-detection.test.ts`)
-- [x] Write tests for completion provider (`test/core/completions/completion-provider.test.ts`)
-
-## Phase 2: Zsh Completion (Oh My Zsh Priority)
-
-- [x] Create `src/core/completions/generators/zsh-generator.ts` implementing `CompletionGenerator` interface
-- [x] Implement Zsh script generation using `_arguments` and `_describe` patterns
-- [x] Add dynamic completion logic for change/spec IDs using completion provider
-- [x] Test Zsh generator output (`test/core/completions/generators/zsh-generator.test.ts`)
-- [x] Create `src/core/completions/installers/zsh-installer.ts` with Oh My Zsh and standard Zsh support
-- [x] Implement Oh My Zsh detection (`$ZSH` env var or `~/.oh-my-zsh/` directory)
-- [x] Implement installation to `~/.oh-my-zsh/custom/completions/_openspec` for Oh My Zsh
-- [x] Implement fallback installation to `~/.zsh/completions/_openspec` with `fpath` updates
-- [x] Test Zsh installer logic with mocked file system (`test/core/completions/installers/zsh-installer.test.ts`)
-
-## Phase 3: CLI Command Implementation
-
-- [x] Create `src/commands/completion.ts` with `CompletionCommand` class
-- [x] Register `completion` command in `src/cli/index.ts` with subcommands: generate, install, uninstall
-- [x] Implement `generateSubcommand()` that outputs Zsh script to stdout
-- [x] Implement `installSubcommand(shell?: 'zsh')` with auto-detection for Zsh-only
-- [x] Implement `uninstallSubcommand(shell?: 'zsh')` for removing Zsh completions
-- [x] Add `--verbose` flag support for detailed installation output
-- [x] Add error handling with clear messages: "Shell '<name>' is not supported yet. Currently supported: zsh"
-- [x] Test completion command integration (`test/commands/completion.test.ts`)
-
-## Phase 4: Integration & Polish
-
-- [x] Create factory pattern in `src/core/completions/factory.ts` to instantiate Zsh generator/installer (extensible for future shells)
-- [x] Add `completion` command to command registry for self-referential completion
-- [x] Implement dynamic completion helper functions in Zsh generator (`_openspec_complete_changes`, `_openspec_complete_specs`, `_openspec_complete_items`)
-- [x] Add 'shell' positional type for completion command arguments
-- [x] Test completion generation with dynamic helpers
-- [x] Test completion install/uninstall flow
-- [x] Verify all tests pass (97 completion tests, 340 total tests)
-- [x] Implement auto-install via npm postinstall script
-- [x] Add safety checks (CI detection, opt-out flag)
-- [x] Handle Oh My Zsh vs standard Zsh installation paths
-- [x] Add test script for postinstall validation
-- [x] Document auto-install behavior and opt-out in README
-- [ ] Manually test Zsh completion in Oh My Zsh environment (install, test tab completion, uninstall)
-- [ ] Manually test Zsh completion in standard Zsh environment
-- [ ] Test dynamic change/spec ID completion in real OpenSpec projects
-- [ ] Verify completion cache behavior (2-second TTL)
-- [ ] Test behavior outside OpenSpec projects (should skip dynamic completions)
-- [x] Update `openspec --help` output to include completion command (automatically done via Commander)
-
-## Phase 5: Edge Cases & Error Handling
-
-- [ ] Test and handle permission errors during installation
-- [ ] Test and handle missing shell configuration directories (auto-create with notification)
-- [ ] Test "already installed" detection and reinstall flow
-- [ ] Test "not installed" detection during uninstall
-- [ ] Verify `--no-color` flag is respected in completion command output
-- [ ] Test shell detection failure scenarios with helpful error messages
-- [ ] Ensure graceful handling when `$SHELL` is unset or invalid
-- [ ] Test non-Zsh shells get clear "not supported yet" error messages
-- [ ] Test generator output can be redirected to files without corruption
-
-## Dependencies
-
-- Phase 2 depends on Phase 1 (foundation must exist first)
-- Phase 3 depends on Phase 2 (CLI needs Zsh generator working)
-- Phase 4 depends on Phase 3 (integration requires CLI + Zsh implementation)
-- Phase 5 depends on Phase 4 (edge case testing after core functionality works)
-
-## Future Work (Not in This Proposal)
-
-- **Bash completions** - Create bash-generator.ts and bash-installer.ts in follow-up proposal
-- **Fish completions** - Create fish-generator.ts and fish-installer.ts in follow-up proposal
-- **PowerShell completions** - Create powershell-generator.ts and powershell-installer.ts in follow-up proposal
-
-The architecture is designed to make adding these shells straightforward by implementing the `CompletionGenerator` interface.

package/OpenSpec-main/openspec/changes/archive/2025-12-20-add-global-config-dir/design.md

@@ -1,105 +0,0 @@
-## Context
-
-OpenSpec needs a standard location for user-level configuration that works across platforms and follows established conventions. This will serve as the foundation for settings, feature flags, and future artifacts like workflows or templates.
-
-## Goals / Non-Goals
-
-**Goals:**
-- Provide a single, well-defined location for global config
-- Follow XDG Base Directory Specification (widely adopted by CLI tools)
-- Support cross-platform usage (Unix, macOS, Windows)
-- Keep implementation minimal - just the foundation
-- Enable future expansion (cache, state, workflows)
-
-**Non-Goals:**
-- Project-local config override (not in scope)
-- Config file migration tooling
-- Config validation CLI commands
-- Multiple config profiles
-
-## Decisions
-
-### Path Resolution Strategy
-
-**Decision:** Use XDG Base Directory Specification with platform fallbacks.
-
-```
-Unix/macOS: $XDG_CONFIG_HOME/openspec/ or ~/.config/openspec/
-Windows:    %APPDATA%/openspec/
-```
-
-**Rationale:**
-- XDG is the de facto standard for CLI tools (used by gh, bat, ripgrep, etc.)
-- Environment variable override allows user customization
-- Windows uses its native convention (%APPDATA%) for better integration
-
-**Alternatives considered:**
-- `~/.openspec/` - Simple but clutters home directory
-- `~/Library/Application Support/` on macOS - Overkill for a CLI tool
-
-### Config File Format
-
-**Decision:** JSON (`config.json`)
-
-**Rationale:**
-- Native Node.js support (no dependencies)
-- Human-readable and editable
-- Type-safe with TypeScript
-- Matches project.md's "minimal dependencies" principle
-
-**Alternatives considered:**
-- YAML - Requires dependency, more error-prone to edit
-- TOML - Less common in Node.js ecosystem
-- Environment variables only - Too limited for structured settings
-
-### Config Schema
-
-**Decision:** Flat structure with typed fields, start minimal.
-
-```typescript
-interface GlobalConfig {
-  featureFlags?: Record<string, boolean>;
-}
-```
-
-**Rationale:**
-- `featureFlags` enables controlled rollout of new features
-- Optional fields with defaults avoid breaking changes
-- Flat structure is easy to understand and extend
-
-### Loading Strategy
-
-**Decision:** Read from disk on each call, no caching.
-
-```typescript
-export function getGlobalConfig(): GlobalConfig {
-  return loadConfigFromDisk();
-}
-```
-
-**Rationale:**
-- CLI commands are short-lived; caching adds complexity without benefit
-- Reading a small JSON file is ~1ms; negligible overhead
-- Always returns fresh data; no cache invalidation concerns
-- Simpler implementation
-
-### Directory Creation
-
-**Decision:** Create directory only when saving, not when reading.
-
-**Rationale:**
-- Don't create empty directories on read operations
-- Users who never save config won't have unnecessary directories
-- Aligns with principle of least surprise
-
-## Risks / Trade-offs
-
-| Risk | Mitigation |
-|------|------------|
-| Config file corruption | Return defaults on parse error, log warning |
-| Permissions issues | Check write permissions before save, clear error message |
-| Future schema changes | Use optional fields, add version field if needed later |
-
-## Open Questions
-
-None - this proposal is intentionally minimal.

package/OpenSpec-main/openspec/changes/archive/2025-12-20-add-global-config-dir/proposal.md

@@ -1,20 +0,0 @@
-## Why
-
-OpenSpec currently has no mechanism for user-level global settings or feature flags. As the CLI grows, we need a standard location to store user preferences, experimental features, and other configuration that persists across projects. Following XDG Base Directory Specification provides a well-understood, cross-platform approach.
-
-## What Changes
-
-- Add new `src/core/global-config.ts` module with:
-  - Path resolution following XDG Base Directory spec (`$XDG_CONFIG_HOME/openspec/` or fallback)
-  - Cross-platform support (Unix, macOS, Windows)
-  - Lazy config loading with sensible defaults
-  - TypeScript types for config shape
-- Export a global config directory path getter for future use (workflows, templates, cache)
-- Initial config schema supports 1-2 settings/feature flags only
-
-## Impact
-
-- Affected specs: New `global-config` capability (no existing specs modified)
-- Affected code:
-  - New `src/core/global-config.ts`
-  - Update `src/core/index.ts` to export new module

package/OpenSpec-main/openspec/changes/archive/2025-12-20-add-global-config-dir/specs/global-config/spec.md

@@ -1,76 +0,0 @@
-## ADDED Requirements
-
-### Requirement: Global Config Directory Path
-
-The system SHALL resolve the global configuration directory path following XDG Base Directory Specification with platform-specific fallbacks.
-
-#### Scenario: Unix/macOS with XDG_CONFIG_HOME set
-- **WHEN** `$XDG_CONFIG_HOME` environment variable is set to `/custom/config`
-- **THEN** `getGlobalConfigDir()` returns `/custom/config/openspec`
-
-#### Scenario: Unix/macOS without XDG_CONFIG_HOME
-- **WHEN** `$XDG_CONFIG_HOME` environment variable is not set
-- **AND** the platform is Unix or macOS
-- **THEN** `getGlobalConfigDir()` returns `~/.config/openspec` (expanded to absolute path)
-
-#### Scenario: Windows platform
-- **WHEN** the platform is Windows
-- **AND** `%APPDATA%` is set to `C:\Users\User\AppData\Roaming`
-- **THEN** `getGlobalConfigDir()` returns `C:\Users\User\AppData\Roaming\openspec`
-
-### Requirement: Global Config Loading
-
-The system SHALL load global configuration from the config directory with sensible defaults when the config file does not exist or cannot be parsed.
-
-#### Scenario: Config file exists and is valid
-- **WHEN** `config.json` exists in the global config directory
-- **AND** the file contains valid JSON matching the config schema
-- **THEN** `getGlobalConfig()` returns the parsed configuration
-
-#### Scenario: Config file does not exist
-- **WHEN** `config.json` does not exist in the global config directory
-- **THEN** `getGlobalConfig()` returns the default configuration
-- **AND** no directory or file is created
-
-#### Scenario: Config file is invalid JSON
-- **WHEN** `config.json` exists but contains invalid JSON
-- **THEN** `getGlobalConfig()` returns the default configuration
-- **AND** a warning is logged to stderr
-
-### Requirement: Global Config Saving
-
-The system SHALL save global configuration to the config directory, creating the directory if it does not exist.
-
-#### Scenario: Save config to new directory
-- **WHEN** `saveGlobalConfig(config)` is called
-- **AND** the global config directory does not exist
-- **THEN** the directory is created
-- **AND** `config.json` is written with the provided configuration
-
-#### Scenario: Save config to existing directory
-- **WHEN** `saveGlobalConfig(config)` is called
-- **AND** the global config directory already exists
-- **THEN** `config.json` is written (overwriting if exists)
-
-### Requirement: Default Configuration
-
-The system SHALL provide a default configuration that is used when no config file exists.
-
-#### Scenario: Default config structure
-- **WHEN** no config file exists
-- **THEN** the default configuration includes an empty `featureFlags` object
-
-### Requirement: Config Schema Evolution
-
-The system SHALL merge loaded configuration with default values to ensure new config fields are available even when loading older config files.
-
-#### Scenario: Config file missing new fields
-- **WHEN** `config.json` exists with `{ "featureFlags": {} }`
-- **AND** the current schema includes a new field `defaultAiTool`
-- **THEN** `getGlobalConfig()` returns `{ featureFlags: {}, defaultAiTool: <default> }`
-- **AND** the loaded values take precedence over defaults for fields that exist in both
-
-#### Scenario: Config file has extra unknown fields
-- **WHEN** `config.json` contains fields not in the current schema
-- **THEN** the unknown fields are preserved in the returned configuration
-- **AND** no error or warning is raised

package/OpenSpec-main/openspec/changes/archive/2025-12-20-add-global-config-dir/tasks.md

@@ -1,26 +0,0 @@
-## 1. Core Implementation
-
-- [x] 1.1 Create `src/core/global-config.ts` with path resolution
-  - Implement `getGlobalConfigDir()` following XDG spec
-  - Support `$XDG_CONFIG_HOME` environment variable override
-  - Platform-specific fallbacks (Unix: `~/.config/`, Windows: `%APPDATA%`)
-- [x] 1.2 Define TypeScript interfaces for config shape
-  - `GlobalConfig` interface with optional fields
-  - Start minimal: just `featureFlags?: Record<string, boolean>`
-- [x] 1.3 Implement config loading with defaults
-  - `getGlobalConfig()` - reads config.json if exists, merges with defaults
-  - No directory/file creation on read (lazy initialization)
-- [x] 1.4 Implement config saving
-  - `saveGlobalConfig(config)` - writes config.json, creates directory if needed
-
-## 2. Integration
-
-- [x] 2.1 Export new module from `src/core/index.ts`
-- [x] 2.2 Add constants for config file name and directory name
-
-## 3. Testing
-
-- [x] 3.1 Manual testing of path resolution on current platform
-- [x] 3.2 Test with/without `$XDG_CONFIG_HOME` set
-- [x] 3.3 Test config load when file doesn't exist (should return defaults)
-- [x] 3.4 Unit tests in `test/core/global-config.test.ts` (18 tests)