sauron-cli 1.3.0 → 1.4.0

package/OpenSpec-main/openspec/changes/add-change-stacking-awareness/proposal.md

@@ -1,93 +0,0 @@
-## Why
-
-Parallel changes often touch the same capabilities and `cli-init`/`cli-update` behavior, but today there is no machine-readable way to express sequencing, dependencies, or expected merge order.
-
-This creates three recurring problems:
-
-- teams cannot tell which change should land first
-- large changes are hard to split into safe mergeable slices
-- parallel work can accidentally reintroduce assumptions already removed by another change
-
-We need lightweight planning metadata and CLI guidance so contributors can safely stack plans on top of each other.
-
-## What Changes
-
-### 1. Add lightweight stack metadata for changes
-
-Extend change metadata to support sequencing and decomposition context, for example:
-
-- `dependsOn`: changes that must land first
-- `provides`: capability markers exposed by this change
-- `requires`: capability markers needed by this change
-- `touches`: capability/spec areas likely affected (advisory only; warning signal, not a hard dependency)
-- `parent`: optional parent change for split work
-
-Metadata is optional and backward compatible for existing changes.
-
-Ordering semantics:
-
-- `dependsOn` is the source of truth for execution/archive ordering
-- `provides`/`requires` are capability contracts for validation and planning visibility
-- `provides`/`requires` do not create implicit dependency edges; authors must still declare required ordering via `dependsOn`
-
-### 2. Add stack-aware validation
-
-Enhance change validation to detect planning issues early:
-
-- missing dependencies
-- dependency cycles
-- archive ordering violations (for example, attempting to archive a change before all `dependsOn` predecessors are archived)
-- unmatched capability markers (for example, `requires` marker with no provider in active history emits non-blocking warning)
-- overlap warnings when active changes touch the same capability
-
-Validation should fail only for deterministic blockers (for example cycles or missing required dependencies), and keep overlap checks as actionable warnings.
-
-### 3. Add sequencing visibility commands
-
-Add lightweight CLI support to inspect and execute plan order:
-
-- `openspec change graph` to show dependency DAG/order
-- `openspec change graph` validates for cycles first; when cycles are present it fails with the same deterministic cycle error as stack-aware validation
-- `openspec change next` to suggest unblocked changes ready to implement/archive
-
-### 4. Add split scaffolding for large changes
-
-Add helper workflow to decompose large proposals into stackable slices:
-
-- `openspec change split <change-id>` scaffolds child changes with `parent` + `dependsOn`
-- generates minimal proposal/tasks stubs for each child slice
-- converts the source change into a parent planning container (no duplicate child implementation tasks)
-- re-running split for an already-split source change returns a deterministic actionable error unless `--overwrite` (alias `--force`) is passed
-- `--overwrite` / `--force` fully regenerates managed child scaffold stubs and metadata links for the split, replacing prior scaffold content
-
-### 5. Document stack-first workflow
-
-Update docs to describe:
-
-- how to model dependencies and parent/child slices
-- when to split a large change
-- how to use graph/next validation signals during parallel development
-- migration guidance for `openspec/changes/IMPLEMENTATION_ORDER.md`:
-  - machine-readable change metadata becomes the normative dependency source
-  - `IMPLEMENTATION_ORDER.md` remains optional narrative context during transition
-
-## Capabilities
-
-### New Capabilities
-
-- `change-stacking-workflow`: Dependency-aware sequencing and split scaffolding for change planning
-
-### Modified Capabilities
-
-- `cli-change`: Adds graph/next/split planning commands and stack-aware validation messaging
-- `change-creation`: Supports parent/dependency metadata when creating or splitting changes
-- `openspec-conventions`: Defines optional stack metadata conventions for change proposals
-
-## Impact
-
-- `src/core/project-config.ts` and related parsing/validation utilities for change metadata loading
-- `src/core/config-schema.ts` (or dedicated change schema) for stack metadata validation
-- `src/commands/change.ts` and/or `src/core/list.ts` for graph/next/split command behavior
-- `src/core/validation/*` for dependency cycle and overlap checks
-- `docs/cli.md`, `docs/concepts.md`, and contributor guidance for stack-aware workflows
-- tests for metadata parsing, graph ordering, next-item suggestions, and split scaffolding

