sauron-cli 1.3.0 → 1.4.0

package/OpenSpec-main/openspec/changes/archive/2026-05-14-workspace-change-planning/specs/cli-config/spec.md

@@ -1,55 +0,0 @@
-## ADDED Requirements
-
-### Requirement: Config profile applies to current workspace
-The `openspec config profile` command SHALL remain global while offering an explicit workspace apply path when run from inside an OpenSpec workspace.
-
-#### Scenario: Config profile run inside a workspace
-- **GIVEN** the command runs from inside an OpenSpec workspace
-- **WHEN** the user changes profile or delivery settings with interactive `openspec config profile`
-- **THEN** OpenSpec SHALL save the global config changes
-- **AND** it SHALL prompt: `Apply changes to this workspace now?`
-
-#### Scenario: User confirms workspace apply
-- **GIVEN** `openspec config profile` changed global profile or delivery settings inside a workspace
-- **WHEN** the user confirms the workspace apply prompt
-- **THEN** OpenSpec SHALL run `openspec workspace update` for the current workspace
-- **AND** it SHALL not run repo-local `openspec update` unless the current planning home is repo-local
-
-#### Scenario: User declines workspace apply
-- **GIVEN** `openspec config profile` changed global profile or delivery settings inside a workspace
-- **WHEN** the user declines the workspace apply prompt
-- **THEN** OpenSpec SHALL explain that global config was updated
-- **AND** it SHALL tell the user to run `openspec workspace update` later to apply the profile to workspace-local skills
-- **AND** it SHALL not modify workspace skill files
-
-#### Scenario: No-op inside workspace
-- **GIVEN** the command runs from inside an OpenSpec workspace
-- **WHEN** `openspec config profile` exits with no effective config changes
-- **THEN** OpenSpec SHALL not prompt to apply changes
-- **AND** it SHALL warn if workspace-local skills are out of sync with the current global profile
-- **AND** the warning SHALL suggest `openspec workspace update`
-
-#### Scenario: Core preset shortcut inside a workspace
-- **GIVEN** the command runs from inside an OpenSpec workspace
-- **WHEN** the user runs `openspec config profile core`
-- **THEN** OpenSpec SHALL save the global config change without prompting to apply immediately
-- **AND** it SHALL tell the user to run `openspec workspace update` to apply the profile to workspace-local skills
-
-#### Scenario: Core preset shortcut inside a repo project
-- **GIVEN** the command runs from inside a repo-local OpenSpec project
-- **WHEN** the user runs `openspec config profile core`
-- **THEN** OpenSpec SHALL preserve existing repo-local shortcut behavior
-- **AND** it SHALL tell the user to run `openspec update` to apply the profile to project files
-
-#### Scenario: Workspace planning home wins over linked repo project
-- **GIVEN** the command runs in a path under a workspace planning home where a repo-local OpenSpec project could also be detected
-- **WHEN** OpenSpec decides which apply prompt to show
-- **THEN** the nearest current planning home SHALL determine whether to offer `openspec workspace update` or repo-local `openspec update`
-- **AND** OpenSpec SHALL not apply profile changes to a linked repo when the current planning home is the workspace
-
-#### Scenario: Linked repo keeps repo-local profile behavior
-- **GIVEN** a repo-local OpenSpec project is registered as a workspace link
-- **AND** the command runs from inside that linked repo rather than from the workspace planning home
-- **WHEN** OpenSpec decides which apply prompt or guidance to show
-- **THEN** OpenSpec SHALL preserve repo-local `openspec update` behavior for that repo
-- **AND** it SHALL not offer `openspec workspace update` unless the workspace is explicitly selected

package/OpenSpec-main/openspec/changes/archive/2026-05-14-workspace-change-planning/specs/cli-update/spec.md

@@ -1,21 +0,0 @@
-## ADDED Requirements
-
-### Requirement: Repo update redirects from workspace planning homes
-The repo-local `openspec update` command SHALL not silently treat a workspace planning home as a repo-local OpenSpec project.
-
-#### Scenario: Running update from a workspace root
-- **GIVEN** the command runs from an OpenSpec workspace root
-- **WHEN** the user runs `openspec update`
-- **THEN** OpenSpec SHALL not generate repo-local project files in the workspace root
-- **AND** it SHALL tell the user to run `openspec workspace update`
-
-#### Scenario: Running update from inside a workspace planning directory
-- **GIVEN** the command runs from a subdirectory of an OpenSpec workspace planning home
-- **WHEN** the user runs `openspec update`
-- **THEN** OpenSpec SHALL not run repo-local update behavior
-- **AND** it SHALL tell the user to run `openspec workspace update`
-
-#### Scenario: Running update from a repo-local project
-- **GIVEN** the command runs from inside a repo-local OpenSpec project
-- **WHEN** the user runs `openspec update`
-- **THEN** OpenSpec SHALL preserve existing repo-local update behavior

