sauron-cli 1.3.0 → 1.4.0

package/OpenSpec-main/openspec/changes/add-global-install-scope/specs/command-generation/spec.md

@@ -1,22 +0,0 @@
-## MODIFIED Requirements
-
-### Requirement: ToolCommandAdapter interface
-The system SHALL provide install-context-aware command path resolution.
-
-#### Scenario: Adapter interface structure
-- **WHEN** implementing a tool adapter
-- **THEN** command file path resolution SHALL receive install context (including effective scope and environment context)
-- **AND** SHALL return the effective command output path for that context
-
-#### Scenario: Codex global path remains supported
-- **WHEN** resolving Codex command paths in global scope
-- **THEN** the adapter SHALL target `$CODEX_HOME/prompts` when `CODEX_HOME` is set
-- **AND** SHALL otherwise target `~/.codex/prompts`
-
-### Requirement: Command generator function
-The command generator SHALL pass install context into adapter path resolution for all generated commands.
-
-#### Scenario: Scoped command generation
-- **WHEN** generating commands for a tool with a resolved effective scope
-- **THEN** generated command paths SHALL match that effective scope
-- **AND** the formatted command body/frontmatter behavior SHALL remain tool-specific and unchanged

package/OpenSpec-main/openspec/changes/add-global-install-scope/specs/global-config/spec.md

@@ -1,24 +0,0 @@
-## ADDED Requirements
-
-### Requirement: Install scope field in global config
-The global config schema SHALL include install scope preference.
-
-#### Scenario: Config shape supports install scope
-- **WHEN** reading or writing global config
-- **THEN** config SHALL support `installScope` with allowed values `global` and `project`
-
-#### Scenario: Schema evolution default
-- **WHEN** loading legacy config without `installScope`
-- **THEN** the system SHALL preserve schema compatibility without mutating the file
-- **AND** effective install scope SHALL resolve to `project` until user explicitly sets `installScope`
-- **AND** preserve all other existing fields
-
-#### Scenario: New config default
-- **WHEN** creating a new global config
-- **THEN** the system SHALL persist `installScope: global` by default
-- **AND** users MAY switch to `project` explicitly
-
-#### Scenario: Invalid install scope value
-- **WHEN** config validation receives an invalid install scope value
-- **THEN** the value SHALL be rejected
-- **AND** the system SHALL preserve the existing valid configuration

package/OpenSpec-main/openspec/changes/add-global-install-scope/specs/installation-scope/spec.md

@@ -1,71 +0,0 @@
-## Purpose
-
-Define the install scope model for OpenSpec-generated skills and commands, including scope preference, effective scope resolution, and fallback/error semantics.
-
-## ADDED Requirements
-
-### Requirement: Install scope preference model
-The system SHALL support a user-level install scope preference with values `global` and `project`.
-
-#### Scenario: Default install scope
-- **WHEN** install scope is not explicitly configured
-- **THEN** the system SHALL resolve a migration-aware default:
-- **AND** use `global` for newly created configs
-- **AND** use `project` for legacy schema-evolved configs until explicit migration
-
-#### Scenario: Explicit install scope
-- **WHEN** user configures install scope to `project`
-- **THEN** generation and update flows SHALL use `project` as the preferred scope
-
-### Requirement: Effective scope resolution by tool surface
-The system SHALL compute effective scope per tool surface (skills, commands) based on preferred scope and tool capability support.
-
-#### Scenario: Preferred scope is supported
-- **WHEN** preferred scope is supported for a tool surface
-- **THEN** the system SHALL use that scope as the effective scope
-
-#### Scenario: Preferred scope is unsupported but alternate is supported
-- **WHEN** preferred scope is not supported for a tool surface
-- **AND** the alternate scope is supported
-- **THEN** the system SHALL use the alternate scope as effective scope
-- **AND** SHALL record a fallback note for user-facing output
-
-#### Scenario: No supported scope
-- **WHEN** neither `global` nor `project` is supported for a tool surface
-- **THEN** the command SHALL fail before writing files
-- **AND** SHALL display actionable remediation
-
-### Requirement: Effective scope reporting
-The system SHALL report effective scope decisions in command output when they differ from the preferred scope.
-
-#### Scenario: Fallback reporting
-- **WHEN** fallback resolution occurs for any selected/configured tool surface
-- **THEN** init/update summaries SHALL include effective scope notes per affected tool
-
-### Requirement: Cross-platform path behavior
-Install scope resolution SHALL produce platform-correct target paths.
-
-#### Scenario: Global scope path on Windows
-- **WHEN** effective scope is `global`
-- **AND** the command runs on Windows
-- **THEN** resolved target paths SHALL use Windows path conventions and separators
-- **AND** SHALL NOT reuse POSIX-style home-relative defaults directly
-
-### Requirement: Cleanup safety for scope transitions
-Scope transitions SHALL update new targets first and clean old managed targets safely.
-
-#### Scenario: Automatic cleanup for managed files on scope change
-- **WHEN** update or init applies a scope transition for a configured tool/surface
-- **THEN** the system SHALL write new artifacts in the new effective scope before cleanup
-- **AND** SHALL automatically remove only OpenSpec-managed files in the previous effective scope
-
-#### Scenario: Cleanup scope boundaries
-- **WHEN** cleanup runs after a scope transition
-- **THEN** the system SHALL leave non-managed files untouched
-- **AND** SHALL limit removal scope to the affected tool/workflow-managed paths
-
-#### Scenario: Cleanup failure after successful writes
-- **WHEN** new artifacts were written successfully in the new scope
-- **AND** cleanup of old managed targets fails
-- **THEN** the command SHALL report failure with leftover cleanup paths
-- **AND** SHALL NOT rollback successfully written new-scope artifacts

