sauron-cli 1.3.0 → 1.4.0

package/OpenSpec-main/openspec/changes/simplify-skill-installation/proposal.md

@@ -1,202 +0,0 @@
-## Why
-
-Users have complained that there are too many skills/commands (currently 10) and new users feel overwhelmed. We want to simplify the default experience while preserving power-user capabilities and backwards compatibility.
-
-The goal: **get users to an "aha moment" in under a minute**.
-
-```text
-0:00  $ openspec init
-      ✓ Done. Run /opsx:propose "your idea"
-
-0:15  /opsx:propose "add user authentication"
-
-0:45  Agent creates proposal.md, design.md, tasks.md
-      "Whoa, it planned the whole thing for me" ← AHA
-
-1:00  /opsx:apply
-```
-
-Additionally, users have different preferences for how workflows are delivered (skills vs commands vs both), but this should be a power-user configuration, not something new users think about.
-
-## What Changes
-
-### 1. Smart Defaults Init
-
-Init auto-detects tools and asks for confirmation:
-
-```text
-$ openspec init
-
-Detected tools:
-  [x] Claude Code
-  [x] Cursor
-  [ ] Windsurf
-
-Press Enter to confirm, or Space to toggle
-
-Setting up OpenSpec...
-✓ Done
-
-Start your first change:
-  /opsx:propose "add dark mode"
-```
-
-**No prompts for profile or delivery.** Defaults are:
-- Profile: core
-- Delivery: both
-
-Power users can customize via `openspec config profile`.
-
-### 2. Tool Detection Behavior
-
-Init scans for existing tool directories (`.claude/`, `.cursor/`, etc.):
-- **Tools detected (interactive):** Shows pre-selected checkboxes, user confirms or adjusts
-- **No tools detected (interactive):** Prompts for full tool selection
-- **Non-interactive (CI):** Uses detected tools automatically, fails if none detected
-
-### 3. Fix Tool Selection UX
-
-Current behavior confuses users:
-- Tab to confirm (unexpected)
-
-New behavior:
-- **Space** to toggle selection
-- **Enter** to confirm
-
-### 4. Introduce Profiles
-
-Profiles define which workflows to install:
-
-- **core** (default): `propose`, `explore`, `apply`, `archive` (4 workflows)
-- **custom**: User-selected subset of workflows
-
-The `propose` workflow is new - it combines `new` + `ff` into a single command that creates a change and generates all artifacts.
-
-### 5. Improved Propose UX
-
-`/opsx:propose` should naturally onboard users by explaining what it's doing:
-
-```text
-I'll create a change with 3 artifacts:
-- proposal.md (what & why)
-- design.md (how)
-- tasks.md (implementation steps)
-
-When ready to implement, run /opsx:apply
-```
-
-This teaches as it goes - no separate onboarding needed for most users.
-
-### 6. Introduce Delivery Config
-
-Delivery controls how workflows are installed:
-
-- **both** (default): Skills and commands
-- **skills**: Skills only
-- **commands**: Commands only
-
-Stored in existing global config (`~/.config/openspec/config.json`). Not prompted during init.
-
-### 7. New CLI Commands
-
-```shell
-# Profile configuration (interactive picker for delivery + workflows)
-openspec config profile          # interactive picker
-openspec config profile core     # preset shortcut (core workflows, preserves delivery)
-```
-
-The interactive picker allows users to configure both delivery method and workflow selection in one place:
-
-```
-$ openspec config profile
-
-Delivery: [skills] [commands] [both]
-                              ^^^^^^
-
-Workflows: (space to toggle, enter to save)
-[x] propose
-[x] explore
-[x] apply
-[x] archive
-[ ] new
-[ ] ff
-[ ] continue
-[ ] verify
-[ ] sync
-[ ] bulk-archive
-[ ] onboard
-```
-
-### 8. Backwards Compatibility & Migration
-
-**Existing users keep their current setup.** When `openspec update` runs on a project with existing workflows and no `profile` in global config, it performs a one-time migration:
-
-1. Scans installed workflow files across all tool directories in the project
-2. Writes `profile: "custom"`, `delivery: "both"`, `workflows: [<detected>]` to global config
-3. Refreshes templates but does NOT add or remove any workflows
-4. Displays: "Migrated: custom profile with N existing workflows"
-
-After migration, subsequent `init` and `update` commands respect the migrated config.
-
-**Key behaviors:**
-- Existing users' workflows are preserved exactly as-is (no `propose` added automatically)
-- Both `init` (re-init) and `update` trigger migration on existing projects if no profile is set
-- `openspec init` on a **new** project (no existing workflows) uses global config, defaulting to `core`
-- `init` with a custom profile applies the configured workflows directly (no profile confirmation prompt)
-- `init` validates `--profile` values (`core` or `custom`) and errors on invalid input
-- Migration message mentions `propose` and suggests `openspec config profile core` to opt in
-- After migration, users can opt into `core` profile via `openspec config profile core`
-- Workflow templates conditionally reference only installed workflows in "next steps" guidance
-- Delivery changes are applied: switching to `skills` removes command files, switching to `commands` removes skill files
-- Re-running `init` applies delivery cleanup on existing projects (removes files that no longer match delivery)
-- `update` treats profile/delivery drift as update-required even when template versions are already current
-- `update` treats command-only installs as configured tools
-- All workflows remain available via custom profile
-
-## Capabilities
-
-### New Capabilities
-
-- `profiles`: Workflow profiles (core, custom), delivery preferences, global config storage, interactive picker
-- `propose-workflow`: Combined workflow that creates change + generates all artifacts
-
-### Modified Capabilities
-
-- `cli-init`: Smart defaults with tool auto-detection, profile-based skill/command generation
-- `cli-update`: Profile support, delivery changes, one-time migration for existing users
-
-## Impact
-
-### New Files
-- `src/core/templates/workflows/propose.ts` - New propose workflow template
-- `src/core/profiles.ts` - Profile definitions and logic
-- `src/core/available-tools.ts` - Detect what AI tools user has from directories
-
-### Modified Files
-- `src/core/init.ts` - Smart defaults, auto-detection, tool confirmation
-- `src/core/config.ts` - Add profile and delivery types
-- `src/core/global-config.ts` - Add profile, delivery, workflows fields to schema
-- `src/core/shared/skill-generation.ts` - Filter by profile, respect delivery
-- `src/core/shared/tool-detection.ts` - Update SKILL_NAMES and COMMAND_IDS to include propose
-- `src/commands/config.ts` - Add `profile` subcommand with interactive picker
-- `src/core/update.ts` - Add profile/delivery support, file deletion for delivery changes
-- `src/prompts/searchable-multi-select.ts` - Fix keybindings (space/enter)
-
-### Global Config Schema Extension
-```json
-// ~/.config/openspec/config.json (extends existing)
-{
-  "telemetry": { ... },          // existing
-  "featureFlags": { ... },       // existing
-  "profile": "core",             // NEW: core | custom
-  "delivery": "both",            // NEW: both | skills | commands
-  "workflows": ["propose", ...]  // NEW: only if profile: custom
-}
-```
-
-## Profiles Reference
-
-| Profile | Workflows | Description |
-|---------|-----------|-------------|
-| core | propose, explore, apply, archive | Streamlined flow for most users (default) |
-| custom | user-defined | Pick exactly what you need via `openspec config profile` |