package/OpenSpec-main/openspec/changes/add-change-stacking-awareness/specs/change-creation/spec.md

@@ -1,15 +0,0 @@
-## ADDED Requirements
-
-### Requirement: Stack Metadata Scaffolding
-Change creation workflows SHALL support optional dependency metadata for new or split changes.
-
-#### Scenario: Create change with stack metadata
-- **WHEN** a change is created with stack metadata inputs
-- **THEN** creation SHALL persist metadata fields in change configuration
-- **AND** persisted metadata SHALL be validated against change metadata schema rules
-
-#### Scenario: Split-generated child metadata
-- **WHEN** child changes are generated from a split workflow
-- **THEN** each child SHALL include a `parent` link to the source change
-- **AND** SHALL include dependency metadata needed for deterministic sequencing
-

package/OpenSpec-main/openspec/changes/add-change-stacking-awareness/specs/change-stacking-workflow/spec.md

@@ -1,65 +0,0 @@
-## ADDED Requirements
-
-### Requirement: Stack Metadata Model
-The system SHALL support optional metadata on active changes to express sequencing and decomposition relationships.
-
-#### Scenario: Optional stack metadata is present
-- **WHEN** a change includes stack metadata fields
-- **THEN** the system SHALL parse and expose `dependsOn`, `provides`, `requires`, `touches`, and `parent`
-- **AND** validation SHALL enforce normalized field shapes and value types (`dependsOn`/`provides`/`requires`/`touches` as string arrays, `parent` as string when present)
-
-#### Scenario: Backward compatibility without stack metadata
-- **WHEN** a change does not include stack metadata
-- **THEN** existing behavior SHALL continue without migration steps
-- **AND** validation SHALL not fail solely because stack metadata is absent
-
-### Requirement: Change Dependency Graph
-The system SHALL provide dependency-aware ordering for active changes.
-
-#### Scenario: Build dependency order
-- **WHEN** users request stack planning output
-- **THEN** the system SHALL compute a dependency graph across active changes
-- **AND** SHALL return a deterministic topological order for unblocked changes
-
-#### Scenario: Tie-breaking within the same dependency depth
-- **WHEN** multiple unblocked changes share the same topological dependency depth
-- **THEN** ordering SHALL break ties lexicographically by change ID
-- **AND** repeated runs over the same input SHALL return the same order
-
-#### Scenario: Dependency cycle detection
-- **WHEN** active changes contain a dependency cycle
-- **THEN** validation SHALL fail with cycle details before archive or sequencing actions proceed
-- **AND** output SHALL include actionable guidance to break the cycle
-
-### Requirement: Capability marker and overlap semantics
-The system SHALL treat capability markers as validation contracts and `touches` as advisory overlap signals.
-
-#### Scenario: Required capability provided by an active change
-- **WHEN** change B declares `requires` marker `X`
-- **AND** active change A declares `provides` marker `X`
-- **THEN** validation SHALL require B to declare an explicit ordering edge in `dependsOn` to at least one active provider of `X`
-- **AND** validation SHALL fail if no explicit dependency is declared
-
-#### Scenario: Requires marker without active provider
-- **WHEN** a change declares a `requires` marker
-- **AND** no active change declares the corresponding `provides` marker
-- **THEN** validation SHALL NOT infer an implicit dependency edge
-- **AND** ordering SHALL continue to be determined solely by explicit `dependsOn` relationships
-
-#### Scenario: Requires marker satisfied by archived history
-- **WHEN** a change declares a `requires` marker
-- **AND** no active change provides that marker
-- **AND** at least one archived change in history provides that marker
-- **THEN** validation SHALL NOT warn solely about missing provider
-- **AND** SHALL continue to use explicit `dependsOn` for active ordering
-
-#### Scenario: Requires marker missing in full history
-- **WHEN** a change declares a `requires` marker
-- **AND** no active or archived change in history provides that marker
-- **THEN** validation SHALL emit a non-blocking warning naming the change and missing marker
-- **AND** SHALL NOT infer an implicit dependency edge
-
-#### Scenario: Overlap warning for shared touches
-- **WHEN** multiple active changes declare overlapping `touches` values
-- **THEN** validation SHALL emit a warning listing the overlapping changes and touched areas
-- **AND** validation SHALL NOT fail solely on overlap