package/OpenSpec-main/openspec/changes/add-global-install-scope/tasks.md

@@ -1,61 +0,0 @@
-## 1. Global Config + Validation
-
-- [ ] 1.1 Add `installScope` (`global` | `project`) to `GlobalConfig` with explicit `global` default for newly created configs
-- [ ] 1.2 Update config schema validation and known-key checks to include install scope
-- [ ] 1.3 Add schema-evolution tests ensuring missing `installScope` in legacy configs resolves to effective `project` until explicit migration
-- [ ] 1.4 Extend `openspec config list` output to show install scope and source (`explicit`, `new-default`, `legacy-default`)
-
-## 2. Tool Capability Metadata + Resolvers
-
-- [ ] 2.1 Extend `AI_TOOLS` metadata to declare scope support per surface (skills/commands)
-- [ ] 2.2 Add shared install-target resolver for skills and commands using requested scope + tool support
-- [ ] 2.3 Implement deterministic fallback/error behavior when preferred scope is unsupported, including default behavior when scope support metadata is absent
-- [ ] 2.4 Add unit tests for scope resolution (preferred, fallback, and hard-fail paths)
-
-## 3. Command Generation Contract
-
-- [ ] 3.1 Update `ToolCommandAdapter` path contract to accept install context
-- [ ] 3.2 Update `generateCommand`/`generateCommands` to pass context through adapters
-- [ ] 3.3 Migrate all command adapters to the new path contract
-- [ ] 3.4 Update adapter tests for scoped path behavior (including Codex global path semantics)
-
-## 4. Init Command Scope Support
-
-- [ ] 4.1 Add scope override flag to `openspec init` (`--scope global|project`)
-- [ ] 4.2 Resolve effective scope per tool/surface before writing artifacts
-- [ ] 4.3 Apply scope-aware generation/removal planning for skills and commands
-- [ ] 4.4 Surface effective scope decisions and fallback notes in init summary output
-- [ ] 4.5 Add init tests for global default, project override, and fallback/error scenarios
-
-## 5. Update Command Scope Support
-
-- [ ] 5.1 Add scope override flag to `openspec update` (`--scope global|project`)
-- [ ] 5.2 Make configured-tool detection and drift checks scope-aware
-- [ ] 5.3 Persist and read last successful effective scope per tool/surface for deterministic scope-drift detection
-- [ ] 5.4 Apply scope-aware sync/removal with consistent fallback/error behavior
-- [ ] 5.5 Ensure scope changes update managed files in new targets and clean old managed targets safely
-- [ ] 5.6 Add update tests for global/project/fallback/error and repeat-run idempotency
-
-## 6. Config UX
-
-- [ ] 6.1 Extend `openspec config profile` interactive flow to select install scope
-- [ ] 6.2 Preserve install scope when using preset shortcuts unless explicitly changed
-- [ ] 6.3 Ensure non-interactive config behavior remains deterministic with clear errors
-- [ ] 6.4 Add/adjust config command tests for install scope flows
-- [ ] 6.5 Add migration UX for legacy users to opt into `global` scope explicitly
-
-## 7. Documentation
-
-- [ ] 7.1 Update `docs/supported-tools.md` with scope behavior and effective-scope fallback notes
-- [ ] 7.2 Update `docs/cli.md` examples for init/update scope options
-- [ ] 7.3 Document cross-project implications of global installs
-- [ ] 7.4 Add existing-user migration guide covering legacy-default behavior and explicit opt-in to `installScope: global`
-
-## 8. Verification
-
-- [ ] 8.1 Run targeted tests for config, adapters, init, and update
-- [ ] 8.2 Run full test suite (`pnpm test`) and resolve regressions
-- [ ] 8.3 Manual smoke test: init/update with `installScope=global`
-- [ ] 8.4 Manual smoke test: init/update with `--scope project`
-- [ ] 8.5 Verify path resolution behavior on Windows CI (or cross-platform unit tests with mocked Windows paths)
-- [ ] 8.6 Verify combined behavior matrix for mixed tools across scope × delivery × command-surface capability