package/OpenSpec-main/openspec/changes/archive/2026-05-14-workspace-change-planning/specs/openspec-conventions/spec.md

@@ -1,32 +0,0 @@
-## ADDED Requirements
-
-### Requirement: Workspace planning vocabulary
-OpenSpec conventions SHALL distinguish workspace planning concepts using user-facing product language.
-
-#### Scenario: Naming affected areas
-- **WHEN** documentation or generated guidance refers to repos, folders, packages, services, apps, or docs sites touched by a workspace change
-- **THEN** it SHALL call them affected areas
-- **AND** it SHALL avoid using "target repo" or "repo slice" as the primary user-facing term
-
-#### Scenario: Naming delivery slices
-- **WHEN** documentation or generated guidance refers to delivery increments inside a larger change
-- **THEN** it SHALL call them slices or phases only when delivery sequencing is the subject
-- **AND** it SHALL not use slice as a synonym for repo, folder, or affected area
-
-### Requirement: Workspace planning and implementation boundary
-OpenSpec conventions SHALL distinguish workspace-level planning from repo-local implementation ownership.
-
-#### Scenario: Workspace as shared planning home
-- **WHEN** a change spans linked repos or folders
-- **THEN** conventions SHALL describe the workspace as the shared planning home
-- **AND** repo-local implementation homes SHALL retain ownership of their code and canonical behavior
-
-#### Scenario: Avoiding materialization-first language
-- **WHEN** documentation explains workspace change creation
-- **THEN** it SHALL describe the user outcome in terms of shared planning and affected areas
-- **AND** it SHALL avoid making users understand implementation terms such as materialization before they can plan
-
-#### Scenario: Preserving familiar workflow verbs
-- **WHEN** workspace guidance describes OpenSpec workflows
-- **THEN** it SHALL keep the familiar verbs explore, propose, apply, verify, and archive
-- **AND** it SHALL explain that workspace context changes paths, scope, and allowed edit roots rather than creating a separate workflow family

package/OpenSpec-main/openspec/changes/archive/2026-05-14-workspace-change-planning/specs/schema-resolution/spec.md

@@ -1,25 +0,0 @@
-## ADDED Requirements
-
-### Requirement: Workspace planning schema resolution
-Schema resolution SHALL support the built-in workspace planning schema.
-
-#### Scenario: Listing workspace planning schema
-- **WHEN** a user runs `openspec schemas`
-- **THEN** the output SHALL include `workspace-planning`
-- **AND** it SHALL identify it as a package-provided schema unless overridden by a higher-precedence schema
-
-#### Scenario: Resolving workspace planning schema by name
-- **WHEN** a workflow command requests schema `workspace-planning`
-- **THEN** schema resolution SHALL resolve it using the normal project, user, then package precedence order
-
-#### Scenario: Workspace default schema for new changes
-- **GIVEN** the command creates a change in a workspace planning home
-- **AND** the user did not pass an explicit `--schema`
-- **WHEN** OpenSpec resolves the schema for the new change
-- **THEN** it SHALL use `workspace-planning` as the default schema
-
-#### Scenario: Explicit schema override for workspace change
-- **GIVEN** the command creates a change in a workspace planning home
-- **WHEN** the user passes an explicit `--schema <name>`
-- **THEN** OpenSpec SHALL use the explicitly requested schema
-- **AND** it SHALL validate that schema using normal schema resolution

package/OpenSpec-main/openspec/changes/archive/2026-05-14-workspace-change-planning/specs/workspace-change-planning/spec.md

