- 创建MD/目录结构(architecture/development/standards/specs/bugs/guides/upgrade) - 制定文档命名规范(大写英文+下划线) - 制定文档格式规范(元数据块、结构模板) - 合并27个文档到MD/目录,按类别分类 - 删除旧的docs/目录 - 更新AGENTS.md铁律#5: 文档统一管理 命名规范: - 架构设计: ARCH_<模块>_<描述>.md - 开发计划: PLAN_<类型>_<版本>.md - 国家标准: STD_<标准名称>.md - 技术规范: SPEC_<类型>_<描述>.md - Bug修复: BUG_<编号>_<描述>.md - 使用指南: GUIDE_<主题>.md - 升级记录: UPGRADE_<组件>_<类型>.md
60 lines
1.7 KiB
Markdown
60 lines
1.7 KiB
Markdown
# HealthLink-HIS 铁律
|
||
|
||
## 铁律 #1: 修改完必须测试
|
||
**任何代码修改后,必须完成以下测试才能提交:**
|
||
|
||
### 白盒测试
|
||
- `mvn clean compile` 编译通过
|
||
- 单元测试通过(如有)
|
||
|
||
### 黑盒测试
|
||
- 启动应用,验证无启动报错
|
||
- 测试关键接口(登录、核心业务接口)
|
||
- 验证请求响应正确
|
||
|
||
### 冒烟测试
|
||
- 应用正常启动(端口监听)
|
||
- 健康检查接口返回正常
|
||
- 基础 CRUD 操作正常
|
||
|
||
## 铁律 #2: Flyway 迁移
|
||
但凡遇到有新建表和字段的,通过 Flyway 框架去实现。
|
||
|
||
## 铁律 #3: 先分解再行动
|
||
任何非平凡任务先出 plan 再执行。
|
||
|
||
## 铁律 #4: 验证后信
|
||
每次修改后必须验证编译通过,不信记忆。
|
||
|
||
## 铁律 #5: 文档统一管理
|
||
**所有文档必须存储在 `MD/` 目录中,遵循以下规范:**
|
||
|
||
### 目录结构
|
||
```
|
||
MD/
|
||
├── architecture/ # 架构设计
|
||
├── development/ # 开发计划与记录
|
||
├── standards/ # 国家/行业标准
|
||
├── specs/ # 技术规范与流程
|
||
├── bugs/ # Bug分析与修复记录
|
||
├── guides/ # 使用指南
|
||
└── upgrade/ # 升级记录
|
||
```
|
||
|
||
### 命名规范
|
||
- 文件名使用**大写英文+下划线**(如 `GRADE3A_DETAILED_DESIGN.md`)
|
||
- 不使用中文作文件名
|
||
- 不使用空格分隔单词
|
||
- 版本号标注在文件名末尾(如 `_V2`)
|
||
|
||
### 格式要求
|
||
- 文档头部必须包含元数据块(文档类型、版本、日期)
|
||
- 代码块必须标注语言类型
|
||
- 表格使用标准Markdown格式
|
||
|
||
### 详细规范
|
||
参见 `MD/DOCUMENTATION_STANDARD.md`
|
||
|
||
## 铁律 #6: 测试通过后才提交
|
||
**代码修改必须通过完整测试后才能提交到远程仓库。**
|