2026-01-07 23:11:44 +08:00
|
|
|
|
# 协作规则
|
|
|
|
|
|
|
2026-01-08 19:52:43 +08:00
|
|
|
|
## 工作流程
|
|
|
|
|
|
|
|
|
|
|
|
本项目采用基于单一真源 (Single Source of Truth) 的 Workflow，所有决策和文档均以 `docs/` 目录为中心。
|
|
|
|
|
|
|
|
|
|
|
|
### 开发流程
|
|
|
|
|
|
|
|
|
|
|
|
1. **需求分析**: 所有需求必须在 `docs/requirements/` 目录中记录
|
|
|
|
|
|
2. **设计决策**: 架构变更必须通过 ADR (Architectural Decision Record) 流程
|
|
|
|
|
|
3. **提示词优先**: 复杂操作必须先在 `docs/prompts/` 中创建 Prompt 模板
|
|
|
|
|
|
4. **会话记录**: 每次重要操作必须在 `docs/sessions/` 中记录执行过程
|
|
|
|
|
|
5. **迭代复盘**: 每个迭代结束后必须在 `docs/retros/` 中进行复盘
|
|
|
|
|
|
|
|
|
|
|
|
### 代码贡献
|
|
|
|
|
|
|
|
|
|
|
|
1. **分支管理**: 基于功能创建分支，分支名格式为 `feature/xxx` 或 `fix/xxx`
|
|
|
|
|
|
2. **提交规范**: 提交信息必须清晰描述变更内容，参考以下格式：
|
|
|
|
|
|
- `feat: 新增功能描述`
|
|
|
|
|
|
- `fix: 修复问题描述`
|
|
|
|
|
|
- `docs: 更新文档描述`
|
|
|
|
|
|
- `refactor: 重构代码描述`
|
|
|
|
|
|
3. **代码风格**: 遵循项目现有的代码风格和命名规范
|
|
|
|
|
|
4. **测试要求**: 新增功能必须包含相应的测试用例
|
|
|
|
|
|
5. **文档更新**: 代码变更必须同步更新相关文档
|
|
|
|
|
|
|
|
|
|
|
|
### 文档规范
|
|
|
|
|
|
|
|
|
|
|
|
1. **唯一入口**: 所有文档必须在 `docs/index.md` 中添加链接
|
|
|
|
|
|
2. **模板使用**: 必须使用 `docs/` 目录中提供的模板文件
|
|
|
|
|
|
3. **链接引用**: 文档间引用必须使用相对路径链接
|
|
|
|
|
|
4. **版本控制**: 文档变更必须通过 Git 进行版本控制
|
|
|
|
|
|
|
|
|
|
|
|
### Canvas 维护规范
|
|
|
|
|
|
|
|
|
|
|
|
1. **同步更新**: 修改代码逻辑时必须同步更新 `docs/Authentication.canvas` 中的对应部分
|
|
|
|
|
|
2. **视觉一致性**: 确保 Canvas 中的架构图与实际代码结构保持一致
|
|
|
|
|
|
3. **节点命名**: 遵循现有的节点命名规范，使用 `[[Class Name]]` 格式
|
|
|
|
|
|
4. **链接关系**: 确保节点间的链接关系准确反映代码调用关系
|
|
|
|
|
|
5. **文档引用**: 在代码和文档中引用 Canvas 时，使用相对路径链接
|
|
|
|
|
|
|
|
|
|
|
|
### 审核流程
|
|
|
|
|
|
|
|
|
|
|
|
1. **代码审核**: 所有代码变更必须经过至少一次审核
|
|
|
|
|
|
2. **文档审核**: 架构决策和重要文档必须经过团队审核
|
|
|
|
|
|
3. **测试验证**: 变更必须通过项目的测试套件
|
|
|
|
|
|
|
|
|
|
|
|
## 沟通渠道
|
|
|
|
|
|
|
|
|
|
|
|
- **问题跟踪**: 使用项目的 issue 系统
|
|
|
|
|
|
- **讨论**: 使用项目的讨论区或团队会议
|
|
|
|
|
|
- **紧急问题**: 直接联系项目负责人
|
|
|
|
|
|
|
|
|
|
|
|
## 行为准则
|
|
|
|
|
|
|
|
|
|
|
|
- 尊重每一位贡献者
|
|
|
|
|
|
- 保持开放和包容的态度
|
|
|
|
|
|
- 专注于解决问题和改进项目
|
|
|
|
|
|
- 提供建设性的反馈
|