package/OpenSpec-main/openspec/changes/add-change-stacking-awareness/specs/cli-change/spec.md

@@ -1,27 +0,0 @@
-## ADDED Requirements
-
-### Requirement: Stack Planning Commands
-The change CLI SHALL provide commands for dependency-aware sequencing of active changes.
-
-#### Scenario: Show dependency graph
-- **WHEN** a user runs `openspec change graph`
-- **THEN** the CLI SHALL display dependency relationships for active changes
-- **AND** SHALL include a deterministic recommended order for execution
-
-#### Scenario: Show next unblocked changes
-- **WHEN** a user runs `openspec change next`
-- **THEN** the CLI SHALL list changes that are not blocked by unresolved dependencies
-- **AND** SHALL use deterministic tie-breaking when multiple options are available
-
-### Requirement: Split Large Change Scaffolding
-The change CLI SHALL support scaffolding child slices from an existing large change.
-
-#### Scenario: Split command scaffolds child changes
-- **WHEN** a user runs `openspec change split <change-id>`
-- **THEN** the CLI SHALL create child change directories with proposal/tasks stubs
-- **AND** generated metadata SHALL include `parent` and dependency links back to the source change
-
-#### Scenario: Re-running split on an already-split change
-- **WHEN** a user runs `openspec change split <change-id>` for a parent whose generated child directories already exist
-- **THEN** the CLI SHALL fail with a deterministic, actionable error
-- **AND** SHALL NOT mutate existing child change content unless an explicit overwrite mode is requested

package/OpenSpec-main/openspec/changes/add-change-stacking-awareness/specs/openspec-conventions/spec.md

@@ -1,29 +0,0 @@
-## ADDED Requirements
-
-### Requirement: Stack-Aware Change Planning Conventions
-OpenSpec conventions SHALL define optional metadata fields for sequencing and decomposition across concurrent changes.
-
-#### Scenario: Declaring change dependencies
-- **WHEN** authors need to sequence related changes
-- **THEN** conventions SHALL define how to declare dependencies and provided/required capability markers
-- **AND** validation guidance SHALL distinguish hard blockers from soft overlap warnings
-
-#### Scenario: Dependency source of truth during migration
-- **WHEN** both stack metadata and `openspec/changes/IMPLEMENTATION_ORDER.md` are present
-- **THEN** conventions SHALL treat per-change stack metadata as the normative dependency source
-- **AND** `IMPLEMENTATION_ORDER.md` SHALL be treated as optional narrative guidance
-
-#### Scenario: Explicit ordering remains required for capability markers
-- **WHEN** authors use `provides` and `requires` markers to describe capability contracts
-- **THEN** conventions SHALL require explicit `dependsOn` edges for ordering relationships
-- **AND** conventions SHALL prohibit treating `requires` as an implicit dependency edge
-
-#### Scenario: Declaring advisory overlap via touches
-- **WHEN** a change may affect capability/spec areas shared by concurrent changes without requiring ordering
-- **THEN** conventions SHALL allow authors to declare `touches` with advisory area identifiers (for example capability IDs, spec area names, or paths)
-- **AND** tooling SHALL treat `touches` as informational only (no implicit dependency edge, non-blocking validation signal)
-
-#### Scenario: Declaring parent-child split structure
-- **WHEN** a large change is decomposed into smaller slices
-- **THEN** conventions SHALL define parent-child metadata and expected ordering semantics
-- **AND** docs SHALL describe when to split versus keep a single change