@@ -1,67 +0,0 @@
-## ADDED Requirements
-
-### Requirement: Workspace change planning home
-OpenSpec SHALL support workspace-level changes whose shared plan lives in the workspace planning home.
-
-#### Scenario: Creating a workspace change
-- **GIVEN** the command runs from an OpenSpec workspace
-- **WHEN** the user creates a change for workspace planning
-- **THEN** OpenSpec SHALL create the change under the workspace planning path
-- **AND** it SHALL treat the workspace as the planning home for that change
-- **AND** it SHALL use the workspace planning schema when no explicit schema is provided
-
-#### Scenario: Workspace planning artifact structure
-- **GIVEN** a workspace change uses the workspace planning schema
-- **WHEN** OpenSpec reports or creates planning artifacts for that change
-- **THEN** it SHALL use workspace-level artifacts for proposal, specs, cross-area design, and coordination tasks
-- **AND** those artifacts SHALL live under the workspace change root
-- **AND** it SHALL not require an additional area manifest outside those normal planning artifacts
-
-#### Scenario: Capturing the shared goal once
-- **WHEN** a workspace change is proposed
-- **THEN** OpenSpec SHALL capture the product goal at the workspace change level
-- **AND** it SHALL avoid requiring separate repo-local proposals before the affected areas are understood
-
-#### Scenario: Preserving linked repos during change creation
-- **WHEN** OpenSpec creates a workspace-level change
-- **THEN** it SHALL not create repo-local OpenSpec change directories inside linked repos or folders
-- **AND** it SHALL not edit implementation files in linked repos or folders
-
-### Requirement: Workspace affected areas
-OpenSpec SHALL represent ownership or implementation boundaries in a workspace change as affected areas.
-
-#### Scenario: Using registered workspace links as areas
-- **GIVEN** a workspace has linked repos or folders
-- **WHEN** a workspace change identifies affected areas by registered link name
-- **THEN** OpenSpec SHALL validate those area names against the workspace links
-- **AND** it SHALL report invalid area names clearly
-
-#### Scenario: Planning before all areas are known
-- **WHEN** a user is still exploring a workspace change
-- **THEN** OpenSpec SHALL allow the shared plan to exist before all affected areas are finalized
-- **AND** it SHALL keep unresolved affected area questions visible in the normal planning artifacts and status output
-
-#### Scenario: Organizing requirements by area
-- **GIVEN** a workspace change has requirements owned by one or more affected areas
-- **WHEN** OpenSpec reports or creates workspace-scoped specs
-- **THEN** it SHALL allow area-specific requirements to be organized under `specs/<area-or-repo>/<capability>/spec.md`
-- **AND** it SHALL not require separate area folders outside the normal `specs/` artifact tree
-- **AND** it SHALL preserve the area-or-repo path segment as workspace planning context rather than flattening it into a repo-local capability name
-
-#### Scenario: Separating areas from delivery slices
-- **WHEN** a workspace change reports affected areas
-- **THEN** OpenSpec SHALL distinguish affected areas from delivery slices or phases
-- **AND** it SHALL not require users to define delivery slices for a small cross-area change
-
-### Requirement: Workspace planning source of truth
-OpenSpec SHALL keep the workspace change plan as the source of truth until implementation begins for a selected affected area.
-
-#### Scenario: Exploring before implementation
-- **WHEN** an agent explores a workspace change
-- **THEN** it SHALL use workspace-level planning artifacts as the shared planning source
-- **AND** it SHALL treat linked repos and folders as available context rather than committed implementation targets
-
-#### Scenario: Deferring repo-local implementation
-- **WHEN** repo-local implementation work is needed for a workspace change
-- **THEN** OpenSpec SHALL require an explicit implementation workflow with a selected affected area
-- **AND** it SHALL expose the allowed edit root for that selected area before implementation edits begin

package/OpenSpec-main/openspec/changes/archive/2026-05-14-workspace-change-planning/specs/workspace-links/spec.md

