sauron-cli 1.3.0 → 1.4.0

package/OpenSpec-main/openspec/changes/fix-opencode-commands-directory/specs/command-generation/spec.md

@@ -1,63 +0,0 @@
-## MODIFIED Requirements
-
-### Requirement: ToolCommandAdapter interface
-
-The system SHALL define a `ToolCommandAdapter` interface for per-tool formatting.
-
-#### Scenario: Adapter interface structure
-
-- **WHEN** implementing a tool adapter
-- **THEN** `ToolCommandAdapter` SHALL require:
-  - `toolId`: string identifier matching `AIToolOption.value`
-  - `getFilePath(commandId: string)`: returns file path for command (relative from project root, or absolute for global-scoped tools like Codex)
-  - `formatFile(content: CommandContent)`: returns complete file content with frontmatter
-
-#### Scenario: Claude adapter formatting
-
-- **WHEN** formatting a command for Claude Code
-- **THEN** the adapter SHALL output YAML frontmatter with `name`, `description`, `category`, `tags` fields
-- **AND** file path SHALL follow pattern `.claude/commands/opsx/<id>.md`
-
-#### Scenario: Cursor adapter formatting
-
-- **WHEN** formatting a command for Cursor
-- **THEN** the adapter SHALL output YAML frontmatter with `name` as `/opsx-<id>`, `id`, `category`, `description` fields
-- **AND** file path SHALL follow pattern `.cursor/commands/opsx-<id>.md`
-
-#### Scenario: Windsurf adapter formatting
-
-- **WHEN** formatting a command for Windsurf
-- **THEN** the adapter SHALL output YAML frontmatter with `name`, `description`, `category`, `tags` fields
-- **AND** file path SHALL follow pattern `.windsurf/workflows/opsx-<id>.md`
-
-#### Scenario: OpenCode adapter formatting
-
-- **WHEN** formatting a command for OpenCode
-- **THEN** the adapter SHALL output YAML frontmatter with `description` field
-- **AND** file path SHALL follow pattern `.opencode/commands/opsx-<id>.md` using `path.join('.opencode', 'commands', ...)` for cross-platform compatibility
-- **AND** the adapter SHALL transform colon-based command references (`/opsx:name`) to hyphen-based (`/opsx-name`) in the body
-
-## ADDED Requirements
-
-### Requirement: Legacy cleanup for renamed OpenCode command directory
-
-The legacy cleanup module SHALL detect and remove old OpenCode command files from the previous singular `.opencode/command/` directory path.
-
-#### Scenario: Detect old singular-path OpenCode command files
-
-- **WHEN** running legacy artifact detection on a project with files matching `.opencode/command/opsx-*.md` or `.opencode/command/openspec-*.md`
-- **THEN** the system SHALL include those files in the legacy slash command files list via `LEGACY_SLASH_COMMAND_PATHS`
-- **AND** `LegacySlashCommandPattern.pattern` SHALL accept `string | string[]` to support multiple glob patterns per tool
-
-#### Scenario: Clean up old OpenCode command files on init
-
-- **WHEN** a user runs `openspec init` in a project with old `.opencode/command/` artifacts
-- **THEN** the system SHALL remove the old files
-- **AND** generate new command files at `.opencode/commands/`
-
-#### Scenario: Auto-cleanup legacy artifacts in non-interactive mode
-
-- **WHEN** a user runs `openspec init` in non-interactive mode (e.g., CI) and legacy artifacts are detected
-- **THEN** the system SHALL auto-cleanup legacy artifacts without requiring `--force`
-- **AND** legacy slash command files (100% OpenSpec-managed) SHALL be removed
-- **AND** config file cleanup SHALL only remove OpenSpec markers (never delete user files)

package/OpenSpec-main/openspec/changes/fix-opencode-commands-directory/tasks.md