package/OpenSpec-main/openspec/changes/add-qa-smoke-harness/.openspec.yaml

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

package/OpenSpec-main/openspec/changes/add-qa-smoke-harness/proposal.md

@@ -1,45 +0,0 @@
-## Why
-
-We need a faster, more reliable way to manually validate CLI behavior changes like profile/delivery sync, migration behavior, and tool-detection UX.
-
-Today, manual review is mostly ad hoc: each developer sets up state differently, runs a different command order, and checks outputs informally. This makes regressions easy to miss and slows iteration on CLI UX work.
-
-An 80/20 solution is to add a lightweight smoke harness for deterministic non-interactive flows, plus a short manual checklist for interactive prompt behavior.
-
-## What Changes
-
-- Add a lightweight QA smoke harness for OpenSpec CLI behavior with isolated per-run sandbox state
-- Use `Makefile` targets as the primary entrypoint:
-  - `make qa` (default local QA entrypoint)
-  - `make qa-smoke` (deterministic non-interactive suite)
-  - `make qa-interactive` (prints/opens manual interactive checklist)
-- Implement smoke logic in a script (invoked by Make targets), not in Make itself
-- Ensure each scenario runs in an isolated sandbox with temporary `HOME`, `XDG_CONFIG_HOME`, `XDG_DATA_HOME`, and `CODEX_HOME`
-- Capture scenario artifacts for inspection (command output, exit code, and before/after filesystem state)
-- Add a focused scenario set for high-risk behavior:
-  - init core output generation
-  - non-interactive detected-tool behavior
-  - migration when profile is unset
-  - delivery cleanup (`both -> skills`, `both -> commands`)
-  - commands-only update detection
-  - new tool directory detection messaging
-  - invalid profile override validation
-- Add a short interactive checklist for keypress/prompt UX verification (Space toggle, Enter confirm, detected pre-selection)
-- Wire CI to run the smoke suite on Linux as a fast regression gate
-
-## Capabilities
-
-### New Capabilities
-
-- `qa-smoke-harness`: Deterministic, sandboxed CLI smoke validation with a single developer entrypoint
-
-### Modified Capabilities
-
-- `developer-qa-workflow`: Standardized local/CI QA flow for CLI behavior and migration-sensitive scenarios
-
-## Impact
-
-- `Makefile` - Add `qa`, `qa-smoke`, and `qa-interactive` targets
-- `scripts/qa-smoke.sh` (or equivalent) - Implement sandbox setup, scenario execution, and assertions
-- `docs/` - Add/update contributor-facing QA instructions and interactive checklist usage
-- CI workflow - Add smoke target execution as a lightweight regression gate

package/OpenSpec-main/openspec/changes/add-qa-smoke-harness/specs/developer-qa-workflow/spec.md

