sauron-cli 1.3.0 → 1.4.0

package/OpenSpec-main/openspec/initiatives/context-store-and-initiatives/work-items/18-explore-initiative-hosted-target-bound-change-artifacts/tasks.md

@@ -1,28 +0,0 @@
-# Explore Initiative-Hosted Target-Bound Change Artifacts Tasks
-
-- [x] Create Item 18 work-item tracking notes.
-- [x] Reframe Item 18 from generic change-home configuration to
-  initiative-hosted target-bound change artifacts.
-- [ ] Audit commands, templates, validation, archive, apply, completion, and
-  docs for repo-local `openspec/changes/` assumptions.
-- [ ] Define user-facing naming for initiative work items, briefs,
-  target-bound changes, artifact homes, and editable targets.
-- [ ] Decide whether initiative-hosted artifacts can graduate into executable
-  changes, and which target metadata is required first.
-- [ ] Decide the configuration or opt-in surface for repo-local versus
-  initiative-hosted artifacts.
-- [ ] Define how `openspec new change` selects and reports the artifact home,
-  implementation target, initiative link, and action context.
-- [ ] Define how initiative linking and workspace guidance discover artifact
-  homes and target repo mappings.
-- [ ] Decide how initiative-hosted target-bound changes bind to repo specs,
-  implementation roots, branches, and local checkout paths.
-- [ ] Decide validation, apply, archive, sync, and conflict behavior for
-  initiative-hosted target-bound changes.
-- [ ] Define the agent JSON contract for work target, artifact home,
-  implementation target, allowed edit roots, unsupported lifecycle commands, and
-  next commands.
-- [ ] Record compatibility behavior for existing repo-local and workspace-local
-  changes.
-- [ ] Produce a recommendation, opt-in/config examples, affected command list,
-  and go/no-go criteria for implementation.

package/OpenSpec-main/openspec/initiatives/context-store-and-initiatives/work-items/19-review-workspace-beta-compatibility-before-public-release/plan.md

@@ -1,62 +0,0 @@
-# Review Workspace Beta Compatibility Before Public Release
-
-## Goal
-
-Before workspaces become public/stable, decide what beta workspace
-compatibility behavior is actually worth carrying forward.
-
-This is intentionally late-stage work. Workspaces have not been publicly
-released yet, so unpublished beta internals should not automatically become a
-permanent compatibility contract.
-
-## Background
-
-The beta currently contains a few compatibility paths:
-
-- Legacy split workspace state readers for `.openspec-workspace/workspace.yaml`
-  and `.openspec-workspace/local.yaml`.
-- Managed workspace registry fallback behavior.
-- `codex` to `codex-cli` opener normalization.
-- Generated `.gitignore` cleanup for old workspace `.code-workspace` ignore
-  rules.
-- Empty or deprecated helper shims that exist only because previous workspace
-  slices exposed them internally.
-
-Some of these may be useful for local beta testers. Others may be safer to
-delete before public release.
-
-## Scope
-
-Review workspace compatibility only. Do not use this item to reopen unrelated
-legacy migration systems such as old slash-command cleanup, telemetry config
-migration, or deprecated `change`/`spec` command aliases.
-
-## Decisions To Make
-
-- Which workspace compatibility paths are part of the public contract?
-- Which paths are beta-only migration helpers and can be removed after one
-  release note or cleanup pass?
-- Which paths are only test compatibility and can be deleted before release?
-- Should beta workspace roots be migrated automatically, left readable, or
-  intentionally unsupported?
-- Should old generated `.gitignore` cleanup exist at all, given workspaces are
-  managed local folders rather than repos?
-
-## Implementation Notes
-
-- Prefer deletion over preserving compatibility for unpublished intermediate
-  beta states.
-- If a compatibility path remains, document why it exists and what would allow
-  it to be removed later.
-- Keep user-owned files safe. Do not clean or rewrite ambiguous local files
-  unless OpenSpec can prove it owns them.
-- Update tests so they describe the chosen public contract rather than the
-  accidental beta history.
-
-## Done When
-
-- Workspace compatibility code is inventoried and classified.
-- Low-value beta-only shims are removed.
-- Remaining compatibility behavior has focused tests and release-note language.
-- Public docs and generated agent guidance do not mention unsupported beta
-  internals.

package/OpenSpec-main/openspec/initiatives/context-store-and-initiatives/work-items/19-review-workspace-beta-compatibility-before-public-release/tasks.md