@@ -1,19 +0,0 @@
-## 1. Adapter Fix
-
-- [x] 1.1 Update `src/core/command-generation/adapters/opencode.ts`: change `path.join('.opencode', 'command', ...)` to `path.join('.opencode', 'commands', ...)` and update the JSDoc comment
-
-## 2. Legacy Cleanup
-
-- [x] 2.1 Update `src/core/legacy-cleanup.ts`: update the `'opencode'` entry in `LEGACY_SLASH_COMMAND_PATHS` to detect both `opsx-*.md` and `openspec-*.md` patterns at `.opencode/command/` for backward compatibility
-
-## 3. Documentation
-
-- [x] 3.1 Update `docs/supported-tools.md`: change OpenCode command path from `.opencode/command/opsx-<id>.md` to `.opencode/commands/opsx-<id>.md`
-
-## 4. Tests
-
-- [x] 4.1 Update `test/core/command-generation/adapters.test.ts`: change the OpenCode file path assertion from `path.join('.opencode', 'command', 'opsx-explore.md')` to `path.join('.opencode', 'commands', 'opsx-explore.md')`
-
-## 5. Changeset
-
-- [x] 5.1 Create a changeset file (`.changeset/fix-opencode-commands-directory.md`) with a patch bump describing the path fix

package/OpenSpec-main/openspec/changes/graceful-status-no-changes/.openspec.yaml

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

package/OpenSpec-main/openspec/changes/graceful-status-no-changes/design.md