package/OpenSpec-main/openspec/changes/add-change-stacking-awareness/tasks.md

@@ -1,39 +0,0 @@
-## 1. Metadata Model
-
-- [ ] 1.1 Add optional stack metadata fields (`dependsOn`, `provides`, `requires`, `touches`, `parent`) to change metadata schema
-- [ ] 1.2 Keep metadata backward compatible for existing changes without new fields
-- [ ] 1.3 Add tests for valid/invalid metadata and schema evolution behavior
-
-## 2. Stack-Aware Validation
-
-- [ ] 2.1 Detect dependency cycles and fail validation with deterministic errors
-- [ ] 2.2 Detect missing `dependsOn` targets (referenced change ID does not exist) and detect changes transitively blocked by unresolved/cyclic dependency paths
-- [ ] 2.3 Add overlap warnings for active changes that touch the same capability/spec areas
-- [ ] 2.4 Emit advisory warnings for unmatched `requires` markers when no provider exists in active history
-- [ ] 2.5 Add tests for cycle, missing dependency, overlap warning, and unmatched `requires` cases
-
-## 3. Sequencing Commands
-
-- [ ] 3.1 Add `openspec change graph` to display dependency order for active changes
-- [ ] 3.2 Add `openspec change next` to suggest unblocked changes in recommended order
-- [ ] 3.3 Add tests for topological ordering and deterministic tie-breaking (lexicographic by change ID at equal depth)
-
-## 4. Split Scaffolding
-
-- [ ] 4.1 Add `openspec change split <change-id>` to scaffold child slices
-- [ ] 4.2 Ensure generated children include parent/dependency metadata and stub proposal/tasks files
-- [ ] 4.3 Convert the source change into a parent planning container as part of split (no duplicate child implementation tasks)
-- [ ] 4.4 Add tests for split output structure, source-change parent conversion, and deterministic re-split error behavior when overwrite mode is not requested
-- [ ] 4.5 Implement and test explicit overwrite mode for `openspec change split` (`--overwrite` / `--force`) for controlled re-splitting
-
-## 5. Documentation
-
-- [ ] 5.1 Document stack metadata and sequencing workflow in `docs/concepts.md`
-- [ ] 5.2 Document new change commands and usage examples in `docs/cli.md`
-- [ ] 5.3 Add guidance for breaking large changes into independently mergeable slices
-- [ ] 5.4 Document migration guidance for `openspec/changes/IMPLEMENTATION_ORDER.md` as optional narrative, not dependency source of truth
-
-## 6. Verification
-
-- [ ] 6.1 Run targeted tests for change parsing, validation, and CLI commands
-- [ ] 6.2 Run full test suite (`pnpm test`) and resolve regressions

package/OpenSpec-main/openspec/changes/add-global-install-scope/.openspec.yaml

@@ -1,2 +0,0 @@
-schema: spec-driven
-created: 2026-02-21

package/OpenSpec-main/openspec/changes/add-global-install-scope/design.md

