/opsx:propose

**Change created: `todo-priority`**

Location: `openspec/changes/todo-priority/`

Artifacts created:
- **proposal.md** — defines the problem and motivation for adding priority support
- **design.md** — technical decisions including default priority, strict enum validation, sort order, and timestamp format change
- **specs/todo-priority/spec.md** — detailed requirements with scenarios covering normal cases, null/empty/invalid priority values
- **tasks.md** — 6 implementation task groups with paired test tasks

All artifacts complete! Ready for implementation.

Run `/opsx:apply` to start implementing.

/opsx:apply

# 第一次运行 - 1 个失败
⎯⎯⎯⎯⎯⎯⎯ Failed Tests 1 ⎯⎯⎯⎯⎯⎯⎯
FAIL  src/store.test.ts > priority validation > should reject undefined priority type
 Test Files  1 failed (1)
      Tests  1 failed | 17 passed (18)

# 修复后运行 - 全部通过
 Test Files  1 passed (1)
      Tests  18 passed (18)

## Implementation Complete

**Change:** todo-priority
**Schema:** spec-driven
**Progress:** 15/15 tasks complete ✓

### Implemented This Session

**Files Created:**
- `src/types.ts` — Todo interface with Priority type
- `src/store.ts` — Store with priority validation and sorting
- `src/routes.ts` — Express routes with priority support
- `src/store.test.ts` — 18 unit tests

**Test Results:** 18 passed

All tasks complete! You can archive this change with `/opsx:archive`.

/opsx:archive

## Archive Complete

**Change:** todo-priority
**Schema:** spec-driven
**Archived to:** `openspec/changes/archive/2026-05-09-todo-priority/`
**Specs:** No delta specs (new capability only)

All artifacts complete. All tasks complete.

/opsx:explore

┌─────────────────────────────────────────────────────────────┐
│                    Priority 设计决策                        │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│   1. 类型选择                                                │
│   ┌──────────────┐         ┌──────────────┐                │
│   │    Enum      │◀───────▶│    String     │                │
│   │  type-safe   │         │   flexible    │                │
│   └──────────────┘         └──────────────┘                │
│                    ▼                                        │
│   2. Null 处理                                               │
│   ┌──────────────┐  ┌──────────────┐  ┌──────────────┐     │
│   │ NOT NULL     │  │ NULL = Medium│  │ NULL = Low   │     │
│   │ 强制有值      │  │ 隐式默认值   │  │ 显式缺失     │     │
│   └──────────────┘  └──────────────┘  └──────────────┘     │
│                                                              │
│   3. 排序权重                                                │
│   ┌──────────────┐  ┌──────────────┐  ┌──────────────┐     │
│   │ HIGH→MED→LOW │  │ LOW→MED→HIGH │  │ MED→HIGH→LOW │     │
│   │ 紧急优先      │  │ 后台任务优先  │  │ 折中方案     │     │
│   └──────────────┘  └──────────────┘  └──────────────┘     │
│                                                              │
│   4. 迁移策略                                                │
│   ┌──────────────┐  ┌──────────────┐  ┌──────────────┐     │
│   │ 全部设为Medium│  │ 用户手动设置  │  │ 脚本批量迁移 │     │
│   └──────────────┘  └──────────────┘  └──────────────┘     │
└─────────────────────────────────────────────────────────────┘

## 推荐方案
- 类型：Enum（固定三个值）
- 数据库：NOT NULL，默认值：'medium'
- 排序权重：HIGH → MEDIUM → LOW
- 迁移：一次性，SQL UPDATE SET priority='medium'

mkdir -p openspec

rules:
  specs:
    - 每个数据字段的变更，必须覆盖 null、空值、越界三种异常场景
    - Scenario 必须使用 #### 四级标题，否则会被静默忽略
  design:
    - 涉及数据库 migration 的设计，必须包含回滚方案
  tasks:
    - 所有实现任务必须配对对应的测试任务，测试任务写在实现任务正下方
    - 单个 task 不超过 30 分钟工作量

# 重新创建变更
openspec new change todo-priority-v2

/opsx:propose

**Change created: `todo-priority-v2`**

Location: `openspec/changes/todo-priority-v2/`

Artifacts created:
- **proposal.md** — defines three-level priority enum, sorting, validation
- **design.md** — enum type, NOT NULL default 'medium', migration plan
- **specs/todo-priority/spec.md** — 4 requirements with scenarios (normal, null, empty, invalid cases)
- **tasks.md** — 6 task groups with paired test tasks (15 total implementation + test tasks)

All artifacts complete! Ready for implementation.

Run `/opsx:apply` to start implementing.

openspec validate todo-priority-v2 --type change

Change 'todo-priority-v2' is valid

Change 'todo-priority-v2' has issues
✗ [ERROR] file: Change must have at least one delta...

openspec schemas

Available schemas:

  spec-driven
    Default OpenSpec workflow - proposal → specs → design → tasks
    Artifacts: proposal → specs → design → tasks

