sauron-cli 1.3.0 → 1.4.1

package/OpenSpec-main/openspec/changes/archive/2025-09-29-improve-cli-e2e-plan/proposal.md

@@ -1,19 +0,0 @@
-## Why
-Recent cross-shell regressions for `openspec` commands revealed that our existing unit/integration tests do not exercise the packaged CLI or shell-specific behavior. The prior attempt at Vitest spawn tests stalled because it coupled e2e coverage with `pnpm pack` installs, which fail in network-restricted environments. With those findings incorporated, we now need an approved plan to realign the work.
-
-## What Changes
-- Adopt a phased strategy that first stabilizes direct spawn testing of the built CLI (`node dist/cli/index.js`) using lightweight fixtures and a shared `runCLI` helper.
-- Expand coverage once the spawn harness is stable, keeping the initial matrix focused on bash jobs for Linux/macOS and `pwsh` on Windows while exercising both the direct `node dist/cli/index.js` invocation and the bin shim with non-TTY defaults and captured diagnostics.
-- Treat packaging/install validation as an optional CI safeguard: when a runner has registry access, run a simple pnpm-based pack→install→smoke-test flow; otherwise document it as out of scope while closing remaining hardening items.
-- Close out the remaining cross-shell hardening items: ensure `.gitattributes` covers packaged assets, enforce executable bits for CLI shims during CI, and finish the pending SIGINT handling improvements.
-
-## Impact
-- Tests: add `test/cli-e2e` spawn suite, create the shared `runCLI` helper, and adjust `vitest.setup.ts` as needed.
-- Tooling: update GitHub Actions workflows with the lightweight matrix above and (optionally) a packaging install check where network is available.
-- Docs: note phase progress and any limitations inline in this proposal (or the relevant spec) so future phases have clear context.
-
-### Phase 1 Status
-- Shared `test/helpers/run-cli.ts` guarantees the CLI bundle exists before spawning and enforces non-TTY defaults for every invocation.
-- New `test/cli-e2e/basic.test.ts` covers `--help`, `--version`, a successful `validate --all --json`, and an unknown-item error path against the `tmp-init` fixture copy.
-- Legacy top-level `validate` exec tests now rely on `runCLI`, avoiding manual `execSync` usage while keeping their fixture authoring intact.
-- CI matrix groundwork is in place (bash on Linux/macOS, pwsh on Windows) so the spawn suite runs the same way the helper does across supported shells.

package/OpenSpec-main/openspec/changes/archive/2025-09-29-improve-cli-e2e-plan/tasks.md

@@ -1,9 +0,0 @@
-## 1. Phase 1 – Stabilize Local Spawn Coverage
-- [x] 1.1 Add `test/helpers/run-cli.ts` that ensures the build runs once and executes `node dist/cli/index.js` with non-TTY defaults; update `vitest.setup.ts` to reuse the shared build step.
-- [x] 1.2 Seed `test/cli-e2e` using the minimal fixture set (`tmp-init` or copy) to cover help/version, a happy-path `validate`, and a representative error flow via the new helper.
-- [x] 1.3 Migrate the highest-value existing CLI exec tests (e.g., validate) onto `runCLI` and summarize Phase 1 coverage in this proposal for the next phase.
-
-## 2. Phase 2 – Expand Cross-Shell Validation
-- [x] 2.1 Exercise both entry points (`node dist/cli/index.js`, `bin/openspec.js`) in the spawn suite and add diagnostics for shell/OS context.
-- [x] 2.2 Extend GitHub Actions to run the spawn suite on bash jobs for Linux/macOS and a `pwsh` job on Windows; capture shell/OS diagnostics and note follow-ups for additional shells.
-

package/OpenSpec-main/openspec/changes/archive/2025-09-29-improve-deterministic-tests/proposal.md