@@ -1,161 +0,0 @@
-## Context
-
-OpenSpec today assumes project-local installation for most generated artifacts, with Codex command prompts as the main global exception. This mixed model works, but it is implicit and not user-configurable.
-
-The requested change is to support user-selectable install scope (`global` or `project`) for tool skills/commands, defaulting to `global` for new configurations while preserving legacy project-local behavior until explicit migration.
-
-## Goals / Non-Goals
-
-**Goals:**
-
-- Provide a single scope preference that users can set globally and override per run
-- Default new users to `global` scope
-- Make install path resolution deterministic and explicit across tools/surfaces
-- Preserve current behavior for users with older config files that do not yet define `installScope`
-- Avoid silent partial installs; surface effective scope decisions in output
-
-**Non-Goals:**
-
-- Implementing project-local config file support for global settings
-- Defining global install paths for tools where upstream location conventions are unknown
-- Changing workflow/profile semantics (`core`, `custom`, `delivery`) in this change
-
-## Decisions
-
-### 1. Scope model in global config
-
-Add install scope preference to global config:
-
-```ts
-type InstallScope = 'global' | 'project';
-
-interface GlobalConfig {
-  // existing fields...
-  installScope?: InstallScope;
-}
-```
-
-Defaults:
-
-- New configs SHOULD write `installScope: global` explicitly.
-- Existing configs without this field continue to load safely through schema evolution and SHALL resolve effective default as `project` until users explicitly set `installScope`.
-
-### 2. Explicit tool scope support metadata
-
-Extend `AI_TOOLS` metadata with optional scope support declarations per surface:
-
-```ts
-interface ToolInstallScopeSupport {
-  skills?: InstallScope[];
-  commands?: InstallScope[];
-}
-```
-
-Resolution rules:
-
-1. If scope support metadata is absent for a tool surface, treat it as project-only support for conservative backward compatibility.
-2. Try preferred scope.
-3. If unsupported, use alternate scope when supported.
-4. If neither is supported, fail with actionable error.
-
-This enables default-global behavior while remaining safe for tools that only support project-local paths.
-
-### 3. Scope-aware install target resolver
-
-Introduce shared resolver utilities to compute effective target paths for:
-
-- skills root directory
-- command output files
-
-Resolver input:
-
-- tool id
-- requested scope
-- project root
-- environment context (`CODEX_HOME`, etc.)
-
-Resolver output:
-
-- effective scope per surface
-- concrete target paths
-- optional fallback reasons for user-facing output
-
-Platform behavior:
-
-- Resolver outputs are OS-aware and normalized for the current platform.
-- Windows global targets MUST use Windows path conventions (for example `%USERPROFILE%\.codex\prompts` fallback for Codex when `CODEX_HOME` is unset), not POSIX defaults.
-
-### 4. Context-aware command adapter paths
-
-Update command generation contract so adapters receive install context for path resolution. This avoids hardcoded absolute/relative assumptions and centralizes scope decisions.
-
-Example direction:
-
-```ts
-getFilePath(commandId: string, context: InstallContext): string
-```
-
-### 5. CLI behavior and UX
-
-`init`:
-
-- Uses configured install scope by default; if absent in a legacy config, uses migration-safe effective default (`project`).
-- Supports explicit override flag (`--scope global|project`).
-- In interactive mode, displays chosen scope and any per-tool fallback decisions before writing files.
-
-`update`:
-
-- Applies current scope preference (or override); if absent in a legacy config, uses migration-safe effective default (`project`).
-- Performs drift detection using effective scoped paths and last-applied scope state.
-- Reports effective scope decisions in summary output.
-
-`config`:
-
-- `openspec config profile` interactive flow includes install scope selection.
-- `openspec config list` shows `installScope` with source annotation (`explicit`, `new-default`, or `legacy-default`).
-
-### 6. Cleanup safety during scope changes
-
-When scope changes:
-
-- Writes occur in the new effective targets.
-- Cleanup/removal is limited to OpenSpec-managed files for the relevant tool/workflow IDs.
-- Output explicitly states which scope locations were updated and which were cleaned.
-
-### 7. Scope drift state tracking
-
-Track last successful effective scope per tool/surface in project-managed state.
-
-Rules:
-
-1. Drift is detected when current resolved scope differs from last successful scope for a configured tool/surface.
-2. Scope support MUST be validated for all configured tools/surfaces before any write starts.
-3. Update writes to newly resolved targets first, verifies completeness, then removes managed files at previous targets.
-4. If new-target writes are partial or verification fails, command SHALL abort old-target cleanup and report actionable failure with incomplete/new and preserved/old paths.
-5. Cleanup failures do not rollback new writes; command returns actionable failure with leftover paths to resolve.
-
-### 8. Coordination with command-surface capability changes
-
-If `add-tool-command-surface-capabilities` lands, planning logic must evaluate scope resolution and delivery/capability behavior together (scope × delivery × command surface).
-
-## Risks / Trade-offs
-
-**Risk: Cross-project shared global state**
-Global installs are shared across projects. Updating global artifacts from one project affects all projects using that tool scope.
-→ Mitigation: make scope explicit in output; keep profile/delivery global and deterministic.
-
-**Risk: Tool-specific unknown global conventions**
-Not all tools document a stable global install location.
-→ Mitigation: use explicit scope support metadata; fallback or fail instead of guessing.
-
-**Risk: Adapter API churn**
-Changing adapter path contracts touches many files/tests.
-→ Mitigation: migrate in one pass with adapter contract tests and existing end-to-end generation tests.
-
-## Rollout Plan
-
-1. Add config schema + defaults for install scope.
-2. Add tool scope capability metadata and resolver utilities.
-3. Upgrade command adapter contract and generator path plumbing.
-4. Integrate scope-aware behavior into init/update.
-5. Add documentation and test coverage.