@@ -1,163 +0,0 @@
-## ADDED Requirements
-
-### Requirement: Workspace setup installs agent skills
-OpenSpec SHALL let users install OpenSpec agent skills into a workspace during workspace setup.
-
-#### Scenario: Prompting for workspace agent skills
-- **WHEN** interactive workspace setup reaches agent skill installation
-- **THEN** OpenSpec SHALL ask which agents should get OpenSpec skills in this workspace
-- **AND** the prompt SHALL use agent-skill language rather than "AI tools" language
-
-#### Scenario: Preselecting the preferred opener
-- **GIVEN** the user selected a preferred opener that supports OpenSpec skill generation
-- **WHEN** interactive workspace setup asks which agents should get skills
-- **THEN** OpenSpec SHALL preselect the matching agent
-- **AND** the user SHALL be able to select additional agents or deselect the preselected agent
-
-#### Scenario: Installing selected workspace skills
-- **WHEN** workspace setup completes with one or more selected agents
-- **THEN** OpenSpec SHALL generate or refresh OpenSpec skill files under the workspace root for each selected agent
-- **AND** it SHALL report which agents received skills
-- **AND** it SHALL store the selected agents in workspace-local machine state
-
-#### Scenario: Installing profile-selected workflows
-- **GIVEN** global config resolves to a workflow profile
-- **WHEN** workspace setup installs agent skills
-- **THEN** OpenSpec SHALL install workspace-local skills for the workflows selected by that profile
-- **AND** it SHALL treat `--tools` as agent selection, not workflow selection
-- **AND** it SHALL record the last applied workflow IDs for drift detection
-
-#### Scenario: Installing skills only during setup
-- **WHEN** workspace setup installs agent skills
-- **THEN** OpenSpec SHALL generate skill files only
-- **AND** it SHALL not generate slash command files or global command files as part of workspace setup
-
-#### Scenario: Ignoring command delivery for workspace setup
-- **GIVEN** global config delivery is `commands` or `both`
-- **WHEN** workspace setup installs agent skills
-- **THEN** OpenSpec SHALL still generate workspace-local skills only
-- **AND** it SHALL report that workspace command generation is not part of this slice
-
-#### Scenario: Preserving linked repos during skill installation
-- **WHEN** workspace setup installs agent skills
-- **THEN** OpenSpec SHALL leave linked repos and folders unchanged
-- **AND** generated skills SHALL be scoped to the workspace planning home
-
-#### Scenario: Non-interactive setup tool selection
-- **WHEN** non-interactive workspace setup receives `--tools all`, `--tools none`, or `--tools <ids>`
-- **THEN** OpenSpec SHALL use the selected tool set for workspace agent skill installation
-- **AND** it SHALL validate tool IDs using the same supported tool IDs as skill generation for repo initialization
-
-#### Scenario: Non-interactive setup without tool selection
-- **WHEN** non-interactive workspace setup omits `--tools`
-- **THEN** OpenSpec SHALL create the workspace without installing agent skills
-- **AND** it SHALL report that no workspace skills were installed
-- **AND** it SHALL tell the user to run `openspec workspace update --tools <ids>` to install skills later
-
-#### Scenario: Reporting setup skills in JSON output
-- **WHEN** non-interactive workspace setup installs agent skills with JSON output enabled
-- **THEN** OpenSpec SHALL include generated, refreshed, skipped, or failed skill installation results in machine-readable output
-
-### Requirement: Workspace update manages agent skills
-OpenSpec SHALL provide a workspace update flow for refreshing agent skills after setup.
-
-#### Scenario: Updating the current workspace
-- **GIVEN** the command runs from inside an OpenSpec workspace
-- **WHEN** the user runs `openspec workspace update`
-- **THEN** OpenSpec SHALL update that current workspace
-
-#### Scenario: Updating a named workspace
-- **GIVEN** a workspace named `platform` is known locally
-- **WHEN** the user runs `openspec workspace update platform`
-- **THEN** OpenSpec SHALL update the `platform` workspace
-
-#### Scenario: Updating a workspace selected by flag
-- **GIVEN** a workspace named `platform` is known locally
-- **WHEN** the user runs `openspec workspace update --workspace platform`
-- **THEN** OpenSpec SHALL update the `platform` workspace
-
-#### Scenario: Updating selected workspace skills
-- **WHEN** workspace update completes with selected agents
-- **THEN** OpenSpec SHALL refresh OpenSpec skills for selected agents
-- **AND** it SHALL add skills for newly selected agents
-- **AND** it SHALL remove OpenSpec-managed workflow skill directories for agents that are no longer selected
-- **AND** it SHALL update the stored workspace-local selected agent list
-
-#### Scenario: Updating profile-selected workflows
-- **GIVEN** global config resolves to a workflow profile
-- **WHEN** workspace update refreshes workspace-local skills
-- **THEN** OpenSpec SHALL sync the workspace-local skill workflow set to the workflows selected by that profile
-- **AND** deselected workflow skill directories SHALL be removed only when they are known OpenSpec-managed workflow skill directories
-- **AND** it SHALL update the last applied workflow IDs used for drift detection
-
-#### Scenario: Ignoring command delivery for workspace update
-- **GIVEN** global config delivery is `commands` or `both`
-- **WHEN** workspace update refreshes workspace-local skills
-- **THEN** OpenSpec SHALL still update workspace-local skills only
-- **AND** it SHALL not generate slash command files or global command files
-
-#### Scenario: Removing only managed skill directories
-- **WHEN** workspace update removes skills for an unselected agent
-- **THEN** OpenSpec SHALL remove only known OpenSpec-managed workflow skill directories
-- **AND** it SHALL preserve unrelated files in the agent directory
-
-#### Scenario: Updating stored agent selection by flag
-- **WHEN** workspace update receives `--tools <ids>` or `--tools none`
-- **THEN** OpenSpec SHALL replace the stored workspace-local selected agent list with that selection
-- **AND** future workspace updates without `--tools` SHALL use the stored selection
-
-#### Scenario: Non-interactive update tool selection
-- **WHEN** workspace update receives `--tools all`, `--tools none`, or `--tools <ids>`
-- **THEN** OpenSpec SHALL update workspace agent skills using that selected tool set
-- **AND** it SHALL avoid prompting for agent selection
-
-#### Scenario: Non-interactive update without tool selection
-- **GIVEN** workspace-local selected agents are stored
-- **WHEN** non-interactive workspace update omits `--tools`
-- **THEN** OpenSpec SHALL refresh the stored selected agents using the active global profile
-- **AND** it SHALL avoid prompting for agent selection
-
-#### Scenario: Non-interactive update without stored selection
-- **GIVEN** no workspace-local selected agents are stored
-- **WHEN** non-interactive workspace update omits `--tools`
-- **THEN** OpenSpec SHALL complete without installing agent skills
-- **AND** it SHALL report a no-op with guidance to pass `--tools`
-
-#### Scenario: Reporting workspace skill drift
-- **GIVEN** workspace-local skill state records last applied workflow IDs
-- **AND** the active global profile resolves to a different workflow set
-- **WHEN** OpenSpec reports workspace skill state
-- **THEN** it SHALL report that workspace-local skills are out of sync with the global profile
-- **AND** it SHALL suggest `openspec workspace update`
-
-#### Scenario: Reporting clean workspace skill sync
-- **GIVEN** workspace-local skill state matches the active global profile and selected agents
-- **WHEN** OpenSpec reports workspace skill state
-- **THEN** it SHALL not report profile drift
-
-#### Scenario: Reporting workspace skill update results
-- **WHEN** workspace update changes agent skill state
-- **THEN** OpenSpec SHALL report which agents were refreshed, added, removed, skipped, or failed
-
-#### Scenario: Reporting workspace update results in JSON output
-- **WHEN** workspace update runs with JSON output enabled
-- **THEN** OpenSpec SHALL include refreshed, added, removed, skipped, or failed skill results in machine-readable output
-
-### Requirement: Workspace skill update surface is documented
-OpenSpec SHALL expose workspace skill setup/update behavior in user-facing command surfaces.
-
-#### Scenario: Workspace update appears in help
-- **WHEN** a user runs `openspec workspace --help`
-- **THEN** OpenSpec SHALL list `workspace update`
-- **AND** it SHALL describe it as refreshing workspace-local agent skills
-
-#### Scenario: Workspace update options appear in help
-- **WHEN** a user runs `openspec workspace update --help`
-- **THEN** OpenSpec SHALL document workspace selection options
-- **AND** it SHALL document `--tools all|none|<ids>`
-- **AND** it SHALL state that global profile selects workflows and `--tools` selects agents
-
-#### Scenario: Workspace update appears in completions
-- **WHEN** shell completions are generated
-- **THEN** the workspace command registry SHALL include `workspace update`
-- **AND** it SHALL include relevant options such as `--workspace`, `--tools`, `--json`, and `--no-interactive`

