sauron-cli 1.2.0 → 1.3.0

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

@@ -0,0 +1,28 @@
+# 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

@@ -0,0 +1,62 @@
+# 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

@@ -0,0 +1,16 @@
+# 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

@@ -0,0 +1,47 @@
+# 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

@@ -0,0 +1,90 @@
+# 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

@@ -0,0 +1,18 @@
+# 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

@@ -0,0 +1,63 @@
+# 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

@@ -0,0 +1,165 @@
+# 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

@@ -0,0 +1,108 @@
+# 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
+