docs: 强化闭环工作法 — 验证通过才能提交,提交后必须推送
§3.3 闭环工作法改为 6 步:理解→实现→验证→提交→文档同步→推送 §13 反模式新增 3 条:禁止跳过验证、禁止不推送、禁止忘记更新文档
This commit is contained in:
18
CLAUDE.md
18
CLAUDE.md
@@ -129,11 +129,18 @@ erp-server (→ 所有 crate,组装入口)
|
|||||||
|
|
||||||
1. **理解需求** — 确认改动的目标模块和影响范围
|
1. **理解需求** — 确认改动的目标模块和影响范围
|
||||||
2. **最小实现** — 只改必要的代码,保持模块边界
|
2. **最小实现** — 只改必要的代码,保持模块边界
|
||||||
3. **自动验证** — `cargo check` / `cargo test` / `pnpm dev` 必须通过
|
3. **验证通过** — 必须全部通过才可继续:
|
||||||
4. **提交** — 按 §10 规范提交
|
- `cargo check` — 编译无错误
|
||||||
5. **文档同步** — 更新相关文档(如果涉及架构变化)
|
- `cargo test --workspace` — 所有测试通过(有相关测试时)
|
||||||
|
- `pnpm dev` — 前端页面可正常渲染(涉及前端时)
|
||||||
|
- 功能验证 — 启动服务实际测试改动是否生效(涉及 API 或 UI 时)
|
||||||
|
4. **提交** — 验证通过后按 §10 规范提交
|
||||||
|
5. **文档同步** — 更新相关文档(如果涉及架构、接口、模块变化)
|
||||||
|
6. **推送到仓库** — 提交后立即 `git push`,确保远程仓库同步
|
||||||
|
|
||||||
**铁律:步骤 4 是任务完成的硬性条件。不允许"等一下再提交"。**
|
**铁律:**
|
||||||
|
- **步骤 3 验证不通过 = 任务未完成**,不允许跳过验证直接提交。
|
||||||
|
- **步骤 6 推送是强制环节**,不推送就等于没完成。不允许"等一下再推"。
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
@@ -501,6 +508,9 @@ chore(docker): 添加 PostgreSQL 健康检查
|
|||||||
- ❌ **不要**忽略 `version` 字段 — 所有更新操作必须检查乐观锁
|
- ❌ **不要**忽略 `version` 字段 — 所有更新操作必须检查乐观锁
|
||||||
- ❌ **不要**在动态表 SQL 中拼接用户输入 — 使用 `sanitize_identifier` 防注入
|
- ❌ **不要**在动态表 SQL 中拼接用户输入 — 使用 `sanitize_identifier` 防注入
|
||||||
- ❌ **不要**在插件 crate 中直接依赖 erp-auth — 权限注册用 raw SQL,保持模块边界
|
- ❌ **不要**在插件 crate 中直接依赖 erp-auth — 权限注册用 raw SQL,保持模块边界
|
||||||
|
- ❌ **不要**跳过验证直接提交 — 编译/测试/功能验证必须全部通过
|
||||||
|
- ❌ **不要**提交后忘记推送 — 不推送等于没完成,远程仓库必须同步
|
||||||
|
- ❌ **不要**忘记更新文档 — 涉及架构、接口、模块变化时必须同步更新相关文档
|
||||||
|
|
||||||
### 场景化指令
|
### 场景化指令
|
||||||
|
|
||||||
|
|||||||
Reference in New Issue
Block a user