sauron-cli 1.3.0 → 1.4.1

package/OpenSpec-main/openspec/specs/cli-update/spec.md

@@ -1,229 +0,0 @@
-# Update Command Specification
-
-## Purpose
-
-As a developer using OpenSpec, I want to update the OpenSpec instructions in my project when new versions are released, so that I can benefit from improvements to AI agent instructions.
-## Requirements
-### Requirement: Update Behavior
-The update command SHALL update OpenSpec instruction files to the latest templates in a team-friendly manner.
-
-#### Scenario: Running update command
-- **WHEN** a user runs `openspec update`
-- **THEN** replace `openspec/AGENTS.md` with the latest template
-- **AND** if a root-level stub (`AGENTS.md`/`CLAUDE.md`) exists, refresh it so it points to `@/openspec/AGENTS.md`
-
-### Requirement: Prerequisites
-
-The command SHALL require an existing OpenSpec structure before allowing updates.
-
-#### Scenario: Checking prerequisites
-
-- **GIVEN** the command requires an existing `openspec` directory (created by `openspec init`)
-- **WHEN** the `openspec` directory does not exist
-- **THEN** display error: "No OpenSpec directory found. Run 'openspec init' first."
-- **AND** exit with code 1
-
-### Requirement: File Handling
-The update command SHALL handle file updates in a predictable and safe manner.
-
-#### Scenario: Updating files
-- **WHEN** updating files
-- **THEN** completely replace `openspec/AGENTS.md` with the latest template
-- **AND** if a root-level stub exists, update the managed block content so it keeps directing teammates to `@/openspec/AGENTS.md`
-
-### Requirement: Tool-Agnostic Updates
-The update command SHALL refresh OpenSpec-managed files in a predictable manner while respecting each team's chosen tooling.
-
-#### Scenario: Updating files
-- **WHEN** updating files
-- **THEN** completely replace `openspec/AGENTS.md` with the latest template
-- **AND** create or refresh the root-level `AGENTS.md` stub using the managed marker block, even if the file was previously absent
-- **AND** update only the OpenSpec-managed sections inside existing AI tool files, leaving user-authored content untouched
-- **AND** avoid creating new native-tool configuration files (slash commands, CLAUDE.md, etc.) unless they already exist
-
-### Requirement: Core Files Always Updated
-The update command SHALL always update the core OpenSpec files and display an ASCII-safe success message.
-
-#### Scenario: Successful update
-- **WHEN** the update completes successfully
-- **THEN** replace `openspec/AGENTS.md` with the latest template
-- **AND** if a root-level stub exists, refresh it so it still directs contributors to `@/openspec/AGENTS.md`
-
-### Requirement: Slash Command Updates
-
-The update command SHALL refresh existing slash command files for configured tools without creating new ones, and ensure the OpenCode archive command accepts change ID arguments.
-
-#### Scenario: Updating slash commands for Antigravity
-- **WHEN** `.agent/workflows/` contains `openspec-proposal.md`, `openspec-apply.md`, and `openspec-archive.md`
-- **THEN** refresh the OpenSpec-managed portion of each file so the workflow copy matches other tools while preserving the existing single-field `description` frontmatter
-- **AND** skip creating any missing workflow files during update, mirroring the behavior for Windsurf and other IDEs
-
-#### Scenario: Updating slash commands for Claude Code
-- **WHEN** `.claude/commands/openspec/` contains `proposal.md`, `apply.md`, and `archive.md`
-- **THEN** refresh each file using shared templates
-- **AND** ensure templates include instructions for the relevant workflow stage
-
-#### Scenario: Updating slash commands for CodeBuddy Code
-- **WHEN** `.codebuddy/commands/openspec/` contains `proposal.md`, `apply.md`, and `archive.md`
-- **THEN** refresh each file using the shared CodeBuddy templates that include YAML frontmatter for the `description` and `argument-hint` fields
-- **AND** use square bracket format for `argument-hint` parameters (e.g., `[change-id]`)
-- **AND** preserve any user customizations outside the OpenSpec managed markers
-
-#### Scenario: Updating slash commands for Cline
-- **WHEN** `.clinerules/workflows/` contains `openspec-proposal.md`, `openspec-apply.md`, and `openspec-archive.md`
-- **THEN** refresh each file using shared templates
-- **AND** include Cline-specific Markdown heading frontmatter
-- **AND** ensure templates include instructions for the relevant workflow stage
-
-#### Scenario: Updating slash commands for Continue
-- **WHEN** `.continue/prompts/` contains `openspec-proposal.prompt`, `openspec-apply.prompt`, and `openspec-archive.prompt`
-- **THEN** refresh each file using shared templates
-- **AND** ensure templates include instructions for the relevant workflow stage
-
-#### Scenario: Updating slash commands for Crush
-- **WHEN** `.crush/commands/` contains `openspec/proposal.md`, `openspec/apply.md`, and `openspec/archive.md`
-- **THEN** refresh each file using shared templates
-- **AND** include Crush-specific frontmatter with OpenSpec category and tags
-- **AND** ensure templates include instructions for the relevant workflow stage
-
-#### Scenario: Updating slash commands for Cursor
-- **WHEN** `.cursor/commands/` contains `openspec-proposal.md`, `openspec-apply.md`, and `openspec-archive.md`
-- **THEN** refresh each file using shared templates
-- **AND** ensure templates include instructions for the relevant workflow stage
-
-#### Scenario: Updating slash commands for Factory Droid
-- **WHEN** `.factory/commands/` contains `openspec-proposal.md`, `openspec-apply.md`, and `openspec-archive.md`
-- **THEN** refresh each file using the shared Factory templates that include YAML frontmatter for the `description` and `argument-hint` fields
-- **AND** ensure the template body retains the `$ARGUMENTS` placeholder so user input keeps flowing into droid
-- **AND** update only the content inside the OpenSpec managed markers, leaving any unmanaged notes untouched
-- **AND** skip creating missing files during update
-
-#### Scenario: Updating slash commands for OpenCode
-- **WHEN** `.opencode/command/` contains `openspec-proposal.md`, `openspec-apply.md`, and `openspec-archive.md`
-- **THEN** refresh each file using shared templates
-- **AND** ensure templates include instructions for the relevant workflow stage
-- **AND** ensure the archive command includes `$ARGUMENTS` placeholder in frontmatter for accepting change ID arguments
-
-#### Scenario: Updating slash commands for Windsurf
-- **WHEN** `.windsurf/workflows/` contains `openspec-proposal.md`, `openspec-apply.md`, and `openspec-archive.md`
-- **THEN** refresh each file using shared templates wrapped in OpenSpec markers
-- **AND** ensure templates include instructions for the relevant workflow stage
-- **AND** skip creating missing files (the update command only refreshes what already exists)
-
-#### Scenario: Updating slash commands for Kilo Code
-- **WHEN** `.kilocode/workflows/` contains `openspec-proposal.md`, `openspec-apply.md`, and `openspec-archive.md`
-- **THEN** refresh each file using shared templates wrapped in OpenSpec markers
-- **AND** ensure templates include instructions for the relevant workflow stage
-- **AND** skip creating missing files (the update command only refreshes what already exists)
-
-#### Scenario: Updating slash commands for Codex
-- **GIVEN** the global Codex prompt directory contains `openspec-proposal.md`, `openspec-apply.md`, and `openspec-archive.md`
-- **WHEN** a user runs `openspec update`
-- **THEN** refresh each file using the shared slash-command templates (including placeholder guidance)
-- **AND** preserve any unmanaged content outside the OpenSpec marker block
-- **AND** skip creation when a Codex prompt file is missing
-
-#### Scenario: Updating slash commands for GitHub Copilot
-- **WHEN** `.github/prompts/` contains `openspec-proposal.prompt.md`, `openspec-apply.prompt.md`, and `openspec-archive.prompt.md`
-- **THEN** refresh each file using shared templates while preserving the YAML frontmatter
-- **AND** update only the OpenSpec-managed block between markers
-- **AND** ensure templates include instructions for the relevant workflow stage
-
-#### Scenario: Updating slash commands for Gemini CLI
-- **WHEN** `.gemini/commands/openspec/` contains `proposal.toml`, `apply.toml`, and `archive.toml`
-- **THEN** refresh the body of each file using the shared proposal/apply/archive templates
-- **AND** replace only the content between `<!-- OPENSPEC:START -->` and `<!-- OPENSPEC:END -->` markers inside the `prompt = """` block so the TOML framing (`description`, `prompt`) stays intact
-- **AND** skip creating any missing `.toml` files during update; only pre-existing Gemini commands are refreshed
-
-#### Scenario: Updating slash commands for iFlow CLI
-- **WHEN** `.iflow/commands/` contains `openspec-proposal.md`, `openspec-apply.md`, and `openspec-archive.md`
-- **THEN** refresh each file using shared templates
-- **AND** preserve the YAML frontmatter with `name`, `id`, `category`, and `description` fields
-- **AND** update only the OpenSpec-managed block between markers
-- **AND** ensure templates include instructions for the relevant workflow stage
-
-#### Scenario: Missing slash command file
-- **WHEN** a tool lacks a slash command file
-- **THEN** do not create a new file during update
-
-### Requirement: Archive Command Argument Support
-The archive slash command template SHALL support optional change ID arguments for tools that support `$ARGUMENTS` placeholder.
-
-#### Scenario: Archive command with change ID argument
-- **WHEN** a user invokes `/openspec:archive <change-id>` with a change ID
-- **THEN** the template SHALL instruct the AI to validate the provided change ID against `openspec list`
-- **AND** use the provided change ID for archiving if valid
-- **AND** fail fast if the provided change ID doesn't match an archivable change
-
-#### Scenario: Archive command without argument (backward compatibility)
-- **WHEN** a user invokes `/openspec:archive` without providing a change ID
-- **THEN** the template SHALL instruct the AI to identify the change ID from context or by running `openspec list`
-- **AND** proceed with the existing behavior (maintaining backward compatibility)
-
-#### Scenario: OpenCode archive template generation
-- **WHEN** generating the OpenCode archive slash command file
-- **THEN** include the `$ARGUMENTS` placeholder in the frontmatter
-- **AND** wrap it in a clear structure like `<ChangeId>\n  $ARGUMENTS\n</ChangeId>` to indicate the expected argument
-- **AND** include validation steps in the template body to check if the change ID is valid
-
-### Requirement: Repo update stays separate from workspace planning homes
-The repo-local `openspec update` command SHALL not silently treat a workspace planning home as a repo-local OpenSpec project.
-
-#### Scenario: Running update from a workspace root
-- **GIVEN** the command runs from an OpenSpec workspace root
-- **WHEN** the user runs `openspec update`
-- **THEN** OpenSpec SHALL not generate repo-local project files in the workspace root
-- **AND** it SHALL tell the user to run `openspec workspace update`
-
-#### Scenario: Running update from inside a workspace planning directory
-- **GIVEN** the command runs from a subdirectory of an OpenSpec workspace planning home
-- **WHEN** the user runs `openspec update`
-- **THEN** OpenSpec SHALL not run repo-local update behavior
-- **AND** it SHALL tell the user to run `openspec workspace update`
-
-#### Scenario: Running update from a repo-local project
-- **GIVEN** the command runs from inside a repo-local OpenSpec project
-- **WHEN** the user runs `openspec update`
-- **THEN** OpenSpec SHALL preserve existing repo-local update behavior
-
-#### Scenario: Updating a repo-local project nested below a workspace folder
-- **GIVEN** the target path contains repo-local OpenSpec state
-- **AND** an ancestor is an OpenSpec workspace root
-- **WHEN** the user runs `openspec update <path>`
-- **THEN** OpenSpec SHALL preserve repo-local update behavior for the target path
-- **AND** it SHALL not run workspace update behavior
-
-## Edge Cases
-
-### Error Handling
-
-The command SHALL handle edge cases gracefully.
-
-#### Scenario: File permission errors
-
-- **WHEN** file write fails
-- **THEN** let the error bubble up naturally with file path
-
-#### Scenario: Missing AI tool files
-
-- **WHEN** an AI tool configuration file doesn't exist
-- **THEN** skip updating that file
-- **AND** do not create it
-
-#### Scenario: Custom directory names
-
-- **WHEN** considering custom directory names
-- **THEN** not supported in this change
-- **AND** the default directory name `openspec` SHALL be used
-
-## Success Criteria
-
-Users SHALL be able to:
-- Update OpenSpec instructions with a single command
-- Get the latest AI agent instructions
-- See clear confirmation of the update
-
-The update process SHALL be:
-- Simple and fast (no version checking)
-- Predictable (same result every time)
-- Self-contained (no network required)

