sauron-cli 1.3.0 → 1.4.1

package/OpenSpec-main/openspec/changes/archive/2025-12-23-extend-shell-completions/specs/cli-completion/spec.md

@@ -1,328 +0,0 @@
-# cli-completion Spec Delta
-
-## MODIFIED Requirements
-
-### Requirement: Native Shell Behavior Integration
-
-The completion system SHALL respect and integrate with each supported shell'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: Bash native completion
-
-- **WHEN** generating Bash completion scripts
-- **THEN** use Bash completion with `complete` builtin and `COMPREPLY` array
-- **AND** completions SHALL trigger on double TAB (standard Bash behavior)
-- **AND** display as space-separated list or column format
-- **AND** support both bash-completion v1 and v2 patterns
-
-#### Scenario: Fish native completion
-
-- **WHEN** generating Fish completion scripts
-- **THEN** use Fish's `complete` command with conditions
-- **AND** completions SHALL trigger on single TAB with auto-suggestion preview
-- **AND** display with Fish's native coloring and description alignment
-- **AND** leverage Fish's built-in caching automatically
-
-#### Scenario: PowerShell native completion
-
-- **WHEN** generating PowerShell completion scripts
-- **THEN** use `Register-ArgumentCompleter` with scriptblock
-- **AND** completions SHALL trigger on TAB with cycling behavior
-- **AND** display with PowerShell's native completion UI
-- **AND** support both Windows PowerShell 5.1 and PowerShell Core 7+
-
-#### Scenario: No custom UX patterns
-
-- **WHEN** implementing completion for any shell
-- **THEN** do NOT attempt to customize completion trigger behavior
-- **AND** do NOT override shell-specific navigation patterns
-- **AND** ensure completions feel native to experienced users of that 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 one of: `zsh`, `bash`, `fish`, `powershell`
-- **AND** throw an error if the shell is not supported
-
-#### Scenario: Detecting Bash from environment
-
-- **WHEN** `$SHELL` contains `bash` in the path
-- **THEN** detect shell as `bash`
-- **AND** proceed with bash-specific completion logic
-
-#### Scenario: Detecting Fish from environment
-
-- **WHEN** `$SHELL` contains `fish` in the path
-- **THEN** detect shell as `fish`
-- **AND** proceed with fish-specific completion logic
-
-#### Scenario: Detecting PowerShell from environment
-
-- **WHEN** `$PSModulePath` environment variable is present
-- **THEN** detect shell as `powershell`
-- **AND** proceed with PowerShell-specific completion logic
-
-#### Scenario: Unsupported shell detection
-
-- **WHEN** shell path indicates an unsupported shell
-- **THEN** throw error: "Shell '<name>' is not supported. Supported shells: zsh, bash, fish, powershell"
-
-### Requirement: Completion Generation
-
-The completion command SHALL generate completion scripts for all supported shells on demand.
-
-#### Scenario: Generating Zsh completion
-
-- **WHEN** user executes `openspec completion generate 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
-
-#### Scenario: Generating Bash completion
-
-- **WHEN** user executes `openspec completion generate bash`
-- **THEN** output a complete Bash completion script to stdout
-- **AND** include completions for all commands and subcommands
-- **AND** use `complete -F` with custom completion function
-- **AND** populate `COMPREPLY` with appropriate suggestions
-- **AND** support dynamic completion for change and spec IDs via `openspec __complete`
-
-#### Scenario: Generating Fish completion
-
-- **WHEN** user executes `openspec completion generate fish`
-- **THEN** output a complete Fish completion script to stdout
-- **AND** use `complete -c openspec` with conditions
-- **AND** include command-specific completions with `--condition` predicates
-- **AND** support dynamic completion for change and spec IDs via `openspec __complete`
-- **AND** include descriptions for each completion option
-
-#### Scenario: Generating PowerShell completion
-
-- **WHEN** user executes `openspec completion generate powershell`
-- **THEN** output a complete PowerShell completion script to stdout
-- **AND** use `Register-ArgumentCompleter -CommandName openspec`
-- **AND** implement scriptblock that handles command context
-- **AND** support dynamic completion for change and spec IDs via `openspec __complete`
-- **AND** return `[System.Management.Automation.CompletionResult]` objects
-
-### Requirement: Installation Automation
-
-The completion command SHALL automatically install completion scripts into shell configuration files for all supported shells.
-
-#### 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: Installing for Bash with bash-completion
-
-- **WHEN** user executes `openspec completion install bash`
-- **THEN** detect if bash-completion is installed by checking for `/usr/share/bash-completion` or `/etc/bash_completion.d`
-- **AND** if bash-completion is available, write to `/etc/bash_completion.d/openspec` (with sudo) or `~/.local/share/bash-completion/completions/openspec`
-- **AND** if bash-completion is not available, write to `~/.bash_completion.d/openspec` and source it from `~/.bashrc`
-- **AND** add sourcing line to `~/.bashrc` using marker-based updates if needed
-- **AND** display success message with instruction to run `exec bash` or restart terminal
-
-#### Scenario: Installing for Fish
-
-- **WHEN** user executes `openspec completion install fish`
-- **THEN** create Fish completions directory at `~/.config/fish/completions/` if it doesn't exist
-- **AND** write completion script to `~/.config/fish/completions/openspec.fish`
-- **AND** Fish automatically loads completions from this directory (no config file modification needed)
-- **AND** display success message indicating completions are immediately available
-
-#### Scenario: Installing for PowerShell
-
-- **WHEN** user executes `openspec completion install powershell`
-- **THEN** detect PowerShell profile location via `$PROFILE` environment variable or default paths
-- **AND** create profile directory if it doesn't exist
-- **AND** add completion script import to profile using marker-based updates
-- **AND** write completion script to PowerShell modules directory or alongside profile
-- **AND** display success message with instruction to restart PowerShell or run `. $PROFILE`
-
-#### Scenario: Auto-detecting shell for installation
-
-- **WHEN** user executes `openspec completion install` without specifying a shell
-- **THEN** detect current shell using shell detection logic
-- **AND** install completion for the detected shell (zsh, bash, fish, or powershell)
-- **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 for all supported shells.
-
-#### Scenario: Uninstalling Zsh completion
-
-- **WHEN** user executes `openspec completion uninstall zsh`
-- **THEN** prompt for confirmation before proceeding (unless `--yes` flag provided)
-- **AND** if user declines, cancel uninstall and display "Uninstall cancelled."
-- **AND** if user confirms, 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** remove fpath modifications from `~/.zshrc` using marker-based removal
-- **AND** display success message
-
-#### Scenario: Uninstalling Bash completion
-
-- **WHEN** user executes `openspec completion uninstall bash`
-- **THEN** prompt for confirmation (unless `--yes` flag provided)
-- **AND** if user confirms, remove completion file from bash-completion directory or `~/.bash_completion.d/`
-- **AND** remove sourcing lines from `~/.bashrc` using marker-based removal
-- **AND** display success message
-
-#### Scenario: Uninstalling Fish completion
-
-- **WHEN** user executes `openspec completion uninstall fish`
-- **THEN** prompt for confirmation (unless `--yes` flag provided)
-- **AND** if user confirms, remove `~/.config/fish/completions/openspec.fish`
-- **AND** display success message (no config file modification needed)
-
-#### Scenario: Uninstalling PowerShell completion
-
-- **WHEN** user executes `openspec completion uninstall powershell`
-- **THEN** prompt for confirmation (unless `--yes` flag provided)
-- **AND** if user confirms, remove completion import from PowerShell profile using marker-based removal
-- **AND** remove completion script file
-- **AND** display success message
-
-#### Scenario: Auto-detecting shell for uninstallation
-
-- **WHEN** user executes `openspec completion uninstall` without specifying a shell
-- **THEN** detect current shell and uninstall completion for that shell
-
-#### Scenario: Not installed
-
-- **WHEN** attempting to uninstall completion that isn't installed
-- **THEN** display error message indicating completion is not installed
-- **AND** exit with code 1
-
-### Requirement: Architecture Patterns
-
-The completion implementation SHALL follow clean architecture principles with TypeScript best practices, supporting multiple shells through a plugin-based pattern.
-
-#### Scenario: Shell-specific generators
-
-- **WHEN** implementing completion generators
-- **THEN** create generator classes for each shell: `ZshGenerator`, `BashGenerator`, `FishGenerator`, `PowerShellGenerator`
-- **AND** implement a common `CompletionGenerator` interface with method:
-  - `generate(commands: CommandDefinition[]): string` - Returns complete shell script
-- **AND** each generator handles shell-specific syntax, escaping, and patterns
-- **AND** all generators consume the same `CommandDefinition[]` from the command registry
-
-#### Scenario: Shell-specific installers
-
-- **WHEN** implementing completion installers
-- **THEN** create installer classes for each shell: `ZshInstaller`, `BashInstaller`, `FishInstaller`, `PowerShellInstaller`
-- **AND** implement a common `CompletionInstaller` interface with methods:
-  - `install(script: string): Promise<InstallationResult>` - Installs completion script
-  - `uninstall(): Promise<{ success: boolean; message: string }>` - Removes completion
-- **AND** each installer handles shell-specific paths, config files, and installation patterns
-
-#### Scenario: Factory pattern for shell selection
-
-- **WHEN** selecting shell-specific implementation
-- **THEN** use `CompletionFactory` class with static methods:
-  - `createGenerator(shell: SupportedShell): CompletionGenerator`
-  - `createInstaller(shell: SupportedShell): CompletionInstaller`
-- **AND** factory uses switch statements with TypeScript exhaustiveness checking
-- **AND** adding new shell requires updating `SupportedShell` type and factory cases
-
-#### 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
-  - `acceptsPositional: boolean` - Whether command takes positional arguments
-  - `positionalType: string` - Type of positional (change-id, spec-id, path, shell)
-  - `subcommands?: CommandDefinition[]` - Nested subcommands
-- **AND** export a `COMMAND_REGISTRY` constant with all command definitions
-- **AND** all generators consume this registry to ensure consistency across shells
-
-#### Scenario: Type-safe shell detection
-
-- **WHEN** implementing shell detection
-- **THEN** define a `SupportedShell` type as literal type: `'zsh' | 'bash' | 'fish' | 'powershell'`
-- **AND** implement `detectShell()` function in `src/utils/shell-detection.ts`
-- **AND** return detected shell or throw error with supported shells list
-
-### Requirement: Testing Support
-
-The completion implementation SHALL be testable with unit and integration tests for all supported shells.
-
-#### Scenario: Mock shell environment
-
-- **WHEN** writing tests for shell detection
-- **THEN** allow overriding `$SHELL` and `$PSModulePath` environment variables
-- **AND** use dependency injection for file system operations
-- **AND** test detection for all four shells independently
-
-#### Scenario: Generator output verification
-
-- **WHEN** testing completion generators
-- **THEN** create test suite for each shell generator (zsh, bash, fish, powershell)
-- **AND** verify generated scripts contain expected patterns for that shell
-- **AND** test that command registry is properly consumed
-- **AND** ensure dynamic completion placeholders are present
-- **AND** verify shell-specific syntax and escaping
-
-#### Scenario: Installer simulation
-
-- **WHEN** testing installation logic
-- **THEN** create test suite for each shell installer
-- **AND** use temporary test directories instead of actual home directories
-- **AND** verify file creation without modifying real shell configurations
-- **AND** test path resolution logic independently
-- **AND** mock file system operations to avoid side effects
-
-#### Scenario: Cross-shell consistency
-
-- **WHEN** testing completion behavior
-- **THEN** verify all shells support the same commands and flags
-- **AND** verify dynamic completions work consistently across shells
-- **AND** ensure error messages are consistent across shells

package/OpenSpec-main/openspec/changes/archive/2025-12-23-extend-shell-completions/tasks.md

@@ -1,49 +0,0 @@
-# Implementation Tasks
-
-## Phase 1: Foundation and Bash Support
-
-- [x] Update `SupportedShell` type in `src/utils/shell-detection.ts` to include `'bash' | 'fish' | 'powershell'`
-- [x] Extend shell detection logic to recognize bash, fish, and PowerShell from environment variables
-- [x] Create `src/core/completions/generators/bash-generator.ts` implementing `CompletionGenerator` interface
-- [x] Create `src/core/completions/installers/bash-installer.ts` implementing `CompletionInstaller` interface
-- [x] Update `CompletionFactory.createGenerator()` to support bash
-- [x] Update `CompletionFactory.createInstaller()` to support bash
-- [x] Create test file `test/core/completions/generators/bash-generator.test.ts` mirroring zsh test structure
-- [x] Create test file `test/core/completions/installers/bash-installer.test.ts` mirroring zsh test structure
-- [x] Verify bash completions work manually: `openspec completion install bash && exec bash`
-
-## Phase 2: Fish Support
-
-- [x] Create `src/core/completions/generators/fish-generator.ts` implementing `CompletionGenerator` interface
-- [x] Create `src/core/completions/installers/fish-installer.ts` implementing `CompletionInstaller` interface
-- [x] Update `CompletionFactory.createGenerator()` to support fish
-- [x] Update `CompletionFactory.createInstaller()` to support fish
-- [x] Create test file `test/core/completions/generators/fish-generator.test.ts`
-- [x] Create test file `test/core/completions/installers/fish-installer.test.ts`
-- [x] Verify fish completions work manually: `openspec completion install fish`
-
-## Phase 3: PowerShell Support
-
-- [x] Create `src/core/completions/generators/powershell-generator.ts` implementing `CompletionGenerator` interface
-- [x] Create `src/core/completions/installers/powershell-installer.ts` implementing `CompletionInstaller` interface
-- [x] Update `CompletionFactory.createGenerator()` to support powershell
-- [x] Update `CompletionFactory.createInstaller()` to support powershell
-- [x] Create test file `test/core/completions/generators/powershell-generator.test.ts`
-- [x] Create test file `test/core/completions/installers/powershell-installer.test.ts`
-- [x] Verify PowerShell completions work manually on Windows or macOS PowerShell
-
-## Phase 4: Documentation and Testing
-
-- [x] Update `CLAUDE.md` or relevant documentation to mention all four supported shells
-- [x] Add cross-shell consistency test verifying all shells support same commands
-- [x] Run `pnpm test` to ensure all tests pass
-- [x] Run `pnpm run build` to verify TypeScript compilation
-- [x] Test all shells on different platforms (Linux for bash/fish/zsh, Windows/macOS for PowerShell)
-
-## Phase 5: Validation and Cleanup
-
-- [x] Run `openspec validate extend-shell-completions --strict` and resolve all issues
-- [x] Update error messages to list all four supported shells
-- [x] Verify `openspec completion --help` documentation is current
-- [x] Test auto-detection works for all shells
-- [x] Ensure uninstall works cleanly for all shells

package/OpenSpec-main/openspec/changes/archive/2025-12-24-add-artifact-graph-core/design.md

@@ -1,197 +0,0 @@
-## Context
-
-This implements "Slice 1: What's Ready?" from the artifact POC analysis. The core insight is using the filesystem as a database - artifact completion is detected by file existence, making the system stateless and version-control friendly.
-
-This module will coexist with the current OpenSpec system as a parallel capability, potentially enabling future migration or integration.
-
-## Goals / Non-Goals
-
-**Goals:**
-- Pure dependency graph logic with no side effects
-- Stateless state detection (rescan filesystem each query)
-- Support glob patterns for multi-file artifacts (e.g., `specs/*.md`)
-- Load artifact definitions from YAML schemas
-- Calculate topological build order
-- Determine "ready" artifacts based on dependency completion
-
-**Non-Goals:**
-- CLI commands (Slice 4)
-- Multi-change management (Slice 2)
-- Template resolution and enrichment (Slice 3)
-- Agent integration or Claude commands
-- Replacing existing OpenSpec functionality
-
-## Decisions
-
-### Decision: Filesystem as Database
-Use file existence for state detection rather than a separate state file.
-
-**Rationale:**
-- Stateless - no state corruption possible
-- Git-friendly - state derived from committed files
-- Simple - no sync issues between state file and actual files
-
-**Alternatives considered:**
-- JSON/SQLite state file: More complex, sync issues, not git-friendly
-- Git metadata: Too coupled to git, complex implementation
-
-### Decision: Kahn's Algorithm for Topological Sort
-Use Kahn's algorithm for computing build order.
-
-**Rationale:**
-- Well-understood, O(V+E) complexity
-- Naturally detects cycles during execution
-- Produces a stable, deterministic order
-
-### Decision: Glob Pattern Support
-Support glob patterns like `specs/*.md` in artifact `generates` field.
-
-**Rationale:**
-- Allows multiple files to satisfy a single artifact requirement
-- Common pattern for spec directories with multiple files
-- Uses standard glob syntax
-
-### Decision: Immutable Completed Set
-Represent completion state as an immutable Set of completed artifact IDs.
-
-**Rationale:**
-- Functional style, easier to reason about
-- State derived fresh each query, no mutation needed
-- Clear separation between graph structure and runtime state
-- Filesystem can only detect binary existence (complete vs not complete)
-
-**Note:** `inProgress` and `failed` states are deferred to future slices. They would require external state tracking (e.g., a status file) since file existence alone cannot distinguish these states.
-
-### Decision: Zod for Schema Validation
-Use Zod for validating YAML schema structure and deriving TypeScript types.
-
-**Rationale:**
-- Already a project dependency (v4.0.17) used in `src/core/schemas/`
-- Type inference via `z.infer<>` - single source of truth for types
-- Runtime validation with detailed error messages
-- Consistent with existing project patterns (`base.schema.ts`, `config-schema.ts`)
-
-**Alternatives considered:**
-- Manual validation: More code, error-prone, no type inference
-- JSON Schema: Would require additional dependency, less TypeScript integration
-- io-ts: Not already in project, steeper learning curve
-
-### Decision: Two-Level Schema Resolution
-Schemas resolve from global user data directory, falling back to package built-ins.
-
-**Resolution order:**
-1. `${XDG_DATA_HOME:-~/.local/share}/openspec/schemas/<name>.yaml` - Global user override
-2. `<package>/schemas/<name>.yaml` - Built-in defaults
-
-**Rationale:**
-- Follows XDG Base Directory Specification (schemas are data, not config)
-- Mirrors existing `getGlobalConfigDir()` pattern in `src/core/global-paths.ts`
-- Built-ins baked into package, never auto-copied
-- Users customize by creating files in global data dir
-- Simple - no project-level overrides (can add later if needed)
-
-**XDG compliance:**
-- Uses `XDG_DATA_HOME` env var when set (all platforms)
-- Unix/macOS fallback: `~/.local/share/openspec/`
-- Windows fallback: `%LOCALAPPDATA%/openspec/`
-
-**Alternatives considered:**
-- Project-level overrides: Added complexity, not needed initially
-- Auto-copy to user space: Creates drift, harder to update defaults
-- Config directory (`XDG_CONFIG_HOME`): Schemas are workflow definitions (data), not user preferences (config)
-
-### Decision: Template Field Parsed But Not Resolved
-The `template` field is required in schema YAML for completeness, but template resolution is deferred to Slice 3.
-
-**Rationale:**
-- Slice 1 focuses on "What's Ready?" - dependency and completion queries only
-- Template paths are validated syntactically (non-empty string) but not resolved
-- Keeps Slice 1 focused and independently testable
-
-### Decision: Cycle Error Format
-Cycle errors list all artifact IDs in the cycle for easy debugging.
-
-**Format:** `"Cyclic dependency detected: A → B → C → A"`
-
-**Rationale:**
-- Shows the full cycle path, not just that a cycle exists
-- Actionable - developer can see exactly which artifacts to fix
-- Consistent with Kahn's algorithm which naturally identifies cycle participants
-
-## Data Structures
-
-**Zod Schemas (source of truth):**
-
-```typescript
-import { z } from 'zod';
-
-// Artifact definition schema
-export const ArtifactSchema = z.object({
-  id: z.string().min(1, 'Artifact ID is required'),
-  generates: z.string().min(1),      // e.g., "proposal.md" or "specs/*.md"
-  description: z.string(),
-  template: z.string(),              // path to template file
-  requires: z.array(z.string()).default([]),
-});
-
-// Full schema YAML structure
-export const SchemaYamlSchema = z.object({
-  name: z.string().min(1, 'Schema name is required'),
-  version: z.number().int().positive(),
-  description: z.string().optional(),
-  artifacts: z.array(ArtifactSchema).min(1, 'At least one artifact required'),
-});
-
-// Derived TypeScript types
-export type Artifact = z.infer<typeof ArtifactSchema>;
-export type SchemaYaml = z.infer<typeof SchemaYamlSchema>;
-```
-
-**Runtime State (not Zod - internal only):**
-
-```typescript
-// Slice 1: Simple completion tracking via filesystem
-type CompletedSet = Set<string>;
-
-// Return type for blocked query
-interface BlockedArtifacts {
-  [artifactId: string]: string[];  // artifact → list of unmet dependencies
-}
-
-interface ArtifactGraphResult {
-  completed: string[];
-  ready: string[];
-  blocked: BlockedArtifacts;
-  buildOrder: string[];
-}
-```
-
-## File Structure
-
-```
-src/core/artifact-graph/
-├── index.ts           # Public exports
-├── types.ts           # Zod schemas and type definitions
-├── graph.ts           # ArtifactGraph class
-├── state.ts           # State detection logic
-├── resolver.ts        # Schema resolution (global → built-in)
-└── schemas/           # Built-in schema definitions (package level)
-    ├── spec-driven.yaml   # Default: proposal → specs → design → tasks
-    └── tdd.yaml           # Alternative: tests → implementation → docs
-```
-
-**Schema Resolution Paths:**
-- Global user override: `${XDG_DATA_HOME:-~/.local/share}/openspec/schemas/<name>.yaml`
-- Package built-in: `src/core/artifact-graph/schemas/<name>.yaml` (bundled with package)
-
-## Risks / Trade-offs
-
-| Risk | Mitigation |
-|------|------------|
-| Glob pattern edge cases | Use well-tested glob library (fast-glob or similar) |
-| Cycle detection | Kahn's algorithm naturally fails on cycles; provide clear error |
-| Schema evolution | Version field in schema, validate on load |
-
-## Open Questions
-
-None - all questions resolved in Decisions section.

package/OpenSpec-main/openspec/changes/archive/2025-12-24-add-artifact-graph-core/proposal.md

@@ -1,18 +0,0 @@
-## Why
-
-The current OpenSpec system relies on conventions and AI inference for artifact ordering. A formal artifact graph with dependency awareness would enable deterministic "what's ready?" queries, making the system more predictable and enabling future features like automated pipeline execution.
-
-## What Changes
-
-- Add `ArtifactGraph` class to model artifacts as a DAG with dependency relationships
-- Add `ArtifactState` type to track completion status (completed, in_progress, failed)
-- Add filesystem-based state detection using file existence and glob patterns
-- Add schema YAML parser to load artifact definitions
-- Implement topological sort (Kahn's algorithm) for build order calculation
-- Add `getNextArtifacts()` to find artifacts ready for creation
-
-## Impact
-
-- Affected specs: New `artifact-graph` capability
-- Affected code: `src/core/artifact-graph/` (new directory)
-- No changes to existing functionality - this is a parallel module