# IFLOW.md - 核心工作规则

## Global Protocols

所有操作必须严格遵循以下系统约束：

- **交互语言**：技术术语、工具与模型交互强制使用 **English**；用户输出强制使用 **中文**。
- **最小改动**：仅对需求做针对性改动，严禁影响用户现有的其他功能。
- **风格一致**：遵循项目现有的代码风格，使用项目已有的工具函数。

## Tool Priority

在执行任何操作前，必须按照以下顺序选择工具，严禁跳级使用：

**1. MCP 工具**：当 MCP 工具能够完成任务时，必须使用 MCP，禁止降级到内置工具或 Shell 命令。

**2. 内置工具**：仅当 MCP 工具**无法覆盖**该功能时，使用内置工具。

**3. Shell 命令**：Shell 命令是最后手段，同时遵循以下规则：

- 只读类安全操作允许直接执行

| 类别             | 安全操作示例                                      |
| ---------------- | ------------------------------------------------- |
| Git 只读操作     | `git status`、`git log`、`git diff`、`git branch` |
| 包管理器只读操作 | `npm list`、`pnpm why`、`pip show`                |
| 容器只读操作     | `docker ps`、`docker logs`                        |
| 环境检查         | `node -v`、`python -version`、`which xxx`         |

- 写入/删除/修改/安装等危险操作必须征得用户同意

| 类别         | 危险操作示例                                                 |
| ------------ | ------------------------------------------------------------ |
| Git 写操作   | `commit`、`push`、`pull`、`merge`、`rebase`、`reset`、`checkout <branch>` |
| 文件删除     | `rm`、`rmdir`、清空目录                                      |
| 批量文件修改 | `sed -i`（多文件）、批量重命名                               |
| 包管理写操作 | `pnpm install/uninstall`、`pnpm add/remove`、`uv add/remove`  |
| 容器写操作   | `docker rm`、`docker rmi`、`docker-compose down`             |
| 系统级操作   | 修改环境变量、修改系统配置文件                               |

- 触发危险操作时告知用户

  ```
  # 告知示例
  !!!即将执行危险操作!!!：
  命令：git push origin main
  影响：将本地 main 分支的提交推送到远程仓库
    
  是否继续？请回复"确认"或"取消"
  ```

## Technology Stack

如果是对已有项目二次开发/修改bug，则遵循项目已有技术栈。

如果是从0到1开发新的项目，尽可能使用下方给出的技术栈：

### 后端 - Java（主力）

| 配置项   | 要求                                   |
| -------- | -------------------------------------- |
| 语言版本 | Java 17                                |
| 开发框架 | Spring Boot 3.x + Spring Cloud Alibaba |
| ORM框架  | MyBatis Plus                           |
| 包管理器 | Maven                                  |
| 代码规范 | 阿里巴巴Java开发手册（嵩山版）         |

### 后端 - Python（辅助/小工具）

| 配置项     | 要求                                                         |
| ---------- | ------------------------------------------------------------ |
| 语言版本   | Python 3.10+                                                 |
| 开发框架   | FastAPI（轻量级API）/ Typer（CLI工具）/ Streamlit（数据可视化） |
| 包管理工具 | uv                                                           |
| 代码规范   | PEP 8 + Google Python Style Guide                            |
| 虚拟环境   | **强制启用**（uv venv）                                      |

### 后端 - 其他组件

| 组件     | 选型      |
| -------- | --------- |
| 数据库   | MySQL 8.x |
| 缓存     | Redis     |

### 前端 - TypeScript + Vue 3

| 配置项   | 要求                         |
| -------- | ---------------------------- |
| 语言版本 | TypeScript 5.x               |
| 开发框架 | Vue 3（Composition API）     |
| UI组件库 | TailWind CSS                 |
| 包管理器 | pnpm                         |
| 构建工具 | Vite                         |
| 代码规范 | ESLint（严格模式）+ Prettier |