package/OpenSpec-main/openspec/specs/cli-validate/spec.md

@@ -1,219 +0,0 @@
-# cli-validate Specification
-
-## Purpose
-Define `openspec validate` behavior for validating changes and specs with actionable remediation guidance and structured output.
-
-## Requirements
-### Requirement: Validation SHALL provide actionable remediation steps
-Validation output SHALL include specific guidance to fix each error, including expected structure, example headers, and suggested commands to verify fixes.
-
-#### Scenario: No deltas found in change
-- **WHEN** validating a change with zero parsed deltas
-- **THEN** show error "No deltas found" with guidance:
-  - Explain that change specs must include `## ADDED Requirements`, `## MODIFIED Requirements`, `## REMOVED Requirements`, or `## RENAMED Requirements`
-  - Remind authors that files must live under `openspec/changes/{id}/specs/<capability>/spec.md`
-  - Include an explicit note: "Spec delta files cannot start with titles before the operation headers"
-  - Suggest running `openspec change show {id} --json --deltas-only` for debugging
-
-#### Scenario: Missing required sections
-- **WHEN** a required section is missing
-- **THEN** include expected header names and a minimal skeleton:
-  - For Spec: `## Purpose`, `## Requirements`
-  - For Change: `## Why`, `## What Changes`
-  - Provide an example snippet of the missing section with placeholder prose ready to copy
-  - Mention the quick-reference section in `openspec/AGENTS.md` as the authoritative template
-
-#### Scenario: Missing requirement descriptive text
-- **WHEN** a requirement header lacks descriptive text before scenarios
-- **THEN** emit an error explaining that `### Requirement:` lines must be followed by narrative text before any `#### Scenario:` headers
-  - Show compliant example: "### Requirement: Foo" followed by "The system SHALL ..."
-  - Suggest adding 1-2 sentences describing the normative behavior prior to listing scenarios
-  - Reference the pre-validation checklist in `openspec/AGENTS.md`
-
-### Requirement: Validator SHALL detect likely misformatted scenarios and warn with a fix
-The validator SHALL recognize bulleted lines that look like scenarios (e.g., lines beginning with WHEN/THEN/AND) and emit a targeted warning with a conversion example to `#### Scenario:`.
-
-#### Scenario: Bulleted WHEN/THEN under a Requirement
-- **WHEN** bullets that start with WHEN/THEN/AND are found under a requirement without any `#### Scenario:` headers
-- **THEN** emit warning: "Scenarios must use '#### Scenario:' headers", and show a conversion template:
-```
-#### Scenario: Short name
-- **WHEN** ...
-- **THEN** ...
-- **AND** ...
-```
-
-### Requirement: All issues SHALL include file paths and structured locations
-Error, warning, and info messages SHALL include:
-- Source file path (`openspec/changes/{id}/proposal.md`, `.../specs/{cap}/spec.md`)
-- Structured path (e.g., `deltas[0].requirements[0].scenarios`)
-
-#### Scenario: Zod validation error
-- **WHEN** a schema validation fails
-- **THEN** the message SHALL include `file`, `path`, and a remediation hint if applicable
-
-### Requirement: Invalid results SHALL include a Next steps footer in human-readable output
-The CLI SHALL append a Next steps footer when the item is invalid and not using `--json`, including:
-- Summary line with counts
-- Top-3 guidance bullets (contextual to the most frequent or blocking errors)
-- A suggestion to re-run with `--json` and/or the debug command
-
-#### Scenario: Change invalid summary
-- **WHEN** a change validation fails
-- **THEN** print "Next steps" with 2-3 targeted bullets and suggest `openspec change show <id> --json --deltas-only`
-
-### Requirement: Top-level validate command
-
-The CLI SHALL provide a top-level `validate` command for validating changes and specs with flexible selection options.
-
-#### Scenario: Interactive validation selection
-
-- **WHEN** executing `openspec validate` without arguments
-- **THEN** prompt user to select what to validate (all, changes, specs, or specific item)
-- **AND** perform validation based on selection
-- **AND** display results with appropriate formatting
-
-#### Scenario: Non-interactive environments do not prompt
-
-- **GIVEN** stdin is not a TTY or `--no-interactive` is provided or environment variable `OPEN_SPEC_INTERACTIVE=0`
-- **WHEN** executing `openspec validate` without arguments
-- **THEN** do not prompt interactively
-- **AND** print a helpful hint listing available commands/flags and exit with code 1
-
-#### Scenario: Direct item validation
-
-- **WHEN** executing `openspec validate <item-name>`
-- **THEN** automatically detect if item is a change or spec
-- **AND** validate the specified item
-- **AND** display validation results
-
-### Requirement: Bulk and filtered validation
-
-The validate command SHALL support flags for bulk validation (--all) and filtered validation by type (--changes, --specs).
-
-#### Scenario: Validate everything
-
-- **WHEN** executing `openspec validate --all`
-- **THEN** validate all changes in openspec/changes/ (excluding archive)
-- **AND** validate all specs in openspec/specs/
-- **AND** display a summary showing passed/failed items
-- **AND** exit with code 1 if any validation fails
-
-#### Scenario: Scope of bulk validation
-
-- **WHEN** validating with `--all` or `--changes`
-- **THEN** include all change proposals under `openspec/changes/`
-- **AND** exclude the `openspec/changes/archive/` directory
-
-- **WHEN** validating with `--specs`
-- **THEN** include all specs that have a `spec.md` under `openspec/specs/<id>/spec.md`
-
-#### Scenario: Validate all changes
-
-- **WHEN** executing `openspec validate --changes`
-- **THEN** validate all changes in openspec/changes/ (excluding archive)
-- **AND** display results for each change
-- **AND** show summary statistics
-
-#### Scenario: Validate all specs
-
-- **WHEN** executing `openspec validate --specs`
-- **THEN** validate all specs in openspec/specs/
-- **AND** display results for each spec
-- **AND** show summary statistics
-
-### Requirement: Validation options and progress indication
-
-The validate command SHALL support standard validation options (--strict, --json) and display progress during bulk operations.
-
-#### Scenario: Strict validation
-
-- **WHEN** executing `openspec validate --all --strict`
-- **THEN** apply strict validation to all items
-- **AND** treat warnings as errors
-- **AND** fail if any item has warnings or errors
-
-#### Scenario: JSON output
-
-- **WHEN** executing `openspec validate --all --json`
-- **THEN** output validation results as JSON
-- **AND** include detailed issues for each item
-- **AND** include summary statistics
-
-#### Scenario: JSON output schema for bulk validation
-
-- **WHEN** executing `openspec validate --all --json` (or `--changes` / `--specs`)
-- **THEN** output a JSON object with the following shape:
-  - `items`: Array of objects with fields `{ id: string, type: "change"|"spec", valid: boolean, issues: Issue[], durationMs: number }`
-  - `summary`: Object `{ totals: { items: number, passed: number, failed: number }, byType: { change?: { items: number, passed: number, failed: number }, spec?: { items: number, passed: number, failed: number } } }`
-  - `version`: String identifier for the schema (e.g., `"1.0"`)
-- **AND** exit with code 1 if any `items[].valid === false`
-
-Where `Issue` follows the existing per-item validation report shape `{ level: "ERROR"|"WARNING"|"INFO", path: string, message: string }`.
-
-#### Scenario: Show validation progress
-
-- **WHEN** validating multiple items (--all, --changes, or --specs)
-- **THEN** show progress indicator or status updates
-- **AND** indicate which item is currently being validated
-- **AND** display running count of passed/failed items
-
-#### Scenario: Concurrency limits for performance
-
-- **WHEN** validating multiple items
-- **THEN** run validations with a bounded concurrency (e.g., 4–8 in parallel)
-- **AND** ensure progress indicators remain responsive
-
-### Requirement: Item type detection and ambiguity handling
-
-The validate command SHALL handle ambiguous names and explicit type overrides to ensure clear, deterministic behavior.
-
-#### Scenario: Direct item validation with automatic type detection
-
-- **WHEN** executing `openspec validate <item-name>`
-- **THEN** if `<item-name>` uniquely matches a change or a spec, validate that item
-
-#### Scenario: Ambiguity between change and spec names
-
-- **GIVEN** `<item-name>` exists both as a change and as a spec
-- **WHEN** executing `openspec validate <item-name>`
-- **THEN** print an ambiguity error explaining both matches
-- **AND** suggest passing `--type change` or `--type spec`, or using `openspec change validate` / `openspec spec validate`
-- **AND** exit with code 1 without performing validation
-
-#### Scenario: Unknown item name
-
-- **WHEN** the `<item-name>` matches neither a change nor a spec
-- **THEN** print a not-found error
-- **AND** show nearest-match suggestions when available
-- **AND** exit with code 1
-
-#### Scenario: Explicit type override
-
-- **WHEN** executing `openspec validate --type change <item>`
-- **THEN** treat `<item>` as a change ID and validate it (skipping auto-detection)
-
-- **WHEN** executing `openspec validate --type spec <item>`
-- **THEN** treat `<item>` as a spec ID and validate it (skipping auto-detection)
-
-### Requirement: Interactivity controls
-
-- The CLI SHALL respect `--no-interactive` to disable prompts.
-- The CLI SHALL respect `OPEN_SPEC_INTERACTIVE=0` to disable prompts globally.
-- Interactive prompts SHALL only be shown when stdin is a TTY and interactivity is not disabled.
-
-#### Scenario: Disabling prompts via flags or environment
-
-- **WHEN** `openspec validate` is executed with `--no-interactive` or with environment `OPEN_SPEC_INTERACTIVE=0`
-- **THEN** the CLI SHALL not display interactive prompts
-- **AND** SHALL print non-interactive hints or chosen outputs as appropriate
-
-### Requirement: Parser SHALL handle cross-platform line endings
-The markdown parser SHALL correctly identify sections regardless of line ending format (LF, CRLF, CR).
-
-#### Scenario: Required sections parsed with CRLF line endings
-- **GIVEN** a change proposal markdown saved with CRLF line endings
-- **AND** the document contains `## Why` and `## What Changes`
-- **WHEN** running `openspec validate <change-id>`
-- **THEN** validation SHALL recognize the sections and NOT raise parsing errors
-