@@ -1,49 +0,0 @@
-## ADDED Requirements
-
-### Requirement: Makefile QA Entry Point
-
-The repository SHALL provide Makefile targets as the primary developer entrypoint for CLI QA flows.
-
-#### Scenario: Default QA target runs smoke suite
-
-- **WHEN** a developer runs `make qa`
-- **THEN** the command SHALL execute the non-interactive smoke suite
-- **AND** exit with status code 0 only when all smoke scenarios pass
-
-#### Scenario: Smoke suite target is directly invokable
-
-- **WHEN** a developer runs `make qa-smoke`
-- **THEN** the command SHALL execute the same smoke suite used by `make qa`
-- **AND** return a non-zero exit code on assertion failure
-
-#### Scenario: Interactive checklist target exists
-
-- **WHEN** a developer runs `make qa-interactive`
-- **THEN** the command SHALL provide the manual interactive verification checklist
-- **AND** SHALL NOT run interactive prompt automation by default
-
-### Requirement: Sandboxed Smoke Scenario Runner
-
-The smoke suite SHALL run CLI scenarios in isolated sandboxes so tests are repeatable and do not depend on machine-global state.
-
-#### Scenario: Scenario execution is environment-isolated
-
-- **WHEN** a smoke scenario runs
-- **THEN** it SHALL use temporary values for `HOME`, `XDG_CONFIG_HOME`, `XDG_DATA_HOME`, and `CODEX_HOME`
-- **AND** global config from the host machine SHALL NOT affect scenario outcomes
-
-#### Scenario: Scenario artifacts are captured for review
-
-- **WHEN** a smoke scenario completes
-- **THEN** the runner SHALL capture command output and exit status
-- **AND** SHALL capture enough filesystem state to inspect before/after behavior
-
-#### Scenario: High-risk workflow coverage exists
-
-- **WHEN** the smoke suite executes
-- **THEN** it SHALL include scenarios covering profile/delivery behavior and migration-sensitive flows
-- **AND** include at least:
-  - non-interactive tool detection
-  - migration when profile is unset
-  - delivery cleanup (`both -> skills`, `both -> commands`)
-  - commands-only update detection

package/OpenSpec-main/openspec/changes/add-tool-command-surface-capabilities/.openspec.yaml

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

package/OpenSpec-main/openspec/changes/add-tool-command-surface-capabilities/proposal.md