package/OpenSpec-main/openspec/changes/archive/2026-05-14-workspace-change-planning/tasks.md

@@ -1,133 +0,0 @@
-## Phase 1: Workspace Setup Skills
-
-User-testable outcome: A user can run workspace setup, choose which agents get the active profile's OpenSpec skills, and verify the selected skills are generated in the workspace root only.
-
-- [x] 1.1 Add an interactive workspace setup step named "Install agent skills" that asks which agents should get OpenSpec skills in this workspace.
-- [x] 1.2 Preselect the preferred opener when that opener supports skills, while allowing users to choose different or additional agents.
-- [x] 1.3 Support non-interactive agent selection with the existing `--tools all|none|<ids>` style.
-- [x] 1.4 Validate workspace setup tool IDs using the same supported skill-generation tool set as repo initialization.
-- [x] 1.5 Resolve the active global profile and use it to choose which workflow skills workspace setup installs.
-- [x] 1.6 Ensure `openspec workspace setup` generates or refreshes OpenSpec agent skills in the workspace root for the selected agents.
-- [x] 1.7 Keep setup-time skill generation scoped to the workspace planning home; do not write skills or OpenSpec artifacts into linked repos or folders during workspace setup.
-- [x] 1.8 Keep workspace setup skill generation skills-only for this slice; do not generate slash commands or global command files even when global delivery includes commands.
-- [x] 1.9 Define how setup reports generated, refreshed, skipped, failed, and skills-only delivery work in human and JSON output.
-- [x] 1.10 Store the selected workspace skill agents and last-applied workflow IDs in workspace-local machine state.
-- [x] 1.11 Preserve non-interactive setup compatibility when `--tools` is omitted by skipping skill installation with clear guidance.
-- [x] 1.12 Manually run workspace setup in interactive and non-interactive modes and verify the selected profile workflows land only in the workspace root.
-- [x] 1.13 Review the setup UX: prompt wording, defaults, skip path, profile/delivery messaging, success output, and JSON output are clear before moving on.
-
-## Phase 2: Workspace Skill Updates
-
-User-testable outcome: A user can change the global profile, run workspace update in an existing workspace, and see workspace-local skills refresh to the selected workflows with clear human and JSON output.
-
-- [x] 2.1 Add a workspace update flow that refreshes, adds, or removes OpenSpec agent skills in an existing workspace.
-- [x] 2.2 Let `openspec workspace update` resolve the current workspace when run from inside a workspace.
-- [x] 2.3 Support named and selected-workspace update forms such as `openspec workspace update platform` and `openspec workspace update --workspace platform`.
-- [x] 2.4 Support non-interactive update forms such as `openspec workspace update platform --tools codex,claude`.
-- [x] 2.5 Remove only known OpenSpec-managed workflow skill directories for agents that are no longer selected.
-- [x] 2.6 Sync workspace-local workflow skill directories to the current global profile selection.
-- [x] 2.7 Keep workspace update skills-only for this slice; do not generate slash commands or global command files even when global delivery includes commands.
-- [x] 2.8 Define how update reports refreshed, added, removed, skipped, failed, and skills-only delivery work in human and JSON output.
-- [x] 2.9 Use stored selected agents when workspace update runs without `--tools`, and update that stored selection when `--tools` is passed.
-- [x] 2.10 Detect workspace-local skill drift from the active global profile and report `openspec workspace update` guidance.
-- [x] 2.11 Manually run workspace update for refresh, add, remove, no-op, omitted-`--tools`, and profile-change cases and verify linked repos remain unchanged.
-- [x] 2.12 Review the update UX: command forms, current-workspace detection, profile/delivery messaging, drift messaging, removal messaging, and JSON output are understandable.
-
-## Phase 3: Config Profile Workspace Apply
-
-User-testable outcome: A user can run `openspec config profile` inside a workspace and choose whether to apply the changed global profile to that workspace now.
-
-- [x] 3.1 Detect when `openspec config profile` runs from inside an OpenSpec workspace.
-- [x] 3.2 After an actual profile or delivery change inside a workspace, prompt to apply changes to the current workspace now.
-- [x] 3.3 When confirmed, run `openspec workspace update` for the current workspace instead of repo-local `openspec update`.
-- [x] 3.4 When declined, report that global config changed and that `openspec workspace update` applies it later.
-- [x] 3.5 Preserve existing repo-local `openspec config profile` apply behavior outside workspaces.
-- [x] 3.6 Keep `openspec config profile core` non-interactive, but print workspace-specific `openspec workspace update` guidance when run inside a workspace.
-- [x] 3.7 Warn on no-op config profile inside a workspace when workspace-local skills drift from the active global profile.
-- [x] 3.8 Manually run `openspec config profile` inside a workspace for confirm, decline, no-op, drift-warning, and `core` preset paths.
-- [x] 3.9 Review the config-profile UX: prompt wording, project/workspace distinction, no-op behavior, preset guidance, and follow-up guidance are clear.
-
-## Phase 4: Workspace Change Creation
-
-User-testable outcome: A user can create a workspace-level change from the coordination root, inspect its workspace planning artifacts, and confirm linked repos were not edited.
-
-- [x] 4.1 Add a built-in `workspace-planning` schema and templates that keep the normal proposal/specs/design/tasks artifact shape.
-- [x] 4.2 Define the workspace-planning specs artifact with nested `specs/**/*.md` output support and instructions for `specs/<area-or-repo>/<capability>/spec.md`.
-- [x] 4.3 Add workspace-aware change creation from the workspace coordination root.
-- [x] 4.4 Default workspace-scoped change creation to the `workspace-planning` schema.
-- [x] 4.5 Store workspace-level changes under the workspace planning path rather than under linked repos or folders.
-- [x] 4.6 Capture the product goal once at the workspace change level.
-- [x] 4.7 Record or validate affected area names through workspace-scoped specs or task sections using registered workspace link names where applicable.
-- [x] 4.8 Ensure creating a workspace change does not create repo-local OpenSpec artifacts or edit linked repos.
-- [x] 4.9 Preserve repo-local change creation behavior outside workspaces.
-- [x] 4.10 Manually create a workspace change from a coordination root and verify the generated artifacts, workspace-scoped specs/tasks, affected areas, and untouched linked repos.
-- [x] 4.11 Review the change creation UX: goal capture, affected-area identification, artifact paths, and next-step guidance feel clear.
-
-## Phase 5: Planning Home And Agent Context
-
-User-testable outcome: A user can run status and instructions for repo-local and workspace changes and see the resolved planning home, artifact paths, affected areas, constraints, and next steps.
-
-- [x] 5.1 Introduce a shared planning-home resolver that identifies repo-local versus workspace planning homes.
-- [x] 5.2 Enrich `openspec status --change <id> --json` with planning home, change root, relevant artifact paths, affected areas, next steps, and action context.
-- [x] 5.3 Enrich `openspec instructions <artifact> --change <id> --json` with resolved artifact paths for repo-local and workspace-scoped changes.
-- [x] 5.4 Keep workspace-level planning as the source of truth until an explicit implementation workflow selects an affected area.
-- [x] 5.5 Preserve nested workspace spec paths in status and instructions output without flattening them into repo-local capability paths.
-- [x] 5.6 Manually run status and instructions for both repo-local and workspace-scoped changes and verify paths and action context are correct.
-- [x] 5.7 Review the planning-context UX: human output, JSON field names, and next-step guidance are easy for users and agents to follow.
-
-## Phase 6: Workflow Skill Instructions
-
-User-testable outcome: A user can inspect regenerated workflow skills and verify they are path-agnostic and tell agents to use CLI-reported artifact paths.
-
-- [x] 6.1 Update generated workflow skill templates to run `openspec status --change <id> --json` before artifact work and trust returned planning context.
-- [x] 6.2 Update generated workflow skill templates to run `openspec instructions <artifact> --change <id> --json` before writing artifacts and use the resolved output path.
-- [x] 6.3 Audit source workflow templates for hardcoded `openspec/changes/<name>` assumptions and replace them with CLI-reported path guidance.
-- [x] 6.4 Keep a separate artifact-context command out of this slice unless enriched status/instructions prove insufficient during implementation.
-- [x] 6.5 Manually regenerate or inspect installed workflow skills and verify they follow CLI-reported artifact paths in a workspace change.
-- [x] 6.6 Guard profile-selected workflow skills whose workspace behavior is not implemented yet so they do not fall back to repo-local paths or edit linked repos.
-- [x] 6.7 Review the agent-instruction UX: instructions are concise, path-agnostic, safe for unsupported workspace workflows, and practical for both repo-local and workspace planning.
-
-## Phase 7: Verification
-
-User-testable outcome: A user or reviewer can run the full manual checklist from a clean workspace and compare expected versus actual evidence for every earlier phase.
-
-- [x] 7.1 Add tests that workspace setup installs skills in the workspace root and leaves linked repos unchanged.
-- [x] 7.2 Add tests that workspace update refreshes, adds, and removes only managed workspace skill directories.
-- [x] 7.3 Add tests that workspace setup/update use the current global profile for workflow skill selection while keeping workspace delivery skills-only.
-- [x] 7.4 Add tests that `openspec config profile` inside a workspace can apply changes through `openspec workspace update`.
-- [x] 7.5 Add tests for stored workspace skill agent selection, omitted-`--tools` behavior, and profile drift reporting.
-- [x] 7.6 Add tests that `openspec update` from a workspace planning home redirects to `openspec workspace update`.
-- [x] 7.7 Add tests that unsupported workspace workflow skills are guarded and do not instruct repo-local fallback edits.
-- [x] 7.8 Add tests that registered repos are visible before change creation.
-- [x] 7.9 Add tests that workspace change creation does not imply repo-local artifact creation.
-- [x] 7.10 Add tests that the workspace-planning schema resolves nested `specs/<area-or-repo>/<capability>/spec.md` files as workspace-scoped specs.
-- [x] 7.11 Add cross-platform path tests for workspace-root skill paths and workspace change paths.
-- [x] 7.12 Update CLI docs, command help, and shell completion coverage for `workspace update`, `--tools`, profile behavior, and workspace skills-only delivery.
-- [x] 7.13 Run `openspec validate workspace-change-planning --strict`.
-- [x] 7.14 Run the full manual acceptance checklist across setup, update, config profile, change creation, planning context, and workflow skills before marking the change complete.
-- [x] 7.15 Complete a final UX review across the whole workflow and record any follow-up fixes or intentional deferrals.
-- [x] 7.16 Before implementation sign-off, record the manual commands or interaction paths, expected observations, and actual observations for each phase.
-- [x] 7.17 Have a separate reviewer or fresh agent context rerun the manual acceptance and UX checklist when available; otherwise rerun it from a clean temporary workspace and report the evidence.
-
-## Verification Evidence
-
-Completion evidence was recorded on 2026-05-14.
-
-Automated checks:
-
-```bash
-pnpm run build
-pnpm vitest run test/commands/workspace.test.ts test/commands/artifact-workflow.test.ts test/core/workspace/skills.test.ts test/core/planning-home.test.ts test/core/templates/skill-templates-parity.test.ts
-node dist/cli/index.js validate workspace-change-planning --strict
-git diff --check
-```
-
-Clean workspace rerun covered non-interactive workspace setup, workspace doctor, config profile update guidance, workspace update redirection, workspace change creation with `--areas api,web`, status/instructions JSON for nested workspace specs, linked repo cleanliness, and guarded unsupported workflow skills.
-
-Observed results:
-
-- Build, targeted tests, strict validation, and whitespace checks passed.
-- Workspace setup/update generated skills only in the workspace root and left linked repos untouched.
-- Workspace change creation used schema `workspace-planning`, reported affected areas `api` and `web`, preserved nested `specs/api/login/spec.md`, and kept `actionContext.allowedEditRoots` empty during planning.
-- Generated workflow skills used CLI-reported paths and workspace guards rather than hardcoded `openspec/changes/<name>` paths.
-- Fresh-agent rerun was not available; the clean temporary workspace rerun served as the fallback independent acceptance pass.

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

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

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

