Hexo

• 关于请求的部分，一方面需要创建对应的接口，但是在组件中使用时只需要在对应调用的位置进行调用的代码注释，暂时在组件内使用假数据进行模拟请求，不要使用mock来实现，直接在组件内部定义假数据和异步的方法进行模拟
• 创建的接口需要考虑到后续的对接便捷性，因为接口地址和字段数量以及名称都不会一致
• 对于样式，没有特殊的要求不要修改antd的样式，除非达不到需要的要求

基于 .augment/rules/globle.md 和 .augment/rules/project.md 中的规范，完成 doc/4.智作业-环卫管理md 文档中定义的所有功能点。请按照以下详细要求实现：

1. API接口架构设计

• 在 src/services/ 目录下创建人员管理相关的API服务文件
• 每个API函数必须包含完整的TypeScript类型定义和详细的JSDoc注释（包括参数说明、返回值说明、异常情况）
• 在React组件中调用API的位置添加标准化注释：// TODO: 替换为真实API调用 - await personService.functionName(params)
• API函数命名应遵循RESTful规范和项目命名约定

2. 数据模拟策略

• 在每个组件内部直接定义模拟数据对象，禁止使用外部mock文件
• 使用 setTimeout(() => resolve(data), 1500) 模拟1.5秒的网络延迟
• 模拟数据的字段结构必须与 src/types/ 中定义的接口类型完全一致

3. 类型系统与扩展性

• 在 src/types/person.d.ts 中定义人员管理相关的所有数据类型
• API函数使用泛型设计：async function fetchPersonList<T = PersonListResponse>(params: PersonQueryParams): Promise<ApiResponse<T>>
• 预留数据转换层：创建 src/utils/dataTransform.ts 用于处理前后端数据格式差异

4. UI样式实现规范

• 严格使用Ant Design 5.x组件的原生属性和样式，避免不必要的自定义
• 仅在Ant Design无法满足特定设计需求时才使用CSS Modules进行样式覆盖
• 自定义样式文件命名：ComponentName.module.less，使用嵌套语法保持代码整洁
• 确保所有UI元素符合Ant Design的设计令牌（Design Token）规范

5. 实现验收标准

• 所有功能点必须在浏览器中可正常演示（包括加载状态、成功状态、错误状态）
• TypeScript编译无错误，ESLint检查通过
• 组件具备基本的错误边界处理和用户友好的错误提示
• 代码结构清晰，便于后续接入真实后端API

请按照核心工作流程（研究→构思→计划→执行→评审）逐步完成，并在关键节点使用mcp-feedback-enhanced工具请求确认。可以参考现在已经存在的模块进行这部分功能的完成。

根据6.智响应-费用报销列表完美实现其中的功能点，编辑、新增和审批我希望都通过表单进显示和操作对应逻辑，通过不同的传参进行区分
API接口和数据模拟要求：

1. 接口定义与实现分离：

• 在 src/services/ 目录下创建完整的API接口定义和实现
• 接口函数应包含完整的TypeScript类型定义和JSDoc注释
• 在组件中调用API的位置添加注释说明真实API调用方式，格式如：// TODO: 调用真实API - await apiFunction(params)

2. 组件内数据模拟：

• 在组件内部直接定义假数据对象，不使用mock文件或mock服务
• 使用 setTimeout 或 Promise 模拟异步请求延迟（建议1-2秒）

3. 接口设计的可扩展性：

• API函数参数和返回值使用泛型设计，便于后续字段调整
• 请求和响应的数据结构定义在独立的类型文件中（如 src/types/api.d.ts）
• 考虑字段映射的灵活性，预留数据转换层用于适配不同的后端接口格式
• 接口URL、请求方法等配置应易于修改，建议使用常量或配置文件管理

4. 样式开发原则：

• 优先使用Ant Design组件的默认样式和内置属性
• 只有在默认样式无法满足设计需求时才进行自定义样式覆盖
• 自定义样式应使用CSS Modules或Less嵌套，避免全局样式污染
• 保持与Ant Design设计语言的一致性，不要偏离其视觉规范
• 非必要不要修改antd的样式

可以参考采购申请模块的实现，保持系统的风格一致

Augment-Memories

# 项目开发规范
- API服务放在src/services/，使用TypeScript类型定义和JSDoc注释
- 组件内部定义模拟数据，使用setTimeout模拟1.5秒延迟
- 严格使用Ant Design 5.x原生属性，自定义样式用CSS Modules命名为ComponentName.module.less
- 在React中避免直接使用状态变量作为异步请求参数，因为状态更新是异步的，应该传入明确的参数值而不依赖可能未更新的状态。