@@ -1,111 +0,0 @@
-## Why
-
-OpenSpec currently assumes command delivery maps directly to command adapters. That assumption does not hold for all tools.
-
-Trae is a concrete example: it invokes OpenSpec workflows via skill entries (for example `/openspec-new-change`) rather than adapter-generated command files. In this model, skills are the command surface.
-
-Today, this creates a behavior gap:
-
-- `delivery=commands` can remove skills
-- tools without adapters skip command generation
-- result: selected tools like Trae can end up with no invocable workflow artifacts
-
-This is more than a prompt UX issue because non-interactive and CI flows bypass interactive guidance. We need a capability-aware model in core generation logic.
-
-## What Changes
-
-### 1. Add explicit command-surface capability metadata
-
-Add an optional field in tool metadata to describe how a tool exposes commands:
-
-- `adapter`: command files are generated through a command adapter
-- `skills-invocable`: skills are directly invocable as commands
-- `none`: no OpenSpec command surface
-
-Field should be optional. Default behavior is inferred from adapter registry presence: tools with a registered adapter resolve to `adapter`; tools with no adapter registration and no explicit annotation resolve to `none`.
-Capability values use kebab-case string tokens for consistency with serialized metadata conventions.
-
-Initial explicit override:
-
-- Trae -> `skills-invocable`
-
-### 2. Make delivery behavior capability-aware
-
-Update `init` and `update` to compute effective artifact actions per tool from:
-
-- global delivery (`both | skills | commands`)
-- tool command surface capability
-
-Behavior matrix:
-
-- `both`:
-  - generate skills for all tools with `skillsDir` (including `skills-invocable`)
-  - generate command files only for `adapter` tools
-  - `none`: no artifact action; MAY emit compatibility warning
-- `skills`:
-  - generate skills for all tools with `skillsDir` (including `skills-invocable`)
-  - remove adapter-generated command files
-  - `none`: no artifact action; MAY emit compatibility warning
-- `commands`:
-  - `adapter`: generate commands, remove skills
-  - `skills-invocable`: generate (or keep if up-to-date) skills as command surface; do not remove them
-  - `none`: fail fast with clear error
-
-### 3. Add preflight validation and clearer output
-
-Before writing/removing artifacts, validate selected/configured tools against delivery mode:
-
-- interactive flow: show clear compatibility note before confirmation
-- non-interactive flow: fail with deterministic error listing incompatible tools and supported alternatives
-
-Update summaries to show effective delivery outcomes per tool (for example, when commands mode still installs skills for skills-invocable tools).
-
-### 4. Update docs and tests
-
-- document capability model and Trae behavior under delivery modes
-- ensure CLI docs and supported-tools docs reflect effective behavior
-- add test coverage for:
-  - `init --tools trae` with `delivery=commands`
-  - `update` with Trae configured under `delivery=commands`
-  - mixed selections (`claude + trae`) across all delivery modes
-  - explicit error path for tools with no command surface under `delivery=commands`
-
-### 5. Coordinate with install-scope behavior
-
-When combined with `add-global-install-scope`, init/update planning must compose:
-
-- install scope (`global | project`)
-- delivery mode (`both | skills | commands`)
-- command surface capability (`adapter | skills-invocable | none`)
-
-Implementation tests should cover mixed-tool matrices to ensure deterministic behavior when both changes are active.
-
-## Capabilities
-
-### New Capabilities
-
-- `tool-command-surface`: Capability model that classifies tools as `adapter`, `skills-invocable`, or `none` to drive delivery behavior
-
-### Modified Capabilities
-
-- `cli-init`: Delivery handling becomes tool-capability-aware with preflight compatibility validation
-- `cli-update`: Delivery sync becomes tool-capability-aware with consistent compatibility validation and messaging
-- `supported-tools-docs`: Documents command-surface semantics for non-adapter tools
-
-## Impact
-
-- `src/core/config.ts` - add optional command-surface metadata and Trae override
-- `src/core/command-generation/registry.ts` (or shared helper) - capability inference from adapter presence
-- `src/core/init.ts` - capability-aware generation/removal planning + compatibility validation + summary messaging
-- `src/core/update.ts` - capability-aware sync/removal planning + compatibility validation + summary messaging
-- `src/core/shared/tool-detection.ts` - include capability-aware detection so `skills-invocable` tools remain detectable under `delivery=commands`, and `none` tools are excluded from command-surface artifact detection
-- `docs/supported-tools.md` and `docs/cli.md` - document delivery behavior and compatibility notes
-- `test/core/init.test.ts` and `test/core/update.test.ts` - add coverage for skills-invocable behavior and mixed-tool delivery scenarios
-
-## Sequencing Notes
-
-- This change is intended to stack safely with `simplify-skill-installation` by introducing additive, capability-specific requirements for init/update.
-- If `simplify-skill-installation` merges first, this change should be rebased and keep the capability-aware rule as the source of truth for `delivery=commands` behavior on `skills-invocable` tools.
-- If this change merges first, the `simplify-skill-installation` branch should be rebased to avoid re-introducing a global "commands-only means no skills for all tools" assumption.
-- If `add-global-install-scope` merges first, this change should be rebased to compose capability-aware behavior on top of scope-resolved path decisions from that change.
-- If this change merges first, `add-global-install-scope` should be rebased to preserve Section 5 composition rules (`install scope` + `delivery mode` + `command surface capability`) without overriding capability-aware command-surface outcomes.

package/OpenSpec-main/openspec/changes/add-tool-command-surface-capabilities/specs/cli-init/spec.md