package/OpenSpec-main/openspec/changes/simplify-skill-installation/specs/cli-init/spec.md

@@ -1,199 +0,0 @@
-## Purpose
-
-The init command SHALL provide a streamlined setup experience that auto-detects tools and uses smart defaults, getting users to their first change in under a minute.
-
-## MODIFIED Requirements
-
-### Requirement: Skill generation per tool (REPLACES fixed 9-skill mandate)
-The init command SHALL generate skills based on the active profile, not a fixed set.
-
-#### Scenario: Core profile skill generation
-- **WHEN** user runs init with profile `core`
-- **THEN** the system SHALL generate skills for workflows in CORE_WORKFLOWS constant: propose, explore, apply, archive
-- **THEN** the system SHALL NOT generate skills for workflows outside the profile
-
-#### Scenario: Custom profile skill generation
-- **WHEN** user runs init with profile `custom`
-- **THEN** the system SHALL generate skills only for workflows listed in config `workflows` array
-
-#### Scenario: Propose workflow included in skill templates
-- **WHEN** generating skills
-- **THEN** the system SHALL include the `propose` workflow as an available skill template
-
-### Requirement: Command generation per tool (REPLACES fixed 9-command mandate)
-The init command SHALL generate commands based on profile AND delivery settings.
-
-#### Scenario: Skills-only delivery
-- **WHEN** delivery is set to `skills`
-- **THEN** the system SHALL NOT generate any command files
-
-#### Scenario: Commands-only delivery
-- **WHEN** delivery is set to `commands`
-- **THEN** the system SHALL NOT generate any skill files
-
-#### Scenario: Both delivery
-- **WHEN** delivery is set to `both`
-- **THEN** the system SHALL generate both skill and command files for profile workflows
-
-#### Scenario: Propose workflow included in command templates
-- **WHEN** generating commands
-- **THEN** the system SHALL include the `propose` workflow as an available command template
-
-### Requirement: Tool auto-detection
-The init command SHALL detect installed AI tools by scanning for their configuration directories in the project root.
-
-#### Scenario: Detection from directories
-- **WHEN** scanning for tools
-- **THEN** the system SHALL check for directories matching each supported AI tool's configuration directory (e.g., `.claude/`, `.cursor/`, `.windsurf/`)
-- **THEN** all tools with a matching directory SHALL be returned as detected
-
-#### Scenario: Detection covers all supported tools
-- **WHEN** scanning for tools
-- **THEN** the system SHALL check for all tools defined in the supported tools configuration that have a configuration directory
-
-#### Scenario: No tools detected
-- **WHEN** no tool configuration directories exist in project root
-- **THEN** the system SHALL return an empty list of detected tools
-
-### Requirement: Smart defaults init flow
-The init command SHALL work with sensible defaults and tool confirmation, minimizing required user input.
-
-#### Scenario: Init with detected tools (interactive)
-- **WHEN** user runs `openspec init` interactively and tool directories are detected
-- **THEN** the system SHALL show detected tools pre-selected
-- **THEN** the system SHALL ask for confirmation (not full selection)
-- **THEN** the system SHALL use default profile (`core`) and delivery (`both`)
-
-#### Scenario: Init with no detected tools (interactive)
-- **WHEN** user runs `openspec init` interactively and no tool directories are detected
-- **THEN** the system SHALL prompt for tool selection
-- **THEN** the system SHALL use default profile (`core`) and delivery (`both`)
-
-#### Scenario: Non-interactive with detected tools
-- **WHEN** user runs `openspec init` non-interactively (e.g., in CI)
-- **AND** tool directories are detected
-- **THEN** the system SHALL use detected tools automatically without prompting
-- **THEN** the system SHALL use default profile and delivery
-
-#### Scenario: Non-interactive with no detected tools
-- **WHEN** user runs `openspec init` non-interactively
-- **AND** no tool directories are detected
-- **THEN** the system SHALL fail with exit code 1
-- **AND** display message to use `--tools` flag
-
-#### Scenario: Non-interactive with explicit tools
-- **WHEN** user runs `openspec init --tools claude`
-- **THEN** the system SHALL use specified tools
-- **THEN** the system SHALL NOT prompt for any input
-
-#### Scenario: Interactive with explicit tools
-- **WHEN** user runs `openspec init --tools claude` interactively
-- **THEN** the system SHALL use specified tools (ignoring auto-detection)
-- **THEN** the system SHALL NOT prompt for tool selection
-- **THEN** the system SHALL proceed with default profile and delivery
-
-#### Scenario: Init success message (propose installed)
-- **WHEN** init completes successfully
-- **AND** `propose` is in the active profile
-- **THEN** the system SHALL display a tool-appropriate success message
-- **THEN** for tools using colon syntax (Claude Code): "Start your first change: /opsx:propose \"your idea\""
-- **THEN** for tools using hyphen syntax (Cursor, others): "Start your first change: /opsx-propose \"your idea\""
-
-#### Scenario: Init success message (propose not installed, new installed)
-- **WHEN** init completes successfully
-- **AND** `propose` is NOT in the active profile
-- **AND** `new` is in the active profile
-- **THEN** for tools using colon syntax: "Start your first change: /opsx:new \"your idea\""
-- **THEN** for tools using hyphen syntax: "Start your first change: /opsx-new \"your idea\""
-
-#### Scenario: Init success message (neither propose nor new)
-- **WHEN** init completes successfully
-- **AND** neither `propose` nor `new` is in the active profile
-- **THEN** the system SHALL display: "Done. Run 'openspec config profile' to configure your workflows."
-
-### Requirement: Init performs migration on existing projects
-The init command SHALL perform one-time migration when re-initializing an existing project, using the same shared migration logic as the update command.
-
-#### Scenario: Re-init on existing project (no profile set)
-- **WHEN** user runs `openspec init` on a project with existing workflow files
-- **AND** global config does not contain a `profile` field
-- **THEN** the system SHALL perform one-time migration before proceeding (see `specs/cli-update/spec.md`)
-- **THEN** the system SHALL proceed with init using the migrated config
-
-#### Scenario: Init on new project (no existing workflows)
-- **WHEN** user runs `openspec init` on a project with no existing workflow files
-- **AND** global config does not contain a `profile` field
-- **THEN** the system SHALL NOT perform migration
-- **THEN** the system SHALL use `core` profile defaults
-
-### Requirement: Init respects global config
-The init command SHALL read and apply settings from global config.
-
-#### Scenario: User has profile preference
-- **WHEN** global config contains `profile: "custom"` with custom workflows
-- **THEN** init SHALL install custom profile workflows
-
-#### Scenario: User has delivery preference
-- **WHEN** global config contains `delivery: "skills"`
-- **THEN** init SHALL install only skill files, not commands
-
-#### Scenario: Override via flags
-- **WHEN** user runs `openspec init --profile core`
-- **THEN** the system SHALL use the flag value instead of config value
-- **THEN** the system SHALL NOT update the global config
-
-#### Scenario: Invalid profile override
-- **WHEN** user runs `openspec init --profile <invalid>`
-- **AND** `<invalid>` is not one of `core` or `custom`
-- **THEN** the system SHALL exit with code 1
-- **THEN** the system SHALL display a validation error listing allowed profile values
-
-### Requirement: Init applies configured profile without confirmation
-The init command SHALL apply the resolved profile (`--profile` override or global config) directly without prompting for confirmation.
-
-#### Scenario: Init with custom profile (interactive)
-- **WHEN** user runs `openspec init` interactively
-- **AND** global config specifies `profile: "custom"` with workflows
-- **THEN** the system SHALL proceed directly using the custom profile workflows
-- **AND** the system SHALL NOT show a profile confirmation prompt
-
-#### Scenario: Non-interactive init with custom profile
-- **WHEN** user runs `openspec init` non-interactively
-- **AND** global config specifies a custom profile
-- **THEN** the system SHALL proceed without confirmation
-
-#### Scenario: Init with core profile
-- **WHEN** user runs `openspec init` interactively
-- **AND** profile is `core` (default)
-- **THEN** the system SHALL proceed directly without a profile confirmation prompt
-
-### Requirement: Init preserves existing workflows
-The init command SHALL NOT remove workflows that are already installed, but SHALL respect delivery setting.
-
-#### Scenario: Existing custom installation
-- **WHEN** user has custom profile with extra workflows and runs `openspec init` with core profile
-- **THEN** the system SHALL NOT remove extra workflows
-- **THEN** the system SHALL regenerate core workflow files, overwriting existing content with latest templates
-
-#### Scenario: Init with different delivery setting
-- **WHEN** user runs `openspec init` on existing project
-- **AND** delivery setting differs from what's installed (e.g., was `both`, now `skills`)
-- **THEN** the system SHALL generate files matching current delivery setting
-- **THEN** the system SHALL delete files that don't match delivery (e.g., commands removed if `skills`)
-- **THEN** this applies to all workflows, including extras not in profile
-
-#### Scenario: Re-init applies delivery cleanup even when templates are current
-- **WHEN** user runs `openspec init` on an existing project
-- **AND** existing files are already on current template versions
-- **AND** delivery changed since the previous init
-- **THEN** the system SHALL still remove files that no longer match delivery
-- **THEN** for example, switching from `both` to `skills` SHALL remove generated command files
-
-### Requirement: Init tool confirmation UX
-The init command SHALL show detected tools and ask for confirmation.
-
-#### Scenario: Confirmation prompt
-- **WHEN** tools are detected in interactive mode
-- **THEN** the system SHALL display: "Detected: Claude Code, Cursor"
-- **THEN** the system SHALL show pre-selected checkboxes for confirmation
-- **THEN** the system SHALL allow user to deselect unwanted tools