@@ -1,16 +0,0 @@
-# Tasks
-
-- [ ] Inventory workspace compatibility code paths and tests.
-- [ ] Classify each path as public contract, beta migration, test-only shim, or
-  removable dead weight.
-- [ ] Decide whether legacy split workspace state remains readable after public
-  release.
-- [ ] Decide whether old generated `.gitignore` cleanup should remain, become
-  more conservative, or be removed entirely.
-- [ ] Decide how long `codex` should remain accepted as an alias for
-  `codex-cli`.
-- [ ] Remove beta-only compatibility paths that do not need to survive public
-  release.
-- [ ] Update tests to encode the chosen compatibility contract.
-- [ ] Update docs, generated guidance, and release notes with the final public
-  behavior.

package/OpenSpec-main/openspec/initiatives/context-store-and-initiatives/work-items/proposed-initiative-next-agent-handoff-ux/evidence.md

@@ -1,47 +0,0 @@
-# Proposed Initiative Next / Agent Handoff UX Evidence
-
-## Source
-
-This discussion item came from the GSD workspace comparison.
-
-GSD's useful lesson was not its storage model. It was the simple user loop:
-create context, move to the next concrete step, and keep the agent from guessing
-where it is in the workflow.
-
-OpenSpec should keep the current boundary:
-
-```text
-Context stores sync truth.
-Initiatives coordinate work.
-Workspaces open local views.
-Changes implement repo-owned slices.
-```
-
-The possible gap is that `initiative show`, repo-local change linking, and
-workspace opening may still require an agent to stitch together the next action
-by hand.
-
-## Current Recommendation
-
-Keep this as a discussion draft until workspace initiative opening is clearer.
-If accepted, the first version should be a small handoff/readiness command, not
-status, progress, dashboarding, or workspace orchestration.
-
-## Manual Beta Pass Addition
-
-The 2026-05-28 manual beta pass found that command-level handoff is not the
-only missing layer. A fresh agent also needs a small, tool-readable guide for
-how to use OpenSpec at all:
-
-- inspect context stores, initiatives, workspaces, and repo-local changes before
-  guessing;
-- understand that context stores can be artifact homes outside implementation
-  repos, not only cross-team coordination spaces;
-- understand that repo-local changes own implementation planning when the user
-  wants artifacts in the repo;
-- treat workspaces as local views, not durable planning homes;
-- route to narrower OpenSpec workflow skills when available.
-
-As a temporary beta aid, a manual Codex skill was created at
-`.codex/skills/use-openspec/` with references for shared context and artifact
-placement. This is not yet productized in the configurator.

package/OpenSpec-main/openspec/initiatives/context-store-and-initiatives/work-items/proposed-initiative-next-agent-handoff-ux/plan.md

@@ -1,90 +0,0 @@
-# Proposed Initiative Next / Agent Handoff UX
-
-## Status
-
-Discussion draft. Not locked into the numbered roadmap yet.
-
-## Why This Exists
-
-The GSD workspace comparison highlighted a UX gap: OpenSpec has increasingly
-good discovery primitives, but agents still need to infer the next useful step
-from several commands.
-
-The candidate idea is a tiny "what now?" handoff command after initiative
-discovery from the current repo or workspace. It should not become a dashboard,
-work-progress status view, or replacement for workspace local-view behavior.
-
-The manual beta pass surfaced a second, related handoff gap: before a command
-like `initiative next` exists, a fresh coding agent still needs baseline
-OpenSpec literacy. It needs to understand context stores, initiatives,
-workspaces, repo-local changes, and where artifacts should live. A small
-`use-openspec` skill may be the simplest first slice.
-
-## Candidate Goal
-
-Help an agent answer:
-
-```text
-What should I do next for this initiative from the current repo or workspace?
-```
-
-## Possible Command Shape
-
-```bash
-openspec initiative next <id> --json
-```
-
-Possible response:
-
-```json
-{
-  "initiative": "billing-launch",
-  "next_action": "create_repo_change",
-  "reason": "initiative found, no linked local change exists for this repo",
-  "suggested_command": "openspec new change add-billing-api --initiative billing-launch"
-}
-```
-
-## Possible Skill Shape
-
-```text
-use-openspec/
-  SKILL.md
-  references/
-    shared-context-beta.md
-    artifact-placement.md
-```
-
-This would be a baseline guide skill, not a workflow action. It should not
-produce `/opsx:use-openspec`, should not appear as an implementation workflow,
-and should not imply that workflow command delivery is unavailable.
-
-Open design question: whether this is literally part of the default profile, a
-separate always-on bundled skill, or a managed guide skill installed by default
-whenever the selected agent supports skills.
-
-## Discussion Points To Review
-
-- Should this become a numbered roadmap item before workspace initiative
-  opening?
-- Is `initiative next` the right command name, or should this guidance live
-  inside workspace initiative opening or repo-local status?
-- Should the command suggest exactly one next action, or return a ranked set of
-  possible actions?
-- Should it inspect actual work progress, or stay limited to handoff readiness?
-- How should it behave when no stores are registered, the initiative is
-  ambiguous, the local repo is unrelated, or linked changes already exist?
-- Should baseline OpenSpec guidance be modeled as a default skill, a profile
-  member, or a separate managed guide?
-- How should the guide skill interact with commands-oriented delivery?
-- How should it teach artifact placement: context-store initiative vs
-  repo-local change vs workspace view?
-
-## Boundaries
-
-- Do not add progress/status semantics in the first version.
-- Do not create changes, clone repos, or mutate workspace state.
-- Do not make workspace opening a prerequisite.
-- Prefer agent-readable JSON over broad interactive UX in the first slice.
-- Do not turn baseline guidance into a new slash command unless a separate
-  workflow need emerges.