@@ -1,78 +0,0 @@
-# Change: Improve Deterministic Tests (Isolate From Repo State)
-
-## Problem
-
-Some unit tests (e.g., ChangeCommand.show/validate) read the live repository
-state via `process.cwd()` and `openspec/changes`. This makes outcomes depend on
-whatever directories happen to exist and the order returned by `fs.readdir`,
-causing flaky success/failure across environments.
-
-Symptoms observed:
-- Tests sometimes select a partial or unrelated change folder.
-- Failures like missing `proposal.md` when a stray change directory is picked.
-- Environment/sandbox differences alter `readdir` ordering and worker behavior.
-
-## Goals
-
-- Make tests deterministic and hermetic.
-- Remove dependence on real repo contents and directory ordering.
-- Keep runtime behavior unchanged for end users.
-
-## Non‑Goals
-
-- Introduce heavy frameworks or test harness complexity.
-- Redesign CLI behavior or change default paths for users.
-
-## Approach
-
-1) Test-local fixture root
-- Each suite that touches filesystem discovery creates a temporary directory:
-  - `openspec/changes/sample-change/proposal.md`
-  - `openspec/changes/sample-change/specs/sample/spec.md`
-- `beforeAll`: `process.chdir(tmpRoot)`; `afterAll`: restore original cwd.
-- Use a constant `changeName = 'sample-change'`; remove reliance on
-  `readdir` order.
-
-2) Optional thin DI for commands (minimal, if needed)
-- Allow `ChangeCommand` (and similar) to accept an optional `root` path
-  (default `process.cwd()`), used for path resolution.
-- Tests pass the temp root explicitly; production code remains unchanged.
-
-3) Harden discovery helpers (safe enhancement)
-- Update `getActiveChangeIds()`/`getActiveChanges()` to include only
-  directories containing `proposal.md` (and optionally at least one
-  `specs/*/spec.md`).
-- Prevents incomplete/stray change folders from being treated as active.
-
-## Rationale
-
-- Small, focused changes eliminate flakiness without altering user workflows.
-- Temporary fixtures are a well-understood testing pattern and keep tests fast.
-- Optional constructor root param is a minimal DI surface that avoids global
-  stubbing and keeps code simple.
-
-## Risks & Mitigations
-
-- Risk: Tests forget to restore `process.cwd()`.
-  - Mitigation: Add `afterAll` guard restoring cwd; reset `process.exitCode` in
-    `afterEach` where modified.
-- Risk: Behavior divergence if DI root is misused.
-  - Mitigation: Default to `process.cwd()`; only tests pass custom roots.
-
-## Acceptance Criteria
-
-- Tests that previously depended on repo state now:
-  - Create and use a temp fixture root.
-  - Do not read real `openspec/changes` during execution.
-  - Pass consistently regardless of directory order or stray folders.
-- No change to CLI behavior for end users (paths still default to cwd).
-
-## Rollout
-
-- Phase 1: Convert the suites that hit `ChangeCommand.show/validate` to
-  isolated fixtures; verify stability locally and in CI.
-- Phase 2: Apply the same pattern to any remaining suites that touch file
-  discovery (`list`, `show`, `validate`, `diff`).
-- Phase 3 (optional): Introduce the constructor `root` param and discovery
-  hardening, if Phase 1 alone isn’t sufficient.
-

package/OpenSpec-main/openspec/changes/archive/2025-09-29-improve-deterministic-tests/tasks.md