@@ -1,121 +0,0 @@
-## ADDED Requirements
-
-### Requirement: Command surface capability resolution
-The init command SHALL resolve each selected tool's command surface using explicit metadata first, then deterministic inference.
-
-#### Scenario: Explicit command surface override
-- **WHEN** a tool declares an explicit command-surface capability
-- **THEN** init SHALL use that explicit capability
-- **AND** SHALL NOT override it based on adapter presence
-
-#### Scenario: Inferred command surface from adapter presence
-- **WHEN** a tool does not declare an explicit command-surface capability
-- **AND** a command adapter is registered for the tool
-- **THEN** init SHALL infer `adapter` as the command surface
-
-#### Scenario: Inferred command surface for skills-only tool
-- **WHEN** a tool does not declare an explicit command-surface capability
-- **AND** no command adapter is registered for the tool
-- **AND** the tool has a configured `skillsDir`
-- **THEN** init SHALL infer `skills-invocable` as the command surface
-
-#### Scenario: Inferred command surface without adapter or skills
-- **WHEN** a tool does not declare an explicit command-surface capability
-- **AND** no command adapter is registered for the tool
-- **AND** the tool has no `skillsDir`
-- **THEN** init SHALL infer `none` as the command surface
-
-### Requirement: Delivery compatibility by tool command surface
-The init command SHALL apply delivery settings using each tool's command surface capability, not adapter presence alone.
-
-#### Scenario: Both delivery for adapter-backed tool
-- **WHEN** user runs `openspec init` with a selected tool that has a command adapter
-- **AND** delivery is set to `both`
-- **THEN** the system SHALL generate command files for active workflows using that adapter
-- **AND** SHALL generate or refresh managed skills when the tool has `skillsDir`
-
-#### Scenario: Both delivery for skills-invocable tool
-- **WHEN** user runs `openspec init` with a selected tool whose command surface is `skills-invocable`
-- **AND** delivery is set to `both`
-- **THEN** the system SHALL generate or refresh managed skill directories when the tool has `skillsDir`
-- **AND** SHALL NOT require adapter-generated command files for that tool
-
-#### Scenario: Both delivery for none command surface
-- **WHEN** user runs `openspec init` with a selected tool whose command surface is `none`
-- **AND** delivery is set to `both`
-- **THEN** the system SHALL perform no command-surface artifact action for that tool
-- **AND** MAY emit a compatibility note indicating no command surface is available
-
-#### Scenario: Skills delivery for adapter-backed tool
-- **WHEN** user runs `openspec init` with a selected tool that has a command adapter
-- **AND** delivery is set to `skills`
-- **THEN** the system SHALL generate or refresh managed skill directories when the tool has `skillsDir`
-- **AND** SHALL remove managed adapter-generated command files for that tool
-
-#### Scenario: Skills delivery for skills-invocable tool
-- **WHEN** user runs `openspec init` with a selected tool whose command surface is `skills-invocable`
-- **AND** delivery is set to `skills`
-- **THEN** the system SHALL generate or refresh managed skill directories when the tool has `skillsDir`
-- **AND** SHALL NOT require adapter-generated command files for that tool
-
-#### Scenario: Skills delivery for none command surface
-- **WHEN** user runs `openspec init` with a selected tool whose command surface is `none`
-- **AND** delivery is set to `skills`
-- **THEN** the system SHALL perform no command-surface artifact action for that tool
-- **AND** MAY emit a compatibility note indicating no command surface is available
-
-#### Scenario: Commands delivery for adapter-backed tool
-- **WHEN** user runs `openspec init` with a selected tool that has a command adapter
-- **AND** delivery is set to `commands`
-- **THEN** the system SHALL generate command files for active workflows using that adapter
-- **AND** the system SHALL remove managed skill directories for that tool
-
-#### Scenario: Commands delivery for skills-invocable tool
-- **WHEN** user runs `openspec init` with a selected tool whose command surface is `skills-invocable`
-- **AND** delivery is set to `commands`
-- **THEN** the system SHALL generate or refresh managed skill directories for active workflows
-- **AND** the system SHALL NOT remove those managed skill directories as part of commands-only cleanup
-- **AND** the system SHALL NOT require a command adapter for that tool
-
-#### Scenario: Commands delivery for mixed tool selection
-- **WHEN** user runs `openspec init` with multiple tools
-- **AND** selected tools include both adapter-backed and skills-invocable command surfaces
-- **AND** delivery is set to `commands`
-- **THEN** the system SHALL apply commands-only behavior per tool capability
-- **AND** the resulting install SHALL include command files for adapter-backed tools and skills for skills-invocable tools
-
-#### Scenario: Commands delivery for unsupported command surface
-- **WHEN** user runs `openspec init` with a selected tool that has no command surface capability
-- **AND** delivery is set to `commands`
-- **THEN** the system SHALL fail before generating or deleting artifacts
-- **AND** the error SHALL list incompatible tool IDs and explain supported alternatives (`both` or `skills`)
-
-#### Scenario: Interactive handling for unsupported command surface
-- **WHEN** user runs `openspec init` interactively
-- **AND** delivery is set to `commands`
-- **AND** selected tools include one or more tools with command surface `none`
-- **THEN** the CLI SHALL show a compatibility error and return to the interactive selection flow for correction
-- **AND** SHALL not perform artifact writes until a valid selection is confirmed
-
-### Requirement: Init compatibility signaling
-The init command SHALL clearly signal command-surface compatibility outcomes in both interactive and non-interactive flows.
-
-#### Scenario: Interactive compatibility note
-- **WHEN** init runs interactively
-- **AND** delivery is `commands`
-- **AND** selected tools include skills-invocable command surfaces
-- **THEN** the system SHALL display a compatibility note before the confirmation prompt indicating those tools will use skills as their command surface
-
-#### Scenario: Non-interactive compatibility summary for skills-invocable tools
-- **WHEN** init runs non-interactively (including `--tools` usage)
-- **AND** delivery is `commands`
-- **AND** selected tools include one or more `skills-invocable` command surfaces
-- **THEN** the command SHALL proceed with exit code 0
-- **AND** the command SHALL write deterministic compatibility summary lines to stdout indicating those tools will use managed skills as their command surface
-
-#### Scenario: Non-interactive compatibility failure
-- **WHEN** init runs non-interactively (including `--tools` usage)
-- **AND** delivery is `commands`
-- **AND** selected tools include any tool with no command surface capability
-- **THEN** the command SHALL exit with code 1
-- **AND** the command SHALL write deterministic, actionable guidance for resolving the selection to stderr

