以下为基础共识，所有开发者必须遵守：
-
代码组织：
- 前端代码 →
easydo-frontend/ - 后端代码 →
easydo-server/ - 执行器agent代码 ->
easydo-agent/
- 前端代码 →
-
开发规范：
- 编译调试必须使用 Docker 在容器内完成编译运行后进行,
- ❌ 禁止直接在机器上通过命令操作（除非必要）
- 禁止读取操作其他目录的内容，只能读取当前工作目录的内容
- 在需要调试的时候，需要先停止旧容器，删除旧镜像，再进行编译部署，需要确保部署的是最新代码
- 调试先通过操作浏览器界面进行测试，界面交互逻辑通过后，还需要对接口进行测试，当前后端都测试通过后才算测试通过
- 无需特意保留截图证据,非必要就不要保留截图； 如果验证阶段必须截图，保存路径为 screenshots 目录中
- 没有成本限制，不要考虑折中或者临时方案, 不要考虑分阶段实现，必须按照以最完善的产品为最终目标进行功能实现。
- 如果存在不确定或者发现有更优方案时及时与我沟通确认，不要不懂装懂，一切以实际情况为准，不允许乱回答。
- 尽可能添加代码注释，讲清楚需求和逻辑, 代码需要尽可能复用，尽量减少代码重复。若代码重复，则需要考虑优化代码。
- 在涉及前端交互上的设计时，需要先进行确认，你需要从用户使用者角度进行步骤确认。
- 项目比较复杂，涉及模块概念多，你需要举一反三，仔细查看改动会影响哪些以及会被哪些所影响。尽量不要引入更多中间件，如需引入，需要说明原因并与我沟通确认。
- 目前阶段尚处于快速开发阶段尚未投入生产，无需考虑升级兼容，如遇数据库变更，可以完全重新部署平台。
- 不要主动阅读参考 docs 目录的文档，除非我明确提出要求。
2.1 ## 工作方式
- 在实现前先说明方法。
- 若需求有歧义、风险较高或影响较大，先澄清并等待批准，再开始写代码。
- Plan 只写方案，不写代码。
- 坚持 Spec Coding，不做 Vibe Coding。
- 优先迭代，使用
/loop。 - 完成后执行
/simplify。 - 你是统筹者，先指定一个 Claude 产出 plan。
- 基于 plan 将任务拆分后分配给不同的 Claude 并行或串行执行。
- 所有子任务应保持边界清晰、职责明确、便于独立验证。
- 完成后再指定一个 agent 汇总结果并输出最终报告给我。
2.2 ## 拆分与范围控制
- 将任务拆分为低耦合、可独立验证的子任务，必要时使用
/batch。 - 重复出现 3 次的流程应沉淀为 Skill。
- 任务分配时优先控制单个 agent 的上下文范围，避免把过多背景一次性注入到同一个上下文中。
- 只向负责该子任务的 agent 提供完成任务所必需的最小上下文。
- 跨任务共享信息时，优先传递经过整理的结论、约束和接口，而不是完整过程性上下文。
2.3 ## 质量要求
- 项目早期只保留最小必要质量标准：可运行、可验证、可回滚。
- 优先保证关键路径和高风险改动可验证。
- 处理 bug 时，先复现，再修复并验证。
2.4 ## 纠错与协作
- 被纠正时，识别原因并改进做法；对重复性问题，沉淀为明确规则。
- 实现与审查分离：先完成方案或代码，再独立复核。
- 统筹者负责跟踪各 agent 的输入、输出、依赖关系和验收结果，避免遗漏与重复劳动。
- 汇总报告应至少包含：任务目标、各子任务结果、验证结论、遗留风险、后续建议。
-
技术栈要求：
- 前端：Vue 3 + Composition API
- 后端：Golang + Gin框架
- 每个模块必须包含Dockerfile
-
数据库：
- MariaDB（主数据库）
- Redis（缓存/会话）
- 前端: Vue 3 + Composition API + Element Plus + Vite
- 后端: Go 1.21 + Gin + GORM + MariaDB + Redis
- 每个模块必须包含Dockerfile
- ❌ 禁止直接操作数据库，必须通过Docker
- ❌ 禁止在生产环境调用
autoMigrate()或任何运行时自动建表/自动迁移逻辑 - ❌ 禁止在 models.go 添加业务逻辑
- ❌ 禁止跳过 lint 检查
- demo / 1qaz2WSX (普通用户)
- admin / 1qaz2WSX (管理员)
- test / 1qaz2WSX (普通用户)