@@ -1,25 +0,0 @@
-# Implementation Tasks
-
-## 1. Test Isolation
-- [x] 1.1 Create temp fixture roots per suite (openspec/changes, openspec/specs)
-- [x] 1.2 Use process.chdir to temp root within tests
-- [x] 1.3 Restore original cwd and clean temp dirs after each
-
-## 2. Deterministic Discovery
-- [x] 2.1 Implement getActiveChangeIds(root?) to only include dirs with proposal.md
-- [x] 2.2 Implement getSpecIds(root?) to only include dirs with spec.md
-- [x] 2.3 Return sorted results to avoid fs.readdir ordering variance
-
-## 3. Command Integration
-- [x] 3.1 Ensure change/show/validate rely on cwd and discovery helpers
-- [x] 3.2 Keep runtime behavior unchanged for end users
-
-## 4. Validation
-- [x] 4.1 Convert affected command tests (show, spec, validate, change) to isolated fixtures
-- [x] 4.2 Verify tests pass consistently across environments
-- [x] 4.3 Confirm no reads from real repo state during tests
-
-## 5. Optional (Not Needed Now)
-- [x] 5.1 Add optional root param to discovery helpers (default process.cwd())
-
-

package/OpenSpec-main/openspec/changes/archive/2025-09-29-improve-init-onboarding/proposal.md

@@ -1,13 +0,0 @@
-## Why
-The current `openspec init` flow assumes a single assistant selection and stops once an OpenSpec structure already exists. That makes onboarding feel rigid: teams cannot configure multiple tools in one pass, they do not learn which files were refreshed, and the success copy always references Claude even when other assistants are involved.
-
-## What Changes
-- Allow selecting multiple assistants during `openspec init`, including refreshing existing configurations in a single run.
-- Provide richer onboarding copy that summarizes which tool files were created or refreshed and guides users on next steps for each assistant.
-- Align generated AI-instruction content and specs so CLAUDE.md and AGENTS.md share the same OpenSpec guidance.
-- Update specs and tests to cover the multi-select prompt, improved summaries, and extend-mode coordination.
-
-## Impact
-- Specs: `cli-init`
-- Code: `src/core/init.ts`, `src/core/config.ts`, `src/core/templates/*`, `src/core/configurators/*`
-- Tests: `test/core/init.test.ts`, `test/core/update.test.ts`

package/OpenSpec-main/openspec/changes/archive/2025-09-29-improve-init-onboarding/specs/cli-init/spec.md

