sauron-cli 1.3.0 → 1.4.0

package/OpenSpec-main/openspec/changes/archive/2025-12-29-unify-change-state-model/proposal.md

@@ -1,101 +0,0 @@
-# Proposal: Unify Change State Model
-
-## Problem Statement
-
-Two bugs create inconsistent behavior when working with changes:
-
-### Bug 1: Empty changes shown as "Completed" in view
-
-```typescript
-// view.ts line 90
-if (progress.total === 0 || progress.completed === progress.total) {
-  completed.push({ name: entry.name });  // BUG: total === 0 ≠ completed
-}
-```
-
-Result: `openspec new change foo && openspec view` shows `foo` as "Completed" when it has no content.
-
-### Bug 2: Artifact workflow commands can't find scaffolded changes
-
-```typescript
-// item-discovery.ts - getActiveChangeIds()
-const proposalPath = path.join(changesPath, entry.name, 'proposal.md');
-await fs.access(proposalPath);  // Only returns changes WITH proposal.md
-```
-
-Result: `openspec status --change foo` says "not found" even though the directory exists.
-
-## Root Cause
-
-The system conflates two different concepts:
-
-| Concept | Question | Source of Truth |
-|---------|----------|-----------------|
-| **Planning Progress** | Are all spec documents created? | File existence (ArtifactGraph) |
-| **Implementation Progress** | Is the coding work done? | Task checkboxes (tasks.md) |
-
-## Proposed Solution
-
-### Fix 1: Add "Draft" state to view command
-
-Keep Active/Completed with their existing meanings, but fix the bug:
-
-| State | Criteria | Meaning |
-|-------|----------|---------|
-| **Draft** | No tasks.md OR `tasks.total === 0` | Still planning |
-| **Active** | `tasks.total > 0` AND `completed < total` | Implementing |
-| **Completed** | `tasks.total > 0` AND `completed === total` | Done |
-
-### Fix 2: Artifact workflow uses directory existence
-
-Update `validateChangeExists()` to check if the directory exists, not if `proposal.md` exists. This allows the artifact workflow to guide users through creating their first artifact.
-
-### Keep existing discovery functions
-
-`getActiveChangeIds()` continues to require `proposal.md` for backward compatibility with validation and other commands.
-
-## What Changes
-
-| Command | Before | After |
-|---------|--------|-------|
-| `openspec view` | Empty = "Completed" | Empty = "Draft" |
-| `openspec status --change X` | Requires proposal.md | Works on any directory |
-| `openspec validate X` | Requires proposal.md | Unchanged (still requires it) |
-
-## Breaking Changes
-
-### Minimal Breaking Change
-
-1. **`openspec view` output**: Empty changes move from "Completed" section to new "Draft" section
-
-### Non-Breaking
-
-- Active/Completed semantics unchanged (still task-based)
-- `getActiveChangeIds()` unchanged
-- `openspec validate` unchanged
-- Archived changes unaffected
-
-## Out of Scope
-
-- Merging task-based and artifact-based progress (they serve different purposes)
-- Changing what "Completed" means (it stays = all tasks done)
-- Adding artifact progress to view command (separate enhancement)
-- Shell tab completions for artifact workflow commands (not yet registered)
-
-## Related Commands Analysis
-
-| Command | Uses `getActiveChangeIds()` | Should include scaffolded? | Change needed? |
-|---------|-----------------------------|-----------------------------|----------------|
-| `openspec view` | No (reads dirs directly) | Yes → Draft section | **Yes** |
-| `openspec list` | No (reads dirs directly) | Yes (shows "No tasks") | No |
-| `openspec status/next/instructions` | Yes | Yes | **Yes** |
-| `openspec validate` | Yes | No (can't validate empty) | No |
-| `openspec show` | Yes | No (nothing to show) | No |
-| Tab completions | Yes | Future enhancement | No |
-
-## Success Criteria
-
-1. `openspec new change foo && openspec view` shows `foo` in "Draft" section
-2. `openspec new change foo && openspec status --change foo` works
-3. Changes with all tasks done still show as "Completed"
-4. All existing tests pass

package/OpenSpec-main/openspec/changes/archive/2025-12-29-unify-change-state-model/specs/cli-artifact-workflow/spec.md

@@ -1,109 +0,0 @@
-# cli-artifact-workflow Specification Delta
-
-## MODIFIED Requirements
-
-### Requirement: Status Command
-
-The system SHALL display artifact completion status for a change, including scaffolded (empty) changes.
-
-> **Fixes bug**: Previously required `proposal.md` to exist via `getActiveChangeIds()`.
-
-#### Scenario: Show status with all states
-
-- **WHEN** user runs `openspec status --change <id>`
-- **THEN** the system displays each artifact with status indicator:
-  - `[x]` for completed artifacts
-  - `[ ]` for ready artifacts
-  - `[-]` for blocked artifacts (with missing dependencies listed)
-
-#### Scenario: Status shows completion summary
-
-- **WHEN** user runs `openspec status --change <id>`
-- **THEN** output includes completion percentage and count (e.g., "2/4 artifacts complete")
-
-#### Scenario: Status JSON output
-
-- **WHEN** user runs `openspec status --change <id> --json`
-- **THEN** the system outputs JSON with changeName, schemaName, isComplete, and artifacts array
-
-#### Scenario: Status on scaffolded change
-
-- **WHEN** user runs `openspec status --change <id>` on a change with no artifacts
-- **THEN** system displays all artifacts with their status
-- **AND** root artifacts (no dependencies) show as ready `[ ]`
-- **AND** dependent artifacts show as blocked `[-]`
-
-#### Scenario: Missing change parameter
-
-- **WHEN** user runs `openspec status` without `--change`
-- **THEN** the system displays an error with list of available changes
-- **AND** includes scaffolded changes (directories without proposal.md)
-
-#### Scenario: Unknown change
-
-- **WHEN** user runs `openspec status --change unknown-id`
-- **AND** directory `openspec/changes/unknown-id/` does not exist
-- **THEN** the system displays an error listing all available change directories
-
-### Requirement: Next Command
-
-The system SHALL show which artifacts are ready to be created, including for scaffolded changes.
-
-#### Scenario: Show ready artifacts
-
-- **WHEN** user runs `openspec next --change <id>`
-- **THEN** the system lists artifacts whose dependencies are all satisfied
-
-#### Scenario: No artifacts ready
-
-- **WHEN** all artifacts are either completed or blocked
-- **THEN** the system indicates no artifacts are ready (with explanation)
-
-#### Scenario: All artifacts complete
-
-- **WHEN** all artifacts in the change are completed
-- **THEN** the system indicates the change is complete
-
-#### Scenario: Next JSON output
-
-- **WHEN** user runs `openspec next --change <id> --json`
-- **THEN** the system outputs JSON array of ready artifact IDs
-
-#### Scenario: Next on scaffolded change
-
-- **WHEN** user runs `openspec next --change <id>` on a change with no artifacts
-- **THEN** system shows root artifacts (e.g., "proposal") as ready to create
-
-### Requirement: Instructions Command
-
-The system SHALL output enriched instructions for creating an artifact, including for scaffolded changes.
-
-#### Scenario: Show enriched instructions
-
-- **WHEN** user runs `openspec instructions <artifact> --change <id>`
-- **THEN** the system outputs:
-  - Artifact metadata (ID, output path, description)
-  - Template content
-  - Dependency status (done/missing)
-  - Unlocked artifacts (what becomes available after completion)
-
-#### Scenario: Instructions JSON output
-
-- **WHEN** user runs `openspec instructions <artifact> --change <id> --json`
-- **THEN** the system outputs JSON matching ArtifactInstructions interface
-
-#### Scenario: Unknown artifact
-
-- **WHEN** user runs `openspec instructions unknown-artifact --change <id>`
-- **THEN** the system displays an error listing valid artifact IDs for the schema
-
-#### Scenario: Artifact with unmet dependencies
-
-- **WHEN** user requests instructions for a blocked artifact
-- **THEN** the system displays instructions with a warning about missing dependencies
-
-#### Scenario: Instructions on scaffolded change
-
-- **WHEN** user runs `openspec instructions proposal --change <id>` on a scaffolded change
-- **THEN** system outputs template and metadata for creating the proposal
-- **AND** does not require any artifacts to already exist

package/OpenSpec-main/openspec/changes/archive/2025-12-29-unify-change-state-model/specs/cli-view/spec.md

@@ -1,60 +0,0 @@
-# cli-view Specification Delta
-
-## ADDED Requirements
-
-### 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
-
-## MODIFIED Requirements
-
-### 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: 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

package/OpenSpec-main/openspec/changes/archive/2025-12-29-unify-change-state-model/tasks.md

@@ -1,25 +0,0 @@
-# Tasks: Unify Change State Model
-
-## Phase 1: Fix Artifact Workflow Discovery
-
-- [x] Update `validateChangeExists()` in `artifact-workflow.ts` to check directory existence instead of using `getActiveChangeIds()`
-- [x] Update error message to list all change directories (not just those with proposal.md)
-- [x] Add test for `openspec status --change <scaffolded-change>`
-- [x] Add test for `openspec next --change <scaffolded-change>`
-- [x] Add test for `openspec instructions proposal --change <scaffolded-change>`
-
-## Phase 2: Fix View Command
-
-- [x] Update `getChangesData()` in `view.ts` to return three categories: draft, active, completed
-- [x] Fix completion logic: `total === 0` → draft, not completed
-- [x] Add "Draft Changes" section to dashboard rendering
-- [x] Update summary to include draft count
-- [x] Add test for draft changes appearing correctly in view
-
-## Phase 3: Cleanup and Validation
-
-- [x] Clean up test changes (`test-workflow`, `test-workflow-2`)
-- [x] Run full test suite
-- [x] Manual test: `openspec new change foo && openspec status --change foo`
-- [x] Manual test: `openspec new change foo && openspec view` shows foo in Draft
-- [x] Validate with `openspec validate unify-change-state-model --strict`

package/OpenSpec-main/openspec/changes/archive/2025-12-30-add-antigravity-support/proposal.md

@@ -1,11 +0,0 @@
-## Why
-Google is rolling out Antigravity, a Windsurf-derived IDE that discovers workflows from `.agent/workflows/*.md`. Today OpenSpec can only scaffold slash commands for Windsurf directories, so Antigravity users cannot run the proposal/apply/archive flows from the IDE.
-
-## What Changes
-- Add Antigravity as a selectable native tool in `openspec init` so it creates `.agent/workflows/openspec-proposal.md`, `openspec-apply.md`, and `openspec-archive.md` with YAML frontmatter containing only a `description` field plus the standard OpenSpec-managed body.
-- Ensure `openspec update` refreshes the body of any existing Antigravity workflows inside `.agent/workflows/` without creating missing files, mirroring the Windsurf behavior.
-- Share e2e/template coverage confirming the generator writes the proper directory, filename casing, and frontmatter format so Antigravity picks up the workflows.
-
-## Impact
-- Affected specs: `specs/cli-init`, `specs/cli-update`
-- Expected code: CLI init/update tool registries, slash-command templates, associated tests

package/OpenSpec-main/openspec/changes/archive/2025-12-30-add-antigravity-support/specs/cli-init/spec.md

@@ -1,105 +0,0 @@
-# Delta for CLI Init
-
-## MODIFIED Requirements
-### Requirement: Slash Command Configuration
-The init command SHALL generate slash command files for supported editors using shared templates.
-
-#### Scenario: Generating slash commands for Antigravity
-- **WHEN** the user selects Antigravity during initialization
-- **THEN** create `.agent/workflows/openspec-proposal.md`, `.agent/workflows/openspec-apply.md`, and `.agent/workflows/openspec-archive.md`
-- **AND** ensure each file begins with YAML frontmatter that contains only a `description: <stage summary>` field followed by the shared OpenSpec workflow instructions wrapped in managed markers
-- **AND** populate the workflow body with the same proposal/apply/archive guidance used for other tools so Antigravity behaves like Windsurf while pointing to the `.agent/workflows/` directory
-
-#### Scenario: Generating slash commands for Claude Code
-- **WHEN** the user selects Claude Code during initialization
-- **THEN** create `.claude/commands/openspec/proposal.md`, `.claude/commands/openspec/apply.md`, and `.claude/commands/openspec/archive.md`
-- **AND** populate each file from shared templates so command text matches other tools
-- **AND** each template includes instructions for the relevant OpenSpec workflow stage
-
-#### Scenario: Generating slash commands for CodeBuddy Code
-- **WHEN** the user selects CodeBuddy Code during initialization
-- **THEN** create `.codebuddy/commands/openspec/proposal.md`, `.codebuddy/commands/openspec/apply.md`, and `.codebuddy/commands/openspec/archive.md`
-- **AND** populate each file from shared templates so command text matches other tools
-- **AND** each template includes instructions for the relevant OpenSpec workflow stage
-
-#### Scenario: Generating slash commands for Cline
-- **WHEN** the user selects Cline during initialization
-- **THEN** create `.clinerules/openspec-proposal.md`, `.clinerules/openspec-apply.md`, and `.clinerules/openspec-archive.md`
-- **AND** populate each file from shared templates so command text matches other tools
-- **AND** include Cline-specific Markdown heading frontmatter
-- **AND** each template includes instructions for the relevant OpenSpec workflow stage
-
-#### Scenario: Generating slash commands for Crush
-- **WHEN** the user selects Crush during initialization
-- **THEN** create `.crush/commands/openspec/proposal.md`, `.crush/commands/openspec/apply.md`, and `.crush/commands/openspec/archive.md`
-- **AND** populate each file from shared templates so command text matches other tools
-- **AND** include Crush-specific frontmatter with OpenSpec category and tags
-- **AND** each template includes instructions for the relevant OpenSpec workflow stage
-
-#### Scenario: Generating slash commands for Cursor
-- **WHEN** the user selects Cursor during initialization
-- **THEN** create `.cursor/commands/openspec-proposal.md`, `.cursor/commands/openspec-apply.md`, and `.cursor/commands/openspec-archive.md`
-- **AND** populate each file from shared templates so command text matches other tools
-- **AND** each template includes instructions for the relevant OpenSpec workflow stage
-
-#### Scenario: Generating slash commands for Factory Droid
-- **WHEN** the user selects Factory Droid during initialization
-- **THEN** create `.factory/commands/openspec-proposal.md`, `.factory/commands/openspec-apply.md`, and `.factory/commands/openspec-archive.md`
-- **AND** populate each file from shared templates that include Factory-compatible YAML frontmatter for the `description` and `argument-hint` fields
-- **AND** include the `$ARGUMENTS` placeholder in the template body so droid receives any user-supplied input
-- **AND** wrap the generated content in OpenSpec managed markers so `openspec update` can safely refresh the commands
-
-#### Scenario: Generating slash commands for OpenCode
-- **WHEN** the user selects OpenCode during initialization
-- **THEN** create `.opencode/commands/openspec-proposal.md`, `.opencode/commands/openspec-apply.md`, and `.opencode/commands/openspec-archive.md`
-- **AND** populate each file from shared templates so command text matches other tools
-- **AND** each template includes instructions for the relevant OpenSpec workflow stage
-
-#### Scenario: Generating slash commands for Windsurf
-- **WHEN** the user selects Windsurf during initialization
-- **THEN** create `.windsurf/workflows/openspec-proposal.md`, `.windsurf/workflows/openspec-apply.md`, and `.windsurf/workflows/openspec-archive.md`
-- **AND** populate each file from shared templates (wrapped in OpenSpec markers) so workflow text matches other tools
-- **AND** each template includes instructions for the relevant OpenSpec workflow stage
-
-#### Scenario: Generating slash commands for Kilo Code
-- **WHEN** the user selects Kilo Code during initialization
-- **THEN** create `.kilocode/workflows/openspec-proposal.md`, `.kilocode/workflows/openspec-apply.md`, and `.kilocode/workflows/openspec-archive.md`
-- **AND** populate each file from shared templates (wrapped in OpenSpec markers) so workflow text matches other tools
-- **AND** each template includes instructions for the relevant OpenSpec workflow stage
-
-#### Scenario: Generating slash commands for Codex
-- **WHEN** the user selects Codex during initialization
-- **THEN** create global prompt files at `~/.codex/prompts/openspec-proposal.md`, `~/.codex/prompts/openspec-apply.md`, and `~/.codex/prompts/openspec-archive.md` (or under `$CODEX_HOME/prompts` if set)
-- **AND** populate each file from shared templates that map the first numbered placeholder (`$1`) to the primary user input (e.g., change identifier or question text)
-- **AND** wrap the generated content in OpenSpec markers so `openspec update` can refresh the prompts without touching surrounding custom notes
-
-#### Scenario: Generating slash commands for GitHub Copilot
-- **WHEN** the user selects GitHub Copilot during initialization
-- **THEN** create `.github/prompts/openspec-proposal.prompt.md`, `.github/prompts/openspec-apply.prompt.md`, and `.github/prompts/openspec-archive.prompt.md`
-- **AND** populate each file with YAML frontmatter containing a `description` field that summarizes the workflow stage
-- **AND** include `$ARGUMENTS` placeholder to capture user input
-- **AND** wrap the shared template body with OpenSpec markers so `openspec update` can refresh the content
-- **AND** each template includes instructions for the relevant OpenSpec workflow stage
-
-#### Scenario: Generating slash commands for Gemini CLI
-- **WHEN** the user selects Gemini CLI during initialization
-- **THEN** create `.gemini/commands/openspec/proposal.toml`, `.gemini/commands/openspec/apply.toml`, and `.gemini/commands/openspec/archive.toml`
-- **AND** populate each file as TOML that sets a stage-specific `description = "<summary>"` and a multi-line `prompt = """` block with the shared OpenSpec template
-- **AND** wrap the OpenSpec managed markers (`<!-- OPENSPEC:START -->` / `<!-- OPENSPEC:END -->`) inside the `prompt` value so `openspec update` can safely refresh the body between markers without touching the TOML framing
-- **AND** ensure the slash-command copy matches the existing proposal/apply/archive templates used by other tools
-
-#### Scenario: Generating slash commands for iFlow CLI
-- **WHEN** the user selects iFlow CLI during initialization
-- **THEN** create `.iflow/commands/openspec-proposal.md`, `.iflow/commands/openspec-apply.md`, and `.iflow/commands/openspec-archive.md`
-- **AND** populate each file from shared templates so command text matches other tools
-- **AND** include YAML frontmatter with `name`, `id`, `category`, and `description` fields for each command
-- **AND** wrap the generated content in OpenSpec managed markers so `openspec update` can safely refresh the commands
-- **AND** each template includes instructions for the relevant OpenSpec workflow stage
-
-#### Scenario: Generating slash commands for RooCode
-- **WHEN** the user selects RooCode during initialization
-- **THEN** create `.roo/commands/openspec-proposal.md`, `.roo/commands/openspec-apply.md`, and `.roo/commands/openspec-archive.md`
-- **AND** populate each file from shared templates so command text matches other tools
-- **AND** include simple Markdown headings (e.g., `# OpenSpec: Proposal`) without YAML frontmatter
-- **AND** wrap the generated content in OpenSpec managed markers where applicable so `openspec update` can safely refresh the commands
-- **AND** each template includes instructions for the relevant OpenSpec workflow stage

package/OpenSpec-main/openspec/changes/archive/2025-12-30-add-antigravity-support/specs/cli-update/spec.md

@@ -1,92 +0,0 @@
-# Delta for CLI Update
-
-## MODIFIED Requirements
-### 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 shared templates
-- **AND** ensure templates include instructions for the relevant workflow stage
-
-#### Scenario: Updating slash commands for Cline
-- **WHEN** `.clinerules/` 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 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

package/OpenSpec-main/openspec/changes/archive/2025-12-30-add-antigravity-support/tasks.md

@@ -1,12 +0,0 @@
-## 1. CLI init support
-- [x] 1.1 Surface Antigravity in the native-tool picker (interactive + `--tools`) so it toggles alongside other IDEs.
-- [x] 1.2 Generate `.agent/workflows/openspec-proposal.md`, `openspec-apply.md`, and `openspec-archive.md` with YAML frontmatter restricted to a single `description` field for each stage and wrap the body in OpenSpec markers.
-- [x] 1.3 Confirm workspace scaffolding covers missing directory creation and re-run scenarios so repeated init refreshes the managed block.
-
-## 2. CLI update support
-- [x] 2.1 Detect existing Antigravity workflow files during `openspec update` and refresh only the managed body, skipping creation when files are missing.
-- [x] 2.2 Ensure update logic preserves the `description` frontmatter block exactly as written by init, including case and spacing, and refreshes body templates alongside other tools.
-
-## 3. Templates and tests
-- [x] 3.1 Add shared template entries for Antigravity that reuse the Windsurf copy but target `.agent/workflows` plus the description-only frontmatter requirement.
-- [x] 3.2 Expand automated coverage (unit or integration) verifying init and update produce the expected file paths and frontmatter + body markers for Antigravity.

package/OpenSpec-main/openspec/changes/archive/2025-12-30-fix-cline-workflows-implementation/proposal.md

@@ -1,13 +0,0 @@
-## Why
-The Cline implementation was architecturally incorrect. According to Cline's official documentation, Cline uses workflows for on-demand automation and rules for behavioral guidelines. The OpenSpec slash commands are procedural workflows (scaffold → implement → archive), not behavioral rules, so they should be placed in `.clinerules/workflows/` instead of `.clinerules/`.
-
-## What Changes
-- Update ClineSlashCommandConfigurator to use `.clinerules/workflows/` paths instead of `.clinerules/` paths
-- Update all tests to expect the correct workflow file locations
-- Update README.md documentation to reflect workflows instead of rules
-- **BREAKING**: Existing Cline users will need to re-run `openspec init` to get the corrected workflow files
-
-## Impact
-- Affected specs: cli-init, cli-update (corrected Cline workflow paths)
-- Affected code: `src/core/configurators/slash/cline.ts`, test files, README.md
-- Modified files: `.clinerules/workflows/openspec-*.md` (moved from `.clinerules/openspec-*.md`)

package/OpenSpec-main/openspec/changes/archive/2025-12-30-fix-cline-workflows-implementation/specs/cli-init/spec.md

@@ -1,105 +0,0 @@
-# Delta for CLI Init
-
-## MODIFIED Requirements
-### Requirement: Slash Command Configuration
-The init command SHALL generate slash command files for supported editors using shared templates.
-
-#### Scenario: Generating slash commands for Antigravity
-- **WHEN** the user selects Antigravity during initialization
-- **THEN** create `.agent/workflows/openspec-proposal.md`, `.agent/workflows/openspec-apply.md`, and `.agent/workflows/openspec-archive.md`
-- **AND** ensure each file begins with YAML frontmatter that contains only a `description: <stage summary>` field followed by the shared OpenSpec workflow instructions wrapped in managed markers
-- **AND** populate the workflow body with the same proposal/apply/archive guidance used for other tools so Antigravity behaves like Windsurf while pointing to the `.agent/workflows/` directory
-
-#### Scenario: Generating slash commands for Claude Code
-- **WHEN** the user selects Claude Code during initialization
-- **THEN** create `.claude/commands/openspec/proposal.md`, `.claude/commands/openspec/apply.md`, and `.claude/commands/openspec/archive.md`
-- **AND** populate each file from shared templates so command text matches other tools
-- **AND** each template includes instructions for the relevant OpenSpec workflow stage
-
-#### Scenario: Generating slash commands for CodeBuddy Code
-- **WHEN** the user selects CodeBuddy Code during initialization
-- **THEN** create `.codebuddy/commands/openspec/proposal.md`, `.codebuddy/commands/openspec/apply.md`, and `.codebuddy/commands/openspec/archive.md`
-- **AND** populate each file from shared templates so command text matches other tools
-- **AND** each template includes instructions for the relevant OpenSpec workflow stage
-
-#### Scenario: Generating slash commands for Cline
-- **WHEN** the user selects Cline during initialization
-- **THEN** create `.clinerules/workflows/openspec-proposal.md`, `.clinerules/workflows/openspec-apply.md`, and `.clinerules/workflows/openspec-archive.md`
-- **AND** populate each file from shared templates so command text matches other tools
-- **AND** include Cline-specific Markdown heading frontmatter
-- **AND** each template includes instructions for the relevant OpenSpec workflow stage
-
-#### Scenario: Generating slash commands for Crush
-- **WHEN** the user selects Crush during initialization
-- **THEN** create `.crush/commands/openspec/proposal.md`, `.crush/commands/openspec/apply.md`, and `.crush/commands/openspec/archive.md`
-- **AND** populate each file from shared templates so command text matches other tools
-- **AND** include Crush-specific frontmatter with OpenSpec category and tags
-- **AND** each template includes instructions for the relevant OpenSpec workflow stage
-
-#### Scenario: Generating slash commands for Cursor
-- **WHEN** the user selects Cursor during initialization
-- **THEN** create `.cursor/commands/openspec-proposal.md`, `.cursor/commands/openspec-apply.md`, and `.cursor/commands/openspec-archive.md`
-- **AND** populate each file from shared templates so command text matches other tools
-- **AND** each template includes instructions for the relevant OpenSpec workflow stage
-
-#### Scenario: Generating slash commands for Factory Droid
-- **WHEN** the user selects Factory Droid during initialization
-- **THEN** create `.factory/commands/openspec-proposal.md`, `.factory/commands/openspec-apply.md`, and `.factory/commands/openspec-archive.md`
-- **AND** populate each file from shared templates that include Factory-compatible YAML frontmatter for the `description` and `argument-hint` fields
-- **AND** include the `$ARGUMENTS` placeholder in the template body so droid receives any user-supplied input
-- **AND** wrap the generated content in OpenSpec managed markers so `openspec update` can safely refresh the commands
-
-#### Scenario: Generating slash commands for OpenCode
-- **WHEN** the user selects OpenCode during initialization
-- **THEN** create `.opencode/commands/openspec-proposal.md`, `.opencode/commands/openspec-apply.md`, and `.opencode/commands/openspec-archive.md`
-- **AND** populate each file from shared templates so command text matches other tools
-- **AND** each template includes instructions for the relevant OpenSpec workflow stage
-
-#### Scenario: Generating slash commands for Windsurf
-- **WHEN** the user selects Windsurf during initialization
-- **THEN** create `.windsurf/workflows/openspec-proposal.md`, `.windsurf/workflows/openspec-apply.md`, and `.windsurf/workflows/openspec-archive.md`
-- **AND** populate each file from shared templates (wrapped in OpenSpec markers) so workflow text matches other tools
-- **AND** each template includes instructions for the relevant OpenSpec workflow stage
-
-#### Scenario: Generating slash commands for Kilo Code
-- **WHEN** the user selects Kilo Code during initialization
-- **THEN** create `.kilocode/workflows/openspec-proposal.md`, `.kilocode/workflows/openspec-apply.md`, and `.kilocode/workflows/openspec-archive.md`
-- **AND** populate each file from shared templates (wrapped in OpenSpec markers) so workflow text matches other tools
-- **AND** each template includes instructions for the relevant OpenSpec workflow stage
-
-#### Scenario: Generating slash commands for Codex
-- **WHEN** the user selects Codex during initialization
-- **THEN** create global prompt files at `~/.codex/prompts/openspec-proposal.md`, `~/.codex/prompts/openspec-apply.md`, and `~/.codex/prompts/openspec-archive.md` (or under `$CODEX_HOME/prompts` if set)
-- **AND** populate each file from shared templates that map the first numbered placeholder (`$1`) to the primary user input (e.g., change identifier or question text)
-- **AND** wrap the generated content in OpenSpec markers so `openspec update` can refresh the prompts without touching surrounding custom notes
-
-#### Scenario: Generating slash commands for GitHub Copilot
-- **WHEN** the user selects GitHub Copilot during initialization
-- **THEN** create `.github/prompts/openspec-proposal.prompt.md`, `.github/prompts/openspec-apply.prompt.md`, and `.github/prompts/openspec-archive.prompt.md`
-- **AND** populate each file with YAML frontmatter containing a `description` field that summarizes the workflow stage
-- **AND** include `$ARGUMENTS` placeholder to capture user input
-- **AND** wrap the shared template body with OpenSpec markers so `openspec update` can refresh the content
-- **AND** each template includes instructions for the relevant OpenSpec workflow stage
-
-#### Scenario: Generating slash commands for Gemini CLI
-- **WHEN** the user selects Gemini CLI during initialization
-- **THEN** create `.gemini/commands/openspec/proposal.toml`, `.gemini/commands/openspec/apply.toml`, and `.gemini/commands/openspec/archive.toml`
-- **AND** populate each file as TOML that sets a stage-specific `description = "<summary>"` and a multi-line `prompt = """` block with the shared OpenSpec template
-- **AND** wrap the OpenSpec managed markers (`<!-- OPENSPEC:START -->` / `<!-- OPENSPEC:END -->`) inside the `prompt` value so `openspec update` can safely refresh the body between markers without touching the TOML framing
-- **AND** ensure the slash-command copy matches the existing proposal/apply/archive templates used by other tools
-
-#### Scenario: Generating slash commands for iFlow CLI
-- **WHEN** the user selects iFlow CLI during initialization
-- **THEN** create `.iflow/commands/openspec-proposal.md`, `.iflow/commands/openspec-apply.md`, and `.iflow/commands/openspec-archive.md`
-- **AND** populate each file from shared templates so command text matches other tools
-- **AND** include YAML frontmatter with `name`, `id`, `category`, and `description` fields for each command
-- **AND** wrap the generated content in OpenSpec managed markers so `openspec update` can safely refresh the commands
-- **AND** each template includes instructions for the relevant OpenSpec workflow stage
-
-#### Scenario: Generating slash commands for RooCode
-- **WHEN** the user selects RooCode during initialization
-- **THEN** create `.roo/commands/openspec-proposal.md`, `.roo/commands/openspec-apply.md`, and `.roo/commands/openspec-archive.md`
-- **AND** populate each file from shared templates so command text matches other tools
-- **AND** include simple Markdown headings (e.g., `# OpenSpec: Proposal`) without YAML frontmatter
-- **AND** wrap the generated content in OpenSpec managed markers where applicable so `openspec update` can safely refresh the commands
-- **AND** each template includes instructions for the relevant OpenSpec workflow stage