@@ -1,48 +0,0 @@
-## Context
-
-The OpenCode adapter in `src/core/command-generation/adapters/opencode.ts` currently generates command files at `.opencode/command/opsx-<id>.md` (singular `command`). OpenCode's official documentation uses `.opencode/commands/` (plural), and every other adapter in the codebase follows the plural convention for commands directories. The legacy cleanup module in `src/core/legacy-cleanup.ts` also references the singular form for detecting old artifacts.
-
-## Goals / Non-Goals
-
-**Goals:**
-- Align the OpenCode adapter path with OpenCode's official `.opencode/commands/` convention
-- Add the old singular path `.opencode/command/` to legacy cleanup so existing installations are properly cleaned
-- Update documentation to reflect the corrected path
-- Update test assertions to match the new path
-
-**Non-Goals:**
-- Changing the OpenCode skill path (`.opencode/skills/`) — already correct
-- Modifying any other adapter's directory structure
-- Adding migration prompts or interactive upgrade flows
-
-## Decisions
-
-### 1. Direct path rename in adapter
-
-**Decision:** Change `path.join('.opencode', 'command', ...)` to `path.join('.opencode', 'commands', ...)` in the adapter's `getFilePath` method.
-
-**Rationale:** This is a single-line change that aligns with the established pattern across all other adapters. No abstraction or indirection needed.
-
-**Alternatives considered:**
-- Add a configuration option for the directory name — rejected as over-engineering for a bug fix
-- Keep singular and add plural as alias — rejected as it creates ambiguity about which is canonical
-
-### 2. Legacy cleanup via existing constant map
-
-**Decision:** Update the `LEGACY_SLASH_COMMAND_PATHS` entry for `'opencode'` from `'.opencode/command/openspec-*.md'` to `'.opencode/command/opsx-*.md'` (the old singular path becomes the legacy pattern) and ensure the new path is handled by the current command generation pipeline.
-
-**Rationale:** The existing legacy cleanup infrastructure uses `LEGACY_SLASH_COMMAND_PATHS` as an explicit lookup. The old singular-path pattern already matches the legacy format (`openspec-*` prefix from the old SlashCommandRegistry era). The current command generation uses the `opsx-*` prefix, so we also need to add a legacy pattern for `opsx-*` files in the old singular directory.
-
-**Alternatives considered:**
-- Add a separate migration script — rejected; the existing legacy cleanup mechanism handles this scenario
-
-### 3. Documentation update
-
-**Decision:** Update the `docs/supported-tools.md` table entry for OpenCode from `.opencode/command/opsx-<id>.md` to `.opencode/commands/opsx-<id>.md`.
-
-**Rationale:** Documentation must match the actual generated paths.
-
-## Risks / Trade-offs
-
-- **[Existing installations have files at old path]** → Mitigated by legacy cleanup detecting `.opencode/command/` artifacts. On next `openspec init`, old files are cleaned up and new files written to `.opencode/commands/`.
-- **[Users referencing old path in custom scripts]** → Low risk. The old path was incorrect per OpenCode's specification, so custom references were already misaligned.

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

@@ -1,26 +0,0 @@
-## Why
-
-The OpenCode adapter uses `.opencode/command/` (singular) for its commands directory, but OpenCode's official documentation specifies `.opencode/commands/` (plural). Every other adapter in the codebase also uses plural directory names (`.claude/commands/`, `.cursor/commands/`, `.factory/commands/`, etc.). This inconsistency was introduced in Oct 2025 without documented rationale. Fixes [#748](https://github.com/Fission-AI/OpenSpec/issues/748).
-
-## What Changes
-
-- OpenCode adapter path changes from `.opencode/command/` to `.opencode/commands/`
-- Legacy cleanup adds `.opencode/command/` (old singular path) for backward compatibility
-- Documentation updated to reflect the new plural path
-
-## Capabilities
-
-### New Capabilities
-
-_None._
-
-### Modified Capabilities
-
-- `command-generation`: OpenCode adapter path changes from singular `command/` to plural `commands/` to match OpenCode's official directory convention
-
-## Impact
-
-- `src/core/command-generation/adapters/opencode.ts` — adapter path
-- `src/core/legacy-cleanup.ts` — legacy cleanup pattern + add old singular path
-- `docs/supported-tools.md` — documentation table
-- `test/core/command-generation/adapters.test.ts` — test assertion