package/OpenSpec-main/openspec/changes/add-global-install-scope/proposal.md

@@ -1,101 +0,0 @@
-## Why
-
-OpenSpec installation paths are currently inconsistent:
-
-- Most skills and commands are written to project-local directories.
-- Codex commands are already global (`$CODEX_HOME/prompts` or `~/.codex/prompts`).
-- Users cannot choose a consistent install scope strategy across tools.
-
-This creates friction for users who prefer user-level setup and expect tool artifacts to be managed globally by default.
-
-## What Changes
-
-### 1. Add install scope preference with legacy-safe defaults
-
-Introduce a global install scope setting with two modes:
-
-- `global` (default for newly created configs)
-- `project`
-
-The setting is stored in global config and can be overridden per command run.
-For schema-evolved legacy configs where `installScope` is absent, effective default remains `project` until users opt in to global scope.
-
-### 2. Add scope-aware path resolution for skills and commands
-
-Refactor path resolution so both `init` and `update` compute install targets from:
-
-- selected scope preference (`global` or `project`)
-- tool capability metadata (which scopes each tool/surface supports)
-- runtime context (project root, home directories, env overrides)
-
-### 3. Add per-tool capability metadata for scope support
-
-Extend tool metadata to explicitly declare scope support per surface:
-
-- skills scope support
-- commands scope support
-
-When preferred scope is unsupported for a tool/surface, the system uses deterministic fallback rules and reports the effective scope in output.
-
-### 4. Make command generation context-aware
-
-Extend command adapter path resolution so adapters receive install context (scope + environment context), instead of only command ID. This removes special-case handling and allows consistent scope behavior across tools.
-
-### 5. Update init/update UX and behavior
-
-- `openspec init`:
-  - accepts scope override flag
-  - uses configured scope or migration-aware default (new configs default global; legacy configs preserve project until migration)
-  - applies scope-aware generation and cleanup planning
-- `openspec update`:
-  - applies current scope preference
-  - syncs artifacts in effective scope per tool/surface
-  - tracks last successful effective scope per tool/surface for deterministic scope-drift detection
-  - reports effective scope decisions clearly
-
-### 6. Extend config UX and docs
-
-- Add install scope control in `openspec config profile` interactive flow.
-- Extend `openspec config list` output with install scope source (`explicit`, `new-default`, `legacy-default`).
-- Add explicit migration guidance and prompt path so legacy users can opt into `global` scope.
-- Update supported tools and CLI docs to explain scope behavior and fallback rules.
-
-### 7. Coordinate with command-surface capability delivery rules
-
-`cli-init` and `cli-update` planning SHALL compose:
-
-- install scope (`global | project`)
-- delivery mode (`both | skills | commands`)
-- command surface capability (`adapter | skills-invocable | none`)
-
-This proposal remains focused on scope resolution, but implementation and test coverage should include mixed-tool cases to avoid regressions when combined with `add-tool-command-surface-capabilities`.
-
-## Capabilities
-
-### New Capabilities
-
-- `installation-scope`: Scope preference model and effective scope resolution for tool artifact installation.
-
-### Modified Capabilities
-
-- `global-config`: Persist install scope preference with schema evolution defaults.
-- `cli-config`: Configure and inspect install scope preferences.
-- `ai-tool-paths`: Add tool-level scope support metadata and path strategy.
-- `command-generation`: Scope-aware adapter path resolution via install context.
-- `cli-init`: Scope-aware initialization planning and output.
-- `cli-update`: Scope-aware update sync, drift detection, and output.
-- `migration`: Scope-aware migration scanning with install-scope-aware workflow lookup.
-
-## Impact
-
-- `src/core/global-config.ts` - new install scope fields and defaults
-- `src/core/config-schema.ts` - validation support for install scope config keys
-- `src/commands/config.ts` - interactive profile/config UX additions for install scope
-- `src/core/config.ts` - tool scope capability metadata
-- `src/core/available-tools.ts` and `src/core/shared/tool-detection.ts` - scope-aware configured detection
-- `src/core/command-generation/types.ts` and adapter implementations - context-aware file path resolution
-- `src/core/init.ts` - scope-aware generation/removal planning
-- `src/core/update.ts` - scope-aware sync/removal/drift planning
-- `src/core/migration.ts` - scope-aware workflow scanning support
-- `docs/supported-tools.md` and `docs/cli.md` - install scope behavior documentation
-- `test/core/init.test.ts`, `test/core/update.test.ts`, adapter tests, config tests - scope coverage

