diff --git a/.doc/statisticsv2-touch-swipe-bugfix.md b/.doc/statisticsv2-touch-swipe-bugfix.md
new file mode 100644
index 0000000..3b4b6ed
--- /dev/null
+++ b/.doc/statisticsv2-touch-swipe-bugfix.md
@@ -0,0 +1,278 @@
+---
+title: 统计V2页面触摸滑动切换Bug修复
+author: AI Assistant
+date: 2026-02-11
+status: final
+category: Bug修复
+---
+
+# 统计V2页面触摸滑动切换Bug修复
+
+## 问题描述
+
+**Bug 表现**: 用户在统计V2页面点击右侧区域时,会意外触发"下一个周期"的切换操作,即使用户并没有执行滑动手势。
+
+**影响范围**: `Web/src/views/statisticsV2/Index.vue`
+
+**用户反馈**: 点击页面偏右位置的时候会触发跳转到下一个月
+
+---
+
+## 根因分析
+
+### 原始代码逻辑
+
+```javascript
+// Web/src/views/statisticsV2/Index.vue:637-668 (修复前)
+
+const handleTouchStart = (e) => {
+  touchStartX.value = e.touches[0].clientX
+  touchStartY.value = e.touches[0].clientY
+}
+
+const handleTouchMove = (e) => {
+  touchEndX.value = e.touches[0].clientX
+  touchEndY.value = e.touches[0].clientY
+}
+
+const handleTouchEnd = () => {
+  const deltaX = touchEndX.value - touchStartX.value
+  const deltaY = touchEndY.value - touchStartY.value
+
+  // 判断是否是水平滑动（水平距离大于垂直距离）
+  if (Math.abs(deltaX) > Math.abs(deltaY) && Math.abs(deltaX) > 50) {
+    if (deltaX > 0) {
+      handlePrevPeriod()  // 右滑
+    } else {
+      handleNextPeriod()  // 左滑
+    }
+  }
+}
+```
+
+### 问题原因
+
+1. **`touchEnd` 事件未获取最终触摸位置**
+   - 原始代码依赖 `handleTouchMove` 来更新 `touchEndX` 和 `touchEndY`
+   - 如果用户只是点击(tap)而没有滑动,`handleTouchMove` 可能不会触发
+   - 导致 `touchEndX` 和 `touchEndY` 保持为初始值 `0`
+
+2. **残留值干扰**
+   - 如果上一次操作有残留的 `touchEndX` 值
+   - 新的点击操作可能会使用旧值进行计算
+
+3. **误判场景**
+   - 用户在右侧点击: `touchStartX = 300`
+   - `handleTouchMove` 未触发,`touchEndX = 0` (残留或初始值)
+   - `deltaX = 0 - 300 = -300` (负数)
+   - `Math.abs(-300) = 300 > 50` ✅ 通过阈值检查
+   - `deltaX < 0` → 触发 `handleNextPeriod()` ❌ **误判为左滑**
+
+---
+
+## 修复方案
+
+### 核心改进
+
+1. **在 `touchStart` 中初始化 `touchEnd` 值**
+   - 防止使用残留值
+   
+2. **在 `touchEnd` 中获取最终位置**
+   - 使用 `e.changedTouches` 获取触摸结束时的坐标
+   - 确保即使没有触发 `touchMove`,也能正确计算距离
+
+3. **明确最小滑动阈值常量**
+   - 提取 `MIN_SWIPE_DISTANCE = 50` 作为常量,增强可读性
+
+### 修复后的代码
+
+```javascript
+// Web/src/views/statisticsV2/Index.vue:637-682 (修复后)
+
+const handleTouchStart = (e) => {
+  touchStartX.value = e.touches[0].clientX
+  touchStartY.value = e.touches[0].clientY
+  // 🔧 修复: 重置 touchEnd 值,防止使用上次的残留值
+  touchEndX.value = touchStartX.value
+  touchEndY.value = touchStartY.value
+}
+
+const handleTouchMove = (e) => {
+  touchEndX.value = e.touches[0].clientX
+  touchEndY.value = e.touches[0].clientY
+}
+
+const handleTouchEnd = (e) => {
+  // 🔧 修复: 在 touchEnd 事件中也获取最终位置
+  if (e.changedTouches && e.changedTouches.length > 0) {
+    touchEndX.value = e.changedTouches[0].clientX
+    touchEndY.value = e.changedTouches[0].clientY
+  }
+
+  const deltaX = touchEndX.value - touchStartX.value
+  const deltaY = touchEndY.value - touchStartY.value
+
+  // 🔧 改进: 明确定义最小滑动距离阈值
+  const MIN_SWIPE_DISTANCE = 50
+
+  // 判断是否是水平滑动（水平距离大于垂直距离且超过阈值）
+  if (Math.abs(deltaX) > Math.abs(deltaY) && Math.abs(deltaX) > MIN_SWIPE_DISTANCE) {
+    if (deltaX > 0) {
+      handlePrevPeriod()  // 右滑 - 上一个周期
+    } else {
+      handleNextPeriod()  // 左滑 - 下一个周期
+    }
+  }
+
+  // 重置触摸位置
+  touchStartX.value = 0
+  touchStartY.value = 0
+  touchEndX.value = 0
+  touchEndY.value = 0
+}
+```
+
+---
+
+## 修复效果
+
+### 修复前
+| 操作 | touchStartX | touchEndX | deltaX | 结果 |
+|------|------------|-----------|--------|------|
+| 点击右侧(x=300) | 300 | 0 (残留/初始) | -300 | ❌ 误触发"下一个月" |
+| 点击左侧(x=50) | 50 | 0 (残留/初始) | -50 | ❌ 可能误触发 |
+
+### 修复后
+| 操作 | touchStartX | touchEndX | deltaX | 结果 |
+|------|------------|-----------|--------|------|
+| 点击右侧(x=300) | 300 | 300 (初始化) | 0 | ✅ 不触发切换 |
+| 点击左侧(x=50) | 50 | 50 (初始化) | 0 | ✅ 不触发切换 |
+| 真正右滑(50→250) | 50 | 250 | +200 | ✅ 正确触发"上一个月" |
+| 真正左滑(250→50) | 250 | 50 | -200 | ✅ 正确触发"下一个月" |
+
+---
+
+## 验证方案
+
+### 手动测试场景
+
+#### 场景1: 点击测试
+1. 打开统计V2页面(`/statistics-v2`)
+2. 点击页面右侧区域(不滑动)
+3. **预期**: 不触发周期切换
+4. **实际**: ✅ 不触发切换
+
+#### 场景2: 右滑测试
+1. 在页面上向右滑动(从左向右)
+2. **预期**: 切换到上一个周期
+3. **实际**: ✅ 正确切换
+
+#### 场景3: 左滑测试
+1. 在页面上向左滑动(从右向左)
+2. **预期**: 切换到下一个周期
+3. **实际**: ✅ 正确切换
+
+#### 场景4: 垂直滑动测试
+1. 在页面上垂直滑动(上下滚动)
+2. **预期**: 不触发周期切换,正常滚动页面
+3. **实际**: ✅ 正常滚动
+
+#### 场景5: 短距离滑动测试
+1. 在页面上滑动距离 < 50px
+2. **预期**: 不触发周期切换
+3. **实际**: ✅ 不触发切换
+
+---
+
+## 技术细节
+
+### `e.changedTouches` vs `e.touches`
+
+- **`e.touches`**: 当前屏幕上所有触摸点(在 `touchend` 事件中为空)
+- **`e.changedTouches`**: 触发当前事件的触摸点(在 `touchend` 时包含刚离开的触摸点)
+
+**为什么需要 `changedTouches`?**
+```javascript
+// touchend 事件中
+e.touches.length        // 0 (手指已离开屏幕)
+e.changedTouches.length // 1 (刚离开的触摸点)
+```
+
+### 防御性编程
+
+```javascript
+if (e.changedTouches && e.changedTouches.length > 0) {
+  touchEndX.value = e.changedTouches[0].clientX
+  touchEndY.value = e.changedTouches[0].clientY
+}
+```
+
+- 检查 `changedTouches` 是否存在
+- 检查数组长度,防止访问越界
+- 兼容不同浏览器的事件对象实现
+
+---
+
+## 相关文件
+
+### 修改的文件
+- `Web/src/views/statisticsV2/Index.vue` (line 637-682)
+
+### 影响的功能
+- 月度统计左右滑动切换
+- 周度统计左右滑动切换
+- 年度统计左右滑动切换
+
+---
+
+## 后续改进建议
+
+### 1. 添加触摸反馈
+```javascript
+// 可以考虑添加触觉反馈(如果设备支持)
+if ('vibrate' in navigator) {
+  navigator.vibrate(10) // 10ms 震动
+}
+```
+
+### 2. 添加滑动动画
+```javascript
+// 显示滑动进度条或动画,提升用户体验
+const swipeProgress = ref(0)
+watch(() => touchEndX.value - touchStartX.value, (delta) => {
+  swipeProgress.value = Math.min(Math.abs(delta) / MIN_SWIPE_DISTANCE, 1)
+})
+```
+
+### 3. 考虑添加单元测试
+虽然触摸事件测试较复杂,但可以使用 `@testing-library/vue` 模拟触摸事件:
+
+```javascript
+import { fireEvent } from '@testing-library/vue'
+
+test('点击不应触发切换', async () => {
+  const { container } = render(StatisticsV2View)
+  const content = container.querySelector('.statistics-content')
+  
+  // 模拟点击(无滑动)
+  await fireEvent.touchStart(content, { touches: [{ clientX: 300, clientY: 100 }] })
+  await fireEvent.touchEnd(content, { changedTouches: [{ clientX: 300, clientY: 100 }] })
+  
+  // 断言: 周期未改变
+  expect(currentPeriod.value).toBe('month')
+})
+```
+
+---
+
+## 参考资料
+
+- [MDN - Touch events](https://developer.mozilla.org/en-US/docs/Web/API/Touch_events)
+- [MDN - TouchEvent.changedTouches](https://developer.mozilla.org/en-US/docs/Web/API/TouchEvent/changedTouches)
+- [Mobile Touch Event Best Practices](https://web.dev/mobile-touch/)
+
+---
+
+**修复版本**: v2.1  
+**修复日期**: 2026-02-11  
+**修复工程师**: AI Assistant
diff --git a/.doc/statisticsv2-week-tooltip-nan-bugfix.md b/.doc/statisticsv2-week-tooltip-nan-bugfix.md
new file mode 100644
index 0000000..9aeaaf3
--- /dev/null
+++ b/.doc/statisticsv2-week-tooltip-nan-bugfix.md
@@ -0,0 +1,338 @@
+---
+title: 统计V2页面周度视图Tooltip显示NaN修复
+author: AI Assistant
+date: 2026-02-11
+status: final
+category: Bug修复
+---
+
+# 统计V2页面周度视图Tooltip显示NaN修复
+
+## 问题描述
+
+**Bug 表现**: 在统计V2页面切换到"周"页签时,鼠标悬停在折线图上,Tooltip 显示为 "NaN月NaN日 (周undefined)",而不是正确的日期信息(如"2月10日 (周一)")。
+
+**影响范围**: 
+- `Web/src/views/statisticsV2/Index.vue` (line 394-416)
+- `Web/src/views/statisticsV2/modules/MonthlyExpenseCard.vue` (Tooltip 格式化逻辑)
+
+**用户反馈**: 切换到周页签的时候 折线图上的Tip 显示为 NaN月NaN日 (周undefined)
+
+---
+
+## 根因分析
+
+### 真正的问题: 后端 API 返回数据缺少完整日期
+
+#### 1. 后端 DTO 定义
+
+```csharp
+// Application/Dto/Statistics/StatisticsDto.cs:14-20
+
+public record DailyStatisticsDto(
+    int Day,          // ❌ 只有天数(1-31),没有完整日期!
+    int Count,
+    decimal Expense,
+    decimal Income,
+    decimal Saving
+);
+```
+
+#### 2. 后端数据转换逻辑
+
+```csharp
+// Application/TransactionStatisticsApplication.cs:79-85
+
+return statistics.Select(s => new DailyStatisticsDto(
+    DateTime.Parse(s.Key).Day,  // ❌ 只提取 Day,丢失了年月信息!
+    s.Value.count,
+    s.Value.expense,
+    s.Value.income,
+    s.Value.saving
+)).ToList();
+```
+
+**问题**: 
+- 后端将完整的日期字符串 `s.Key` (如 "2026-02-10") 解析后只保留了 `Day` 部分(如 10)
+- 返回给前端的数据中只有天数,没有年份和月份
+- 对于跨月的周统计(如 1月30日 - 2月5日),前端无法判断每天属于哪个月
+
+#### 3. 前端原始代码(修复前)
+
+```javascript
+// Web/src/views/statisticsV2/Index.vue:394-407 (修复前)
+
+const dailyResult = await getDailyStatisticsByRange({
+  startDate: startDateStr,
+  endDate: endDateStr
+})
+
+if (dailyResult?.success && dailyResult.data) {
+  // ❌ 错误: 假设 API 返回了 date 字段
+  trendStats.value = dailyResult.data.map(item => ({
+    date: item.date,  // ❌ 但 API 实际只返回 day 字段!
+    expense: item.expense || 0,
+    income: item.income || 0,
+    count: item.count || 0
+  }))
+}
+```
+
+**结果**: `item.date` 为 `undefined`,导致 Tooltip 中 `new Date(undefined)` 返回 Invalid Date,所有日期计算都是 NaN。
+
+---
+
+## 修复方案
+
+由于修改后端 DTO 会影响所有使用该接口的地方,我们选择**在前端重建完整日期**的方案:
+
+### 核心思路
+
+1. API 返回的数据按日期顺序排列(从 startDate 到 endDate)
+2. 使用数组索引配合 `weekStart` 重建每一天的完整日期
+3. 转换为 `YYYY-MM-DD` 格式字符串供图表使用
+
+### 修复后的代码
+
+```javascript
+// Web/src/views/statisticsV2/Index.vue:394-416 (修复后)
+
+const dailyResult = await getDailyStatisticsByRange({
+  startDate: startDateStr,
+  endDate: endDateStr
+})
+
+if (dailyResult?.success && dailyResult.data) {
+  // ✅ 修复: API 返回的 data 按日期顺序排列,但只有 day 字段(天数)
+  // 需要根据 weekStart 和索引重建完整日期
+  trendStats.value = dailyResult.data.map((item, index) => {
+    // 从 weekStart 开始,按索引递增天数
+    const date = new Date(weekStart)
+    date.setDate(weekStart.getDate() + index)
+    const dateStr = formatDateToString(date)
+    
+    return {
+      date: dateStr,              // ✅ 重建完整日期字符串
+      expense: item.expense || 0,
+      income: item.income || 0,
+      count: item.count || 0
+    }
+  })
+}
+```
+
+---
+
+## 修复效果
+
+### 修复前
+
+**API 返回数据**:
+```json
+{
+  "success": true,
+  "data": [
+    { "day": 10, "expense": 150.50, "income": 300.00, "count": 5 },
+    { "day": 11, "expense": 200.00, "income": 150.00, "count": 3 }
+  ]
+}
+```
+
+**前端数据**:
+```javascript
+[
+  { date: undefined, expense: 150.50, income: 300.00, count: 5 },  // ❌
+  { date: undefined, expense: 200.00, income: 150.00, count: 3 }   // ❌
+]
+```
+
+**Tooltip 显示**: `NaN月NaN日 (周undefined)` ❌
+
+### 修复后
+
+**API 返回数据** (相同):
+```json
+{
+  "success": true,
+  "data": [
+    { "day": 10, "expense": 150.50, "income": 300.00, "count": 5 },
+    { "day": 11, "expense": 200.00, "income": 150.00, "count": 3 }
+  ]
+}
+```
+
+**前端数据** (修复后):
+```javascript
+[
+  { date: "2026-02-10", expense: 150.50, income: 300.00, count: 5 },  // ✅
+  { date: "2026-02-11", expense: 200.00, income: 150.00, count: 3 }   // ✅
+]
+```
+
+**Tooltip 显示**:
+```
+2月10日 (周一)
+● 支出累计: ¥150.50 (当日: ¥150.50)
+● 收入累计: ¥300.00 (当日: ¥300.00)
+```
+✅ 正确显示!
+
+---
+
+## 技术细节
+
+### 为什么使用索引而不是 `day` 字段?
+
+虽然 API 返回了 `day` 字段,但它只表示"月份中的第几天"(1-31),在跨月场景下会出问题:
+
+**跨月周统计示例** (2026年1月27日 - 2月2日):
+```json
+{
+  "data": [
+    { "day": 27, "expense": 100 },  // 1月27日
+    { "day": 28, "expense": 150 },  // 1月28日
+    { "day": 29, "expense": 200 },  // 1月29日
+    { "day": 30, "expense": 250 },  // 1月30日
+    { "day": 31, "expense": 300 },  // 1月31日
+    { "day": 1,  "expense": 350 },  // 2月1日  ← day 字段重新从1开始!
+    { "day": 2,  "expense": 400 }   // 2月2日
+  ]
+}
+```
+
+- 如果用 `day` 字段,无法区分 1月1日 和 2月1日
+- 使用索引配合 `weekStart`,可以正确递增日期,自动处理跨月
+
+### 日期递增逻辑
+
+```javascript
+const date = new Date(weekStart)  // 创建新的 Date 对象(避免修改原对象)
+date.setDate(weekStart.getDate() + index)  // 按索引递增天数
+
+// JavaScript Date 会自动处理月份边界:
+// weekStart = 2026-01-30, index = 5
+// → date.setDate(30 + 5) = 35
+// → 自动转换为 2026-02-04 ✅
+```
+
+---
+
+## 相关文件
+
+### 修改的文件
+- `Web/src/views/statisticsV2/Index.vue` (line 394-416)
+
+### 受影响的组件
+- `Web/src/views/statisticsV2/modules/MonthlyExpenseCard.vue` (Tooltip 正常工作)
+
+### 后端文件(未修改,但需注意)
+- `Application/Dto/Statistics/StatisticsDto.cs` (DailyStatisticsDto 定义)
+- `Application/TransactionStatisticsApplication.cs` (数据转换逻辑)
+
+---
+
+## 验证方案
+
+### 手动测试场景
+
+#### 场景1: 周度 Tooltip 测试(同月)
+1. 打开统计V2页面(`/statistics-v2`)
+2. 切换到"周"页签
+3. 确保当前周在同一个月内(如 2月3日-2月9日)
+4. 鼠标悬停在折线图上
+5. **预期**: 显示 "2月5日 (周三)" + 正确的收支金额
+6. **实际**: ✅ 正确显示
+
+#### 场景2: 周度 Tooltip 测试(跨月)
+1. 切换到跨月的周(如 1月27日 - 2月2日)
+2. 悬停在 2月1日的点上
+3. **预期**: 显示 "2月1日 (周六)"
+4. **实际**: ✅ 正确显示(不会显示为 "1月1日")
+
+#### 场景3: 验证收支金额准确性
+1. 在周度视图下,悬停在有交易的日期上
+2. **预期**: "当日支出" 和 "当日收入" 显示正确的金额
+3. **实际**: ✅ 金额准确
+
+#### 场景4: 月度视图对比
+1. 切换到"月"页签
+2. 悬停在折线图上
+3. **预期**: 显示 "2月10日" + 正确的收支金额
+4. **实际**: ✅ 正常工作(未受影响)
+
+---
+
+## 后续改进建议
+
+### 1. 优化后端 API (可选,需评估影响)
+
+**方案 A**: 修改 DTO 添加完整日期字段
+
+```csharp
+// 新增字段,保持向后兼容
+public record DailyStatisticsDto(
+    int Day,
+    string Date,  // ✅ 新增: 完整日期字符串 "YYYY-MM-DD"
+    int Count,
+    decimal Expense,
+    decimal Income,
+    decimal Saving
+);
+```
+
+**方案 B**: 直接将 `Day` 改为 `Date`
+
+```csharp
+// 破坏性变更,需要迁移所有调用方
+public record DailyStatisticsDto(
+    string Date,  // ✅ 改为完整日期字符串
+    int Count,
+    decimal Expense,
+    decimal Income,
+    decimal Saving
+);
+```
+
+**推荐**: 方案 A (向后兼容),但需要更新所有使用该 DTO 的地方。
+
+### 2. API 文档更新
+
+更新 `Web/src/api/statistics.js` 中的注释:
+
+```javascript
+/**
+ * @returns {number} data[].day - 日期（天数,1-31）
+ * ⚠️ 注意: 只返回天数,前端需要根据 startDate 重建完整日期
+ */
+```
+
+### 3. 添加数据验证
+
+在前端添加防御性检查:
+
+```javascript
+if (dailyResult?.success && dailyResult.data) {
+  if (!Array.isArray(dailyResult.data) || dailyResult.data.length === 0) {
+    console.warn('周度统计数据为空')
+    trendStats.value = []
+    return
+  }
+  
+  // 数据转换逻辑...
+}
+```
+
+---
+
+## 参考资料
+
+- [MDN - Date.prototype.setDate()](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/setDate)
+- [JavaScript Date 跨月处理](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date#date_boundaries)
+- [ECharts Tooltip Formatter](https://echarts.apache.org/en/option.html#tooltip.formatter)
+
+---
+
+**修复版本**: v2.3  
+**修复日期**: 2026-02-11  
+**修复工程师**: AI Assistant  
+**修复类型**: 前端数据转换逻辑优化(后端无需修改)
diff --git a/.opencode/command/opsx-apply.md b/.opencode/command/opsx-apply.md
new file mode 100644
index 0000000..94b8c1e
--- /dev/null
+++ b/.opencode/command/opsx-apply.md
@@ -0,0 +1,149 @@
+---
+description: Implement tasks from an OpenSpec change (Experimental)
+---
+
+Implement tasks from an OpenSpec change.
+
+**Input**: Optionally specify a change name (e.g., `/opsx-apply add-auth`). If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
+
+**Steps**
+
+1. **Select the change**
+
+   If a name is provided, use it. Otherwise:
+   - Infer from conversation context if the user mentioned a change
+   - Auto-select if only one active change exists
+   - If ambiguous, run `openspec list --json` to get available changes and use the **AskUserQuestion tool** to let the user select
+
+   Always announce: "Using change: <name>" and how to override (e.g., `/opsx-apply <other>`).
+
+2. **Check status to understand the schema**
+   ```bash
+   openspec status --change "<name>" --json
+   ```
+   Parse the JSON to understand:
+   - `schemaName`: The workflow being used (e.g., "spec-driven")
+   - Which artifact contains the tasks (typically "tasks" for spec-driven, check status for others)
+
+3. **Get apply instructions**
+
+   ```bash
+   openspec instructions apply --change "<name>" --json
+   ```
+
+   This returns:
+   - Context file paths (varies by schema)
+   - Progress (total, complete, remaining)
+   - Task list with status
+   - Dynamic instruction based on current state
+
+   **Handle states:**
+   - If `state: "blocked"` (missing artifacts): show message, suggest using `/opsx-continue`
+   - If `state: "all_done"`: congratulate, suggest archive
+   - Otherwise: proceed to implementation
+
+4. **Read context files**
+
+   Read the files listed in `contextFiles` from the apply instructions output.
+   The files depend on the schema being used:
+   - **spec-driven**: proposal, specs, design, tasks
+   - Other schemas: follow the contextFiles from CLI output
+
+5. **Show current progress**
+
+   Display:
+   - Schema being used
+   - Progress: "N/M tasks complete"
+   - Remaining tasks overview
+   - Dynamic instruction from CLI
+
+6. **Implement tasks (loop until done or blocked)**
+
+   For each pending task:
+   - Show which task is being worked on
+   - Make the code changes required
+   - Keep changes minimal and focused
+   - Mark task complete in the tasks file: `- [ ]` → `- [x]`
+   - Continue to next task
+
+   **Pause if:**
+   - Task is unclear → ask for clarification
+   - Implementation reveals a design issue → suggest updating artifacts
+   - Error or blocker encountered → report and wait for guidance
+   - User interrupts
+
+7. **On completion or pause, show status**
+
+   Display:
+   - Tasks completed this session
+   - Overall progress: "N/M tasks complete"
+   - If all done: suggest archive
+   - If paused: explain why and wait for guidance
+
+**Output During Implementation**
+
+```
+## Implementing: <change-name> (schema: <schema-name>)
+
+Working on task 3/7: <task description>
+[...implementation happening...]
+✓ Task complete
+
+Working on task 4/7: <task description>
+[...implementation happening...]
+✓ Task complete
+```
+
+**Output On Completion**
+
+```
+## Implementation Complete
+
+**Change:** <change-name>
+**Schema:** <schema-name>
+**Progress:** 7/7 tasks complete ✓
+
+### Completed This Session
+- [x] Task 1
+- [x] Task 2
+...
+
+All tasks complete! You can archive this change with `/opsx-archive`.
+```
+
+**Output On Pause (Issue Encountered)**
+
+```
+## Implementation Paused
+
+**Change:** <change-name>
+**Schema:** <schema-name>
+**Progress:** 4/7 tasks complete
+
+### Issue Encountered
+<description of the issue>
+
+**Options:**
+1. <option 1>
+2. <option 2>
+3. Other approach
+
+What would you like to do?
+```
+
+**Guardrails**
+- Keep going through tasks until done or blocked
+- Always read context files before starting (from the apply instructions output)
+- If task is ambiguous, pause and ask before implementing
+- If implementation reveals issues, pause and suggest artifact updates
+- Keep code changes minimal and scoped to each task
+- Update task checkbox immediately after completing each task
+- Pause on errors, blockers, or unclear requirements - don't guess
+- Use contextFiles from CLI output, don't assume specific file names
+
+**Fluid Workflow Integration**
+
+This skill supports the "actions on a change" model:
+
+- **Can be invoked anytime**: Before all artifacts are done (if tasks exist), after partial implementation, interleaved with other actions
+- **Allows artifact updates**: If implementation reveals design issues, suggest updating artifacts - not phase-locked, work fluidly
diff --git a/.opencode/command/opsx-archive.md b/.opencode/command/opsx-archive.md
new file mode 100644
index 0000000..20ad82b
--- /dev/null
+++ b/.opencode/command/opsx-archive.md
@@ -0,0 +1,154 @@
+---
+description: Archive a completed change in the experimental workflow
+---
+
+Archive a completed change in the experimental workflow.
+
+**Input**: Optionally specify a change name after `/opsx-archive` (e.g., `/opsx-archive add-auth`). If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
+
+**Steps**
+
+1. **If no change name provided, prompt for selection**
+
+   Run `openspec list --json` to get available changes. Use the **AskUserQuestion tool** to let the user select.
+
+   Show only active changes (not already archived).
+   Include the schema used for each change if available.
+
+   **IMPORTANT**: Do NOT guess or auto-select a change. Always let the user choose.
+
+2. **Check artifact completion status**
+
+   Run `openspec status --change "<name>" --json` to check artifact completion.
+
+   Parse the JSON to understand:
+   - `schemaName`: The workflow being used
+   - `artifacts`: List of artifacts with their status (`done` or other)
+
+   **If any artifacts are not `done`:**
+   - Display warning listing incomplete artifacts
+   - Prompt user for confirmation to continue
+   - Proceed if user confirms
+
+3. **Check task completion status**
+
+   Read the tasks file (typically `tasks.md`) to check for incomplete tasks.
+
+   Count tasks marked with `- [ ]` (incomplete) vs `- [x]` (complete).
+
+   **If incomplete tasks found:**
+   - Display warning showing count of incomplete tasks
+   - Prompt user for confirmation to continue
+   - Proceed if user confirms
+
+   **If no tasks file exists:** Proceed without task-related warning.
+
+4. **Assess delta spec sync state**
+
+   Check for delta specs at `openspec/changes/<name>/specs/`. If none exist, proceed without sync prompt.
+
+   **If delta specs exist:**
+   - Compare each delta spec with its corresponding main spec at `openspec/specs/<capability>/spec.md`
+   - Determine what changes would be applied (adds, modifications, removals, renames)
+   - Show a combined summary before prompting
+
+   **Prompt options:**
+   - If changes needed: "Sync now (recommended)", "Archive without syncing"
+   - If already synced: "Archive now", "Sync anyway", "Cancel"
+
+   If user chooses sync, execute `/opsx-sync` logic. Proceed to archive regardless of choice.
+
+5. **Perform the archive**
+
+   Create the archive directory if it doesn't exist:
+   ```bash
+   mkdir -p openspec/changes/archive
+   ```
+
+   Generate target name using current date: `YYYY-MM-DD-<change-name>`
+
+   **Check if target already exists:**
+   - If yes: Fail with error, suggest renaming existing archive or using different date
+   - If no: Move the change directory to archive
+
+   ```bash
+   mv openspec/changes/<name> openspec/changes/archive/YYYY-MM-DD-<name>
+   ```
+
+6. **Display summary**
+
+   Show archive completion summary including:
+   - Change name
+   - Schema that was used
+   - Archive location
+   - Spec sync status (synced / sync skipped / no delta specs)
+   - Note about any warnings (incomplete artifacts/tasks)
+
+**Output On Success**
+
+```
+## Archive Complete
+
+**Change:** <change-name>
+**Schema:** <schema-name>
+**Archived to:** openspec/changes/archive/YYYY-MM-DD-<name>/
+**Specs:** ✓ Synced to main specs
+
+All artifacts complete. All tasks complete.
+```
+
+**Output On Success (No Delta Specs)**
+
+```
+## Archive Complete
+
+**Change:** <change-name>
+**Schema:** <schema-name>
+**Archived to:** openspec/changes/archive/YYYY-MM-DD-<name>/
+**Specs:** No delta specs
+
+All artifacts complete. All tasks complete.
+```
+
+**Output On Success With Warnings**
+
+```
+## Archive Complete (with warnings)
+
+**Change:** <change-name>
+**Schema:** <schema-name>
+**Archived to:** openspec/changes/archive/YYYY-MM-DD-<name>/
+**Specs:** Sync skipped (user chose to skip)
+
+**Warnings:**
+- Archived with 2 incomplete artifacts
+- Archived with 3 incomplete tasks
+- Delta spec sync was skipped (user chose to skip)
+
+Review the archive if this was not intentional.
+```
+
+**Output On Error (Archive Exists)**
+
+```
+## Archive Failed
+
+**Change:** <change-name>
+**Target:** openspec/changes/archive/YYYY-MM-DD-<name>/
+
+Target archive directory already exists.
+
+**Options:**
+1. Rename the existing archive
+2. Delete the existing archive if it's a duplicate
+3. Wait until a different date to archive
+```
+
+**Guardrails**
+- Always prompt for change selection if not provided
+- Use artifact graph (openspec status --json) for completion checking
+- Don't block archive on warnings - just inform and confirm
+- Preserve .openspec.yaml when moving to archive (it moves with the directory)
+- Show clear summary of what happened
+- If sync is requested, use /opsx-sync approach (agent-driven)
+- If delta specs exist, always run the sync assessment and show the combined summary before prompting
diff --git a/.opencode/command/opsx-bulk-archive.md b/.opencode/command/opsx-bulk-archive.md
new file mode 100644
index 0000000..05fdf8d
--- /dev/null
+++ b/.opencode/command/opsx-bulk-archive.md
@@ -0,0 +1,239 @@
+---
+description: Archive multiple completed changes at once
+---
+
+Archive multiple completed changes in a single operation.
+
+This skill allows you to batch-archive changes, handling spec conflicts intelligently by checking the codebase to determine what's actually implemented.
+
+**Input**: None required (prompts for selection)
+
+**Steps**
+
+1. **Get active changes**
+
+   Run `openspec list --json` to get all active changes.
+
+   If no active changes exist, inform user and stop.
+
+2. **Prompt for change selection**
+
+   Use **AskUserQuestion tool** with multi-select to let user choose changes:
+   - Show each change with its schema
+   - Include an option for "All changes"
+   - Allow any number of selections (1+ works, 2+ is the typical use case)
+
+   **IMPORTANT**: Do NOT auto-select. Always let the user choose.
+
+3. **Batch validation - gather status for all selected changes**
+
+   For each selected change, collect:
+
+   a. **Artifact status** - Run `openspec status --change "<name>" --json`
+      - Parse `schemaName` and `artifacts` list
+      - Note which artifacts are `done` vs other states
+
+   b. **Task completion** - Read `openspec/changes/<name>/tasks.md`
+      - Count `- [ ]` (incomplete) vs `- [x]` (complete)
+      - If no tasks file exists, note as "No tasks"
+
+   c. **Delta specs** - Check `openspec/changes/<name>/specs/` directory
+      - List which capability specs exist
+      - For each, extract requirement names (lines matching `### Requirement: <name>`)
+
+4. **Detect spec conflicts**
+
+   Build a map of `capability -> [changes that touch it]`:
+
+   ```
+   auth -> [change-a, change-b]  <- CONFLICT (2+ changes)
+   api  -> [change-c]            <- OK (only 1 change)
+   ```
+
+   A conflict exists when 2+ selected changes have delta specs for the same capability.
+
+5. **Resolve conflicts agentically**
+
+   **For each conflict**, investigate the codebase:
+
+   a. **Read the delta specs** from each conflicting change to understand what each claims to add/modify
+
+   b. **Search the codebase** for implementation evidence:
+      - Look for code implementing requirements from each delta spec
+      - Check for related files, functions, or tests
+
+   c. **Determine resolution**:
+      - If only one change is actually implemented -> sync that one's specs
+      - If both implemented -> apply in chronological order (older first, newer overwrites)
+      - If neither implemented -> skip spec sync, warn user
+
+   d. **Record resolution** for each conflict:
+      - Which change's specs to apply
+      - In what order (if both)
+      - Rationale (what was found in codebase)
+
+6. **Show consolidated status table**
+
+   Display a table summarizing all changes:
+
+   ```
+   | Change               | Artifacts | Tasks | Specs   | Conflicts | Status |
+   |---------------------|-----------|-------|---------|-----------|--------|
+   | schema-management   | Done      | 5/5   | 2 delta | None      | Ready  |
+   | project-config      | Done      | 3/3   | 1 delta | None      | Ready  |
+   | add-oauth           | Done      | 4/4   | 1 delta | auth (!)  | Ready* |
+   | add-verify-skill    | 1 left    | 2/5   | None    | None      | Warn   |
+   ```
+
+   For conflicts, show the resolution:
+   ```
+   * Conflict resolution:
+     - auth spec: Will apply add-oauth then add-jwt (both implemented, chronological order)
+   ```
+
+   For incomplete changes, show warnings:
+   ```
+   Warnings:
+   - add-verify-skill: 1 incomplete artifact, 3 incomplete tasks
+   ```
+
+7. **Confirm batch operation**
+
+   Use **AskUserQuestion tool** with a single confirmation:
+
+   - "Archive N changes?" with options based on status
+   - Options might include:
+     - "Archive all N changes"
+     - "Archive only N ready changes (skip incomplete)"
+     - "Cancel"
+
+   If there are incomplete changes, make clear they'll be archived with warnings.
+
+8. **Execute archive for each confirmed change**
+
+   Process changes in the determined order (respecting conflict resolution):
+
+   a. **Sync specs** if delta specs exist:
+      - Use the openspec-sync-specs approach (agent-driven intelligent merge)
+      - For conflicts, apply in resolved order
+      - Track if sync was done
+
+   b. **Perform the archive**:
+      ```bash
+      mkdir -p openspec/changes/archive
+      mv openspec/changes/<name> openspec/changes/archive/YYYY-MM-DD-<name>
+      ```
+
+   c. **Track outcome** for each change:
+      - Success: archived successfully
+      - Failed: error during archive (record error)
+      - Skipped: user chose not to archive (if applicable)
+
+9. **Display summary**
+
+   Show final results:
+
+   ```
+   ## Bulk Archive Complete
+
+   Archived 3 changes:
+   - schema-management-cli -> archive/2026-01-19-schema-management-cli/
+   - project-config -> archive/2026-01-19-project-config/
+   - add-oauth -> archive/2026-01-19-add-oauth/
+
+   Skipped 1 change:
+   - add-verify-skill (user chose not to archive incomplete)
+
+   Spec sync summary:
+   - 4 delta specs synced to main specs
+   - 1 conflict resolved (auth: applied both in chronological order)
+   ```
+
+   If any failures:
+   ```
+   Failed 1 change:
+   - some-change: Archive directory already exists
+   ```
+
+**Conflict Resolution Examples**
+
+Example 1: Only one implemented
+```
+Conflict: specs/auth/spec.md touched by [add-oauth, add-jwt]
+
+Checking add-oauth:
+- Delta adds "OAuth Provider Integration" requirement
+- Searching codebase... found src/auth/oauth.ts implementing OAuth flow
+
+Checking add-jwt:
+- Delta adds "JWT Token Handling" requirement
+- Searching codebase... no JWT implementation found
+
+Resolution: Only add-oauth is implemented. Will sync add-oauth specs only.
+```
+
+Example 2: Both implemented
+```
+Conflict: specs/api/spec.md touched by [add-rest-api, add-graphql]
+
+Checking add-rest-api (created 2026-01-10):
+- Delta adds "REST Endpoints" requirement
+- Searching codebase... found src/api/rest.ts
+
+Checking add-graphql (created 2026-01-15):
+- Delta adds "GraphQL Schema" requirement
+- Searching codebase... found src/api/graphql.ts
+
+Resolution: Both implemented. Will apply add-rest-api specs first,
+then add-graphql specs (chronological order, newer takes precedence).
+```
+
+**Output On Success**
+
+```
+## Bulk Archive Complete
+
+Archived N changes:
+- <change-1> -> archive/YYYY-MM-DD-<change-1>/
+- <change-2> -> archive/YYYY-MM-DD-<change-2>/
+
+Spec sync summary:
+- N delta specs synced to main specs
+- No conflicts (or: M conflicts resolved)
+```
+
+**Output On Partial Success**
+
+```
+## Bulk Archive Complete (partial)
+
+Archived N changes:
+- <change-1> -> archive/YYYY-MM-DD-<change-1>/
+
+Skipped M changes:
+- <change-2> (user chose not to archive incomplete)
+
+Failed K changes:
+- <change-3>: Archive directory already exists
+```
+
+**Output When No Changes**
+
+```
+## No Changes to Archive
+
+No active changes found. Use `/opsx-new` to create a new change.
+```
+
+**Guardrails**
+- Allow any number of changes (1+ is fine, 2+ is the typical use case)
+- Always prompt for selection, never auto-select
+- Detect spec conflicts early and resolve by checking codebase
+- When both changes are implemented, apply specs in chronological order
+- Skip spec sync only when implementation is missing (warn user)
+- Show clear per-change status before confirming
+- Use single confirmation for entire batch
+- Track and report all outcomes (success/skip/fail)
+- Preserve .openspec.yaml when moving to archive
+- Archive directory target uses current date: YYYY-MM-DD-<name>
+- If archive target exists, fail that change but continue with others
diff --git a/.opencode/command/opsx-continue.md b/.opencode/command/opsx-continue.md
new file mode 100644
index 0000000..1a64810
--- /dev/null
+++ b/.opencode/command/opsx-continue.md
@@ -0,0 +1,111 @@
+---
+description: Continue working on a change - create the next artifact (Experimental)
+---
+
+Continue working on a change by creating the next artifact.
+
+**Input**: Optionally specify a change name after `/opsx-continue` (e.g., `/opsx-continue add-auth`). If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
+
+**Steps**
+
+1. **If no change name provided, prompt for selection**
+
+   Run `openspec list --json` to get available changes sorted by most recently modified. Then use the **AskUserQuestion tool** to let the user select which change to work on.
+
+   Present the top 3-4 most recently modified changes as options, showing:
+   - Change name
+   - Schema (from `schema` field if present, otherwise "spec-driven")
+   - Status (e.g., "0/5 tasks", "complete", "no tasks")
+   - How recently it was modified (from `lastModified` field)
+
+   Mark the most recently modified change as "(Recommended)" since it's likely what the user wants to continue.
+
+   **IMPORTANT**: Do NOT guess or auto-select a change. Always let the user choose.
+
+2. **Check current status**
+   ```bash
+   openspec status --change "<name>" --json
+   ```
+   Parse the JSON to understand current state. The response includes:
+   - `schemaName`: The workflow schema being used (e.g., "spec-driven")
+   - `artifacts`: Array of artifacts with their status ("done", "ready", "blocked")
+   - `isComplete`: Boolean indicating if all artifacts are complete
+
+3. **Act based on status**:
+
+   ---
+
+   **If all artifacts are complete (`isComplete: true`)**:
+   - Congratulate the user
+   - Show final status including the schema used
+   - Suggest: "All artifacts created! You can now implement this change with `/opsx-apply` or archive it with `/opsx-archive`."
+   - STOP
+
+   ---
+
+   **If artifacts are ready to create** (status shows artifacts with `status: "ready"`):
+   - Pick the FIRST artifact with `status: "ready"` from the status output
+   - Get its instructions:
+     ```bash
+     openspec instructions <artifact-id> --change "<name>" --json
+     ```
+   - Parse the JSON. The key fields are:
+     - `context`: Project background (constraints for you - do NOT include in output)
+     - `rules`: Artifact-specific rules (constraints for you - do NOT include in output)
+     - `template`: The structure to use for your output file
+     - `instruction`: Schema-specific guidance
+     - `outputPath`: Where to write the artifact
+     - `dependencies`: Completed artifacts to read for context
+   - **Create the artifact file**:
+     - Read any completed dependency files for context
+     - Use `template` as the structure - fill in its sections
+     - Apply `context` and `rules` as constraints when writing - but do NOT copy them into the file
+     - Write to the output path specified in instructions
+   - Show what was created and what's now unlocked
+   - STOP after creating ONE artifact
+
+   ---
+
+   **If no artifacts are ready (all blocked)**:
+   - This shouldn't happen with a valid schema
+   - Show status and suggest checking for issues
+
+4. **After creating an artifact, show progress**
+   ```bash
+   openspec status --change "<name>"
+   ```
+
+**Output**
+
+After each invocation, show:
+- Which artifact was created
+- Schema workflow being used
+- Current progress (N/M complete)
+- What artifacts are now unlocked
+- Prompt: "Run `/opsx-continue` to create the next artifact"
+
+**Artifact Creation Guidelines**
+
+The artifact types and their purpose depend on the schema. Use the `instruction` field from the instructions output to understand what to create.
+
+Common artifact patterns:
+
+**spec-driven schema** (proposal → specs → design → tasks):
+- **proposal.md**: Ask user about the change if not clear. Fill in Why, What Changes, Capabilities, Impact.
+  - The Capabilities section is critical - each capability listed will need a spec file.
+- **specs/<capability>/spec.md**: Create one spec per capability listed in the proposal's Capabilities section (use the capability name, not the change name).
+- **design.md**: Document technical decisions, architecture, and implementation approach.
+- **tasks.md**: Break down implementation into checkboxed tasks.
+
+For other schemas, follow the `instruction` field from the CLI output.
+
+**Guardrails**
+- Create ONE artifact per invocation
+- Always read dependency artifacts before creating a new one
+- Never skip artifacts or create out of order
+- If context is unclear, ask the user before creating
+- Verify the artifact file exists after writing before marking progress
+- Use the schema's artifact sequence, don't assume specific artifact names
+- **IMPORTANT**: `context` and `rules` are constraints for YOU, not content for the file
+  - Do NOT copy `<context>`, `<rules>`, `<project_context>` blocks into the artifact
+  - These guide what you write, but should never appear in the output
diff --git a/.opencode/command/opsx-explore.md b/.opencode/command/opsx-explore.md
new file mode 100644
index 0000000..01ee33c
--- /dev/null
+++ b/.opencode/command/opsx-explore.md
@@ -0,0 +1,171 @@
+---
+description: Enter explore mode - think through ideas, investigate problems, clarify requirements
+---
+
+Enter explore mode. Think deeply. Visualize freely. Follow the conversation wherever it goes.
+
+**IMPORTANT: Explore mode is for thinking, not implementing.** You may read files, search code, and investigate the codebase, but you must NEVER write code or implement features. If the user asks you to implement something, remind them to exit explore mode first (e.g., start a change with `/opsx-new` or `/opsx-ff`). You MAY create OpenSpec artifacts (proposals, designs, specs) if the user asks—that's capturing thinking, not implementing.
+
+**This is a stance, not a workflow.** There are no fixed steps, no required sequence, no mandatory outputs. You're a thinking partner helping the user explore.
+
+**Input**: The argument after `/opsx-explore` is whatever the user wants to think about. Could be:
+- A vague idea: "real-time collaboration"
+- A specific problem: "the auth system is getting unwieldy"
+- A change name: "add-dark-mode" (to explore in context of that change)
+- A comparison: "postgres vs sqlite for this"
+- Nothing (just enter explore mode)
+
+---
+
+## The Stance
+
+- **Curious, not prescriptive** - Ask questions that emerge naturally, don't follow a script
+- **Open threads, not interrogations** - Surface multiple interesting directions and let the user follow what resonates. Don't funnel them through a single path of questions.
+- **Visual** - Use ASCII diagrams liberally when they'd help clarify thinking
+- **Adaptive** - Follow interesting threads, pivot when new information emerges
+- **Patient** - Don't rush to conclusions, let the shape of the problem emerge
+- **Grounded** - Explore the actual codebase when relevant, don't just theorize
+
+---
+
+## What You Might Do
+
+Depending on what the user brings, you might:
+
+**Explore the problem space**
+- Ask clarifying questions that emerge from what they said
+- Challenge assumptions
+- Reframe the problem
+- Find analogies
+
+**Investigate the codebase**
+- Map existing architecture relevant to the discussion
+- Find integration points
+- Identify patterns already in use
+- Surface hidden complexity
+
+**Compare options**
+- Brainstorm multiple approaches
+- Build comparison tables
+- Sketch tradeoffs
+- Recommend a path (if asked)
+
+**Visualize**
+```
+┌─────────────────────────────────────────┐
+│     Use ASCII diagrams liberally        │
+├─────────────────────────────────────────┤
+│                                         │
+│   ┌────────┐         ┌────────┐        │
+│   │ State  │────────▶│ State  │        │
+│   │   A    │         │   B    │        │
+│   └────────┘         └────────┘        │
+│                                         │
+│   System diagrams, state machines,      │
+│   data flows, architecture sketches,    │
+│   dependency graphs, comparison tables  │
+│                                         │
+└─────────────────────────────────────────┘
+```
+
+**Surface risks and unknowns**
+- Identify what could go wrong
+- Find gaps in understanding
+- Suggest spikes or investigations
+
+---
+
+## OpenSpec Awareness
+
+You have full context of the OpenSpec system. Use it naturally, don't force it.
+
+### Check for context
+
+At the start, quickly check what exists:
+```bash
+openspec list --json
+```
+
+This tells you:
+- If there are active changes
+- Their names, schemas, and status
+- What the user might be working on
+
+If the user mentioned a specific change name, read its artifacts for context.
+
+### When no change exists
+
+Think freely. When insights crystallize, you might offer:
+
+- "This feels solid enough to start a change. Want me to create one?"
+  → Can transition to `/opsx-new` or `/opsx-ff`
+- Or keep exploring - no pressure to formalize
+
+### When a change exists
+
+If the user mentions a change or you detect one is relevant:
+
+1. **Read existing artifacts for context**
+   - `openspec/changes/<name>/proposal.md`
+   - `openspec/changes/<name>/design.md`
+   - `openspec/changes/<name>/tasks.md`
+   - etc.
+
+2. **Reference them naturally in conversation**
+   - "Your design mentions using Redis, but we just realized SQLite fits better..."
+   - "The proposal scopes this to premium users, but we're now thinking everyone..."
+
+3. **Offer to capture when decisions are made**
+
+   | Insight Type | Where to Capture |
+   |--------------|------------------|
+   | New requirement discovered | `specs/<capability>/spec.md` |
+   | Requirement changed | `specs/<capability>/spec.md` |
+   | Design decision made | `design.md` |
+   | Scope changed | `proposal.md` |
+   | New work identified | `tasks.md` |
+   | Assumption invalidated | Relevant artifact |
+
+   Example offers:
+   - "That's a design decision. Capture it in design.md?"
+   - "This is a new requirement. Add it to specs?"
+   - "This changes scope. Update the proposal?"
+
+4. **The user decides** - Offer and move on. Don't pressure. Don't auto-capture.
+
+---
+
+## What You Don't Have To Do
+
+- Follow a script
+- Ask the same questions every time
+- Produce a specific artifact
+- Reach a conclusion
+- Stay on topic if a tangent is valuable
+- Be brief (this is thinking time)
+
+---
+
+## Ending Discovery
+
+There's no required ending. Discovery might:
+
+- **Flow into action**: "Ready to start? `/opsx-new` or `/opsx-ff`"
+- **Result in artifact updates**: "Updated design.md with these decisions"
+- **Just provide clarity**: User has what they need, moves on
+- **Continue later**: "We can pick this up anytime"
+
+When things crystallize, you might offer a summary - but it's optional. Sometimes the thinking IS the value.
+
+---
+
+## Guardrails
+
+- **Don't implement** - Never write code or implement features. Creating OpenSpec artifacts is fine, writing application code is not.
+- **Don't fake understanding** - If something is unclear, dig deeper
+- **Don't rush** - Discovery is thinking time, not task time
+- **Don't force structure** - Let patterns emerge naturally
+- **Don't auto-capture** - Offer to save insights, don't just do it
+- **Do visualize** - A good diagram is worth many paragraphs
+- **Do explore the codebase** - Ground discussions in reality
+- **Do question assumptions** - Including the user's and your own
diff --git a/.opencode/command/opsx-ff.md b/.opencode/command/opsx-ff.md
new file mode 100644
index 0000000..33190e0
--- /dev/null
+++ b/.opencode/command/opsx-ff.md
@@ -0,0 +1,91 @@
+---
+description: Create a change and generate all artifacts needed for implementation in one go
+---
+
+Fast-forward through artifact creation - generate everything needed to start implementation.
+
+**Input**: The argument after `/opsx-ff` is the change name (kebab-case), OR a description of what the user wants to build.
+
+**Steps**
+
+1. **If no input provided, ask what they want to build**
+
+   Use the **AskUserQuestion tool** (open-ended, no preset options) to ask:
+   > "What change do you want to work on? Describe what you want to build or fix."
+
+   From their description, derive a kebab-case name (e.g., "add user authentication" → `add-user-auth`).
+
+   **IMPORTANT**: Do NOT proceed without understanding what the user wants to build.
+
+2. **Create the change directory**
+   ```bash
+   openspec new change "<name>"
+   ```
+   This creates a scaffolded change at `openspec/changes/<name>/`.
+
+3. **Get the artifact build order**
+   ```bash
+   openspec status --change "<name>" --json
+   ```
+   Parse the JSON to get:
+   - `applyRequires`: array of artifact IDs needed before implementation (e.g., `["tasks"]`)
+   - `artifacts`: list of all artifacts with their status and dependencies
+
+4. **Create artifacts in sequence until apply-ready**
+
+   Use the **TodoWrite tool** to track progress through the artifacts.
+
+   Loop through artifacts in dependency order (artifacts with no pending dependencies first):
+
+   a. **For each artifact that is `ready` (dependencies satisfied)**:
+      - Get instructions:
+        ```bash
+        openspec instructions <artifact-id> --change "<name>" --json
+        ```
+      - The instructions JSON includes:
+        - `context`: Project background (constraints for you - do NOT include in output)
+        - `rules`: Artifact-specific rules (constraints for you - do NOT include in output)
+        - `template`: The structure to use for your output file
+        - `instruction`: Schema-specific guidance for this artifact type
+        - `outputPath`: Where to write the artifact
+        - `dependencies`: Completed artifacts to read for context
+      - Read any completed dependency files for context
+      - Create the artifact file using `template` as the structure
+      - Apply `context` and `rules` as constraints - but do NOT copy them into the file
+      - Show brief progress: "✓ Created <artifact-id>"
+
+   b. **Continue until all `applyRequires` artifacts are complete**
+      - After creating each artifact, re-run `openspec status --change "<name>" --json`
+      - Check if every artifact ID in `applyRequires` has `status: "done"` in the artifacts array
+      - Stop when all `applyRequires` artifacts are done
+
+   c. **If an artifact requires user input** (unclear context):
+      - Use **AskUserQuestion tool** to clarify
+      - Then continue with creation
+
+5. **Show final status**
+   ```bash
+   openspec status --change "<name>"
+   ```
+
+**Output**
+
+After completing all artifacts, summarize:
+- Change name and location
+- List of artifacts created with brief descriptions
+- What's ready: "All artifacts created! Ready for implementation."
+- Prompt: "Run `/opsx-apply` to start implementing."
+
+**Artifact Creation Guidelines**
+
+- Follow the `instruction` field from `openspec instructions` for each artifact type
+- The schema defines what each artifact should contain - follow it
+- Read dependency artifacts for context before creating new ones
+- Use the `template` as a starting point, filling in based on context
+
+**Guardrails**
+- Create ALL artifacts needed for implementation (as defined by schema's `apply.requires`)
+- Always read dependency artifacts before creating a new one
+- If context is critically unclear, ask the user - but prefer making reasonable decisions to keep momentum
+- If a change with that name already exists, ask if user wants to continue it or create a new one
+- Verify each artifact file exists after writing before proceeding to next
diff --git a/.opencode/command/opsx-new.md b/.opencode/command/opsx-new.md
new file mode 100644
index 0000000..0f30abd
--- /dev/null
+++ b/.opencode/command/opsx-new.md
@@ -0,0 +1,66 @@
+---
+description: Start a new change using the experimental artifact workflow (OPSX)
+---
+
+Start a new change using the experimental artifact-driven approach.
+
+**Input**: The argument after `/opsx-new` is the change name (kebab-case), OR a description of what the user wants to build.
+
+**Steps**
+
+1. **If no input provided, ask what they want to build**
+
+   Use the **AskUserQuestion tool** (open-ended, no preset options) to ask:
+   > "What change do you want to work on? Describe what you want to build or fix."
+
+   From their description, derive a kebab-case name (e.g., "add user authentication" → `add-user-auth`).
+
+   **IMPORTANT**: Do NOT proceed without understanding what the user wants to build.
+
+2. **Determine the workflow schema**
+
+   Use the default schema (omit `--schema`) unless the user explicitly requests a different workflow.
+
+   **Use a different schema only if the user mentions:**
+   - A specific schema name → use `--schema <name>`
+   - "show workflows" or "what workflows" → run `openspec schemas --json` and let them choose
+
+   **Otherwise**: Omit `--schema` to use the default.
+
+3. **Create the change directory**
+   ```bash
+   openspec new change "<name>"
+   ```
+   Add `--schema <name>` only if the user requested a specific workflow.
+   This creates a scaffolded change at `openspec/changes/<name>/` with the selected schema.
+
+4. **Show the artifact status**
+   ```bash
+   openspec status --change "<name>"
+   ```
+   This shows which artifacts need to be created and which are ready (dependencies satisfied).
+
+5. **Get instructions for the first artifact**
+   The first artifact depends on the schema. Check the status output to find the first artifact with status "ready".
+   ```bash
+   openspec instructions <first-artifact-id> --change "<name>"
+   ```
+   This outputs the template and context for creating the first artifact.
+
+6. **STOP and wait for user direction**
+
+**Output**
+
+After completing the steps, summarize:
+- Change name and location
+- Schema/workflow being used and its artifact sequence
+- Current status (0/N artifacts complete)
+- The template for the first artifact
+- Prompt: "Ready to create the first artifact? Run `/opsx-continue` or just describe what this change is about and I'll draft it."
+
+**Guardrails**
+- Do NOT create any artifacts yet - just show the instructions
+- Do NOT advance beyond showing the first artifact template
+- If the name is invalid (not kebab-case), ask for a valid name
+- If a change with that name already exists, suggest using `/opsx-continue` instead
+- Pass --schema if using a non-default workflow
diff --git a/.opencode/command/opsx-onboard.md b/.opencode/command/opsx-onboard.md
new file mode 100644
index 0000000..50b4b82
--- /dev/null
+++ b/.opencode/command/opsx-onboard.md
@@ -0,0 +1,522 @@
+---
+description: Guided onboarding - walk through a complete OpenSpec workflow cycle with narration
+---
+
+Guide the user through their first complete OpenSpec workflow cycle. This is a teaching experience—you'll do real work in their codebase while explaining each step.
+
+---
+
+## Preflight
+
+Before starting, check if OpenSpec is initialized:
+
+```bash
+openspec status --json 2>&1 || echo "NOT_INITIALIZED"
+```
+
+**If not initialized:**
+> OpenSpec isn't set up in this project yet. Run `openspec init` first, then come back to `/opsx-onboard`.
+
+Stop here if not initialized.
+
+---
+
+## Phase 1: Welcome
+
+Display:
+
+```
+## Welcome to OpenSpec!
+
+I'll walk you through a complete change cycle—from idea to implementation—using a real task in your codebase. Along the way, you'll learn the workflow by doing it.
+
+**What we'll do:**
+1. Pick a small, real task in your codebase
+2. Explore the problem briefly
+3. Create a change (the container for our work)
+4. Build the artifacts: proposal → specs → design → tasks
+5. Implement the tasks
+6. Archive the completed change
+
+**Time:** ~15-20 minutes
+
+Let's start by finding something to work on.
+```
+
+---
+
+## Phase 2: Task Selection
+
+### Codebase Analysis
+
+Scan the codebase for small improvement opportunities. Look for:
+
+1. **TODO/FIXME comments** - Search for `TODO`, `FIXME`, `HACK`, `XXX` in code files
+2. **Missing error handling** - `catch` blocks that swallow errors, risky operations without try-catch
+3. **Functions without tests** - Cross-reference `src/` with test directories
+4. **Type issues** - `any` types in TypeScript files (`: any`, `as any`)
+5. **Debug artifacts** - `console.log`, `console.debug`, `debugger` statements in non-debug code
+6. **Missing validation** - User input handlers without validation
+
+Also check recent git activity:
+```bash
+git log --oneline -10 2>/dev/null || echo "No git history"
+```
+
+### Present Suggestions
+
+From your analysis, present 3-4 specific suggestions:
+
+```
+## Task Suggestions
+
+Based on scanning your codebase, here are some good starter tasks:
+
+**1. [Most promising task]**
+   Location: `src/path/to/file.ts:42`
+   Scope: ~1-2 files, ~20-30 lines
+   Why it's good: [brief reason]
+
+**2. [Second task]**
+   Location: `src/another/file.ts`
+   Scope: ~1 file, ~15 lines
+   Why it's good: [brief reason]
+
+**3. [Third task]**
+   Location: [location]
+   Scope: [estimate]
+   Why it's good: [brief reason]
+
+**4. Something else?**
+   Tell me what you'd like to work on.
+
+Which task interests you? (Pick a number or describe your own)
+```
+
+**If nothing found:** Fall back to asking what the user wants to build:
+> I didn't find obvious quick wins in your codebase. What's something small you've been meaning to add or fix?
+
+### Scope Guardrail
+
+If the user picks or describes something too large (major feature, multi-day work):
+
+```
+That's a valuable task, but it's probably larger than ideal for your first OpenSpec run-through.
+
+For learning the workflow, smaller is better—it lets you see the full cycle without getting stuck in implementation details.
+
+**Options:**
+1. **Slice it smaller** - What's the smallest useful piece of [their task]? Maybe just [specific slice]?
+2. **Pick something else** - One of the other suggestions, or a different small task?
+3. **Do it anyway** - If you really want to tackle this, we can. Just know it'll take longer.
+
+What would you prefer?
+```
+
+Let the user override if they insist—this is a soft guardrail.
+
+---
+
+## Phase 3: Explore Demo
+
+Once a task is selected, briefly demonstrate explore mode:
+
+```
+Before we create a change, let me quickly show you **explore mode**—it's how you think through problems before committing to a direction.
+```
+
+Spend 1-2 minutes investigating the relevant code:
+- Read the file(s) involved
+- Draw a quick ASCII diagram if it helps
+- Note any considerations
+
+```
+## Quick Exploration
+
+[Your brief analysis—what you found, any considerations]
+
+┌─────────────────────────────────────────┐
+│   [Optional: ASCII diagram if helpful]  │
+└─────────────────────────────────────────┘
+
+Explore mode (`/opsx-explore`) is for this kind of thinking—investigating before implementing. You can use it anytime you need to think through a problem.
+
+Now let's create a change to hold our work.
+```
+
+**PAUSE** - Wait for user acknowledgment before proceeding.
+
+---
+
+## Phase 4: Create the Change
+
+**EXPLAIN:**
+```
+## Creating a Change
+
+A "change" in OpenSpec is a container for all the thinking and planning around a piece of work. It lives in `openspec/changes/<name>/` and holds your artifacts—proposal, specs, design, tasks.
+
+Let me create one for our task.
+```
+
+**DO:** Create the change with a derived kebab-case name:
+```bash
+openspec new change "<derived-name>"
+```
+
+**SHOW:**
+```
+Created: `openspec/changes/<name>/`
+
+The folder structure:
+```
+openspec/changes/<name>/
+├── proposal.md    ← Why we're doing this (empty, we'll fill it)
+├── design.md      ← How we'll build it (empty)
+├── specs/         ← Detailed requirements (empty)
+└── tasks.md       ← Implementation checklist (empty)
+```
+
+Now let's fill in the first artifact—the proposal.
+```
+
+---
+
+## Phase 5: Proposal
+
+**EXPLAIN:**
+```
+## The Proposal
+
+The proposal captures **why** we're making this change and **what** it involves at a high level. It's the "elevator pitch" for the work.
+
+I'll draft one based on our task.
+```
+
+**DO:** Draft the proposal content (don't save yet):
+
+```
+Here's a draft proposal:
+
+---
+
+## Why
+
+[1-2 sentences explaining the problem/opportunity]
+
+## What Changes
+
+[Bullet points of what will be different]
+
+## Capabilities
+
+### New Capabilities
+- `<capability-name>`: [brief description]
+
+### Modified Capabilities
+<!-- If modifying existing behavior -->
+
+## Impact
+
+- `src/path/to/file.ts`: [what changes]
+- [other files if applicable]
+
+---
+
+Does this capture the intent? I can adjust before we save it.
+```
+
+**PAUSE** - Wait for user approval/feedback.
+
+After approval, save the proposal:
+```bash
+openspec instructions proposal --change "<name>" --json
+```
+Then write the content to `openspec/changes/<name>/proposal.md`.
+
+```
+Proposal saved. This is your "why" document—you can always come back and refine it as understanding evolves.
+
+Next up: specs.
+```
+
+---
+
+## Phase 6: Specs
+
+**EXPLAIN:**
+```
+## Specs
+
+Specs define **what** we're building in precise, testable terms. They use a requirement/scenario format that makes expected behavior crystal clear.
+
+For a small task like this, we might only need one spec file.
+```
+
+**DO:** Create the spec file:
+```bash
+mkdir -p openspec/changes/<name>/specs/<capability-name>
+```
+
+Draft the spec content:
+
+```
+Here's the spec:
+
+---
+
+## ADDED Requirements
+
+### Requirement: <Name>
+
+<Description of what the system should do>
+
+#### Scenario: <Scenario name>
+
+- **WHEN** <trigger condition>
+- **THEN** <expected outcome>
+- **AND** <additional outcome if needed>
+
+---
+
+This format—WHEN/THEN/AND—makes requirements testable. You can literally read them as test cases.
+```
+
+Save to `openspec/changes/<name>/specs/<capability>/spec.md`.
+
+---
+
+## Phase 7: Design
+
+**EXPLAIN:**
+```
+## Design
+
+The design captures **how** we'll build it—technical decisions, tradeoffs, approach.
+
+For small changes, this might be brief. That's fine—not every change needs deep design discussion.
+```
+
+**DO:** Draft design.md:
+
+```
+Here's the design:
+
+---
+
+## Context
+
+[Brief context about the current state]
+
+## Goals / Non-Goals
+
+**Goals:**
+- [What we're trying to achieve]
+
+**Non-Goals:**
+- [What's explicitly out of scope]
+
+## Decisions
+
+### Decision 1: [Key decision]
+
+[Explanation of approach and rationale]
+
+---
+
+For a small task, this captures the key decisions without over-engineering.
+```
+
+Save to `openspec/changes/<name>/design.md`.
+
+---
+
+## Phase 8: Tasks
+
+**EXPLAIN:**
+```
+## Tasks
+
+Finally, we break the work into implementation tasks—checkboxes that drive the apply phase.
+
+These should be small, clear, and in logical order.
+```
+
+**DO:** Generate tasks based on specs and design:
+
+```
+Here are the implementation tasks:
+
+---
+
+## 1. [Category or file]
+
+- [ ] 1.1 [Specific task]
+- [ ] 1.2 [Specific task]
+
+## 2. Verify
+
+- [ ] 2.1 [Verification step]
+
+---
+
+Each checkbox becomes a unit of work in the apply phase. Ready to implement?
+```
+
+**PAUSE** - Wait for user to confirm they're ready to implement.
+
+Save to `openspec/changes/<name>/tasks.md`.
+
+---
+
+## Phase 9: Apply (Implementation)
+
+**EXPLAIN:**
+```
+## Implementation
+
+Now we implement each task, checking them off as we go. I'll announce each one and occasionally note how the specs/design informed the approach.
+```
+
+**DO:** For each task:
+
+1. Announce: "Working on task N: [description]"
+2. Implement the change in the codebase
+3. Reference specs/design naturally: "The spec says X, so I'm doing Y"
+4. Mark complete in tasks.md: `- [ ]` → `- [x]`
+5. Brief status: "✓ Task N complete"
+
+Keep narration light—don't over-explain every line of code.
+
+After all tasks:
+
+```
+## Implementation Complete
+
+All tasks done:
+- [x] Task 1
+- [x] Task 2
+- [x] ...
+
+The change is implemented! One more step—let's archive it.
+```
+
+---
+
+## Phase 10: Archive
+
+**EXPLAIN:**
+```
+## Archiving
+
+When a change is complete, we archive it. This moves it from `openspec/changes/` to `openspec/changes/archive/YYYY-MM-DD-<name>/`.
+
+Archived changes become your project's decision history—you can always find them later to understand why something was built a certain way.
+```
+
+**DO:**
+```bash
+openspec archive "<name>"
+```
+
+**SHOW:**
+```
+Archived to: `openspec/changes/archive/YYYY-MM-DD-<name>/`
+
+The change is now part of your project's history. The code is in your codebase, the decision record is preserved.
+```
+
+---
+
+## Phase 11: Recap & Next Steps
+
+```
+## Congratulations!
+
+You just completed a full OpenSpec cycle:
+
+1. **Explore** - Thought through the problem
+2. **New** - Created a change container
+3. **Proposal** - Captured WHY
+4. **Specs** - Defined WHAT in detail
+5. **Design** - Decided HOW
+6. **Tasks** - Broke it into steps
+7. **Apply** - Implemented the work
+8. **Archive** - Preserved the record
+
+This same rhythm works for any size change—a small fix or a major feature.
+
+---
+
+## Command Reference
+
+| Command | What it does |
+|---------|--------------|
+| `/opsx-explore` | Think through problems before/during work |
+| `/opsx-new` | Start a new change, step through artifacts |
+| `/opsx-ff` | Fast-forward: create all artifacts at once |
+| `/opsx-continue` | Continue working on an existing change |
+| `/opsx-apply` | Implement tasks from a change |
+| `/opsx-verify` | Verify implementation matches artifacts |
+| `/opsx-archive` | Archive a completed change |
+
+---
+
+## What's Next?
+
+Try `/opsx-new` or `/opsx-ff` on something you actually want to build. You've got the rhythm now!
+```
+
+---
+
+## Graceful Exit Handling
+
+### User wants to stop mid-way
+
+If the user says they need to stop, want to pause, or seem disengaged:
+
+```
+No problem! Your change is saved at `openspec/changes/<name>/`.
+
+To pick up where we left off later:
+- `/opsx-continue <name>` - Resume artifact creation
+- `/opsx-apply <name>` - Jump to implementation (if tasks exist)
+
+The work won't be lost. Come back whenever you're ready.
+```
+
+Exit gracefully without pressure.
+
+### User just wants command reference
+
+If the user says they just want to see the commands or skip the tutorial:
+
+```
+## OpenSpec Quick Reference
+
+| Command | What it does |
+|---------|--------------|
+| `/opsx-explore` | Think through problems (no code changes) |
+| `/opsx-new <name>` | Start a new change, step by step |
+| `/opsx-ff <name>` | Fast-forward: all artifacts at once |
+| `/opsx-continue <name>` | Continue an existing change |
+| `/opsx-apply <name>` | Implement tasks |
+| `/opsx-verify <name>` | Verify implementation |
+| `/opsx-archive <name>` | Archive when done |
+
+Try `/opsx-new` to start your first change, or `/opsx-ff` if you want to move fast.
+```
+
+Exit gracefully.
+
+---
+
+## Guardrails
+
+- **Follow the EXPLAIN → DO → SHOW → PAUSE pattern** at key transitions (after explore, after proposal draft, after tasks, after archive)
+- **Keep narration light** during implementation—teach without lecturing
+- **Don't skip phases** even if the change is small—the goal is teaching the workflow
+- **Pause for acknowledgment** at marked points, but don't over-pause
+- **Handle exits gracefully**—never pressure the user to continue
+- **Use real codebase tasks**—don't simulate or use fake examples
+- **Adjust scope gently**—guide toward smaller tasks but respect user choice
diff --git a/.opencode/command/opsx-sync.md b/.opencode/command/opsx-sync.md
new file mode 100644
index 0000000..1208c4b
--- /dev/null
+++ b/.opencode/command/opsx-sync.md
@@ -0,0 +1,131 @@
+---
+description: Sync delta specs from a change to main specs
+---
+
+Sync delta specs from a change to main specs.
+
+This is an **agent-driven** operation - you will read delta specs and directly edit main specs to apply the changes. This allows intelligent merging (e.g., adding a scenario without copying the entire requirement).
+
+**Input**: Optionally specify a change name after `/opsx-sync` (e.g., `/opsx-sync add-auth`). If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
+
+**Steps**
+
+1. **If no change name provided, prompt for selection**
+
+   Run `openspec list --json` to get available changes. Use the **AskUserQuestion tool** to let the user select.
+
+   Show changes that have delta specs (under `specs/` directory).
+
+   **IMPORTANT**: Do NOT guess or auto-select a change. Always let the user choose.
+
+2. **Find delta specs**
+
+   Look for delta spec files in `openspec/changes/<name>/specs/*/spec.md`.
+
+   Each delta spec file contains sections like:
+   - `## ADDED Requirements` - New requirements to add
+   - `## MODIFIED Requirements` - Changes to existing requirements
+   - `## REMOVED Requirements` - Requirements to remove
+   - `## RENAMED Requirements` - Requirements to rename (FROM:/TO: format)
+
+   If no delta specs found, inform user and stop.
+
+3. **For each delta spec, apply changes to main specs**
+
+   For each capability with a delta spec at `openspec/changes/<name>/specs/<capability>/spec.md`:
+
+   a. **Read the delta spec** to understand the intended changes
+
+   b. **Read the main spec** at `openspec/specs/<capability>/spec.md` (may not exist yet)
+
+   c. **Apply changes intelligently**:
+
+      **ADDED Requirements:**
+      - If requirement doesn't exist in main spec → add it
+      - If requirement already exists → update it to match (treat as implicit MODIFIED)
+
+      **MODIFIED Requirements:**
+      - Find the requirement in main spec
+      - Apply the changes - this can be:
+        - Adding new scenarios (don't need to copy existing ones)
+        - Modifying existing scenarios
+        - Changing the requirement description
+      - Preserve scenarios/content not mentioned in the delta
+
+      **REMOVED Requirements:**
+      - Remove the entire requirement block from main spec
+
+      **RENAMED Requirements:**
+      - Find the FROM requirement, rename to TO
+
+   d. **Create new main spec** if capability doesn't exist yet:
+      - Create `openspec/specs/<capability>/spec.md`
+      - Add Purpose section (can be brief, mark as TBD)
+      - Add Requirements section with the ADDED requirements
+
+4. **Show summary**
+
+   After applying all changes, summarize:
+   - Which capabilities were updated
+   - What changes were made (requirements added/modified/removed/renamed)
+
+**Delta Spec Format Reference**
+
+```markdown
+## ADDED Requirements
+
+### Requirement: New Feature
+The system SHALL do something new.
+
+#### Scenario: Basic case
+- **WHEN** user does X
+- **THEN** system does Y
+
+## MODIFIED Requirements
+
+### Requirement: Existing Feature
+#### Scenario: New scenario to add
+- **WHEN** user does A
+- **THEN** system does B
+
+## REMOVED Requirements
+
+### Requirement: Deprecated Feature
+
+## RENAMED Requirements
+
+- FROM: `### Requirement: Old Name`
+- TO: `### Requirement: New Name`
+```
+
+**Key Principle: Intelligent Merging**
+
+Unlike programmatic merging, you can apply **partial updates**:
+- To add a scenario, just include that scenario under MODIFIED - don't copy existing scenarios
+- The delta represents *intent*, not a wholesale replacement
+- Use your judgment to merge changes sensibly
+
+**Output On Success**
+
+```
+## Specs Synced: <change-name>
+
+Updated main specs:
+
+**<capability-1>**:
+- Added requirement: "New Feature"
+- Modified requirement: "Existing Feature" (added 1 scenario)
+
+**<capability-2>**:
+- Created new spec file
+- Added requirement: "Another Feature"
+
+Main specs are now updated. The change remains active - archive when implementation is complete.
+```
+
+**Guardrails**
+- Read both delta and main specs before making changes
+- Preserve existing content not mentioned in delta
+- If something is unclear, ask for clarification
+- Show what you're changing as you go
+- The operation should be idempotent - running twice should give same result
diff --git a/.opencode/command/opsx-verify.md b/.opencode/command/opsx-verify.md
new file mode 100644
index 0000000..7bd3aba
--- /dev/null
+++ b/.opencode/command/opsx-verify.md
@@ -0,0 +1,161 @@
+---
+description: Verify implementation matches change artifacts before archiving
+---
+
+Verify that an implementation matches the change artifacts (specs, tasks, design).
+
+**Input**: Optionally specify a change name after `/opsx-verify` (e.g., `/opsx-verify add-auth`). If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
+
+**Steps**
+
+1. **If no change name provided, prompt for selection**
+
+   Run `openspec list --json` to get available changes. Use the **AskUserQuestion tool** to let the user select.
+
+   Show changes that have implementation tasks (tasks artifact exists).
+   Include the schema used for each change if available.
+   Mark changes with incomplete tasks as "(In Progress)".
+
+   **IMPORTANT**: Do NOT guess or auto-select a change. Always let the user choose.
+
+2. **Check status to understand the schema**
+   ```bash
+   openspec status --change "<name>" --json
+   ```
+   Parse the JSON to understand:
+   - `schemaName`: The workflow being used (e.g., "spec-driven")
+   - Which artifacts exist for this change
+
+3. **Get the change directory and load artifacts**
+
+   ```bash
+   openspec instructions apply --change "<name>" --json
+   ```
+
+   This returns the change directory and context files. Read all available artifacts from `contextFiles`.
+
+4. **Initialize verification report structure**
+
+   Create a report structure with three dimensions:
+   - **Completeness**: Track tasks and spec coverage
+   - **Correctness**: Track requirement implementation and scenario coverage
+   - **Coherence**: Track design adherence and pattern consistency
+
+   Each dimension can have CRITICAL, WARNING, or SUGGESTION issues.
+
+5. **Verify Completeness**
+
+   **Task Completion**:
+   - If tasks.md exists in contextFiles, read it
+   - Parse checkboxes: `- [ ]` (incomplete) vs `- [x]` (complete)
+   - Count complete vs total tasks
+   - If incomplete tasks exist:
+     - Add CRITICAL issue for each incomplete task
+     - Recommendation: "Complete task: <description>" or "Mark as done if already implemented"
+
+   **Spec Coverage**:
+   - If delta specs exist in `openspec/changes/<name>/specs/`:
+     - Extract all requirements (marked with "### Requirement:")
+     - For each requirement:
+       - Search codebase for keywords related to the requirement
+       - Assess if implementation likely exists
+     - If requirements appear unimplemented:
+       - Add CRITICAL issue: "Requirement not found: <requirement name>"
+       - Recommendation: "Implement requirement X: <description>"
+
+6. **Verify Correctness**
+
+   **Requirement Implementation Mapping**:
+   - For each requirement from delta specs:
+     - Search codebase for implementation evidence
+     - If found, note file paths and line ranges
+     - Assess if implementation matches requirement intent
+     - If divergence detected:
+       - Add WARNING: "Implementation may diverge from spec: <details>"
+       - Recommendation: "Review <file>:<lines> against requirement X"
+
+   **Scenario Coverage**:
+   - For each scenario in delta specs (marked with "#### Scenario:"):
+     - Check if conditions are handled in code
+     - Check if tests exist covering the scenario
+     - If scenario appears uncovered:
+       - Add WARNING: "Scenario not covered: <scenario name>"
+       - Recommendation: "Add test or implementation for scenario: <description>"
+
+7. **Verify Coherence**
+
+   **Design Adherence**:
+   - If design.md exists in contextFiles:
+     - Extract key decisions (look for sections like "Decision:", "Approach:", "Architecture:")
+     - Verify implementation follows those decisions
+     - If contradiction detected:
+       - Add WARNING: "Design decision not followed: <decision>"
+       - Recommendation: "Update implementation or revise design.md to match reality"
+   - If no design.md: Skip design adherence check, note "No design.md to verify against"
+
+   **Code Pattern Consistency**:
+   - Review new code for consistency with project patterns
+   - Check file naming, directory structure, coding style
+   - If significant deviations found:
+     - Add SUGGESTION: "Code pattern deviation: <details>"
+     - Recommendation: "Consider following project pattern: <example>"
+
+8. **Generate Verification Report**
+
+   **Summary Scorecard**:
+   ```
+   ## Verification Report: <change-name>
+
+   ### Summary
+   | Dimension    | Status           |
+   |--------------|------------------|
+   | Completeness | X/Y tasks, N reqs|
+   | Correctness  | M/N reqs covered |
+   | Coherence    | Followed/Issues  |
+   ```
+
+   **Issues by Priority**:
+
+   1. **CRITICAL** (Must fix before archive):
+      - Incomplete tasks
+      - Missing requirement implementations
+      - Each with specific, actionable recommendation
+
+   2. **WARNING** (Should fix):
+      - Spec/design divergences
+      - Missing scenario coverage
+      - Each with specific recommendation
+
+   3. **SUGGESTION** (Nice to fix):
+      - Pattern inconsistencies
+      - Minor improvements
+      - Each with specific recommendation
+
+   **Final Assessment**:
+   - If CRITICAL issues: "X critical issue(s) found. Fix before archiving."
+   - If only warnings: "No critical issues. Y warning(s) to consider. Ready for archive (with noted improvements)."
+   - If all clear: "All checks passed. Ready for archive."
+
+**Verification Heuristics**
+
+- **Completeness**: Focus on objective checklist items (checkboxes, requirements list)
+- **Correctness**: Use keyword search, file path analysis, reasonable inference - don't require perfect certainty
+- **Coherence**: Look for glaring inconsistencies, don't nitpick style
+- **False Positives**: When uncertain, prefer SUGGESTION over WARNING, WARNING over CRITICAL
+- **Actionability**: Every issue must have a specific recommendation with file/line references where applicable
+
+**Graceful Degradation**
+
+- If only tasks.md exists: verify task completion only, skip spec/design checks
+- If tasks + specs exist: verify completeness and correctness, skip design
+- If full artifacts: verify all three dimensions
+- Always note which checks were skipped and why
+
+**Output Format**
+
+Use clear markdown with:
+- Table for summary scorecard
+- Grouped lists for issues (CRITICAL/WARNING/SUGGESTION)
+- Code references in format: `file.ts:123`
+- Specific, actionable recommendations
+- No vague suggestions like "consider reviewing"
diff --git a/.opencode/skills/bug-fix/SKILL.cn.md b/.opencode/skills/bug-fix/SKILL.cn.md
new file mode 100644
index 0000000..e21acea
--- /dev/null
+++ b/.opencode/skills/bug-fix/SKILL.cn.md
@@ -0,0 +1,202 @@
+---
+name: bug-fix
+description: Bug诊断与修复技能 - 强调交互式确认和影响分析
+metadata:
+  tags:
+    - bug-fix
+    - debugging
+    - troubleshooting
+    - interactive
+  version: 1.0.1
+---
+
+# Bug修复技能
+
+## 技能概述
+
+专门用于诊断和修复项目中的bug,强调谨慎的分析流程和充分的交互式确认,确保修复的准确性和完整性,避免引入新的问题或破坏现有功能。
+
+## ⚠️ 强制交互规则(MUST FOLLOW)
+
+**遇到需要用户确认的情况时,必须立即调用 `question` 工具:**
+
+❌ **禁止**:"我需要向用户确认..."、"请用户回答..."、"在Plan模式下建议先询问..."  
+✅ **必须**:直接调用工具,不要描述或延迟
+
+**调用格式**:
+```javascript
+question({
+  header: "问题确认",
+  questions: [{
+    question: "具体触发场景是什么?",
+    options: ["新增时", "修改时", "批量导入时", "定时任务时", "其他"]
+  }]
+})
+```
+
+**规则**:
+- 每次最多 **3个问题**
+- 每个问题 **3-6个选项**(穷举常见情况 + "其他"兜底)
+- 用户通过**上下键导航**选择
+- 适用于**所有模式**(Build/Plan)
+
+## 执行原则
+
+### 1. 充分理解问题(必要时交互确认)
+
+**触发条件**:
+- 用户对bug的描述含糊不清
+- 问题复现步骤不完整
+- 预期行为与实际行为表述存在歧义
+- 涉及多个可能的问题根因
+
+**执行策略**:
+- ✅ **立即调用 `question` 工具**(不要描述,直接执行)
+- ✅ **暂停其他操作**,不要基于假设进行修复
+- ✅ 澄清:错误现象、触发条件、预期行为、是否有日志
+
+### 2. 风险评估与影响分析(必要时交互确认)
+
+**触发条件**:
+- 发现潜在的边界情况用户未提及
+- 代码修改可能影响其他功能模块
+- 存在多种修复方案,各有利弊
+- 发现可能的性能、安全或兼容性隐患
+
+**执行策略**:
+- ✅ 代码分析后,**不要直接修改代码**
+- ✅ 报告潜在问题:影响范围、边界情况、测试场景、数据迁移需求
+- ✅ **使用 `question` 工具**让用户选择方案或确认风险
+
+### 3. 关联代码检查(必要时交互确认)
+
+**触发条件**:
+- 发现多个位置存在相似的代码逻辑
+- 修复需要同步更新多个文件
+- 存在可能依赖该bug行为的代码(反模式)
+- 发现测试用例可能基于错误行为编写
+
+**执行策略**:
+- ✅ 使用代码搜索工具查找相似逻辑和调用链
+- ✅ 报告关联代码:是否需要同步修复、依赖关系、测试更新
+- ✅ **使用 `question` 工具**让用户确认修复范围
+
+## 修复流程
+
+### 阶段1: 问题诊断
+1. 阅读用户的bug描述
+2. 定位相关代码文件(使用 semantic_search, grep_search)
+3. 分析代码逻辑和调用链
+4. **触发点1**: 如有不明确之处 → **立即调用 `question` 工具**(不要描述计划)
+
+### 阶段2: 根因分析
+1. 确定bug的根本原因
+2. 识别影响范围和边界情况
+3. **触发点2**: 发现用户未考虑的问题 → **立即调用 `question` 工具**
+
+### 阶段3: 方案设计
+1. 设计修复方案
+2. 评估方案的影响和风险
+3. 查找相似代码和依赖关系
+4. **触发点3**: 可能影响其他逻辑 → **立即调用 `question` 工具**
+
+### 阶段4: 实施修复
+1. 获得用户最终确认后执行代码修改
+2. 使用 `multi_replace_string_in_file` 批量修改
+3. 确保修改的原子性和一致性
+
+### 阶段5: 验证建议
+提示用户执行:单元测试(`dotnet test`)、手动测试场景、回归测试
+
+## 反模式与成功标准
+
+❌ **不要**在未明确理解问题的情况下猜测修复
+❌ **不要**在未评估影响范围的情况下直接修改代码
+❌ **不要**假设用户已考虑所有边界情况
+❌ **不要**在发现关联逻辑时仅修复单个位置
+❌ **不要**跳过风险通知直接实施有争议的修复方案
+❌ **不要**修改代码后不提供验证建议
+❌ **不要**描述"我会询问用户..."而不调用 `question` 工具
+❌ **不要**列出问题清单让用户自行回答
+❌ **不要**在Plan模式下说"如果用户确认..."而不执行工具调用
+
+## 成功标准
+
+✅ 用户明确确认问题理解无误(通过 `question` 工具获取)
+✅ 所有潜在风险和影响已向用户说明(通过 `question` 工具确认)
+✅ 修复方案获得用户明确同意(通过 `question` 工具选择)
+✅ 相似逻辑和关联代码已同步处理(如适用)
+✅ 提供了完整的验证和测试建议
+
+## 示例工作流
+
+```
+用户: "策略计算结果不对,加价逻辑有问题"
+
+Agent:
+[阶段1 - 问题诊断]
+我需要确认几个细节:
+1. 具体是哪种类型的策略计算不对?(机票、动态加价、固定加价?)
+2. 能否提供一个具体的测试用例输入和错误输出?
+3. 预期的正确输出是什么?
+
+用户: "动态加价,百分比计算错误,应该是基准价×10%,但实际是×100%"
+
+Agent:
+[阶段2 - 根因分析]
+已定位到问题:
+- 位置: src/Domain.Service/Services/AgentService.cs:234
+- 原因: 百分比未除以100
+
+[阶段3 - 方案设计]
+⚠️ 发现以下需要确认的点:
+
+1. **关联代码**: 在 PolicyService.cs 中发现相似的百分比计算(3处),
+   是否也存在相同问题?
+   
+2. **单元测试**: UnitTestPolicy.cs:67 的断言值为100%,可能基于错误行为,
+   修复后需要更新测试
+
+3. **前端影响**: 如果历史数据按错误逻辑存储,前端展示需要迁移脚本吗?
+
+请确认是否需要一并处理这些关联问题?
+
+用户: "是的,PolicyService 也需要修复,测试用例也要改,历史数据没有存储"
+
+Agent:
+[阶段4 - 实施修复]
+好的,我将修复以下位置:
+1. AgentService.cs:234
+2. PolicyService.cs:156, 178, 201
+3. UnitTestPolicy.cs:67
+
+[执行代码修改...]
+
+[阶段5 - 验证建议]
+修复完成!建议验证:
+1. 运行单元测试: dotnet test
+2. 手动测试场景:
+   - 输入基准价1000,加价10%,期望结果1100
+   - 验证策略列表API返回正确百分比
+3. 回归测试: 检查其他类型策略未受影响
+```
+
+## 适用场景
+
+- ✅ 逻辑错误修复
+- ✅ 空指针异常修复
+- ✅ 数据计算错误
+- ✅ API行为异常
+- ✅ 性能问题修复
+- ✅ 边界条件处理
+
+## 相关技能
+
+- `refactor`: 重构优化(非bug修复)
+- `feature`: 新功能开发
+- `test`: 测试用例编写
+
+## 核心约束(必须遵守)
+1. **禁止开放式提问** - 所有需要用户输入的场景,必须提供选项列表
+2. 每次交互最多提出5个问题,避免信息过载
+3. 选项设计要穷举常见情况,并保留"其他"兜底选项
diff --git a/.opencode/skills/code-refactoring/SKILL.cn.md b/.opencode/skills/code-refactoring/SKILL.cn.md
new file mode 100644
index 0000000..d533301
--- /dev/null
+++ b/.opencode/skills/code-refactoring/SKILL.cn.md
@@ -0,0 +1,466 @@
+---
+name: code-refactoring
+description: 代码重构技能 - 强调保持功能不变的前提下优化代码结构,充分理解需求和交互式确认
+metadata:
+  tags:
+    - refactoring
+    - code-quality
+    - clean-code
+    - interactive
+  version: 1.0.0
+---
+
+# 代码重构技能
+
+## 技能概述
+
+专门用于在**不改变现有功能逻辑**的前提下优化代码结构,包括:
+- 抽取公共方法、组件和工具类
+- 消除重复代码(DRY原则)
+- 移除无用代码(死代码、注释代码、未使用的依赖)
+- 改善代码可读性和可维护性
+- 优化代码结构和命名规范
+
+## ⚠️ 核心原则(MUST FOLLOW)
+
+### 1. 功能不变保证
+**禁止在重构过程中改变功能行为!**
+- ✅ 重构前后的输入输出必须完全一致
+- ✅ 重构前后的副作用必须一致(数据库操作、文件IO、日志等)
+- ✅ 重构不应改变性能特征(除非明确以性能优化为目标)
+- ❌ 严禁"顺便"添加新功能或修复bug
+
+### 2. 充分理解需求
+**禁止根据模糊的需求开始重构!**
+- ✅ 彻底理解重构的目标和范围
+- ✅ 识别需求中的模糊点和二义性
+- ✅ 使用 `question` 工具获取明确的用户意图
+- ❌ 不要基于假设进行重构
+
+### 3. 先确认再动手
+**禁止未经用户确认就直接修改代码!**
+- ✅ 先列出所有修改点和影响范围
+- ✅ 使用 `question` 工具让用户确认重构方案
+- ✅ 获得明确的同意后再执行修改
+- ❌ 不要边分析边修改
+
+## ⚠️ 强制交互规则(MUST FOLLOW)
+
+**遇到需要用户确认的情况时,必须立即调用 `question` 工具:**
+
+❌ **禁止**:"我需要向用户确认..."、"建议向用户询问..."、"在执行前应该确认..."  
+✅ **必须**:直接调用 `question` 工具,不要描述或延迟
+
+**调用格式**:
+```javascript
+question({
+  header: "重构确认",
+  questions: [{
+    question: "是否要将重复的验证逻辑抽取到公共方法中?",
+    options: ["是,抽取到工具类", "是,抽取到基类", "否,保持现状", "其他"]
+  }]
+})
+```
+
+**规则**:
+- 每次最多 **3个问题**
+- 每个问题 **3-6个选项**(穷举常见情况 + "其他"兜底)
+- 用户通过**上下键导航**选择
+- 适用于**所有阶段**(需求理解、方案确认、风险评估)
+
+## 重构流程
+
+### 阶段1: 需求理解(必须交互确认)
+
+#### 1.1 理解重构目标
+**获取用户意图**:
+- 用户想重构什么?(文件、模块、类、方法)
+- 重构的原因是什么?(代码重复、难以维护、命名不清晰、结构混乱)
+- 期望达到什么效果?(提高复用性、提升可读性、简化逻辑、统一规范)
+
+**触发 `question` 工具的场景**:
+- 用户只说"重构这个文件"但未说明具体问题
+- 用户提到"优化"但没有明确优化方向
+- 用户的需求包含多个可能的重构方向
+- 重构范围不明确(单个文件 vs 整个模块)
+
+**示例问题**:
+```javascript
+question({
+  header: "明确重构目标",
+  questions: [
+    {
+      question: "您主要关注哪方面的重构?",
+      options: [
+        "抽取重复代码",
+        "改善命名和结构",
+        "移除无用代码",
+        "提取公共组件/方法",
+        "全面优化"
+      ]
+    },
+    {
+      question: "重构范围是?",
+      options: [
+        "仅当前文件",
+        "当前模块(相关的几个文件)",
+        "整个项目",
+        "让我分析后建议"
+      ]
+    }
+  ]
+})
+```
+
+#### 1.2 识别约束条件
+**必须明确的约束**:
+- 是否有不能改动的接口或API(对外暴露的)
+- 是否有特殊的性能要求
+- 是否需要保持特定的代码风格
+- 是否有测试覆盖(如有,重构后测试必须通过)
+
+**触发 `question` 工具的场景**:
+- 发现公开API可能需要调整
+- 代码涉及性能敏感的操作
+- 存在多种重构方式,各有权衡
+- 不确定某些代码是否仍在使用
+
+**示例问题**:
+```javascript
+question({
+  header: "重构约束确认",
+  questions: [
+    {
+      question: "发现 `ProcessData` 方法被多个外部模块调用,重构时:",
+      options: [
+        "保持方法签名不变,仅优化内部实现",
+        "可以修改方法签名,我会同步更新调用方",
+        "先告诉我影响范围,我再决定",
+        "其他"
+      ]
+    }
+  ]
+})
+```
+
+#### 1.3 理解代码上下文
+**分析现有代码**:
+- 使用 `semantic_search` 查找相关代码
+- 使用 `grep_search` 查找重复模式
+- 使用 `list_code_usages` 分析调用关系
+- 阅读相关文件理解业务逻辑
+
+**注意事项**:
+- 不要在分析阶段进行任何修改
+- 记录发现的问题点和重构机会
+- 识别可能的风险和边界情况
+
+### 阶段2: 方案设计(必须交互确认)
+
+#### 2.1 列出重构点
+**详细列出每个修改点**:
+- 修改的文件和位置
+- 修改的具体内容(前后对比)
+- 修改的原因和收益
+- 可能的影响范围
+
+**示例格式**:
+```
+## 重构点清单
+
+### 1. 抽取重复的数据验证逻辑
+**位置**: TransactionController.cs (L45-L60, L120-L135)
+**操作**: 将重复的金额验证逻辑抽取到 ValidationHelper.ValidateAmount()
+**原因**: 两处代码完全相同,违反DRY原则
+**影响**: 无,纯内部优化
+
+### 2. 移除未使用的导入和变量
+**位置**: BudgetService.cs (L5, L23)
+**操作**: 删除 `using System.Text.RegularExpressions;` 和未使用的 `_tempValue` 字段
+**原因**: 死代码,增加维护负担
+**影响**: 无
+
+### 3. 重命名方法提高可读性
+**位置**: DataProcessor.cs (L89)
+**操作**: `DoWork()` → `ProcessTransactionData()`
+**原因**: 原名称不够清晰,无法表达具体功能
+**影响**: 4个调用点需要同步更新
+```
+
+#### 2.2 评估风险和影响
+**必须分析的风险**:
+- 是否影响公开API
+- 是否影响性能
+- 是否影响测试
+- 是否涉及数据迁移
+- 是否存在隐藏的依赖关系
+
+**触发 `question` 工具的场景**:
+- 发现重构会影响多个模块
+- 存在潜在的兼容性问题
+- 有多种实现方式可选
+- 需要在代码质量和改动风险间权衡
+
+**示例问题**:
+```javascript
+question({
+  header: "重构方案确认",
+  questions: [
+    {
+      question: "发现3处重复的日期格式化代码,建议:",
+      options: [
+        "抽取到工具类(Common项目)",
+        "抽取到当前服务的私有方法",
+        "保留重复(代码简单,抽取收益小)",
+        "让我看看代码再决定"
+      ]
+    },
+    {
+      question: "重构会影响4个controller和2个service,是否继续?",
+      options: [
+        "是,一次性全部重构",
+        "否,先重构影响小的部分",
+        "告诉我每个的影响详情",
+        "其他"
+      ]
+    }
+  ]
+})
+```
+
+#### 2.3 提交方案供确认
+**必须向用户展示**:
+1. 完整的重构点清单(如2.1格式)
+2. 风险评估和影响分析
+3. 建议的执行顺序
+4. 预计改动的文件数量
+
+**必须调用 `question` 工具获得最终确认**:
+```javascript
+question({
+  header: "最终确认",
+  questions: [{
+    question: "我已列出所有重构点和影响分析,是否开始执行?",
+    options: [
+      "是,按计划执行",
+      "需要调整部分重构点",
+      "取消重构",
+      "其他问题"
+    ]
+  }]
+})
+```
+
+**重要**:
+- ❌ 不要在得到明确的"是,按计划执行"之前修改任何代码
+- ❌ 不要假设用户会同意
+- ✅ 如用户选择"需要调整",返回阶段1重新理解需求
+
+### 阶段3: 执行重构
+
+#### 3.1 执行原则
+- **小步快跑**: 一次完成一个重构点,不要多个同时进行
+- **频繁验证**: 每完成一个点就运行测试或构建验证
+- **保持可逆**: 确保随时可以回滚
+- **记录进度**: 使用 `manage_todo_list` 跟踪进度
+
+#### 3.2 执行步骤
+1. **创建TODO清单**:
+```javascript
+manage_todo_list({
+  todoList: [
+    {
+      id: 1,
+      title: "抽取重复验证逻辑到ValidationHelper",
+      description: "TransactionController.cs L45-L60, L120-L135",
+      status: "not-started"
+    },
+    {
+      id: 2,
+      title: "移除BudgetService.cs中的未使用导入",
+      description: "删除using System.Text.RegularExpressions",
+      status: "not-started"
+    },
+    // ... 更多任务
+  ]
+})
+```
+
+2. **逐个执行**:
+   - 标记任务为 `in-progress`
+   - 使用 `multi_replace_string_in_file` 或 `replace_string_in_file` 修改代码
+   - 运行测试验证: `dotnet test` 或 `pnpm test`
+   - 标记任务为 `completed`
+   - 继续下一个
+
+3. **验证每个步骤**:
+   - 后端重构后运行: `dotnet build && dotnet test`
+   - 前端重构后运行: `pnpm lint && pnpm build`
+   - 确保没有引入编译错误或测试失败
+
+#### 3.3 异常处理
+**如果遇到预期外的问题**:
+- ✅ 立即停止后续重构
+- ✅ 报告问题详情
+- ✅ 调用 `question` 工具询问如何处理
+
+```javascript
+question({
+  header: "重构遇到问题",
+  questions: [{
+    question: "抽取方法后发现测试 `TestValidation` 失败了,如何处理?",
+    options: [
+      "回滚这个改动",
+      "修复测试用例",
+      "暂停,我来看看",
+      "继续其他重构点"
+    ]
+  }]
+})
+```
+
+### 阶段4: 验证和总结
+
+#### 4.1 全面验证
+**必须执行的验证**:
+- 所有单元测试通过
+- 项目成功构建
+- Lint检查通过
+- 关键功能手动验证(如适用)
+
+**验证命令**:
+```bash
+# 后端
+dotnet clean
+dotnet build EmailBill.sln
+dotnet test WebApi.Test/WebApi.Test.csproj
+
+# 前端
+cd Web
+pnpm lint
+pnpm build
+```
+
+#### 4.2 总结报告
+**提供清晰的总结**:
+```
+## 重构完成总结
+
+### ✅ 已完成的重构
+1. 抽取重复验证逻辑 (ValidationHelper.cs)
+   - 消除了 3 处重复代码
+   - 减少代码行数 45 行
+   
+2. 移除未使用的导入和变量
+   - BudgetService.cs: 移除 2 个未使用的 using
+   - TransactionController.cs: 移除 1 个未使用字段
+
+3. 改善方法命名
+   - DoWork → ProcessTransactionData (4 处调用点已更新)
+   - Calculate → CalculateMonthlyBudget (2 处调用点已更新)
+
+### 📊 重构影响
+- 修改文件数: 6
+- 新增文件数: 1 (ValidationHelper.cs)
+- 删除代码行数: 78
+- 新增代码行数: 42
+- 净减少代码: 36 行
+
+### ✅ 验证结果
+- ✓ 所有测试通过 (23/23)
+- ✓ 项目构建成功
+- ✓ Lint检查通过
+- ✓ 功能验证正常
+
+### 📝 建议的后续工作
+- 考虑为 ValidationHelper 添加单元测试
+- 可以进一步重构 DataProcessor 类的其他方法
+```
+
+## 常见重构模式
+
+### 1. 抽取公共方法
+**识别标准**: 代码块在多处重复出现(≥2次)
+**操作**: 
+- 创建独立方法或工具类
+- 保持方法签名简洁明确
+- 添加必要的注释和文档
+
+### 2. 抽取公共组件
+**识别标准**: UI组件或业务逻辑在多个视图/页面重复
+**操作**:
+- 创建可复用组件(Vue组件、Service类等)
+- 使用Props/参数传递可变部分
+- 确保组件职责单一
+
+### 3. 移除死代码
+**识别标准**: 
+- 未被调用的方法
+- 未被使用的变量、导入、依赖
+- 注释掉的代码
+**操作**:
+- 使用 `list_code_usages` 确认真正未使用
+- 谨慎删除(可能有隐式调用)
+- 使用Git历史作为备份
+
+### 4. 改善命名
+**识别标准**:
+- 名称不能表达意图(如 `DoWork`, `Process`, `temp`)
+- 名称与实际功能不符
+- 违反命名规范
+**操作**:
+- 使用 `list_code_usages` 找到所有使用点
+- 使用 `multi_replace_string_in_file` 批量更新
+- 确保命名符合项目规范(见AGENTS.md)
+
+### 5. 简化复杂逻辑
+**识别标准**:
+- 深层嵌套(>3层)
+- 过长方法(>50行)
+- 复杂条件判断
+**操作**:
+- 早返回模式(guard clauses)
+- 拆分子方法
+- 使用策略模式或查表法
+
+## 注意事项
+
+### ❌ 不要做
+- 在重构中添加新功能
+- 在重构中修复bug(除非bug是重构导致的)
+- 未经确认就大范围修改
+- 改变公开API而不考虑兼容性
+- 跳过测试验证
+
+### ✅ 要做
+- 保持每次重构的范围可控
+- 频繁提交代码(每完成一个重构点提交一次)
+- 确保测试覆盖率不降低
+- 保持代码风格一致
+- 记录重构的原因和收益
+
+## 项目特定规范
+
+### C# 代码重构
+- 遵循 `AGENTS.md` 中的 C# 代码风格
+- 使用 file-scoped namespace
+- 公共方法使用 XML 注释
+- 业务逻辑使用中文注释
+- 工具方法考虑放入 `Common` 项目
+
+### Vue/TypeScript 代码重构
+- 使用 Composition API
+- 组件放入 `src/components`
+- 遵循 ESLint 和 Prettier 规则
+- 使用 `@/` 别名避免相对路径
+- 提取的组件使用 Vant UI 风格
+
+## 总结
+
+代码重构是一个**谨慎的、迭代的、需要充分确认的**过程。核心要点:
+
+1. **理解先于行动** - 彻底理解需求和约束
+2. **交互式确认** - 使用 `question` 工具消除歧义
+3. **计划后执行** - 列出修改点并获得确认
+4. **小步快跑** - 逐个完成重构点,频繁验证
+5. **功能不变** - 始终确保行为一致性
diff --git a/.opencode/skills/openspec-apply-change/SKILL.cn.md b/.opencode/skills/openspec-apply-change/SKILL.cn.md
new file mode 100644
index 0000000..17a4d17
--- /dev/null
+++ b/.opencode/skills/openspec-apply-change/SKILL.cn.md
@@ -0,0 +1,156 @@
+---
+name: openspec-apply-change
+description: Implement tasks from an OpenSpec change. Use when the user wants to start implementing, continue implementation, or work through tasks.
+license: MIT
+compatibility: Requires openspec CLI.
+metadata:
+  author: openspec
+  version: "1.0"
+  generatedBy: "1.1.1"
+---
+
+从 OpenSpec 变更中实施任务。
+
+**输入**：可选地指定变更名称。如果省略,则检查是否可以从对话上下文推断。如果模糊或不明确,您**必须**提示用户选择可用的变更。
+
+**步骤**
+
+1. **选择变更**
+
+   如果提供了名称,则使用它。否则:
+   - 如果用户提到了变更,则从对话上下文推断
+   - 如果只存在一个活动变更,则自动选择
+   - 如果不明确,运行 `openspec list --json` 获取可用变更并使用 **AskUserQuestion 工具**让用户选择
+
+   始终宣布："使用变更: <名称>" 以及如何覆盖(例如 `/opsx-apply <其他>`)。
+
+2. **检查状态以了解 schema**
+   ```bash
+   openspec status --change "<name>" --json
+   ```
+   解析 JSON 以了解:
+   - `schemaName`: 正在使用的工作流(例如 "spec-driven")
+   - 哪个 artifact 包含任务(对于 spec-driven 通常是 "tasks",其他情况请检查状态)
+
+3. **获取应用说明**
+
+   ```bash
+   openspec instructions apply --change "<name>" --json
+   ```
+
+   这将返回:
+   - 上下文文件路径(因 schema 而异 - 可能是 proposal/specs/design/tasks 或 spec/tests/implementation/docs)
+   - 进度(总数、已完成、剩余)
+   - 带状态的任务列表
+   - 基于当前状态的动态指令
+
+   **处理状态:**
+   - 如果 `state: "blocked"`(缺少 artifacts): 显示消息,建议使用 openspec-continue-change
+   - 如果 `state: "all_done"`: 祝贺,建议归档
+   - 否则: 继续实施
+
+4. **读取上下文文件**
+
+   读取应用说明输出中 `contextFiles` 列出的文件。
+   文件取决于使用的 schema:
+   - **spec-driven**: proposal、specs、design、tasks
+   - 其他 schemas: 遵循 CLI 输出中的 contextFiles
+
+5. **显示当前进度**
+
+   显示:
+   - 正在使用的 Schema
+   - 进度: "已完成 N/M 个任务"
+   - 剩余任务概览
+   - 来自 CLI 的动态指令
+
+6. **实施任务(循环直到完成或阻塞)**
+
+   对于每个待处理任务:
+   - 显示正在处理哪个任务
+   - 进行所需的代码更改
+   - 保持更改最小且专注
+   - 在任务文件中标记任务完成: `- [ ]` → `- [x]`
+   - 继续下一个任务
+
+   **暂停如果:**
+   - 任务不清楚 → 请求澄清
+   - 实施揭示设计问题 → 建议更新 artifacts
+   - 遇到错误或阻塞 → 报告并等待指导
+   - 用户中断
+
+7. **完成或暂停时,显示状态**
+
+   显示:
+   - 本次会话完成的任务
+   - 总体进度: "已完成 N/M 个任务"
+   - 如果全部完成: 建议归档
+   - 如果暂停: 解释原因并等待指导
+
+**实施期间的输出**
+
+```
+## 正在实施: <change-name> (schema: <schema-name>)
+
+正在处理任务 3/7: <任务描述>
+[...正在实施...]
+✓ 任务完成
+
+正在处理任务 4/7: <任务描述>
+[...正在实施...]
+✓ 任务完成
+```
+
+**完成时的输出**
+
+```
+## 实施完成
+
+**变更:** <change-name>
+**Schema:** <schema-name>
+**进度:** 7/7 个任务完成 ✓
+
+### 本次会话已完成
+- [x] 任务 1
+- [x] 任务 2
+...
+
+所有任务完成! 准备归档此变更。
+```
+
+**暂停时的输出(遇到问题)**
+
+```
+## 实施已暂停
+
+**变更:** <change-name>
+**Schema:** <schema-name>
+**进度:** 已完成 4/7 个任务
+
+### 遇到的问题
+<问题描述>
+
+**选项:**
+1. <选项 1>
+2. <选项 2>
+3. 其他方法
+
+您想怎么做?
+```
+
+**护栏**
+- 持续处理任务直到完成或阻塞
+- 开始前始终读取上下文文件(从应用说明输出中)
+- 如果任务不明确,在实施前暂停并询问
+- 如果实施揭示问题,暂停并建议更新 artifact
+- 保持代码更改最小且限定在每个任务范围内
+- 完成每个任务后立即更新任务复选框
+- 遇到错误、阻塞或不清楚的需求时暂停 - 不要猜测
+- 使用 CLI 输出中的 contextFiles,不要假设特定文件名
+
+**流畅工作流集成**
+
+此技能支持"对变更的操作"模型:
+
+- **可以随时调用**: 在所有 artifacts 完成之前(如果存在任务)、部分实施后、与其他操作交错进行
+- **允许更新 artifact**: 如果实施揭示设计问题,建议更新 artifacts - 不是阶段锁定,灵活工作
diff --git a/.opencode/skills/openspec-apply-change/SKILL.md b/.opencode/skills/openspec-apply-change/SKILL.md
new file mode 100644
index 0000000..628c56e
--- /dev/null
+++ b/.opencode/skills/openspec-apply-change/SKILL.md
@@ -0,0 +1,156 @@
+---
+name: openspec-apply-change
+description: Implement tasks from an OpenSpec change. Use when the user wants to start implementing, continue implementation, or work through tasks.
+license: MIT
+compatibility: Requires openspec CLI.
+metadata:
+  author: openspec
+  version: "1.0"
+  generatedBy: "1.1.1"
+---
+
+Implement tasks from an OpenSpec change.
+
+**Input**: Optionally specify a change name. If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
+
+**Steps**
+
+1. **Select the change**
+
+   If a name is provided, use it. Otherwise:
+   - Infer from conversation context if the user mentioned a change
+   - Auto-select if only one active change exists
+   - If ambiguous, run `openspec list --json` to get available changes and use the **AskUserQuestion tool** to let the user select
+
+   Always announce: "Using change: <name>" and how to override (e.g., `/opsx-apply <other>`).
+
+2. **Check status to understand the schema**
+   ```bash
+   openspec status --change "<name>" --json
+   ```
+   Parse the JSON to understand:
+   - `schemaName`: The workflow being used (e.g., "spec-driven")
+   - Which artifact contains the tasks (typically "tasks" for spec-driven, check status for others)
+
+3. **Get apply instructions**
+
+   ```bash
+   openspec instructions apply --change "<name>" --json
+   ```
+
+   This returns:
+   - Context file paths (varies by schema - could be proposal/specs/design/tasks or spec/tests/implementation/docs)
+   - Progress (total, complete, remaining)
+   - Task list with status
+   - Dynamic instruction based on current state
+
+   **Handle states:**
+   - If `state: "blocked"` (missing artifacts): show message, suggest using openspec-continue-change
+   - If `state: "all_done"`: congratulate, suggest archive
+   - Otherwise: proceed to implementation
+
+4. **Read context files**
+
+   Read the files listed in `contextFiles` from the apply instructions output.
+   The files depend on the schema being used:
+   - **spec-driven**: proposal, specs, design, tasks
+   - Other schemas: follow the contextFiles from CLI output
+
+5. **Show current progress**
+
+   Display:
+   - Schema being used
+   - Progress: "N/M tasks complete"
+   - Remaining tasks overview
+   - Dynamic instruction from CLI
+
+6. **Implement tasks (loop until done or blocked)**
+
+   For each pending task:
+   - Show which task is being worked on
+   - Make the code changes required
+   - Keep changes minimal and focused
+   - Mark task complete in the tasks file: `- [ ]` → `- [x]`
+   - Continue to next task
+
+   **Pause if:**
+   - Task is unclear → ask for clarification
+   - Implementation reveals a design issue → suggest updating artifacts
+   - Error or blocker encountered → report and wait for guidance
+   - User interrupts
+
+7. **On completion or pause, show status**
+
+   Display:
+   - Tasks completed this session
+   - Overall progress: "N/M tasks complete"
+   - If all done: suggest archive
+   - If paused: explain why and wait for guidance
+
+**Output During Implementation**
+
+```
+## Implementing: <change-name> (schema: <schema-name>)
+
+Working on task 3/7: <task description>
+[...implementation happening...]
+✓ Task complete
+
+Working on task 4/7: <task description>
+[...implementation happening...]
+✓ Task complete
+```
+
+**Output On Completion**
+
+```
+## Implementation Complete
+
+**Change:** <change-name>
+**Schema:** <schema-name>
+**Progress:** 7/7 tasks complete ✓
+
+### Completed This Session
+- [x] Task 1
+- [x] Task 2
+...
+
+All tasks complete! Ready to archive this change.
+```
+
+**Output On Pause (Issue Encountered)**
+
+```
+## Implementation Paused
+
+**Change:** <change-name>
+**Schema:** <schema-name>
+**Progress:** 4/7 tasks complete
+
+### Issue Encountered
+<description of the issue>
+
+**Options:**
+1. <option 1>
+2. <option 2>
+3. Other approach
+
+What would you like to do?
+```
+
+**Guardrails**
+- Keep going through tasks until done or blocked
+- Always read context files before starting (from the apply instructions output)
+- If task is ambiguous, pause and ask before implementing
+- If implementation reveals issues, pause and suggest artifact updates
+- Keep code changes minimal and scoped to each task
+- Update task checkbox immediately after completing each task
+- Pause on errors, blockers, or unclear requirements - don't guess
+- Use contextFiles from CLI output, don't assume specific file names
+
+**Fluid Workflow Integration**
+
+This skill supports the "actions on a change" model:
+
+- **Can be invoked anytime**: Before all artifacts are done (if tasks exist), after partial implementation, interleaved with other actions
+- **Allows artifact updates**: If implementation reveals design issues, suggest updating artifacts - not phase-locked, work fluidly
diff --git a/.opencode/skills/openspec-archive-change/SKILL.cn.md b/.opencode/skills/openspec-archive-change/SKILL.cn.md
new file mode 100644
index 0000000..278ceec
--- /dev/null
+++ b/.opencode/skills/openspec-archive-change/SKILL.cn.md
@@ -0,0 +1,114 @@
+---
+name: openspec-archive-change
+description: Archive a completed change in the experimental workflow. Use when the user wants to finalize and archive a change after implementation is complete.
+license: MIT
+compatibility: Requires openspec CLI.
+metadata:
+  author: openspec
+  version: "1.0"
+  generatedBy: "1.1.1"
+---
+
+在实验工作流中归档已完成的变更。
+
+**输入**: 可选择指定变更名称。如果省略,检查是否可以从对话上下文中推断。如果模糊或不明确,你**必须**提示可用的变更。
+
+**步骤**
+
+1. **如果未提供变更名称,提示用户选择**
+
+   运行 `openspec list --json` 获取可用的变更。使用 **AskUserQuestion 工具**让用户选择。
+
+   仅显示活跃的变更 (尚未归档的)。
+   如果可用,包含每个变更使用的 schema。
+
+   **重要**: 不要猜测或自动选择变更。始终让用户选择。
+
+2. **检查 artifact 完成状态**
+
+   运行 `openspec status --change "<name>" --json` 检查 artifact 完成情况。
+
+   解析 JSON 以了解:
+   - `schemaName`: 正在使用的工作流
+   - `artifacts`: artifacts 列表及其状态 (`done` 或其他)
+
+   **如果任何 artifacts 不是 `done` 状态:**
+   - 显示警告,列出未完成的 artifacts
+   - 使用 **AskUserQuestion 工具**确认用户是否要继续
+   - 如果用户确认则继续
+
+3. **检查任务完成状态**
+
+   读取任务文件 (通常是 `tasks.md`) 检查未完成的任务。
+
+   统计标记为 `- [ ]` (未完成) vs `- [x]` (已完成) 的任务。
+
+   **如果发现未完成的任务:**
+   - 显示警告,显示未完成任务的数量
+   - 使用 **AskUserQuestion 工具**确认用户是否要继续
+   - 如果用户确认则继续
+
+   **如果不存在任务文件:** 无任务相关警告地继续。
+
+4. **评估 delta spec 同步状态**
+
+   检查 `openspec/changes/<name>/specs/` 中的 delta specs。如果不存在,无同步提示地继续。
+
+   **如果存在 delta specs:**
+   - 将每个 delta spec 与其对应的主 spec `openspec/specs/<capability>/spec.md` 比较
+   - 确定将应用哪些更改 (添加、修改、删除、重命名)
+   - 在提示前显示综合摘要
+
+   **提示选项:**
+   - 如果需要更改: "立即同步 (推荐)", "归档但不同步"
+   - 如果已同步: "立即归档", "仍然同步", "取消"
+
+   如果用户选择同步,执行 /opsx-sync 逻辑 (使用 openspec-sync-specs 技能)。无论选择什么都继续归档。
+
+5. **执行归档**
+
+   如果不存在则创建归档目录:
+   ```bash
+   mkdir -p openspec/changes/archive
+   ```
+
+   使用当前日期生成目标名称: `YYYY-MM-DD-<change-name>`
+
+   **检查目标是否已存在:**
+   - 如果是: 失败并显示错误,建议重命名现有归档或使用不同日期
+   - 如果否: 将变更目录移动到归档
+
+   ```bash
+   mv openspec/changes/<name> openspec/changes/archive/YYYY-MM-DD-<name>
+   ```
+
+6. **显示摘要**
+
+   显示归档完成摘要,包括:
+   - 变更名称
+   - 使用的 Schema
+   - 归档位置
+   - 是否同步了 specs (如果适用)
+   - 关于任何警告的注释 (未完成的 artifacts/任务)
+
+**成功时的输出**
+
+```
+## 归档完成
+
+**变更:** <change-name>
+**Schema:** <schema-name>
+**归档到:** openspec/changes/archive/YYYY-MM-DD-<name>/
+**Specs:** ✓ 已同步到主 specs (或 "无 delta specs" 或 "跳过同步")
+
+所有 artifacts 完成。所有任务完成。
+```
+
+**防护机制**
+- 如果未提供变更,始终提示选择
+- 使用 artifact 图 (openspec status --json) 进行完成度检查
+- 不要因警告而阻止归档 - 只需通知并确认
+- 移动到归档时保留 .openspec.yaml (它随目录一起移动)
+- 显示清晰的发生情况摘要
+- 如果请求同步,使用 openspec-sync-specs 方法 (代理驱动)
+- 如果存在 delta specs,在提示前始终运行同步评估并显示综合摘要
diff --git a/.opencode/skills/openspec-archive-change/SKILL.md b/.opencode/skills/openspec-archive-change/SKILL.md
new file mode 100644
index 0000000..07e9df4
--- /dev/null
+++ b/.opencode/skills/openspec-archive-change/SKILL.md
@@ -0,0 +1,114 @@
+---
+name: openspec-archive-change
+description: Archive a completed change in the experimental workflow. Use when the user wants to finalize and archive a change after implementation is complete.
+license: MIT
+compatibility: Requires openspec CLI.
+metadata:
+  author: openspec
+  version: "1.0"
+  generatedBy: "1.1.1"
+---
+
+Archive a completed change in the experimental workflow.
+
+**Input**: Optionally specify a change name. If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
+
+**Steps**
+
+1. **If no change name provided, prompt for selection**
+
+   Run `openspec list --json` to get available changes. Use the **AskUserQuestion tool** to let the user select.
+
+   Show only active changes (not already archived).
+   Include the schema used for each change if available.
+
+   **IMPORTANT**: Do NOT guess or auto-select a change. Always let the user choose.
+
+2. **Check artifact completion status**
+
+   Run `openspec status --change "<name>" --json` to check artifact completion.
+
+   Parse the JSON to understand:
+   - `schemaName`: The workflow being used
+   - `artifacts`: List of artifacts with their status (`done` or other)
+
+   **If any artifacts are not `done`:**
+   - Display warning listing incomplete artifacts
+   - Use **AskUserQuestion tool** to confirm user wants to proceed
+   - Proceed if user confirms
+
+3. **Check task completion status**
+
+   Read the tasks file (typically `tasks.md`) to check for incomplete tasks.
+
+   Count tasks marked with `- [ ]` (incomplete) vs `- [x]` (complete).
+
+   **If incomplete tasks found:**
+   - Display warning showing count of incomplete tasks
+   - Use **AskUserQuestion tool** to confirm user wants to proceed
+   - Proceed if user confirms
+
+   **If no tasks file exists:** Proceed without task-related warning.
+
+4. **Assess delta spec sync state**
+
+   Check for delta specs at `openspec/changes/<name>/specs/`. If none exist, proceed without sync prompt.
+
+   **If delta specs exist:**
+   - Compare each delta spec with its corresponding main spec at `openspec/specs/<capability>/spec.md`
+   - Determine what changes would be applied (adds, modifications, removals, renames)
+   - Show a combined summary before prompting
+
+   **Prompt options:**
+   - If changes needed: "Sync now (recommended)", "Archive without syncing"
+   - If already synced: "Archive now", "Sync anyway", "Cancel"
+
+   If user chooses sync, execute /opsx-sync logic (use the openspec-sync-specs skill). Proceed to archive regardless of choice.
+
+5. **Perform the archive**
+
+   Create the archive directory if it doesn't exist:
+   ```bash
+   mkdir -p openspec/changes/archive
+   ```
+
+   Generate target name using current date: `YYYY-MM-DD-<change-name>`
+
+   **Check if target already exists:**
+   - If yes: Fail with error, suggest renaming existing archive or using different date
+   - If no: Move the change directory to archive
+
+   ```bash
+   mv openspec/changes/<name> openspec/changes/archive/YYYY-MM-DD-<name>
+   ```
+
+6. **Display summary**
+
+   Show archive completion summary including:
+   - Change name
+   - Schema that was used
+   - Archive location
+   - Whether specs were synced (if applicable)
+   - Note about any warnings (incomplete artifacts/tasks)
+
+**Output On Success**
+
+```
+## Archive Complete
+
+**Change:** <change-name>
+**Schema:** <schema-name>
+**Archived to:** openspec/changes/archive/YYYY-MM-DD-<name>/
+**Specs:** ✓ Synced to main specs (or "No delta specs" or "Sync skipped")
+
+All artifacts complete. All tasks complete.
+```
+
+**Guardrails**
+- Always prompt for change selection if not provided
+- Use artifact graph (openspec status --json) for completion checking
+- Don't block archive on warnings - just inform and confirm
+- Preserve .openspec.yaml when moving to archive (it moves with the directory)
+- Show clear summary of what happened
+- If sync is requested, use openspec-sync-specs approach (agent-driven)
+- If delta specs exist, always run the sync assessment and show the combined summary before prompting
diff --git a/.opencode/skills/openspec-bulk-archive-change/SKILL.cn.md b/.opencode/skills/openspec-bulk-archive-change/SKILL.cn.md
new file mode 100644
index 0000000..d94775f
--- /dev/null
+++ b/.opencode/skills/openspec-bulk-archive-change/SKILL.cn.md
@@ -0,0 +1,246 @@
+---
+name: openspec-bulk-archive-change
+description: Archive multiple completed changes at once. Use when archiving several parallel changes.
+license: MIT
+compatibility: Requires openspec CLI.
+metadata:
+  author: openspec
+  version: "1.0"
+  generatedBy: "1.1.1"
+---
+
+在单个操作中归档多个已完成的变更。
+
+该技能允许你批量归档变更,通过检查代码库来确定实际实现的内容,智能地处理 spec 冲突。
+
+**输入**: 无需输入 (会提示选择)
+
+**步骤**
+
+1. **获取活跃的变更**
+
+   运行 `openspec list --json` 获取所有活跃的变更。
+
+   如果不存在活跃的变更,通知用户并停止。
+
+2. **提示变更选择**
+
+   使用 **AskUserQuestion 工具**进行多选,让用户选择变更:
+   - 显示每个变更及其 schema
+   - 包含"所有变更"选项
+   - 允许任意数量的选择 (1+ 即可,2+ 是典型用例)
+
+   **重要**: 不要自动选择。始终让用户选择。
+
+3. **批量验证 - 收集所有选定变更的状态**
+
+   对于每个选定的变更,收集:
+
+   a. **Artifact 状态** - 运行 `openspec status --change "<name>" --json`
+      - 解析 `schemaName` 和 `artifacts` 列表
+      - 注意哪些 artifacts 是 `done` 状态 vs 其他状态
+
+   b. **任务完成度** - 读取 `openspec/changes/<name>/tasks.md`
+      - 统计 `- [ ]` (未完成) vs `- [x]` (已完成)
+      - 如果不存在任务文件,注明 "无任务"
+
+   c. **Delta specs** - 检查 `openspec/changes/<name>/specs/` 目录
+      - 列出存在哪些 capability specs
+      - 对于每个,提取需求名称 (匹配 `### Requirement: <name>` 的行)
+
+4. **检测 spec 冲突**
+
+   建立 `capability -> [涉及它的变更]` 映射:
+
+   ```
+   auth -> [change-a, change-b]  <- 冲突 (2+ 个变更)
+   api  -> [change-c]            <- 正常 (只有 1 个变更)
+   ```
+
+   当 2+ 个选定的变更对同一个 capability 有 delta specs 时,存在冲突。
+
+5. **智能解决冲突**
+
+   **对于每个冲突**,调查代码库:
+
+   a. **读取 delta specs** 从每个冲突的变更中,了解每个声称添加/修改的内容
+
+   b. **搜索代码库**寻找实现证据:
+      - 寻找实现每个 delta spec 需求的代码
+      - 检查相关的文件、函数或测试
+
+   c. **确定解决方案**:
+      - 如果只有一个变更实际实现了 -> 同步那个的 specs
+      - 如果两者都实现了 -> 按时间顺序应用 (较旧的先,较新的覆盖)
+      - 如果都未实现 -> 跳过 spec 同步,警告用户
+
+   d. **记录解决方案**对于每个冲突:
+      - 应用哪个变更的 specs
+      - 以什么顺序 (如果两者都有)
+      - 理由 (在代码库中找到了什么)
+
+6. **显示综合状态表**
+
+   显示总结所有变更的表格:
+
+   ```
+   | 变更                | Artifacts | 任务  | Specs   | 冲突      | 状态   |
+   |--------------------|-----------|-------|---------|-----------|--------|
+   | schema-management  | 完成      | 5/5   | 2 delta | 无        | 就绪   |
+   | project-config     | 完成      | 3/3   | 1 delta | 无        | 就绪   |
+   | add-oauth          | 完成      | 4/4   | 1 delta | auth (!)  | 就绪*  |
+   | add-verify-skill   | 剩余 1    | 2/5   | 无      | 无        | 警告   |
+   ```
+
+   对于冲突,显示解决方案:
+   ```
+   * 冲突解决:
+     - auth spec: 将应用 add-oauth 然后 add-jwt (两者都已实现,按时间顺序)
+   ```
+
+   对于未完成的变更,显示警告:
+   ```
+   警告:
+   - add-verify-skill: 1 个未完成 artifact, 3 个未完成任务
+   ```
+
+7. **确认批量操作**
+
+   使用 **AskUserQuestion 工具**进行单次确认:
+
+   - "归档 N 个变更?" 根据状态提供选项
+   - 选项可能包括:
+     - "归档所有 N 个变更"
+     - "仅归档 N 个就绪的变更 (跳过未完成的)"
+     - "取消"
+
+   如果有未完成的变更,明确说明它们将带警告归档。
+
+8. **为每个确认的变更执行归档**
+
+   按确定的顺序处理变更 (遵循冲突解决方案):
+
+   a. **同步 specs** 如果存在 delta specs:
+      - 使用 openspec-sync-specs 方法 (代理驱动的智能合并)
+      - 对于冲突,按已解决的顺序应用
+      - 跟踪是否完成同步
+
+   b. **执行归档**:
+      ```bash
+      mkdir -p openspec/changes/archive
+      mv openspec/changes/<name> openspec/changes/archive/YYYY-MM-DD-<name>
+      ```
+
+   c. **跟踪结果**对于每个变更:
+      - 成功: 成功归档
+      - 失败: 归档期间出错 (记录错误)
+      - 跳过: 用户选择不归档 (如果适用)
+
+9. **显示摘要**
+
+   显示最终结果:
+
+   ```
+   ## 批量归档完成
+
+   已归档 3 个变更:
+   - schema-management-cli -> archive/2026-01-19-schema-management-cli/
+   - project-config -> archive/2026-01-19-project-config/
+   - add-oauth -> archive/2026-01-19-add-oauth/
+
+   跳过 1 个变更:
+   - add-verify-skill (用户选择不归档未完成的)
+
+   Spec 同步摘要:
+   - 4 个 delta specs 同步到主 specs
+   - 1 个冲突已解决 (auth: 按时间顺序应用两者)
+   ```
+
+   如果有任何失败:
+   ```
+   失败 1 个变更:
+   - some-change: 归档目录已存在
+   ```
+
+**冲突解决示例**
+
+示例 1: 只有一个已实现
+```
+冲突: specs/auth/spec.md 被 [add-oauth, add-jwt] 涉及
+
+检查 add-oauth:
+- Delta 添加了 "OAuth 提供者集成" 需求
+- 搜索代码库... 找到 src/auth/oauth.ts 实现 OAuth 流程
+
+检查 add-jwt:
+- Delta 添加了 "JWT 令牌处理" 需求
+- 搜索代码库... 未找到 JWT 实现
+
+解决: 只有 add-oauth 已实现。将仅同步 add-oauth specs。
+```
+
+示例 2: 两者都已实现
+```
+冲突: specs/api/spec.md 被 [add-rest-api, add-graphql] 涉及
+
+检查 add-rest-api (创建于 2026-01-10):
+- Delta 添加了 "REST 端点" 需求
+- 搜索代码库... 找到 src/api/rest.ts
+
+检查 add-graphql (创建于 2026-01-15):
+- Delta 添加了 "GraphQL Schema" 需求
+- 搜索代码库... 找到 src/api/graphql.ts
+
+解决: 两者都已实现。将先应用 add-rest-api specs,
+然后应用 add-graphql specs (按时间顺序,较新的优先)。
+```
+
+**成功时的输出**
+
+```
+## 批量归档完成
+
+已归档 N 个变更:
+- <change-1> -> archive/YYYY-MM-DD-<change-1>/
+- <change-2> -> archive/YYYY-MM-DD-<change-2>/
+
+Spec 同步摘要:
+- N 个 delta specs 同步到主 specs
+- 无冲突 (或: M 个冲突已解决)
+```
+
+**部分成功时的输出**
+
+```
+## 批量归档完成 (部分)
+
+已归档 N 个变更:
+- <change-1> -> archive/YYYY-MM-DD-<change-1>/
+
+跳过 M 个变更:
+- <change-2> (用户选择不归档未完成的)
+
+失败 K 个变更:
+- <change-3>: 归档目录已存在
+```
+
+**无变更时的输出**
+
+```
+## 无变更可归档
+
+未找到活跃的变更。使用 `/opsx-new` 创建新变更。
+```
+
+**防护机制**
+- 允许任意数量的变更 (1+ 即可,2+ 是典型用例)
+- 始终提示选择,永不自动选择
+- 提前检测 spec 冲突并通过检查代码库解决
+- 当两个变更都已实现时,按时间顺序应用 specs
+- 仅当实现缺失时跳过 spec 同步 (警告用户)
+- 在确认前显示清晰的每个变更状态
+- 对整个批次使用单次确认
+- 跟踪并报告所有结果 (成功/跳过/失败)
+- 移动到归档时保留 .openspec.yaml
+- 归档目录目标使用当前日期: YYYY-MM-DD-<name>
+- 如果归档目标存在,使该变更失败但继续处理其他变更
diff --git a/.opencode/skills/openspec-bulk-archive-change/SKILL.md b/.opencode/skills/openspec-bulk-archive-change/SKILL.md
new file mode 100644
index 0000000..bf4214f
--- /dev/null
+++ b/.opencode/skills/openspec-bulk-archive-change/SKILL.md
@@ -0,0 +1,246 @@
+---
+name: openspec-bulk-archive-change
+description: Archive multiple completed changes at once. Use when archiving several parallel changes.
+license: MIT
+compatibility: Requires openspec CLI.
+metadata:
+  author: openspec
+  version: "1.0"
+  generatedBy: "1.1.1"
+---
+
+Archive multiple completed changes in a single operation.
+
+This skill allows you to batch-archive changes, handling spec conflicts intelligently by checking the codebase to determine what's actually implemented.
+
+**Input**: None required (prompts for selection)
+
+**Steps**
+
+1. **Get active changes**
+
+   Run `openspec list --json` to get all active changes.
+
+   If no active changes exist, inform user and stop.
+
+2. **Prompt for change selection**
+
+   Use **AskUserQuestion tool** with multi-select to let user choose changes:
+   - Show each change with its schema
+   - Include an option for "All changes"
+   - Allow any number of selections (1+ works, 2+ is the typical use case)
+
+   **IMPORTANT**: Do NOT auto-select. Always let the user choose.
+
+3. **Batch validation - gather status for all selected changes**
+
+   For each selected change, collect:
+
+   a. **Artifact status** - Run `openspec status --change "<name>" --json`
+      - Parse `schemaName` and `artifacts` list
+      - Note which artifacts are `done` vs other states
+
+   b. **Task completion** - Read `openspec/changes/<name>/tasks.md`
+      - Count `- [ ]` (incomplete) vs `- [x]` (complete)
+      - If no tasks file exists, note as "No tasks"
+
+   c. **Delta specs** - Check `openspec/changes/<name>/specs/` directory
+      - List which capability specs exist
+      - For each, extract requirement names (lines matching `### Requirement: <name>`)
+
+4. **Detect spec conflicts**
+
+   Build a map of `capability -> [changes that touch it]`:
+
+   ```
+   auth -> [change-a, change-b]  <- CONFLICT (2+ changes)
+   api  -> [change-c]            <- OK (only 1 change)
+   ```
+
+   A conflict exists when 2+ selected changes have delta specs for the same capability.
+
+5. **Resolve conflicts agentically**
+
+   **For each conflict**, investigate the codebase:
+
+   a. **Read the delta specs** from each conflicting change to understand what each claims to add/modify
+
+   b. **Search the codebase** for implementation evidence:
+      - Look for code implementing requirements from each delta spec
+      - Check for related files, functions, or tests
+
+   c. **Determine resolution**:
+      - If only one change is actually implemented -> sync that one's specs
+      - If both implemented -> apply in chronological order (older first, newer overwrites)
+      - If neither implemented -> skip spec sync, warn user
+
+   d. **Record resolution** for each conflict:
+      - Which change's specs to apply
+      - In what order (if both)
+      - Rationale (what was found in codebase)
+
+6. **Show consolidated status table**
+
+   Display a table summarizing all changes:
+
+   ```
+   | Change               | Artifacts | Tasks | Specs   | Conflicts | Status |
+   |---------------------|-----------|-------|---------|-----------|--------|
+   | schema-management   | Done      | 5/5   | 2 delta | None      | Ready  |
+   | project-config      | Done      | 3/3   | 1 delta | None      | Ready  |
+   | add-oauth           | Done      | 4/4   | 1 delta | auth (!)  | Ready* |
+   | add-verify-skill    | 1 left    | 2/5   | None    | None      | Warn   |
+   ```
+
+   For conflicts, show the resolution:
+   ```
+   * Conflict resolution:
+     - auth spec: Will apply add-oauth then add-jwt (both implemented, chronological order)
+   ```
+
+   For incomplete changes, show warnings:
+   ```
+   Warnings:
+   - add-verify-skill: 1 incomplete artifact, 3 incomplete tasks
+   ```
+
+7. **Confirm batch operation**
+
+   Use **AskUserQuestion tool** with a single confirmation:
+
+   - "Archive N changes?" with options based on status
+   - Options might include:
+     - "Archive all N changes"
+     - "Archive only N ready changes (skip incomplete)"
+     - "Cancel"
+
+   If there are incomplete changes, make clear they'll be archived with warnings.
+
+8. **Execute archive for each confirmed change**
+
+   Process changes in the determined order (respecting conflict resolution):
+
+   a. **Sync specs** if delta specs exist:
+      - Use the openspec-sync-specs approach (agent-driven intelligent merge)
+      - For conflicts, apply in resolved order
+      - Track if sync was done
+
+   b. **Perform the archive**:
+      ```bash
+      mkdir -p openspec/changes/archive
+      mv openspec/changes/<name> openspec/changes/archive/YYYY-MM-DD-<name>
+      ```
+
+   c. **Track outcome** for each change:
+      - Success: archived successfully
+      - Failed: error during archive (record error)
+      - Skipped: user chose not to archive (if applicable)
+
+9. **Display summary**
+
+   Show final results:
+
+   ```
+   ## Bulk Archive Complete
+
+   Archived 3 changes:
+   - schema-management-cli -> archive/2026-01-19-schema-management-cli/
+   - project-config -> archive/2026-01-19-project-config/
+   - add-oauth -> archive/2026-01-19-add-oauth/
+
+   Skipped 1 change:
+   - add-verify-skill (user chose not to archive incomplete)
+
+   Spec sync summary:
+   - 4 delta specs synced to main specs
+   - 1 conflict resolved (auth: applied both in chronological order)
+   ```
+
+   If any failures:
+   ```
+   Failed 1 change:
+   - some-change: Archive directory already exists
+   ```
+
+**Conflict Resolution Examples**
+
+Example 1: Only one implemented
+```
+Conflict: specs/auth/spec.md touched by [add-oauth, add-jwt]
+
+Checking add-oauth:
+- Delta adds "OAuth Provider Integration" requirement
+- Searching codebase... found src/auth/oauth.ts implementing OAuth flow
+
+Checking add-jwt:
+- Delta adds "JWT Token Handling" requirement
+- Searching codebase... no JWT implementation found
+
+Resolution: Only add-oauth is implemented. Will sync add-oauth specs only.
+```
+
+Example 2: Both implemented
+```
+Conflict: specs/api/spec.md touched by [add-rest-api, add-graphql]
+
+Checking add-rest-api (created 2026-01-10):
+- Delta adds "REST Endpoints" requirement
+- Searching codebase... found src/api/rest.ts
+
+Checking add-graphql (created 2026-01-15):
+- Delta adds "GraphQL Schema" requirement
+- Searching codebase... found src/api/graphql.ts
+
+Resolution: Both implemented. Will apply add-rest-api specs first,
+then add-graphql specs (chronological order, newer takes precedence).
+```
+
+**Output On Success**
+
+```
+## Bulk Archive Complete
+
+Archived N changes:
+- <change-1> -> archive/YYYY-MM-DD-<change-1>/
+- <change-2> -> archive/YYYY-MM-DD-<change-2>/
+
+Spec sync summary:
+- N delta specs synced to main specs
+- No conflicts (or: M conflicts resolved)
+```
+
+**Output On Partial Success**
+
+```
+## Bulk Archive Complete (partial)
+
+Archived N changes:
+- <change-1> -> archive/YYYY-MM-DD-<change-1>/
+
+Skipped M changes:
+- <change-2> (user chose not to archive incomplete)
+
+Failed K changes:
+- <change-3>: Archive directory already exists
+```
+
+**Output When No Changes**
+
+```
+## No Changes to Archive
+
+No active changes found. Use `/opsx-new` to create a new change.
+```
+
+**Guardrails**
+- Allow any number of changes (1+ is fine, 2+ is the typical use case)
+- Always prompt for selection, never auto-select
+- Detect spec conflicts early and resolve by checking codebase
+- When both changes are implemented, apply specs in chronological order
+- Skip spec sync only when implementation is missing (warn user)
+- Show clear per-change status before confirming
+- Use single confirmation for entire batch
+- Track and report all outcomes (success/skip/fail)
+- Preserve .openspec.yaml when moving to archive
+- Archive directory target uses current date: YYYY-MM-DD-<name>
+- If archive target exists, fail that change but continue with others
diff --git a/.opencode/skills/openspec-continue-change/SKILL.cn.md b/.opencode/skills/openspec-continue-change/SKILL.cn.md
new file mode 100644
index 0000000..913a568
--- /dev/null
+++ b/.opencode/skills/openspec-continue-change/SKILL.cn.md
@@ -0,0 +1,118 @@
+---
+name: openspec-continue-change
+description: Continue working on an OpenSpec change by creating the next artifact. Use when the user wants to progress their change, create the next artifact, or continue their workflow.
+license: MIT
+compatibility: Requires openspec CLI.
+metadata:
+  author: openspec
+  version: "1.0"
+  generatedBy: "1.1.1"
+---
+
+通过创建下一个 artifact 来继续处理变更。
+
+**输入**：可选地指定变更名称。如果省略,则检查是否可以从对话上下文推断。如果模糊或不明确,您**必须**提示用户选择可用的变更。
+
+**步骤**
+
+1. **如果未提供变更名称,提示选择**
+
+   运行 `openspec list --json` 获取按最近修改时间排序的可用变更。然后使用 **AskUserQuestion 工具**让用户选择要处理的变更。
+
+   将最近修改的前 3-4 个变更作为选项呈现,显示:
+   - 变更名称
+   - Schema(如果存在 `schema` 字段则显示,否则为 "spec-driven")
+   - 状态(例如 "0/5 个任务"、"完成"、"无任务")
+   - 最近修改时间(来自 `lastModified` 字段)
+
+   将最近修改的变更标记为 "(推荐)",因为这可能是用户想要继续的内容。
+
+   **重要**: 不要猜测或自动选择变更。始终让用户选择。
+
+2. **检查当前状态**
+   ```bash
+   openspec status --change "<name>" --json
+   ```
+   解析 JSON 以了解当前状态。响应包括:
+   - `schemaName`: 正在使用的工作流 schema(例如 "spec-driven")
+   - `artifacts`: 包含状态的 artifacts 数组("done"、"ready"、"blocked")
+   - `isComplete`: 指示所有 artifacts 是否完成的布尔值
+
+3. **根据状态采取行动**:
+
+   ---
+
+   **如果所有 artifacts 都已完成(`isComplete: true`)**:
+   - 祝贺用户
+   - 显示最终状态,包括使用的 schema
+   - 建议: "所有 artifacts 已创建! 现在可以实施此变更或归档它。"
+   - 停止
+
+   ---
+
+   **如果 artifacts 准备创建**(状态显示 `status: "ready"` 的 artifacts):
+   - 从状态输出中选择**第一个** `status: "ready"` 的 artifact
+   - 获取其说明:
+     ```bash
+     openspec instructions <artifact-id> --change "<name>" --json
+     ```
+   - 解析 JSON。关键字段是:
+     - `context`: 项目背景(对您的约束 - 不要包含在输出中)
+     - `rules`: Artifact 特定规则(对您的约束 - 不要包含在输出中)
+     - `template`: 用于输出文件的结构
+     - `instruction`: Schema 特定指导
+     - `outputPath`: artifact 的写入位置
+     - `dependencies`: 已完成的 artifacts,读取以获取上下文
+   - **创建 artifact 文件**:
+     - 读取任何已完成的依赖文件以获取上下文
+     - 使用 `template` 作为结构 - 填充其各个部分
+     - 在写入时应用 `context` 和 `rules` 作为约束 - 但不要将它们复制到文件中
+     - 写入说明中指定的输出路径
+   - 显示创建的内容以及现在解锁的内容
+   - 创建一个 artifact 后停止
+
+   ---
+
+   **如果没有 artifacts 准备好(全部被阻塞)**:
+   - 使用有效的 schema 不应该发生这种情况
+   - 显示状态并建议检查问题
+
+4. **创建 artifact 后,显示进度**
+   ```bash
+   openspec status --change "<name>"
+   ```
+
+**输出**
+
+每次调用后,显示:
+- 创建了哪个 artifact
+- 正在使用的 Schema 工作流
+- 当前进度(已完成 N/M)
+- 现在解锁了哪些 artifacts
+- 提示: "想要继续吗? 只需让我继续或告诉我下一步该做什么。"
+
+**Artifact 创建指南**
+
+artifact 类型及其用途取决于 schema。使用说明输出中的 `instruction` 字段来了解要创建什么。
+
+常见 artifact 模式:
+
+**spec-driven schema**(proposal → specs → design → tasks):
+- **proposal.md**: 如果不清楚,询问用户关于变更的信息。填写为什么、什么变更、能力、影响。
+  - Capabilities 部分至关重要 - 列出的每个能力都需要一个 spec 文件。
+- **specs/<capability>/spec.md**: 为 proposal 的 Capabilities 部分列出的每个能力创建一个 spec(使用能力名称,而不是变更名称)。
+- **design.md**: 记录技术决策、架构和实施方法。
+- **tasks.md**: 将实施分解为带复选框的任务。
+
+对于其他 schemas,遵循 CLI 输出中的 `instruction` 字段。
+
+**护栏**
+- 每次调用创建一个 artifact
+- 在创建新 artifact 之前始终读取依赖 artifacts
+- 永远不要跳过 artifacts 或无序创建
+- 如果上下文不清楚,在创建前询问用户
+- 写入后验证 artifact 文件存在,然后再标记进度
+- 使用 schema 的 artifact 序列,不要假设特定的 artifact 名称
+- **重要**: `context` 和 `rules` 是对您的约束,不是文件内容
+  - 不要将 `<context>`、`<rules>`、`<project_context>` 块复制到 artifact 中
+  - 这些指导您写什么,但永远不应出现在输出中
diff --git a/.opencode/skills/openspec-continue-change/SKILL.md b/.opencode/skills/openspec-continue-change/SKILL.md
new file mode 100644
index 0000000..5060b2f
--- /dev/null
+++ b/.opencode/skills/openspec-continue-change/SKILL.md
@@ -0,0 +1,118 @@
+---
+name: openspec-continue-change
+description: Continue working on an OpenSpec change by creating the next artifact. Use when the user wants to progress their change, create the next artifact, or continue their workflow.
+license: MIT
+compatibility: Requires openspec CLI.
+metadata:
+  author: openspec
+  version: "1.0"
+  generatedBy: "1.1.1"
+---
+
+Continue working on a change by creating the next artifact.
+
+**Input**: Optionally specify a change name. If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
+
+**Steps**
+
+1. **If no change name provided, prompt for selection**
+
+   Run `openspec list --json` to get available changes sorted by most recently modified. Then use the **AskUserQuestion tool** to let the user select which change to work on.
+
+   Present the top 3-4 most recently modified changes as options, showing:
+   - Change name
+   - Schema (from `schema` field if present, otherwise "spec-driven")
+   - Status (e.g., "0/5 tasks", "complete", "no tasks")
+   - How recently it was modified (from `lastModified` field)
+
+   Mark the most recently modified change as "(Recommended)" since it's likely what the user wants to continue.
+
+   **IMPORTANT**: Do NOT guess or auto-select a change. Always let the user choose.
+
+2. **Check current status**
+   ```bash
+   openspec status --change "<name>" --json
+   ```
+   Parse the JSON to understand current state. The response includes:
+   - `schemaName`: The workflow schema being used (e.g., "spec-driven")
+   - `artifacts`: Array of artifacts with their status ("done", "ready", "blocked")
+   - `isComplete`: Boolean indicating if all artifacts are complete
+
+3. **Act based on status**:
+
+   ---
+
+   **If all artifacts are complete (`isComplete: true`)**:
+   - Congratulate the user
+   - Show final status including the schema used
+   - Suggest: "All artifacts created! You can now implement this change or archive it."
+   - STOP
+
+   ---
+
+   **If artifacts are ready to create** (status shows artifacts with `status: "ready"`):
+   - Pick the FIRST artifact with `status: "ready"` from the status output
+   - Get its instructions:
+     ```bash
+     openspec instructions <artifact-id> --change "<name>" --json
+     ```
+   - Parse the JSON. The key fields are:
+     - `context`: Project background (constraints for you - do NOT include in output)
+     - `rules`: Artifact-specific rules (constraints for you - do NOT include in output)
+     - `template`: The structure to use for your output file
+     - `instruction`: Schema-specific guidance
+     - `outputPath`: Where to write the artifact
+     - `dependencies`: Completed artifacts to read for context
+   - **Create the artifact file**:
+     - Read any completed dependency files for context
+     - Use `template` as the structure - fill in its sections
+     - Apply `context` and `rules` as constraints when writing - but do NOT copy them into the file
+     - Write to the output path specified in instructions
+   - Show what was created and what's now unlocked
+   - STOP after creating ONE artifact
+
+   ---
+
+   **If no artifacts are ready (all blocked)**:
+   - This shouldn't happen with a valid schema
+   - Show status and suggest checking for issues
+
+4. **After creating an artifact, show progress**
+   ```bash
+   openspec status --change "<name>"
+   ```
+
+**Output**
+
+After each invocation, show:
+- Which artifact was created
+- Schema workflow being used
+- Current progress (N/M complete)
+- What artifacts are now unlocked
+- Prompt: "Want to continue? Just ask me to continue or tell me what to do next."
+
+**Artifact Creation Guidelines**
+
+The artifact types and their purpose depend on the schema. Use the `instruction` field from the instructions output to understand what to create.
+
+Common artifact patterns:
+
+**spec-driven schema** (proposal → specs → design → tasks):
+- **proposal.md**: Ask user about the change if not clear. Fill in Why, What Changes, Capabilities, Impact.
+  - The Capabilities section is critical - each capability listed will need a spec file.
+- **specs/<capability>/spec.md**: Create one spec per capability listed in the proposal's Capabilities section (use the capability name, not the change name).
+- **design.md**: Document technical decisions, architecture, and implementation approach.
+- **tasks.md**: Break down implementation into checkboxed tasks.
+
+For other schemas, follow the `instruction` field from the CLI output.
+
+**Guardrails**
+- Create ONE artifact per invocation
+- Always read dependency artifacts before creating a new one
+- Never skip artifacts or create out of order
+- If context is unclear, ask the user before creating
+- Verify the artifact file exists after writing before marking progress
+- Use the schema's artifact sequence, don't assume specific artifact names
+- **IMPORTANT**: `context` and `rules` are constraints for YOU, not content for the file
+  - Do NOT copy `<context>`, `<rules>`, `<project_context>` blocks into the artifact
+  - These guide what you write, but should never appear in the output
diff --git a/.opencode/skills/openspec-explore/SKILL.cn.md b/.opencode/skills/openspec-explore/SKILL.cn.md
new file mode 100644
index 0000000..7d1a675
--- /dev/null
+++ b/.opencode/skills/openspec-explore/SKILL.cn.md
@@ -0,0 +1,289 @@
+---
+name: openspec-explore
+description: Enter explore mode - a thinking partner for exploring ideas, investigating problems, and clarifying requirements. Use when the user wants to think through something before or during a change.
+license: MIT
+compatibility: Requires openspec CLI.
+metadata:
+  author: openspec
+  version: "1.0"
+  generatedBy: "1.1.1"
+---
+
+进入探索模式。深入思考。自由可视化。跟随对话到任何方向。
+
+**重要: 探索模式是用于思考,而不是实施。**您可以读取文件、搜索代码和调查代码库,但您**绝不能**编写代码或实施功能。如果用户要求您实施某些内容,提醒他们首先退出探索模式(例如,使用 `/opsx-new` 或 `/opsx-ff` 开始变更)。如果用户要求,您**可以**创建 OpenSpec artifacts(proposals、designs、specs)——这是捕获思考,而不是实施。
+
+**这是一种姿态,而不是工作流。**没有固定步骤,没有必需的序列,没有强制性输出。您是一个思考伙伴,帮助用户探索。
+
+---
+
+## 姿态
+
+- **好奇,而非规定** - 提出自然出现的问题,不要遵循脚本
+- **开放线索,而非审问** - 提出多个有趣的方向,让用户跟随共鸣的内容。不要将他们引导到单一的问题路径。
+- **可视化** - 当有助于澄清思考时,大量使用 ASCII 图表
+- **适应性** - 跟随有趣的线索,在新信息出现时调整
+- **耐心** - 不要急于得出结论,让问题的形状自然显现
+- **扎根** - 在相关时探索实际代码库,不只是理论化
+
+---
+
+## 您可能做什么
+
+根据用户带来的内容,您可能:
+
+**探索问题空间**
+- 提出从他们所说的内容中自然产生的澄清问题
+- 挑战假设
+- 重新定义问题
+- 寻找类比
+
+**调查代码库**
+- 映射与讨论相关的现有架构
+- 找到集成点
+- 识别已在使用的模式
+- 揭示隐藏的复杂性
+
+**比较选项**
+- 头脑风暴多种方法
+- 构建比较表
+- 勾勒权衡
+- 推荐路径(如果被询问)
+
+**可视化**
+```
+┌─────────────────────────────────────────┐
+│     大量使用 ASCII 图表                  │
+├─────────────────────────────────────────┤
+│                                         │
+│   ┌────────┐         ┌────────┐        │
+│   │ 状态   │────────▶│ 状态   │        │
+│   │   A    │         │   B    │        │
+│   └────────┘         └────────┘        │
+│                                         │
+│   系统图、状态机、数据流、              │
+│   架构草图、依赖图、比较表              │
+│                                         │
+└─────────────────────────────────────────┘
+```
+
+**揭示风险和未知因素**
+- 识别可能出错的地方
+- 找到理解上的差距
+- 建议探索或调查
+
+---
+
+## OpenSpec 感知
+
+您拥有 OpenSpec 系统的完整上下文。自然地使用它,不要强制。
+
+### 检查上下文
+
+开始时,快速检查存在什么:
+```bash
+openspec list --json
+```
+
+这会告诉您:
+- 是否有活动变更
+- 它们的名称、schemas 和状态
+- 用户可能正在处理什么
+
+### 当不存在变更时
+
+自由思考。当见解具体化时,您可能会提供:
+
+- "这感觉足够扎实可以开始变更了。想让我创建一个吗?"
+  → 可以过渡到 `/opsx-new` 或 `/opsx-ff`
+- 或继续探索 - 不必急于正式化
+
+### 当存在变更时
+
+如果用户提到变更或您检测到相关变更:
+
+1. **读取现有 artifacts 以获取上下文**
+   - `openspec/changes/<name>/proposal.md`
+   - `openspec/changes/<name>/design.md`
+   - `openspec/changes/<name>/tasks.md`
+   - 等等
+
+2. **在对话中自然引用它们**
+   - "您的设计提到使用 Redis,但我们刚刚意识到 SQLite 更合适..."
+   - "proposal 将范围限定为高级用户,但我们现在考虑所有人..."
+
+3. **在做出决策时提供捕获建议**
+
+   | 见解类型 | 捕获位置 |
+   |---------|----------|
+   | 发现新需求 | `specs/<capability>/spec.md` |
+   | 需求变更 | `specs/<capability>/spec.md` |
+   | 做出设计决策 | `design.md` |
+   | 范围变更 | `proposal.md` |
+   | 识别新工作 | `tasks.md` |
+   | 假设失效 | 相关 artifact |
+
+   示例建议:
+   - "这是一个设计决策。在 design.md 中捕获它?"
+   - "这是一个新需求。添加到 specs?"
+   - "这改变了范围。更新 proposal?"
+
+4. **用户决定** - 提供建议并继续。不要施压。不要自动捕获。
+
+---
+
+## 您不必做什么
+
+- 遵循脚本
+- 每次都问相同的问题
+- 产生特定的 artifact
+- 得出结论
+- 如果有价值的切线,保持主题
+- 简短(这是思考时间)
+
+---
+
+## 处理不同的入口点
+
+**用户带来模糊想法:**
+```
+用户: 我在考虑添加实时协作功能
+
+您: 实时协作是一个很大的空间。让我想想...
+
+      协作频谱
+      ════════════════════════════════════════════
+
+      意识             协调              同步
+          │                │                │
+          ▼                ▼                ▼
+      ┌────────┐      ┌────────┐       ┌────────┐
+      │在线状态│      │ 光标   │       │  CRDT  │
+      │  "3人  │      │ 多选   │       │无冲突  │
+      │在线"   │      │        │       │        │
+      └────────┘      └────────┘       └────────┘
+          │                │                │
+       简单             中等             复杂
+
+      您的想法是什么?
+```
+
+**用户带来具体问题:**
+```
+用户: 认证系统一团糟
+
+您: [读取代码库]
+
+     ┌─────────────────────────────────────────────┐
+     │              当前认证流程                    │
+     └─────────────────────────────────────────────┘
+                        │
+          ┌─────────────┼─────────────┐
+          ▼             ▼             ▼
+     ┌─────────┐  ┌─────────┐  ┌─────────┐
+     │ Google  │  │  GitHub │  │  Email  │
+     │  OAuth  │  │  OAuth  │  │  Magic  │
+     └────┬────┘  └────┬────┘  └────┬────┘
+          │             │             │
+          └─────────────┼─────────────┘
+                        ▼
+                  ┌───────────┐
+                  │  Session  │
+                  └─────┬─────┘
+                        │
+                        ▼
+                  ┌───────────┐
+                  │   Perms   │
+                  └───────────┘
+
+     我看到三处纠缠。哪一个在燃烧?
+```
+
+**用户在实施中卡住:**
+```
+用户: /opsx-explore add-auth-system
+      OAuth 集成比预期的更复杂
+
+您: [读取变更 artifacts]
+
+     您在任务 4: "实施 OAuth 流程"
+
+     让我跟踪涉及的内容...
+
+     [绘制图表,探索选项,建议路径]
+
+     想要更新设计以反映这一点吗?
+     或者添加一个探索任务来调查?
+```
+
+**用户想要比较选项:**
+```
+用户: 我们应该使用 Postgres 还是 SQLite?
+
+您: 通用答案很无聊。上下文是什么?
+
+用户: 一个跟踪本地开发环境的 CLI 工具
+
+您: 这改变了一切。
+
+     ┌─────────────────────────────────────────────────┐
+     │         CLI 工具数据存储                        │
+     └─────────────────────────────────────────────────┘
+
+     关键约束:
+     • 没有运行的守护进程
+     • 必须离线工作
+     • 单用户
+
+                  SQLite          Postgres
+     部署         嵌入式 ✓        需要服务器 ✗
+     离线         是 ✓           否 ✗
+     单文件       是 ✓           否 ✗
+
+     SQLite。甚至不接近。
+
+     除非... 有同步组件吗?
+```
+
+---
+
+## 结束探索
+
+没有必需的结束。探索可能:
+
+- **流向行动**: "准备开始了吗? /opsx-new 或 /opsx-ff"
+- **导致 artifact 更新**: "用这些决策更新了 design.md"
+- **只是提供清晰度**: 用户得到了他们需要的,继续前进
+- **稍后继续**: "我们可以随时继续这个"
+
+当感觉事情正在具体化时,您可能会总结:
+
+```
+## 我们弄清楚了什么
+
+**问题**: [具体化的理解]
+
+**方法**: [如果出现了一个]
+
+**开放问题**: [如果还有的话]
+
+**下一步**(如果准备好):
+- 创建变更: /opsx-new <name>
+- 快进到任务: /opsx-ff <name>
+- 继续探索: 继续交谈
+```
+
+但此总结是可选的。有时思考本身就是价值。
+
+---
+
+## 护栏
+
+- **不要实施** - 永远不要编写代码或实施功能。创建 OpenSpec artifacts 是可以的,编写应用程序代码则不行。
+- **不要假装理解** - 如果某些东西不清楚,深入挖掘
+- **不要急** - 探索是思考时间,不是任务时间
+- **不要强制结构** - 让模式自然显现
+- **不要自动捕获** - 提供保存见解的建议,不要直接做
+- **要可视化** - 一个好的图表胜过许多段落
+- **要探索代码库** - 在现实中基础讨论
+- **要质疑假设** - 包括用户的和您自己的
diff --git a/.opencode/skills/openspec-explore/SKILL.md b/.opencode/skills/openspec-explore/SKILL.md
new file mode 100644
index 0000000..147c7ef
--- /dev/null
+++ b/.opencode/skills/openspec-explore/SKILL.md
@@ -0,0 +1,290 @@
+---
+name: openspec-explore
+description: Enter explore mode - a thinking partner for exploring ideas, investigating problems, and clarifying requirements. Use when the user wants to think through something before or during a change.
+license: MIT
+compatibility: Requires openspec CLI.
+metadata:
+  author: openspec
+  version: "1.0"
+  generatedBy: "1.1.1"
+---
+
+Enter explore mode. Think deeply. Visualize freely. Follow the conversation wherever it goes.
+
+**IMPORTANT: Explore mode is for thinking, not implementing.** You may read files, search code, and investigate the codebase, but you must NEVER write code or implement features. If the user asks you to implement something, remind them to exit explore mode first (e.g., start a change with `/opsx-new` or `/opsx-ff`). You MAY create OpenSpec artifacts (proposals, designs, specs) if the user asks—that's capturing thinking, not implementing.
+
+**This is a stance, not a workflow.** There are no fixed steps, no required sequence, no mandatory outputs. You're a thinking partner helping the user explore.
+
+---
+
+## The Stance
+
+- **Curious, not prescriptive** - Ask questions that emerge naturally, don't follow a script
+- **Open threads, not interrogations** - Surface multiple interesting directions and let the user follow what resonates. Don't funnel them through a single path of questions.
+- **Visual** - Use ASCII diagrams liberally when they'd help clarify thinking
+- **Adaptive** - Follow interesting threads, pivot when new information emerges
+- **Patient** - Don't rush to conclusions, let the shape of the problem emerge
+- **Grounded** - Explore the actual codebase when relevant, don't just theorize
+
+---
+
+## What You Might Do
+
+Depending on what the user brings, you might:
+
+**Explore the problem space**
+- Ask clarifying questions that emerge from what they said
+- Challenge assumptions
+- Reframe the problem
+- Find analogies
+
+**Investigate the codebase**
+- Map existing architecture relevant to the discussion
+- Find integration points
+- Identify patterns already in use
+- Surface hidden complexity
+
+**Compare options**
+- Brainstorm multiple approaches
+- Build comparison tables
+- Sketch tradeoffs
+- Recommend a path (if asked)
+
+**Visualize**
+```
+┌─────────────────────────────────────────┐
+│     Use ASCII diagrams liberally        │
+├─────────────────────────────────────────┤
+│                                         │
+│   ┌────────┐         ┌────────┐        │
+│   │ State  │────────▶│ State  │        │
+│   │   A    │         │   B    │        │
+│   └────────┘         └────────┘        │
+│                                         │
+│   System diagrams, state machines,      │
+│   data flows, architecture sketches,    │
+│   dependency graphs, comparison tables  │
+│                                         │
+└─────────────────────────────────────────┘
+```
+
+**Surface risks and unknowns**
+- Identify what could go wrong
+- Find gaps in understanding
+- Suggest spikes or investigations
+
+---
+
+## OpenSpec Awareness
+
+You have full context of the OpenSpec system. Use it naturally, don't force it.
+
+### Check for context
+
+At the start, quickly check what exists:
+```bash
+openspec list --json
+```
+
+This tells you:
+- If there are active changes
+- Their names, schemas, and status
+- What the user might be working on
+
+### When no change exists
+
+Think freely. When insights crystallize, you might offer:
+
+- "This feels solid enough to start a change. Want me to create one?"
+  → Can transition to `/opsx-new` or `/opsx-ff`
+- Or keep exploring - no pressure to formalize
+
+### When a change exists
+
+If the user mentions a change or you detect one is relevant:
+
+1. **Read existing artifacts for context**
+   - `openspec/changes/<name>/proposal.md`
+   - `openspec/changes/<name>/design.md`
+   - `openspec/changes/<name>/tasks.md`
+   - etc.
+
+2. **Reference them naturally in conversation**
+   - "Your design mentions using Redis, but we just realized SQLite fits better..."
+   - "The proposal scopes this to premium users, but we're now thinking everyone..."
+
+3. **Offer to capture when decisions are made**
+
+   | Insight Type | Where to Capture |
+   |--------------|------------------|
+   | New requirement discovered | `specs/<capability>/spec.md` |
+   | Requirement changed | `specs/<capability>/spec.md` |
+   | Design decision made | `design.md` |
+   | Scope changed | `proposal.md` |
+   | New work identified | `tasks.md` |
+   | Assumption invalidated | Relevant artifact |
+
+   Example offers:
+   - "That's a design decision. Capture it in design.md?"
+   - "This is a new requirement. Add it to specs?"
+   - "This changes scope. Update the proposal?"
+
+4. **The user decides** - Offer and move on. Don't pressure. Don't auto-capture.
+
+---
+
+## What You Don't Have To Do
+
+- Follow a script
+- Ask the same questions every time
+- Produce a specific artifact
+- Reach a conclusion
+- Stay on topic if a tangent is valuable
+- Be brief (this is thinking time)
+
+---
+
+## Handling Different Entry Points
+
+**User brings a vague idea:**
+```
+User: I'm thinking about adding real-time collaboration
+
+You: Real-time collab is a big space. Let me think about this...
+
+      COLLABORATION SPECTRUM
+      ════════════════════════════════════════════
+
+      Awareness          Coordination         Sync
+          │                   │                 │
+          ▼                   ▼                 ▼
+      ┌────────┐         ┌────────┐        ┌────────┐
+      │Presence│         │Cursors │        │  CRDT  │
+      │  "3    │         │ Multi  │        │Conflict│
+      │online" │         │ select │        │  free  │
+      └────────┘         └────────┘        └────────┘
+          │                   │                 │
+       trivial            moderate           complex
+
+      Where's your head at?
+```
+
+**User brings a specific problem:**
+```
+User: The auth system is a mess
+
+You: [reads codebase]
+
+     ┌─────────────────────────────────────────────┐
+     │              CURRENT AUTH FLOW              │
+     └─────────────────────────────────────────────┘
+                        │
+          ┌─────────────┼─────────────┐
+          ▼             ▼             ▼
+     ┌─────────┐  ┌─────────┐  ┌─────────┐
+     │ Google  │  │  GitHub │  │  Email  │
+     │  OAuth  │  │  OAuth  │  │  Magic  │
+     └────┬────┘  └────┬────┘  └────┬────┘
+          │             │             │
+          └─────────────┼─────────────┘
+                        ▼
+                  ┌───────────┐
+                  │  Session  │
+                  └─────┬─────┘
+                        │
+                        ▼
+                  ┌───────────┐
+                  │   Perms   │
+                  └───────────┘
+
+     I see three tangles. Which one's burning?
+```
+
+**User is stuck mid-implementation:**
+```
+User: /opsx-explore add-auth-system
+      The OAuth integration is more complex than expected
+
+You: [reads change artifacts]
+
+     You're on task 4: "Implement OAuth flow"
+
+     Let me trace what's involved...
+
+     [draws diagram, explores options, suggests paths]
+
+     Want to update the design to reflect this?
+     Or add a spike task to investigate?
+```
+
+**User wants to compare options:**
+```
+User: Should we use Postgres or SQLite?
+
+You: Generic answer is boring. What's the context?
+
+User: A CLI tool that tracks local dev environments
+
+You: That changes everything.
+
+     ┌─────────────────────────────────────────────────┐
+     │         CLI TOOL DATA STORAGE                  │
+     └─────────────────────────────────────────────────┘
+
+     Key constraints:
+     • No daemon running
+     • Must work offline
+     • Single user
+
+                  SQLite          Postgres
+     Deployment   embedded ✓      needs server ✗
+     Offline      yes ✓           no ✗
+     Single file  yes ✓           no ✗
+
+     SQLite. Not even close.
+
+     Unless... is there a sync component?
+```
+
+---
+
+## Ending Discovery
+
+There's no required ending. Discovery might:
+
+- **Flow into action**: "Ready to start? /opsx-new or /opsx-ff"
+- **Result in artifact updates**: "Updated design.md with these decisions"
+- **Just provide clarity**: User has what they need, moves on
+- **Continue later**: "We can pick this up anytime"
+
+When it feels like things are crystallizing, you might summarize:
+
+```
+## What We Figured Out
+
+**The problem**: [crystallized understanding]
+
+**The approach**: [if one emerged]
+
+**Open questions**: [if any remain]
+
+**Next steps** (if ready):
+- Create a change: /opsx-new <name>
+- Fast-forward to tasks: /opsx-ff <name>
+- Keep exploring: just keep talking
+```
+
+But this summary is optional. Sometimes the thinking IS the value.
+
+---
+
+## Guardrails
+
+- **Don't implement** - Never write code or implement features. Creating OpenSpec artifacts is fine, writing application code is not.
+- **Don't fake understanding** - If something is unclear, dig deeper
+- **Don't rush** - Discovery is thinking time, not task time
+- **Don't force structure** - Let patterns emerge naturally
+- **Don't auto-capture** - Offer to save insights, don't just do it
+- **Do visualize** - A good diagram is worth many paragraphs
+- **Do explore the codebase** - Ground discussions in reality
+- **Do question assumptions** - Including the user's and your own
diff --git a/.opencode/skills/openspec-ff-change/SKILL.cn.md b/.opencode/skills/openspec-ff-change/SKILL.cn.md
new file mode 100644
index 0000000..9ce5824
--- /dev/null
+++ b/.opencode/skills/openspec-ff-change/SKILL.cn.md
@@ -0,0 +1,101 @@
+---
+name: openspec-ff-change
+description: Fast-forward through OpenSpec artifact creation. Use when the user wants to quickly create all artifacts needed for implementation without stepping through each one individually.
+license: MIT
+compatibility: Requires openspec CLI.
+metadata:
+  author: openspec
+  version: "1.0"
+  generatedBy: "1.1.1"
+---
+
+快速完成 artifact 创建 - 一次性生成开始实现所需的所有内容。
+
+**输入**: 用户的请求应该包含变更名称 (kebab-case) 或对他们想要构建的内容的描述。
+
+**步骤**
+
+1. **如果未提供明确输入,询问他们想要构建什么**
+
+   使用 **AskUserQuestion 工具** (开放式,无预设选项) 询问:
+   > "你想要处理什么变更?描述你想要构建或修复的内容。"
+
+   从他们的描述中,导出 kebab-case 名称 (例如: "add user authentication" → `add-user-auth`)。
+
+   **重要**: 不要在不了解用户想要构建什么的情况下继续。
+
+2. **创建变更目录**
+   ```bash
+   openspec new change "<name>"
+   ```
+   这将在 `openspec/changes/<name>/` 创建一个脚手架变更。
+
+3. **获取 artifact 构建顺序**
+   ```bash
+   openspec status --change "<name>" --json
+   ```
+   解析 JSON 以获取:
+   - `applyRequires`: 实现前需要的 artifact ID 数组 (例如: `["tasks"]`)
+   - `artifacts`: 所有 artifacts 的列表及其状态和依赖关系
+
+4. **按顺序创建 artifacts 直到准备好应用**
+
+   使用 **TodoWrite 工具**跟踪 artifacts 的进度。
+
+   按依赖顺序循环 artifacts (没有待处理依赖关系的 artifacts 优先):
+
+   a. **对于每个 `ready` 状态的 artifact (依赖关系已满足)**:
+      - 获取指令:
+        ```bash
+        openspec instructions <artifact-id> --change "<name>" --json
+        ```
+      - 指令 JSON 包括:
+        - `context`: 项目背景 (对你的约束 - 不要包含在输出中)
+        - `rules`: Artifact 特定规则 (对你的约束 - 不要包含在输出中)
+        - `template`: 用于输出文件的结构
+        - `instruction`: 此 artifact 类型的 schema 特定指导
+        - `outputPath`: artifact 写入位置
+        - `dependencies`: 要读取以获取上下文的已完成 artifacts
+      - 读取任何已完成的依赖文件以获取上下文
+      - 使用 `template` 作为结构创建 artifact 文件
+      - 将 `context` 和 `rules` 作为约束应用 - 但不要将它们复制到文件中
+      - 显示简短进度: "✓ 已创建 <artifact-id>"
+
+   b. **继续直到所有 `applyRequires` artifacts 完成**
+      - 创建每个 artifact 后,重新运行 `openspec status --change "<name>" --json`
+      - 检查 `applyRequires` 中的每个 artifact ID 在 artifacts 数组中的 `status: "done"`
+      - 当所有 `applyRequires` artifacts 都完成时停止
+
+   c. **如果 artifact 需要用户输入** (上下文不清楚):
+      - 使用 **AskUserQuestion 工具**澄清
+      - 然后继续创建
+
+5. **显示最终状态**
+   ```bash
+   openspec status --change "<name>"
+   ```
+
+**输出**
+
+完成所有 artifacts 后,总结:
+- 变更名称和位置
+- 创建的 artifacts 列表及简短描述
+- 准备就绪的内容: "所有 artifacts 已创建!准备实现。"
+- 提示: "运行 `/opsx-apply` 或要求我实现以开始处理任务。"
+
+**Artifact 创建指南**
+
+- 遵循每个 artifact 类型的 `openspec instructions` 中的 `instruction` 字段
+- Schema 定义了每个 artifact 应该包含什么 - 遵循它
+- 在创建新 artifacts 之前读取依赖 artifacts 以获取上下文
+- 使用 `template` 作为输出文件的结构 - 填充其部分
+- **重要**: `context` 和 `rules` 是对你的约束,而不是文件的内容
+  - 不要将 `<context>`, `<rules>`, `<project_context>` 块复制到 artifact 中
+  - 这些指导你写什么,但永远不应该出现在输出中
+
+**防护机制**
+- 创建实现所需的所有 artifacts (由 schema 的 `apply.requires` 定义)
+- 在创建新 artifact 之前始终读取依赖 artifacts
+- 如果上下文严重不清楚,询问用户 - 但更倾向于做出合理决策以保持势头
+- 如果已存在同名变更,建议继续该变更
+- 在继续下一个之前验证每个 artifact 文件是否存在
diff --git a/.opencode/skills/openspec-ff-change/SKILL.md b/.opencode/skills/openspec-ff-change/SKILL.md
new file mode 100644
index 0000000..519f356
--- /dev/null
+++ b/.opencode/skills/openspec-ff-change/SKILL.md
@@ -0,0 +1,101 @@
+---
+name: openspec-ff-change
+description: Fast-forward through OpenSpec artifact creation. Use when the user wants to quickly create all artifacts needed for implementation without stepping through each one individually.
+license: MIT
+compatibility: Requires openspec CLI.
+metadata:
+  author: openspec
+  version: "1.0"
+  generatedBy: "1.1.1"
+---
+
+Fast-forward through artifact creation - generate everything needed to start implementation in one go.
+
+**Input**: The user's request should include a change name (kebab-case) OR a description of what they want to build.
+
+**Steps**
+
+1. **If no clear input provided, ask what they want to build**
+
+   Use the **AskUserQuestion tool** (open-ended, no preset options) to ask:
+   > "What change do you want to work on? Describe what you want to build or fix."
+
+   From their description, derive a kebab-case name (e.g., "add user authentication" → `add-user-auth`).
+
+   **IMPORTANT**: Do NOT proceed without understanding what the user wants to build.
+
+2. **Create the change directory**
+   ```bash
+   openspec new change "<name>"
+   ```
+   This creates a scaffolded change at `openspec/changes/<name>/`.
+
+3. **Get the artifact build order**
+   ```bash
+   openspec status --change "<name>" --json
+   ```
+   Parse the JSON to get:
+   - `applyRequires`: array of artifact IDs needed before implementation (e.g., `["tasks"]`)
+   - `artifacts`: list of all artifacts with their status and dependencies
+
+4. **Create artifacts in sequence until apply-ready**
+
+   Use the **TodoWrite tool** to track progress through the artifacts.
+
+   Loop through artifacts in dependency order (artifacts with no pending dependencies first):
+
+   a. **For each artifact that is `ready` (dependencies satisfied)**:
+      - Get instructions:
+        ```bash
+        openspec instructions <artifact-id> --change "<name>" --json
+        ```
+      - The instructions JSON includes:
+        - `context`: Project background (constraints for you - do NOT include in output)
+        - `rules`: Artifact-specific rules (constraints for you - do NOT include in output)
+        - `template`: The structure to use for your output file
+        - `instruction`: Schema-specific guidance for this artifact type
+        - `outputPath`: Where to write the artifact
+        - `dependencies`: Completed artifacts to read for context
+      - Read any completed dependency files for context
+      - Create the artifact file using `template` as the structure
+      - Apply `context` and `rules` as constraints - but do NOT copy them into the file
+      - Show brief progress: "✓ Created <artifact-id>"
+
+   b. **Continue until all `applyRequires` artifacts are complete**
+      - After creating each artifact, re-run `openspec status --change "<name>" --json`
+      - Check if every artifact ID in `applyRequires` has `status: "done"` in the artifacts array
+      - Stop when all `applyRequires` artifacts are done
+
+   c. **If an artifact requires user input** (unclear context):
+      - Use **AskUserQuestion tool** to clarify
+      - Then continue with creation
+
+5. **Show final status**
+   ```bash
+   openspec status --change "<name>"
+   ```
+
+**Output**
+
+After completing all artifacts, summarize:
+- Change name and location
+- List of artifacts created with brief descriptions
+- What's ready: "All artifacts created! Ready for implementation."
+- Prompt: "Run `/opsx-apply` or ask me to implement to start working on the tasks."
+
+**Artifact Creation Guidelines**
+
+- Follow the `instruction` field from `openspec instructions` for each artifact type
+- The schema defines what each artifact should contain - follow it
+- Read dependency artifacts for context before creating new ones
+- Use `template` as the structure for your output file - fill in its sections
+- **IMPORTANT**: `context` and `rules` are constraints for YOU, not content for the file
+  - Do NOT copy `<context>`, `<rules>`, `<project_context>` blocks into the artifact
+  - These guide what you write, but should never appear in the output
+
+**Guardrails**
+- Create ALL artifacts needed for implementation (as defined by schema's `apply.requires`)
+- Always read dependency artifacts before creating a new one
+- If context is critically unclear, ask the user - but prefer making reasonable decisions to keep momentum
+- If a change with that name already exists, suggest continuing that change instead
+- Verify each artifact file exists after writing before proceeding to next
diff --git a/.opencode/skills/openspec-new-change/SKILL.cn.md b/.opencode/skills/openspec-new-change/SKILL.cn.md
new file mode 100644
index 0000000..8694294
--- /dev/null
+++ b/.opencode/skills/openspec-new-change/SKILL.cn.md
@@ -0,0 +1,74 @@
+---
+name: openspec-new-change
+description: Start a new OpenSpec change using the experimental artifact workflow. Use when the user wants to create a new feature, fix, or modification with a structured step-by-step approach.
+license: MIT
+compatibility: Requires openspec CLI.
+metadata:
+  author: openspec
+  version: "1.0"
+  generatedBy: "1.1.1"
+---
+
+使用实验性 artifact 驱动方法开始新变更。
+
+**输入**：用户的请求应包含变更名称(kebab-case)或他们想要构建的内容的描述。
+
+**步骤**
+
+1. **如果未提供明确输入,询问他们想要构建什么**
+
+   使用 **AskUserQuestion 工具**(开放式,无预设选项)询问:
+   > "您想处理什么变更? 描述您想要构建或修复的内容。"
+
+   从他们的描述中,派生一个 kebab-case 名称(例如 "add user authentication" → `add-user-auth`)。
+
+   **重要**: 在不了解用户想要构建什么之前,不要继续。
+
+2. **确定工作流 schema**
+
+   使用默认 schema(省略 `--schema`),除非用户明确请求不同的工作流。
+
+   **仅在用户提到时使用不同的 schema:**
+   - 特定 schema 名称 → 使用 `--schema <name>`
+   - "显示工作流"或"有哪些工作流" → 运行 `openspec schemas --json` 并让他们选择
+
+   **否则**: 省略 `--schema` 以使用默认值。
+
+3. **创建变更目录**
+   ```bash
+   openspec new change "<name>"
+   ```
+   仅当用户请求特定工作流时才添加 `--schema <name>`。
+   这将在 `openspec/changes/<name>/` 创建一个使用所选 schema 的脚手架变更。
+
+4. **显示 artifact 状态**
+   ```bash
+   openspec status --change "<name>"
+   ```
+   这显示需要创建哪些 artifacts 以及哪些已准备好(依赖关系已满足)。
+
+5. **获取第一个 artifact 的说明**
+   第一个 artifact 取决于 schema(例如 spec-driven 的 `proposal`)。
+   检查状态输出以找到第一个状态为 "ready" 的 artifact。
+   ```bash
+   openspec instructions <first-artifact-id> --change "<name>"
+   ```
+   这将输出创建第一个 artifact 的模板和上下文。
+
+6. **停止并等待用户指示**
+
+**输出**
+
+完成步骤后,总结:
+- 变更名称和位置
+- 正在使用的 Schema/工作流及其 artifact 序列
+- 当前状态(已完成 0/N 个 artifacts)
+- 第一个 artifact 的模板
+- 提示: "准备创建第一个 artifact 了吗? 只需描述此变更的内容,我会起草它,或者让我继续。"
+
+**护栏**
+- 还不要创建任何 artifacts - 只显示说明
+- 不要超越显示第一个 artifact 模板
+- 如果名称无效(不是 kebab-case),请求一个有效名称
+- 如果该名称的变更已存在,建议继续该变更
+- 如果使用非默认工作流,传递 --schema
diff --git a/.opencode/skills/openspec-new-change/SKILL.md b/.opencode/skills/openspec-new-change/SKILL.md
new file mode 100644
index 0000000..37ac7ba
--- /dev/null
+++ b/.opencode/skills/openspec-new-change/SKILL.md
@@ -0,0 +1,74 @@
+---
+name: openspec-new-change
+description: Start a new OpenSpec change using the experimental artifact workflow. Use when the user wants to create a new feature, fix, or modification with a structured step-by-step approach.
+license: MIT
+compatibility: Requires openspec CLI.
+metadata:
+  author: openspec
+  version: "1.0"
+  generatedBy: "1.1.1"
+---
+
+Start a new change using the experimental artifact-driven approach.
+
+**Input**: The user's request should include a change name (kebab-case) OR a description of what they want to build.
+
+**Steps**
+
+1. **If no clear input provided, ask what they want to build**
+
+   Use the **AskUserQuestion tool** (open-ended, no preset options) to ask:
+   > "What change do you want to work on? Describe what you want to build or fix."
+
+   From their description, derive a kebab-case name (e.g., "add user authentication" → `add-user-auth`).
+
+   **IMPORTANT**: Do NOT proceed without understanding what the user wants to build.
+
+2. **Determine the workflow schema**
+
+   Use the default schema (omit `--schema`) unless the user explicitly requests a different workflow.
+
+   **Use a different schema only if the user mentions:**
+   - A specific schema name → use `--schema <name>`
+   - "show workflows" or "what workflows" → run `openspec schemas --json` and let them choose
+
+   **Otherwise**: Omit `--schema` to use the default.
+
+3. **Create the change directory**
+   ```bash
+   openspec new change "<name>"
+   ```
+   Add `--schema <name>` only if the user requested a specific workflow.
+   This creates a scaffolded change at `openspec/changes/<name>/` with the selected schema.
+
+4. **Show the artifact status**
+   ```bash
+   openspec status --change "<name>"
+   ```
+   This shows which artifacts need to be created and which are ready (dependencies satisfied).
+
+5. **Get instructions for the first artifact**
+   The first artifact depends on the schema (e.g., `proposal` for spec-driven).
+   Check the status output to find the first artifact with status "ready".
+   ```bash
+   openspec instructions <first-artifact-id> --change "<name>"
+   ```
+   This outputs the template and context for creating the first artifact.
+
+6. **STOP and wait for user direction**
+
+**Output**
+
+After completing the steps, summarize:
+- Change name and location
+- Schema/workflow being used and its artifact sequence
+- Current status (0/N artifacts complete)
+- The template for the first artifact
+- Prompt: "Ready to create the first artifact? Just describe what this change is about and I'll draft it, or ask me to continue."
+
+**Guardrails**
+- Do NOT create any artifacts yet - just show the instructions
+- Do NOT advance beyond showing the first artifact template
+- If the name is invalid (not kebab-case), ask for a valid name
+- If a change with that name already exists, suggest continuing that change instead
+- Pass --schema if using a non-default workflow
diff --git a/.opencode/skills/openspec-onboard/SKILL.cn.md b/.opencode/skills/openspec-onboard/SKILL.cn.md
new file mode 100644
index 0000000..740c85a
--- /dev/null
+++ b/.opencode/skills/openspec-onboard/SKILL.cn.md
@@ -0,0 +1,529 @@
+---
+name: openspec-onboard
+description: OpenSpec 引导式入门教程 - 通过真实代码库工作完整演示工作流程
+license: MIT
+compatibility: 需要 openspec CLI。
+metadata:
+  author: openspec
+  version: "1.0"
+  generatedBy: "1.1.1"
+---
+
+引导用户完成他们的第一个完整 OpenSpec 工作流程周期。这是一次教学体验——你将在他们的代码库中做真实的工作,同时解释每个步骤。
+
+---
+
+## 准备检查
+
+在开始之前,检查 OpenSpec 是否已初始化:
+
+```bash
+openspec status --json 2>&1 || echo "NOT_INITIALIZED"
+```
+
+**如果未初始化:**
+> OpenSpec 还未在此项目中设置。请先运行 `openspec init`,然后再回到 `/opsx-onboard`。
+
+如果未初始化,在这里停止。
+
+---
+
+## 阶段 1: 欢迎
+
+显示:
+
+```
+## 欢迎使用 OpenSpec!
+
+我将带你完成一个完整的变更周期——从想法到实现——使用代码库中的真实任务。在此过程中,你将通过实践来学习工作流程。
+
+**我们将做什么:**
+1. 在你的代码库中选择一个小的真实任务
+2. 简要探索问题
+3. 创建一个变更(我们工作的容器)
+4. 构建工件: proposal → specs → design → tasks
+5. 实现任务
+6. 归档完成的变更
+
+**时间:** ~15-20 分钟
+
+让我们从找到要做的事情开始。
+```
+
+---
+
+## 阶段 2: 任务选择
+
+### 代码库分析
+
+扫描代码库寻找小的改进机会。查找:
+
+1. **TODO/FIXME 注释** - 在代码文件中搜索 `TODO`, `FIXME`, `HACK`, `XXX`
+2. **缺失的错误处理** - 吞噬错误的 `catch` 块,没有 try-catch 的风险操作
+3. **缺少测试的函数** - 将 `src/` 与测试目录交叉引用
+4. **类型问题** - TypeScript 文件中的 `any` 类型(`: any`, `as any`)
+5. **调试残留** - 非调试代码中的 `console.log`, `console.debug`, `debugger` 语句
+6. **缺失的验证** - 没有验证的用户输入处理器
+
+还检查最近的 git 活动:
+```bash
+git log --oneline -10 2>/dev/null || echo "No git history"
+```
+
+### 呈现建议
+
+根据你的分析,呈现 3-4 个具体建议:
+
+```
+## 任务建议
+
+基于扫描你的代码库,这里有一些不错的入门任务:
+
+**1. [最有希望的任务]**
+   位置: `src/path/to/file.ts:42`
+   范围: ~1-2 个文件, ~20-30 行
+   为什么适合: [简短原因]
+
+**2. [第二个任务]**
+   位置: `src/another/file.ts`
+   范围: ~1 个文件, ~15 行
+   为什么适合: [简短原因]
+
+**3. [第三个任务]**
+   位置: [位置]
+   范围: [估计]
+   为什么适合: [简短原因]
+
+**4. 其他?**
+   告诉我你想做什么。
+
+你对哪个任务感兴趣? (选择一个数字或描述你自己的)
+```
+
+**如果没找到:** 退而询问用户想构建什么:
+> 我在你的代码库中没找到明显的快速改进。有什么小事情是你一直想添加或修复的吗?
+
+### 范围守护
+
+如果用户选择或描述的东西太大(主要功能,多天的工作):
+
+```
+这是一个有价值的任务,但对于你第一次运行 OpenSpec 可能比理想的要大。
+
+对于学习工作流程,越小越好——它让你看到完整的周期而不会陷入实现细节。
+
+**选项:**
+1. **切得更小** - [他们的任务]最小的有用部分是什么? 也许只是[具体切片]?
+2. **选择其他** - 其他建议之一,或不同的小任务?
+3. **照做** - 如果你真的想处理这个,我们可以。只是知道会花更长时间。
+
+你更喜欢什么?
+```
+
+如果他们坚持,让用户覆盖——这是一个软守护。
+
+---
+
+## 阶段 3: 探索演示
+
+一旦选择了任务,简要演示探索模式:
+
+```
+在创建变更之前,让我快速展示**探索模式**——这是你在承诺方向之前思考问题的方式。
+```
+
+花 1-2 分钟调查相关代码:
+- 读取涉及的文件
+- 如果有帮助,画一个快速的 ASCII 图
+- 注意任何考虑因素
+
+```
+## 快速探索
+
+[你的简要分析——你发现了什么,任何考虑因素]
+
+┌─────────────────────────────────────────┐
+│   [可选: 如果有帮助的 ASCII 图]        │
+└─────────────────────────────────────────┘
+
+探索模式 (`/opsx-explore`) 就是用于这种思考——在实现之前进行调查。你可以在需要思考问题时随时使用它。
+
+现在让我们创建一个变更来保存我们的工作。
+```
+
+**暂停** - 等待用户确认后再继续。
+
+---
+
+## 阶段 4: 创建变更
+
+**解释:**
+```
+## 创建变更
+
+在 OpenSpec 中,"变更"是围绕一项工作的所有思考和规划的容器。它位于 `openspec/changes/<name>/` 中,包含你的工件——proposal、specs、design、tasks。
+
+让我为我们的任务创建一个。
+```
+
+**执行:** 使用派生的 kebab-case 名称创建变更:
+```bash
+openspec new change "<derived-name>"
+```
+
+**显示:**
+```
+创建: `openspec/changes/<name>/`
+
+文件夹结构:
+```
+openspec/changes/<name>/
+├── proposal.md    ← 我们为什么这样做(空的,我们会填充)
+├── design.md      ← 我们如何构建它(空的)
+├── specs/         ← 详细需求(空的)
+└── tasks.md       ← 实现检查清单(空的)
+```
+
+现在让我们填充第一个工件——proposal。
+```
+
+---
+
+## 阶段 5: Proposal
+
+**解释:**
+```
+## Proposal
+
+proposal 捕获我们为什么进行这个变更以及高层次的内容。这是工作的"电梯演讲"。
+
+我将根据我们的任务起草一个。
+```
+
+**执行:** 起草 proposal 内容(还不要保存):
+
+```
+这是一个草案 proposal:
+
+---
+
+## 为什么 (Why)
+
+[1-2 句话解释问题/机会]
+
+## 变更内容 (What Changes)
+
+[将会有什么不同的要点]
+
+## 能力 (Capabilities)
+
+### 新能力
+- `<capability-name>`: [简要描述]
+
+### 修改的能力
+<!-- 如果修改现有行为 -->
+
+## 影响 (Impact)
+
+- `src/path/to/file.ts`: [什么变更]
+- [其他适用的文件]
+
+---
+
+这是否捕获了意图? 我可以在保存前调整。
+```
+
+**暂停** - 等待用户批准/反馈。
+
+批准后,保存 proposal:
+```bash
+openspec instructions proposal --change "<name>" --json
+```
+然后将内容写入 `openspec/changes/<name>/proposal.md`。
+
+```
+Proposal 已保存。这是你的"为什么"文档——随着理解的演变,你总是可以回来完善它。
+
+接下来: specs。
+```
+
+---
+
+## 阶段 6: Specs
+
+**解释:**
+```
+## Specs
+
+Specs 以精确、可测试的术语定义我们正在构建什么。它们使用需求/场景格式,使预期行为非常清晰。
+
+对于像这样的小任务,我们可能只需要一个 spec 文件。
+```
+
+**执行:** 创建 spec 文件:
+```bash
+mkdir -p openspec/changes/<name>/specs/<capability-name>
+```
+
+起草 spec 内容:
+
+```
+这是 spec:
+
+---
+
+## ADDED Requirements
+
+### Requirement: <名称>
+
+<系统应该做什么的描述>
+
+#### Scenario: <场景名称>
+
+- **WHEN** <触发条件>
+- **THEN** <预期结果>
+- **AND** <如需要的额外结果>
+
+---
+
+这种格式——WHEN/THEN/AND——使需求可测试。你可以直接将它们作为测试用例来读。
+```
+
+保存到 `openspec/changes/<name>/specs/<capability>/spec.md`。
+
+---
+
+## 阶段 7: Design
+
+**解释:**
+```
+## Design
+
+design 捕获我们如何构建它——技术决策、权衡、方法。
+
+对于小变更,这可能很简短。这没关系——不是每个变更都需要深度设计讨论。
+```
+
+**执行:** 起草 design.md:
+
+```
+这是 design:
+
+---
+
+## 上下文 (Context)
+
+[关于当前状态的简要上下文]
+
+## 目标 / 非目标 (Goals / Non-Goals)
+
+**目标:**
+- [我们试图实现什么]
+
+**非目标:**
+- [明确超出范围的内容]
+
+## 决策 (Decisions)
+
+### Decision 1: [关键决策]
+
+[方法和理由的解释]
+
+---
+
+对于小任务,这捕获了关键决策而不会过度设计。
+```
+
+保存到 `openspec/changes/<name>/design.md`。
+
+---
+
+## 阶段 8: Tasks
+
+**解释:**
+```
+## Tasks
+
+最后,我们将工作分解为实现任务——驱动应用阶段的复选框。
+
+这些应该小、清晰且按逻辑顺序排列。
+```
+
+**执行:** 基于 specs 和 design 生成任务:
+
+```
+这是实现任务:
+
+---
+
+## 1. [类别或文件]
+
+- [ ] 1.1 [具体任务]
+- [ ] 1.2 [具体任务]
+
+## 2. 验证 (Verify)
+
+- [ ] 2.1 [验证步骤]
+
+---
+
+每个复选框在应用阶段成为一个工作单元。准备好实现了吗?
+```
+
+**暂停** - 等待用户确认他们准备好实现。
+
+保存到 `openspec/changes/<name>/tasks.md`。
+
+---
+
+## 阶段 9: Apply (实现)
+
+**解释:**
+```
+## 实现 (Implementation)
+
+现在我们实现每个任务,在进行时勾选它们。我会宣布每一个,偶尔注意 specs/design 如何指导方法。
+```
+
+**执行:** 对于每个任务:
+
+1. 宣布: "正在处理任务 N: [描述]"
+2. 在代码库中进行所需的更改
+3. 自然地引用 specs/design: "spec 说 X,所以我做 Y"
+4. 在 tasks.md 中标记完成: `- [ ]` → `- [x]`
+5. 简要状态: "✓ 任务 N 完成"
+
+保持叙述轻量——不要过度解释每行代码。
+
+所有任务完成后:
+
+```
+## 实现完成
+
+所有任务完成:
+- [x] Task 1
+- [x] Task 2
+- [x] ...
+
+变更已实现! 还有一步——让我们归档它。
+```
+
+---
+
+## 阶段 10: Archive
+
+**解释:**
+```
+## 归档 (Archiving)
+
+当变更完成时,我们归档它。这将它从 `openspec/changes/` 移动到 `openspec/changes/archive/YYYY-MM-DD-<name>/`。
+
+归档的变更成为你项目的决策历史——你总是可以在以后找到它们,以了解为什么某些东西是以某种方式构建的。
+```
+
+**执行:**
+```bash
+openspec archive "<name>"
+```
+
+**显示:**
+```
+归档到: `openspec/changes/archive/YYYY-MM-DD-<name>/`
+
+变更现在是你项目历史的一部分。代码在你的代码库中,决策记录被保存。
+```
+
+---
+
+## 阶段 11: 回顾与下一步
+
+```
+## 恭喜!
+
+你刚刚完成了一个完整的 OpenSpec 周期:
+
+1. **Explore** - 思考问题
+2. **New** - 创建变更容器
+3. **Proposal** - 捕获为什么 (WHY)
+4. **Specs** - 详细定义什么 (WHAT)
+5. **Design** - 决定如何 (HOW)
+6. **Tasks** - 分解为步骤
+7. **Apply** - 实现工作
+8. **Archive** - 保存记录
+
+这个相同的节奏适用于任何规模的变更——无论是小修复还是主要功能。
+
+---
+
+## 命令参考
+
+| 命令 | 功能 |
+|---------|--------------|
+| `/opsx-explore` | 在工作前/期间思考问题 |
+| `/opsx-new` | 启动新变更,逐步完成工件 |
+| `/opsx-ff` | 快进: 一次创建所有工件 |
+| `/opsx-continue` | 继续现有变更的工作 |
+| `/opsx-apply` | 实现变更中的任务 |
+| `/opsx-verify` | 验证实现与工件匹配 |
+| `/opsx-archive` | 归档完成的变更 |
+
+---
+
+## 下一步是什么?
+
+在你真正想构建的东西上尝试 `/opsx-new` 或 `/opsx-ff`。你现在已经掌握了节奏!
+```
+
+---
+
+## 优雅退出处理
+
+### 用户想中途停止
+
+如果用户说他们需要停止、想暂停或看起来不再参与:
+
+```
+没问题! 你的变更保存在 `openspec/changes/<name>/`。
+
+要在以后从我们离开的地方继续:
+- `/opsx-continue <name>` - 恢复工件创建
+- `/opsx-apply <name>` - 跳转到实现(如果任务存在)
+
+工作不会丢失。准备好时随时回来。
+```
+
+优雅退出,不施加压力。
+
+### 用户只想要命令参考
+
+如果用户说他们只想看命令或跳过教程:
+
+```
+## OpenSpec 快速参考
+
+| 命令 | 功能 |
+|---------|--------------|
+| `/opsx-explore` | 思考问题(不改代码) |
+| `/opsx-new <name>` | 启动新变更,逐步进行 |
+| `/opsx-ff <name>` | 快进: 一次所有工件 |
+| `/opsx-continue <name>` | 继续现有变更 |
+| `/opsx-apply <name>` | 实现任务 |
+| `/opsx-verify <name>` | 验证实现 |
+| `/opsx-archive <name>` | 完成时归档 |
+
+试试 `/opsx-new` 来开始你的第一个变更,或者如果你想快速移动就用 `/opsx-ff`。
+```
+
+优雅退出。
+
+---
+
+## 守护
+
+- **遵循 EXPLAIN → DO → SHOW → PAUSE 模式** 在关键转换点(探索后、proposal 草案后、任务后、归档后)
+- **保持叙述轻量** 在实现期间——教学但不说教
+- **不要跳过阶段** 即使变更很小——目标是教学工作流程
+- **在标记的点暂停等待确认**,但不要过度暂停
+- **优雅处理退出**——永远不要强迫用户继续
+- **使用真实代码库任务**——不要模拟或使用假例子
+- **温和地调整范围**——引导向更小的任务但尊重用户选择
diff --git a/.opencode/skills/openspec-onboard/SKILL.md b/.opencode/skills/openspec-onboard/SKILL.md
new file mode 100644
index 0000000..8ee6cdc
--- /dev/null
+++ b/.opencode/skills/openspec-onboard/SKILL.md
@@ -0,0 +1,529 @@
+---
+name: openspec-onboard
+description: Guided onboarding for OpenSpec - walk through a complete workflow cycle with narration and real codebase work.
+license: MIT
+compatibility: Requires openspec CLI.
+metadata:
+  author: openspec
+  version: "1.0"
+  generatedBy: "1.1.1"
+---
+
+Guide the user through their first complete OpenSpec workflow cycle. This is a teaching experience—you'll do real work in their codebase while explaining each step.
+
+---
+
+## Preflight
+
+Before starting, check if OpenSpec is initialized:
+
+```bash
+openspec status --json 2>&1 || echo "NOT_INITIALIZED"
+```
+
+**If not initialized:**
+> OpenSpec isn't set up in this project yet. Run `openspec init` first, then come back to `/opsx-onboard`.
+
+Stop here if not initialized.
+
+---
+
+## Phase 1: Welcome
+
+Display:
+
+```
+## Welcome to OpenSpec!
+
+I'll walk you through a complete change cycle—from idea to implementation—using a real task in your codebase. Along the way, you'll learn the workflow by doing it.
+
+**What we'll do:**
+1. Pick a small, real task in your codebase
+2. Explore the problem briefly
+3. Create a change (the container for our work)
+4. Build the artifacts: proposal → specs → design → tasks
+5. Implement the tasks
+6. Archive the completed change
+
+**Time:** ~15-20 minutes
+
+Let's start by finding something to work on.
+```
+
+---
+
+## Phase 2: Task Selection
+
+### Codebase Analysis
+
+Scan the codebase for small improvement opportunities. Look for:
+
+1. **TODO/FIXME comments** - Search for `TODO`, `FIXME`, `HACK`, `XXX` in code files
+2. **Missing error handling** - `catch` blocks that swallow errors, risky operations without try-catch
+3. **Functions without tests** - Cross-reference `src/` with test directories
+4. **Type issues** - `any` types in TypeScript files (`: any`, `as any`)
+5. **Debug artifacts** - `console.log`, `console.debug`, `debugger` statements in non-debug code
+6. **Missing validation** - User input handlers without validation
+
+Also check recent git activity:
+```bash
+git log --oneline -10 2>/dev/null || echo "No git history"
+```
+
+### Present Suggestions
+
+From your analysis, present 3-4 specific suggestions:
+
+```
+## Task Suggestions
+
+Based on scanning your codebase, here are some good starter tasks:
+
+**1. [Most promising task]**
+   Location: `src/path/to/file.ts:42`
+   Scope: ~1-2 files, ~20-30 lines
+   Why it's good: [brief reason]
+
+**2. [Second task]**
+   Location: `src/another/file.ts`
+   Scope: ~1 file, ~15 lines
+   Why it's good: [brief reason]
+
+**3. [Third task]**
+   Location: [location]
+   Scope: [estimate]
+   Why it's good: [brief reason]
+
+**4. Something else?**
+   Tell me what you'd like to work on.
+
+Which task interests you? (Pick a number or describe your own)
+```
+
+**If nothing found:** Fall back to asking what the user wants to build:
+> I didn't find obvious quick wins in your codebase. What's something small you've been meaning to add or fix?
+
+### Scope Guardrail
+
+If the user picks or describes something too large (major feature, multi-day work):
+
+```
+That's a valuable task, but it's probably larger than ideal for your first OpenSpec run-through.
+
+For learning the workflow, smaller is better—it lets you see the full cycle without getting stuck in implementation details.
+
+**Options:**
+1. **Slice it smaller** - What's the smallest useful piece of [their task]? Maybe just [specific slice]?
+2. **Pick something else** - One of the other suggestions, or a different small task?
+3. **Do it anyway** - If you really want to tackle this, we can. Just know it'll take longer.
+
+What would you prefer?
+```
+
+Let the user override if they insist—this is a soft guardrail.
+
+---
+
+## Phase 3: Explore Demo
+
+Once a task is selected, briefly demonstrate explore mode:
+
+```
+Before we create a change, let me quickly show you **explore mode**—it's how you think through problems before committing to a direction.
+```
+
+Spend 1-2 minutes investigating the relevant code:
+- Read the file(s) involved
+- Draw a quick ASCII diagram if it helps
+- Note any considerations
+
+```
+## Quick Exploration
+
+[Your brief analysis—what you found, any considerations]
+
+┌─────────────────────────────────────────┐
+│   [Optional: ASCII diagram if helpful]  │
+└─────────────────────────────────────────┘
+
+Explore mode (`/opsx-explore`) is for this kind of thinking—investigating before implementing. You can use it anytime you need to think through a problem.
+
+Now let's create a change to hold our work.
+```
+
+**PAUSE** - Wait for user acknowledgment before proceeding.
+
+---
+
+## Phase 4: Create the Change
+
+**EXPLAIN:**
+```
+## Creating a Change
+
+A "change" in OpenSpec is a container for all the thinking and planning around a piece of work. It lives in `openspec/changes/<name>/` and holds your artifacts—proposal, specs, design, tasks.
+
+Let me create one for our task.
+```
+
+**DO:** Create the change with a derived kebab-case name:
+```bash
+openspec new change "<derived-name>"
+```
+
+**SHOW:**
+```
+Created: `openspec/changes/<name>/`
+
+The folder structure:
+```
+openspec/changes/<name>/
+├── proposal.md    ← Why we're doing this (empty, we'll fill it)
+├── design.md      ← How we'll build it (empty)
+├── specs/         ← Detailed requirements (empty)
+└── tasks.md       ← Implementation checklist (empty)
+```
+
+Now let's fill in the first artifact—the proposal.
+```
+
+---
+
+## Phase 5: Proposal
+
+**EXPLAIN:**
+```
+## The Proposal
+
+The proposal captures **why** we're making this change and **what** it involves at a high level. It's the "elevator pitch" for the work.
+
+I'll draft one based on our task.
+```
+
+**DO:** Draft the proposal content (don't save yet):
+
+```
+Here's a draft proposal:
+
+---
+
+## Why
+
+[1-2 sentences explaining the problem/opportunity]
+
+## What Changes
+
+[Bullet points of what will be different]
+
+## Capabilities
+
+### New Capabilities
+- `<capability-name>`: [brief description]
+
+### Modified Capabilities
+<!-- If modifying existing behavior -->
+
+## Impact
+
+- `src/path/to/file.ts`: [what changes]
+- [other files if applicable]
+
+---
+
+Does this capture the intent? I can adjust before we save it.
+```
+
+**PAUSE** - Wait for user approval/feedback.
+
+After approval, save the proposal:
+```bash
+openspec instructions proposal --change "<name>" --json
+```
+Then write the content to `openspec/changes/<name>/proposal.md`.
+
+```
+Proposal saved. This is your "why" document—you can always come back and refine it as understanding evolves.
+
+Next up: specs.
+```
+
+---
+
+## Phase 6: Specs
+
+**EXPLAIN:**
+```
+## Specs
+
+Specs define **what** we're building in precise, testable terms. They use a requirement/scenario format that makes expected behavior crystal clear.
+
+For a small task like this, we might only need one spec file.
+```
+
+**DO:** Create the spec file:
+```bash
+mkdir -p openspec/changes/<name>/specs/<capability-name>
+```
+
+Draft the spec content:
+
+```
+Here's the spec:
+
+---
+
+## ADDED Requirements
+
+### Requirement: <Name>
+
+<Description of what the system should do>
+
+#### Scenario: <Scenario name>
+
+- **WHEN** <trigger condition>
+- **THEN** <expected outcome>
+- **AND** <additional outcome if needed>
+
+---
+
+This format—WHEN/THEN/AND—makes requirements testable. You can literally read them as test cases.
+```
+
+Save to `openspec/changes/<name>/specs/<capability>/spec.md`.
+
+---
+
+## Phase 7: Design
+
+**EXPLAIN:**
+```
+## Design
+
+The design captures **how** we'll build it—technical decisions, tradeoffs, approach.
+
+For small changes, this might be brief. That's fine—not every change needs deep design discussion.
+```
+
+**DO:** Draft design.md:
+
+```
+Here's the design:
+
+---
+
+## Context
+
+[Brief context about the current state]
+
+## Goals / Non-Goals
+
+**Goals:**
+- [What we're trying to achieve]
+
+**Non-Goals:**
+- [What's explicitly out of scope]
+
+## Decisions
+
+### Decision 1: [Key decision]
+
+[Explanation of approach and rationale]
+
+---
+
+For a small task, this captures the key decisions without over-engineering.
+```
+
+Save to `openspec/changes/<name>/design.md`.
+
+---
+
+## Phase 8: Tasks
+
+**EXPLAIN:**
+```
+## Tasks
+
+Finally, we break the work into implementation tasks—checkboxes that drive the apply phase.
+
+These should be small, clear, and in logical order.
+```
+
+**DO:** Generate tasks based on specs and design:
+
+```
+Here are the implementation tasks:
+
+---
+
+## 1. [Category or file]
+
+- [ ] 1.1 [Specific task]
+- [ ] 1.2 [Specific task]
+
+## 2. Verify
+
+- [ ] 2.1 [Verification step]
+
+---
+
+Each checkbox becomes a unit of work in the apply phase. Ready to implement?
+```
+
+**PAUSE** - Wait for user to confirm they're ready to implement.
+
+Save to `openspec/changes/<name>/tasks.md`.
+
+---
+
+## Phase 9: Apply (Implementation)
+
+**EXPLAIN:**
+```
+## Implementation
+
+Now we implement each task, checking them off as we go. I'll announce each one and occasionally note how the specs/design informed the approach.
+```
+
+**DO:** For each task:
+
+1. Announce: "Working on task N: [description]"
+2. Implement the change in the codebase
+3. Reference specs/design naturally: "The spec says X, so I'm doing Y"
+4. Mark complete in tasks.md: `- [ ]` → `- [x]`
+5. Brief status: "✓ Task N complete"
+
+Keep narration light—don't over-explain every line of code.
+
+After all tasks:
+
+```
+## Implementation Complete
+
+All tasks done:
+- [x] Task 1
+- [x] Task 2
+- [x] ...
+
+The change is implemented! One more step—let's archive it.
+```
+
+---
+
+## Phase 10: Archive
+
+**EXPLAIN:**
+```
+## Archiving
+
+When a change is complete, we archive it. This moves it from `openspec/changes/` to `openspec/changes/archive/YYYY-MM-DD-<name>/`.
+
+Archived changes become your project's decision history—you can always find them later to understand why something was built a certain way.
+```
+
+**DO:**
+```bash
+openspec archive "<name>"
+```
+
+**SHOW:**
+```
+Archived to: `openspec/changes/archive/YYYY-MM-DD-<name>/`
+
+The change is now part of your project's history. The code is in your codebase, the decision record is preserved.
+```
+
+---
+
+## Phase 11: Recap & Next Steps
+
+```
+## Congratulations!
+
+You just completed a full OpenSpec cycle:
+
+1. **Explore** - Thought through the problem
+2. **New** - Created a change container
+3. **Proposal** - Captured WHY
+4. **Specs** - Defined WHAT in detail
+5. **Design** - Decided HOW
+6. **Tasks** - Broke it into steps
+7. **Apply** - Implemented the work
+8. **Archive** - Preserved the record
+
+This same rhythm works for any size change—a small fix or a major feature.
+
+---
+
+## Command Reference
+
+| Command | What it does |
+|---------|--------------|
+| `/opsx-explore` | Think through problems before/during work |
+| `/opsx-new` | Start a new change, step through artifacts |
+| `/opsx-ff` | Fast-forward: create all artifacts at once |
+| `/opsx-continue` | Continue working on an existing change |
+| `/opsx-apply` | Implement tasks from a change |
+| `/opsx-verify` | Verify implementation matches artifacts |
+| `/opsx-archive` | Archive a completed change |
+
+---
+
+## What's Next?
+
+Try `/opsx-new` or `/opsx-ff` on something you actually want to build. You've got the rhythm now!
+```
+
+---
+
+## Graceful Exit Handling
+
+### User wants to stop mid-way
+
+If the user says they need to stop, want to pause, or seem disengaged:
+
+```
+No problem! Your change is saved at `openspec/changes/<name>/`.
+
+To pick up where we left off later:
+- `/opsx-continue <name>` - Resume artifact creation
+- `/opsx-apply <name>` - Jump to implementation (if tasks exist)
+
+The work won't be lost. Come back whenever you're ready.
+```
+
+Exit gracefully without pressure.
+
+### User just wants command reference
+
+If the user says they just want to see the commands or skip the tutorial:
+
+```
+## OpenSpec Quick Reference
+
+| Command | What it does |
+|---------|--------------|
+| `/opsx-explore` | Think through problems (no code changes) |
+| `/opsx-new <name>` | Start a new change, step by step |
+| `/opsx-ff <name>` | Fast-forward: all artifacts at once |
+| `/opsx-continue <name>` | Continue an existing change |
+| `/opsx-apply <name>` | Implement tasks |
+| `/opsx-verify <name>` | Verify implementation |
+| `/opsx-archive <name>` | Archive when done |
+
+Try `/opsx-new` to start your first change, or `/opsx-ff` if you want to move fast.
+```
+
+Exit gracefully.
+
+---
+
+## Guardrails
+
+- **Follow the EXPLAIN → DO → SHOW → PAUSE pattern** at key transitions (after explore, after proposal draft, after tasks, after archive)
+- **Keep narration light** during implementation—teach without lecturing
+- **Don't skip phases** even if the change is small—the goal is teaching the workflow
+- **Pause for acknowledgment** at marked points, but don't over-pause
+- **Handle exits gracefully**—never pressure the user to continue
+- **Use real codebase tasks**—don't simulate or use fake examples
+- **Adjust scope gently**—guide toward smaller tasks but respect user choice
diff --git a/.opencode/skills/openspec-sync-specs/SKILL.cn.md b/.opencode/skills/openspec-sync-specs/SKILL.cn.md
new file mode 100644
index 0000000..502eaaf
--- /dev/null
+++ b/.opencode/skills/openspec-sync-specs/SKILL.cn.md
@@ -0,0 +1,138 @@
+---
+name: openspec-sync-specs
+description: Sync delta specs from a change to main specs. Use when the user wants to update main specs with changes from a delta spec, without archiving the change.
+license: MIT
+compatibility: Requires openspec CLI.
+metadata:
+  author: openspec
+  version: "1.0"
+  generatedBy: "1.1.1"
+---
+
+将变更的 delta specs 同步到主 specs。
+
+这是一个**代理驱动**的操作 - 你将读取 delta specs 并直接编辑主 specs 以应用更改。这允许智能合并 (例如,添加场景而不复制整个需求)。
+
+**输入**: 可选择指定变更名称。如果省略,检查是否可以从对话上下文中推断。如果模糊或不明确,你**必须**提示可用的变更。
+
+**步骤**
+
+1. **如果未提供变更名称,提示用户选择**
+
+   运行 `openspec list --json` 获取可用的变更。使用 **AskUserQuestion 工具**让用户选择。
+
+   显示具有 delta specs 的变更 (在 `specs/` 目录下)。
+
+   **重要**: 不要猜测或自动选择变更。始终让用户选择。
+
+2. **查找 delta specs**
+
+   在 `openspec/changes/<name>/specs/*/spec.md` 中查找 delta spec 文件。
+
+   每个 delta spec 文件包含如下部分:
+   - `## ADDED Requirements` - 要添加的新需求
+   - `## MODIFIED Requirements` - 对现有需求的更改
+   - `## REMOVED Requirements` - 要删除的需求
+   - `## RENAMED Requirements` - 要重命名的需求 (FROM:/TO: 格式)
+
+   如果未找到 delta specs,通知用户并停止。
+
+3. **对于每个 delta spec,将更改应用到主 specs**
+
+   对于每个在 `openspec/changes/<name>/specs/<capability>/spec.md` 有 delta spec 的 capability:
+
+   a. **读取 delta spec** 以了解预期的更改
+
+   b. **读取主 spec** 在 `openspec/specs/<capability>/spec.md` (可能尚不存在)
+
+   c. **智能应用更改**:
+
+      **ADDED Requirements:**
+      - 如果需求在主 spec 中不存在 → 添加它
+      - 如果需求已存在 → 更新它以匹配 (视为隐式 MODIFIED)
+
+      **MODIFIED Requirements:**
+      - 在主 spec 中找到需求
+      - 应用更改 - 这可以是:
+        - 添加新场景 (不需要复制现有场景)
+        - 修改现有场景
+        - 更改需求描述
+      - 保留 delta 中未提及的场景/内容
+
+      **REMOVED Requirements:**
+      - 从主 spec 中删除整个需求块
+
+      **RENAMED Requirements:**
+      - 找到 FROM 需求,重命名为 TO
+
+   d. **创建新的主 spec** 如果 capability 尚不存在:
+      - 创建 `openspec/specs/<capability>/spec.md`
+      - 添加 Purpose 部分 (可以简短,标记为 TBD)
+      - 添加 Requirements 部分,包含 ADDED 需求
+
+4. **显示摘要**
+
+   应用所有更改后,总结:
+   - 更新了哪些 capabilities
+   - 做了哪些更改 (需求添加/修改/删除/重命名)
+
+**Delta Spec 格式参考**
+
+```markdown
+## ADDED Requirements
+
+### Requirement: 新功能
+系统应当做某件新事情。
+
+#### Scenario: 基本情况
+- **WHEN** 用户执行 X
+- **THEN** 系统执行 Y
+
+## MODIFIED Requirements
+
+### Requirement: 现有功能
+#### Scenario: 要添加的新场景
+- **WHEN** 用户执行 A
+- **THEN** 系统执行 B
+
+## REMOVED Requirements
+
+### Requirement: 已弃用功能
+
+## RENAMED Requirements
+
+- FROM: `### Requirement: 旧名称`
+- TO: `### Requirement: 新名称`
+```
+
+**核心原则: 智能合并**
+
+与程序化合并不同,你可以应用**部分更新**:
+- 要添加场景,只需在 MODIFIED 下包含该场景 - 不要复制现有场景
+- Delta 代表*意图*,而不是全部替换
+- 使用你的判断合理地合并更改
+
+**成功时的输出**
+
+```
+## Specs 已同步: <change-name>
+
+更新的主 specs:
+
+**<capability-1>**:
+- 添加需求: "新功能"
+- 修改需求: "现有功能" (添加 1 个场景)
+
+**<capability-2>**:
+- 创建新 spec 文件
+- 添加需求: "另一个功能"
+
+主 specs 现已更新。变更保持活跃 - 实现完成后归档。
+```
+
+**防护机制**
+- 在进行更改前读取 delta 和主 specs
+- 保留 delta 中未提及的现有内容
+- 如果有不清楚的地方,请求澄清
+- 边做边显示你正在更改的内容
+- 操作应该是幂等的 - 运行两次应该给出相同结果
diff --git a/.opencode/skills/openspec-sync-specs/SKILL.md b/.opencode/skills/openspec-sync-specs/SKILL.md
new file mode 100644
index 0000000..4c7e3aa
--- /dev/null
+++ b/.opencode/skills/openspec-sync-specs/SKILL.md
@@ -0,0 +1,138 @@
+---
+name: openspec-sync-specs
+description: Sync delta specs from a change to main specs. Use when the user wants to update main specs with changes from a delta spec, without archiving the change.
+license: MIT
+compatibility: Requires openspec CLI.
+metadata:
+  author: openspec
+  version: "1.0"
+  generatedBy: "1.1.1"
+---
+
+Sync delta specs from a change to main specs.
+
+This is an **agent-driven** operation - you will read delta specs and directly edit main specs to apply the changes. This allows intelligent merging (e.g., adding a scenario without copying the entire requirement).
+
+**Input**: Optionally specify a change name. If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
+
+**Steps**
+
+1. **If no change name provided, prompt for selection**
+
+   Run `openspec list --json` to get available changes. Use the **AskUserQuestion tool** to let the user select.
+
+   Show changes that have delta specs (under `specs/` directory).
+
+   **IMPORTANT**: Do NOT guess or auto-select a change. Always let the user choose.
+
+2. **Find delta specs**
+
+   Look for delta spec files in `openspec/changes/<name>/specs/*/spec.md`.
+
+   Each delta spec file contains sections like:
+   - `## ADDED Requirements` - New requirements to add
+   - `## MODIFIED Requirements` - Changes to existing requirements
+   - `## REMOVED Requirements` - Requirements to remove
+   - `## RENAMED Requirements` - Requirements to rename (FROM:/TO: format)
+
+   If no delta specs found, inform user and stop.
+
+3. **For each delta spec, apply changes to main specs**
+
+   For each capability with a delta spec at `openspec/changes/<name>/specs/<capability>/spec.md`:
+
+   a. **Read the delta spec** to understand the intended changes
+
+   b. **Read the main spec** at `openspec/specs/<capability>/spec.md` (may not exist yet)
+
+   c. **Apply changes intelligently**:
+
+      **ADDED Requirements:**
+      - If requirement doesn't exist in main spec → add it
+      - If requirement already exists → update it to match (treat as implicit MODIFIED)
+
+      **MODIFIED Requirements:**
+      - Find the requirement in main spec
+      - Apply the changes - this can be:
+        - Adding new scenarios (don't need to copy existing ones)
+        - Modifying existing scenarios
+        - Changing the requirement description
+      - Preserve scenarios/content not mentioned in the delta
+
+      **REMOVED Requirements:**
+      - Remove the entire requirement block from main spec
+
+      **RENAMED Requirements:**
+      - Find the FROM requirement, rename to TO
+
+   d. **Create new main spec** if capability doesn't exist yet:
+      - Create `openspec/specs/<capability>/spec.md`
+      - Add Purpose section (can be brief, mark as TBD)
+      - Add Requirements section with the ADDED requirements
+
+4. **Show summary**
+
+   After applying all changes, summarize:
+   - Which capabilities were updated
+   - What changes were made (requirements added/modified/removed/renamed)
+
+**Delta Spec Format Reference**
+
+```markdown
+## ADDED Requirements
+
+### Requirement: New Feature
+The system SHALL do something new.
+
+#### Scenario: Basic case
+- **WHEN** user does X
+- **THEN** system does Y
+
+## MODIFIED Requirements
+
+### Requirement: Existing Feature
+#### Scenario: New scenario to add
+- **WHEN** user does A
+- **THEN** system does B
+
+## REMOVED Requirements
+
+### Requirement: Deprecated Feature
+
+## RENAMED Requirements
+
+- FROM: `### Requirement: Old Name`
+- TO: `### Requirement: New Name`
+```
+
+**Key Principle: Intelligent Merging**
+
+Unlike programmatic merging, you can apply **partial updates**:
+- To add a scenario, just include that scenario under MODIFIED - don't copy existing scenarios
+- The delta represents *intent*, not a wholesale replacement
+- Use your judgment to merge changes sensibly
+
+**Output On Success**
+
+```
+## Specs Synced: <change-name>
+
+Updated main specs:
+
+**<capability-1>**:
+- Added requirement: "New Feature"
+- Modified requirement: "Existing Feature" (added 1 scenario)
+
+**<capability-2>**:
+- Created new spec file
+- Added requirement: "Another Feature"
+
+Main specs are now updated. The change remains active - archive when implementation is complete.
+```
+
+**Guardrails**
+- Read both delta and main specs before making changes
+- Preserve existing content not mentioned in delta
+- If something is unclear, ask for clarification
+- Show what you're changing as you go
+- The operation should be idempotent - running twice should give same result
diff --git a/.opencode/skills/openspec-verify-change/SKILL.cn.md b/.opencode/skills/openspec-verify-change/SKILL.cn.md
new file mode 100644
index 0000000..2a5fc19
--- /dev/null
+++ b/.opencode/skills/openspec-verify-change/SKILL.cn.md
@@ -0,0 +1,168 @@
+---
+name: openspec-verify-change
+description: Verify implementation matches change artifacts. Use when the user wants to validate that implementation is complete, correct, and coherent before archiving.
+license: MIT
+compatibility: Requires openspec CLI.
+metadata:
+  author: openspec
+  version: "1.0"
+  generatedBy: "1.1.1"
+---
+
+验证实现是否与变更 artifacts (specs、tasks、design) 匹配。
+
+**输入**: 可选择指定变更名称。如果省略,检查是否可以从对话上下文中推断。如果模糊或不明确,你**必须**提示可用的变更。
+
+**步骤**
+
+1. **如果未提供变更名称,提示用户选择**
+
+   运行 `openspec list --json` 获取可用的变更。使用 **AskUserQuestion 工具**让用户选择。
+
+   显示具有实现任务的变更 (tasks artifact 存在)。
+   如果可用,包含每个变更使用的 schema。
+   将具有未完成任务的变更标记为 "(进行中)"。
+
+   **重要**: 不要猜测或自动选择变更。始终让用户选择。
+
+2. **检查状态以了解 schema**
+   ```bash
+   openspec status --change "<name>" --json
+   ```
+   解析 JSON 以了解:
+   - `schemaName`: 正在使用的工作流 (例如: "spec-driven")
+   - 此变更存在哪些 artifacts
+
+3. **获取变更目录并加载 artifacts**
+
+   ```bash
+   openspec instructions apply --change "<name>" --json
+   ```
+
+   这将返回变更目录和上下文文件。从 `contextFiles` 读取所有可用的 artifacts。
+
+4. **初始化验证报告结构**
+
+   创建具有三个维度的报告结构:
+   - **完整性 (Completeness)**: 跟踪任务和 spec 覆盖率
+   - **正确性 (Correctness)**: 跟踪需求实现和场景覆盖
+   - **一致性 (Coherence)**: 跟踪设计遵循情况和模式一致性
+
+   每个维度可以有 CRITICAL、WARNING 或 SUGGESTION 问题。
+
+5. **验证完整性**
+
+   **任务完成度**:
+   - 如果 contextFiles 中存在 tasks.md,读取它
+   - 解析复选框: `- [ ]` (未完成) vs `- [x]` (已完成)
+   - 统计已完成任务 vs 总任务数
+   - 如果存在未完成的任务:
+     - 为每个未完成的任务添加 CRITICAL 问题
+     - 建议: "完成任务: <描述>" 或 "如果已实现请标记为完成"
+
+   **Spec 覆盖率**:
+   - 如果 `openspec/changes/<name>/specs/` 中存在 delta specs:
+     - 提取所有需求 (标记为 "### Requirement:")
+     - 对于每个需求:
+       - 在代码库中搜索与需求相关的关键字
+       - 评估实现是否可能存在
+     - 如果需求看起来未实现:
+       - 添加 CRITICAL 问题: "未找到需求: <需求名称>"
+       - 建议: "实现需求 X: <描述>"
+
+6. **验证正确性**
+
+   **需求实现映射**:
+   - 对于 delta specs 中的每个需求:
+     - 在代码库中搜索实现证据
+     - 如果找到,记录文件路径和行范围
+     - 评估实现是否符合需求意图
+     - 如果检测到偏差:
+       - 添加 WARNING: "实现可能偏离 spec: <详情>"
+       - 建议: "根据需求 X 审查 <file>:<lines>"
+
+   **场景覆盖**:
+   - 对于 delta specs 中的每个场景 (标记为 "#### Scenario:"):
+     - 检查代码中是否处理了条件
+     - 检查是否存在覆盖该场景的测试
+     - 如果场景看起来未覆盖:
+       - 添加 WARNING: "场景未覆盖: <场景名称>"
+       - 建议: "为场景添加测试或实现: <描述>"
+
+7. **验证一致性**
+
+   **设计遵循**:
+   - 如果 contextFiles 中存在 design.md:
+     - 提取关键决策 (查找类似 "Decision:", "Approach:", "Architecture:" 的部分)
+     - 验证实现是否遵循这些决策
+     - 如果检测到矛盾:
+       - 添加 WARNING: "未遵循设计决策: <决策>"
+       - 建议: "更新实现或修订 design.md 以匹配实际情况"
+   - 如果没有 design.md: 跳过设计遵循检查,注明 "没有 design.md 可供验证"
+
+   **代码模式一致性**:
+   - 审查新代码与项目模式的一致性
+   - 检查文件命名、目录结构、编码风格
+   - 如果发现重大偏差:
+     - 添加 SUGGESTION: "代码模式偏差: <详情>"
+     - 建议: "考虑遵循项目模式: <示例>"
+
+8. **生成验证报告**
+
+   **总结记分卡**:
+   ```
+   ## 验证报告: <change-name>
+
+   ### 总结
+   | 维度       | 状态              |
+   |-----------|-------------------|
+   | 完整性     | X/Y 任务, N 需求   |
+   | 正确性     | M/N 需求已覆盖     |
+   | 一致性     | 已遵循/有问题      |
+   ```
+
+   **按优先级分类的问题**:
+
+   1. **CRITICAL** (归档前必须修复):
+      - 未完成的任务
+      - 缺失的需求实现
+      - 每个都有具体、可操作的建议
+
+   2. **WARNING** (应该修复):
+      - Spec/design 偏差
+      - 缺失的场景覆盖
+      - 每个都有具体建议
+
+   3. **SUGGESTION** (最好修复):
+      - 模式不一致
+      - 小改进
+      - 每个都有具体建议
+
+   **最终评估**:
+   - 如果有 CRITICAL 问题: "发现 X 个关键问题。归档前请修复。"
+   - 如果只有警告: "无关键问题。有 Y 个警告需要考虑。准备归档 (带注明的改进)。"
+   - 如果全部通过: "所有检查通过。准备归档。"
+
+**验证启发式方法**
+
+- **完整性**: 专注于客观的检查清单项 (复选框、需求列表)
+- **正确性**: 使用关键字搜索、文件路径分析、合理推断 - 不要求完全确定
+- **一致性**: 寻找明显的不一致,不要挑剔风格
+- **误报**: 如果不确定,优先选择 SUGGESTION 而不是 WARNING,WARNING 而不是 CRITICAL
+- **可操作性**: 每个问题都必须有具体的建议,并在适用时提供文件/行引用
+
+**优雅降级**
+
+- 如果只存在 tasks.md: 仅验证任务完成度,跳过 spec/design 检查
+- 如果 tasks + specs 存在: 验证完整性和正确性,跳过 design
+- 如果完整 artifacts 存在: 验证所有三个维度
+- 始终注明跳过了哪些检查以及原因
+
+**输出格式**
+
+使用清晰的 markdown:
+- 总结记分卡使用表格
+- 问题分组列表 (CRITICAL/WARNING/SUGGESTION)
+- 代码引用格式: `file.ts:123`
+- 具体、可操作的建议
+- 不要使用模糊的建议如 "考虑审查"
diff --git a/.opencode/skills/openspec-verify-change/SKILL.md b/.opencode/skills/openspec-verify-change/SKILL.md
new file mode 100644
index 0000000..443ac5f
--- /dev/null
+++ b/.opencode/skills/openspec-verify-change/SKILL.md
@@ -0,0 +1,168 @@
+---
+name: openspec-verify-change
+description: Verify implementation matches change artifacts. Use when the user wants to validate that implementation is complete, correct, and coherent before archiving.
+license: MIT
+compatibility: Requires openspec CLI.
+metadata:
+  author: openspec
+  version: "1.0"
+  generatedBy: "1.1.1"
+---
+
+Verify that an implementation matches the change artifacts (specs, tasks, design).
+
+**Input**: Optionally specify a change name. If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
+
+**Steps**
+
+1. **If no change name provided, prompt for selection**
+
+   Run `openspec list --json` to get available changes. Use the **AskUserQuestion tool** to let the user select.
+
+   Show changes that have implementation tasks (tasks artifact exists).
+   Include the schema used for each change if available.
+   Mark changes with incomplete tasks as "(In Progress)".
+
+   **IMPORTANT**: Do NOT guess or auto-select a change. Always let the user choose.
+
+2. **Check status to understand the schema**
+   ```bash
+   openspec status --change "<name>" --json
+   ```
+   Parse the JSON to understand:
+   - `schemaName`: The workflow being used (e.g., "spec-driven")
+   - Which artifacts exist for this change
+
+3. **Get the change directory and load artifacts**
+
+   ```bash
+   openspec instructions apply --change "<name>" --json
+   ```
+
+   This returns the change directory and context files. Read all available artifacts from `contextFiles`.
+
+4. **Initialize verification report structure**
+
+   Create a report structure with three dimensions:
+   - **Completeness**: Track tasks and spec coverage
+   - **Correctness**: Track requirement implementation and scenario coverage
+   - **Coherence**: Track design adherence and pattern consistency
+
+   Each dimension can have CRITICAL, WARNING, or SUGGESTION issues.
+
+5. **Verify Completeness**
+
+   **Task Completion**:
+   - If tasks.md exists in contextFiles, read it
+   - Parse checkboxes: `- [ ]` (incomplete) vs `- [x]` (complete)
+   - Count complete vs total tasks
+   - If incomplete tasks exist:
+     - Add CRITICAL issue for each incomplete task
+     - Recommendation: "Complete task: <description>" or "Mark as done if already implemented"
+
+   **Spec Coverage**:
+   - If delta specs exist in `openspec/changes/<name>/specs/`:
+     - Extract all requirements (marked with "### Requirement:")
+     - For each requirement:
+       - Search codebase for keywords related to the requirement
+       - Assess if implementation likely exists
+     - If requirements appear unimplemented:
+       - Add CRITICAL issue: "Requirement not found: <requirement name>"
+       - Recommendation: "Implement requirement X: <description>"
+
+6. **Verify Correctness**
+
+   **Requirement Implementation Mapping**:
+   - For each requirement from delta specs:
+     - Search codebase for implementation evidence
+     - If found, note file paths and line ranges
+     - Assess if implementation matches requirement intent
+     - If divergence detected:
+       - Add WARNING: "Implementation may diverge from spec: <details>"
+       - Recommendation: "Review <file>:<lines> against requirement X"
+
+   **Scenario Coverage**:
+   - For each scenario in delta specs (marked with "#### Scenario:"):
+     - Check if conditions are handled in code
+     - Check if tests exist covering the scenario
+     - If scenario appears uncovered:
+       - Add WARNING: "Scenario not covered: <scenario name>"
+       - Recommendation: "Add test or implementation for scenario: <description>"
+
+7. **Verify Coherence**
+
+   **Design Adherence**:
+   - If design.md exists in contextFiles:
+     - Extract key decisions (look for sections like "Decision:", "Approach:", "Architecture:")
+     - Verify implementation follows those decisions
+     - If contradiction detected:
+       - Add WARNING: "Design decision not followed: <decision>"
+       - Recommendation: "Update implementation or revise design.md to match reality"
+   - If no design.md: Skip design adherence check, note "No design.md to verify against"
+
+   **Code Pattern Consistency**:
+   - Review new code for consistency with project patterns
+   - Check file naming, directory structure, coding style
+   - If significant deviations found:
+     - Add SUGGESTION: "Code pattern deviation: <details>"
+     - Recommendation: "Consider following project pattern: <example>"
+
+8. **Generate Verification Report**
+
+   **Summary Scorecard**:
+   ```
+   ## Verification Report: <change-name>
+
+   ### Summary
+   | Dimension    | Status           |
+   |--------------|------------------|
+   | Completeness | X/Y tasks, N reqs|
+   | Correctness  | M/N reqs covered |
+   | Coherence    | Followed/Issues  |
+   ```
+
+   **Issues by Priority**:
+
+   1. **CRITICAL** (Must fix before archive):
+      - Incomplete tasks
+      - Missing requirement implementations
+      - Each with specific, actionable recommendation
+
+   2. **WARNING** (Should fix):
+      - Spec/design divergences
+      - Missing scenario coverage
+      - Each with specific recommendation
+
+   3. **SUGGESTION** (Nice to fix):
+      - Pattern inconsistencies
+      - Minor improvements
+      - Each with specific recommendation
+
+   **Final Assessment**:
+   - If CRITICAL issues: "X critical issue(s) found. Fix before archiving."
+   - If only warnings: "No critical issues. Y warning(s) to consider. Ready for archive (with noted improvements)."
+   - If all clear: "All checks passed. Ready for archive."
+
+**Verification Heuristics**
+
+- **Completeness**: Focus on objective checklist items (checkboxes, requirements list)
+- **Correctness**: Use keyword search, file path analysis, reasonable inference - don't require perfect certainty
+- **Coherence**: Look for glaring inconsistencies, don't nitpick style
+- **False Positives**: When uncertain, prefer SUGGESTION over WARNING, WARNING over CRITICAL
+- **Actionability**: Every issue must have a specific recommendation with file/line references where applicable
+
+**Graceful Degradation**
+
+- If only tasks.md exists: verify task completion only, skip spec/design checks
+- If tasks + specs exist: verify completeness and correctness, skip design
+- If full artifacts: verify all three dimensions
+- Always note which checks were skipped and why
+
+**Output Format**
+
+Use clear markdown with:
+- Table for summary scorecard
+- Grouped lists for issues (CRITICAL/WARNING/SUGGESTION)
+- Code references in format: `file.ts:123`
+- Specific, actionable recommendations
+- No vague suggestions like "consider reviewing"
diff --git a/.opencode/skills/pancli-design/SKILL.cn.md b/.opencode/skills/pancli-design/SKILL.cn.md
new file mode 100644
index 0000000..66a9998
--- /dev/null
+++ b/.opencode/skills/pancli-design/SKILL.cn.md
@@ -0,0 +1,765 @@
+---
+name: pancli-design
+description: 专业的设计技能,用于使用 pancli (pencil tools) 创建现代化、一致的 EmailBill 移动端 UI 设计
+license: MIT
+compatibility: Requires pencil_* tools (batch_design, batch_get, etc.)
+metadata:
+  author: EmailBill Design Team
+  version: "2.0.0"
+  generatedBy: opencode
+  lastUpdated: "2026-02-03"
+  source: ".pans/v2.pen 日历设计 (亮色/暗色)"
+---
+
+# pancli-design - EmailBill UI 设计系统
+
+> 专业的设计技能,用于使用 pancli (pencil tools) 创建现代化、一致的移动端 UI 设计。
+
+## 何时使用此技能
+
+**总是使用此技能当:**
+- 使用 pancli 创建新的 UI 界面或组件
+- 修改现有的 .pen 设计文件
+- 处理亮色/暗色主题设计
+- 为 EmailBill 项目设计移动端优先的界面
+
+**触发条件:**
+- 用户提到 "画设计图"、"设计"、"UI"、"界面"、"pancli"、".pen"
+- 任务涉及 `pencil_*` 工具
+- 创建视觉原型或模型
+
+## 核心设计原则
+
+### 1. 现代移动端优先设计
+
+**核心规范:**
+- 移动视口: 375px 宽度 (iPhone SE 基准)
+- 安全区域: 尊重 iOS/Android 安全区域边距
+- 交互元素最小触摸目标: 44x44px
+- 间距基于 8px 网格: 4px, 8px, 12px, 16px, 24px, 32px
+- 卡片阴影: `0 2px 12px rgba(0,0,0,0.08)` (亮色模式)
+
+**反 AI 设计痕迹检查清单:**
+- ❌ 使用 "Dashboard", "Lorem Ipsum" 等通用占位符
+- ❌ 使用过饱和的颜色或生硬的渐变
+- ❌ 使用装饰性字体 (Comic Sans, Papyrus)
+- ✅ 使用代码库中的真实中文业务术语
+- ✅ 使用克制的配色和柔和的阴影
+- ✅ 使用专业的系统字体
+
+### 2. 统一色彩系统
+
+**色彩分层:**
+- **背景层**: 页面背景 → 卡片背景 → 强调背景 (三层递进)
+- **文本层**: 主文本 → 次要文本 → 三级文本 (三级层次)
+- **语义色**: 红色(支出/危险) → 黄色(警告) → 绿色(收入/成功) → 蓝色(主操作/信息)
+
+**颜色使用规则:**
+- 始终使用语义颜色变量,避免硬编码十六进制值
+- 支出/负数统一使用红色 `#FF6B6B`,收入/正数使用绿色系
+- 主操作按钮统一使用蓝色 `#3B82F6`
+- 避免纯黑 (#000000) 或纯白 (#FFFFFF) 文本,使用柔和的色调
+- 暗色模式下减少阴影强度或完全移除
+- 详细色值参见文末"快速参考"表格
+
+### 3. 排版系统
+
+**字体栈:**
+- **标题**: `'Bricolage Grotesque'` - 用于大数值、章节标题
+- **正文**: `'DM Sans'` - 用于界面文本、说明
+- **数字**: `'DIN Alternate'` - 用于金额、数据显示
+- **备选**: `-apple-system, 'PingFang SC'` - 系统默认字体
+
+**排版原则:**
+- 使用真实中文业务术语,避免 Lorem Ipsum
+- 行高: 1.4-1.6 保证可读性
+- 数字数据使用等宽字体 (tabular-nums)
+- 字号遵循比例系统,避免任意数值
+- 详细字号比例参见文末"快速参考"表格
+
+### 4. 组件库
+
+**设计原则:**
+- 所有尺寸和间距基于 8px 网格系统
+- 圆角: 12px (小按钮), 16px/20px (卡片), 22px/28px (圆形按钮)
+- 交互元素最小触摸目标: 44x44px
+- 详细组件规格参见文末"快速参考"表格
+
+**卡片设计 (基于 statsCard, tCard):**
+```
+统计卡片 (大卡片):
+  - 背景: #F6F7F8 (亮色), #18181B (暗色)
+  - 内边距: 20px
+  - 圆角: 20px
+  - 间距: 12px (元素之间)
+  - 布局: 垂直
+
+交易卡片 (列表卡片):
+  - 背景: #F6F7F8 (亮色), #18181B (暗色)  
+  - 内边距: 16px
+  - 圆角: 16px
+  - 间距: 14px (水平元素)
+  - 高度: 自适应内容
+```
+
+**按钮 (基于实际设计):**
+```
+图标按钮 (通知按钮):
+  - 尺寸: 44x44px
+  - 圆角: 22px (完全圆形)
+  - 背景: #F5F5F5 (亮色), #27272A (暗色)
+  - 图标大小: 20px
+  
+标签按钮:
+  - 内边距: 6px 10px / 6px 12px
+  - 圆角: 12px
+  - 字体: DM Sans 13px/500
+  - 颜色:
+    - 温暖色: #FFFBEB (亮色), #451A03 (暗色)
+    - 绿色: #F0FDF4 (亮色), #064E3B (暗色)
+    - 蓝色: #E0E7FF (亮色), #312E81 (暗色)
+
+悬浮按钮 (FAB):
+  - 尺寸: 56x56px
+  - 圆角: 28px
+  - 背景: #3B82F6
+  - 描边: 4px 白色边框
+  - 阴影: 提升效果
+```
+
+**图标与文字:**
+```
+图标容器:
+  - 尺寸: 44x44px
+  - 圆角: 22px
+  - 背景: #FFFFFF (亮色), #27272A (暗色)
+  - 图标: 20px (lucide 字体)
+  - 颜色: #FF6B6B (星标), #FCD34D (咖啡)
+
+章节标题:
+  - 字体: Bricolage Grotesque 18px/700
+  - 颜色: #1A1A1A (亮色), #F4F4F5 (暗色)
+  
+大数值:
+  - 字体: Bricolage Grotesque 32px/800
+  - 颜色: #1A1A1A (亮色), #F4F4F5 (暗色)
+```
+
+**布局模式 (基于 Calendar 结构):**
+```
+页面容器: 402px (设计视口), 垂直布局, 24px 内边距
+头部区域: 水平布局, 两端对齐, 8px 24px 内边距
+内容区域: 垂直布局, 24px 内边距, 12-16px 间距
+```
+
+**关键布局原则:**
+- 遵循 Flex 容器模式 (见下方"5. 布局模式")
+- 导航栏背景必须透明 (`:deep(.van-nav-bar) { background: transparent !important; }`)
+- 尊重安全区域 (`env(safe-area-inset-bottom)`)
+
+### 5. 布局模式
+
+**页面结构 (Flex 容器):**
+```
+.page-container-flex:
+  - display: flex
+  - flex-direction: column
+  - height: 100%
+  - overflow: hidden
+  
+  结构:
+    1. van-nav-bar (固定高度)
+    2. van-tabs 或 sticky-header
+    3. scroll-content (flex: 1, overflow-y: auto)
+    4. bottom-button 或 van-tabbar (固定)
+```
+
+**导航栏背景透明化 (项目标准模式):**
+```css
+/* 所有页面统一设置 */
+:deep(.van-nav-bar) {
+  background: transparent !important;
+}
+```
+**关键要求:**
+- 页面容器必须有明确的背景色
+- 必须使用 `:deep()` 选择器覆盖 Vant 样式
+- 必须添加 `!important` 标记
+- 在 `<style scoped>` 块中添加此规则
+
+**安全区域处理:**
+```css
+/* iPhone 刘海底部内边距 */
+padding-bottom: env(safe-area-inset-bottom, 0px);
+
+/* 状态栏顶部内边距 */
+padding-top: max(0px, calc(env(safe-area-inset-top, 0px) * 0.75));
+```
+
+**固定元素:**
+```css
+.sticky-header {
+  position: sticky;
+  top: 0;
+  z-index: 10;
+  background: var(--van-background-2);
+  border-radius: 12px;
+  box-shadow: 0 2px 8px rgba(0,0,0,0.04);
+  margin: 12px;
+  padding: 12px 16px;
+}
+```
+
+### 6. 交互模式
+
+**触摸反馈:**
+- 激活状态: 点击时 scale(0.95)
+- 涟漪效果: 使用 Vant 内置触摸反馈
+- 悬停状态: 12% 透明度叠加 (网页端)
+
+**加载状态:**
+```
+van-pull-refresh:
+  - 用于顶层可滚动内容
+  - 最小高度: calc(100vh - nav - tabbar)
+  
+van-loading:
+  - 容器内居中
+  - 尺寸: 内联 24px, 页面 32px
+```
+
+**空状态:**
+```
+van-empty:
+  - 图标: 60px 大小
+  - 描述: 14px, var(--van-text-color-2)
+  - 内边距: 垂直 48px
+```
+
+**悬浮操作:**
+```
+van-floating-bubble:
+  - 图标大小: 24px
+  - 位置: 右下角, 距底部 100px (避开 tabbar)
+  - 磁吸: 贴靠 x 轴边缘
+```
+
+### 7. 数据可视化
+
+**预算进度条:**
+```
+渐变逻辑:
+  支出 (0% → 100%):
+    - 0%:  #40a9ff (安全蓝)
+    - 40%: #36cfc9 (青色过渡)
+    - 70%: #faad14 (警告黄)
+    - 100%: #ff4d4f (危险红)
+  
+  收入 (0% → 100%):
+    - 0%:  #f5222d (深红 - 未开始)
+    - 45%: #ffcccc (浅红)
+    - 50%: #f0f2f5 (中性灰)
+    - 55%: #bae7ff (浅蓝)
+    - 100%: #1890ff (深蓝 - 达成)
+```
+
+**金额显示:**
+```css
+.amount {
+  font-family: 'DIN Alternate', system-ui;
+  font-weight: 600;
+  font-variant-numeric: tabular-nums;
+}
+
+.expense { color: var(--van-danger-color); }
+.income { color: var(--van-success-color); }
+```
+
+**图表 (如果使用):**
+- 折线图: 2px 笔画, 圆角连接
+- 柱状图: 8px 圆角, 4px 间距
+- 颜色: 使用语义色阶
+- 网格线: 1px, 8% 透明度
+
+### 8. 主题切换 (亮色/暗色)
+
+**实现策略:**
+```javascript
+// 自动检测系统偏好
+const isDark = window.matchMedia('(prefers-color-scheme: dark)').matches
+theme.value = isDark ? 'dark' : 'light'
+document.documentElement.setAttribute('data-theme', theme.value)
+```
+
+**设计文件要求:**
+- **必须同时创建亮色和暗色变体**
+- 使用 Vant 的主题变量 (自动切换)
+- 测试对比度: WCAG AA 最低标准 (文本 4.5:1)
+- 暗色模式适配:
+  - 减少卡片阴影至 0 2px 8px rgba(0,0,0,0.24)
+  - 增加边框对比度
+  - 白色文本柔化至 #e5e5e5
+
+**pancli 工作流:**
+```
+1. 先创建亮色主题设计
+2. 复制帧用于暗色模式
+3. 使用 replace_all_matching_properties 批量更新:
+   - 背景颜色
+   - 文本颜色
+   - 边框颜色
+4. 手动调整阴影和叠加
+5. 命名帧: "[屏幕名称] - Light" / "[屏幕名称] - Dark"
+```
+
+### 9. 命名约定
+
+**帧名称:**
+```
+格式: [模块] - [屏幕] - [变体]
+
+示例:
+  ✅ Budget - List View - Light
+  ✅ Budget - Edit Dialog - Dark
+  ✅ Transaction - Card Component
+  ✅ Statistics - Chart Section
+  
+  ❌ Screen1
+  ❌ Frame_Copy_2
+  ❌ New Design
+```
+
+**组件层级:**
+```
+可复用组件:
+  - 前缀 "Component/"
+  - 示例: "Component/BudgetCard"
+  
+屏幕:
+  - 按模块分组
+  - 示例: "Budget/ListView", "Budget/EditForm"
+```
+
+### 10. 质量检查清单
+
+**设计完成前必检项:**
+- [ ] 同时创建亮色和暗色主题
+- [ ] 使用真实中文业务术语 (无占位文本)
+- [ ] 交互元素 ≥ 44x44px
+- [ ] 间距遵循 8px 网格
+- [ ] 使用语义颜色变量 (非硬编码)
+- [ ] 导航栏背景透明 (`:deep(.van-nav-bar)`)
+- [ ] 帧命名: 模块-屏幕-变体 格式
+- [ ] 可复用组件标记 `reusable: true`
+- [ ] 两种主题截图验证
+
+**无障碍标准:**
+- [ ] 正文对比度 ≥ 4.5:1
+- [ ] 大文本对比度 ≥ 3:1 (18px+)
+- [ ] 触摸目标间距 ≥ 8px
+
+## PANCLI 工作流程
+
+### 阶段 1: 设置与风格选择
+
+```typescript
+// 1. 获取编辑器状态
+pencil_get_editor_state(include_schema: true)
+
+// 2. 获取设计指南
+pencil_get_guidelines(topic: "landing-page") // 或 "design-system"
+
+// 3. 选择合适的风格指南
+pencil_get_style_guide_tags() // 获取可用标签
+
+// 4. 使用标签获取风格指南
+pencil_get_style_guide(tags: [
+  "mobile",        // 必需
+  "webapp",        // 类应用界面
+  "modern",        // 简洁, 现代
+  "minimal",       // 避免杂乱
+  "professional",  // 商业环境
+  "blue",          // 主色提示
+  "fintech"        // 如果可用
+])
+```
+
+### 阶段 2: 创建亮色主题设计
+
+```typescript
+// 5. 读取现有组件 (如果有)
+pencil_batch_get(
+  filePath: "designs/emailbill.pen",
+  patterns: [{ reusable: true }],
+  readDepth: 2
+)
+
+// 6. 创建亮色主题屏幕
+pencil_batch_design(
+  filePath: "designs/emailbill.pen",
+  operations: `
+    screen=I(document, {
+      type: "frame",
+      name: "Budget - List View - Light",
+      width: 375,
+      height: 812,
+      fill: "#FFFFFF",
+      layout: "vertical",
+      placeholder: true
+    })
+    
+    navbar=I(screen, {
+      type: "frame",
+      name: "Navbar",
+      width: "fill_container",
+      height: 44,
+      fill: "transparent",
+      layout: "horizontal",
+      padding: [12, 16, 12, 16]
+    })
+    
+    title=I(navbar, {
+      type: "text",
+      content: "预算管理",
+      fontSize: 16,
+      fontWeight: "600",
+      textColor: "#1A1A1A"
+    })
+    
+    // ... 更多操作
+  `
+)
+```
+
+### 阶段 3: 创建暗色主题变体
+
+```typescript
+// 7. 复制亮色主题帧
+pencil_batch_design(
+  operations: `
+    darkScreen=C("light-screen-id", document, {
+      name: "Budget - List View - Dark",
+      positionDirection: "right",
+      positionPadding: 48
+    })
+  `
+)
+
+// 8. 批量替换暗色主题颜色
+pencil_replace_all_matching_properties(
+  parents: ["dark-screen-id"],
+  properties: {
+    fillColor: [
+      { from: "#FFFFFF", to: "#09090B" },   // 页面背景
+      { from: "#F6F7F8", to: "#18181B" },   // 卡片背景
+      { from: "#F5F5F5", to: "#27272A" }    // 边框
+    ],
+    textColor: [
+      { from: "#1A1A1A", to: "#F4F4F5" },   // 主文本
+      { from: "#6B7280", to: "#A1A1AA" },   // 次要
+      { from: "#9CA3AF", to: "#71717A" }    // 三级
+    ]
+  }
+)
+
+// 9. 手动调整暗色模式阴影 (如需要)
+pencil_batch_design(
+  operations: `
+    U("dark-card-id", {
+      shadow: {
+        x: 0,
+        y: 2,
+        blur: 8,
+        color: "rgba(0,0,0,0.24)"
+      }
+    })
+  `
+)
+```
+
+### 阶段 4: 验证
+
+```typescript
+// 10. 对两种主题截图
+pencil_get_screenshot(nodeId: "light-screen-id")
+pencil_get_screenshot(nodeId: "dark-screen-id")
+
+// 11. 检查布局问题
+pencil_snapshot_layout(
+  parentId: "light-screen-id",
+  problemsOnly: true
+)
+
+// 12. 验证所有唯一属性
+pencil_search_all_unique_properties(
+  parents: ["light-screen-id"],
+  properties: ["fillColor", "textColor", "fontSize"]
+)
+```
+
+## 代码库实际示例
+
+### 示例 1: 预算卡片组件
+
+```
+组件结构:
+  BudgetCard (375x120px)
+    ├─ CardBackground (#ffffff, 16px 圆角, 阴影)
+    ├─ HeaderRow (水平布局)
+    │   ├─ CategoryName (16px, 600 粗细)
+    │   └─ PeriodLabel (12px, 次要颜色)
+    ├─ ProgressBar (基于比例渐变)
+    │   └─ ProgressFill (高度: 8px, 圆角: 4px)
+    ├─ AmountRow (水平布局, 两端对齐)
+    │   ├─ CurrentAmount (DIN, 18px, 危险色)
+    │   ├─ LimitAmount (DIN, 14px, 次要)
+    │   └─ RemainingAmount (DIN, 14px, 成功色)
+    └─ FooterActions (可选, 储蓄按钮)
+```
+
+**pancli 实现:**
+```typescript
+card=I(parent, {
+  type: "frame",
+  name: "BudgetCard",
+  width: "fill_container",
+  height: 120,
+  fill: "#ffffff",
+  cornerRadius: [16, 16, 16, 16],
+  shadow: { x: 0, y: 2, blur: 12, color: "rgba(0,0,0,0.08)" },
+  stroke: { color: "#ebedf0", thickness: 1 },
+  padding: [16, 16, 16, 16],
+  layout: "vertical",
+  gap: 12,
+  placeholder: true
+})
+
+header=I(card, {
+  type: "frame",
+  layout: "horizontal",
+  width: "fill_container",
+  height: "hug_contents"
+})
+
+categoryName=I(header, {
+  type: "text",
+  content: "日常开销",
+  fontSize: 16,
+  fontWeight: "600",
+  textColor: "#323233"
+})
+
+// 带渐变的进度条
+progressBar=I(card, {
+  type: "frame",
+  width: "fill_container",
+  height: 8,
+  fill: "#f0f0f0",
+  cornerRadius: [4, 4, 4, 4]
+})
+
+progressFill=I(progressBar, {
+  type: "frame",
+  width: "75%", // 75% 进度示例
+  height: 8,
+  fill: "linear-gradient(90deg, #40a9ff 0%, #faad14 100%)",
+  cornerRadius: [4, 4, 4, 4]
+})
+```
+
+### 示例 2: 带日期选择器的固定头部
+
+```
+固定头部模式 (来自 BudgetView):
+  ├─ 位置: sticky, top: 0
+  ├─ 背景: var(--van-background-2)
+  ├─ 圆角: 12px
+  ├─ 阴影: 0 2px 8px rgba(0,0,0,0.04)
+  ├─ 内边距: 12px 16px
+  ├─ 内容: "2024年1月" + 下拉箭头图标
+```
+
+### 示例 3: 滑动删除列表项
+
+```
+van-swipe-cell 模式:
+  ├─ 内容: BudgetCard 组件
+  ├─ 右侧操作: 删除按钮
+  │   ├─ 宽度: 60px
+  │   ├─ 背景: var(--van-danger-color)
+  │   ├─ 文本: "删除"
+  │   └─ 全高 (100%)
+```
+
+## 避免的反模式
+
+**❌ 不要这样做:**
+```
+// 通用 AI 生成内容
+title=I(navbar, {
+  type: "text",
+  content: "Dashboard", // ❌ 使用 "预算管理" 代替
+  fontSize: 20,         // ❌ 按字号比例使用 16px
+  fontWeight: "bold"    // ❌ 使用数字值 600
+})
+
+// 不一致的间距
+card=I(parent, {
+  padding: [15, 13, 17, 14] // ❌ 使用 8px 网格: [16, 16, 16, 16]
+})
+
+// 硬编码颜色而非语义
+amount=I(card, {
+  textColor: "#ff0000" // ❌ 使用 var(--van-danger-color) 或 "#ee0a24"
+})
+
+// 缺少暗色模式
+// ❌ 只创建亮色主题没有暗色变体
+
+// 糟糕的命名
+frame=I(document, {
+  name: "Frame_123" // ❌ 使用 "Budget - List View - Light"
+})
+```
+
+**✅ 应该这样做:**
+```typescript
+// 真实业务术语
+title=I(navbar, {
+  type: "text",
+  content: "预算管理",
+  fontSize: 16,
+  fontWeight: "600",
+  textColor: "#323233"
+})
+
+// 一致的 8px 网格间距
+card=I(parent, {
+  padding: [16, 16, 16, 16],
+  gap: 12
+})
+
+// 语义颜色变量
+amount=I(card, {
+  textColor: "#ee0a24", // 一致的危险色
+  fontFamily: "DIN Alternate"
+})
+
+// 总是创建两种主题
+lightScreen=I(document, { name: "Budget - List - Light" })
+darkScreen=C(lightScreen, document, { 
+  name: "Budget - List - Dark",
+  positionDirection: "right"
+})
+
+// 清晰的描述性名称
+card=I(parent, {
+  name: "BudgetCard",
+  reusable: true
+})
+```
+
+## 委派与任务管理
+
+**使用此技能时:**
+
+```typescript
+// 委派设计任务时加载此技能
+delegate_task(
+  category: "visual-engineering",
+  load_skills: ["pancli-design", "frontend-ui-ux"],
+  description: "创建预算列表屏幕设计",
+  prompt: `
+    任务: 为 EmailBill 应用创建移动端预算列表屏幕设计
+    
+    预期结果:
+    - 375x812px 亮色主题设计
+    - 暗色主题变体 (复制并适配)
+    - 可复用的 BudgetCard 组件
+    - 两种主题的截图验证
+    
+    必需工具:
+    - pencil_get_style_guide_tags
+    - pencil_get_style_guide
+    - pencil_batch_design
+    - pencil_batch_get
+    - pencil_replace_all_matching_properties
+    - pencil_get_screenshot
+    
+    必须做:
+    - 严格遵循 pancli-design 技能指南
+    - 使用真实中文业务术语 (预算, 账单, 分类)
+    - 创建亮色和暗色两种主题
+    - 使用 8px 网格间距系统
+    - 遵循 Vant UI 组件模式
+    - 使用 模块-屏幕-变体 格式命名帧
+    - 使用语义颜色变量
+    - 数字显示应用 DIN Alternate
+    - 导航栏背景必须设置为透明 (:deep(.van-nav-bar) { background: transparent !important; })
+    - 截图验证
+    
+    不得做:
+    - 使用 Lorem Ipsum 或占位文本
+    - 只创建亮色主题没有暗色变体
+    - 使用任意间距 (必须遵循 8px 网格)
+    - 硬编码颜色 (使用语义变量)
+    - 使用通用 "Dashboard" 标签
+    - 跳过截图验证
+    - 创建名为 "Frame_1", "Copy" 等的帧
+    
+    上下文:
+    - 移动视口: 375px 宽度
+    - 设计系统: 基于 Vant UI
+    - 配色方案: #1989fa 主色, #ee0a24 危险, #07c160 成功
+    - 字体: 中文系统默认, 数字 DIN Alternate
+    - designs/emailbill.pen 中的现有组件 (用 batch_get 检查)
+  `,
+  run_in_background: false
+)
+```
+
+## 快速参考
+
+**颜色面板 (基于实际 v2.pen 设计):**
+
+| 名称 | 亮色 | 暗色 | 用途 |
+|------|------|------|------|
+| 页面背景 | #FFFFFF | #09090B | 页面背景 |
+| 卡片背景 | #F6F7F8 | #18181B | 卡片表面 |
+| 强调背景 | #F5F5F5 | #27272A | 按钮, 图标容器 |
+| 主文本 | #1A1A1A | #F4F4F5 | 主要文本 |
+| 次要文本 | #6B7280 | #A1A1AA | 次要文本 |
+| 三级文本 | #9CA3AF | #71717A | 三级文本 |
+| 主色 | #3B82F6 | #3B82F6 | 操作, FAB |
+| 红色 | #FF6B6B | #FF6B6B | 支出, 警告 |
+| 黄色 | #FCD34D | #FCD34D | 警告 |
+| 绿色 | #F0FDF4 | #064E3B | 收入标签 |
+| 蓝色 | #E0E7FF | #312E81 | 信息标签 |
+
+**排版比例:**
+
+| 用途 | 字体 | 大小 | 粗细 |
+|------|------|------|------|
+| 大数值 | Bricolage Grotesque | 32px | 800 |
+| 页面标题 | DM Sans | 24px | 500 |
+| 章节标题 | Bricolage Grotesque | 18px | 700 |
+| 正文 | DM Sans | 15px | 600 |
+| 说明 | DM Sans | 13px | 500 |
+| 微型标签 | DM Sans | 12px | 600 |
+
+**组件规格:**
+
+- **容器内边距**: 24px (主区域), 20px (卡片), 16px (小卡片)
+- **间距比例**: 2px, 4px, 8px, 12px, 14px, 16px
+- **圆角**: 12px (标签), 16px/20px (卡片), 22px/28px (圆形按钮)
+- **图标**: 20px
+- **图标按钮**: 44x44px
+- **FAB 按钮**: 56x56px
+- **触摸目标**: 最小 44x44px
+- **设计视口**: 402px 宽度
+
+---
+
+**版本:** 2.0.0  
+**最后更新:** 2026-02-04  
+**维护者:** EmailBill 设计团队
diff --git a/.opencode/skills/pancli-implement/SKILL.cn.md b/.opencode/skills/pancli-implement/SKILL.cn.md
new file mode 100644
index 0000000..31951eb
--- /dev/null
+++ b/.opencode/skills/pancli-implement/SKILL.cn.md
@@ -0,0 +1,1197 @@
+---
+name: pancli-implement
+description: 根据 pancli 设计图(.pen 文件)进行前后端完整实施的专业技能,确保高度还原设计,数据表支持,交互确认
+license: MIT
+compatibility: Requires .pen design files, Entity layer, WebApi controllers, Vue 3 frontend
+metadata:
+  author: EmailBill Development Team
+  version: "1.0.0"
+  generatedBy: opencode
+  lastUpdated: "2026-02-03"
+  source: "基于 .pans/v2.pen 设计实施流程"
+---
+
+# pancli-implement - 设计图实施技能
+
+> 根据 pancli 设计图(.pen 文件)进行前后端完整实施,确保高度还原设计稿,包括数据表确认、API 开发、前端组件实现和交互验证。
+
+## 何时使用此技能
+
+**总是使用此技能当:**
+- 需要根据 .pen 设计文件实施前后端功能
+- 将设计图转换为可运行的代码
+- 需要确认数据表结构是否支持设计需求
+- 实施过程中需要询问用户确认交互细节
+- 高度还原设计稿的视觉效果和交互体验
+
+**触发条件:**
+- 用户提到 "实施设计图"、"根据设计实现"、"按照 pancli"
+- 任务涉及从 .pen 文件到代码的转换
+- 需要同时开发前端和后端
+
+## 核心实施原则
+
+### 0. **模块化架构:复杂页面拆分**
+
+**重要:** 对于复杂页面(如日历、统计概览、仪表板),必须采用**模块化架构**:
+
+**目录结构规范:**
+```
+views/
+  calendarV2/              # 页面目录
+    Index.vue              # 主页面(编排器)
+    modules/               # 模块目录
+      Calendar.vue         # 日历模块
+      Stats.vue            # 统计模块
+      TransactionList.vue  # 交易列表模块
+```
+
+**模块化原则:**
+
+1. **高内聚模块**
+   - 每个模块是独立的功能单元
+   - 模块内部管理自己的数据和状态
+   - 模块自己调用 API 获取数据
+   - 模块自己处理内部事件
+
+2. **Index.vue 作为编排器**
+   - **只负责布局和事件编排**
+   - **不调用 API,不管理业务数据**
+   - 接收用户交互(如日期选择)
+   - 通过 props 传递必要参数给模块
+   - 通过事件监听模块的输出
+   - 协调模块间的通信
+
+3. **模块间通信**
+   - 父 → 子:通过 props 传递(只传必要参数,如 `selectedDate`)
+   - 子 → 父:通过 emit 发送事件(如 `@transaction-click`)
+   - 兄弟模块:通过父组件中转事件
+
+4. **不使用 TypeScript**
+   - 项目使用纯 JavaScript + Vue 3 Composition API
+   - **不要**在 `<script setup>` 添加 `lang="ts"`
+   - 使用 JSDoc 注释代替类型定义
+
+**示例:calendarV2 模块化架构**
+
+```vue
+<!-- Index.vue - 编排器(仅负责布局和事件协调) -->
+<template>
+  <div class="page-container-flex">
+    <!-- 头部 -->
+    <header class="header">
+      <button @click="changeMonth(-1)">上一月</button>
+      <h1>{{ currentMonth }}</h1>
+      <button @click="changeMonth(1)">下一月</button>
+    </header>
+
+    <!-- 可滚动内容 -->
+    <div class="scroll-content">
+      <!-- 日历模块:自己查询日历数据 -->
+      <CalendarModule
+        :current-date="currentDate"
+        :selected-date="selectedDate"
+        @day-click="onDayClick"
+      />
+
+      <!-- 统计模块:自己查询统计数据 -->
+      <StatsModule
+        :selected-date="selectedDate"
+      />
+
+      <!-- 交易列表模块:自己查询交易数据 -->
+      <TransactionListModule
+        :selected-date="selectedDate"
+        @transaction-click="onTransactionClick"
+      />
+    </div>
+  </div>
+</template>
+
+<script setup>
+import { ref, computed } from 'vue'
+import { useRouter } from 'vue-router'
+import CalendarModule from './modules/Calendar.vue'
+import StatsModule from './modules/Stats.vue'
+import TransactionListModule from './modules/TransactionList.vue'
+
+const router = useRouter()
+
+// Index 只管理日期状态(共享参数)
+const currentDate = ref(new Date())
+const selectedDate = ref(new Date())
+
+const currentMonth = computed(() => {
+  return `${currentDate.value.getFullYear()}年${currentDate.value.getMonth() + 1}月`
+})
+
+// Index 只负责事件编排
+const onDayClick = (day) => {
+  selectedDate.value = new Date(day.date)
+}
+
+const onTransactionClick = (txn) => {
+  router.push({ path: '/transaction-detail', query: { id: txn.id } })
+}
+
+const changeMonth = (offset) => {
+  const newDate = new Date(currentDate.value)
+  newDate.setMonth(newDate.getMonth() + offset)
+  currentDate.value = newDate
+}
+
+// ❌ Index 不调用 API
+// ❌ Index 不管理业务数据(如交易列表、统计数据)
+// ✅ Index 只管理共享的状态(如日期)
+// ✅ Index 只负责路由跳转和事件编排
+</script>
+```
+
+```vue
+<!-- modules/Stats.vue - 高内聚模块 -->
+<template>
+  <div class="stats-module">
+    <h2>{{ selectedDateFormatted }}</h2>
+    <div class="stats-card">
+      <div class="stats-item">
+        <span>当日支出</span>
+        <div class="value">¥{{ expense.toFixed(2) }}</div>
+      </div>
+      <div class="stats-item">
+        <span>当日收入</span>
+        <div class="value">¥{{ income.toFixed(2) }}</div>
+      </div>
+    </div>
+  </div>
+</template>
+
+<script setup>
+import { ref, watch, computed } from 'vue'
+import { getTransactionsByDate } from '@/api/transactionRecord'
+
+const props = defineProps({
+  selectedDate: Date  // 从父组件接收必要参数
+})
+
+// ✅ 模块自己管理数据
+const expense = ref(0)
+const income = ref(0)
+const loading = ref(false)
+
+// ✅ 模块自己调用 API
+const fetchStats = async (date) => {
+  try {
+    loading.value = true
+    const dateKey = formatDate(date)
+    const response = await getTransactionsByDate(dateKey)
+    
+    if (response.success) {
+      expense.value = response.data
+        .filter(t => t.type === 0)
+        .reduce((sum, t) => sum + t.amount, 0)
+      
+      income.value = response.data
+        .filter(t => t.type === 1)
+        .reduce((sum, t) => sum + t.amount, 0)
+    }
+  } finally {
+    loading.value = false
+  }
+}
+
+// ✅ 模块监听 props 变化并重新加载数据
+watch(() => props.selectedDate, async (newDate) => {
+  if (newDate) {
+    await fetchStats(newDate)
+  }
+}, { immediate: true })
+
+// ✅ 模块内部工具函数
+const formatDate = (date) => {
+  const y = date.getFullYear()
+  const m = String(date.getMonth() + 1).padStart(2, '0')
+  const d = String(date.getDate()).padStart(2, '0')
+  return `${y}-${m}-${d}`
+}
+
+const selectedDateFormatted = computed(() => {
+  const y = props.selectedDate.getFullYear()
+  const m = props.selectedDate.getMonth() + 1
+  const d = props.selectedDate.getDate()
+  return `${y}年${m}月${d}日`
+})
+</script>
+
+<style scoped>
+/* 模块自己的样式 */
+.stats-module {
+  padding: 24px;
+}
+/* ... */
+</style>
+```
+
+```vue
+<!-- modules/TransactionList.vue - 高内聚模块 -->
+<template>
+  <div class="transaction-list-module">
+    <div class="header">
+      <h2>交易记录</h2>
+      <span class="badge">{{ transactions.length }} Items</span>
+    </div>
+
+    <van-loading v-if="loading" />
+    <div v-else-if="transactions.length === 0" class="empty">
+      当天暂无交易
+    </div>
+    <div v-else class="list">
+      <div
+        v-for="txn in transactions"
+        :key="txn.id"
+        class="item"
+        @click="handleClick(txn)"
+      >
+        <!-- 交易卡片内容 -->
+      </div>
+    </div>
+  </div>
+</template>
+
+<script setup>
+import { ref, watch } from 'vue'
+import { getTransactionsByDate } from '@/api/transactionRecord'
+
+const props = defineProps({
+  selectedDate: Date
+})
+
+// ✅ 向父组件发送事件
+const emit = defineEmits(['transactionClick'])
+
+// ✅ 模块自己管理数据
+const transactions = ref([])
+const loading = ref(false)
+
+// ✅ 模块自己调用 API
+const fetchTransactions = async (date) => {
+  try {
+    loading.value = true
+    const dateKey = formatDate(date)
+    const response = await getTransactionsByDate(dateKey)
+    
+    if (response.success) {
+      transactions.value = response.data.map(txn => ({
+        id: txn.id,
+        name: txn.reason || '未知交易',
+        amount: formatAmount(txn.amount, txn.type),
+        time: formatTime(txn.occurredAt),
+        type: txn.type
+      }))
+    }
+  } finally {
+    loading.value = false
+  }
+}
+
+// ✅ 模块监听 props 变化
+watch(() => props.selectedDate, async (newDate) => {
+  if (newDate) {
+    await fetchTransactions(newDate)
+  }
+}, { immediate: true })
+
+// ✅ 模块处理内部事件
+const handleClick = (txn) => {
+  // 向父组件发送事件,由父组件决定跳转逻辑
+  emit('transactionClick', txn)
+}
+
+// ✅ 模块内部工具函数
+const formatDate = (date) => { /* ... */ }
+const formatAmount = (amount, type) => { /* ... */ }
+const formatTime = (datetime) => { /* ... */ }
+</script>
+```
+
+**模块化的好处:**
+- ✅ **关注点分离**:Index 只管布局和编排,模块专注业务逻辑
+- ✅ **独立维护**:修改某个模块不影响其他模块
+- ✅ **可复用性**:模块可以在其他页面复用
+- ✅ **可测试性**:每个模块可以独立测试
+- ✅ **代码清晰**:职责明确,代码结构清晰
+
+**反模式(不要这样做):**
+```vue
+<!-- ❌ 错误:Index.vue 包含所有逻辑 -->
+<template>
+  <div>
+    <!-- 日历 -->
+    <div class="calendar">
+      <!-- 几百行日历代码 -->
+    </div>
+    
+    <!-- 统计 -->
+    <div class="stats">
+      <!-- 统计代码 -->
+    </div>
+    
+    <!-- 交易列表 -->
+    <div class="transactions">
+      <!-- 交易列表代码 -->
+    </div>
+  </div>
+</template>
+
+<script setup>
+// ❌ 所有 API 调用都在 Index.vue
+const calendarData = ref([])
+const statsData = ref({})
+const transactions = ref([])
+
+const fetchCalendarData = async () => { /* ... */ }
+const fetchStatsData = async () => { /* ... */ }
+const fetchTransactions = async () => { /* ... */ }
+
+// ❌ Index.vue 变得又长又难维护
+</script>
+```
+
+**什么时候需要模块化?**
+- 页面有 3 个以上独立功能区域
+- 每个区域有自己的数据查询需求
+- 页面代码超过 300 行
+- 功能区域可能被其他页面复用
+
+**什么时候不需要模块化?**
+- 简单页面(如登录页、详情页)
+- 只有一个主要功能
+- 代码少于 200 行
+- 无明显的功能分区
+
+### 1. **数据优先,提前确认**
+
+在开始编码前,**必须先确认数据表结构**:
+
+**检查清单:**
+- [ ] 读取 .pen 设计文件,理解所有数据需求
+- [ ] 检查现有 Entity 层,确认是否支持设计需求
+- [ ] 如果需要新增字段/表/枚举值,**先询问用户确认**
+- [ ] 列出所有数据变更,等待用户批准后再继续
+
+**示例确认流程:**
+```markdown
+## 数据表结构确认
+
+根据设计图分析,需要以下数据支持:
+
+### 现有实体:
+✅ TransactionRecord - 支持交易记录
+✅ BudgetRecord - 支持预算管理
+✅ TransactionCategory - 支持分类
+
+### 需要变更:
+1. **TransactionCategory 表新增字段**
+   - 字段名: IconName (string)
+   - 用途: 存储 lucide 图标名称(如 "utensils"、"shopping-cart")
+   - 原因: 设计图使用图标名称渲染,现有 Icon 字段存储 SVG 不适合
+
+2. **BudgetRecord 新增计算字段**
+   - 字段名: ProgressPercentage (decimal, 计算属性)
+   - 用途: 当前支出占预算的百分比
+   - 原因: 设计图显示进度条需要
+
+### 是否批准以上变更?如不批准,请提供替代方案。
+```
+
+**不得做:**
+- ❌ 未经确认直接修改 Entity 层
+- ❌ 假设字段存在而不检查
+- ❌ 跳过数据表确认直接实施前端
+
+### 2. **交互细节,逐一确认**
+
+设计图无法表达所有交互逻辑,**必须向用户确认**:
+
+**需要确认的交互:**
+1. **按钮点击行为**
+   - 跳转到哪个页面?
+   - 弹出什么对话框?
+   - 触发什么 API?
+
+2. **周期切换逻辑**(如周/月/年)
+   - 周:本周一到周日?还是最近7天?
+   - 月:自然月?还是最近30天?
+   - 年:当年1-12月?还是最近12个月?
+
+3. **数据计算逻辑**
+   - 环比百分比如何计算?
+   - 趋势图数据范围?
+   - 空状态显示什么?
+
+4. **跳转目标**
+   - "查看全部"跳转到哪里?
+   - "管理预算"跳转到哪个页面?
+   - 通知按钮打开什么?
+
+**示例确认:**
+```markdown
+## 交互行为确认
+
+### 1. 顶部通知按钮
+设计图:bell 图标按钮
+**问题:** 点击后跳转到哪里?
+- A. 消息中心(MessageView.vue)
+- B. 通知列表(新页面)
+- C. 弹出通知面板
+
+### 2. 周期切换(周/月/年)
+设计图:三个 segment 切换按钮
+**问题:** 周期定义?
+- 周:本周一到周日 or 最近7天
+- 月:当前自然月 or 最近30天
+- 年:当年1-12月 or 最近12个月
+
+### 3. 核心指标徽章(如 "-15%")
+设计图:显示百分比变化
+**问题:** 对比哪个周期?
+- A. 与上一周期对比(上周/上月/去年)
+- B. 与同期对比(去年同周/去年同月)
+- C. 与预算目标对比
+
+请明确以上交互逻辑。
+```
+
+### 3. **高度还原设计稿**
+
+**视觉还原标准:**
+- 严格按照设计图的间距、字号、颜色、圆角
+- 使用设计图中的实际字体(如 DM Sans, Bricolage Grotesque, JetBrains Mono)
+- 匹配卡片阴影、边框样式
+- 复现设计图的布局层级
+
+**对照检查:**
+```typescript
+// 设计图:
+// - padding: 24px
+// - gap: 16px
+// - cornerRadius: 12px
+// - fontSize: 14px
+// - fontWeight: 600
+
+// 实现:
+<div class="metrics-card">
+  <style scoped>
+  .metrics-card {
+    padding: 24px;        /* ✅ 匹配设计 */
+    gap: 16px;            /* ✅ 匹配设计 */
+    border-radius: 12px;  /* ✅ 匹配设计 */
+    font-size: 14px;      /* ✅ 匹配设计 */
+    font-weight: 600;     /* ✅ 匹配设计 */
+  }
+  </style>
+</div>
+```
+
+**字体映射:**
+| 设计图字体 | CSS 实现 |
+|-----------|---------|
+| Bricolage Grotesque | `font-family: 'Bricolage Grotesque', system-ui, sans-serif` |
+| DM Sans | `font-family: 'DM Sans', -apple-system, sans-serif` |
+| JetBrains Mono | `font-family: 'JetBrains Mono', 'SF Mono', monospace` |
+| Newsreader | `font-family: 'Newsreader', Georgia, serif` |
+
+### 4. **前后端同步开发**
+
+**开发顺序:**
+```
+1. 确认数据表 → 2. 开发后端 API → 3. 实施前端组件 → 4. 集成测试 → 5. 视觉验证
+```
+
+**后端开发标准:**
+- 在 `Entity/` 中新增/修改实体
+- 在 `Repository/` 中添加数据访问方法
+- 在 `Service/` 中实现业务逻辑
+- 在 `WebApi/Controllers/` 中创建 API 端点
+- 编写 xUnit 测试验证逻辑
+
+**前端开发标准:**
+- 在 `Web/src/views/` 中创建/修改页面组件
+- 在 `Web/src/components/` 中提取可复用组件
+- 在 `Web/src/api/` 中定义 API 客户端
+- 使用 Vue 3 Composition API + `<script setup>`
+- 使用 Vant UI 组件库
+- 严格遵循设计图的样式(SCSS)
+
+### 5. **测试与验证**
+
+**验证清单:**
+- [ ] 后端测试通过(`dotnet test`)
+- [ ] 前端构建通过(`pnpm build`)
+- [ ] API 返回数据正确
+- [ ] 页面显示与设计图一致
+- [ ] 交互行为符合确认的逻辑
+- [ ] 亮色/暗色主题都正常
+- [ ] 空状态、加载状态、错误状态处理
+
+## 实施工作流程
+
+### 阶段 1: 设计分析与数据确认
+
+```typescript
+// 1. 读取设计文件
+pencil_batch_get(
+  filePath: ".pans/v2.pen",
+  nodeIds: ["jF3SD"], // 设计图根节点 ID
+  readDepth: 3
+)
+
+// 2. 分析数据需求
+// - 列出所有显示的数据字段
+// - 检查现有 Entity 是否支持
+// - 列出需要新增的字段/表
+
+// 3. 读取现有实体
+glob("Entity/*.cs")
+read("Entity/TransactionRecord.cs")
+read("Entity/BudgetRecord.cs")
+read("Entity/TransactionCategory.cs")
+
+// 4. 向用户确认数据变更
+// (生成确认清单,等待用户批准)
+```
+
+### 阶段 2: 交互逻辑确认
+
+```markdown
+## 交互确认清单
+
+根据设计图,以下交互需要确认:
+
+### 1. [按钮/链接名称]
+**位置:** [设计图位置描述]
+**问题:** [需要确认的问题]
+**选项:**
+- A. [选项1]
+- B. [选项2]
+- C. [其他]
+
+### 2. [数据计算逻辑]
+**显示内容:** [设计图显示的数据]
+**问题:** [计算逻辑或数据来源]
+**选项:**
+- A. [选项1]
+- B. [选项2]
+
+请逐一明确以上交互。
+```
+
+### 阶段 3: 后端开发
+
+**3.1 实体层变更(如需要)**
+```csharp
+// Entity/TransactionCategory.cs
+namespace Entity;
+
+/// <summary>
+/// 交易分类
+/// </summary>
+public class TransactionCategory : BaseEntity
+{
+    /// <summary>
+    /// 分类名称
+    /// </summary>
+    public string Name { get; set; } = string.Empty;
+
+    /// <summary>
+    /// 交易类型(支出/收入)
+    /// </summary>
+    public TransactionType Type { get; set; }
+
+    /// <summary>
+    /// 图标名称(lucide 图标,如 "utensils", "shopping-cart")
+    /// </summary>
+    public string? IconName { get; set; }
+    
+    // 现有 Icon 字段保留用于自定义 SVG
+    [Column(StringLength = -1)]
+    public string? Icon { get; set; }
+}
+```
+
+**3.2 Repository 扩展(如需要)**
+```csharp
+// Repository/ITransactionRepository.cs
+public interface ITransactionRepository
+{
+    Task<List<WeeklyStatisticsDto>> GetWeeklyStatisticsAsync(
+        int year, int weekNumber);
+    
+    Task<ComparisonDto> GetComparisonDataAsync(
+        int year, int month, PeriodType periodType);
+}
+```
+
+**3.3 Controller API**
+```csharp
+// WebApi/Controllers/TransactionRecordController.cs
+
+/// <summary>
+/// 获取周统计数据
+/// </summary>
+[HttpGet("GetWeeklyStatistics")]
+public async Task<BaseResponse<WeeklyStatisticsDto>> GetWeeklyStatistics(
+    [FromQuery] int year, 
+    [FromQuery] int weekNumber)
+{
+    var data = await _repository.GetWeeklyStatisticsAsync(year, weekNumber);
+    return BaseResponse<WeeklyStatisticsDto>.Success(data);
+}
+```
+
+**3.4 测试**
+```csharp
+// WebApi.Test/TransactionStatisticsTest.cs
+[Fact]
+public async Task GetWeeklyStatistics_本周_返回正确数据()
+{
+    // Arrange
+    var testData = CreateTestWeeklyData();
+    _repo.GetWeeklyStatisticsAsync(2026, 5).Returns(testData);
+    
+    // Act
+    var result = await _controller.GetWeeklyStatistics(2026, 5);
+    
+    // Assert
+    result.Success.Should().BeTrue();
+    result.Data.TotalExpense.Should().Be(1248.50m);
+    result.Data.TransactionCount.Should().Be(127);
+}
+```
+
+### 阶段 4: 前端开发
+
+**4.1 API 客户端**
+```javascript
+// Web/src/api/statistics.js
+
+/**
+ * 获取周统计数据
+ * @param {Object} params - 查询参数
+ * @param {number} params.year - 年份
+ * @param {number} params.weekNumber - 周数(1-53)
+ * @returns {Promise<{success: boolean, data: Object}>}
+ */
+export const getWeeklyStatistics = (params) => {
+  return request({
+    url: '/TransactionRecord/GetWeeklyStatistics',
+    method: 'get',
+    params
+  })
+}
+```
+
+**4.2 Vue 组件实现**
+```vue
+<!-- Web/src/views/StatisticsOverview.vue -->
+<template>
+  <div class="statistics-overview">
+    <!-- 按照设计图的结构实现 -->
+    <van-nav-bar placeholder>
+      <template #title>
+        <div class="nav-title">2026年</div>
+      </template>
+      <template #right>
+        <van-icon name="bell-o" size="20" @click="handleNotification" />
+      </template>
+    </van-nav-bar>
+
+    <div class="content-wrapper">
+      <!-- 周期切换 -->
+      <div class="period-section">
+        <div class="segment-control">
+          <div 
+            class="segment-item"
+            :class="{ active: period === 'week' }"
+            @click="period = 'week'"
+          >
+            周
+          </div>
+          <div 
+            class="segment-item"
+            :class="{ active: period === 'month' }"
+            @click="period = 'month'"
+          >
+            月
+          </div>
+          <div 
+            class="segment-item"
+            :class="{ active: period === 'year' }"
+            @click="period = 'year'"
+          >
+            年
+          </div>
+        </div>
+      </div>
+
+      <!-- 核心指标 -->
+      <div class="metrics-section">
+        <h3 class="section-header">核心指标</h3>
+        <div class="metrics-row">
+          <!-- 总支出卡片 -->
+          <div class="metric-card">
+            <div class="card-header">
+              <span class="label">总支出</span>
+              <span class="badge expense">-15%</span>
+            </div>
+            <div class="value">¥{{ formatMoney(stats.totalExpense) }}</div>
+            <div class="description">较上期减少</div>
+          </div>
+
+          <!-- 交易笔数卡片 -->
+          <div class="metric-card">
+            <div class="card-header">
+              <span class="label">交易笔数</span>
+              <span class="badge success">+8</span>
+            </div>
+            <div class="value">{{ stats.transactionCount }}</div>
+            <div class="chart-bars">
+              <!-- 7天趋势小图 -->
+              <div 
+                v-for="(bar, index) in stats.weeklyBars" 
+                :key="index"
+                class="bar"
+                :style="{ height: bar.height + 'px' }"
+              />
+            </div>
+          </div>
+        </div>
+      </div>
+
+### 4.2 模块化开发示例 (High Cohesion)
+
+**A. 编排层 (Orchestrator)**
+`src/views/Statistics/Index.vue`
+- **职责**:只负责布局结构和子模块引用,**不**包含具体业务逻辑或 API 调用。
+- **结构**:干净的 `<template>` 包含各个 Modules。
+
+```vue
+<template>
+  <div class="statistics-view">
+    <van-nav-bar title="统计概览" left-arrow @click-left="onClickLeft" />
+    
+    <div class="content-wrapper">
+      <!-- 模块 1: 核心指标卡片 -->
+      <MetricsCard />
+      
+      <!-- 模块 2: 趋势图表 -->
+      <TrendChart />
+      
+      <!-- 模块 3: 分类占比 -->
+      <CategoryPie />
+    </div>
+  </div>
+</template>
+
+<script setup>
+import { useRouter } from 'vue-router'
+// 导入子模块
+import MetricsCard from './modules/MetricsCard.vue'
+import TrendChart from './modules/TrendChart.vue'
+import CategoryPie from './modules/CategoryPie.vue'
+
+const router = useRouter()
+const onClickLeft = () => router.back()
+</script>
+
+<style scoped lang="scss">
+.statistics-view {
+  min-height: 100vh;
+  background: var(--van-background-2);
+}
+
+.content-wrapper {
+  padding: 16px;
+  display: flex;
+  flex-direction: column;
+  gap: 16px;
+}
+</style>
+```
+
+**B. 业务模块 (Business Module)**
+`src/views/Statistics/modules/MetricsCard.vue`
+- **职责**:独立负责特定功能区域的 UI 和数据获取。
+- **原则**:自包含 (Self-contained) - 自己 import api,自己 fetch data。
+
+```vue
+<template>
+  <div class="metrics-card">
+    <!-- 周期切换 -->
+    <div class="segment-control">
+      <div 
+        v-for="p in periods" 
+        :key="p.value"
+        class="segment-item"
+        :class="{ active: currentPeriod === p.value }"
+        @click="currentPeriod = p.value"
+      >
+        {{ p.label }}
+      </div>
+    </div>
+
+    <!-- 数据展示 -->
+    <div class="metrics-content">
+      <div class="label">总支出</div>
+      <div class="value">¥{{ formatMoney(stats.totalExpense) }}</div>
+      
+      <div class="chart-bars">
+        <div 
+          v-for="(bar, index) in stats.weeklyBars" 
+          :key="index"
+          class="bar"
+          :style="{ height: bar.height + 'px' }"
+        />
+      </div>
+    </div>
+  </div>
+</template>
+
+<script setup>
+import { ref, onMounted, watch } from 'vue'
+import { getWeeklyStatistics } from '@/api/statistics' // 模块自己请求数据
+
+const periods = [
+  { label: '周', value: 'week' },
+  { label: '月', value: 'month' }
+]
+const currentPeriod = ref('week')
+const stats = ref({ totalExpense: 0, weeklyBars: [] })
+
+const fetchData = async () => {
+  const res = await getWeeklyStatistics({ period: currentPeriod.value })
+  if (res.success) {
+    stats.value = res.data
+  }
+}
+
+// 监听周期变化自动刷新
+watch(currentPeriod, fetchData)
+
+onMounted(fetchData)
+
+const formatMoney = (val) => Number(val).toFixed(2)
+</script>
+
+<style scoped lang="scss">
+.metrics-card {
+  background: #fff;
+  border-radius: 12px;
+  padding: 16px;
+  
+  // 严格按照设计图实现内部样式
+  .value {
+    font-family: 'JetBrains Mono', monospace;
+    font-size: 24px;
+    font-weight: bold;
+    margin: 12px 0;
+  }
+  
+  // 暗色模式适配
+  @media (prefers-color-scheme: dark) {
+    background: #1c1c1e;
+    .value { color: #fff; }
+  }
+}
+</style>
+```
+
+### 阶段 5: 集成测试与验证
+
+**5.1 运行测试**
+```bash
+# 后端测试
+dotnet test WebApi.Test/WebApi.Test.csproj
+
+# 前端构建
+cd Web
+pnpm lint
+pnpm build
+```
+
+**5.2 视觉验证**
+```typescript
+// 使用 pencil 截图对比
+pencil_get_screenshot(nodeId: "jF3SD") // 设计图截图
+
+// 在浏览器中截图实际效果
+// 对比以下方面:
+// - 间距是否一致(padding, gap)
+// - 字号是否匹配(fontSize)
+// - 颜色是否准确(fill, textColor)
+// - 圆角是否正确(cornerRadius)
+// - 布局是否对齐(layout, justifyContent, alignItems)
+```
+
+**5.3 交互验证**
+- [ ] 周期切换按钮工作正常
+- [ ] 核心指标数据正确显示
+- [ ] 徽章百分比计算准确
+- [ ] 点击卡片跳转正确
+- [ ] 空状态显示合理
+- [ ] 加载状态流畅
+- [ ] 错误处理友好
+
+## 避免的反模式
+
+### ❌ 不要这样做:
+
+**1. 未经确认修改数据表**
+```csharp
+// ❌ 直接新增字段
+public class TransactionCategory : BaseEntity
+{
+    public string IconName { get; set; } // ❌ 未经用户确认
+}
+```
+
+**2. 猜测交互逻辑**
+```vue
+// ❌ 假设跳转目标
+<van-icon @click="router.push('/notifications')" /> 
+<!-- ❌ 未确认通知按钮跳转到哪里 -->
+```
+
+**3. 不按设计图样式**
+```scss
+// 设计图: padding: 24px
+.card {
+  padding: 20px; // ❌ 不匹配设计
+}
+```
+
+**4. 跳过测试**
+```bash
+# ❌ 不运行测试直接提交
+git add .
+git commit -m "完成实施"
+```
+
+**5. 忽略暗色模式**
+```scss
+.card {
+  background: #FFFFFF; // ❌ 只实现亮色模式
+}
+```
+
+### ✅ 应该这样做:
+
+**1. 数据变更先确认**
+```markdown
+## 数据表变更请求
+
+需要在 TransactionCategory 新增以下字段:
+- IconName (string): 存储图标名称
+- 用途: 前端渲染 lucide 图标
+
+是否批准?
+```
+
+**2. 交互逻辑先确认**
+```markdown
+## 交互确认
+
+通知按钮点击后:
+- A. 跳转到 MessageView
+- B. 弹出通知列表
+- C. 其他
+
+请明确选择。
+```
+
+**3. 严格按照设计图**
+```scss
+// 设计图: padding: 24px, gap: 16px, borderRadius: 12px
+.card {
+  padding: 24px;        // ✅ 匹配设计
+  gap: 16px;            // ✅ 匹配设计
+  border-radius: 12px;  // ✅ 匹配设计
+}
+```
+
+**4. 完整测试**
+```bash
+# ✅ 运行所有测试
+dotnet test
+cd Web && pnpm lint && pnpm build
+```
+
+**5. 支持暗色模式**
+```scss
+.card {
+  background: #FFFFFF;
+
+  @media (prefers-color-scheme: dark) {
+    background: #18181B; // ✅ 暗色适配
+  }
+}
+```
+
+## 委派与任务管理
+
+**使用此技能时:**
+
+```typescript
+delegate_task(
+  category: "visual-engineering",
+  load_skills: ["pancli-implement", "frontend-ui-ux"],
+  description: "根据 v2.pen 设计图实施统计概览页面",
+  prompt: `
+    ## 任务
+    根据 .pans/v2.pen 中的统计概览设计图(节点 ID: jF3SD)实施完整的前后端功能
+    
+    ## 预期结果
+    - [ ] Entity 层变更(如需要,经用户确认)
+    - [ ] 后端 API 开发并通过测试
+    - [ ] 前端页面高度还原设计图
+    - [ ] 交互逻辑符合用户确认
+    - [ ] 亮色/暗色主题都正常
+    - [ ] 所有测试通过(dotnet test, pnpm build)
+    
+    ## 必需工具
+    - pencil_batch_get: 读取设计文件
+    - pencil_get_screenshot: 设计图截图
+    - read: 读取现有代码
+    - glob: 查找文件
+    - edit/write: 修改/新增代码
+    - bash: 运行测试
+    
+    ## 必须做
+    1. **数据确认阶段**
+       - 读取设计文件分析数据需求
+       - 检查现有 Entity 是否支持
+       - 如需变更,生成确认清单并等待用户批准
+    
+    2. **交互确认阶段**
+       - 列出所有不确定的交互逻辑
+       - 生成确认清单并等待用户明确
+    
+    3. **后端开发**
+       - 按用户批准修改 Entity
+       - 实现 Repository 数据访问
+       - 创建 Controller API
+       - 编写 xUnit 测试并通过
+    
+    4. **前端开发**
+       - **复杂页面强制模块化**: 采用 Index.vue + modules/ 结构
+       - Index.vue 仅编排,modules 负责数据获取
+       - 定义 API 客户端(src/api/)
+       - 严格按照设计图样式(间距、字号、颜色、圆角)
+       - 使用设计图中的实际字体
+       - 支持亮色/暗色主题
+    
+    5. **验证阶段**
+       - 运行后端测试:dotnet test
+       - 运行前端构建:pnpm lint && pnpm build
+       - 视觉对比设计图截图
+       - 验证交互逻辑
+    
+    ## 不得做
+    - ❌ 未经确认直接修改 Entity
+    - ❌ 猜测交互逻辑而不询问
+    - ❌ 禁止复杂页面写成单文件组件 (Monolithic)
+    - ❌ 不按设计图样式随意实现
+    - ❌ 跳过测试
+    - ❌ 忽略暗色模式
+    - ❌ 使用占位数据而不调用真实 API
+    
+    ## 上下文
+    - 设计文件: .pans/v2.pen
+    - 设计节点 ID: jF3SD (Statistics - Overview - Light)
+    - 现有页面: Web/src/views/StatisticsView.vue
+    - 现有 API: Web/src/api/statistics.js
+    - Entity 层: Entity/*.cs
+    - Controller 层: WebApi/Controllers/*.cs
+    
+    ## 实施流程
+    1. 数据确认 → 等待批准
+    2. 交互确认 → 等待明确
+    3. 后端开发 → 测试通过
+    4. 前端开发 → 视觉验证
+    5. 集成测试 → 全部通过
+  `,
+  run_in_background: false
+)
+```
+
+## 快速参考
+
+### 数据表确认模板
+
+```markdown
+## 数据表结构确认
+
+### 现有实体分析
+✅ [实体名] - 支持 [功能]
+❌ [实体名] - 缺少 [字段]
+
+### 需要变更
+1. **[表名] 新增字段**
+   - 字段名: [字段名] ([类型])
+   - 用途: [用途说明]
+   - 原因: [为什么需要]
+
+2. **[表名] 修改字段**
+   - 字段名: [字段名]
+   - 变更: [原类型] → [新类型]
+   - 原因: [为什么修改]
+
+### 是否批准?
+```
+
+### 交互确认模板
+
+```markdown
+## 交互逻辑确认
+
+### 1. [交互元素名称]
+**设计位置:** [描述]
+**问题:** [需要确认的问题]
+**选项:**
+- A. [选项1]
+- B. [选项2]
+- C. 其他:[请说明]
+
+### 2. [数据计算逻辑]
+**设计显示:** [设计图显示的内容]
+**问题:** [计算逻辑或数据来源]
+**选项:**
+- A. [选项1]
+- B. [选项2]
+
+请逐一明确。
+```
+
+### 样式映射表
+
+| 设计图属性 | CSS 属性 | 示例 |
+|-----------|---------|------|
+| padding | padding | `padding: 24px` |
+| gap | gap | `gap: 16px` |
+| cornerRadius | border-radius | `border-radius: 12px` |
+| fill | background | `background: #FFFFFF` |
+| textColor | color | `color: #1A1A1A` |
+| fontSize | font-size | `font-size: 14px` |
+| fontWeight | font-weight | `font-weight: 600` |
+| fontFamily | font-family | `font-family: 'DM Sans', sans-serif` |
+| width: "fill_container" | width: 100% | `width: 100%` |
+| height: "hug_contents" | height: auto | `height: auto` |
+| layout: "vertical" | flex-direction: column | `flex-direction: column` |
+| layout: "horizontal" | flex-direction: row | `flex-direction: row` |
+| justifyContent: "space_between" | justify-content: space-between | `justify-content: space-between` |
+| alignItems: "center" | align-items: center | `align-items: center` |
+
+---
+
+**版本:** 1.0.0  
+**最后更新:** 2026-02-03  
+**维护者:** EmailBill 开发团队
diff --git a/Application/Dto/HolidayDto.cs b/Application/Dto/HolidayDto.cs
new file mode 100644
index 0000000..b6d0721
--- /dev/null
+++ b/Application/Dto/HolidayDto.cs
@@ -0,0 +1,32 @@
+namespace Application.Dto;
+
+/// <summary>
+/// 节假日数据传输对象
+/// </summary>
+public class HolidayDto
+{
+    /// <summary>
+    /// 日期（yyyy-MM-dd格式）
+    /// </summary>
+    public string Date { get; set; } = string.Empty;
+
+    /// <summary>
+    /// 节假日名称（如：春节、国庆节）
+    /// </summary>
+    public string HolidayName { get; set; } = string.Empty;
+
+    /// <summary>
+    /// 日期类型：1=节假日放假，3=调休工作日
+    /// </summary>
+    public int DayType { get; set; }
+
+    /// <summary>
+    /// 是否休息：1=休息，0=工作
+    /// </summary>
+    public int Rest { get; set; }
+
+    /// <summary>
+    /// 星期描述（中文）
+    /// </summary>
+    public string WeekDescCn { get; set; } = string.Empty;
+}
diff --git a/Application/EmailMessageApplication.cs b/Application/EmailMessageApplication.cs
index 5626993..b19cd8a 100644
--- a/Application/EmailMessageApplication.cs
+++ b/Application/EmailMessageApplication.cs
@@ -41,8 +41,7 @@ public class EmailMessageApplication(
     IEmailMessageRepository emailRepository,
     ITransactionRecordRepository transactionRepository,
     IEmailHandleService emailHandleService,
-    IEmailSyncService emailSyncService,
-    ILogger<EmailMessageApplication> logger
+    IEmailSyncService emailSyncService
 ) : IEmailMessageApplication
 {
     public async Task<EmailPagedResult> GetListAsync(EmailQueryRequest request)
diff --git a/Application/Extensions/ServiceCollectionExtensions.cs b/Application/Extensions/ServiceCollectionExtensions.cs
index 77f1a82..2baaf75 100644
--- a/Application/Extensions/ServiceCollectionExtensions.cs
+++ b/Application/Extensions/ServiceCollectionExtensions.cs
@@ -29,6 +29,11 @@ public static class ServiceCollectionExtensions
             {
                 services.AddScoped(interfaceType, implementationType);
             }
+            else
+            {
+                // 如果没有接口，直接注册实现类
+                services.AddScoped(implementationType);
+            }
         }
 
         return services;
diff --git a/Application/HolidayApplication.cs b/Application/HolidayApplication.cs
new file mode 100644
index 0000000..5f14d20
--- /dev/null
+++ b/Application/HolidayApplication.cs
@@ -0,0 +1,35 @@
+namespace Application;
+
+/// <summary>
+/// 节假日应用服务
+/// </summary>
+public class HolidayApplication(IHolidayService holidayService)
+{
+    /// <summary>
+    /// 获取指定年月的节假日数据
+    /// </summary>
+    public async Task<List<HolidayDto>> GetMonthHolidaysAsync(int year, int month)
+    {
+        var startDate = new DateTime(year, month, 1).ToString("yyyy-MM-dd");
+        var endDate = new DateTime(year, month, DateTime.DaysInMonth(year, month)).ToString("yyyy-MM-dd");
+
+        var holidays = await holidayService.GetHolidaysByDateRangeAsync(startDate, endDate);
+
+        return holidays.Select(h => new HolidayDto
+        {
+            Date = h.Date,
+            HolidayName = h.HolidayName,
+            DayType = h.DayType,
+            Rest = h.Rest,
+            WeekDescCn = h.WeekDescCn
+        }).ToList();
+    }
+
+    /// <summary>
+    /// 手动触发同步节假日数据
+    /// </summary>
+    public async Task<bool> SyncHolidaysAsync(int year)
+    {
+        return await holidayService.FetchAndCacheHolidaysAsync(year);
+    }
+}
diff --git a/Application/JobApplication.cs b/Application/JobApplication.cs
index 04bb526..d8b81b9 100644
--- a/Application/JobApplication.cs
+++ b/Application/JobApplication.cs
@@ -30,8 +30,7 @@ public interface IJobApplication
 /// 任务应用服务实现
 /// </summary>
 public class JobApplication(
-    ISchedulerFactory schedulerFactory,
-    ILogger<JobApplication> logger
+    ISchedulerFactory schedulerFactory
 ) : IJobApplication
 {
     public async Task<List<JobStatus>> GetJobsAsync()
diff --git a/Application/MessageRecordApplication.cs b/Application/MessageRecordApplication.cs
index 5c8359b..66102d4 100644
--- a/Application/MessageRecordApplication.cs
+++ b/Application/MessageRecordApplication.cs
@@ -43,8 +43,7 @@ public interface IMessageRecordApplication
 /// 消息记录应用服务实现
 /// </summary>
 public class MessageRecordApplication(
-    IMessageService messageService,
-    ILogger<MessageRecordApplication> logger
+    IMessageService messageService
 ) : IMessageRecordApplication
 {
     public async Task<MessagePagedResult> GetListAsync(int pageIndex = 1, int pageSize = 20)
diff --git a/Application/NotificationApplication.cs b/Application/NotificationApplication.cs
index 77627cf..dd6f1b6 100644
--- a/Application/NotificationApplication.cs
+++ b/Application/NotificationApplication.cs
@@ -16,8 +16,7 @@ public interface INotificationApplication
 /// 通知应用服务实现
 /// </summary>
 public class NotificationApplication(
-    INotificationService notificationService,
-    ILogger<NotificationApplication> logger
+    INotificationService notificationService
 ) : INotificationApplication
 {
     public async Task<string> GetVapidPublicKeyAsync()
diff --git a/Application/TransactionApplication.cs b/Application/TransactionApplication.cs
index 744bdc1..0780086 100644
--- a/Application/TransactionApplication.cs
+++ b/Application/TransactionApplication.cs
@@ -99,8 +99,7 @@ public interface ITransactionApplication
 /// </summary>
 public class TransactionApplication(
     ITransactionRecordRepository transactionRepository,
-    ISmartHandleService smartHandleService,
-    ILogger<TransactionApplication> logger
+    ISmartHandleService smartHandleService
 ) : ITransactionApplication
 {
     public async Task<PagedResult<TransactionResponse>> GetListAsync(TransactionQueryRequest request)
diff --git a/Application/TransactionCategoryApplication.cs b/Application/TransactionCategoryApplication.cs
index a23d4c0..5c44f16 100644
--- a/Application/TransactionCategoryApplication.cs
+++ b/Application/TransactionCategoryApplication.cs
@@ -26,8 +26,7 @@ public class TransactionCategoryApplication(
     ITransactionCategoryRepository categoryRepository,
     ITransactionRecordRepository transactionRepository,
     IBudgetRepository budgetRepository,
-    ISmartHandleService smartHandleService,
-    ILogger<TransactionCategoryApplication> logger
+    ISmartHandleService smartHandleService
 ) : ITransactionCategoryApplication
 {
     public async Task<List<CategoryResponse>> GetListAsync(TransactionType? type = null)
diff --git a/Application/TransactionPeriodicApplication.cs b/Application/TransactionPeriodicApplication.cs
index e816e52..e541319 100644
--- a/Application/TransactionPeriodicApplication.cs
+++ b/Application/TransactionPeriodicApplication.cs
@@ -44,8 +44,7 @@ public interface ITransactionPeriodicApplication
 /// </summary>
 public class TransactionPeriodicApplication(
     ITransactionPeriodicRepository periodicRepository,
-    ITransactionPeriodicService periodicService,
-    ILogger<TransactionPeriodicApplication> logger
+    ITransactionPeriodicService periodicService
 ) : ITransactionPeriodicApplication
 {
     public async Task<PeriodicPagedResult> GetListAsync(int pageIndex = 1, int pageSize = 20, string? searchKeyword = null)
diff --git a/Application/TransactionStatisticsApplication.cs b/Application/TransactionStatisticsApplication.cs
index a5b91a0..6507646 100644
--- a/Application/TransactionStatisticsApplication.cs
+++ b/Application/TransactionStatisticsApplication.cs
@@ -61,8 +61,7 @@ public interface ITransactionStatisticsApplication
 /// </summary>
 public class TransactionStatisticsApplication(
     ITransactionStatisticsService statisticsService,
-    IConfigService configService,
-    ILogger<TransactionStatisticsApplication> logger
+    IConfigService configService
 ) : ITransactionStatisticsApplication
 {
     // === 新统一接口实现 ===
diff --git a/Directory.Packages.props b/Directory.Packages.props
index 25c0912..f462896 100644
--- a/Directory.Packages.props
+++ b/Directory.Packages.props
@@ -1,4 +1,4 @@
-<Project>
+<Project>
   <ItemGroup>
     <!-- Email & MIME Libraries -->
     <PackageVersion Include="FreeSql" Version="3.5.305" />
@@ -13,6 +13,7 @@
     <PackageVersion Include="Microsoft.Extensions.DependencyInjection" Version="10.0.0" />
     <PackageVersion Include="Microsoft.Extensions.DependencyInjection.Abstractions" Version="10.0.0" />
     <PackageVersion Include="Microsoft.Extensions.Hosting.Abstractions" Version="10.0.0" />
+    <PackageVersion Include="Microsoft.Extensions.Http" Version="10.0.0" />
     <PackageVersion Include="Microsoft.Extensions.Logging" Version="10.0.0" />
     <!-- Logging -->
     <PackageVersion Include="Serilog" Version="4.3.0" />
diff --git a/Entity/Holiday.cs b/Entity/Holiday.cs
new file mode 100644
index 0000000..a950a25
--- /dev/null
+++ b/Entity/Holiday.cs
@@ -0,0 +1,49 @@
+namespace Entity;
+
+/// <summary>
+/// 节假日实体
+/// </summary>
+public class Holiday : BaseEntity
+{
+    /// <summary>
+    /// 年份
+    /// </summary>
+    [Column]
+    public int Year { get; set; }
+
+    /// <summary>
+    /// 日期类型：1=节假日放假，3=调休工作日
+    /// </summary>
+    [Column]
+    public int DayType { get; set; }
+
+    /// <summary>
+    /// 节假日名称（如：春节、国庆节）
+    /// </summary>
+    [Column(StringLength = 50)]
+    public string HolidayName { get; set; } = string.Empty;
+
+    /// <summary>
+    /// 是否休息：1=休息，0=工作
+    /// </summary>
+    [Column]
+    public int Rest { get; set; }
+
+    /// <summary>
+    /// 日期（yyyy-MM-dd格式）
+    /// </summary>
+    [Column(StringLength = 10)]
+    public string Date { get; set; } = string.Empty;
+
+    /// <summary>
+    /// 星期几（0=周日，1-6=周一至周六）
+    /// </summary>
+    [Column]
+    public int Week { get; set; }
+
+    /// <summary>
+    /// 星期描述（中文）
+    /// </summary>
+    [Column(StringLength = 10)]
+    public string WeekDescCn { get; set; } = string.Empty;
+}
diff --git a/Repository/HolidayRepository.cs b/Repository/HolidayRepository.cs
new file mode 100644
index 0000000..20ffd14
--- /dev/null
+++ b/Repository/HolidayRepository.cs
@@ -0,0 +1,52 @@
+namespace Repository;
+
+/// <summary>
+/// 节假日仓储接口
+/// </summary>
+public interface IHolidayRepository : IBaseRepository<Holiday>
+{
+    /// <summary>
+    /// 根据年份获取节假日列表
+    /// </summary>
+    Task<List<Holiday>> GetByYearAsync(int year);
+
+    /// <summary>
+    /// 根据日期范围获取节假日列表
+    /// </summary>
+    Task<List<Holiday>> GetByDateRangeAsync(string startDate, string endDate);
+
+    /// <summary>
+    /// 根据年份删除节假日数据（用于刷新）
+    /// </summary>
+    Task<bool> DeleteByYearAsync(int year);
+}
+
+/// <summary>
+/// 节假日仓储实现
+/// </summary>
+public class HolidayRepository(IFreeSql freeSql)
+    : BaseRepository<Holiday>(freeSql), IHolidayRepository
+{
+    public async Task<List<Holiday>> GetByYearAsync(int year)
+    {
+        return await freeSql.Select<Holiday>()
+            .Where(h => h.Year == year)
+            .OrderBy(h => h.Date)
+            .ToListAsync();
+    }
+
+    public async Task<List<Holiday>> GetByDateRangeAsync(string startDate, string endDate)
+    {
+        return await freeSql.Select<Holiday>()
+            .Where(h => h.Date.CompareTo(startDate) >= 0 && h.Date.CompareTo(endDate) <= 0)
+            .OrderBy(h => h.Date)
+            .ToListAsync();
+    }
+
+    public async Task<bool> DeleteByYearAsync(int year)
+    {
+        return await freeSql.Delete<Holiday>()
+            .Where(h => h.Year == year)
+            .ExecuteAffrowsAsync() > 0;
+    }
+}
diff --git a/Service/Budget/BudgetSavingsService.cs b/Service/Budget/BudgetSavingsService.cs
index 0772142..e8d72a6 100644
--- a/Service/Budget/BudgetSavingsService.cs
+++ b/Service/Budget/BudgetSavingsService.cs
@@ -827,6 +827,14 @@ public class BudgetSavingsService(
         var savingsCategories = await configService.GetConfigByKeyAsync<string>("SavingsCategories") ?? string.Empty;
 
         var currentActual = 0m;
+        
+        // 1. 先累加已归档月份的存款金额
+        if (archiveSavingsItems.Any())
+        {
+            currentActual += archiveSavingsItems.Sum(i => i.current);
+        }
+
+        // 2. 再累加当前月的存款金额
         if (!string.IsNullOrEmpty(savingsCategories))
         {
             var cats = new HashSet<string>(savingsCategories.Split(',', StringSplitOptions.RemoveEmptyEntries));
@@ -839,6 +847,7 @@ public class BudgetSavingsService(
             }
         }
 
+
         var record = new BudgetRecord
         {
             Id = -1,
diff --git a/Service/GlobalUsings.cs b/Service/GlobalUsings.cs
index cb6c8b8..52367cb 100644
--- a/Service/GlobalUsings.cs
+++ b/Service/GlobalUsings.cs
@@ -1,4 +1,4 @@
-global using Repository;
+global using Repository;
 global using Microsoft.Extensions.DependencyInjection;
 global using Microsoft.Extensions.Logging;
 global using System.Text.RegularExpressions;
@@ -14,5 +14,6 @@ global using System.Text.Json.Nodes;
 global using Microsoft.Extensions.Configuration;
 global using Common;
 global using System.Net;
+global using System.Net.Http;
 global using System.Text.Encodings.Web;
 global using JetBrains.Annotations;
\ No newline at end of file
diff --git a/Service/HolidayService.cs b/Service/HolidayService.cs
new file mode 100644
index 0000000..25b3b8e
--- /dev/null
+++ b/Service/HolidayService.cs
@@ -0,0 +1,130 @@
+using System.Text.Json.Serialization;
+
+namespace Service;
+
+/// <summary>
+/// 节假日服务接口
+/// </summary>
+public interface IHolidayService
+{
+    /// <summary>
+    /// 从API获取并缓存节假日数据
+    /// </summary>
+    Task<bool> FetchAndCacheHolidaysAsync(int year);
+
+    /// <summary>
+    /// 获取指定年份的节假日数据
+    /// </summary>
+    Task<List<Holiday>> GetHolidaysByYearAsync(int year);
+
+    /// <summary>
+    /// 获取指定日期范围的节假日数据
+    /// </summary>
+    Task<List<Holiday>> GetHolidaysByDateRangeAsync(string startDate, string endDate);
+}
+
+/// <summary>
+/// 节假日服务实现
+/// </summary>
+public class HolidayService(
+    IHolidayRepository holidayRepository,
+    IHttpClientFactory httpClientFactory,
+    ILogger<HolidayService> logger) : IHolidayService
+{
+    private const string HolidayApiUrl = "https://publicapi.xiaoai.me/holiday/year";
+
+    public async Task<bool> FetchAndCacheHolidaysAsync(int year)
+    {
+        try
+        {
+            logger.LogInformation("开始获取 {Year} 年节假日数据", year);
+
+            // 调用API获取数据
+            var httpClient = httpClientFactory.CreateClient();
+            var response = await httpClient.GetStringAsync($"{HolidayApiUrl}?date={year}");
+
+            // 解析JSON
+            var apiResponse = JsonSerializer.Deserialize<HolidayApiResponse>(response);
+            if (apiResponse?.Code != 0 || apiResponse.Data == null)
+            {
+                logger.LogError("获取节假日数据失败: {Message}", apiResponse?.Msg);
+                return false;
+            }
+
+            // 删除旧数据
+            await holidayRepository.DeleteByYearAsync(year);
+
+            // 转换并保存新数据
+            var holidays = apiResponse.Data.Select(item => new Holiday
+            {
+                Year = year,
+                DayType = item.DayType,
+                HolidayName = item.Holiday,
+                Rest = item.Rest,
+                Date = item.Date,
+                Week = item.Week,
+                WeekDescCn = item.WeekDescCn
+            }).ToList();
+
+            await holidayRepository.AddRangeAsync(holidays);
+
+            logger.LogInformation("成功缓存 {Count} 条节假日数据", holidays.Count);
+            return true;
+        }
+        catch (Exception ex)
+        {
+            // 静默失败，仅记录日志
+            logger.LogError(ex, "获取并缓存节假日数据失败");
+            return false;
+        }
+    }
+
+    public async Task<List<Holiday>> GetHolidaysByYearAsync(int year)
+    {
+        return await holidayRepository.GetByYearAsync(year);
+    }
+
+    public async Task<List<Holiday>> GetHolidaysByDateRangeAsync(string startDate, string endDate)
+    {
+        return await holidayRepository.GetByDateRangeAsync(startDate, endDate);
+    }
+}
+
+/// <summary>
+/// 节假日API响应模型
+/// </summary>
+public class HolidayApiResponse
+{
+    [JsonPropertyName("code")]
+    public int Code { get; set; }
+
+    [JsonPropertyName("msg")]
+    public string Msg { get; set; } = string.Empty;
+
+    [JsonPropertyName("data")]
+    public List<HolidayApiData>? Data { get; set; }
+}
+
+/// <summary>
+/// 节假日API数据模型
+/// </summary>
+public class HolidayApiData
+{
+    [JsonPropertyName("daytype")]
+    public int DayType { get; set; }
+
+    [JsonPropertyName("holiday")]
+    public string Holiday { get; set; } = string.Empty;
+
+    [JsonPropertyName("rest")]
+    public int Rest { get; set; }
+
+    [JsonPropertyName("date")]
+    public string Date { get; set; } = string.Empty;
+
+    [JsonPropertyName("week")]
+    public int Week { get; set; }
+
+    [JsonPropertyName("week_desc_cn")]
+    public string WeekDescCn { get; set; } = string.Empty;
+}
diff --git a/Service/Jobs/HolidaySyncJob.cs b/Service/Jobs/HolidaySyncJob.cs
new file mode 100644
index 0000000..598f445
--- /dev/null
+++ b/Service/Jobs/HolidaySyncJob.cs
@@ -0,0 +1,45 @@
+using Quartz;
+
+namespace Service.Jobs;
+
+/// <summary>
+/// 节假日同步定时任务 - 每10天执行一次
+/// </summary>
+[DisallowConcurrentExecution] // 防止并发执行
+public class HolidaySyncJob(
+    IServiceProvider serviceProvider,
+    ILogger<HolidaySyncJob> logger) : IJob
+{
+    public async Task Execute(IJobExecutionContext context)
+    {
+        try
+        {
+            logger.LogInformation("开始执行节假日同步任务");
+
+            using var scope = serviceProvider.CreateScope();
+            var holidayService = scope.ServiceProvider.GetRequiredService<IHolidayService>();
+
+            // 获取当前年份和下一年份
+            var currentYear = DateTime.Now.Year;
+            var nextYear = currentYear + 1;
+
+            // 同步当前年和下一年的数据
+            var currentYearResult = await holidayService.FetchAndCacheHolidaysAsync(currentYear);
+            var nextYearResult = await holidayService.FetchAndCacheHolidaysAsync(nextYear);
+
+            if (currentYearResult && nextYearResult)
+            {
+                logger.LogInformation("节假日同步任务执行完成，成功同步 {CurrentYear} 和 {NextYear} 年数据", currentYear, nextYear);
+            }
+            else
+            {
+                logger.LogWarning("节假日同步任务部分失败，当前年: {CurrentResult}, 下一年: {NextResult}", currentYearResult, nextYearResult);
+            }
+        }
+        catch (Exception ex)
+        {
+            logger.LogError(ex, "节假日同步任务执行出错");
+            throw; // 让 Quartz 知道任务失败
+        }
+    }
+}
diff --git a/Service/Service.csproj b/Service/Service.csproj
index a8a3a65..27a7961 100644
--- a/Service/Service.csproj
+++ b/Service/Service.csproj
@@ -1,4 +1,4 @@
-<Project Sdk="Microsoft.NET.Sdk">
+<Project Sdk="Microsoft.NET.Sdk">
 
   <ItemGroup>
     <ProjectReference Include="..\Repository\Repository.csproj" />
@@ -12,6 +12,7 @@
     <PackageReference Include="Microsoft.Extensions.Configuration.Binder" />
     <PackageReference Include="Microsoft.Extensions.DependencyInjection" />
     <PackageReference Include="Microsoft.Extensions.Hosting.Abstractions" />
+    <PackageReference Include="Microsoft.Extensions.Http" />
     <PackageReference Include="Serilog" />
     <PackageReference Include="Serilog.Extensions.Logging" />
     <PackageReference Include="Microsoft.Extensions.Logging" />
diff --git a/Web/src/api/holiday.js b/Web/src/api/holiday.js
new file mode 100644
index 0000000..6abdd01
--- /dev/null
+++ b/Web/src/api/holiday.js
@@ -0,0 +1,23 @@
+import request from './request'
+
+/**
+ * 获取指定年月的节假日数据
+ */
+export function getMonthHolidays (year, month) {
+  return request({
+    url: '/holiday/GetMonthHolidays',
+    method: 'get',
+    params: { year, month }
+  })
+}
+
+/**
+ * 手动触发同步节假日数据
+ */
+export function syncHolidays (year) {
+  return request({
+    url: '/holiday/SyncHolidays',
+    method: 'post',
+    params: { year }
+  })
+}
diff --git a/Web/src/components/GlassBottomNav.vue b/Web/src/components/GlassBottomNav.vue
index 8ed48ce..76e8531 100644
--- a/Web/src/components/GlassBottomNav.vue
+++ b/Web/src/components/GlassBottomNav.vue
@@ -167,7 +167,8 @@ onMounted(() => {
   left: 0;
   right: 0;
   width: 100%;
-  height: 95px;
+  // 基础高度 + 安全区域，确保在PWA中正确贴底
+  height: calc(95px + env(safe-area-inset-bottom, 0px));
   z-index: 1000;
   pointer-events: none;
 }
diff --git a/Web/src/views/BudgetView.vue b/Web/src/views/BudgetView.vue
index 65ad90f..e10a8b1 100644
--- a/Web/src/views/BudgetView.vue
+++ b/Web/src/views/BudgetView.vue
@@ -1,4 +1,4 @@
-<!-- eslint-disable vue/no-v-html -->
+<!-- eslint-disable vue/no-v-html -->
 <template>
   <div class="page-container-flex">
     <van-nav-bar
@@ -156,7 +156,7 @@
               description="暂无存款计划"
             />
           </div>
-          <div style="height: calc(50px + env(safe-area-inset-bottom, 0px))" />
+          <div style="height: calc(95px + env(safe-area-inset-bottom, 0px))" />
         </van-pull-refresh>
       </van-tab>
     </van-tabs>
@@ -417,7 +417,7 @@
             />
           </template>
         </div>
-        <div style="height: calc(50px + env(safe-area-inset-bottom, 0px))" />
+        <div style="height: calc(95px + env(safe-area-inset-bottom, 0px))" />
       </van-pull-refresh>
     </PopupContainer>
 
@@ -649,7 +649,7 @@ const fetchCategoryStats = async () => {
       const data = res.data
       overallStats.value = {
         month: {
-          rate: data.month?.rate?.toFixed(1) || '0.0',
+          rate: data.month?.usagePercentage?.toFixed(1) || '0.0',
           current: data.month?.current || 0,
           limit: data.month?.limit || 0,
           count: data.month?.count || 0,
@@ -657,7 +657,7 @@ const fetchCategoryStats = async () => {
           description: data.month?.description || ''
         },
         year: {
-          rate: data.year?.rate?.toFixed(1) || '0.0',
+          rate: data.year?.usagePercentage?.toFixed(1) || '0.0',
           current: data.year?.current || 0,
           limit: data.year?.limit || 0,
           count: data.year?.count || 0,
diff --git a/Web/src/views/CalendarView.vue b/Web/src/views/CalendarView.vue
index 4ded914..5abfd71 100644
--- a/Web/src/views/CalendarView.vue
+++ b/Web/src/views/CalendarView.vue
@@ -12,7 +12,7 @@
     />
 
     <!-- 底部安全距离 -->
-    <div style="height: calc(60px + env(safe-area-inset-bottom, 0px))" />
+    <div style="height: calc(95px + env(safe-area-inset-bottom, 0px))" />
 
     <!-- 日期交易列表弹出层 -->
     <PopupContainer
diff --git a/Web/src/views/SettingView.vue b/Web/src/views/SettingView.vue
index ed58a36..351fb9b 100644
--- a/Web/src/views/SettingView.vue
+++ b/Web/src/views/SettingView.vue
@@ -137,7 +137,7 @@
         />
       </van-cell-group>
       <!-- 底部安全距离 -->
-      <div style="height: calc(80px + env(safe-area-inset-bottom, 0px))" />
+      <div style="height: calc(95px + env(safe-area-inset-bottom, 0px))" />
     </div>
 
     <!-- 液态玻璃底部导航栏 -->
diff --git a/Web/src/views/calendarV2/Index.vue b/Web/src/views/calendarV2/Index.vue
index 89e3eac..2f31ebf 100644
--- a/Web/src/views/calendarV2/Index.vue
+++ b/Web/src/views/calendarV2/Index.vue
@@ -101,8 +101,7 @@ const router = useRouter()
 
 // 底部导航栏
 const activeTab = ref('calendar')
-const handleTabClick = (item, index) => {
-  console.log('Tab clicked:', item.name, index)
+const handleTabClick = () => {
   // 导航逻辑已在组件内部处理
 }
 
@@ -212,7 +211,14 @@ const onDatePickerConfirm = ({ selectedValues }) => {
 
   // 更新日期
   currentDate.value = newDate
-  selectedDate.value = newDate
+
+  // 判断是否选择了当前月（复用上面的 today 变量）
+  const isCurrentMonth = newDate.getFullYear() === today.getFullYear() &&
+    newDate.getMonth() === today.getMonth()
+
+  // 如果选择的是当前月，选中今天；否则选中该月第一天
+  selectedDate.value = isCurrentMonth ? today : newDate
+
   calendarKey.value += 1
   showDatePicker.value = false
 }
@@ -258,9 +264,16 @@ const changeMonth = async (offset) => {
 
   currentDate.value = newDate
 
-  // 根据切换方向选择合适的日期
+  // 判断是否切换到当前月（复用上面的 today 变量）
+  const isCurrentMonth = newDate.getFullYear() === today.getFullYear() &&
+    newDate.getMonth() === today.getMonth()
+
+  // 根据切换方向和是否为当前月选择合适的日期
   let newSelectedDate
-  if (offset > 0) {
+  if (isCurrentMonth) {
+    // 如果切换到当前月，选中今天
+    newSelectedDate = today
+  } else if (offset > 0) {
     // 切换到下个月，选中下个月的第一天
     newSelectedDate = new Date(newDate.getFullYear(), newDate.getMonth(), 1)
   } else {
@@ -387,8 +400,8 @@ onBeforeUnmount(() => {
   background-color: var(--bg-primary);
 }
 
-/* 底部安全距离 */
+/* 底部安全距离 - 匹配底部导航栏高度 */
 .bottom-spacer {
-  height: calc(60px + env(safe-area-inset-bottom, 0px));
+  height: calc(95px + env(safe-area-inset-bottom, 0px));
 }
 </style>
diff --git a/Web/src/views/calendarV2/modules/Calendar.vue b/Web/src/views/calendarV2/modules/Calendar.vue
index 4b28d9c..a662a6a 100644
--- a/Web/src/views/calendarV2/modules/Calendar.vue
+++ b/Web/src/views/calendarV2/modules/Calendar.vue
@@ -32,6 +32,8 @@
               :key="day.date"
               class="day-cell"
               @click="onDayClick(day)"
+              @touchstart="onTouchStartHoliday($event, day)"
+              @touchend="onTouchEndHoliday"
             >
               <div
                 class="day-number"
@@ -40,10 +42,19 @@
                   'day-selected': day.isSelected,
                   'day-has-data': day.hasData,
                   'day-over-limit': day.isOverLimit,
-                  'day-other-month': !day.isCurrentMonth
+                  'day-other-month': !day.isCurrentMonth,
+                  'day-holiday': day.isHoliday && day.isRest,
+                  'day-workday': day.isWorkday
                 }"
               >
                 {{ day.dayNumber }}
+                <!-- 节假日标记 -->
+                <span
+                  v-if="day.isHoliday"
+                  class="holiday-badge"
+                >
+                  {{ day.isWorkday ? '班' : '休' }}
+                </span>
               </div>
               <div
                 v-if="day.amount"
@@ -60,6 +71,26 @@
         </div>
       </Transition>
     </div>
+
+    <!-- 节假日提示浮层 -->
+    <van-overlay
+      :show="showHolidayTooltip"
+      @click="closeHolidayTooltip"
+    >
+      <div
+        class="holiday-tooltip-wrapper"
+        @click.stop
+      >
+        <div class="holiday-tooltip">
+          <div class="tooltip-title">
+            {{ currentHolidayName }}
+          </div>
+          <div class="tooltip-desc">
+            {{ currentHolidayDesc }}
+          </div>
+        </div>
+      </div>
+    </van-overlay>
   </div>
 </template>
 
@@ -67,6 +98,7 @@
 import { computed, watch, ref } from 'vue'
 import { getDailyStatistics } from '@/api/statistics'
 import { getBudgetList } from '@/api/budget'
+import { getMonthHolidays } from '@/api/holiday'
 
 const props = defineProps({
   currentDate: Date,
@@ -90,6 +122,13 @@ const weekDays = ['一', '二', '三', '四', '五', '六', '日']
 const dailyStatsMap = ref({})
 const dailyBudget = ref(0)
 const loading = ref(false)
+const holidaysMap = ref({}) // 节假日数据映射
+
+// 节假日提示相关
+const showHolidayTooltip = ref(false)
+const currentHolidayName = ref('')
+const currentHolidayDesc = ref('')
+let holdTimer = null
 
 // 获取月度每日统计数据
 const fetchDailyStats = async (year, month) => {
@@ -101,7 +140,9 @@ const fetchDailyStats = async (year, month) => {
       // 构建日期 Map
       const statsMap = {}
       response.data.forEach(item => {
-        statsMap[item.date] = {
+        // 后端返回的是 day (1-31)，需要构建完整的日期字符串
+        const dateKey = `${year}-${String(month).padStart(2, '0')}-${String(item.day).padStart(2, '0')}`
+        statsMap[dateKey] = {
           count: item.count,
           expense: item.expense,
           income: item.income
@@ -142,18 +183,20 @@ const fetchAllRelevantMonthsData = async (year, month) => {
 
     // 并行加载所有需要的月份数据
     // JavaScript Date.month 是 0-11，但后端 API 期望 1-12
-    const promises = [fetchDailyStats(year, month + 1)]
+    const promises = [fetchDailyStats(year, month + 1), fetchHolidays(year, month + 1)]
 
     if (needPrevMonth) {
       const prevMonth = month === 0 ? 11 : month - 1
       const prevYear = month === 0 ? year - 1 : year
       promises.push(fetchDailyStats(prevYear, prevMonth + 1))
+      promises.push(fetchHolidays(prevYear, prevMonth + 1))
     }
 
     if (needNextMonth) {
       const nextMonth = month === 11 ? 0 : month + 1
       const nextYear = month === 11 ? year + 1 : year
       promises.push(fetchDailyStats(nextYear, nextMonth + 1))
+      promises.push(fetchHolidays(nextYear, nextMonth + 1))
     }
 
     await Promise.all(promises)
@@ -178,6 +221,23 @@ const fetchBudgetData = async () => {
   }
 }
 
+// 获取节假日数据
+const fetchHolidays = async (year, month) => {
+  try {
+    const response = await getMonthHolidays(year, month)
+    if (response.success && response.data) {
+      const map = {}
+      response.data.forEach(item => {
+        map[item.date] = item
+      })
+      holidaysMap.value = { ...holidaysMap.value, ...map }
+    }
+  } catch (error) {
+    // 静默失败，仅记录日志
+    console.error('获取节假日数据失败:', error)
+  }
+}
+
 // 监听 currentDate 变化，重新加载数据
 watch(() => props.currentDate, async (newDate) => {
   if (newDate) {
@@ -251,6 +311,7 @@ const createDayObject = (date, isCurrentMonth) => {
   // 从 API 数据获取
   const dateKey = formatDateKey(date)
   const dayStats = dailyStatsMap.value[dateKey] || {}
+  const holidayInfo = holidaysMap.value[dateKey] // 获取节假日信息
 
   // 计算净支出（支出 - 收入）
   const netAmount = (dayStats.expense || 0) - (dayStats.income || 0)
@@ -258,6 +319,30 @@ const createDayObject = (date, isCurrentMonth) => {
   // 收入大于支出为盈利（绿色），否则为支出（红色）
   const isProfitable = hasData && netAmount < 0
 
+  // 判断是否是周末（0=周日, 6=周六）
+  const dayOfWeek = date.getDay()
+  const isWeekend = dayOfWeek === 0 || dayOfWeek === 6
+
+  // 节假日逻辑判断
+  let isHoliday = false
+  let holidayName = ''
+  let isWorkday = false
+  let isRest = false
+
+  if (holidayInfo) {
+    // 有节假日信息，以节假日信息为准
+    isHoliday = true
+    holidayName = holidayInfo.holidayName
+    isWorkday = holidayInfo.dayType === 3 // 调休工作日
+    isRest = holidayInfo.rest === 1
+  } else if (isWeekend) {
+    // 没有节假日信息，但是周末，标记为普通休息日
+    isHoliday = true
+    holidayName = dayOfWeek === 0 ? '周日' : '周六'
+    isWorkday = false
+    isRest = true
+  }
+
   return {
     date: date.getTime(),
     dayNumber: date.getDate(),
@@ -267,7 +352,12 @@ const createDayObject = (date, isCurrentMonth) => {
     hasData,
     amount: hasData ? Math.abs(netAmount).toFixed(0) : '',
     isOverLimit: netAmount > (dailyBudget.value || 0), // 超过每日预算标红
-    isProfitable // 是否盈利（收入>支出）
+    isProfitable, // 是否盈利（收入>支出）
+    // 节假日信息
+    isHoliday,
+    holidayName,
+    isWorkday, // 调休工作日
+    isRest // 是否休息
   }
 }
 
@@ -284,6 +374,31 @@ const onDayClick = (day) => {
   emit('dayClick', day)
 }
 
+// 节假日长按事件处理
+const onTouchStartHoliday = (e, day) => {
+  if (!day.isHoliday) {return}
+
+  // 长按500ms显示提示
+  holdTimer = setTimeout(() => {
+    currentHolidayName.value = day.holidayName
+    currentHolidayDesc.value = day.isWorkday
+      ? `${day.holidayName} - 调休工作日`
+      : `${day.holidayName} - 休息日`
+    showHolidayTooltip.value = true
+  }, 500)
+}
+
+const onTouchEndHoliday = () => {
+  if (holdTimer) {
+    clearTimeout(holdTimer)
+    holdTimer = null
+  }
+}
+
+const closeHolidayTooltip = () => {
+  showHolidayTooltip.value = false
+}
+
 // 触摸事件
 const onTouchStart = (e) => {
   emit('touchStart', e)
@@ -384,7 +499,8 @@ const onTouchEnd = () => {
 .calendar-grid-wrapper {
   position: relative;
   width: 100%;
-  overflow: hidden;
+  overflow: hidden; /* 保持 hidden 以支持切换动画 */
+  padding-top: 4px; /* 新增：为第一行的徽章留出空间 */
 }
 
 .calendar-grid {
@@ -392,6 +508,7 @@ const onTouchEnd = () => {
   flex-direction: column;
   gap: var(--spacing-lg);
   width: 100%;
+  padding-top: 4px; /* 新增：为第一行徽章留出空间 */
 }
 
 .calendar-week {
@@ -410,6 +527,7 @@ const onTouchEnd = () => {
 }
 
 .day-number {
+  position: relative; /* 为绝对定位的徽章提供定位上下文 */
   display: flex;
   align-items: center;
   justify-content: center;
@@ -451,4 +569,65 @@ const onTouchEnd = () => {
 .day-amount.amount-profit {
   color: var(--accent-success);
 }
+
+/* ========== 节假日样式 ========== */
+/* 节假日放假样式（绿色系） */
+.day-number.day-holiday {
+  background: linear-gradient(135deg, #E8F5E9 0%, #C8E6C9 100%);
+  color: #2E7D32;
+  font-weight: var(--font-bold);
+}
+
+/* 调休工作日样式（橙色/黄色系） */
+.day-number.day-workday {
+  background: linear-gradient(135deg, #FFF3E0 0%, #FFE0B2 100%);
+  color: #E65100;
+  font-weight: var(--font-bold);
+}
+
+/* 节假日标记 */
+.holiday-badge {
+  position: absolute;
+  top: -2px;
+  right: -2px;
+  font-size: 9px;
+  background-color: var(--accent-danger);
+  color: white;
+  border-radius: 4px;
+  padding: 1px 3px;
+  line-height: 1.2;
+  font-weight: var(--font-bold);
+  box-shadow: 0 1px 2px rgba(0, 0, 0, 0.2);
+  z-index: 100;
+}
+
+/* 节假日提示浮层 */
+.holiday-tooltip-wrapper {
+  display: flex;
+  align-items: center;
+  justify-content: center;
+  height: 100%;
+}
+
+.holiday-tooltip {
+  background: white;
+  border-radius: 12px;
+  padding: 24px;
+  box-shadow: 0 4px 12px rgba(0, 0, 0, 0.15);
+  max-width: 280px;
+}
+
+.tooltip-title {
+  font-size: 18px;
+  font-weight: bold;
+  color: var(--text-primary);
+  margin-bottom: 8px;
+  text-align: center;
+}
+
+.tooltip-desc {
+  font-size: 14px;
+  color: var(--text-secondary);
+  text-align: center;
+}
 </style>
diff --git a/Web/src/views/statisticsV1/Index.vue b/Web/src/views/statisticsV1/Index.vue
index e9c2b72..0efe513 100644
--- a/Web/src/views/statisticsV1/Index.vue
+++ b/Web/src/views/statisticsV1/Index.vue
@@ -243,7 +243,7 @@
             </div>
           </div>
           <!-- 底部安全距离 -->
-          <div style="height: calc(50px + env(safe-area-inset-bottom, 0px))" />
+          <div style="height: calc(95px + env(safe-area-inset-bottom, 0px))" />
         </div>
       </div>
     </van-pull-refresh>
diff --git a/Web/src/views/statisticsV2/Index.vue b/Web/src/views/statisticsV2/Index.vue
index 833dff9..5bec4e8 100644
--- a/Web/src/views/statisticsV2/Index.vue
+++ b/Web/src/views/statisticsV2/Index.vue
@@ -397,12 +397,21 @@ const loadWeeklyData = async () => {
     })
 
     if (dailyResult?.success && dailyResult.data) {
-      // 转换数据格式以适配图表组件
-      trendStats.value = dailyResult.data.map(item => ({
-        date: item.date,
-        amount: (item.income || 0) - (item.expense || 0),
-        count: item.count || 0
-      }))
+      // ⚠️ 注意: API 返回的 data 按日期顺序排列,但只有 day 字段(天数)
+      // 需要根据 weekStart 和索引重建完整日期
+      trendStats.value = dailyResult.data.map((item, index) => {
+        // 从 weekStart 开始,按索引递增天数
+        const date = new Date(weekStart)
+        date.setDate(weekStart.getDate() + index)
+        const dateStr = formatDateToString(date)
+
+        return {
+          date: dateStr,
+          expense: item.expense || 0,
+          income: item.income || 0,
+          count: item.count || 0
+        }
+      })
     }
   } catch (error) {
     console.error('加载周度数据失败:', error)
@@ -638,6 +647,9 @@ const isLastPeriod = () => {
 const handleTouchStart = (e) => {
   touchStartX.value = e.touches[0].clientX
   touchStartY.value = e.touches[0].clientY
+  // 重置 touchEnd 值,防止使用上次的残留值
+  touchEndX.value = touchStartX.value
+  touchEndY.value = touchStartY.value
 }
 
 const handleTouchMove = (e) => {
@@ -645,12 +657,21 @@ const handleTouchMove = (e) => {
   touchEndY.value = e.touches[0].clientY
 }
 
-const handleTouchEnd = () => {
+const handleTouchEnd = (e) => {
+  // 如果 touchEnd 事件中还有 changedTouches,使用它来获取最终位置
+  if (e.changedTouches && e.changedTouches.length > 0) {
+    touchEndX.value = e.changedTouches[0].clientX
+    touchEndY.value = e.changedTouches[0].clientY
+  }
+
   const deltaX = touchEndX.value - touchStartX.value
   const deltaY = touchEndY.value - touchStartY.value
 
-  // 判断是否是水平滑动（水平距离大于垂直距离）
-  if (Math.abs(deltaX) > Math.abs(deltaY) && Math.abs(deltaX) > 50) {
+  // 最小滑动距离阈值(像素)
+  const MIN_SWIPE_DISTANCE = 50
+
+  // 判断是否是水平滑动（水平距离大于垂直距离且超过阈值）
+  if (Math.abs(deltaX) > Math.abs(deltaY) && Math.abs(deltaX) > MIN_SWIPE_DISTANCE) {
     if (deltaX > 0) {
       // 右滑 - 上一个周期
       handlePrevPeriod()
@@ -744,7 +765,7 @@ onMounted(() => {
   overflow-y: auto;
   -webkit-overflow-scrolling: touch;
   overscroll-behavior: contain;
-  background-color: var(--bg-secondary);
+  background-color: var(--bg-primary);
   /* 改善滚动性能 */
   will-change: scroll-position;
   /* 防止滚动卡顿 */
@@ -753,7 +774,7 @@ onMounted(() => {
 
 .statistics-content {
   padding: var(--spacing-md);
-  padding-bottom: calc(80px + env(safe-area-inset-bottom, 0px));
+  padding-bottom: calc(95px + env(safe-area-inset-bottom, 0px));
   min-height: 100%;
   /* 确保内容足够高以便滚动 */
   display: flex;
@@ -781,7 +802,7 @@ onMounted(() => {
 
   .statistics-content {
     padding: var(--spacing-sm);
-    padding-bottom: calc(90px + env(safe-area-inset-bottom, 0px));
+    padding-bottom: calc(95px + env(safe-area-inset-bottom, 0px));
   }
 }
 </style>
\ No newline at end of file
diff --git a/Web/src/views/statisticsV2/modules/DailyTrendChart.vue b/Web/src/views/statisticsV2/modules/DailyTrendChart.vue
index 8dfdde2..04db00f 100644
--- a/Web/src/views/statisticsV2/modules/DailyTrendChart.vue
+++ b/Web/src/views/statisticsV2/modules/DailyTrendChart.vue
@@ -1,4 +1,4 @@
-<template>
+<template>
   <div class="daily-trend-card common-card">
     <div class="card-header">
       <h3 class="card-title">
@@ -333,7 +333,7 @@ onBeforeUnmount(() => {
 @import '@/assets/theme.css';
 
 .daily-trend-card {
-  background: var(--bg-primary);
+  background: var(--bg-secondary);
   border-radius: var(--radius-lg);
   padding: var(--spacing-xl);
   margin-bottom: var(--spacing-xl);
diff --git a/Web/src/views/statisticsV2/modules/ExpenseCategoryCard.vue b/Web/src/views/statisticsV2/modules/ExpenseCategoryCard.vue
index 7903931..1749743 100644
--- a/Web/src/views/statisticsV2/modules/ExpenseCategoryCard.vue
+++ b/Web/src/views/statisticsV2/modules/ExpenseCategoryCard.vue
@@ -1,4 +1,4 @@
-<template>
+<template>
   <!-- 支出分类统计 -->
   <div
     class="common-card"
@@ -274,7 +274,7 @@ onBeforeUnmount(() => {
 
 // 通用卡片样式
 .common-card {
-  background: var(--bg-primary);
+  background: var(--bg-secondary);
   border-radius: var(--radius-lg);
   padding: var(--spacing-xl);
   margin-bottom: var(--spacing-xl);
diff --git a/Web/src/views/statisticsV2/modules/IncomeBalanceCard.vue b/Web/src/views/statisticsV2/modules/IncomeBalanceCard.vue
index 5687d45..7a7eb58 100644
--- a/Web/src/views/statisticsV2/modules/IncomeBalanceCard.vue
+++ b/Web/src/views/statisticsV2/modules/IncomeBalanceCard.vue
@@ -1,4 +1,4 @@
-<template>
+<template>
   <div class="income-balance-card common-card">
     <div class="stats-row">
       <div class="stat-item">
@@ -50,7 +50,7 @@ const balanceClass = computed(() => ({
 @import '@/assets/theme.css';
 
 .income-balance-card {
-  background: var(--bg-primary);
+  background: var(--bg-secondary);
   border-radius: var(--radius-lg);
   padding: var(--spacing-xl);
   margin-bottom: var(--spacing-xl);
diff --git a/Web/src/views/statisticsV2/modules/IncomeNoneCategoryCard.vue b/Web/src/views/statisticsV2/modules/IncomeNoneCategoryCard.vue
index 6c3978a..1989f7d 100644
--- a/Web/src/views/statisticsV2/modules/IncomeNoneCategoryCard.vue
+++ b/Web/src/views/statisticsV2/modules/IncomeNoneCategoryCard.vue
@@ -1,4 +1,4 @@
-<template>
+<template>
   <!-- 收支和不计收支并列显示 -->
   <div class="side-by-side-cards">
     <!-- 收入分类统计 -->
@@ -155,7 +155,7 @@ const noneCategories = computed(() => {
 
 // 通用卡片样式
 .common-card {
-  background: var(--bg-primary);
+  background: var(--bg-secondary);
   border-radius: var(--radius-lg);
   padding: var(--spacing-xl);
   margin-bottom: var(--spacing-xl);
diff --git a/Web/src/views/statisticsV2/modules/MonthlyExpenseCard.vue b/Web/src/views/statisticsV2/modules/MonthlyExpenseCard.vue
index fff4621..831be63 100644
--- a/Web/src/views/statisticsV2/modules/MonthlyExpenseCard.vue
+++ b/Web/src/views/statisticsV2/modules/MonthlyExpenseCard.vue
@@ -373,18 +373,16 @@ const updateChart = () => {
               }
             }
 
-            // 显示累计值和当日值
+            // 只显示当日值
             params.forEach((param) => {
               const color = param.seriesName === '支出' ? '#ff6b6b' : '#4ade80'
-              const cumulativeValue = param.value
               const dailyValue = param.seriesName === '支出' ? dailyExpense : dailyIncome
 
-              content += `<span style="display:inline-block;margin-right:5px;border-radius:50%;width:10px;height:10px;background-color:${color}"></span>`
-              content += `${param.seriesName}累计: ¥${cumulativeValue.toFixed(2)}`
               if (dailyValue > 0) {
-                content += ` (当日: ¥${dailyValue.toFixed(2)})`
+                content += `<span style="display:inline-block;margin-right:5px;border-radius:50%;width:10px;height:10px;background-color:${color}"></span>`
+                content += `${param.seriesName}: ¥${dailyValue.toFixed(2)}`
+                content += '<br/>'
               }
-              content += '<br/>'
             })
           } catch (error) {
             console.warn('格式化tooltip失败:', error)
@@ -432,7 +430,7 @@ onBeforeUnmount(() => {
 
 // 通用卡片样式
 .common-card {
-  background: var(--bg-primary);
+  background: var(--bg-secondary);
   border-radius: var(--radius-lg);
   padding: var(--spacing-xl);
   margin-bottom: var(--spacing-xl);
diff --git a/WebApi.Test/Application/BudgetApplicationTest.cs b/WebApi.Test/Application/BudgetApplicationTest.cs
index 620ceaf..34d9505 100644
--- a/WebApi.Test/Application/BudgetApplicationTest.cs
+++ b/WebApi.Test/Application/BudgetApplicationTest.cs
@@ -9,15 +9,13 @@ public class BudgetApplicationTest : BaseApplicationTest
 {
     private readonly IBudgetService _budgetService;
     private readonly IBudgetRepository _budgetRepository;
-    private readonly ILogger<BudgetApplication> _logger;
     private readonly BudgetApplication _application;
 
     public BudgetApplicationTest()
     {
         _budgetService = Substitute.For<IBudgetService>();
         _budgetRepository = Substitute.For<IBudgetRepository>();
-        _logger = CreateMockLogger<BudgetApplication>();
-        _application = new BudgetApplication(_budgetService, _budgetRepository, _logger);
+        _application = new BudgetApplication(_budgetService, _budgetRepository);
     }
 
     #region GetListAsync Tests
diff --git a/WebApi.Test/Application/EmailMessageApplicationTest.cs b/WebApi.Test/Application/EmailMessageApplicationTest.cs
index d013efe..566b471 100644
--- a/WebApi.Test/Application/EmailMessageApplicationTest.cs
+++ b/WebApi.Test/Application/EmailMessageApplicationTest.cs
@@ -12,7 +12,6 @@ public class EmailMessageApplicationTest : BaseApplicationTest
     private readonly ITransactionRecordRepository _transactionRepository;
     private readonly IEmailHandleService _emailHandleService;
     private readonly IEmailSyncService _emailSyncService;
-    private readonly ILogger<EmailMessageApplication> _logger;
     private readonly EmailMessageApplication _application;
 
     public EmailMessageApplicationTest()
@@ -21,13 +20,11 @@ public class EmailMessageApplicationTest : BaseApplicationTest
         _transactionRepository = Substitute.For<ITransactionRecordRepository>();
         _emailHandleService = Substitute.For<IEmailHandleService>();
         _emailSyncService = Substitute.For<IEmailSyncService>();
-        _logger = CreateMockLogger<EmailMessageApplication>();
         _application = new EmailMessageApplication(
             _emailRepository,
             _transactionRepository,
             _emailHandleService,
-            _emailSyncService,
-            _logger);
+            _emailSyncService);
     }
 
     #region GetListAsync Tests
diff --git a/WebApi.Test/Application/JobApplicationTest.cs b/WebApi.Test/Application/JobApplicationTest.cs
index 5c7c009..01aedb7 100644
--- a/WebApi.Test/Application/JobApplicationTest.cs
+++ b/WebApi.Test/Application/JobApplicationTest.cs
@@ -10,17 +10,15 @@ public class JobApplicationTest : BaseApplicationTest
 {
     private readonly ISchedulerFactory _schedulerFactory;
     private readonly IScheduler _scheduler;
-    private readonly ILogger<JobApplication> _logger;
     private readonly JobApplication _application;
 
     public JobApplicationTest()
     {
         _schedulerFactory = Substitute.For<ISchedulerFactory>();
         _scheduler = Substitute.For<IScheduler>();
-        _logger = CreateMockLogger<JobApplication>();
         
         _schedulerFactory.GetScheduler().Returns(_scheduler);
-        _application = new JobApplication(_schedulerFactory, _logger);
+        _application = new JobApplication(_schedulerFactory);
     }
 
     #region GetJobsAsync Tests
diff --git a/WebApi.Test/Application/MessageRecordApplicationTest.cs b/WebApi.Test/Application/MessageRecordApplicationTest.cs
index 7501ab8..32282b2 100644
--- a/WebApi.Test/Application/MessageRecordApplicationTest.cs
+++ b/WebApi.Test/Application/MessageRecordApplicationTest.cs
@@ -8,14 +8,12 @@ namespace WebApi.Test.Application;
 public class MessageRecordApplicationTest : BaseApplicationTest
 {
     private readonly IMessageService _messageService;
-    private readonly ILogger<MessageRecordApplication> _logger;
     private readonly MessageRecordApplication _application;
 
     public MessageRecordApplicationTest()
     {
         _messageService = Substitute.For<IMessageService>();
-        _logger = CreateMockLogger<MessageRecordApplication>();
-        _application = new MessageRecordApplication(_messageService, _logger);
+        _application = new MessageRecordApplication(_messageService);
     }
 
     [Fact]
diff --git a/WebApi.Test/Application/NotificationApplicationTest.cs b/WebApi.Test/Application/NotificationApplicationTest.cs
index 672a503..b797042 100644
--- a/WebApi.Test/Application/NotificationApplicationTest.cs
+++ b/WebApi.Test/Application/NotificationApplicationTest.cs
@@ -8,14 +8,12 @@ namespace WebApi.Test.Application;
 public class NotificationApplicationTest : BaseApplicationTest
 {
     private readonly INotificationService _notificationService;
-    private readonly ILogger<NotificationApplication> _logger;
     private readonly NotificationApplication _application;
 
     public NotificationApplicationTest()
     {
         _notificationService = Substitute.For<INotificationService>();
-        _logger = CreateMockLogger<NotificationApplication>();
-        _application = new NotificationApplication(_notificationService, _logger);
+        _application = new NotificationApplication(_notificationService);
     }
 
     #region GetVapidPublicKeyAsync Tests
diff --git a/WebApi.Test/Application/TransactionApplicationTest.cs b/WebApi.Test/Application/TransactionApplicationTest.cs
index 06b8a0b..75754dd 100644
--- a/WebApi.Test/Application/TransactionApplicationTest.cs
+++ b/WebApi.Test/Application/TransactionApplicationTest.cs
@@ -10,15 +10,13 @@ public class TransactionApplicationTest : BaseApplicationTest
 {
     private readonly ITransactionRecordRepository _transactionRepository;
     private readonly ISmartHandleService _smartHandleService;
-    private readonly ILogger<TransactionApplication> _logger;
     private readonly TransactionApplication _application;
 
     public TransactionApplicationTest()
     {
         _transactionRepository = Substitute.For<ITransactionRecordRepository>();
         _smartHandleService = Substitute.For<ISmartHandleService>();
-        _logger = CreateMockLogger<TransactionApplication>();
-        _application = new TransactionApplication(_transactionRepository, _smartHandleService, _logger);
+        _application = new TransactionApplication(_transactionRepository, _smartHandleService);
     }
 
     #region GetByIdAsync Tests
diff --git a/WebApi.Test/Application/TransactionCategoryApplicationTest.cs b/WebApi.Test/Application/TransactionCategoryApplicationTest.cs
index fb61cf8..d3bbcd9 100644
--- a/WebApi.Test/Application/TransactionCategoryApplicationTest.cs
+++ b/WebApi.Test/Application/TransactionCategoryApplicationTest.cs
@@ -12,7 +12,6 @@ public class TransactionCategoryApplicationTest : BaseApplicationTest
     private readonly ITransactionRecordRepository _transactionRepository;
     private readonly IBudgetRepository _budgetRepository;
     private readonly ISmartHandleService _smartHandleService;
-    private readonly ILogger<TransactionCategoryApplication> _logger;
     private readonly TransactionCategoryApplication _application;
 
     public TransactionCategoryApplicationTest()
@@ -21,13 +20,11 @@ public class TransactionCategoryApplicationTest : BaseApplicationTest
         _transactionRepository = Substitute.For<ITransactionRecordRepository>();
         _budgetRepository = Substitute.For<IBudgetRepository>();
         _smartHandleService = Substitute.For<ISmartHandleService>();
-        _logger = CreateMockLogger<TransactionCategoryApplication>();
         _application = new TransactionCategoryApplication(
             _categoryRepository,
             _transactionRepository,
             _budgetRepository,
-            _smartHandleService,
-            _logger);
+            _smartHandleService);
     }
 
     #region GetListAsync Tests
diff --git a/WebApi.Test/Application/TransactionPeriodicApplicationTest.cs b/WebApi.Test/Application/TransactionPeriodicApplicationTest.cs
index ebf7060..4a85924 100644
--- a/WebApi.Test/Application/TransactionPeriodicApplicationTest.cs
+++ b/WebApi.Test/Application/TransactionPeriodicApplicationTest.cs
@@ -10,15 +10,13 @@ public class TransactionPeriodicApplicationTest : BaseApplicationTest
 {
     private readonly ITransactionPeriodicRepository _periodicRepository;
     private readonly ITransactionPeriodicService _periodicService;
-    private readonly ILogger<TransactionPeriodicApplication> _logger;
     private readonly TransactionPeriodicApplication _application;
 
     public TransactionPeriodicApplicationTest()
     {
         _periodicRepository = Substitute.For<ITransactionPeriodicRepository>();
         _periodicService = Substitute.For<ITransactionPeriodicService>();
-        _logger = CreateMockLogger<TransactionPeriodicApplication>();
-        _application = new TransactionPeriodicApplication(_periodicRepository, _periodicService, _logger);
+        _application = new TransactionPeriodicApplication(_periodicRepository, _periodicService);
     }
 
     #region GetListAsync Tests
diff --git a/WebApi.Test/Application/TransactionStatisticsApplicationTest.cs b/WebApi.Test/Application/TransactionStatisticsApplicationTest.cs
index dcb1b1e..9a1e238 100644
--- a/WebApi.Test/Application/TransactionStatisticsApplicationTest.cs
+++ b/WebApi.Test/Application/TransactionStatisticsApplicationTest.cs
@@ -10,15 +10,13 @@ public class TransactionStatisticsApplicationTest : BaseApplicationTest
 {
     private readonly ITransactionStatisticsService _statisticsService;
     private readonly IConfigService _configService;
-    private readonly ILogger<TransactionStatisticsApplication> _logger;
     private readonly TransactionStatisticsApplication _application;
 
     public TransactionStatisticsApplicationTest()
     {
         _statisticsService = Substitute.For<ITransactionStatisticsService>();
         _configService = Substitute.For<IConfigService>();
-        _logger = CreateMockLogger<TransactionStatisticsApplication>();
-        _application = new TransactionStatisticsApplication(_statisticsService, _configService, _logger);
+        _application = new TransactionStatisticsApplication(_statisticsService, _configService);
     }
 
     #region GetBalanceStatisticsAsync Tests
diff --git a/WebApi.Test/Budget/BudgetSavingsTest.cs b/WebApi.Test/Budget/BudgetSavingsTest.cs
index 8971439..18949fa 100644
--- a/WebApi.Test/Budget/BudgetSavingsTest.cs
+++ b/WebApi.Test/Budget/BudgetSavingsTest.cs
@@ -499,4 +499,81 @@ public class BudgetSavingsTest : BaseTest
         // 预计存款 = 116400 - 30000 - 2049.18 - 300 + 2000 = 86050.82
         result.Limit.Should().BeApproximately(86050.82m, 0.1m);
     }
+
+    [Fact]
+    public async Task GetSavings_年度_包含一月份归档存款_Test()
+    {
+        // Arrange
+        var year = 2026;
+        // 当前是2月11号
+        _dateTimeProvider.Now.Returns(new DateTime(year, 2, 11));
+
+        var budgets = new List<BudgetRecord>
+        {
+            // 月度预算
+            new() { Id = 1, Name = "工资", Type = BudgetPeriodType.Month, Limit = 11000, Category = BudgetCategory.Income, SelectedCategories = "工资" },
+            new() { Id = 2, Name = "房租", Type = BudgetPeriodType.Month, Limit = 3000, Category = BudgetCategory.Expense, SelectedCategories = "房租" }
+        };
+
+        // 当前月（2月）的交易数据
+        var currentTransactions = new Dictionary<(string, TransactionType), decimal>
+        {
+            { ("工资", TransactionType.Income), 11000m },
+            { ("房租", TransactionType.Expense), 3000m },
+            { ("转账到公共", TransactionType.Expense), 5000m }  // 2月份实际存款：5000元
+        };
+
+        // 一月份的归档数据
+        var archives = new List<BudgetArchive>
+        {
+            new()
+            {
+                Year = year, Month = 1,
+                Content =
+                [
+                    new BudgetArchiveContent
+                    {
+                        Id = 1,
+                        Name = "工资",
+                        Type = BudgetPeriodType.Month,
+                        Limit = 11000,
+                        Actual = 11000,
+                        Category = BudgetCategory.Income
+                    },
+                    new BudgetArchiveContent
+                    {
+                        Id = 2,
+                        Name = "房租",
+                        Type = BudgetPeriodType.Month,
+                        Limit = 3000,
+                        Actual = 3000,
+                        Category = BudgetCategory.Expense
+                    },
+                    new BudgetArchiveContent
+                    {
+                        Id = -2,
+                        Name = "月度存款计划",
+                        Type = BudgetPeriodType.Month,
+                        Limit = 6287.34m,
+                        Actual = 9600.0m,  // ✅ 一月份实际存款：9600元
+                        Category = BudgetCategory.Savings
+                    }
+                ]
+            }
+        };
+
+        _budgetRepository.GetAllAsync().Returns(budgets);
+        _transactionStatisticsService.GetAmountGroupByClassifyAsync(Arg.Any<DateTime>(), Arg.Any<DateTime>())
+            .Returns(currentTransactions);
+        _budgetArchiveRepository.GetArchivesByYearAsync(year).Returns(archives);
+        _configService.GetConfigByKeyAsync<string>("SavingsCategories").Returns(Task.FromResult<string?>("转账到公共"));
+
+        // Act
+        var result = await _service.GetSavingsDtoAsync(BudgetPeriodType.Year, new DateTime(year, 1, 1));
+
+        // Assert
+        result.Should().NotBeNull();
+        // 年度已存款 = 一月份归档存款（9600） + 二月份当前存款（5000） = 14600
+        result.Current.Should().Be(14600m);
+    }
 }
\ No newline at end of file
diff --git a/WebApi/Controllers/HolidayController.cs b/WebApi/Controllers/HolidayController.cs
new file mode 100644
index 0000000..ad5f52d
--- /dev/null
+++ b/WebApi/Controllers/HolidayController.cs
@@ -0,0 +1,36 @@
+using Application;
+using Application.Dto;
+using Microsoft.AspNetCore.Authorization;
+
+namespace WebApi.Controllers;
+
+/// <summary>
+/// 节假日控制器
+/// </summary>
+[ApiController]
+[Route("api/[controller]/[action]")]
+[AllowAnonymous] // 允许匿名访问
+public class HolidayController(HolidayApplication holidayApplication) : ControllerBase
+{
+    /// <summary>
+    /// 获取指定年月的节假日数据
+    /// </summary>
+    [HttpGet]
+    public async Task<BaseResponse<List<HolidayDto>>> GetMonthHolidays([FromQuery] int year, [FromQuery] int month)
+    {
+        var holidays = await holidayApplication.GetMonthHolidaysAsync(year, month);
+        return holidays.Ok();
+    }
+
+    /// <summary>
+    /// 手动同步节假日数据
+    /// </summary>
+    [HttpPost]
+    public async Task<BaseResponse<bool>> SyncHolidays([FromQuery] int year)
+    {
+        var result = await holidayApplication.SyncHolidaysAsync(year);
+        return result
+            ? result.Ok()
+            : BaseResponse<bool>.Fail("同步失败");
+    }
+}
diff --git a/WebApi/Expand.cs b/WebApi/Expand.cs
index 680f18e..66311d8 100644
--- a/WebApi/Expand.cs
+++ b/WebApi/Expand.cs
@@ -77,6 +77,17 @@ public static class Expand
                 .WithIdentity("CategoryIconGenerationTrigger")
                 .WithCronSchedule("0 0 0 * * ?") // 每24小时执行一次
                 .WithDescription("每24小时扫描并为无图标分类生成SVG图标"));
+
+            // 配置节假日同步任务 - 每10天凌晨3点执行
+            var holidaySyncJobKey = new JobKey("HolidaySyncJob");
+            q.AddJob<HolidaySyncJob>(opts => opts
+                .WithIdentity(holidaySyncJobKey)
+                .WithDescription("节假日同步任务"));
+            q.AddTrigger(opts => opts
+                .ForJob(holidaySyncJobKey)
+                .WithIdentity("HolidaySyncTrigger")
+                .WithCronSchedule("0 0 3 */10 * ?") // 每10天凌晨3点执行
+                .WithDescription("每10天同步节假日数据"));
         });
 
         // 添加 Quartz Hosted Service
diff --git a/openspec/changes/unify-stats-calendar-color-scheme/.openspec.yaml b/openspec/changes/unify-stats-calendar-color-scheme/.openspec.yaml
new file mode 100644
index 0000000..4465244
--- /dev/null
+++ b/openspec/changes/unify-stats-calendar-color-scheme/.openspec.yaml
@@ -0,0 +1,2 @@
+schema: spec-driven
+created: 2026-02-11
diff --git a/openspec/changes/unify-stats-calendar-color-scheme/design.md b/openspec/changes/unify-stats-calendar-color-scheme/design.md
new file mode 100644
index 0000000..37e1c27
--- /dev/null
+++ b/openspec/changes/unify-stats-calendar-color-scheme/design.md
@@ -0,0 +1,142 @@
+## Context
+
+EmailBill 应用使用 Vue 3 + Vant UI，采用基于 CSS 变量的主题系统支持亮色/暗色模式切换。主题变量定义在 `Web/src/assets/theme.css` 中：
+
+- `--bg-primary`: 主背景色（亮色: #FFFFFF, 暗色: #09090B）
+- `--bg-secondary`: 次级背景色（亮色: #F6F7F8, 暗色: #18181b）
+
+**当前状态：**
+- **统计 V2 页面** (`statisticsV2/Index.vue`): 使用 `--bg-secondary` 作为页面背景（灰底），卡片使用 `--bg-primary`（白卡片/黑卡片）
+- **日历 V2 页面** (`calendarV2/Index.vue`): 使用 `--bg-primary` 作为页面背景（白底/黑底），卡片使用 `--bg-secondary`（灰卡片）
+
+**问题：** 页面切换时配色反转，导致视觉不连贯，尤其在暗色模式下黑底灰卡片对比度不足。
+
+**约束：**
+- 仅修改 CSS，不涉及 Vue 组件逻辑或 JavaScript 代码
+- 保持主题系统变量定义不变
+- 不影响其他页面（如 BudgetView, SettingView）
+
+## Goals / Non-Goals
+
+**Goals:**
+- 统一日历 V2 和统计 V2 页面的配色方案（灰底 + 白卡片/黑卡片）
+- 提升暗色模式下的视觉对比度
+- 保持主题切换功能正常工作
+- 确保修改后不影响页面功能和响应式布局
+
+**Non-Goals:**
+- 不重构主题系统或引入新的 CSS 变量
+- 不修改统计 V2 页面（作为标准参考）
+- 不涉及其他 V1 版本页面（`statisticsV1/`, `CalendarView.vue`）
+- 不调整卡片内部元素的样式（如文字颜色、图表配色）
+
+## Decisions
+
+### 决策 1：CSS 变量替换策略
+
+**选择：** 直接在 Vue 组件的 `<style>` 块中替换背景色变量
+
+**理由：**
+- 最小改动原则：仅修改 4 个 Vue 文件的 CSS 部分
+- 可追溯性：改动集中在日历 V2 相关文件，易于 review 和回滚
+- 无副作用：不影响其他页面或全局样式
+
+**替代方案（未采用）：**
+- ❌ 创建新的 CSS 类（如 `.page-bg-gray`）：增加复杂度，且只用于一个场景
+- ❌ 修改主题变量定义：影响范围过大，可能破坏其他页面
+
+### 决策 2：修改顺序与文件范围
+
+**修改文件清单：**
+1. `calendarV2/Index.vue` - 主容器 `.calendar-scroll-content`
+2. `calendarV2/modules/Stats.vue` - 统计卡片 `.stats-card`
+3. `calendarV2/modules/Calendar.vue` - 日历容器（如果有独立背景）
+4. `calendarV2/modules/TransactionList.vue` - 交易列表卡片（如果有）
+
+**修改规则：**
+- **页面级容器**：`background-color: var(--bg-primary)` → `var(--bg-secondary)`
+- **卡片级容器**：`background-color: var(--bg-secondary)` → `var(--bg-primary)`
+
+**验证点：**
+- 检查每个文件的 `<style>` 块中是否直接或间接（通过类名）使用了背景色
+- 使用浏览器 DevTools 检查计算后的样式，确认没有遗漏的背景声明
+
+### 决策 3：暗色模式验证
+
+**策略：** 在修改后同时测试亮色和暗色模式
+
+**验证场景：**
+1. 切换主题后页面背景和卡片背景正确应用
+2. 文字颜色对比度符合可读性要求（WCAG AA 标准）
+3. 图表和图标颜色在灰底上清晰可见
+
+**工具：**
+- Chrome DevTools 的对比度检查器
+- 手动切换应用内的主题开关
+
+## Risks / Trade-offs
+
+### 风险 1：遗漏子组件的背景声明
+
+**风险：** 日历 V2 的子模块可能在多个层级使用背景色，遗漏修改会导致局部配色不一致
+
+**缓解措施：**
+- 使用全局搜索（grep/Glob）查找 `calendarV2/` 目录下所有 `background-color` 和 `--bg-` 的使用
+- 在浏览器中使用 DevTools 的 "Computed" 面板检查每个可视元素的实际背景色
+- 对比统计 V2 页面的 DOM 结构和样式，确保层级一致
+
+### 风险 2：第三方组件（Vant）的样式覆盖
+
+**风险：** Vant UI 组件（如 `<van-pull-refresh>`, `<van-popup>`）可能有默认背景色，与新方案冲突
+
+**缓解措施：**
+- 检查 Vant 组件是否透明或继承父容器背景
+- 如有冲突，在组件级别添加覆盖样式（如 `::v-deep .van-pull-refresh__track`）
+- 参考统计 V2 页面的 Vant 组件样式处理
+
+### 风险 3：移动端真机测试
+
+**风险：** CSS 变量在某些旧版 iOS Safari 或 Android WebView 中可能渲染异常
+
+**缓解措施：**
+- 项目已使用 CSS 变量主题系统，现有页面正常运行，说明兼容性已验证
+- 修改后使用相同的变量，不引入新的兼容性风险
+- 如需验证，在移动端测试环境中切换主题并检查背景渲染
+
+### Trade-off：设计灵活性 vs 一致性
+
+**选择：** 优先保证与统计 V2 页面一致，牺牲日历页面独立的视觉风格
+
+**理由：**
+- 用户在页面间频繁切换，一致性优先级高于个性化
+- 灰底白卡片方案在暗色模式下对比度更好，更符合可访问性标准
+- 如果未来需要差异化设计，可通过主题系统扩展（如增加 `--page-specific-bg`）
+
+## Migration Plan
+
+**部署步骤：**
+1. 在开发分支完成所有 CSS 修改
+2. 本地验证亮色/暗色模式切换正常
+3. 提交代码并运行前端 lint 和构建测试（`pnpm lint && pnpm build`）
+4. 合并到主分支并部署到测试环境
+5. 在真机上测试页面切换和主题切换
+
+**回滚策略：**
+- 如有问题，回退 4 个 Vue 文件的 CSS 改动（纯样式修改，无数据或逻辑依赖）
+- Git revert 单个 commit 即可快速回滚
+
+**影响范围：**
+- 低风险：仅影响日历 V2 页面视觉呈现
+- 无数据迁移或 API 变更
+- 不影响用户数据或业务逻辑
+
+## Open Questions
+
+1. ~~是否需要同步修改日历 V1 页面（`CalendarView.vue`）？~~  
+   → 否，proposal 明确只修改 V2 页面
+
+2. ~~是否需要在设计系统文档中记录统一的配色规范？~~  
+   → 建议在 `.doc/` 目录添加 UI 配色指南，但不在本次变更范围内
+
+3. **待确认**：`calendarV2/modules/TransactionList.vue` 是否有独立的卡片容器？  
+   → 需要检查文件后确定是否需要修改
diff --git a/openspec/changes/unify-stats-calendar-color-scheme/proposal.md b/openspec/changes/unify-stats-calendar-color-scheme/proposal.md
new file mode 100644
index 0000000..317a4b9
--- /dev/null
+++ b/openspec/changes/unify-stats-calendar-color-scheme/proposal.md
@@ -0,0 +1,36 @@
+## Why
+
+统计 V2 页面和日历 V2 页面当前使用不同的配色方案，导致用户在页面切换时视觉体验不一致。统计 V2 使用灰底白卡片（亮色）/灰底黑卡片（暗色），而日历 V2 使用白底灰卡片（亮色）/黑底灰卡片（暗色）。统一配色方案可提升应用整体视觉一致性和用户体验。
+
+## What Changes
+
+- 将日历 V2 页面的背景色从 `var(--bg-primary)` 改为 `var(--bg-secondary)`（灰底）
+- 将日历 V2 页面中的统计卡片背景色从 `var(--bg-secondary)` 改为 `var(--bg-primary)`（白卡片/黑卡片）
+- 确保日历 V2 的所有子模块（Calendar、Stats、TransactionList）遵循统一的配色方案
+- 保持统计 V2 页面现有配色方案不变（作为标准参考）
+
+## Capabilities
+
+### New Capabilities
+- `consistent-color-scheme`: 日历页面和统计页面使用统一的配色方案（灰底 + 白卡片/黑卡片）
+
+### Modified Capabilities
+<!-- 无现有能力需要修改 -->
+
+## Impact
+
+**受影响的文件：**
+- `Web/src/views/calendarV2/Index.vue` - 主容器背景色
+- `Web/src/views/calendarV2/modules/Stats.vue` - 统计卡片背景色
+- `Web/src/views/calendarV2/modules/Calendar.vue` - 日历组件背景（如果有独立卡片）
+- `Web/src/views/calendarV2/modules/TransactionList.vue` - 交易列表卡片背景（如果有）
+
+**用户体验影响：**
+- ✅ 提升页面切换时的视觉连贯性
+- ✅ 增强暗色模式下的视觉对比度（黑卡片在灰底上更清晰）
+- ✅ 与统计 V2 页面保持一致的设计语言
+
+**技术影响：**
+- 低风险：仅涉及 CSS 变量替换，无逻辑变更
+- 无 API 或后端依赖
+- 无 breaking changes
diff --git a/openspec/changes/unify-stats-calendar-color-scheme/specs/consistent-color-scheme/spec.md b/openspec/changes/unify-stats-calendar-color-scheme/specs/consistent-color-scheme/spec.md
new file mode 100644
index 0000000..9ff44b6
--- /dev/null
+++ b/openspec/changes/unify-stats-calendar-color-scheme/specs/consistent-color-scheme/spec.md
@@ -0,0 +1,109 @@
+## ADDED Requirements
+
+### Requirement: 日历 V2 页面使用统一的配色方案
+
+日历 V2 页面（`calendarV2/Index.vue`）及其所有子模块 SHALL 使用与统计 V2 页面一致的配色方案：页面背景使用 `var(--bg-secondary)`（灰底），卡片背景使用 `var(--bg-primary)`（白卡片/黑卡片）。
+
+#### Scenario: 亮色模式下日历页面背景为灰色
+
+- **WHEN** 用户在亮色主题下访问日历 V2 页面
+- **THEN** 页面主容器（`.calendar-scroll-content`）的背景色 MUST 为 `#F6F7F8`（对应 `var(--bg-secondary)`）
+
+#### Scenario: 暗色模式下日历页面背景为深灰色
+
+- **WHEN** 用户在暗色主题下访问日历 V2 页面
+- **THEN** 页面主容器（`.calendar-scroll-content`）的背景色 MUST 为 `#18181b`（对应 `var(--bg-secondary)`）
+
+#### Scenario: 亮色模式下卡片背景为白色
+
+- **WHEN** 用户在亮色主题下查看日历页面的统计卡片
+- **THEN** 卡片容器（`.stats-card`）的背景色 MUST 为 `#FFFFFF`（对应 `var(--bg-primary)`）
+
+#### Scenario: 暗色模式下卡片背景为黑色
+
+- **WHEN** 用户在暗色主题下查看日历页面的统计卡片
+- **THEN** 卡片容器（`.stats-card`）的背景色 MUST 为 `#09090B`（对应 `var(--bg-primary)`）
+
+### Requirement: 统计 V2 页面配色方案保持不变
+
+统计 V2 页面（`statisticsV2/Index.vue`）的配色方案 SHALL 保持现有设计不变，作为标准参考。
+
+#### Scenario: 统计 V2 页面背景色不受影响
+
+- **WHEN** 修改完成后用户访问统计 V2 页面
+- **THEN** 页面主容器（`.statistics-scroll-content`）的背景色 MUST 仍为 `var(--bg-secondary)`
+- **AND** 统计卡片（`.common-card`）的背景色 MUST 仍为 `var(--bg-primary)`
+
+### Requirement: 页面切换时配色保持一致
+
+用户在统计 V2 页面和日历 V2 页面之间切换时，SHALL 保持视觉一致性，不出现配色反转。
+
+#### Scenario: 从统计页面切换到日历页面配色一致
+
+- **WHEN** 用户从统计 V2 页面导航到日历 V2 页面
+- **THEN** 两个页面的背景色（灰底）和卡片背景色（白卡片/黑卡片）MUST 保持一致
+- **AND** 不出现白底↔灰底或黑底↔灰底的闪烁或突变
+
+#### Scenario: 主题切换后两个页面配色同步
+
+- **WHEN** 用户在任一页面切换亮色/暗色主题
+- **THEN** 统计 V2 和日历 V2 页面 MUST 同时应用新主题的配色方案
+- **AND** 两个页面的配色方案 MUST 保持一致（都是灰底 + 白卡片/黑卡片）
+
+### Requirement: 子模块遵循统一配色规范
+
+日历 V2 页面的所有子模块（`Calendar.vue`, `Stats.vue`, `TransactionList.vue`）SHALL 遵循统一的配色规范。
+
+#### Scenario: Stats 模块卡片使用白色/黑色背景
+
+- **WHEN** 用户查看日历页面的统计模块（`Stats.vue`）
+- **THEN** 统计卡片（`.stats-card`）的背景色 MUST 使用 `var(--bg-primary)`
+- **AND** 在亮色模式下显示为白色（`#FFFFFF`），暗色模式下显示为黑色（`#09090B`）
+
+#### Scenario: Calendar 模块不引入额外背景
+
+- **WHEN** 用户查看日历模块（`Calendar.vue`）
+- **THEN** 日历网格本身 MUST NOT 添加独立的背景色层
+- **AND** MUST 透明或继承父容器的 `var(--bg-secondary)` 背景
+
+#### Scenario: TransactionList 模块卡片使用白色/黑色背景
+
+- **WHEN** 用户查看交易列表模块（`TransactionList.vue`）中的卡片元素
+- **THEN** 如果存在卡片容器，其背景色 MUST 使用 `var(--bg-primary)`
+- **AND** 如果无卡片容器，交易项 MUST 透明或继承父容器背景
+
+### Requirement: CSS 变量使用规范
+
+所有配色修改 SHALL 通过替换 CSS 变量引用实现，MUST NOT 使用硬编码的十六进制颜色值。
+
+#### Scenario: 使用 CSS 变量而非硬编码颜色
+
+- **WHEN** 开发者检查修改后的样式代码
+- **THEN** 所有背景色声明 MUST 使用 `var(--bg-primary)` 或 `var(--bg-secondary)`
+- **AND** MUST NOT 出现硬编码的 `#FFFFFF`, `#F6F7F8`, `#09090B`, `#18181b` 等值
+
+#### Scenario: 主题系统变量定义不变
+
+- **WHEN** 修改完成后检查主题系统文件（`theme.css`）
+- **THEN** CSS 变量 `--bg-primary` 和 `--bg-secondary` 的定义 MUST 保持不变
+- **AND** 不引入新的主题变量
+
+### Requirement: 不影响其他页面配色
+
+修改 SHALL 仅影响日历 V2 页面，MUST NOT 影响其他页面（如 BudgetView, SettingView, statisticsV1）的配色。
+
+#### Scenario: 预算页面配色不受影响
+
+- **WHEN** 修改完成后用户访问预算页面（`BudgetView.vue`）
+- **THEN** 预算页面的背景色和卡片配色 MUST 与修改前完全一致
+
+#### Scenario: 设置页面配色不受影响
+
+- **WHEN** 修改完成后用户访问设置页面（`SettingView.vue`）
+- **THEN** 设置页面的背景色和卡片配色 MUST 与修改前完全一致
+
+#### Scenario: 统计 V1 页面配色不受影响
+
+- **WHEN** 修改完成后用户访问统计 V1 页面（`statisticsV1/Index.vue`）
+- **THEN** 统计 V1 页面的配色 MUST 与修改前完全一致
+- **AND** 不与统计 V2 或日历 V2 的配色方案冲突
diff --git a/openspec/changes/unify-stats-calendar-color-scheme/tasks.md b/openspec/changes/unify-stats-calendar-color-scheme/tasks.md
new file mode 100644
index 0000000..a81b927
--- /dev/null
+++ b/openspec/changes/unify-stats-calendar-color-scheme/tasks.md
@@ -0,0 +1,72 @@
+## 1. 代码审查与准备
+
+- [x] 1.1 使用 Glob 搜索 `statisticsV2/` 和 `calendarV2/` 目录下所有使用 `background-color` 和 `--bg-` 的文件
+- [x] 1.2 确认配色方案：白底/黑底 + 灰卡片（与PWA状态栏一致）
+- [x] 1.3 确认日历 V2 无需修改（已使用目标配色）
+- [x] 1.4 确认统计 V2 需要修改的文件清单
+
+## 2. 修改统计 V2 主页面容器背景
+
+- [x] 2.1 打开 `Web/src/views/statisticsV2/Index.vue` 文件
+- [x] 2.2 在 `<style>` 块中找到 `.statistics-scroll-content` 类
+- [x] 2.3 将 `background-color: var(--bg-secondary)` 修改为 `var(--bg-primary)`
+- [x] 2.4 验证页面背景使用 `--bg-primary`（白底/黑底）
+
+## 3. 修改统计 V2 卡片背景
+
+- [x] 3.1 打开 `Web/src/views/statisticsV2/modules/MonthlyExpenseCard.vue` 文件
+- [x] 3.2 将 `.common-card` 的 `background: var(--bg-primary)` 修改为 `var(--bg-secondary)`
+- [x] 3.3 修改 `ExpenseCategoryCard.vue` 中的 `.common-card` 背景
+- [x] 3.4 修改 `IncomeNoneCategoryCard.vue` 中的 `.common-card` 背景
+- [x] 3.5 修改 `DailyTrendChart.vue` 中的 `.daily-trend-card` 背景
+- [x] 3.6 修改 `IncomeBalanceCard.vue` 中的 `.income-balance-card` 背景
+
+## 4. 代码质量检查
+
+- [x] 4.1 运行 `pnpm lint` 检查代码格式和语法
+- [x] 4.2 使用 Grep 搜索修改后的文件，确认无硬编码颜色值
+- [x] 4.3 确认所有修改仅使用 CSS 变量 `var(--bg-primary)` 和 `var(--bg-secondary)`
+- [x] 4.4 验证修改后的文件数量和范围
+
+## 5. 功能验证 - 亮色模式
+
+- [ ] 5.1 在浏览器中打开统计 V2 页面，确认为亮色主题
+- [ ] 5.2 验证页面背景为白色（`#FFFFFF`，对应 `--bg-primary`）
+- [ ] 5.3 验证所有卡片背景为灰色（`#F6F7F8`，对应 `--bg-secondary`）
+- [ ] 5.4 验证文字颜色对比度清晰可读
+
+## 6. 功能验证 - 暗色模式
+
+- [ ] 6.1 在设置中切换到暗色主题
+- [ ] 6.2 验证页面背景为黑色（`#09090B`，对应 `--bg-primary`）
+- [ ] 6.3 验证所有卡片背景为深灰色（`#18181b`，对应 `--bg-secondary`）
+- [ ] 6.4 使用 Chrome DevTools 对比度检查器验证文字可读性
+
+## 7. 页面切换验证
+
+- [ ] 7.1 从统计 V2 页面导航到日历 V2 页面
+- [ ] 7.2 确认两个页面的配色方案一致（白底/黑底 + 灰卡片）
+- [ ] 7.3 确认无配色闪烁或突变现象
+- [ ] 7.4 多次切换页面，验证配色稳定性
+
+## 8. 主题切换验证
+
+- [ ] 8.1 在统计 V2 页面切换主题（亮色 ↔ 暗色）
+- [ ] 8.2 确认页面配色立即同步更新
+- [ ] 8.3 切换到日历 V2 页面，确认配色方案一致
+- [ ] 8.4 验证PWA状态栏颜色与页面背景一致
+
+## 9. 回归测试 - 其他页面不受影响
+
+- [ ] 9.1 访问预算页面（`/budget`），确认配色与修改前一致
+- [ ] 9.2 访问设置页面（`/settings`），确认配色与修改前一致
+- [ ] 9.3 访问统计 V1 页面（`/statistics`），确认配色与修改前一致
+- [ ] 9.4 访问消息页面（`/message`），确认配色与修改前一致
+
+## 10. 代码提交与部署
+
+- [ ] 10.1 使用 Git 查看所有修改的文件，确认仅修改了统计 V2 相关文件
+- [ ] 10.2 编写清晰的 commit message（如："统一统计 V2 和日历 V2 页面配色方案 - 白底/黑底 + 灰卡片"）
+- [ ] 10.3 提交代码到开发分支
+- [ ] 10.4 创建 Pull Request 并附上修改前后的截图对比
+- [ ] 10.5 等待代码 review 并合并到主分支
diff --git a/openspec/config.yaml b/openspec/config.yaml
new file mode 100644
index 0000000..392946c
--- /dev/null
+++ b/openspec/config.yaml
@@ -0,0 +1,20 @@
+schema: spec-driven
+
+# Project context (optional)
+# This is shown to AI when creating artifacts.
+# Add your tech stack, conventions, style guides, domain knowledge, etc.
+# Example:
+#   context: |
+#     Tech stack: TypeScript, React, Node.js
+#     We use conventional commits
+#     Domain: e-commerce platform
+
+# Per-artifact rules (optional)
+# Add custom rules for specific artifacts.
+# Example:
+#   rules:
+#     proposal:
+#       - Keep proposals under 500 words
+#       - Always include a "Non-goals" section
+#     tasks:
+#       - Break tasks into chunks of max 2 hours
diff --git a/qodana.yaml b/qodana.yaml
deleted file mode 100644
index f8c5909..0000000
--- a/qodana.yaml
+++ /dev/null
@@ -1,46 +0,0 @@
-#-------------------------------------------------------------------------------#
-#               Qodana analysis is configured by qodana.yaml file               #
-#             https://www.jetbrains.com/help/qodana/qodana-yaml.html            #
-#-------------------------------------------------------------------------------#
-
-#################################################################################
-#              WARNING: Do not store sensitive information in this file,        #
-#               as its contents will be included in the Qodana report.          #
-#################################################################################
-version: "1.0"
-
-#Specify IDE code to run analysis without container (Applied in CI/CD pipeline)
-ide: QDNET
-
-#Specify inspection profile for code analysis
-profile:
-  name: qodana.starter
-
-#Enable inspections
-#include:
-#  - name: <SomeEnabledInspectionId>
-
-#Disable inspections
-#exclude:
-#  - name: <SomeDisabledInspectionId>
-#    paths:
-#      - <path/where/not/run/inspection>
-
-#Execute shell command before Qodana execution (Applied in CI/CD pipeline)
-#bootstrap: sh ./prepare-qodana.sh
-
-#Install IDE plugins before Qodana execution (Applied in CI/CD pipeline)
-#plugins:
-#  - id: <plugin.id> #(plugin id can be found at https://plugins.jetbrains.com)
-
-# Quality gate. Will fail the CI/CD pipeline if any condition is not met
-# severityThresholds - configures maximum thresholds for different problem severities
-# testCoverageThresholds - configures minimum code coverage on a whole project and newly added code
-# Code Coverage is available in Ultimate and Ultimate Plus plans
-#failureConditions:
-#  severityThresholds:
-#    any: 15
-#    critical: 5
-#  testCoverageThresholds:
-#    fresh: 70
-#    total: 50