@@ -1,92 +0,0 @@
-## MODIFIED Requirements
-### Requirement: AI Tool Configuration
-
-The command SHALL configure AI coding assistants with OpenSpec instructions based on user selection.
-
-#### Scenario: Prompting for AI tool selection
-
-- **WHEN** run interactively
-- **THEN** prompt the user with "Which AI tools do you use?" using a multi-select menu
-- **AND** list every available tool with a checkbox:
-  - Claude Code (creates or refreshes CLAUDE.md and slash commands)
-  - Cursor (creates or refreshes `.cursor/commands/*` slash commands)
-  - AGENTS.md standard (creates or refreshes AGENTS.md with OpenSpec markers)
-- **AND** show "(already configured)" beside tools whose managed files exist so users understand selections will refresh content
-- **AND** treat disabled tools as "coming soon" and keep them unselectable
-- **AND** allow confirming with Enter after selecting one or more tools
-
-### Requirement: AI Tool Configuration Details
-
-The command SHALL properly configure selected AI tools with OpenSpec-specific instructions using a marker system.
-
-#### Scenario: Configuring Claude Code
-
-- **WHEN** Claude Code is selected
-- **THEN** create or update `CLAUDE.md` in the project root directory (not inside openspec/)
-
-#### Scenario: Creating new CLAUDE.md
-
-- **WHEN** CLAUDE.md does not exist
-- **THEN** create new file with OpenSpec content wrapped in markers:
-```markdown
-<!-- OPENSPEC:START -->
-# OpenSpec Instructions
-
-Instructions for AI coding assistants using OpenSpec for spec-driven development.
-
-## TL;DR Quick Checklist
-- Search existing work: `openspec spec list --long`, `openspec list`
-- Decide scope: new capability vs modify existing capability
-- Pick a unique `change-id`: verb-led kebab-case (`add-`, `update-`, `remove-`, `refactor-`)
-- Scaffold: `proposal.md`, `tasks.md`, optional `design.md`, and spec deltas
-- Validate with `openspec validate [change-id] --strict`
-- Request approval before implementation
-<!-- OPENSPEC:END -->
-```
-
-#### Scenario: Updating existing CLAUDE.md
-
-- **WHEN** CLAUDE.md already exists
-- **THEN** preserve all existing content
-- **AND** insert OpenSpec content at the beginning of the file using markers
-- **AND** ensure markers don't duplicate if they already exist
-
-#### Scenario: Managing content with markers
-
-- **WHEN** using the marker system
-- **THEN** use `<!-- OPENSPEC:START -->` to mark the beginning of managed content
-- **AND** use `<!-- OPENSPEC:END -->` to mark the end of managed content
-- **AND** allow OpenSpec to update its content without affecting user customizations
-- **AND** preserve all content outside the markers intact
-
-### Requirement: Interactive Mode
-
-The command SHALL provide an interactive menu for AI tool selection with clear navigation instructions.
-
-#### Scenario: Displaying interactive menu
-
-- **WHEN** run
-- **THEN** prompt the user with: "Which AI tools do you use?"
-- **AND** show a checkbox-based multi-select menu with available tools (Claude Code, Cursor, AGENTS.md standard)
-- **AND** show disabled options as "coming soon" (not selectable)
-- **AND** display inline help indicating Space toggles selections and Enter confirms
-
-#### Scenario: Navigating the menu
-
-- **WHEN** the user is in the menu
-- **THEN** allow arrow keys to move between options
-- **AND** allow Spacebar to toggle the highlighted option
-- **AND** allow Enter key to confirm all current selections
-
-### Requirement: Success Output
-
-The command SHALL provide clear, actionable next steps upon successful initialization.
-
-#### Scenario: Displaying success message
-
-- **WHEN** initialization completes successfully
-- **THEN** display a success banner followed by actionable prompts tailored to the selected tools
-- **AND** summarize which assistant files were created versus refreshed (e.g., `CLAUDE.md (created)`, `.cursor/commands/openspec-apply.md (refreshed)`)
-- **AND** include copy-pasteable onboarding prompts for each configured assistant, replacing placeholder text ([YOUR FEATURE HERE]) with real guidance to customize
-- **AND** reference AGENTS.md-compatible assistants when no tool-specific file exists (e.g., when only AGENTS.md standard is selected)
-

package/OpenSpec-main/openspec/changes/archive/2025-09-29-improve-init-onboarding/tasks.md

@@ -1,12 +0,0 @@
-## 1. Planning & Spec Updates
-- [x] 1.1 Confirm overlap with `add-multi-agent-init` and coordinate extend-mode flow
-- [x] 1.2 Update `openspec/specs/cli-init/spec.md` to capture multi-select onboarding requirements
-
-## 2. Implementation
-- [x] 2.1 Add multi-select support to the `openspec init` prompt, including indicators for existing tool configs
-- [x] 2.2 Enhance success messaging to summarize created/refreshed assets per tool
-- [x] 2.3 Ensure shared instruction template is applied consistently (CLAUDE.md, AGENTS.md, slash commands)
-
-## 3. Quality
-- [x] 3.1 Expand unit tests for init/update flows covering multi-select and summaries
-- [x] 3.2 Perform `openspec init` smoke test in a temp directory (document output)

package/OpenSpec-main/openspec/changes/archive/2025-09-29-remove-diff-command/proposal.md