package/OpenSpec-main/openspec/initiatives/context-store-and-initiatives/work-items/proposed-initiative-next-agent-handoff-ux/tasks.md

@@ -1,18 +0,0 @@
-# Proposed Initiative Next / Agent Handoff UX Tasks
-
-These are discussion tasks only. Do not implement until the roadmap position and
-scope are confirmed.
-
-- [ ] Decide whether to add this as a numbered roadmap item.
-- [ ] Decide whether the command is `initiative next`, workspace initiative
-  opening guidance, or repo-local status guidance.
-- [ ] Decide the minimal JSON output contract for agent handoff.
-- [ ] Decide whether the command returns one next action or multiple options.
-- [ ] Decide the error and empty-state behavior.
-- [ ] Decide whether actual work progress/status is explicitly out of scope.
-- [ ] Decide whether to ship `use-openspec` as a managed default skill.
-- [ ] Decide whether `use-openspec` is a default-profile member or a separate
-      always-on guide skill.
-- [ ] Decide how `use-openspec` interacts with commands-oriented delivery.
-- [ ] Decide the minimal artifact-placement guidance for context-store
-      initiatives, repo-local changes, and workspace views.

package/OpenSpec-main/openspec/specs/ai-tool-paths/spec.md

@@ -1,63 +0,0 @@
-# ai-tool-paths Specification
-
-## Purpose
-Define AI tool path metadata used to generate OpenSpec skills and commands in tool-specific directories.
-## Requirements
-### Requirement: AIToolOption skillsDir field
-
-The `AIToolOption` interface SHALL include an optional `skillsDir` field for skill generation path configuration.
-
-#### Scenario: Interface includes skillsDir field
-
-- **WHEN** a tool entry is defined in `AI_TOOLS` that supports skill generation
-- **THEN** it SHALL include a `skillsDir` field specifying the project-local base directory (e.g., `.claude`)
-
-#### Scenario: Skills path follows Agent Skills spec
-
-- **WHEN** generating skills for a tool with `skillsDir: '.claude'`
-- **THEN** skills SHALL be written to `<projectRoot>/<skillsDir>/skills/`
-- **AND** the `/skills` suffix is appended per Agent Skills specification
-
-### Requirement: Path configuration for supported tools
-
-The `AI_TOOLS` array SHALL include `skillsDir` for tools that support the Agent Skills specification.
-
-#### Scenario: Claude Code paths defined
-
-- **WHEN** looking up the `claude` tool
-- **THEN** `skillsDir` SHALL be `.claude`
-
-#### Scenario: Cursor paths defined
-
-- **WHEN** looking up the `cursor` tool
-- **THEN** `skillsDir` SHALL be `.cursor`
-
-#### Scenario: Windsurf paths defined
-
-- **WHEN** looking up the `windsurf` tool
-- **THEN** `skillsDir` SHALL be `.windsurf`
-
-#### Scenario: Kimi CLI paths defined
-
-- **WHEN** looking up the `kimi` tool
-- **THEN** `skillsDir` SHALL be `.kimi`
-
-#### Scenario: Tools without skillsDir
-
-- **WHEN** a tool has no `skillsDir` defined
-- **THEN** skill generation SHALL error with message indicating the tool is not supported
-
-### Requirement: Cross-platform path handling
-
-The system SHALL handle paths correctly across operating systems.
-
-#### Scenario: Path construction on Windows
-
-- **WHEN** constructing skill paths on Windows
-- **THEN** the system SHALL use `path.join()` for all path construction
-- **AND** SHALL NOT hardcode forward slashes
-
-#### Scenario: Path construction on Unix
-
-- **WHEN** constructing skill paths on macOS or Linux
-- **THEN** the system SHALL use `path.join()` for consistency

