sauron-cli 1.3.0 → 1.4.1

package/OpenSpec-main/openspec/specs/workspace-links/spec.md

@@ -1,529 +0,0 @@
-# workspace-links Specification
-
-## Purpose
-Define the direct workspace setup, discovery, linking, relinking, health check,
-and JSON-output behavior for managing OpenSpec workspaces across repos and
-folders.
-## Requirements
-### Requirement: Guided Workspace Setup
-OpenSpec SHALL provide a guided setup flow for users starting workspace planning.
-
-#### Scenario: Creating a workspace through setup
-- **WHEN** a user runs `openspec workspace setup`
-- **THEN** OpenSpec SHALL guide the user through creating an OpenSpec workspace
-- **AND** the workspace SHALL use the standard workspace location from the workspace foundation
-
-#### Scenario: Asking for the workspace name first
-- **WHEN** interactive setup starts
-- **THEN** OpenSpec SHALL ask for the workspace name before asking for repos or folders
-- **AND** workspace names SHALL use kebab-case with lowercase letters, numbers, and hyphens
-
-#### Scenario: Retrying an invalid workspace name during setup
-- **WHEN** an interactive user enters an invalid workspace name
-- **THEN** OpenSpec SHALL explain that workspace names must be kebab-case
-- **AND** it SHALL let the user enter another workspace name before continuing setup
-
-#### Scenario: Linking a required first repo or folder
-- **WHEN** setup asks for repos or folders
-- **THEN** the user SHALL provide at least one existing repo or folder path
-- **AND** setup SHALL not finish successfully until at least one path is linked
-
-#### Scenario: Inferring link names during setup
-- **WHEN** the user provides a repo or folder path during setup
-- **THEN** OpenSpec SHALL infer the link name from the folder basename
-- **AND** it SHALL ask for a different name only when the inferred name conflicts
-
-#### Scenario: Handling inferred link name conflicts during setup
-- **GIVEN** setup infers a link name that already exists in the workspace
-- **WHEN** setup is interactive
-- **THEN** OpenSpec SHALL show the conflicting link name and the existing path for that link
-- **AND** it SHALL ask the user for a different link name before continuing
-
-#### Scenario: Preserving folder-style link names
-- **WHEN** OpenSpec accepts a workspace link name
-- **THEN** it SHALL allow folder-style names that are valid under the workspace foundation link-name rules
-- **AND** it SHALL not require link names to use the stricter workspace-name kebab-case rule
-
-#### Scenario: Adding multiple repos or folders during setup
-- **WHEN** setup links a repo or folder
-- **THEN** OpenSpec SHALL let the user add another repo or folder with a simple repeated prompt
-- **AND** each linked path SHALL be recorded without editing the target repo or folder
-
-#### Scenario: Storing verified absolute paths during setup
-- **WHEN** setup links a repo or folder path
-- **THEN** OpenSpec SHALL verify that the path resolves to an existing folder
-- **AND** it SHALL store an absolute runtime-local path in machine-local state instead of the raw user input
-- **AND** relative inputs SHALL be resolved against the command's current working directory
-
-#### Scenario: Preserving equals signs in setup link paths
-- **WHEN** non-interactive setup receives a `--link` value that resolves to an existing folder and contains `=`
-- **THEN** OpenSpec SHALL treat the full value as the path
-- **AND** it SHALL infer the link name from the folder basename
-- **AND** explicit `--link <name>=<path>` inputs SHALL preserve `=` characters inside `<path>`
-
-#### Scenario: Running setup with non-interactive inputs
-- **WHEN** `openspec workspace setup --no-interactive` receives a workspace name and at least one valid link
-- **THEN** OpenSpec SHALL create the workspace without prompts
-- **AND** it SHALL support repeated `--link` values
-
-#### Scenario: Non-interactive setup duplicate link names
-- **WHEN** `openspec workspace setup --no-interactive` receives two links with the same inferred or explicit name
-- **THEN** OpenSpec SHALL fail with a clear duplicate link-name error
-- **AND** the error SHALL show the conflicting link name and the first path using that name
-- **AND** it SHALL suggest using explicit `--link <name>=<path>` values with different names
-
-#### Scenario: Missing non-interactive setup inputs
-- **WHEN** `openspec workspace setup --no-interactive` is missing a workspace name or link
-- **THEN** OpenSpec SHALL fail with a clear message
-- **AND** it SHALL explain which flags are required
-
-#### Scenario: Finishing setup
-- **WHEN** setup finishes
-- **THEN** OpenSpec SHALL show the workspace location, planning path, and linked repos or folders
-- **AND** it SHALL check what the current machine can resolve
-
-#### Scenario: Recording created workspaces locally
-- **WHEN** setup creates a workspace
-- **THEN** OpenSpec SHALL record it in the local workspace registry
-- **AND** the workspace folder SHALL remain the source of truth for workspace state
-
-#### Scenario: Reusing an existing workspace name during setup
-- **GIVEN** a managed workspace already exists with the requested name
-- **WHEN** a user runs setup with that workspace name
-- **THEN** OpenSpec SHALL explain that the workspace already exists
-- **AND** it SHALL not overwrite the existing workspace
-
-### Requirement: Workspace Discovery
-OpenSpec SHALL let users see the OpenSpec-managed workspaces available on the current machine.
-
-#### Scenario: Listing workspaces
-- **WHEN** a user runs `openspec workspace list`
-- **THEN** OpenSpec SHALL list known managed workspaces
-- **AND** each workspace SHALL include the workspace name, workspace location, and linked repos or folders
-
-#### Scenario: Using the short list command
-- **WHEN** a user runs `openspec workspace ls`
-- **THEN** OpenSpec SHALL behave the same as `openspec workspace list`
-
-#### Scenario: Listing when no workspaces exist
-- **WHEN** a user runs `openspec workspace list`
-- **AND** no managed workspaces exist
-- **THEN** OpenSpec SHALL say that no workspaces were found
-- **AND** it SHALL show the user how to create one
-
-#### Scenario: Listing stale registry entries
-- **WHEN** the local registry contains a workspace location that no longer exists
-- **THEN** `workspace list` SHALL report the stale workspace entry
-- **AND** it SHALL avoid silently deleting registry state
-- **AND** it SHALL avoid rewriting or repairing registry state automatically
-
-#### Scenario: Avoiding registry cleanup commands
-- **WHEN** users inspect stale workspace registry entries in this slice
-- **THEN** OpenSpec SHALL treat stale entries as report-only diagnostics
-- **AND** it SHALL not expose a registry cleanup command such as `workspace forget`
-
-### Requirement: Global Workspace Commands
-OpenSpec SHALL let workspace commands run from outside workspace directories.
-
-#### Scenario: Selecting a workspace by flag
-- **WHEN** a command that needs one workspace receives `--workspace <name>`
-- **THEN** OpenSpec SHALL use that workspace from the local registry
-- **AND** it SHALL fail clearly if the workspace name is unknown
-
-#### Scenario: Using the current workspace
-- **GIVEN** the command runs from a workspace folder or subdirectory
-- **WHEN** the command needs one workspace and no `--workspace` flag is provided
-- **THEN** OpenSpec SHALL use the current workspace
-
-#### Scenario: Using an unregistered current workspace
-- **GIVEN** the command runs from a valid workspace folder or subdirectory
-- **AND** that workspace is not recorded in the local workspace registry
-- **WHEN** the command needs one workspace and no `--workspace <name>` flag is provided
-- **THEN** OpenSpec SHALL use the current workspace
-- **AND** it SHALL include a non-fatal warning status with code `workspace_not_in_local_registry`
-- **AND** the warning SHALL explain how the user can get the workspace recorded locally
-
-#### Scenario: Recording an unregistered current workspace after mutation
-- **GIVEN** a mutating workspace command uses a valid current workspace that is not recorded in the local workspace registry
-- **WHEN** `workspace link` or `workspace relink` succeeds
-- **THEN** OpenSpec SHALL record the workspace name and location in the local workspace registry
-
-#### Scenario: Doctor does not register current workspaces
-- **GIVEN** `workspace doctor` uses a valid current workspace that is not recorded in the local workspace registry
-- **WHEN** doctor finishes
-- **THEN** OpenSpec SHALL report the non-fatal registry warning
-- **AND** it SHALL not write registry state
-
-#### Scenario: Picking from multiple workspaces
-- **GIVEN** multiple known workspaces exist
-- **WHEN** an interactive command needs one workspace and none is specified
-- **THEN** OpenSpec SHALL show a workspace picker
-- **AND** the picker SHALL include workspace names and paths
-
-#### Scenario: Ambiguous non-interactive workspace selection
-- **GIVEN** multiple known workspaces exist
-- **WHEN** a non-interactive command needs one workspace and none is specified
-- **THEN** OpenSpec SHALL fail with a clear message
-- **AND** it SHALL suggest passing `--workspace <name>`
-
-#### Scenario: Ambiguous JSON workspace selection
-- **GIVEN** multiple known workspaces exist
-- **WHEN** a command running with `--json` needs one workspace and none is specified
-- **THEN** OpenSpec SHALL fail without showing a picker
-- **AND** it SHALL emit a structured status error
-- **AND** it SHALL suggest passing `--workspace <name>`
-
-#### Scenario: No known workspaces for a command that needs one
-- **GIVEN** no known workspaces exist in the local registry
-- **AND** the command is not running from a workspace folder or subdirectory
-- **WHEN** `workspace link`, `workspace relink`, `workspace doctor`, or another command that needs one workspace runs without `--workspace <name>`
-- **THEN** OpenSpec SHALL fail without showing a picker regardless of interactive mode
-- **AND** it SHALL print `No known OpenSpec workspaces. Run 'openspec workspace setup' first.`
-- **AND** it SHALL explain that `--workspace <name>` can be used after at least one workspace is known locally
-
-### Requirement: Workspace Links
-OpenSpec SHALL let users link existing repos or folders to a workspace before creating a change.
-
-#### Scenario: Linking with an inferred name
-- **WHEN** a user runs `openspec workspace link <path>`
-- **THEN** OpenSpec SHALL infer the link name from the folder basename
-- **AND** it SHALL store the verified absolute local path as machine-local state
-
-#### Scenario: Linking with an explicit name
-- **WHEN** a user runs `openspec workspace link <name> <path>`
-- **THEN** OpenSpec SHALL use the explicit link name for planning
-- **AND** it SHALL store the verified absolute local path as machine-local state
-
-#### Scenario: Requiring an existing path
-- **WHEN** a user links a repo or folder path
-- **THEN** the path SHALL exist on the current machine
-- **AND** OpenSpec SHALL reject missing paths with a clear message
-
-#### Scenario: Resolving linked paths before storage
-- **WHEN** a user links a repo or folder path
-- **THEN** OpenSpec SHALL store the verified absolute path for the current runtime
-- **AND** relative inputs SHALL be resolved against the command's current working directory
-- **AND** OpenSpec SHALL not translate paths between native Windows, WSL2, and Unix runtimes
-
-#### Scenario: Linking a monorepo folder
-- **WHEN** a user links a package, service, app, or directory inside a monorepo
-- **THEN** OpenSpec SHALL store it as a workspace link
-- **AND** it SHALL not require that folder to have its own repo-local `openspec/` directory
-
-#### Scenario: Linking without repo-local OpenSpec
-- **WHEN** a user links a path that does not contain repo-local OpenSpec state
-- **THEN** OpenSpec SHALL keep that repo or folder available for workspace planning
-- **AND** it SHALL not treat missing repo-local OpenSpec state as a link failure
-
-#### Scenario: Link records only
-- **WHEN** a user links a repo or folder
-- **THEN** OpenSpec SHALL record workspace state and local path state
-- **AND** it SHALL not create, copy, move, initialize, or edit files in the linked repo or folder
-
-#### Scenario: Blocking link when local state is invalid
-- **GIVEN** the workspace machine-local state file exists but cannot be parsed or validated
-- **WHEN** a user runs `openspec workspace link`
-- **THEN** OpenSpec SHALL fail with status code `workspace_local_state_invalid`
-- **AND** it SHALL not rewrite shared workspace state or machine-local path state
-
-#### Scenario: Reusing a link name
-- **GIVEN** a workspace already has a link with a given name
-- **WHEN** a user tries to link another path with the same name
-- **THEN** OpenSpec SHALL explain that the link name is already in use by another link
-- **AND** it SHALL show the existing link name and existing path
-- **AND** it SHALL suggest choosing a different link name
-- **AND** it SHALL suggest `workspace relink <name> <path>` when the user intended to change the existing link path
-- **AND** it SHALL preserve the existing link unless the user explicitly relinks it
-
-### Requirement: Workspace Relinks
-OpenSpec SHALL let users update existing link paths without recreating the workspace.
-
-#### Scenario: Updating a local path
-- **GIVEN** a workspace has a link
-- **WHEN** a user runs `openspec workspace relink <name> <path>`
-- **THEN** OpenSpec SHALL keep the stable link name
-- **AND** it SHALL update the machine-local path for the current machine to the verified absolute path
-
-#### Scenario: Requiring an existing relink path
-- **WHEN** a user relinks to a new path
-- **THEN** the new path SHALL exist on the current machine
-- **AND** OpenSpec SHALL reject missing paths with a clear message
-
-#### Scenario: Resolving relink paths before storage
-- **WHEN** a user relinks to a new path
-- **THEN** OpenSpec SHALL store the verified absolute path for the current runtime
-- **AND** relative inputs SHALL be resolved against the command's current working directory
-
-#### Scenario: Blocking relink when local state is invalid
-- **GIVEN** the workspace machine-local state file exists but cannot be parsed or validated
-- **WHEN** a user runs `openspec workspace relink`
-- **THEN** OpenSpec SHALL fail with status code `workspace_local_state_invalid`
-- **AND** it SHALL not rewrite machine-local path state
-
-#### Scenario: Updating an unknown link
-- **WHEN** a user tries to relink a link that does not exist
-- **THEN** OpenSpec SHALL explain that the link name is unknown
-- **AND** it SHALL preserve existing workspace state
-
-#### Scenario: Avoiding owner and handoff fields
-- **WHEN** users link or relink repos or folders in this slice
-- **THEN** OpenSpec SHALL not ask for owner or handoff metadata
-- **AND** link maintenance SHALL focus on names and local paths
-
-### Requirement: Workspace Health Check
-OpenSpec SHALL explain what the current machine can resolve for a workspace.
-
-#### Scenario: Doctor checks one selected workspace
-- **WHEN** a user runs `openspec workspace doctor`
-- **THEN** OpenSpec SHALL inspect one selected workspace
-- **AND** it SHALL not scan every known workspace in the local registry by default
-
-#### Scenario: Doctor infers the current workspace
-- **GIVEN** the command runs from a workspace folder or subdirectory
-- **WHEN** the user runs `openspec workspace doctor` without `--workspace <name>`
-- **THEN** OpenSpec SHALL inspect the current workspace
-
-#### Scenario: Checking a healthy workspace
-- **WHEN** a user runs `openspec workspace doctor`
-- **THEN** OpenSpec SHALL show the workspace location and workspace planning path
-- **AND** it SHALL show linked repos or folders and which paths resolve on the current machine
-
-#### Scenario: Selected workspace location is missing
-- **GIVEN** the selected workspace comes from the local registry
-- **AND** the registered workspace location is missing or invalid
-- **WHEN** a user runs `openspec workspace doctor`
-- **THEN** OpenSpec SHALL report a selected-workspace status error
-- **AND** it SHALL not attempt to inspect links for that workspace
-
-#### Scenario: Reporting repo-local specs paths
-- **WHEN** a linked repo or folder resolves
-- **THEN** doctor SHALL report `repo_specs_path` when repo-local `openspec/specs` exists
-- **AND** it SHALL report `repo_specs_path: null` when repo-local specs are not present
-
-#### Scenario: Checking missing paths
-- **WHEN** a link points to a path that is missing on the current machine
-- **THEN** doctor SHALL identify the affected link name
-- **AND** it SHALL include a suggested `workspace relink` fix
-
-#### Scenario: Checking shared and local state drift
-- **WHEN** shared workspace state and machine-local path state do not agree
-- **THEN** doctor SHALL explain which link names are affected
-- **AND** it SHALL distinguish shared workspace links from local-only paths
-
-#### Scenario: Reporting invalid local state
-- **WHEN** list or doctor reads a workspace whose machine-local state file cannot be parsed or validated
-- **THEN** OpenSpec SHALL report status code `workspace_local_state_invalid`
-- **AND** it SHALL avoid treating the invalid local state as an empty path map for mutation or repair suggestions
-- **AND** it SHALL not rewrite workspace registry state or machine-local path state
-
-#### Scenario: Reporting without auto-repair
-- **WHEN** doctor finds issues
-- **THEN** it SHALL report all issues it can find
-- **AND** it SHALL not automatically repair workspace state
-
-#### Scenario: Using readable human output
-- **WHEN** doctor prints human output
-- **THEN** it SHALL show a readable workspace summary, linked repos or folders, and issues when present
-- **AND** it SHALL avoid printing raw JSON or relying on a rigid YAML dump as the default human experience
-
-### Requirement: Scriptable Workspace Setup Commands
-OpenSpec SHALL provide JSON output for direct workspace setup commands.
-
-#### Scenario: Requesting JSON output
-- **WHEN** a user passes `--json` to direct workspace setup commands
-- **THEN** OpenSpec SHALL print machine-readable output
-- **AND** the output SHALL avoid extra human-readable text
-- **AND** the output SHALL separate primary objects from structured `status` entries
-
-#### Scenario: Setup JSON requires non-interactive setup
-- **WHEN** a user runs `openspec workspace setup --json` without `--no-interactive`
-- **THEN** OpenSpec SHALL fail clearly
-- **AND** it SHALL explain that `workspace setup --json` requires `--no-interactive`
-
-#### Scenario: JSON output disables prompts
-- **WHEN** a direct workspace setup command runs with `--json`
-- **THEN** OpenSpec SHALL avoid interactive prompts
-- **AND** it SHALL fail with structured status output when required choices are ambiguous
-
-#### Scenario: JSON status entry shape
-- **WHEN** a direct workspace setup command reports warnings, errors, or suggested fixes in JSON output
-- **THEN** each status entry SHALL include a stable `code`, a `severity`, and a human-readable `message`
-- **AND** status entries MAY include `target` and `fix` fields when a specific object field or suggested command is useful
-
-#### Scenario: JSON object status shape
-- **WHEN** a direct workspace setup command emits JSON for workspace, link, or list objects
-- **THEN** each object MAY include a `status` array for object-specific warnings or errors
-- **AND** the top-level response SHALL include a `status` array for command-level warnings or errors
-- **AND** healthy objects and healthy responses SHALL use an empty `status` array
-
-#### Scenario: Commands with JSON output
-- **WHEN** users run `workspace setup --no-interactive`, `workspace list`, `workspace link`, `workspace relink`, or `workspace doctor`
-- **THEN** each command SHALL support JSON output
-
-### 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: Identifying managed workflow skill directories
-- **WHEN** workspace update evaluates a workflow skill directory for removal
-- **THEN** OpenSpec SHALL treat it as OpenSpec-managed only when the directory name matches a known generated workflow skill directory and its `SKILL.md` contains OpenSpec generated metadata
-- **AND** generated metadata SHALL include the `generatedBy` marker written by OpenSpec skill generation
-- **AND** OpenSpec SHALL not remove directories that are missing the generated metadata, even when their names match known workflow skill directory names
-
-#### 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`