@@ -1,81 +0,0 @@
-# Remove Diff Command
-
-## Problem
-
-The `openspec diff` command adds unnecessary complexity to the OpenSpec CLI for several reasons:
-
-1. **Redundant functionality**: The `openspec show` command already provides comprehensive visualization of changes through structured JSON output and markdown rendering
-2. **Maintenance burden**: The diff command requires a separate dependency (jest-diff) and additional code complexity (~227 lines)
-3. **Limited value**: Developers can achieve better diff visualization using existing tools:
-   - Git diff for actual file changes
-   - The `show` command for structured change viewing
-   - Standard diff utilities for comparing spec files directly
-4. **Inconsistent with verb-noun pattern**: The command doesn't follow the preferred verb-first command structure that other commands are migrating to
-
-## Solution
-
-Remove the `openspec diff` command entirely and guide users to more appropriate alternatives:
-
-1. **For viewing change content**: Use `openspec show <change-name>` which provides:
-   - Structured JSON output with `--json` flag
-   - Markdown rendering for human-readable format
-   - Delta-only views with `--deltas-only` flag
-   - Full spec content visualization
-
-2. **For comparing files**: Use standard tools:
-   - `git diff` for version control comparisons
-   - System diff utilities for file-by-file comparisons
-   - IDE diff viewers for visual comparisons
-
-## Benefits
-
-- **Reduced complexity**: Removes ~227 lines of code and the jest-diff dependency
-- **Clearer user journey**: Directs users to the canonical `show` command for viewing changes
-- **Lower maintenance**: Fewer commands to maintain and test
-- **Better alignment**: Focuses on the core OpenSpec workflow without redundant features
-
-## Implementation
-
-### Files to Remove
-- `/src/core/diff.ts` - The entire diff command implementation
-- `/openspec/specs/cli-diff/spec.md` - The diff command specification
-
-### Files to Update
-- `/src/cli/index.ts` - Remove diff command registration (lines 8, 84-96)
-- `/package.json` - Remove jest-diff dependency
-- `/README.md` - Remove diff command documentation
-- `/openspec/README.md` - Remove diff command references
-- Various documentation files mentioning `openspec diff`
-
-### Migration Guide for Users
-
-Users currently using `openspec diff` should transition to:
-
-```bash
-# Before
-openspec diff add-feature
-
-# After - view the change proposal
-openspec show add-feature
-
-# After - view only the deltas
-openspec show add-feature --json --deltas-only
-
-# After - use git for file comparisons
-git diff openspec/specs openspec/changes/add-feature/specs
-```
-
-## Risks
-
-- **User disruption**: Existing users may have workflows depending on the diff command
-  - Mitigation: Provide clear migration guide and deprecation period
-  
-- **Loss of visual diff**: The colored, unified diff format will no longer be available
-  - Mitigation: Users can use git diff or other tools for visual comparisons
-
-## Success Metrics
-
-- Successful removal with no broken dependencies
-- Documentation updated to reflect the change
-- Tests passing without the diff command
-- Reduced package size from removing jest-diff dependency

package/OpenSpec-main/openspec/changes/archive/2025-09-29-remove-diff-command/tasks.md

@@ -1,37 +0,0 @@
-# Remove Diff Command - Tasks
-
-## 1. Remove Core Implementation
-- [x] Delete `/src/core/diff.ts`
-- [x] Remove DiffCommand import from `/src/cli/index.ts`
-- [x] Remove diff command registration from CLI
-
-## 2. Remove Specifications
-- [x] Delete `/openspec/specs/cli-diff/spec.md`
-- [x] Archive the spec for historical reference if needed
-
-## 3. Update Dependencies
-- [x] Remove jest-diff from package.json dependencies
-- [x] Run pnpm install to update lock file
-
-## 4. Update Documentation
-- [x] Update main README.md to remove diff command references
-- [x] Update openspec/README.md to remove diff command from command list
-- [x] Update CLAUDE.md template if it mentions diff command
-- [x] Update any example workflows that use diff command
-
-## 5. Update Related Files
-- [x] Search and update any remaining references to "openspec diff" in:
-  - Template files
-  - Test files (if any exist for diff command)
-  - Archive documentation
-  - Change proposals
-
-## 7. Testing
-- [x] Ensure all tests pass after removal
-- [x] Verify CLI help text no longer shows diff command
-- [x] Test that show command provides adequate replacement functionality
-
-## 8. Documentation of Alternative Workflows
-- [x] Document how to use `openspec show` for viewing changes
-- [x] Document how to use git diff for file comparisons
-- [x] Add migration guide to help text or documentation