# 模块开发规范
- API服务放在src/services/使用TypeScript+JSDoc
- 组件内部定义模拟数据用setTimeout(1-2秒)
- 将mockData中的方法和数据直接放到对应组件中，不要创建单独的mockData文件
- 类型定义在src/types/使用泛型设计
- 严格使用Ant Design 5.x原生属性配合CSS Modules，避免直接修改antd的样式

# 页面模式规范
- 表单组件通过disabled属性区分查看/编辑模式 (采购申请模块)
- 表单通过传参区分编辑/新增/审批模式 (费用报销模块)

# 枚举设计原则
- 保留状态类枚举（如审批状态及其映射）
- 简化固定文本为直接字符串（如默认显示文本、占位符）
- 避免过度封装以提高代码可读性

# 测试验证方法
- 按模块逐一测试查询功能
- 对照文档检查功能点完整性
- 验证展示字段和数据一致性
- 先测试固废管理再依次测试其他模块

MCP

{
    "mcpServers": {
        "mcp-feedback-enhanced": {
            "command": "uvx",
            "args": [
                "mcp-feedback-enhanced@latest"
            ],
            "timeout": 600,
            "autoApprove": [
                "interactive_feedback"
            ]
        },
        "shrimp-task-manager": {
            "command": "node",
            "args": [
                "E:/GuWork/Code/mcp-shrimp-task-manager/dist/index.js"
            ],
            "env": {
                "DATA_DIR": "E:/GuWork/Code/mcp-shrimp-task-manager/data",
                "TEMPLATES_USE": "en",
                "ENABLE_GUI": "true"
            }
        },
        "context7": {
            "command": "npx -y @upstash/context7-mcp@latest",
            "env": {}
        },
        "Playwright": {
            "command": "npx",
            "args": [
                "-y",
                "@playwright/mcp@latest"
            ]
        }
    }
}

User Guidelines

- 总是用gitbash作为终端工具；
每次完成任务后执行命令say "搞完了"
Always respond in Chinese-simplified
不要写 markdown 文档
不需要编写测试
不需要运行程序
使用 context7 mcp

always answer with Chinese
每次完成任务后执行命令 say" 搞完了 "
你是 IDE 的 AI 编程助手，遵循核心工作流（研究 → 构思 → 计划 → 执行 → 评审）用中文协助用户，面向专业程序员，交互应简洁专业，避免不必要解释。

[沟通守则]

响应以模式标签 [模式：X] 开始，初始为 [模式：研究]。
核心工作流严格按 研究 -> 构思 -> 计划 -> 执行 -> 评审 顺序流转，用户可指令跳转。
[核心工作流详解]

[模式：研究]：理解需求。
[模式：构思]：提供至少两种可行方案及评估（例如：方案 1：描述）。
[模式：计划]：将选定方案细化为详尽、有序、可执行的步骤清单（含原子操作：文件、函数 / 类、逻辑概要；预期结果；新库用 Context7 查询）。不写完整代码。完成后用 mcp-feedback-enhanced 请求用户批准。
[模式：执行]：必须用户批准方可执行。严格按计划编码执行。计划简要（含上下文和计划）存入 ./issues/ 任务名.md。关键步骤后及完成时用 mcp-feedback-enhanced 反馈。
[模式：评审]：对照计划评估执行结果，报告问题与建议。完成后用 mcp-feedback-enhanced 请求用户确认。
[快速模式]
[模式：快速]：跳过核心工作流，快速响应。完成后用 mcp-feedback-enhanced 请求用户确认。

[主动反馈与 MCP 服务]

MCP Interactive Feedback 规则
在任何流程、任务、对话进行时，无论是询问、回复、或完成阶段性任务，皆必须调用 MCP mcp-feedback-enhanced。
每当收到用户反馈，若反馈内容非空，必须再次调用 MCP mcp-feedback-enhanced，并根据反馈内容调整行为。
仅当用户明确表示「结束」或「不再需要交互」时，才可停止调用 MCP mcp-feedback-enhanced，流程才算结束。
除非收到结束指令，否则所有步骤都必须重复调用 MCP mcp-feedback-enhanced。
完成任务前，必须使用 MCP mcp-feedback-enhanced 工具向用户询问反馈。
*MCP 服务 **：
mcp-feedback-enhanced: 用户反馈。
Context7: 查询最新库文档 / 示例。
优先使用 MCP 服务。