openspec schema fork spec-driven with-review

Note: Schema commands are experimental and may change.
- Forking 'spec-driven' to 'with-review'...
✔ Forked 'spec-driven' to 'with-review'

Source: /opt/homebrew/lib/node_modules/@fission-ai/openspec/schemas/spec-driven (package)
Destination: /Users/shuge/.../todo-api/openspec/schemas/with-review

You can now customize the schema at:
  /Users/shuge/.../todo-api/openspec/schemas/with-review

artifacts:
  - id: proposal
    generates: proposal.md
    template: proposal.md
    description: 变更提案 - 做什么、为什么做
    requires: []

  - id: specs
    generates: specs/**/*.md
    template: spec.md
    description: 行为规范 - 系统应该做什么
    requires: [proposal]

  - id: design
    generates: design.md
    template: design.md
    description: 技术设计 - 怎么做
    requires: [proposal]

  # ⬇️ 新增的 review 工件
  - id: review
    generates: review.md
    template: review.md   # ← 需要在 templates/ 目录下创建此文件
    description: 五维审查 - 检查设计方案和 Spec 的完整性
    instruction: |
      从五个维度审查所有工件的完整性：
      1. 边界条件：Spec 是否覆盖 null、空值、越界、并发等异常场景
      2. 回滚方案：数据库变更是否包含回滚策略
      3. 测试覆盖：Design 是否明确了需要测试的场景和用例
      4. 向后兼容：是否分析了现有接口和数据的兼容性
      5. 任务粒度：初步判断 tasks 应该怎么拆分才合理
    requires: [proposal, specs, design]

  - id: tasks
    generates: tasks.md
    template: tasks.md
    description: 实现任务列表
    requires: [review]   # ← 从 [specs, design] 改为 [review]

openspec new change todo-priority-v3 --schema with-review

- Creating change 'todo-priority-v3' with schema 'with-review'...
✔ Created change 'todo-priority-v3' at openspec/changes/todo-priority-v3/ (schema: with-review)

/opsx:propose

**Change created: `todo-priority-v3`**

Location: `openspec/changes/todo-priority-v3/`
Schema: `with-review` (includes review artifact)

Artifacts created:
- **proposal.md** — same content as v2, defines priority enum with three values
- **design.md** — same content as v2, documents decisions and migration plan
- **specs/todo-priority/spec.md** — same content as v2, 4 requirements with scenarios
- **review.md** — quality review across 5 dimensions (boundary conditions, rollback, test coverage, backward compatibility, task granularity)
- **tasks.md** — 6 task groups with paired test tasks (20 total tasks, includes review recommendations)

All artifacts complete! Ready for implementation.

# Quality Review

## 1. Boundary Conditions

**Status**: ✅ Pass

**Findings**:
- Specs cover null priority (rejected with 400)
- Specs cover empty string priority (rejected with 400)
- Specs cover invalid value "urgent" (rejected with 400)
- Specs cover non-existent todo PATCH (404)
- Scenarios for: valid priority creation, default priority on create, sorted listing, sorted vs default order

**Recommendations**:
None — all three error cases plus normal flow are covered.

## 2. Rollback Plan

**Status**: ✅ Pass

**Findings**:
- Design explicitly states "No rollback needed for priority field" because it's additive
- Migration is one-time and idempotent (UPDATE to 'medium' is safe to re-run)
- Migration plan includes rollback strategy for breaking changes
- Default 'medium' ensures graceful behavior even if migration partially runs

**Recommendations**:
None — rollback plan is complete for this change.

## 3. Test Coverage

**Status**: ⚠️ Warning

**Findings**:
- Specs identify test scenarios for each requirement
- Scenarios map to test cases (18 tests implemented in v1)
- Tasks.md requires paired test tasks (rule from config)

**Recommendations**:
- Ensure tasks.md includes explicit test tasks for each requirement
- Verify 18 tests cover all spec scenarios

## 4. Backward Compatibility

**Status**: ✅ Pass

**Findings**:
- Priority field is additive — existing GET responses unchanged
- POST/PATCH validation is new — only affects new writes
- Migration sets existing todos to 'medium' default
- No breaking changes to existing API contracts except timestamp format (already covered in separate change)

**Recommendations**:
None — migration addresses backward compatibility.

## 5. Task Granularity

**Status**: ✅ Pass

**Findings**:
- Requirements are clear and can be broken into small tasks
- Config rule: single task ≤ 30 minutes
- 15 tasks in todo-priority-v2, each specific and verifiable

**Recommendations**:
None — task breakdown is adequate.

---

## Overall Assessment

All five dimensions pass. The change is well-scoped with clear requirements and migration plan.

**Key recommendations for tasks.md**:
- Include explicit test tasks paired with each implementation task
- Verify sorting edge case (empty list returns empty array)
- Verify PATCH with only priority update (not touching other fields)