- 创建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
1.7 KiB
1.7 KiB
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: 测试通过后才提交
代码修改必须通过完整测试后才能提交到远程仓库。