package/OpenSpec-main/openspec/specs/artifact-graph/spec.md

@@ -1,165 +0,0 @@
-# artifact-graph Specification
-
-## Purpose
-Define the artifact graph model, dependency validation, and completion-state logic used by schema-driven workflows.
-## Requirements
-### Requirement: Schema Loading
-The system SHALL load artifact graph definitions from YAML schema files within schema directories.
-
-#### Scenario: Valid schema loaded
-- **WHEN** a schema directory contains a valid `schema.yaml` file
-- **THEN** the system returns an ArtifactGraph with all artifacts and dependencies
-
-#### Scenario: Invalid schema rejected
-- **WHEN** a schema YAML file is missing required fields
-- **THEN** the system throws an error with a descriptive message
-
-#### Scenario: Cyclic dependencies detected
-- **WHEN** a schema contains cyclic artifact dependencies
-- **THEN** the system throws an error listing the artifact IDs in the cycle
-
-#### Scenario: Invalid dependency reference
-- **WHEN** an artifact's `requires` array references a non-existent artifact ID
-- **THEN** the system throws an error identifying the invalid reference
-
-#### Scenario: Duplicate artifact IDs rejected
-- **WHEN** a schema contains multiple artifacts with the same ID
-- **THEN** the system throws an error identifying the duplicate
-
-#### Scenario: Schema directory not found
-- **WHEN** resolving a schema name that has no corresponding directory
-- **THEN** the system throws an error listing available schemas
-
-### Requirement: Build Order Calculation
-The system SHALL compute a valid topological build order for artifacts.
-
-#### Scenario: Linear dependency chain
-- **WHEN** artifacts form a linear chain (A → B → C)
-- **THEN** getBuildOrder() returns [A, B, C]
-
-#### Scenario: Diamond dependency
-- **WHEN** artifacts form a diamond (A → B, A → C, B → D, C → D)
-- **THEN** getBuildOrder() returns A before B and C, and D last
-
-#### Scenario: Independent artifacts
-- **WHEN** artifacts have no dependencies
-- **THEN** getBuildOrder() returns them in a stable order
-
-### Requirement: State Detection
-The system SHALL detect artifact completion state by scanning the filesystem.
-
-#### Scenario: Simple file exists
-- **WHEN** an artifact generates "proposal.md" and the file exists
-- **THEN** the artifact is marked as completed
-
-#### Scenario: Simple file missing
-- **WHEN** an artifact generates "proposal.md" and the file does not exist
-- **THEN** the artifact is not marked as completed
-
-#### Scenario: Glob pattern with files
-- **WHEN** an artifact generates "specs/*.md" and the specs/ directory contains .md files
-- **THEN** the artifact is marked as completed
-
-#### Scenario: Glob pattern empty
-- **WHEN** an artifact generates "specs/*.md" and the specs/ directory is empty or missing
-- **THEN** the artifact is not marked as completed
-
-#### Scenario: Missing change directory
-- **WHEN** the change directory does not exist
-- **THEN** all artifacts are marked as not completed (empty state)
-
-### Requirement: Ready Artifact Query
-The system SHALL identify which artifacts are ready to be created based on dependency completion.
-
-#### Scenario: Root artifacts ready initially
-- **WHEN** no artifacts are completed
-- **THEN** getNextArtifacts() returns artifacts with no dependencies
-
-#### Scenario: Dependent artifact becomes ready
-- **WHEN** an artifact's dependencies are all completed
-- **THEN** getNextArtifacts() includes that artifact
-
-#### Scenario: Blocked artifacts excluded
-- **WHEN** an artifact has uncompleted dependencies
-- **THEN** getNextArtifacts() does not include that artifact
-
-### Requirement: Completion Check
-The system SHALL determine when all artifacts in a graph are complete.
-
-#### Scenario: All complete
-- **WHEN** all artifacts in the graph are in the completed set
-- **THEN** isComplete() returns true
-
-#### Scenario: Partially complete
-- **WHEN** some artifacts in the graph are not completed
-- **THEN** isComplete() returns false
-
-### Requirement: Blocked Query
-The system SHALL identify which artifacts are blocked and return all their unmet dependencies.
-
-#### Scenario: Artifact blocked by single dependency
-- **WHEN** artifact B requires artifact A and A is not complete
-- **THEN** getBlocked() returns `{ B: ['A'] }`
-
-#### Scenario: Artifact blocked by multiple dependencies
-- **WHEN** artifact C requires A and B, and only A is complete
-- **THEN** getBlocked() returns `{ C: ['B'] }`
-
-#### Scenario: Artifact blocked by all dependencies
-- **WHEN** artifact C requires A and B, and neither is complete
-- **THEN** getBlocked() returns `{ C: ['A', 'B'] }`
-
-### Requirement: Schema Directory Structure
-The system SHALL support self-contained schema directories with co-located templates.
-
-#### Scenario: Schema with templates
-- **WHEN** a schema directory contains `schema.yaml` and `templates/` subdirectory
-- **THEN** artifacts can reference templates relative to the schema's templates directory
-
-#### Scenario: User schema override
-- **WHEN** a schema directory exists at `${XDG_DATA_HOME}/openspec/schemas/<name>/`
-- **THEN** the system uses that directory instead of the built-in
-
-#### Scenario: Built-in schema fallback
-- **WHEN** no user override exists for a schema
-- **THEN** the system uses the package built-in schema directory
-
-#### Scenario: List available schemas
-- **WHEN** listing schemas
-- **THEN** the system returns schema names from both user and package directories
-
-### Requirement: Workspace planning schema
-The artifact graph SHALL provide a built-in workspace planning schema for workspace-scoped changes.
-
-#### Scenario: Built-in workspace planning schema is available
-- **WHEN** schemas are resolved from package built-ins
-- **THEN** a schema named `workspace-planning` SHALL be available
-- **AND** it SHALL describe the artifact structure for workspace-scoped planning
-
-#### Scenario: Workspace planning schema artifacts
-- **WHEN** the `workspace-planning` schema is loaded
-- **THEN** it SHALL include the normal planning artifacts for a shared proposal, workspace-scoped specs, cross-area design, and coordination tasks
-- **AND** it SHALL not require an additional area manifest outside those normal planning artifacts
-
-#### Scenario: Workspace planning schema supports nested specs
-- **WHEN** the `workspace-planning` schema defines its specs artifact
-- **THEN** the specs artifact SHALL resolve workspace-scoped spec files under `specs/**/*.md`
-- **AND** schema guidance SHALL describe `specs/<area-or-repo>/<capability>/spec.md` as the default convention for area-specific requirements
-
-#### Scenario: Workspace planning schema templates
-- **WHEN** artifact instructions are requested for the `workspace-planning` schema
-- **THEN** the schema SHALL provide templates that guide agents to write workspace-level planning content
-- **AND** those templates SHALL avoid instructing agents to create repo-local implementation artifacts
-- **AND** specs instructions SHALL support organizing area-specific requirements under workspace-scoped `specs/` paths
-
-#### Scenario: Workspace nested spec paths stay workspace-scoped
-- **GIVEN** a workspace change has spec files under `specs/<area-or-repo>/<capability>/spec.md`
-- **WHEN** OpenSpec reports status or artifact instructions for the workspace change
-- **THEN** it SHALL preserve the concrete nested workspace spec paths
-- **AND** it SHALL not treat those files as repo-local specs to sync or archive without an explicit affected-area implementation context
-
-#### Scenario: Workspace planning apply readiness
-- **WHEN** the `workspace-planning` schema defines apply readiness
-- **THEN** it SHALL require coordination tasks before implementation begins
-- **AND** the apply guidance SHALL direct agents to select an affected area before making implementation edits
-

