simplify status command proposal to minimal scope

feat: adopt future state storage for OpenSpec changes

openspec/README.md

@@ -26,9 +26,9 @@ openspec/
 │   │   ├── proposal.md     # Why, what, impact (consolidated)
 │   │   ├── tasks.md        # Implementation checklist
 │   │   ├── design.md       # Technical decisions (optional, for complex changes)
-│   │   └── patches/        # Spec intent changes
+│   │   └── specs/          # Future state of affected specs
 │   │       └── [capability]/
-│   │           └── spec.md.diff
+│   │           └── spec.md # Clean markdown (no diff syntax)
 │   └── archive/            # Completed changes (dated)
 ```
 
@@ -91,12 +91,13 @@ openspec/changes/[descriptive-name]/
 - Affected specs: [list capabilities that will change]
 - Affected code: [list key files/systems]
 
-# 3. Create patches for ALL spec changes
-# - For EXISTING capabilities: show what changes (+ for additions, - for removals)
-# - For NEW capabilities: show entire new spec with + prefix on every line
-patches/
+# 3. Create future state specs for ALL affected capabilities
+# - Store complete spec files as they will exist after the change
+# - Use clean markdown without diff syntax (+/- prefixes)
+# - Include all formatting and structure of the final intended state
+specs/
 └── [capability]/
-    └── spec.md.diff
+    └── spec.md
 
 # 4. Create tasks.md with implementation steps
 ## 1. [Task Group]

openspec/changes/add-init-command/patches/cli-init/spec.md.diff

@@ -1,66 +0,0 @@
-+# CLI Init Specification
-+
-+## Purpose
-+
-+The `openspec init` command SHALL create a complete OpenSpec directory structure in any project, enabling immediate adoption of OpenSpec conventions.
-+
-+## Behavior
-+
-+### Directory Creation
-+
-+WHEN `openspec init` is executed
-+THEN create the following directory structure:
-+```
-+openspec/
-+├── project.md
-+├── README.md
-+├── specs/
-+└── changes/
-+    └── archive/
-+```
-+
-+### File Generation
-+
-+The command SHALL generate:
-+- `README.md` containing complete OpenSpec instructions for AI assistants
-+- `project.md` with customizable project context template
-+
-+### Interactive Mode (Default)
-+
-+WHEN run without flags
-+THEN prompt user for:
-+- Project name
-+- Project description
-+- Technology stack
-+- Key conventions
-+
-+### Non-Interactive Mode
-+
-+WHEN run with `--yes` flag
-+THEN use sensible defaults for all prompts
-+
-+WHEN run with `--no-input` flag
-+THEN skip all prompts and use minimal defaults
-+
-+### Safety Checks
-+
-+WHEN `openspec/` directory already exists
-+THEN exit with error unless `--force` flag is provided
-+
-+WHEN `--force` flag is provided
-+THEN backup existing directory before overwriting
-+
-+### Exit Codes
-+
-+- 0: Success
-+- 1: OpenSpec directory already exists
-+- 2: Insufficient permissions
-+- 3: User cancelled operation
-+
-+## Why
-+
-+Manual creation of OpenSpec structure is error-prone and creates adoption friction. A standardized init command ensures:
-+- Consistent structure across all projects
-+- Proper AI instruction files are always included
-+- Quick onboarding for new projects
-+- Clear conventions from the start

openspec/changes/add-init-command/specs/cli-init/spec.md

@@ -0,0 +1,66 @@
+# CLI Init Specification
+
+## Purpose
+
+The `openspec init` command SHALL create a complete OpenSpec directory structure in any project, enabling immediate adoption of OpenSpec conventions.
+
+## Behavior
+
+### Directory Creation
+
+WHEN `openspec init` is executed
+THEN create the following directory structure:
+```
+openspec/
+├── project.md
+├── README.md
+├── specs/
+└── changes/
+    └── archive/
+```
+
+### File Generation
+
+The command SHALL generate:
+- `README.md` containing complete OpenSpec instructions for AI assistants
+- `project.md` with customizable project context template
+
+### Interactive Mode (Default)
+
+WHEN run without flags
+THEN prompt user for:
+- Project name
+- Project description
+- Technology stack
+- Key conventions
+
+### Non-Interactive Mode
+
+WHEN run with `--yes` flag
+THEN use sensible defaults for all prompts
+
+WHEN run with `--no-input` flag
+THEN skip all prompts and use minimal defaults
+
+### Safety Checks
+
+WHEN `openspec/` directory already exists
+THEN exit with error unless `--force` flag is provided
+
+WHEN `--force` flag is provided
+THEN backup existing directory before overwriting
+
+### Exit Codes
+
+- 0: Success
+- 1: OpenSpec directory already exists
+- 2: Insufficient permissions
+- 3: User cancelled operation
+
+## Why
+
+Manual creation of OpenSpec structure is error-prone and creates adoption friction. A standardized init command ensures:
+- Consistent structure across all projects
+- Proper AI instruction files are always included
+- Quick onboarding for new projects
+- Clear conventions from the start

openspec/changes/add-status-command/proposal.md

@@ -0,0 +1,19 @@
+# Add Status Command to OpenSpec CLI
+
+## Why
+
+Developers need to know which changes have all tasks completed and are ready to archive.
+
+## What Changes
+
+- Add `openspec status` command that scans the changes/ directory
+- Parse each tasks.md file to count `[x]` (complete) and `[ ]` (incomplete) tasks
+- Display each change with its completion status (e.g., "auth-feature: 5/5" or "auth-feature: ✓")
+- Skip the archive/ subdirectory
+
+## Impact
+
+- Affected specs: New capability `cli-status` will be added
+- Affected code:
+  - `src/cli/index.ts` - Add status command
+  - `src/core/status.ts` - New file with simple scanning and parsing logic (~50 lines)

openspec/changes/add-status-command/specs/cli-status/spec.md

@@ -0,0 +1,58 @@
+# CLI Status Command Specification
+
+## Purpose
+
+The status command shows which OpenSpec changes are ready to archive by displaying task completion status for each change.
+
+## Command Interface
+
+```bash
+# Show status of all changes
+openspec status
+```
+
+## Behavior
+
+WHEN the status command runs:
+1. Scan the `openspec/changes/` directory
+2. Skip the `archive/` subdirectory
+3. For each change directory with a `tasks.md` file:
+   - Count tasks marked with `[x]` (case-insensitive)
+   - Count tasks marked with `[ ]`
+   - Display the change name and completion status
+
+## Output Format
+
+```
+add-auth-feature: 15/15
+fix-payment-bug: 8/8
+refactor-api: 3/10
+update-docs: 0/5
+```
+
+Or with checkmark for fully complete:
+
+```
+add-auth-feature: ✓
+fix-payment-bug: ✓  
+refactor-api: 3/10
+update-docs: 0/5
+```
+
+## Task Detection
+
+The command recognizes these patterns as tasks:
+- `- [ ]` Incomplete task
+- `- [x]` Complete task (lowercase)
+- `- [X]` Complete task (uppercase)
+
+## Error Handling
+
+- If no `tasks.md` exists, skip that change
+- If `tasks.md` is empty or has no tasks, skip that change
+- Continue scanning even if individual files have errors
+
+## Exit Codes
+
+- `0`: Success - status displayed
+- `1`: Error - unable to scan changes directory

openspec/changes/add-status-command/tasks.md

@@ -0,0 +1,8 @@
+# Implementation Tasks for Status Command
+
+## Core Implementation
+- [ ] Add status command to `src/cli/index.ts`
+- [ ] Create `src/core/status.ts` with directory scanning logic
+- [ ] Parse tasks.md files to count `[x]` and `[ ]` patterns
+- [ ] Display each change with completion status (name: complete/total)
+- [ ] Skip the archive/ subdirectory when scanning

openspec/changes/adopt-future-state-storage/tasks.md

@@ -1,36 +1,36 @@
 # Implementation Tasks
 
 ## 1. Update Core Documentation
-- [ ] 1.1 Update openspec/README.md section on "Creating a Change Proposal"
-  - [ ] Replace `patches/` with `specs/` in directory structure
-  - [ ] Update step 3 to show storing complete future state
-  - [ ] Remove diff syntax instructions (+/- prefixes)
+- [x] 1.1 Update openspec/README.md section on "Creating a Change Proposal"
+  - [x] Replace `patches/` with `specs/` in directory structure
+  - [x] Update step 3 to show storing complete future state
+  - [x] Remove diff syntax instructions (+/- prefixes)
 
 ## 2. Migrate Existing Change
-- [ ] 2.1 Convert add-init-command change to new format
-  - [ ] Create `specs/cli-init/spec.md` with clean content (no diff markers)
-  - [ ] Delete old `patches/` directory
-- [ ] 2.2 Test that the migrated change is clear and reviewable
+- [x] 2.1 Convert add-init-command change to new format
+  - [x] Create `specs/cli-init/spec.md` with clean content (no diff markers)
+  - [x] Delete old `patches/` directory
+- [x] 2.2 Test that the migrated change is clear and reviewable
 
 ## 3. Update Documentation Examples
-- [ ] 3.1 Update docs/PRD.md
-  - [ ] Fix directory structure examples (lines 376-382)
-  - [ ] Update archive examples (lines 778-783)
-  - [ ] Ensure consistency throughout
-- [ ] 3.2 Update docs/openspec-walkthrough.md
-  - [ ] Replace diff examples with future state examples
-  - [ ] Ensure the walkthrough reflects new approach
+- [x] 3.1 Update docs/PRD.md
+  - [x] Fix directory structure examples (lines 376-382)
+  - [x] Update archive examples (lines 778-783)
+  - [x] Ensure consistency throughout
+- [x] 3.2 Update docs/openspec-walkthrough.md
+  - [x] Replace diff examples with future state examples
+  - [x] Ensure the walkthrough reflects new approach
 
 ## 4. Create New Spec
-- [ ] 4.1 Finalize openspec-conventions spec in main specs/ directory
-  - [ ] Document the future state storage approach
-  - [ ] Include examples of good proposals
-  - [ ] Make it the source of truth for conventions
+- [x] 4.1 Finalize openspec-conventions spec in main specs/ directory
+  - [x] Document the future state storage approach
+  - [x] Include examples of good proposals
+  - [x] Make it the source of truth for conventions
 
 ## 5. Validation
-- [ ] 5.1 Verify all documentation is consistent
-- [ ] 5.2 Test creating a new change with the new approach
-- [ ] 5.3 Ensure GitHub PR view shows diffs clearly
+- [x] 5.1 Verify all documentation is consistent
+- [x] 5.2 Test creating a new change with the new approach
+- [x] 5.3 Ensure GitHub PR view shows diffs clearly
 
 ## 6. Deployment
 - [ ] 6.1 Get approval for this change

openspec/specs/openspec-conventions/spec.md

@@ -0,0 +1,120 @@
+# OpenSpec Conventions Specification
+
+## Purpose
+
+OpenSpec conventions SHALL define how system capabilities are documented, how changes are proposed and tracked, and how specifications evolve over time. This meta-specification serves as the source of truth for OpenSpec's own conventions.
+
+## Core Principles
+
+The system SHALL follow these principles:
+- Specs reflect what IS currently built and deployed
+- Changes contain proposals for what SHOULD be changed
+- AI drives the documentation process
+- Specs are living documentation kept in sync with deployed code
+
+## Directory Structure
+
+WHEN an OpenSpec project is initialized
+THEN it SHALL have this structure:
+```
+openspec/
+├── project.md              # Project-specific context
+├── README.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]/
+```
+
+## Change Storage Convention
+
+### Future State Storage
+
+WHEN creating a change proposal
+THEN store the complete future state of affected specs
+AND use clean markdown without diff syntax
+
+The `changes/[name]/specs/` directory SHALL contain:
+- Complete spec files as they will exist after the change
+- Clean markdown without `+` or `-` prefixes
+- All formatting and structure of the final intended state
+
+### Proposal Format
+
+WHEN documenting what changes
+THEN the proposal SHALL explicitly describe each change:
+
+```markdown
+**[Section or Behavior Name]**
+- From: [current state/requirement]
+- To: [future state/requirement]
+- Reason: [why this change is needed]
+- Impact: [breaking/non-breaking, who's affected]
+```
+
+This explicit format compensates for not having inline diffs and ensures reviewers understand exactly what will change.
+
+## Change Lifecycle
+
+The change process SHALL follow these states:
+
+1. **Propose**: AI creates change with future state specs and explicit proposal
+2. **Review**: Humans review proposal and future state
+3. **Approve**: Change is approved for implementation
+4. **Implement**: Follow tasks.md checklist (can span multiple PRs)
+5. **Deploy**: Changes are deployed to production
+6. **Update**: Specs in `specs/` are updated to match deployed reality
+7. **Archive**: Change is moved to `archive/YYYY-MM-DD-[name]/`
+
+## Viewing Changes
+
+WHEN reviewing proposed changes
+THEN reviewers can compare using:
+- GitHub PR diff view when changes are committed
+- Command line: `diff -u specs/[capability]/spec.md changes/[name]/specs/[capability]/spec.md`
+- Any visual diff tool comparing current vs future state
+
+The system relies on tools to generate diffs rather than storing them.
+
+## Capability Naming
+
+Capabilities SHALL use:
+- Verb-noun patterns (e.g., `user-auth`, `payment-capture`)
+- Hyphenated lowercase names
+- Singular focus (one responsibility per capability)
+- No nesting (flat structure under `specs/`)
+
+## When Changes Require Proposals
+
+A proposal SHALL be created for:
+- New features or capabilities
+- Breaking changes to existing behavior
+- Architecture or pattern changes
+- Performance optimizations that change behavior
+- Security updates affecting access patterns
+
+A proposal is NOT required for:
+- Bug fixes restoring intended behavior
+- Typos or formatting fixes
+- Non-breaking dependency updates
+- Adding tests for existing behavior
+- Documentation clarifications
+
+## Why This Approach
+
+Clean future state storage provides:
+- **Readability**: No diff syntax pollution
+- **AI-compatibility**: Standard markdown that AI tools understand
+- **Simplicity**: No special parsing or processing needed
+- **Tool-agnostic**: Any diff tool can show changes
+- **Clear intent**: Explicit proposals document reasoning