leniu-dev 2.0.0

package/.claude/commands/next.md

@@ -0,0 +1,281 @@
+# /next - 下一步建议
+
+作为项目开发顾问，根据当前项目状态，为您建议下一步应该做什么。
+
+## 执行流程
+
+### 第一步：快速扫描项目状态
+
+```bash
+# 查看最近 Git 提交记录
+git log -5 --oneline
+
+# 扫描所有业务模块中的 TODO/FIXME
+Grep pattern: "TODO:|FIXME:" path: sys-canteen/,sys-kitchen/,sys-drp/,sys-common/ glob: "*.java" output_mode: content -B 2
+
+# 检查代码规范问题
+Grep pattern: "package org\.dromara\.|package com\.ruoyi\." path: sys-canteen/,sys-kitchen/,sys-drp/ glob: "*.java" output_mode: files_with_matches
+Grep pattern: "MapstructUtils|ServiceException" path: sys-canteen/,sys-kitchen/,sys-drp/ glob: "*.java" output_mode: files_with_matches
+
+# 扫描 OpenSpec 活跃变更（如果存在 openspec 目录）
+Glob pattern: "openspec/changes/*/tasks.md"
+# 对每个找到的 tasks.md，读取内容检查任务完成状态（[ ] 未完成 / [x] 已完成）
+```
+
+### 第二步：分析开发阶段
+
+根据代码完整性和功能数量判断：
+
+| 阶段 | 特征 | 功能完成率 |
+|------|------|----------|
+| 🟢 初期 | 基础框架搭建，功能模块较少 | < 30% |
+| 🟡 中期 | 核心功能开发中，模块逐步完善 | 30-70% |
+| 🔴 后期 | 功能基本完成，处于优化阶段 | > 70% |
+
+### 第三步：分析 OpenSpec 变更状态（如有）
+
+如果发现 `openspec/changes/` 下有活跃变更：
+
+1. 读取每个变更的 `tasks.md`，统计未完成任务
+2. 读取 `proposal.md` 获取变更概述
+3. 将未完成的 OpenSpec 任务纳入建议优先级
+
+### 第四步：分类问题和建议
+
+- **紧急问题**：安全漏洞、严重 Bug、编译错误
+- **OpenSpec 待实现**：已拆解但未完成的变更任务
+- **重要问题**：功能缺陷、设计问题、规范问题
+- **优化建议**：性能优化、代码重构、文档完善
+
+---
+
+## 输出格式
+
+```markdown
+# 下一步建议
+
+**分析时间**：YYYY-MM-DD HH:mm
+**分析范围**：全量后端代码
+
+---
+
+## 当前状态
+
+### Git 提交分析
+- **最近一次提交**：[commit message] ([commit hash])
+- **最近在做**：[根据提交记录推断]
+- **提交频率**：[活跃/不活跃]
+
+### 代码状态
+- **开发阶段**：🟡 中期（核心功能开发中）
+- **代码质量**：良好（包名符合 net.xnzn.core.*）
+- **规范问题**：3 个接口缺少 @RequiresAuthentication 注解
+
+### 代码待办统计
+- **TODO 项**：X 个
+- **FIXME 项**：X 个
+- **编译/运行错误**：无
+
+### OpenSpec 变更状态（如有活跃变更）
+- **活跃变更**：X 个
+- **待实现任务**：X 个
+- **变更列表**：
+  - `[变更名]`：X/Y 任务完成（[proposal 概述]）
+
+---
+
+## 建议优先级
+
+### 🔴 高优先级（必须立即处理）
+
+1. **修复 FIXME 问题**
+   - 位置：sys-canteen/.../service/impl/XxxService.java:156
+   - 问题：业务逻辑存在已知错误
+   - 原因：影响核心业务正确性
+   - 影响：可能导致数据异常
+   - **快速修复**：`/check` 找出所有 FIXME 并逐一解决
+
+2. **补充缺失的权限注解**
+   - 位置：sys-canteen 模块 3 个接口
+   - 问题：缺少 @RequiresAuthentication 或 @RequiresGuest 注解
+   - 原因：权限控制不完整
+   - 影响：系统存在未授权访问风险
+   - **快速修复**：`/check canteen` 查出所有问题接口
+
+3. **完善代码规范**
+   - 问题：部分接口 POST 请求未使用 LeRequest<T> 封装
+   - 原因：请求封装规范不一致
+   - 影响：后续维护成本高
+   - **快速修复**：`/check` 全量检查
+
+### 🟡 中优先级（近期应该做）
+
+1. **补充缺失功能模块**
+   - 建议模块：[根据扫描结果列出未完成的业务模块]
+   - 完成率：目前 X%，建议提升到 80%
+   - **快速开发**：`/crud [表名]` 快速生成 CRUD 代码
+
+2. **优化 Service 查询层**
+   - 建议模块：[根据扫描结果列出查询不完善的模块]
+   - 问题：buildWrapper 查询条件需要完善
+   - 价值：提升查询效率，支持更复杂的搜索
+   - **参考代码**：`sys-canteen/.../order/common/service/impl/OrderInfoService.java`
+
+3. **补充接口文档注释**
+   - 建议范围：所有 Controller 接口
+   - 目标：添加 @Api、@ApiOperation Swagger 文档注解、JavaDoc 方法注释
+   - 价值：便于接口文档自动生成
+
+### 🟢 低优先级（可以考虑）
+
+1. **性能优化**
+   - 建议项：添加查询缓存、分页优化
+   - 触发条件：数据量大时
+
+2. **代码重构**
+   - 建议项：提取通用工具类、统一错误处理
+
+3. **单元测试**
+   - 建议项：为核心 Service 添加单元测试
+   - 触发条件：功能稳定后
+
+---
+
+## 具体行动建议
+
+### 如果有未完成的 OpenSpec 变更：
+
+**推荐：继续实现已拆解的任务**
+- 变更名称：`[change-name]`
+- 未完成任务：[列出 tasks.md 中 [ ] 的任务]
+- **快速开始**：
+  ```bash
+  /opsx:apply [change-name]   # 自动实现下一个任务
+  /dev [任务描述]              # 手动实现特定任务
+  ```
+
+### 如果您想继续开发新功能：
+
+**推荐 1：完善业务模块**
+- 建议实现：[根据扫描结果列出未完成的功能]
+- 所属模块：[sys-canteen / sys-kitchen / sys-drp / sys-common]
+- **快速开始**：
+  ```bash
+  /crud [表名]          # 快速生成 CRUD 代码
+  /check [模块名]       # 检查并修复规范问题
+  ```
+
+**推荐 2：开发新的业务功能**
+- 建议实现：[根据项目进展推荐下一个业务功能]
+- **快速开始**：
+  ```bash
+  /dev 功能名称   # 使用向导开发新功能（含表设计）
+  ```
+
+### 如果您想优化代码质量：
+
+**推荐 1：规范检查和修复**
+- 建议优化：修复所有代码规范问题
+- **快速检查**：
+  ```bash
+  /check               # 全量检查
+  /check canteen       # 按模块检查
+  ```
+
+**推荐 2：Service 层优化**
+- 建议优化：完善 buildWrapper 实现，支持更复杂的查询
+- **参考代码**：`sys-canteen/.../order/common/service/impl/OrderInfoService.java`
+
+**推荐 3：注释和文档**
+- 建议优化：添加 JavaDoc 注释
+- 位置：所有 Controller 接口和关键 Service 方法
+
+### 如果您想修复现存问题：
+
+**按严重程度排序的问题列表**：
+
+#### 🔴 严重问题（立即修复）
+- **FIXME 问题**：[根据扫描结果列出 FIXME 位置和内容]
+- **权限注解缺失**：[根据扫描结果列出缺少 @RequiresAuthentication 的接口]
+- **命令**：`/check [模块名]`
+
+#### 🟡 重要问题（本周修复）
+- **LeRequest 封装缺失**：[根据扫描结果列出未使用 LeRequest<T> 的 POST 接口]
+- **del_flag 值错误**：[扫描是否有 delFlag=0 的设置]
+- **命令**：`/check [模块名]`
+
+#### 🟢 建议问题（择机修复）
+- **缺少接口文档**：所有 Controller
+- **缺少业务注释**：部分 Service 方法
+- **命令**：逐一完善
+
+---
+
+## 开发建议
+
+### 开发流程建议
+
+1. **明确需求**：使用 `/start` 快速了解项目结构
+2. **检查规范**：使用 `/check` 检查代码质量
+3. **分析进度**：使用 `/progress` 了解完成情况
+4. **开始开发**：使用 `/dev` 或 `/crud` 快速生成代码
+5. **添加待办**：使用 `/add-todo` 跟踪任务
+6. **获取建议**：使用 `/next` 确定下一步方向
+
+### 最佳实践
+
+| 实践 | 说明 |
+|------|------|
+| 四层职责清晰 | Controller 路由 → Business 编排 → Service 单表 → Mapper ORM |
+| 查询构建 | 在 Service 层用 LambdaQueryWrapper 构建，禁止在 Controller 层 |
+| 对象转换 | 使用 BeanUtil.copyProperties()，禁止 MapstructUtils |
+| 权限管理 | 所有接口必须有 @RequiresAuthentication 或 @RequiresGuest |
+| 请求封装 | POST 请求体统一使用 LeRequest<T>，通过 request.getContent() 获取参数 |
+| 注释完整 | 关键方法必须有 JavaDoc 注释 |
+| 定期检查 | 每周至少一次运行 `/check` 和 `/progress` |
+
+### 技术选型建议
+
+| 场景 | 推荐方案 | 理由 |
+|------|--------|------|
+| 快速生成 CRUD | `/crud` 命令 | 已有表结构时最快 |
+| 从零开发功能 | `/dev` 命令 | 包含数据库设计和代码生成 |
+| 代码规范检查 | `/check` 命令 | 及时发现问题 |
+| 项目进度追踪 | `/progress` 命令 | 定期了解完成情况 |
+
+---
+
+## 需要确认的问题
+
+### 如果不确定下一步方向，请回答：
+
+- [ ] **您更希望继续开发功能，还是优化现有代码？**
+  - 选项 A：继续开发新功能（推荐 `/crud` 或 `/dev` 命令）
+  - 选项 B：优化现有代码（推荐 `/check` 和 `/progress` 命令）
+
+- [ ] **是否需要为新开发的功能添加到待办列表中？**
+  - 可使用 `/add-todo` 快速添加
+
+---
+
+## 相关命令
+
+| 命令 | 用途 | 何时使用 |
+|------|------|---------|
+| `/start` | 快速了解项目 | 初次接触项目 |
+| `/check` | 代码规范检查 | 开发完成后、定期检查 |
+| `/progress` | 查看项目进度 | 了解完成情况 |
+| `/next` | 获取建议 | 不知道下一步做什么 |
+| `/dev` | 开发新功能 | 从零开始开发 |
+| `/crud` | 快速生成代码 | 表已存在时 |
+| `/add-todo` | 添加待办任务 | 跟踪任务 |
+
+---
+
+## 说明
+
+- 本建议基于对当前项目代码的分析生成
+- 建议具体且可执行，不空泛
+- 会考虑开发的连贯性和代码质量
+- 如发现紧急问题会明确标注
+- 如不确定用户意图会主动询问

package/.claude/commands/opsx-apply.md

@@ -0,0 +1,147 @@
+# /opsx-apply - 实现 OpenSpec 变更任务
+
+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

package/.claude/commands/opsx-archive.md

@@ -0,0 +1,105 @@
+# /opsx-archive - 归档 OpenSpec 变更
+
+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