package/OpenSpec-main/openspec/specs/change-creation/spec.md

@@ -1,108 +0,0 @@
-# change-creation Specification
-
-## Purpose
-Provide programmatic utilities for creating and validating OpenSpec change directories.
-## Requirements
-### Requirement: Change Creation
-The system SHALL provide a function to create new change directories programmatically.
-
-#### Scenario: Create change
-- **WHEN** `createChange(projectRoot, 'add-auth')` is called
-- **THEN** the system creates `openspec/changes/add-auth/` directory
-
-#### Scenario: Duplicate change rejected
-- **WHEN** `createChange(projectRoot, 'add-auth')` is called and `openspec/changes/add-auth/` already exists
-- **THEN** the system throws an error indicating the change already exists
-
-#### Scenario: Creates parent directories if needed
-- **WHEN** `createChange(projectRoot, 'add-auth')` is called and `openspec/changes/` does not exist
-- **THEN** the system creates the full path including parent directories
-
-#### Scenario: Invalid change name rejected
-- **WHEN** `createChange(projectRoot, 'Add Auth')` is called with an invalid name
-- **THEN** the system throws a validation error
-
-### Requirement: Change Name Validation
-The system SHALL validate change names follow kebab-case conventions.
-
-#### Scenario: Valid kebab-case name accepted
-- **WHEN** a change name like `add-user-auth` is validated
-- **THEN** validation returns `{ valid: true }`
-
-#### Scenario: Numeric suffixes accepted
-- **WHEN** a change name like `add-feature-2` is validated
-- **THEN** validation returns `{ valid: true }`
-
-#### Scenario: Single word accepted
-- **WHEN** a change name like `refactor` is validated
-- **THEN** validation returns `{ valid: true }`
-
-#### Scenario: Uppercase characters rejected
-- **WHEN** a change name like `Add-Auth` is validated
-- **THEN** validation returns `{ valid: false, error: "..." }`
-
-#### Scenario: Spaces rejected
-- **WHEN** a change name like `add auth` is validated
-- **THEN** validation returns `{ valid: false, error: "..." }`
-
-#### Scenario: Underscores rejected
-- **WHEN** a change name like `add_auth` is validated
-- **THEN** validation returns `{ valid: false, error: "..." }`
-
-#### Scenario: Special characters rejected
-- **WHEN** a change name like `add-auth!` is validated
-- **THEN** validation returns `{ valid: false, error: "..." }`
-
-#### Scenario: Leading hyphen rejected
-- **WHEN** a change name like `-add-auth` is validated
-- **THEN** validation returns `{ valid: false, error: "..." }`
-
-#### Scenario: Trailing hyphen rejected
-- **WHEN** a change name like `add-auth-` is validated
-- **THEN** validation returns `{ valid: false, error: "..." }`
-
-#### Scenario: Consecutive hyphens rejected
-- **WHEN** a change name like `add--auth` is validated
-- **THEN** validation returns `{ valid: false, error: "..." }`
-
-### Requirement: Workspace-aware change creation
-Change creation SHALL support both repo-local and workspace planning homes.
-
-#### Scenario: Creating a change from a workspace root
-- **GIVEN** the command runs from an OpenSpec workspace root
-- **WHEN** the user creates a new change
-- **THEN** OpenSpec SHALL create the change under the workspace planning path
-- **AND** it SHALL not create the change under a linked repo's `openspec/changes/` directory
-- **AND** it SHALL use the `workspace-planning` schema when no explicit schema is provided
-
-#### Scenario: Creating a change from inside a workspace
-- **GIVEN** the command runs from a subdirectory of an OpenSpec workspace planning home
-- **WHEN** the user creates a new change
-- **THEN** OpenSpec SHALL resolve the current workspace as the planning home
-- **AND** it SHALL create the change under that workspace's planning path
-- **AND** it SHALL use the `workspace-planning` schema when no explicit schema is provided
-
-#### Scenario: Creating a change from inside a linked repo
-- **GIVEN** a repo or folder is registered as a workspace link
-- **AND** the command runs from inside that linked repo or folder rather than from the workspace planning home
-- **WHEN** the user creates a new change without explicitly selecting a workspace
-- **THEN** OpenSpec SHALL preserve repo-local change creation behavior for that location
-- **AND** it SHALL not create a workspace-scoped change merely because the location is registered as a workspace link
-
-#### Scenario: Preserving repo-local change creation
-- **GIVEN** the command runs outside an OpenSpec workspace
-- **WHEN** the user creates a new change in a repo-local OpenSpec project
-- **THEN** OpenSpec SHALL continue to create the change under `openspec/changes/`
-
-#### Scenario: Rejecting invalid workspace affected areas
-- **GIVEN** a workspace change creation request includes affected area names
-- **WHEN** one or more names are not registered workspace links
-- **THEN** OpenSpec SHALL reject those invalid affected areas
-- **AND** it SHALL list the valid workspace link names
-
-#### Scenario: Creating without affected areas
-- **GIVEN** the user is still exploring scope
-- **WHEN** the user creates a workspace change without affected areas
-- **THEN** OpenSpec SHALL create the workspace change
-- **AND** it SHALL allow affected areas to be identified later
-