# 协作规则

## 工作流程

本项目采用基于单一真源 (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 系统
- **讨论**: 使用项目的讨论区或团队会议
- **紧急问题**: 直接联系项目负责人

## 行为准则

- 尊重每一位贡献者
- 保持开放和包容的态度
- 专注于解决问题和改进项目
- 提供建设性的反馈