@@ -1,38 +0,0 @@
-## Context
-
-`statusCommand` in `src/commands/workflow/status.ts` calls `validateChangeExists()` from `shared.ts` as its first operation. When no `--change` option is provided and no change directories exist, `validateChangeExists` throws: `No changes found. Create one with: openspec new change <name>`. This error propagates up as a fatal CLI error (non-zero exit code).
-
-This is correct behavior for commands like `apply` and `show` that require a change to operate on. However, `status` is an informational command — it should report the current state, even when that state is "no changes exist."
-
-The error surfaces during onboarding (issue #714) when AI agents call `openspec status` before any change has been created.
-
-## Goals / Non-Goals
-
-**Goals:**
-- Make `openspec status` exit with code 0 and a friendly message when no changes exist
-- Support both text and JSON output modes for the no-changes case
-- Keep all other commands' validation behavior unchanged
-
-**Non-Goals:**
-- Changing the behavior of `validateChangeExists` (keep it strict for all consumers; only extract its internal helper)
-- Changing the onboard template or skill instructions
-- Handling the case where `--change` is provided but the specific change doesn't exist (this should remain an error)
-
-## Decisions
-
-### Extract `getAvailableChanges` and check before validation
-
-**Rationale**: Extract the private `getAvailableChanges` closure from `validateChangeExists` into a public exported function in `shared.ts`. Then, in `statusCommand`, call `getAvailableChanges` *before* `validateChangeExists` to detect the no-changes case early and handle it gracefully. This avoids using try/catch for control flow and eliminates any coupling to error message strings.
-
-**Alternative considered**: Catching the error from `validateChangeExists` by matching `error.message.startsWith('No changes found')`. Rejected because string coupling is fragile — if the error message changes, the catch silently stops working.
-
-**Alternative considered**: Adding a `throwOnEmpty` parameter to `validateChangeExists`. Rejected because it adds complexity to a shared function for a single consumer's needs and mixes UX concerns into a validation utility.
-
-### Keep `validateChangeExists` strict
-
-**Rationale**: `validateChangeExists` remains unchanged in behavior — it still throws for all error cases. The graceful handling lives entirely in `statusCommand`, which is the appropriate layer for UX decisions. Other commands (`apply`, `show`, `instructions`) are unaffected.
-
-## Risks / Trade-offs
-
-- [Risk] Extra filesystem read when no `--change` is provided and changes *do* exist (`getAvailableChanges` is called first, then `validateChangeExists` performs its own read) → Mitigation: `statusCommand` returns early before reaching `validateChangeExists` when no changes exist, so the double-read only occurs when changes are present — minimal overhead.
-- [Risk] Other commands may also benefit from graceful no-changes handling in the future → Mitigation: `getAvailableChanges` is now public and reusable, making it easy to apply the same pattern elsewhere.

package/OpenSpec-main/openspec/changes/graceful-status-no-changes/proposal.md

@@ -1,25 +0,0 @@
-## Why
-
-When `openspec status` is called without `--change` and no changes exist (e.g., during onboarding on a freshly initialized project), the CLI throws a fatal error: `No changes found. Create one with: openspec new change <name>`. This breaks the onboarding flow because AI agents may call `openspec status` before any change has been created, causing the agent to halt or report failure. Fixes [#714](https://github.com/Fission-AI/OpenSpec/issues/714).
-
-## What Changes
-
-- `openspec status` will exit gracefully (code 0) with a friendly message when no changes exist, instead of throwing a fatal error
-- `openspec status --json` will return a valid JSON object with an empty changes array when no changes exist
-- Other commands (`apply`, `show`, etc.) retain their current strict validation behavior
-
-## Capabilities
-
-### New Capabilities
-
-- `graceful-status-empty`: Graceful handling of `openspec status` when no changes exist, covering both text and JSON output modes
-
-### Modified Capabilities
-
-_None — `validateChangeExists` was internally refactored to delegate to the newly exported `getAvailableChanges`, but its behavior and public contract are unchanged. Other consumers are unaffected._
-
-## Impact
-
-- `src/commands/workflow/shared.ts` — extract `getAvailableChanges` as a public function (validation behavior unchanged)
-- `src/commands/workflow/status.ts` — check for available changes before validation, handle empty case gracefully
-- Tests for the status command need to cover the new graceful behavior

package/OpenSpec-main/openspec/changes/graceful-status-no-changes/specs/graceful-status-empty/spec.md

@@ -1,27 +0,0 @@
-## ADDED Requirements
-
-### Requirement: Status command exits gracefully when no changes exist
-The `statusCommand` function SHALL check for available changes via `getAvailableChanges` before calling `validateChangeExists`. When no `--change` option is provided and no change directories exist, it SHALL print a friendly informational message and exit with code 0, instead of reaching `validateChangeExists` and propagating a fatal error.
-
-#### Scenario: No changes exist, text mode
-- **WHEN** user runs `openspec status` without `--change` and no change directories exist under `openspec/changes/`
-- **THEN** the CLI prints `No active changes. Create one with: openspec new change <name>` to stdout and exits with code 0
-
-#### Scenario: No changes exist, JSON mode
-- **WHEN** user runs `openspec status --json` without `--change` and no change directories exist
-- **THEN** the CLI outputs `{"changes":[],"message":"No active changes."}` as valid JSON to stdout and exits with code 0
-
-### Requirement: Existing status validation behavior is preserved
-Other error paths in `validateChangeExists` that apply to the status command SHALL continue to throw errors as before. Commands other than `status` that use `validateChangeExists` SHALL NOT be affected.
-
-#### Scenario: Changes exist but --change not specified
-- **WHEN** user runs `openspec status` without `--change` and one or more change directories exist
-- **THEN** the CLI throws an error listing available changes with the message `Missing required option --change. Available changes: ...`
-
-#### Scenario: Specified change does not exist
-- **WHEN** user runs `openspec status --change non-existent`
-- **THEN** the CLI throws an error with message `Change 'non-existent' not found`
-
-#### Scenario: Other commands unaffected
-- **WHEN** user runs `openspec show` or `openspec instructions` without `--change` and no changes exist
-- **THEN** the CLI throws the original `No changes found` error (no behavior change)

package/OpenSpec-main/openspec/changes/graceful-status-no-changes/tasks.md

@@ -1,16 +0,0 @@
-## 1. Implementation
-
-- [x] 1.1 Extract `getAvailableChanges` in `shared.ts` and use it in `statusCommand` to check for changes before calling `validateChangeExists`
-- [x] 1.2 In text mode: print `No active changes. Create one with: openspec new change <name>` and return (exit 0)
-- [x] 1.3 In JSON mode: output `{"changes":[],"message":"No active changes."}` and return (exit 0)
-
-## 2. Tests
-
-- [x] 2.1 Add test: `openspec status` with no changes exits gracefully with friendly message (text mode)
-- [x] 2.2 Add test: `openspec status --json` with no changes returns valid JSON with empty changes array
-- [x] 2.3 Verify existing behavior: `openspec status` without `--change` when changes exist still throws missing option error
-- [x] 2.4 Verify cross-platform: tests use `path.join()` for any path assertions
-
-## 3. Release
-
-- [x] 3.1 Add changeset describing the fix

package/OpenSpec-main/openspec/changes/schema-alias-support/.openspec.yaml

@@ -1,2 +0,0 @@
-schema: spec-driven
-created: 2026-01-20

package/OpenSpec-main/openspec/changes/schema-alias-support/proposal.md

@@ -1,28 +0,0 @@
-## Why
-
-We want to rename `spec-driven` to `openspec-default` to better reflect that it's the standard/default workflow. However, renaming directly would break existing projects that have `schema: spec-driven` in their `openspec/config.yaml`. Adding alias support allows both names to work interchangeably, enabling a smooth transition with no breaking changes.
-
-## What Changes
-
-- Add schema alias resolution in the schema resolver
-- `openspec-default` and `spec-driven` will both resolve to the same schema
-- The physical directory remains `schemas/spec-driven/` (or could be renamed to `schemas/openspec-default/` with `spec-driven` as the alias)
-- All CLI commands and config files accept either name
-- No changes required to existing user configs
-
-## Capabilities
-
-### New Capabilities
-
-- `schema-aliases`: Support for schema name aliases so multiple names can resolve to the same schema directory
-
-### Modified Capabilities
-
-<!-- No existing spec-level behavior is changing - this is purely additive -->
-
-## Impact
-
-- `src/core/artifact-graph/resolver.ts` - Add alias resolution logic
-- `schemas/` directory - Potentially rename `spec-driven` to `openspec-default`
-- Documentation - Update to prefer `openspec-default` while noting `spec-driven` still works
-- Default schema constants - Update `DEFAULT_SCHEMA` to `openspec-default`

package/OpenSpec-main/openspec/changes/simplify-skill-installation/.openspec.yaml

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

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

@@ -1,288 +0,0 @@
-## Context
-
-OpenSpec currently installs 10 workflows (skills + commands) for every user, overwhelming new users. The init flow asks multiple questions (profile, delivery, tools) creating friction before users can experience value.
-
-Current architecture:
-- `src/core/init.ts` - Handles tool selection and skill/command generation
-- `src/core/config.ts` - Defines `AI_TOOLS` with `skillsDir` mappings
-- `src/core/shared/skill-generation.ts` - Generates skill files from templates
-- `src/core/templates/workflows/*.ts` - Individual workflow templates
-- `src/prompts/searchable-multi-select.ts` - Tool selection UI
-
-Global config exists at `~/.config/openspec/config.json` for telemetry/feature flags. Profile/delivery settings will extend this existing config.
-
-## Goals / Non-Goals
-
-**Goals:**
-- Get new users to "aha moment" in under 1 minute
-- Smart defaults init with auto-detection and confirmation (core profile, both delivery)
-- Auto-detect installed tools from existing directories
-- Introduce profile system (core/custom) for workflow selection
-- Introduce delivery config (skills/commands/both) as power-user setting
-- Create new `propose` workflow combining `new` + `ff`
-- Fix tool selection UX (space to select, enter to confirm)
-- Maintain backwards compatibility for existing users
-
-**Non-Goals:**
-- Removing any existing workflows (all remain available via custom profile)
-- Per-project profile/delivery settings (user-level only)
-- Changing the artifact structure or schema system
-- Modifying how skills/commands are formatted or written
-
-## Decisions
-
-### 1. Extend Existing Global Config
-
-Add profile/delivery settings to existing `~/.config/openspec/config.json` (via `src/core/global-config.ts`).
-
-**Rationale:** Global config already exists with XDG/APPDATA cross-platform path handling, schema evolution, and merge-with-defaults behavior. Reusing it avoids a second config file and leverages existing infrastructure.
-
-**Schema extension:**
-```json
-{
-  "telemetry": { ... },     // existing
-  "featureFlags": { ... },  // existing
-  "profile": "core",        // NEW
-  "delivery": "both",       // NEW
-  "workflows": [...]        // NEW (only for custom profile)
-}
-```
-
-**Alternatives considered:**
-- New `~/.openspec/config.yaml`: Creates second config file, different format, path confusion
-- Project config: Would require syncing mechanism, users edit it directly
-- Environment variables: Less discoverable, harder to persist
-
-### 2. Profile System with Two Tiers
-
-```
-core (default):     propose, explore, apply, archive (4)
-custom:             user-defined subset of workflows
-```
-
-**Rationale:** Core covers the essential loop (propose → explore → apply → archive). Custom allows users to pick exactly what they need via an interactive picker.
-
-**Configuration UX:**
-```
-$ openspec config profile
-
-Delivery: [skills] [commands] [both]
-                              ^^^^^^
-
-Workflows: (space to toggle, enter to save)
-[x] propose
-[x] explore
-[x] apply
-[x] archive
-[ ] new
-[ ] ff
-...
-```
-
-**Alternatives considered:**
-- Three tiers (core/extended/custom): Extended is redundant - users who want all workflows can select them in custom
-- Separate commands for profile and delivery: Combining into one picker reduces cognitive load
-
-### 3. Propose Workflow = New + FF Combined
-
-Single workflow that creates a change and generates all artifacts in one step.
-
-**Rationale:** Most users want to go from idea to implementation-ready. Separating `new` (creates folder) and `ff` (generates artifacts) adds unnecessary steps. Power users who want control can use `new` + `continue` via custom profile.
-
-**Implementation:** New template in `src/core/templates/workflows/propose.ts` that:
-1. Creates change directory via `openspec new change`
-2. Runs artifact generation loop (like ff does)
-3. Includes onboarding-style explanations in output
-
-### 4. Auto-Detection with Confirmation
-
-Scan for existing tool directories, pre-select detected tools, ask for confirmation.
-
-**Rationale:** Reduces questions while still giving user control. Better than full auto (no confirmation) which might install unwanted tools, or no detection (always ask) which adds friction.
-
-**Detection logic:**
-```typescript
-// Use existing AI_TOOLS config to get directory mappings
-// Each tool in AI_TOOLS has a skillsDir property (e.g., '.claude', '.cursor', '.windsurf')
-// Scan cwd for existing directories matching skillsDir values, pre-select matches
-const detectedTools = AI_TOOLS.filter(tool =>
-  fs.existsSync(path.join(cwd, tool.skillsDir))
-);
-```
-
-### 5. Delivery as Part of Profile Config
-
-Delivery preference (skills/commands/both) stored in global config, defaulting to "both".
-
-**Rationale:** Most users don't know or care about this distinction. Power users who have a preference can set it via `openspec config profile` interactive picker. Not worth asking during init.
-
-### 6. Filesystem as Truth for Installed Workflows
-
-What's installed in `.claude/skills/` (etc.) is the source of truth, not config.
-
-**Rationale:**
-- Backwards compatible with existing installs
-- User can manually add/remove skill directories
-- Config profile is a "template" for what to install, not a constraint
-
-**Behavior:**
-- `openspec init` sets up new projects OR re-initializes existing projects (selects tools, generates workflows)
-- `openspec update` refreshes an existing project to match current config (no tool selection)
-- `openspec config profile` updates global config only, offers to run update if in a project
-- Extra workflows (not in profile) are preserved
-- Delivery changes are applied: switching to `skills` removes commands, switching to `commands` removes skills
-
-**Why not a separate tool manifest?**
-
-Tool selection (which assistants a project uses) is per-user AND per-project, but the two config locations are per-user-only (global config) or per-project-shared (checked-in project config). A separate manifest was explored and rejected:
-
-- *Path-keyed global config* (`projects: { "/path": { tools: [...] } }`): Fragile on directory move/rename/delete, symlink ambiguity, and project behavior depends on invisible external state.
-- *Gitignored local file* (`.openspec.local`): Lost on fresh clone, adds file management overhead.
-- *Checked-in project config* (`openspec/config.yaml` with `tools` field): Forces tool choices on the whole team — Alice uses Claude Code, Bob uses Cursor, neither wants the other's tools mandated.
-
-The filesystem approach avoids all three problems. For teams, it's actually beneficial: checked-in skill files mean `openspec update` from any team member refreshes skills for all tools the project supports. The generated files serve as both the deliverable and the implicit tool manifest.
-
-Known gap: a tool that stores config outside the project tree (no local directory to scan) would need tool-specific handling, since there's nothing in the project to scan. Address if/when such a tool is supported.
-
-**When to use init vs update:**
-- `init`: First time setup, or when you want to change which tools are configured
-- `update`: After changing config, or to refresh templates to latest version
-
-### 8. Existing User Migration
-
-When `openspec init` or `openspec update` encounters a project with existing workflows but no `profile` field in global config, it performs a one-time migration to preserve the user's current setup.
-
-**Rationale:** Without migration, existing users would default to `core` profile, causing `propose` to be added on top of their 10 workflows — making things worse, not better. Migration ensures existing users keep exactly what they have.
-
-**Triggered by:** Both `init` (re-init on existing project) and `update`. The migration check is a shared function called early in both commands, before profile resolution.
-
-**Detection logic:**
-```typescript
-// Shared migration check, called by both init and update:
-function migrateIfNeeded(projectPath: string, tools: AiTool[]): void {
-  const globalConfig = readGlobalConfig();
-  if (globalConfig.profile) return; // already migrated or explicitly set
-
-  const installedWorkflows = scanInstalledWorkflows(projectPath, tools);
-  if (installedWorkflows.length === 0) return; // new user, use core defaults
-
-  // Existing user — migrate to custom profile
-  writeGlobalConfig({
-    ...globalConfig,
-    profile: 'custom',
-    delivery: 'both',
-    workflows: installedWorkflows,
-  });
-}
-```
-
-**Scanning logic:**
-- Scan all tool directories (`.claude/skills/`, `.cursor/skills/`, etc.) for workflow directories/files
-- Match only against `ALL_WORKFLOWS` constant — ignore user-created custom skills/commands
-- Map directory names back to workflow IDs (e.g., `openspec-explore/` → `explore`, `opsx-explore.md` → `explore`)
-- Take the union of detected workflow names across all tools
-
-**Edge cases:**
-- **User manually deleted some workflows:** Migration scans what's actually installed, respecting their choices
-- **Multiple projects with different workflow sets:** First project to trigger migration sets global config; subsequent projects use it
-- **User has custom (non-OpenSpec) skills in the directory:** Ignored — scanner only matches known workflow IDs from `ALL_WORKFLOWS`
-- **Migration is idempotent:** If `profile` is already set in config, no re-migration occurs
-- **Non-interactive (CI):** Same migration logic, no confirmation needed — it's preserving existing state
-
-**Alternatives considered:**
-- Migrate during `init` instead of `update`: Init already has its own flow (tool selection, etc.). Mixing migration with init creates confusing UX
-- Don't migrate, just default to core: Breaks existing users by adding `propose` and showing "extra workflows" warnings
-- Migrate at global config read time: Too implicit, hard to show feedback to user
-
-### 9. Generic Next-Step Guidance in Templates
-
-Workflow templates use generic, concept-based next-step guidance rather than referencing specific workflow commands. For example, instead of "run `/opsx:propose`", templates say "create a change proposal".
-
-**Rationale:** Conditional cross-referencing (where each template checks which other workflows are installed and renders different command names) adds significant complexity to template generation, testing, and maintenance. Generic guidance avoids this entirely while still being useful — users already know their installed workflows.
-
-**Note:** If we find that users consistently struggle to map concepts to commands, we can revisit this with conditional cross-references. For now, simplicity wins.
-
-### 7. Fix Multi-Select Keybindings
-
-Change from tab-to-confirm to industry-standard space/enter.
-
-**Rationale:** Tab to confirm is non-standard and confuses users. Most CLI tools use space to toggle, enter to confirm.
-
-**Implementation:** Modify `src/prompts/searchable-multi-select.ts` keybinding configuration.
-
-### 10. Update Sync Must Consider Config Drift, Not Just Version Drift
-
-`openspec update` cannot rely only on `generatedBy` version checks for deciding whether work is needed.
-
-**Rationale:** profile and delivery changes can require file add/remove operations even when existing skill templates are current. If we only check template versions, update may incorrectly return "up to date" and skip required sync.
-
-**Implementation:**
-- Keep version checks for template refresh decisions
-- Add file-state drift checks for profile/delivery (missing expected files or stale files from removed delivery mode)
-- Treat either version drift OR config drift as update-required
-
-### 11. Tool Configuration Detection Includes Commands-Only Installs
-
-Configured-tool detection for update must include command files, not only skill files.
-
-**Rationale:** with `delivery: commands`, a project can be fully configured without skill files. Skill-only detection incorrectly reports "No configured tools found."
-
-**Implementation:**
-- For update flows, treat a tool as configured if it has either generated skills or generated commands
-- Keep migration workflow scanning behavior unchanged (skills remain the migration source of truth)
-
-### 12. Init Profile Override Is Strictly Validated
-
-`openspec init --profile` must validate allowed values before proceeding.
-
-**Rationale:** silently accepting unknown profile values hides user errors and produces implicit fallback behavior.
-
-**Implementation:** accept only `core` and `custom`; throw a clear CLI error for invalid values.
-
-## Risks / Trade-offs
-
-**Risk: Breaking existing user workflows**
-→ Mitigation: Filesystem is truth, existing installs untouched. All workflows available via custom profile.
-
-**Risk: Propose workflow duplicates ff logic**
-→ Mitigation: Extract shared artifact generation into reusable function, both `propose` and `ff` call it.
-
-**Risk: Global config file management**
-→ Mitigation: Create directory/file on first use. Handle missing file gracefully (use defaults).
-
-**Risk: Auto-detection false positives**
-→ Mitigation: Show detected tools and ask for confirmation, don't auto-install silently.
-
-**Trade-off: Core profile has only 4 workflows**
-→ Acceptable: These cover the main loop. Users who need more can use `openspec config profile` to select additional workflows.
-
-## Migration Plan
-
-1. **Phase 1: Add infrastructure**
-   - Extend global-config.ts with profile/delivery/workflows fields
-   - Profile definitions and resolution
-   - Tool auto-detection
-
-2. **Phase 2: Create propose workflow**
-   - New template combining new + ff
-   - Enhanced UX with explanatory output
-
-3. **Phase 3: Update init flow**
-   - Smart defaults with tool confirmation
-   - Auto-detect and confirm tools
-   - Respect profile/delivery settings
-
-4. **Phase 4: Add config profile command**
-   - `openspec config profile` interactive picker
-   - `openspec config profile core` preset shortcut
-
-5. **Phase 5: Update the update command**
-   - Read global config for profile/delivery
-   - Add missing workflows from profile
-   - Delete files when delivery changes (e.g., commands removed if `skills`)
-   - Display summary of changes
-
-6. **Phase 6: Fix multi-select UX**
-   - Update keybindings in searchable-multi-select
-
-**Rollback:** All changes are additive. Existing behavior preserved via custom profile with all workflows selected.