package/OpenSpec-main/openspec/changes/archive/2025-09-29-sort-active-changes-by-progress/proposal.md

@@ -1,25 +0,0 @@
-# Change: Sort Active Changes by Progress
-
-## Problem
-- The dashboard currently lists active changes in filesystem discovery order.
-- Users cannot quickly spot proposals that have not started or are nearly complete.
-- Inconsistent ordering between runs makes it harder to track progress when many changes exist.
-
-## Proposal
-1. Update the Active Changes list in the dashboard to sort by percentage of completion in ascending order so 0% items show first.
-2. When two changes share the same completion percentage, break ties deterministically by change identifier (alphabetical).
-
-## Benefits
-- Highlights work that has not started yet, enabling quicker prioritization.
-- Provides consistent ordering across machines and repeated runs.
-- Keeps the dashboard compact while communicating the most important status signal.
-
-## Risks & Mitigations
-- **Risk:** Sorting logic could regress rendering when progress data is missing.
-  - **Mitigation:** Treat missing progress as 0% so items still surface and document behavior in tests.
-- **Risk:** Additional sorting could impact performance for large change sets.
-  - **Mitigation:** The number of active changes is typically small; sorting a few entries is negligible.
-
-## Success Criteria
-- Dashboard output shows active changes ordered by ascending completion percentage with deterministic tie-breaking.
-- Unit coverage verifying the sort when percentages vary and when ties occur.

package/OpenSpec-main/openspec/changes/archive/2025-09-29-sort-active-changes-by-progress/specs/cli-view/spec.md

@@ -1,9 +0,0 @@
-## MODIFIED Requirements
-### 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

package/OpenSpec-main/openspec/changes/archive/2025-09-29-sort-active-changes-by-progress/tasks.md

@@ -1,8 +0,0 @@
-# Implementation Tasks
-
-## 1. Dashboard Sorting Logic
-- [x] 1.1 Update the Active Changes rendering to sort by completion percentage ascending.
-- [x] 1.2 Treat missing progress as 0% and break ties alphabetically by change identifier.
-
-## 2. Verification
-- [x] 2.1 Add tests that cover different completion percentages and tie cases to confirm deterministic ordering.

package/OpenSpec-main/openspec/changes/archive/2025-09-29-update-agent-file-name/proposal.md

@@ -1,29 +0,0 @@
-# Update Agent Instruction File Name
-
-## Problem
-The agent instructions live in `openspec/README.md`, which clashes with conventional project README usage and creates confusion for tooling and contributors.
-
-## Solution
-Rename the agent instruction file to `openspec/AGENTS.md` and update OpenSpec tooling to use the new filename:
-- `openspec init` generates `AGENTS.md` instead of `README.md`
-- Templates and code reference `AGENTS.md`
-- Specifications and documentation are updated accordingly
-
-## Benefits
-- Clear separation from project documentation
-- Consistent naming with other agent instruction files
-- Simplifies tooling and project onboarding
-
-## Implementation
-- Rename instruction file and template
-- Update CLI commands (`init`, `update`) to read/write `AGENTS.md`
-- Adjust specs and documentation to reference the new path
-
-## Risks
-- Existing projects may still rely on `README.md`
-- Tooling may miss lingering references to the old filename
-
-## Success Metrics
-- `openspec init` creates `openspec/AGENTS.md`
-- `openspec update` refreshes `AGENTS.md`
-- All specs reference `openspec/AGENTS.md`

package/OpenSpec-main/openspec/changes/archive/2025-09-29-update-agent-file-name/specs/cli-init/spec.md