package/OpenSpec-main/openspec/changes/add-tool-command-surface-capabilities/specs/cli-update/spec.md

@@ -1,48 +0,0 @@
-## ADDED Requirements
-
-### Requirement: Delivery sync by command surface capability
-The update command SHALL synchronize artifacts using each configured tool's command surface capability.
-
-#### Scenario: Commands delivery for adapter-backed configured tool
-- **WHEN** user runs `openspec update`
-- **AND** delivery is set to `commands`
-- **AND** a configured tool has an adapter-backed command surface
-- **THEN** the system SHALL generate or refresh command files for active workflows
-- **AND** the system SHALL remove managed skill directories for that tool
-
-#### Scenario: Commands delivery for skills-invocable configured tool
-- **WHEN** user runs `openspec update`
-- **AND** delivery is set to `commands`
-- **AND** a configured tool has `skills-invocable` command surface capability
-- **THEN** the system SHALL generate or refresh managed skill directories for active workflows
-- **AND** the system SHALL NOT remove those managed skill directories as part of commands-only cleanup
-- **AND** the system SHALL NOT attempt to require adapter-generated command files for that tool
-
-#### Scenario: Commands delivery with unsupported command surface
-- **WHEN** user runs `openspec update`
-- **AND** delivery is set to `commands`
-- **AND** a configured tool has no command surface capability
-- **THEN** the system SHALL fail with exit code 1 before applying partial updates
-- **AND** the output SHALL identify incompatible tools and recommended remediation
-
-### Requirement: Configured-tool detection for skills-invocable command surfaces
-The update command SHALL treat tools with skills-invocable command surfaces as configured when managed skill artifacts are present, including under commands delivery.
-
-#### Scenario: Skills-invocable tool under commands delivery
-- **WHEN** user runs `openspec update`
-- **AND** delivery is set to `commands`
-- **AND** a tool has no adapter-generated command files
-- **AND** that tool is marked `skills-invocable` and has managed skills installed
-- **THEN** the system SHALL include the tool in configured-tool detection
-- **AND** the system SHALL apply normal version/profile/delivery sync to that tool
-
-### Requirement: Update summary reflects effective per-tool delivery
-The update command SHALL report effective artifact behavior when delivery intent and artifact type differ due to tool capability.
-
-#### Scenario: Summary for skills-invocable tools in commands delivery
-- **WHEN** update completes successfully
-- **AND** delivery is `commands`
-- **AND** at least one updated tool is `skills-invocable`
-- **THEN** output SHALL include a clear note that those tools use skills as their command surface
-- **AND** output SHALL avoid implying that command generation was skipped due to an error
-

package/OpenSpec-main/openspec/changes/add-tool-command-surface-capabilities/tasks.md