package/OpenSpec-main/openspec/changes/add-global-install-scope/specs/ai-tool-paths/spec.md

@@ -1,35 +0,0 @@
-## MODIFIED Requirements
-
-### Requirement: AIToolOption skillsDir field
-The `AIToolOption` interface SHALL include scope support metadata in addition to path metadata.
-
-#### Scenario: Scope support metadata present
-- **WHEN** a tool entry is defined in `AI_TOOLS`
-- **THEN** it MAY declare supported install scopes for skills and commands
-- **AND** this metadata SHALL be used for effective scope resolution
-
-#### Scenario: Scope support metadata absent
-- **WHEN** a tool entry in `AI_TOOLS` omits scope support metadata for a surface
-- **THEN** resolver behavior SHALL default that surface to project-only support
-- **AND** effective scope resolution SHALL apply normal preferred/fallback rules against that default
-
-### Requirement: Path configuration for supported tools
-Path metadata SHALL support both project and global install targets via resolver logic.
-
-#### Scenario: Project scope path
-- **WHEN** effective scope is `project` for skills
-- **THEN** `skillsDir` SHALL be treated as a tool-specific container path under project root
-- **AND** managed skill artifacts SHALL be written under `<projectRoot>/<skillsDir>/skills/`
-- **AND** tool definitions SHALL set `skillsDir` accordingly (for example `.openspec` -> `.openspec/skills/`)
-
-#### Scenario: Global scope path
-- **WHEN** effective scope is `global` for a supported tool/surface
-- **THEN** paths SHALL resolve to tool-specific global directories
-- **AND** environment overrides (for example `CODEX_HOME`) SHALL be respected where applicable
-
-#### Scenario: Windows global path resolution for Codex commands
-- **WHEN** effective scope is `global`
-- **AND** tool is Codex
-- **AND** platform is Windows
-- **THEN** command targets SHALL resolve to `%CODEX_HOME%\prompts` when `CODEX_HOME` is set
-- **AND** SHALL otherwise resolve to `%USERPROFILE%\.codex\prompts`

package/OpenSpec-main/openspec/changes/add-global-install-scope/specs/cli-config/spec.md