@@ -1,40 +0,0 @@
-## MODIFIED Requirements
-
-### Requirement: Directory Creation
-The command SHALL create the complete OpenSpec directory structure with all required directories and files.
-
-#### Scenario: Creating OpenSpec structure
-- **WHEN** `openspec init` is executed
-- **THEN** create the following directory structure:
-```
-openspec/
-├── project.md
-├── AGENTS.md
-├── specs/
-└── changes/
-    └── archive/
-```
-
-### Requirement: File Generation
-The command SHALL generate required template files with appropriate content for immediate use.
-
-#### Scenario: Generating template files
-- **WHEN** initializing OpenSpec
-- **THEN** generate `AGENTS.md` containing complete OpenSpec instructions for AI assistants
-- **AND** generate `project.md` with project context template
-
-### Requirement: AI Tool Configuration Details
-
-The command SHALL properly configure selected AI tools with OpenSpec-specific instructions using a marker system.
-
-#### Scenario: Creating new CLAUDE.md
-- **WHEN** CLAUDE.md does not exist
-- **THEN** create new file with OpenSpec content wrapped in markers including reference to `@openspec/AGENTS.md`
-
-### Requirement: Success Output
-
-The command SHALL provide clear, actionable next steps upon successful initialization.
-
-#### Scenario: Displaying success message
-- **WHEN** initialization completes successfully
-- **THEN** include prompt: "Please explain the OpenSpec workflow from openspec/AGENTS.md and how I should work with you on this project"

package/OpenSpec-main/openspec/changes/archive/2025-09-29-update-agent-file-name/specs/cli-update/spec.md

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

package/OpenSpec-main/openspec/changes/archive/2025-09-29-update-agent-file-name/specs/openspec-conventions/spec.md

@@ -1,27 +0,0 @@
-## MODIFIED Requirements
-
-### Requirement: Project Structure
-An OpenSpec project SHALL maintain a consistent directory structure for specifications and changes.
-
-#### Scenario: Initializing project structure
-- **WHEN** an OpenSpec project is initialized
-- **THEN** it SHALL have this structure:
-```
-openspec/
-├── project.md              # Project-specific context
-├── AGENTS.md               # AI assistant instructions
-├── specs/                  # Current deployed capabilities
-│   └── [capability]/       # Single, focused capability
-│       ├── spec.md         # WHAT and WHY
-│       └── design.md       # HOW (optional, for established patterns)
-└── changes/                # Proposed changes
-    ├── [change-name]/      # Descriptive change identifier
-    │   ├── proposal.md     # Why, what, and impact
-    │   ├── tasks.md        # Implementation checklist
-    │   ├── design.md       # Technical decisions (optional)
-    │   └── specs/          # Complete future state
-    │       └── [capability]/
-    │           └── spec.md # Clean markdown (no diff syntax)
-    └── archive/            # Completed changes
-        └── YYYY-MM-DD-[name]/
-```

package/OpenSpec-main/openspec/changes/archive/2025-09-29-update-agent-file-name/tasks.md

@@ -1,22 +0,0 @@
-# Update Agent Instruction File Name - Tasks
-
-## 1. Rename Instruction File
-- [x] Rename `openspec/README.md` to `openspec/AGENTS.md`
-- [x] Update root references to new path
-
-## 2. Update Templates
-- [x] Rename `src/core/templates/readme-template.ts` to `agents-template.ts`
-- [x] Update exported constant from `readmeTemplate` to `agentsTemplate`
-
-## 3. Adjust CLI Commands
-- [x] Modify `openspec init` to generate `AGENTS.md`
-- [x] Update `openspec update` to refresh `AGENTS.md`
-- [x] Ensure CLAUDE.md markers link to `@openspec/AGENTS.md`
-
-## 4. Update Specifications
-- [x] Modify `cli-init` spec to reference `AGENTS.md`
-- [x] Modify `cli-update` spec to reference `AGENTS.md`
-- [x] Modify `openspec-conventions` spec to include `AGENTS.md` in project structure
-
-## 5. Validation
-- [x] `pnpm test`