@@ -1,53 +0,0 @@
-## 0. Stacking Coordination
-
-- [ ] 0.1 Rebase this change on latest `main` before implementation
-- [ ] 0.2 If `simplify-skill-installation` is merged first, preserve its profile/delivery model and apply this change as a capability-aware refinement
-- [ ] 0.3 If this change merges first, ensure follow-up rebases do not reintroduce a blanket "commands = remove all skills" rule
-- [ ] 0.4 If `add-global-install-scope` is merged, verify combined scope × delivery × command-surface behavior remains deterministic
-
-## 1. Tool Command-Surface Capability Model
-
-- [ ] 1.1 Extend tool metadata in `src/core/config.ts` with an optional command-surface capability field
-- [ ] 1.2 Define supported capability values: `adapter`, `skills-invocable`, `none`
-- [ ] 1.3 Mark Trae as `skills-invocable`
-- [ ] 1.4 Add a shared capability resolver (explicit metadata override first, inferred fallback from adapter presence second)
-- [ ] 1.5 Add focused unit tests for capability resolution (explicit override, inferred adapter, inferred none)
-
-## 2. Init: Capability-Aware Delivery Planning
-
-- [ ] 2.1 Refactor init generation logic to compute per-tool effective actions (generate/remove skills and commands) instead of using only global booleans
-- [ ] 2.2 In `delivery=commands`, keep/generate skills for `skills-invocable` tools and do not remove those managed skill directories
-- [ ] 2.3 In `delivery=commands`, fail fast before writes when any selected tool resolves to `none`
-- [ ] 2.4 Update init output to clearly report effective behavior for `skills-invocable` tools (skills used as command surface)
-- [ ] 2.5 Ensure init no longer reports "no adapter" for tools intentionally using `skills-invocable`
-- [ ] 2.6 Add/adjust init tests for `delivery=commands` + `trae` (skills retained/generated, no adapter error), mixed tools (`claude,trae`) with per-tool expected outputs, and deterministic failure path for unsupported command surface (`none`)
-
-## 3. Update: Capability-Aware Sync and Drift Detection
-
-- [ ] 3.1 Refactor update sync logic to apply delivery behavior per tool capability (not globally per run)
-- [ ] 3.2 In `delivery=commands`, keep/generate managed skills for `skills-invocable` tools
-- [ ] 3.3 In `delivery=commands`, fail before partial updates when configured tools include a `none` command surface
-- [ ] 3.4 Update profile/delivery drift detection to avoid perpetual drift for `skills-invocable` tools under commands delivery
-- [ ] 3.5 Ensure configured-tool detection still includes `skills-invocable` tools under commands delivery when managed skills exist
-- [ ] 3.6 Update summary output so skills-invocable behavior is reported as expected behavior (not implicit skip/error)
-- [ ] 3.7 Add/adjust update tests for `delivery=commands` + configured Trae (skills retained/generated), idempotent second update (no false drift loop), mixed configured tools (`claude` + `trae`), and deterministic preflight failure for unsupported command surface (`none`)
-
-## 4. UX and Error Messaging
-
-- [ ] 4.1 Add interactive init compatibility note for `delivery=commands` when selected tools include `skills-invocable`
-- [ ] 4.2 Add deterministic non-interactive error text with incompatible tool IDs and suggested alternatives (`both` or `skills`)
-- [ ] 4.3 Align init and update wording so capability-related behavior/messages are consistent
-
-## 5. Documentation Updates
-
-- [ ] 5.1 Update `docs/supported-tools.md` to document command-surface semantics for Trae and clarify delivery interactions
-- [ ] 5.2 Update `docs/cli.md` delivery guidance to explain capability-aware behavior for `delivery=commands`
-- [ ] 5.3 Add a short troubleshooting note for "commands-only + unsupported tool" failures
-
-## 6. Verification
-
-- [ ] 6.1 Run targeted tests: `test/core/init.test.ts` and `test/core/update.test.ts`
-- [ ] 6.2 Run any new capability/unit test files added in this change
-- [ ] 6.3 Run full test suite (`pnpm test`) and resolve regressions
-- [ ] 6.4 Manual smoke check: `openspec init --tools trae` with `delivery=commands`
-- [ ] 6.5 Manual smoke check: mixed tools (`claude,trae`) with `delivery=commands`