@@ -1,21 +0,0 @@
-## ADDED Requirements
-
-### Requirement: Install scope configuration via profile flow
-The config profile workflow SHALL allow users to configure install scope preference.
-
-#### Scenario: Interactive profile includes install scope
-- **WHEN** user runs `openspec config profile`
-- **THEN** the interactive flow SHALL include install scope selection with values `global` and `project`
-- **AND** the currently configured value SHALL be pre-selected
-
-#### Scenario: Save install scope
-- **WHEN** user confirms config profile changes
-- **THEN** selected install scope SHALL be saved to global config
-
-### Requirement: Install scope visibility in config output
-The config command SHALL display install scope preference in human-readable output.
-
-#### Scenario: Config list shows install scope
-- **WHEN** user runs `openspec config list`
-- **THEN** output SHALL include current install scope value
-- **AND** indicate whether value is default or explicit

package/OpenSpec-main/openspec/changes/add-global-install-scope/specs/cli-init/spec.md

@@ -1,28 +0,0 @@
-## ADDED Requirements
-
-### Requirement: Init install scope selection
-The init command SHALL support install scope selection for generated artifacts.
-
-#### Scenario: Scope defaults to global
-- **WHEN** user runs `openspec init` without explicit scope override
-- **THEN** init SHALL use global config install scope
-- **AND** if unset, SHALL resolve migration-aware default (`global` for newly created configs, `project` for legacy schema-evolved configs)
-
-#### Scenario: Scope override via flag
-- **WHEN** user runs `openspec init --scope project`
-- **THEN** init SHALL use `project` as preferred scope for that run
-- **AND** SHALL NOT mutate persisted global config unless user explicitly changes config
-
-### Requirement: Init uses effective scope resolution
-The init command SHALL resolve effective scope per tool surface before generating files.
-
-#### Scenario: Effective scope with fallback
-- **WHEN** selected tool/surface does not support preferred scope
-- **AND** supports alternate scope
-- **THEN** init SHALL generate files at alternate effective scope
-- **AND** SHALL display fallback note in summary
-
-#### Scenario: Unsupported scope selection
-- **WHEN** selected tool/surface supports neither preferred nor alternate scope
-- **THEN** init SHALL fail before writing files
-- **AND** SHALL provide clear error guidance

package/OpenSpec-main/openspec/changes/add-global-install-scope/specs/cli-update/spec.md

@@ -1,34 +0,0 @@
-## ADDED Requirements
-
-### Requirement: Update install scope selection
-The update command SHALL support install scope selection for sync operations.
-
-#### Scenario: Scope defaults to global config value
-- **WHEN** user runs `openspec update` without explicit scope override
-- **THEN** update SHALL use configured install scope
-- **AND** if unset, SHALL resolve migration-aware default (`global` for newly created configs, `project` for legacy schema-evolved configs)
-
-#### Scenario: Scope override via flag
-- **WHEN** user runs `openspec update --scope project`
-- **THEN** update SHALL use `project` as preferred scope for that run
-
-### Requirement: Scope-aware sync and drift detection
-The update command SHALL evaluate configured state and drift using effective scoped paths.
-
-#### Scenario: Scoped drift detection
-- **WHEN** update evaluates whether tools are up-to-date
-- **THEN** it SHALL inspect files at effective scoped targets for each tool/surface
-- **AND** SHALL compare current resolved scope against last successful effective scope for each tool/surface
-- **AND** SHALL treat a difference as sync-required drift
-
-#### Scenario: Scope fallback during update
-- **WHEN** preferred scope is unsupported for a configured tool/surface
-- **AND** alternate scope is supported
-- **THEN** update SHALL apply fallback scope resolution
-- **AND** SHALL report fallback in output
-
-#### Scenario: Unsupported scope during update
-- **WHEN** configured tool/surface supports neither preferred nor alternate scope
-- **THEN** scope support SHALL be validated for all configured tools/surfaces before any write
-- **AND** update SHALL fail without performing file writes when incompatibilities are detected
-- **AND** SHALL report incompatible tools with remediation steps