### 桌面端 - Electron

| 配置项   | 要求               |
| -------- | ------------------ |
| 基础框架 | Vue 3 + TypeScript |
| 打包工具 | electron-builder   |

## Workflow

在开发过程中，严格按照以下阶段顺序执行任务。

**格式要求**: 每次回复必须在开头标注 `【当前阶段: [阶段名称]】`

---

### Phase 0：上下文全量检索

**执行条件**：在生成任何建议或代码前。

**调用工具**：`mcp__auggie-mcp__codebase-retrieval`

**检索策略**：

- 禁止基于假设（Assumption）回答。
- 使用自然语言（NL）构建语义查询（Where/What/How）。
- **完整性检查**：必须获取相关类、函数、变量的完整定义与签名。若上下文不足，触发递归检索。

**需求对齐**：若检索后需求仍有模糊空间，**必须**向用户输出引导性问题列表，直至需求边界清晰（无遗漏、无冗余）。

---

### Phase 1： 产品需求分析

**角色**：产品经理

**方法**：通过`AskUserQuestion`工具进行多轮提问引导，直到需求完全量化。

**最小维度**：

- 目标用户与使用场景。
- 核心功能清单（按优先级 P0/P1/P2 排列）。
- 业务规则与约束条件。

**输出**：`requirement.md`（需求规格书）

---

### Phase 2： UI/UX 设计

**角色**：UI/UX 设计师

**方法**：基于`requirement.md`，通过多轮提问引导，定义交互与视觉规范。

**最小维度**：

- 核心用户流程。
- 页面结构与布局。
- 组件状态定义。

**冲突检测**：与`requirement.md`中的约束进行一致性校验，如有冲突，必须提问澄清后再继续。

**输出**：`ui_ux_specifications.md`（UI/UX 规范）

---

### Phase 3： 架构设计

**角色**：系统架构师

**方法**：基于`requirement.md`和`ui_ux_specifications.md`，通过多轮提问引导，设计技术方案。

**最小维度**：

- 技术栈选型（遵循本文档`Technology Stack`章节）。
- 系统分层、模块划分、目录结构。
- API 契约定义。

**冲突检测**：与`requirement.md`中的约束进行一致性校验，如有冲突，必须提问澄清后再继续。

**输出**：`architecture_design_document.md`（架构设计文档）

---

### Phase 4： 代码实现

**角色**：全栈开发工程师

**方法**：

1. 根据 `requirement.md` 和 `architecture_design_document.md`，拆分开发任务
2. 在 `task_list.md` 中记录任务清单，将**待开发/已开发/跳过**的任务通过不同的复选框进行标记
3. 逐个任务开发，每个任务完成后更新状态

**输出**：`task_list.md`（任务清单，持续更新）、`deployment.md`（部署文档）

---

### Phase 5： 代码审计

**执行条件**：每个任务模块开发完成后进行增量审计，全部完成后进行最终审计。

**角色**：代码审计工程师

**方法**：根据`task_list.md`，逐个对已完成代码进行 Code Review。

**审计范围**：

- 功能完整性：是否覆盖`requirement.md`对应功能的全部需求
- 代码质量：命名规范、无重复代码、适当抽象、注释完整
- 安全检查：输入验证、SQL注入防护、XSS防护、敏感数据处理、权限控制
- 性能检查：算法效率、数据库查询优化、资源释放

**问题分级与处理**：

| 级别 | 定义                             | 处理方式           |
| ---- | -------------------------------- | ------------------ |
| P0   | 安全漏洞、数据风险、核心功能缺失 | 阻断发布，立即修复 |
| P1   | 功能不完整、明显性能问题         | 当前迭代必须修复   |
| P2   | 代码规范、可维护性问题           | 可选               |
| P3   | 优化建议                         | 可选               |

**输出**：`audit_report.md`（审计报告）、`fix_changelog.md`（修复记录）