package/OpenSpec-main/openspec/changes/simplify-skill-installation/specs/cli-update/spec.md

@@ -1,177 +0,0 @@
-## Purpose
-
-The update command SHALL apply global configuration changes to existing projects, syncing profile and delivery preferences without requiring full re-initialization.
-
-## MODIFIED Requirements
-
-### Requirement: Update respects global profile config
-The update command SHALL read global config and apply profile settings to the project.
-
-#### Scenario: Update adds missing workflows from config
-- **WHEN** user runs `openspec update`
-- **AND** global config specifies workflows not currently installed in the project
-- **THEN** the system SHALL generate skill/command files for missing workflows
-- **THEN** the system SHALL display: "Added: <workflow-names>"
-
-#### Scenario: Update refreshes existing workflows
-- **WHEN** user runs `openspec update`
-- **AND** workflows are already installed in the project
-- **THEN** the system SHALL refresh those workflow files with latest templates
-- **THEN** the system SHALL display: "Updated: <workflow-names>"
-
-#### Scenario: Update with no changes needed
-- **WHEN** user runs `openspec update`
-- **AND** installed workflows match global config
-- **AND** all templates are current
-- **AND** delivery setting matches installed files
-- **THEN** the system SHALL display: "Already up to date."
-
-#### Scenario: Profile or delivery drift with current templates
-- **WHEN** user runs `openspec update`
-- **AND** workflow templates are current for the installed skills
-- **AND** project files do not match current profile and/or delivery config
-- **THEN** the system SHALL treat this as an update-required state (not "Already up to date.")
-- **THEN** the system SHALL add/remove files to match current profile and delivery settings
-
-#### Scenario: Update summary output
-- **WHEN** update completes with changes
-- **THEN** the system SHALL display a summary:
-  - "Added: propose, explore" (new workflows installed)
-  - "Updated: apply, archive" (existing workflows refreshed)
-  - "Removed: 4 command files" (if delivery changed)
-- **THEN** the system SHALL list affected tools: "Tools: Claude Code, Cursor"
-
-### Requirement: Update respects delivery setting
-The update command SHALL add or remove files based on the delivery setting.
-
-#### Scenario: Delivery changed to skills-only
-- **WHEN** user runs `openspec update`
-- **AND** global config specifies `delivery: skills`
-- **AND** project has command files installed
-- **THEN** the system SHALL delete command files for workflows in the profile
-- **THEN** the system SHALL generate/update skill files only
-- **THEN** the system SHALL display: "Removed: <count> command files (delivery: skills)"
-
-#### Scenario: Delivery changed to commands-only
-- **WHEN** user runs `openspec update`
-- **AND** global config specifies `delivery: commands`
-- **AND** project has skill files installed
-- **THEN** the system SHALL delete skill directories for workflows in the profile
-- **THEN** the system SHALL generate/update command files only
-- **THEN** the system SHALL display: "Removed: <count> skill directories (delivery: commands)"
-
-#### Scenario: Delivery is both
-- **WHEN** user runs `openspec update`
-- **AND** global config specifies `delivery: both`
-- **THEN** the system SHALL generate/update both skill and command files
-
-### Requirement: Update detects configured tools from skills or commands
-The update command SHALL treat a tool as configured if it has either generated skill files or generated command files.
-
-#### Scenario: Commands-only installation
-- **WHEN** user runs `openspec update`
-- **AND** a tool has generated OpenSpec command files
-- **AND** that tool has no OpenSpec skill files (commands-only delivery)
-- **THEN** the tool SHALL still be treated as configured
-- **THEN** the system SHALL apply profile and delivery sync for that tool
-
-### Requirement: One-time migration for existing users
-The update command SHALL detect existing users (no `profile` in global config + existing workflows) and migrate them to `custom` profile before applying updates.
-
-#### Scenario: First update after upgrade (existing user)
-- **WHEN** user runs `openspec update`
-- **AND** global config does not contain a `profile` field
-- **AND** project has existing workflow files installed
-- **THEN** the system SHALL scan installed workflows across all tool directories in the project
-- **THEN** the system SHALL only match workflow names present in `ALL_WORKFLOWS` constant (ignoring user-created custom skills)
-- **THEN** the system SHALL take the union of detected workflow names across all tools
-- **THEN** the system SHALL write to global config: `profile: "custom"`, `delivery: "both"`, `workflows: [<detected>]`
-- **THEN** the system SHALL display: "Migrated: custom profile with <count> workflows (<workflow-names>)"
-- **THEN** the system SHALL display: "New in this version: /opsx:propose (combines new + ff). Try 'openspec config profile core' for the streamlined 4-workflow experience."
-- **THEN** the system SHALL proceed with normal update logic (using the migrated config)
-- **THEN** the result SHALL be template refresh only (no workflows added or removed)
-
-#### Scenario: Migration with partial workflows (user manually removed some)
-- **WHEN** user runs `openspec update`
-- **AND** global config does not contain a `profile` field
-- **AND** project has fewer than the original 10 workflows installed
-- **THEN** the system SHALL migrate with only the workflows that are actually present
-- **THEN** the migrated `workflows` array SHALL reflect the user's current state, not the original set
-
-#### Scenario: Migration with multiple tools having different workflow sets
-- **WHEN** user runs `openspec update`
-- **AND** project has multiple tools configured (e.g., Claude Code, Cursor)
-- **AND** different tools have different workflows installed
-- **THEN** the system SHALL take the union of all detected workflows across all tools
-- **THEN** the migrated `workflows` array SHALL include any workflow that exists in at least one tool
-
-#### Scenario: No migration needed (profile already set)
-- **WHEN** user runs `openspec update`
-- **AND** global config already contains a `profile` field
-- **THEN** the system SHALL NOT perform migration
-- **THEN** the system SHALL proceed with normal update logic using existing config
-
-#### Scenario: No migration needed (no existing workflows)
-- **WHEN** user runs `openspec update`
-- **AND** global config does not contain a `profile` field
-- **AND** project has no existing workflow files
-- **THEN** the system SHALL NOT perform migration
-- **THEN** the system SHALL use `core` profile defaults
-
-#### Scenario: Migration is idempotent
-- **WHEN** user runs `openspec update` multiple times
-- **THEN** migration SHALL only occur on the first run (when `profile` field is absent)
-- **THEN** subsequent runs SHALL use the existing global config without re-scanning
-
-#### Scenario: Non-interactive migration
-- **WHEN** user runs `openspec update` non-interactively (e.g., in CI)
-- **AND** migration is triggered
-- **THEN** the system SHALL perform migration without prompting
-- **THEN** the system SHALL display the migration summary to stdout
-
-### Requirement: Update detects new tool directories
-The update command SHALL notify the user if new AI tool directories are detected that aren't currently configured.
-
-#### Scenario: New tool directory detected
-- **WHEN** user runs `openspec update`
-- **AND** a new tool directory is detected (e.g., `.windsurf/` exists but Windsurf is not configured)
-- **THEN** the system SHALL display: "Detected new tool: Windsurf. Run 'openspec init' to add it."
-- **THEN** the system SHALL NOT automatically add the new tool
-- **THEN** the system SHALL proceed with update for currently configured tools only
-
-#### Scenario: Multiple new tool directories detected
-- **WHEN** user runs `openspec update`
-- **AND** multiple new tool directories are detected (e.g., `.github/` and `.windsurf/` exist but neither tool is configured)
-- **THEN** the system SHALL display one consolidated message listing all detected tools, for example: "Detected new tools: GitHub Copilot, Windsurf. Run 'openspec init' to add them."
-- **THEN** the system SHALL NOT automatically add any new tools
-- **THEN** the system SHALL proceed with update for currently configured tools only
-
-#### Scenario: No new tool directories
-- **WHEN** user runs `openspec update`
-- **AND** no new tool directories are detected
-- **THEN** the system SHALL NOT display any tool detection message
-
-### Requirement: Update requires an OpenSpec project
-The update command SHALL only run inside an initialized OpenSpec project.
-
-#### Scenario: Update outside a project
-- **WHEN** user runs `openspec update`
-- **AND** no `openspec/` directory exists in the current working directory
-- **THEN** the system SHALL display: "No OpenSpec project found. Run 'openspec init' to set up."
-- **THEN** the system SHALL exit with code 1
-
-### Requirement: Extra workflows synchronized to active profile
-The update command SHALL remove workflow files that are no longer selected in the current profile.
-
-#### Scenario: Deselected workflows from previous profile
-- **WHEN** user runs `openspec update`
-- **AND** project has workflows not in current profile (e.g., user switched from custom to core or deselected workflows via `openspec config profile`)
-- **THEN** the system SHALL delete skill and command workflow files for deselected workflows (respecting active delivery mode)
-- **THEN** the system SHALL keep only workflows currently selected in profile
-
-#### Scenario: Delivery change with extra workflows
-- **WHEN** user runs `openspec update`
-- **AND** delivery changed (e.g., `both` → `skills`)
-- **AND** project has extra workflows not in current profile
-- **THEN** the system SHALL delete files for extra workflows that match the removed delivery type
-- **THEN** for example: if switching to `skills`, all command files are deleted (including for extra workflows)