1.格式说明

2.总体开发流程与版本控制规范

分支策略:

• main: 发布/演示版（仅合并经 PR 审核通过的代码）
• dev: 每日集成主线（功能合并后先合到 dev）
• feature/<ISSUE#>-<简短名>: 每个 Issue 对应一个分支
• hotfix/<id>: 紧急修复

合并与审核:

• 所有代码通过 PR 合并，至少 1 名同组成员进行检查
• PR 必须包含：变更说明、关联 Issue、Testing 说明、影响范围

Commit / PR 规范
Commit message 模板：

<type>(<scope>): <简短说明> #<issue-number>

type 可以为：feat / fix / docs / refactor / test / chore
示例:

feat(auth): add login API with JWT #32
fix(ui): adjust result page layout #36

3.语言/框架 代码规范

3.1 后端 (Python / Flask)

• 遵守 PEP8；使用 flake8 做静态检查，black 做格式化
• 命名：模块/文件 snake_case，类 PascalCase，函数/变量 snake_case
• 每个公开函数/方法需补充 docstring；复杂逻辑写清注释或单元测试
• 异常处理：统一 error handler，返回标准 JSON（{code,msg,data}）
• 配置：使用环境变量（.env），敏感信息不入库

3.2 前端 (Vue3 + ElementPlus)

• 使用 ESLint + Prettier，保存时自动格式化
• 组件命名及文件命名均使用PascalCase命名法
• 组件职责单一化，避免过大的单文件组件（SFC）
• 所有网络请求需处理错误并显示友好提示
• 重要交互（上传、保存）需有 loading 与错误回滚策略

4.Issue / PR / Commit 证据规范

• 若成员角色为开发：必须保有 code check-ins（commit/PR），并提供对应 Issue 的内容与链接、以及 commit/PR 的链接或截图
• 若成员角色为测试/其他：必须提供具体结果（测试报告、截图、日志、设计稿等）

5.最低安全、依赖与部署要求

• requirements.txt（后端）与 package.json（前端）必须准确列出依赖版本并提交到仓库
• 私有信息（API Key 等）不得提交到仓库；使用 .env.example 提示配置项