package/OpenSpec-main/openspec/specs/cli-view/spec.md

@@ -1,129 +0,0 @@
-# cli-view Specification
-
-## Purpose
-
-The `openspec view` command provides a comprehensive dashboard view of the OpenSpec project state, displaying specifications, changes, and progress metrics in a unified, visually appealing format to help developers quickly understand project status.
-## Requirements
-### Requirement: Dashboard Display
-
-The system SHALL provide a `view` command that displays a dashboard overview of specs and changes.
-
-#### Scenario: Basic dashboard display
-
-- **WHEN** user runs `openspec view`
-- **THEN** system displays a formatted dashboard with sections for summary, active changes, completed changes, and specifications
-
-#### Scenario: No OpenSpec directory
-
-- **WHEN** user runs `openspec view` in a directory without OpenSpec
-- **THEN** system displays error message "✗ No openspec directory found"
-
-### Requirement: Summary Section
-
-The dashboard SHALL display a summary section with key project metrics, including draft change count.
-
-#### Scenario: Complete summary display
-
-- **WHEN** dashboard is rendered with specs and changes
-- **THEN** system shows total number of specifications and requirements
-- **AND** shows number of draft changes
-- **AND** shows number of active changes in progress
-- **AND** shows number of completed changes
-- **AND** shows overall task progress percentage
-
-#### Scenario: Empty project summary
-
-- **WHEN** no specs or changes exist
-- **THEN** summary shows zero counts for all metrics
-
-### Requirement: Active Changes Display
-The dashboard SHALL show active changes with visual progress indicators.
-
-#### Scenario: Active changes ordered by completion percentage
-- **WHEN** multiple active changes are displayed with progress information
-- **THEN** list them sorted by completion percentage ascending so 0% items appear first
-- **AND** treat missing progress values as 0% for ordering
-- **AND** break ties by change identifier in ascending alphabetical order to keep output deterministic
-
-### Requirement: Completed Changes Display
-
-The dashboard SHALL list completed changes in a separate section, only showing changes with ALL tasks completed.
-
-> **Fixes bug**: Previously, changes with `total === 0` were incorrectly shown as completed.
-
-#### Scenario: Completed changes listing
-
-- **WHEN** there are changes with `tasks.total > 0` AND `tasks.completed === tasks.total`
-- **THEN** system shows them with checkmark indicators in a dedicated section
-
-#### Scenario: Mixed completion states
-
-- **WHEN** some changes are complete and others active
-- **THEN** system separates them into appropriate sections
-
-#### Scenario: Empty changes not completed
-
-- **WHEN** a change has no tasks.md or zero tasks defined
-- **THEN** system does NOT show it in "Completed Changes" section
-- **AND** shows it in "Draft Changes" section instead
-
-### Requirement: Specifications Display
-
-The dashboard SHALL display specifications sorted by requirement count.
-
-#### Scenario: Specs listing with counts
-
-- **WHEN** specifications exist in the project
-- **THEN** system shows specs sorted by requirement count (descending) with count labels
-
-#### Scenario: Specs with parsing errors
-
-- **WHEN** a spec file cannot be parsed
-- **THEN** system includes it with 0 requirement count
-
-### Requirement: Visual Formatting
-
-The dashboard SHALL use consistent visual formatting with colors and symbols.
-
-#### Scenario: Color coding
-
-- **WHEN** dashboard elements are displayed
-- **THEN** system uses cyan for specification items
-- **AND** yellow for active changes
-- **AND** green for completed items
-- **AND** dim gray for supplementary text
-
-#### Scenario: Progress bar rendering
-
-- **WHEN** displaying progress bars
-- **THEN** system uses filled blocks (█) for completed portions and light blocks (░) for remaining
-
-### Requirement: Error Handling
-
-The view command SHALL handle errors gracefully.
-
-#### Scenario: File system errors
-
-- **WHEN** file system operations fail
-- **THEN** system continues with available data and omits inaccessible items
-
-#### Scenario: Invalid data structures
-
-- **WHEN** specs or changes have invalid format
-- **THEN** system skips invalid items and continues rendering
-
-### Requirement: Draft Changes Display
-
-The dashboard SHALL display changes without tasks in a separate "Draft" section.
-
-#### Scenario: Draft changes listing
-
-- **WHEN** there are changes with no tasks.md or zero tasks defined
-- **THEN** system shows them in a "Draft Changes" section
-- **AND** uses a distinct indicator (e.g., `○`) to show draft status
-
-#### Scenario: Draft section ordering
-
-- **WHEN** multiple draft changes exist
-- **THEN** system sorts them alphabetically by name
-

