1adf627c0d
- 基础环境：Docker 部署配置，源码挂载实时同步 - 修复：super_admin 权限补全、登录重定向循环 - 开发：店铺营销账户账单 - 抖音账户（15字段汇总账单） - 开发：店铺营销账户账单 - 淘系支付宝账户（8字段流水账单） - 开发：店铺营销账户账单 - 拼多多账户（7字段流水账单） - 业务页面导航集成：config/business_navigation.php + Business\Pages 控制器 - 各平台独立表结构和视图，互不影响
73 lines
4.6 KiB
Markdown
73 lines
4.6 KiB
Markdown
# CaiWuXiTong 团队通用规则
|
||
|
||
适用范围：本仓库所有成员、所有分支，以及使用 Codex 等 AI 编程工具完成的工作。
|
||
|
||
## 1. 核心原则
|
||
|
||
- 本项目是财务系统。金额、权限、审批、数据导入、数据库迁移和生产配置均属于高风险内容。
|
||
- AI 是协作工具，不是审批人。AI 生成的代码、命令和结论必须由提交人检查并完成实际验证。
|
||
- 不确定当前环境、分支、命令作用或数据范围时，停止操作并向负责人或 Codex 说明现场，不要猜。
|
||
- 一次只完成一个明确任务；不顺手重构、升级依赖或修改无关模块。
|
||
|
||
## 2. 分支与提交
|
||
|
||
- `main` 是稳定主线，禁止直接推送、禁止强推、禁止直接修改。
|
||
- 每项任务都必须从最新 `main` 新建分支；不得长期共用或复用旧任务分支。
|
||
- 分支命名：新功能用 `feature/用户名-任务名`，修复用 `fix/用户名-问题名`，紧急修复用 `hotfix/用户名-问题名`。
|
||
- 示例：`feature/dodo-login`、`fix/wangshu-amount-rounding`。
|
||
- 一个分支只做一个任务。任务完成并合并后，删除该分支；下一项任务重新从 `main` 新建。
|
||
- 提交前必须查看 `git status` 和 `git diff`，确认没有把别人的改动、日志、构建产物、`.env` 或敏感文件带进去。
|
||
- 禁止使用 `git push --force`、`git reset --hard`、`git clean -fd`，除非负责人明确给出目标和操作步骤。
|
||
|
||
## 3. 新人使用 AI 的固定流程
|
||
|
||
1. 先确认任务目标、验收方式、影响范围和不能触碰的模块。
|
||
2. 进入正确项目和分支，先执行 `git status`；看到陌生改动，先停止并说明情况。
|
||
3. 向 AI 提供：任务目标、当前分支、报错或现象、相关文件、不可修改的范围。
|
||
4. 要求 AI 先说明改动计划、涉及文件、风险和验证步骤；确认后再修改。
|
||
5. 修改后查看 diff，并要求 AI 用普通语言解释“改了什么、为什么、怎样测试”。
|
||
6. 在本地或测试环境完成最小有效验证，记录实际结果。
|
||
7. 推送任务分支并发起 PR；不得自行绕过 PR 合并到 `main`。
|
||
|
||
推荐向 AI 提问的模板：
|
||
|
||
```text
|
||
项目：CaiWuXiTong（Laravel/PHP 财务系统）。
|
||
任务：<要实现的功能或要修复的问题>。
|
||
当前分支：<分支名>。
|
||
现场：<报错、复现步骤、相关文件>。
|
||
边界：不要修改 <模块/表/配置>；不要执行删除、部署、生产数据库操作。
|
||
要求：先列出改动计划、风险和验证步骤，等我确认后再改。
|
||
```
|
||
|
||
## 4. PR 与合并
|
||
|
||
- 所有任务分支必须通过 PR 合并到 `main`。
|
||
- PR 作者必须填写：做了什么、Codex 改了哪些文件、怎样测试、是否涉及金额/权限/数据库/配置。
|
||
- PR 至少由另一位成员检查后才能批准；作者不得把“AI 已完成”当作测试结果。
|
||
- 涉及金额计算、权限、导入、数据库迁移、账户或系统配置时，必须在 PR 中明确标注，并由负责人最终确认。
|
||
- 使用仓库默认的 Squash merge（压缩合并）。合并由负责人或指定合并人执行。
|
||
- PR 合并后分支自动删除；不要把已合并分支继续用于新任务。
|
||
|
||
## 5. 测试与问题处理
|
||
|
||
- 修改完成不等于可用。至少验证正常流程、错误输入/无权限场景和本次改动影响的旧功能。
|
||
- 出现冲突、测试失败或 PR 显示落后 `main` 时，不要自行猜命令。先让 AI 只分析同步方案，禁止强推和 rebase；必要时找负责人处理。
|
||
- 提交问题时必须写清：环境、账号角色、复现步骤、实际结果、期望结果和报错截图/日志（脱敏后）。
|
||
|
||
## 6. 数据与安全红线
|
||
|
||
- 不得提交 `.env`、密码、Token、SSH 私钥、数据库连接串、真实财务数据、客户数据或生产日志。
|
||
- 不得把上述内容粘贴到 AI 对话、工单、PR、聊天群或截图中。
|
||
- 不得在不确认环境和影响范围时执行数据库写入、迁移、删除、导入、部署或服务器命令。
|
||
- 任何包含金额、账户、登录凭据、权限或数据库连接的信息都按敏感数据处理。
|
||
- 发现误提交、泄露或错误操作，立即告知负责人；不要自行删除记录掩盖问题。
|
||
|
||
## 7. 本仓库的最小验证要求
|
||
|
||
- 前端改动：至少检查目标页面、正常交互和错误提示。
|
||
- 后端改动：至少执行相关测试或启动后走一次目标接口/页面。
|
||
- 数据库迁移：新人不得自行在共享环境执行；先在 PR 说明影响、验证方式和回滚思路。
|
||
- 未完成验证时，PR 必须明确写“未验证”及原因，不能写“应该没问题”。
|
||
|