mirror of
https://github.com/kuaifan/dootask.git
synced 2025-12-10 18:02:55 +00:00
no message
This commit is contained in:
kuaifan
parent
66252072c7
commit
10925d3a47
80
.cursor/rules/001-graphiti-mcp.mdc
Normal file
80
.cursor/rules/001-graphiti-mcp.mdc
Normal file
@ -0,0 +1,80 @@
|
||||
---
|
||||
description: Graphiti MCP 记忆使用规范（dootask 项目）
|
||||
globs: []
|
||||
alwaysApply: true
|
||||
---
|
||||
|
||||
- **总体目标：把 Graphiti 当作本项目的「长期记忆」**
|
||||
- 在本项目中，Graphiti MCP 负责持久化：用户偏好（Preferences）、工作流程/习惯（Procedures）、重要约束（Requirements）以及关键事实/关系（Facts）。
|
||||
- 使用 Graphiti 的目标是：跨对话、跨任务保持一致的行为和决策，而不是简单地「多记一点东西」。
|
||||
- 本项目的 Graphiti `group_id` **统一固定为** `dootask-main`，所有读写操作都应显式使用该 group（或依赖 MCP 服务器已配置好的默认 group）。
|
||||
|
||||
- **任务开始前：先查已有记忆**
|
||||
- 在开始任何实质性工作（写代码、设计方案、做大改动）前，优先调用：
|
||||
- `mcp_graphiti-mcp_search_nodes`：搜索与当前任务相关的偏好（Preference）、流程（Procedure）、需求（Requirement）等节点，**优先传入** `group_ids: ["dootask-main"]`。
|
||||
- `mcp_graphiti-mcp_search_memory_facts`：搜索与当前任务相关的事实与实体间关系，**优先传入** `group_ids: ["dootask-main"]`。
|
||||
- **搜索策略：**
|
||||
- 查询语句中尽量包含：任务类型（如「Bug 修复」「重构」「新功能设计」）、涉及模块（如「任务管理」「评论」「WebSocket」「Docker」）、以及「dootask」关键词。
|
||||
- 对于复杂任务，同时进行节点搜索和事实搜索，并在阅读结果后再决定具体实现方案。
|
||||
- **使用已有知识：**
|
||||
- 如果找到与当前任务高度相关的偏好/流程/约束，应优先遵循这些既有规则，而不是从零开始设定新习惯。
|
||||
- 如发现多个偏好或流程相互冲突，应在回复中简要说明冲突，并基于上下文（时间、新旧程度、显式优先级）做出合理选择。
|
||||
|
||||
- **写入记忆：什么时候需要调用 `mcp_graphiti-mcp_add_memory`**
|
||||
- **用户偏好（Preferences）：**当用户明确或隐含表达持续性的偏好时，应立即写入记忆。例如：
|
||||
- 语言偏好：如「所有回答使用中文」「代码注释使用英文」。
|
||||
- 输出格式偏好：如「需要分步骤说明」「统一使用 Markdown 标题结构」。
|
||||
- 技术栈偏好：如「优先使用 Laravel 原生特性」「前端优先使用原项目已有的 Vue 组件」。
|
||||
- **工作流程 / 习惯（Procedures）：**
|
||||
- 当用户描述「以后都按这个流程来」或在项目层面形成稳定流程（例如「先写测试再实现」「所有接口加统一错误码说明」），应将该流程拆解为清晰步骤写入记忆。
|
||||
- **约束 / 决策（Requirements）：**
|
||||
- 与项目长期有效的决策或约束相关时（如「不再支持 PHP 7.x」「前端打包使用 Vite 而非 Webpack」），应作为需求/约束写入。
|
||||
- **关键事实与关系（Facts）：**
|
||||
- 例如：重要模块边界约定、服务之间的调用关系、与外部系统（如 AgoraIO、ZincSearch）的集成方式等。
|
||||
- **写入内容的组织建议：**
|
||||
- 默认使用 `source: "text"`，在 `episode_body` 中使用简洁、结构化的自然语言，包含：
|
||||
- 背景（Context）——来自哪次任务/对话，解决了什么问题。
|
||||
- 类型（Type）——偏好 / 流程 / 约束 / 事实。
|
||||
- 范围（Scope）——例如「dootask 后端任务模块」「docker 部署」「桌面端 electron 打包」。
|
||||
- 具体内容（Details）——条目化描述，方便后续检索和理解。
|
||||
- 当需要存储明确结构化数据时，可以使用 `source: "json"`，确保 `episode_body` 是合法的 JSON 字符串。
|
||||
- 所有写入操作默认应使用 `group_id: "dootask-main"`，只在有非常明确的跨项目需求时才考虑其他 group（目前 dootask 项目不建议这么做）。
|
||||
|
||||
- **更新与更正记忆**
|
||||
- 如果用户**改变了偏好或流程**（例如从「总是返回详细解释」改为「只要简洁答案」）：
|
||||
- 新建一条描述最新偏好/流程的 episode，并在其中说明这是对旧习惯的更新。
|
||||
- 在后续决策时，优先采用最新一条、最明确的偏好/流程。
|
||||
- 如果用户明确要求「忘记」或「不再使用」某些记忆：
|
||||
- 通过适当的 Graphiti MCP 删除或更正接口（如 `mcp_graphiti-mcp_delete_episode` 或 `mcp_graphiti-mcp_delete_entity_edge`）进行处理，避免继续引用无效信息。
|
||||
- 尽可能避免直接修改历史事实，而是通过新增 episode 记录「更正」或「废弃」说明，以保留决策轨迹。
|
||||
|
||||
- **在工作过程中如何使用图谱中的知识**
|
||||
- **尊重偏好：**在代码实现、文档撰写、回答风格上，优先对齐已存储的用户偏好；如需临时偏离，应在回复中说明原因。
|
||||
- **遵循流程：**如图谱中存在与当前任务高度相关的流程（Procedure），应按步骤执行，并在必要时说明是否对流程做了调整。
|
||||
- **利用事实：**
|
||||
- 在理解系统行为、模块边界、历史决策时优先查阅已存储的事实，减少对代码的「重新摸索」。
|
||||
- 对于跨模块改动（如同时涉及 `app/Module`、`docker`、`electron` 等目录），尤其应查找是否已有相关决策或踩坑记录。
|
||||
|
||||
- **适用于 dootask 项目的具体约定**
|
||||
- **领域术语统一：**
|
||||
- 在 episode 中描述业务时，优先使用本项目已有的术语：项目、任务、子任务、评论、对话、WebSocket、看板、工时报表等。
|
||||
- 如果是针对特定模块的约定（例如「ZincSearch 搜索索引字段约束」），在 Scope 中标明模块名，便于后续检索。
|
||||
- **跨平台特性：**
|
||||
- 对涉及 Web、Electron 客户端、Docker 部署等多端一致性的规则，应在同一 episode 中写明所有相关端，避免分散且难以关联。
|
||||
- **重要变更要总结：**
|
||||
- 对于大范围重构或关键特性上线（例如「任务模块权限系统重构」），在完成后为该任务写一条简洁的总结 episode，包含：
|
||||
- 变更动机
|
||||
- 核心设计决策
|
||||
- 受影响的主要文件/模块
|
||||
- 后续需要注意的坑或约束
|
||||
|
||||
- **不要写入 Graphiti 的内容（应只做临时使用）**
|
||||
- 含有敏感信息的内容：例如访问密钥、数据库密码、用户隐私数据等，**不得**写入 Graphiti。
|
||||
- 只与当前一次任务相关、不会在未来复用的短期信息：例如一次性调试日志、临时命令输出等，只需在当前对话中使用，不应持久化。
|
||||
- 特别巨大的原始数据（如完整日志文件、长脚本全文）：应只存储精炼后的摘要与关键结论，而不是原始内容。
|
||||
|
||||
- **与本项目其他工具的配合**
|
||||
- 在需要长期复用的信息上，优先使用 Graphiti MCP，而不是仅依赖对话上下文或一次性注释。
|
||||
- 当对某个偏好/流程是否已存储存在疑问时，**先搜索再写入**：避免重复创建大量语义相近但难以区分的条目。
|
||||
- 始终将 Graphiti 视为「事实来源之一」：如与代码现状冲突，应以代码实际为准，并在必要时通过新增 episode 更新事实。
|
||||
|
||||
88
.cursor/rules/010-dootask-dev-process.mdc
Normal file
88
.cursor/rules/010-dootask-dev-process.mdc
Normal file
@ -0,0 +1,88 @@
|
||||
---
|
||||
description: dootask 开发流程与代码结构约定（controller + model + module + Vue2 + ./cmd）
|
||||
globs: []
|
||||
alwaysApply: true
|
||||
---
|
||||
|
||||
- **整体目标**
|
||||
- 统一 dootask 项目的开发流程和代码结构约定，让后续协作、排障和重构更可预期。
|
||||
- 为 Cursor 中的 AI 助手提供清晰的「在本仓库应该怎么查代码、怎么改代码、怎么跑命令」的行为规范。
|
||||
|
||||
- **一、在 Cursor 中处理需求的通用流程**
|
||||
- 处理任何一个需求或问题时，AI 助手应优先按下面的步骤行动：
|
||||
1. **澄清问题与范围**：从用户问题中提炼出是「Bug 修复」「新功能」「重构」还是「排查/文档」类任务，大概会影响哪些模块（如任务、项目、对话、WebSocket、报表等）。
|
||||
2. **定位相关代码**：使用 `grep` / `codebase_search` / `read_file` 等工具，优先阅读路由、控制器、模型、模块，以及前端 `resources/assets/js` 下的相关页面或组件。
|
||||
3. **设计修改方案**：在代码层面给出清晰的改动思路（改哪些文件、增加/修改哪些类和方法），必要时在回复中简单说明权衡点。
|
||||
4. **实施改动并自检**：通过 `apply_patch` 修改代码，保持控制器+模型+模块结构清晰；需要运行命令时，统一通过 `./cmd ...`（如 `./cmd artisan ...`、`./cmd dev`、`./cmd build` 等），并使用 `read_lints` 等工具做基础检查。
|
||||
5. **考虑长期沉淀**：对于「以后会反复遇到」的流程、约束或经验，可以再参考 `001-graphiti-mcp.mdc` 中的约定，选择性地写入 Graphiti（`group_id: "dootask-main"`），但 Graphiti 不是每次任务的必选步骤。
|
||||
|
||||
- **二、后端代码结构约定：Controller + Model + Module**
|
||||
- **Controller（控制器，`app/Http/Controllers`）**
|
||||
- 负责：路由入口、参数接收与基础验证、调用对应的模型/模块、最终组装 API 响应。
|
||||
- 原则：控制器内尽量保持「薄」，只做请求编排，不堆积复杂业务逻辑。
|
||||
- 错误处理：业务异常优先使用 `App\Exceptions\ApiException` 抛出，由全局 Handler 统一转换成标准 JSON 响应。
|
||||
- **Model（模型，`app/Models`）**
|
||||
- 负责：数据表结构映射、关系定义（relations）、访问器/修改器、自定义查询 Scope 等「数据层」逻辑。
|
||||
- 原则：避免在模型方法中塞入大量跨业务的流程控制逻辑，复杂业务应下沉到模块中。
|
||||
- **Module（模块，`app/Module`）**
|
||||
- 负责：承载跨控制器、跨模型的业务逻辑，以及独立的功能子域。
|
||||
- 适用场景示例：
|
||||
- 外部服务集成：如 `AgoraIO/*`、`ZincSearch/*` 等第三方接口与搜索封装。
|
||||
- 通用工具与能力：如 `Lock.php`（分布式锁）、`RandomColor.php`、`TextExtractor.php`、`Image.php` 等。
|
||||
- 业务协作逻辑：项目/任务/对话等领域中，跨多个模型的复杂操作，可抽象为专门的模块方法。
|
||||
- 原则：
|
||||
- 新增较复杂的业务功能时，优先考虑创建/扩展 Module，而不是在 Controller 或 Model 中堆砌流程。
|
||||
- Module 尽量保持「单一职责」与「可复用」，命名上能直接反映其业务或能力作用。
|
||||
- 与长期约定的联动：
|
||||
- 对于关键 Module（如权限相关、搜索相关、外部系统对接），在设计上应尽量保持单一职责和清晰边界；如需记录长期约定，可参考 `001-graphiti-mcp.mdc` 使用 Graphiti 做补充说明。
|
||||
- **运行环境：Laravel + LaravelS（Swoole）**
|
||||
- 本项目通过 LaravelS 将 Laravel 运行在 Swoole 常驻进程中，与传统「每请求重启框架」的 PHP-FPM 模式不同。
|
||||
- 注意事项（AI 在修改后端代码时需特别留意）：
|
||||
- 避免在静态属性、单例、全局变量中存储请求级状态或可变数据，防止请求间数据串联和内存泄漏。
|
||||
- 不要假设构造函数、服务提供者或 `boot()` 方法会在每个请求重新执行；涉及配置、路由等的改动，通常需要通过 `./cmd php restart` 或容器重启后才能生效。
|
||||
- 编写长连接、定时任务、WebSocket 等长生命周期逻辑时，优先复用现有模式（如 `Services`、`Module` 中的实现），并避免使用会长时间阻塞协程/事件循环的操作。
|
||||
|
||||
- **三、数据库与迁移约定**
|
||||
- 表结构变更必须通过 Laravel migration 完成，禁止直接手工修改数据库结构。
|
||||
- 与迁移相关的约定：
|
||||
- 创建迁移文件和执行迁移时，优先使用容器内环境，通过 `./cmd artisan ...`（例如 `./cmd artisan make:migration ...`、`./cmd artisan migrate`）。
|
||||
- 涉及核心表（项目、任务、对话、用户、权限等）的 schema 变更，应在代码注释、迁移命名和提交信息中尽量说明字段含义与兼容性考虑；如属于长期架构决策，可再结合 `001-graphiti-mcp.mdc` 选择性写入 Graphiti。
|
||||
|
||||
- **四、前端开发约定：Vue2 + Vite**
|
||||
- 主前端代码位于 `resources/assets/js`，基于 Vue2 实现单页应用，结构大致包括：
|
||||
- `app.js`、`App.vue`：应用入口与根组件。
|
||||
- `components/`：通用组件与业务组件（如任务看板、文件预览、聊天等）。
|
||||
- `pages/`：页面级组件（登录、项目管理、任务视图、消息、报表等）。
|
||||
- `store/`：全局状态管理。
|
||||
- `routes.js`：路由配置。
|
||||
- 构建与开发命令：
|
||||
- 开发模式：使用 `./cmd dev` 或 `./cmd serve`，内部通过 Vite 启动开发服务器，并自动处理端口与调试模式。
|
||||
- 生产构建：使用 `./cmd build` 或 `./cmd prod`，内部使用 `npx vite build` 产出前端静态资源。
|
||||
- 与后端接口的协作：
|
||||
- 接口调用默认通过 Vuex 的 `call` action 封装：在组件/页面中使用 `this.$store.dispatch("call", {...})` 发起请求；如需新增接口，优先在 `store/actions.js` 中扩展逻辑，而不是在组件中直接调用 `axios/fetch`。
|
||||
- 错误提示、登录态失效、权限校验等跨页面行为，尽量复用已有的全局处理逻辑（如 `AIAssistant.vue`、消息通知组件、全局异常组件等）；如形成稳定的新约定，可按需沉淀到文档或 Graphiti。
|
||||
|
||||
- **五、Electron 相关约定**
|
||||
- 当前项目中 Electron 主要作为桌面入口壳，核心业务逻辑仍在 Web/Vue2 前端与 PHP/Laravel 后端。
|
||||
- Electron 的构建与开发：
|
||||
- 日常开发与调试优先使用 `./cmd electron ...`；仅在需要构建 App 端前端/安装包时，才使用 `./cmd appbuild`。
|
||||
- 原则：
|
||||
- 优先保证 Web 端行为正确，再通过 Electron 壳复用 Web 逻辑。
|
||||
- 若未来扩展 Electron 专有功能（如本地文件访问、系统托盘等），应在代码与文档中说明边界；如属长期约束，可再结合 `001-graphiti-mcp.mdc` 写入 Graphiti。
|
||||
|
||||
- **六、命令行与开发工具统一通过 `./cmd`**
|
||||
- 为了对齐 Docker 环境、避免本地环境差异，项目开发相关命令统一通过根目录的 `./cmd` 脚本执行，包括但不限于：
|
||||
- 启动/停止服务：`./cmd up`、`./cmd down`、`./cmd restart`、`./cmd reup`。
|
||||
- Laravel 工具：`./cmd artisan ...`（迁移、队列、任务、缓存等）。
|
||||
- Composer：`./cmd composer ...`。
|
||||
- PHP 命令：`./cmd php ...`。
|
||||
- 生成 API 文档：`./cmd doc`。
|
||||
- 规则：
|
||||
- 在项目文档、脚本示例和与 AI 的交流中，示例命令尽量使用 `./cmd ...` 形式，而不是直接调用 `php`、`composer`、`npm` 等，保持环境一致性。
|
||||
- 如需对 `./cmd` 脚本进行较大调整（例如新增开发流程或重构子命令），应在提交信息或说明文档中写清动机和影响范围；如这是长期流程变更，可参考 `001-graphiti-mcp.mdc` 选择性写入 Graphiti。
|
||||
|
||||
- **七、与 Graphiti 的关系（简要说明）**
|
||||
- 本规则文件的重点是「在 Cursor 中如何开发 dootask」；Graphiti 作为「长期记忆」工具，仅在需要跨会话、跨任务复用的信息时才使用。
|
||||
- 所有与 dootask 项目相关的 Graphiti 操作应使用 `group_id: "dootask-main"`，具体使用规范见 `001-graphiti-mcp.mdc`。
|
||||
- 当 AI 判断某个流程/约束/事实值得长期记忆时，可结合 `001-graphiti-mcp.mdc` 中的说明，主动调用对应 MCP 工具进行写入。
|
||||
|
||||
3
.gitignore
vendored
3
.gitignore
vendored
@ -23,6 +23,9 @@
|
||||
vars.yaml
|
||||
|
||||
# IDE and editor files
|
||||
.cursor/*
|
||||
!.cursor/rules/
|
||||
!.cursor/rules/**
|
||||
.idea
|
||||
.vscode
|
||||
.windsurfrules
|
||||
|
||||
@ -716,7 +716,6 @@ export default {
|
||||
},
|
||||
}).then(_ => {
|
||||
$A.messageSuccess('保存成功');
|
||||
this.loadCustomMicroMenus();
|
||||
this.$store.dispatch("updateMicroAppsStatus");
|
||||
}).catch(({msg}) => {
|
||||
if (msg) {
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user