package/OpenSpec-main/openspec/specs/command-generation/spec.md

@@ -1,97 +0,0 @@
-# command-generation Specification
-
-## Purpose
-Define tool-agnostic command content and adapter contracts for generating tool-specific OpenSpec command files.
-
-## Requirements
-### Requirement: CommandContent interface
-
-The system SHALL define a tool-agnostic `CommandContent` interface for command data.
-
-#### Scenario: CommandContent structure
-
-- **WHEN** defining a command to generate
-- **THEN** `CommandContent` SHALL include:
-  - `id`: string identifier (e.g., 'explore', 'apply')
-  - `name`: human-readable name (e.g., 'OpenSpec Explore')
-  - `description`: brief description of command purpose
-  - `category`: grouping category (e.g., 'OpenSpec')
-  - `tags`: array of tag strings
-  - `body`: the command instruction content
-
-### Requirement: ToolCommandAdapter interface
-
-The system SHALL define a `ToolCommandAdapter` interface for per-tool formatting.
-
-#### Scenario: Adapter interface structure
-
-- **WHEN** implementing a tool adapter
-- **THEN** `ToolCommandAdapter` SHALL require:
-  - `toolId`: string identifier matching `AIToolOption.value`
-  - `getFilePath(commandId: string)`: returns file path for command (relative from project root, or absolute for global-scoped tools like Codex)
-  - `formatFile(content: CommandContent)`: returns complete file content with frontmatter
-
-#### Scenario: Claude adapter formatting
-
-- **WHEN** formatting a command for Claude Code
-- **THEN** the adapter SHALL output YAML frontmatter with `name`, `description`, `category`, `tags` fields
-- **AND** file path SHALL follow pattern `.claude/commands/opsx/<id>.md`
-
-#### Scenario: Cursor adapter formatting
-
-- **WHEN** formatting a command for Cursor
-- **THEN** the adapter SHALL output YAML frontmatter with `name` as `/opsx-<id>`, `id`, `category`, `description` fields
-- **AND** file path SHALL follow pattern `.cursor/commands/opsx-<id>.md`
-
-#### Scenario: Windsurf adapter formatting
-
-- **WHEN** formatting a command for Windsurf
-- **THEN** the adapter SHALL output YAML frontmatter with `name`, `description`, `category`, `tags` fields
-- **AND** file path SHALL follow pattern `.windsurf/workflows/opsx-<id>.md`
-
-### Requirement: Command generator function
-
-The system SHALL provide a `generateCommand` function that combines content with adapter.
-
-#### Scenario: Generate command file
-
-- **WHEN** calling `generateCommand(content, adapter)`
-- **THEN** it SHALL return an object with:
-  - `path`: the file path from `adapter.getFilePath(content.id)`
-  - `fileContent`: the formatted content from `adapter.formatFile(content)`
-
-#### Scenario: Generate multiple commands
-
-- **WHEN** generating all opsx commands for a tool
-- **THEN** the system SHALL iterate over command contents and generate each using the tool's adapter
-
-### Requirement: CommandAdapterRegistry
-
-The system SHALL provide a registry for looking up tool adapters.
-
-#### Scenario: Get adapter by tool ID
-
-- **WHEN** calling `CommandAdapterRegistry.get('cursor')`
-- **THEN** it SHALL return the Cursor adapter or undefined if not registered
-
-#### Scenario: Get all adapters
-
-- **WHEN** calling `CommandAdapterRegistry.getAll()`
-- **THEN** it SHALL return array of all registered adapters
-
-#### Scenario: Adapter not found
-
-- **WHEN** looking up an adapter for unregistered tool
-- **THEN** `CommandAdapterRegistry.get()` SHALL return undefined
-- **AND** caller SHALL handle missing adapter appropriately
-
-### Requirement: Shared command body content
-
-The body content of commands SHALL be shared across all tools.
-
-#### Scenario: Same instructions across tools
-
-- **WHEN** generating the 'explore' command for Claude and Cursor
-- **THEN** both SHALL use the same `body` content
-- **AND** only the frontmatter and file path SHALL differ
-