2026-05-19-22-59-07 建立代码编纂工作流
This commit is contained in:
@@ -1,60 +1,68 @@
|
||||
# 代码编纂工作流
|
||||
|
||||
本工作流适用于后续所有项目修改相关需求。除非用户明确说明跳过流程，否则每次修改都按以下步骤执行。
|
||||
更新时间：2026-05-19-22-59-07
|
||||
|
||||
本工作流适用于后续所有项目修改相关需求。只要用户提出的是项目修改、修复、重构、部署、文档治理或功能调整，都必须按本流程走；除非用户明确要求跳过其中某一步。
|
||||
|
||||
## 0. 记录开始时间
|
||||
|
||||
- 每次执行前先记录问题开始时间，格式为 `{Year}-{Mon}-{Day}-{Hour}-{Min}-{Sec}`。
|
||||
- 本时间戳用于贯穿需求分析、实现方案、测试方案、经验记录和 Git 提交信息。
|
||||
- 时间以当前执行环境为准。
|
||||
- 同一个时间戳贯穿当次需求分析、实现方案、测试方案、经验记录、commit message 和最终汇报。
|
||||
|
||||
## 1. 阅读工程分析
|
||||
## 1. 阅读或创建工程分析目录
|
||||
|
||||
- 每次修改前阅读或创建 `工程分析/` 文件夹。
|
||||
- 每次修改前确认 `工程分析/` 存在，不存在则创建。
|
||||
- 优先阅读：
|
||||
- `工程分析/代码编纂工作流.md`
|
||||
- `工程分析/工程整体分析.md`
|
||||
- `工程分析/经验记录.md`
|
||||
- 与当前需求相关的历史 `需求分析-*`、`实现方案-*`、`测试方案-*` 文档
|
||||
- 与当前需求相关的历史 `需求分析-*`、`实现方案-*`、`测试方案-*`
|
||||
- 如果发现 `工程分析/` 文档在工作区被删除，应先说明风险，只恢复或重建当次必要的核心文档，不把无关删除混入提交。
|
||||
|
||||
## 2. 写入需求分析
|
||||
|
||||
- 将用户当次需求整理写入：
|
||||
- `工程分析/需求分析-{Year}-{Mon}-{Day}-{Hour}-{Min}-{Sec}.md`
|
||||
- 内容至少包括：
|
||||
- 文档至少包含：
|
||||
- 开始时间
|
||||
- 原始需求摘要
|
||||
- 业务目标
|
||||
- 输入与输出
|
||||
- 影响范围
|
||||
- 关键约束
|
||||
- 风险点
|
||||
- 待确认问题
|
||||
- 待确认问题或默认假设
|
||||
|
||||
## 3. 写入实现方案并等待人工审核
|
||||
## 3. 写入实现方案
|
||||
|
||||
- 将实现方案写入：
|
||||
- `工程分析/实现方案-{Year}-{Mon}-{Day}-{Hour}-{Min}-{Sec}.md`
|
||||
- 文档必须包含：
|
||||
- 文档至少包含：
|
||||
- 实现方案文档路径
|
||||
- 修改目标
|
||||
- 涉及路径
|
||||
- 技术路线
|
||||
- 数据流或交互流程
|
||||
- 执行步骤
|
||||
- 兼容性与回滚方案
|
||||
- 预计文件变更
|
||||
- 人工审核状态
|
||||
- 实现方案写完后必须等待用户二次人工审核确认。
|
||||
- 未收到明确确认前，不执行项目业务代码修改。
|
||||
- 提交与部署策略
|
||||
- 2026-05-07-16-35-52 起，用户已确认“都确认，后续直接搞”。因此默认不在实现方案阶段暂停等待二次确认；若用户明确要求人工审核，则必须等待确认后再执行。
|
||||
|
||||
## 4. 写入测试方案并等待人工审核
|
||||
## 4. 写入测试方案
|
||||
|
||||
- 将测试方案写入：
|
||||
- `工程分析/测试方案-{Year}-{Mon}-{Day}-{Hour}-{Min}-{Sec}.md`
|
||||
- 文档必须包含：
|
||||
- 文档至少包含：
|
||||
- 测试方案文档路径
|
||||
- 静态检查
|
||||
- 单元或集成测试
|
||||
- 构建检查
|
||||
- 关键业务场景验证
|
||||
- 医学影像数据相关边界验证
|
||||
- 回归风险
|
||||
- 人工审核状态
|
||||
- 测试方案写完后必须等待用户二次人工审核确认。
|
||||
- 未收到明确确认前，不执行最终修改方案。
|
||||
- 部署验证
|
||||
- Git/Gitea 备份验证
|
||||
- 风险与回归关注点
|
||||
- 默认不在测试方案阶段暂停等待二次确认；若用户明确要求人工审核，则必须等待确认后再执行。
|
||||
|
||||
## 5. 执行前后维护经验记录
|
||||
|
||||
@@ -73,30 +81,25 @@
|
||||
- Commit message 必须同时包含：
|
||||
- `{Year}-{Mon}-{Day}-{Hour}-{Min}-{Sec}` 时间戳
|
||||
- 本次修改简要描述
|
||||
- 备份完成后提醒用户：文档备份 commit 已完成。
|
||||
- 备份提交时默认只暂存本次相关文档和明确属于本次修改的文件，避免提交无关工作区变化。
|
||||
- 备份完成后必须提醒用户：文档备份 commit 已完成。
|
||||
- 默认远程仓库：
|
||||
- `http://192.168.31.5:5002/admin/REVOXELSEG_DICOM.git`
|
||||
|
||||
## 7. 重新部署
|
||||
|
||||
- 最终修改完成并通过测试后，重新部署本项目。
|
||||
- 若项目只有前端开发环境，默认使用 `WebSite/` 下的脚本：
|
||||
- 优先使用当前项目约定：
|
||||
- `cd WebSite`
|
||||
- `npm run build`
|
||||
- `npm run dev`
|
||||
- 若已有服务进程或部署脚本，优先沿用现有部署方式。
|
||||
- `tmux` 会话 `revoxelseg-dicom`
|
||||
- `npm run serve -- --host 0.0.0.0 --port 4000`
|
||||
- 若端口或会话冲突，先检查并记录实际处理方式。
|
||||
- 部署后至少验证：
|
||||
- `http://127.0.0.1:4000/api/health`
|
||||
- `http://127.0.0.1:4000/`
|
||||
|
||||
## 人工确认口令
|
||||
## 8. 最终汇报
|
||||
|
||||
后续当我完成实现方案和测试方案文档后，需要用户明确回复类似以下内容才继续：
|
||||
|
||||
- `确认实现方案`
|
||||
- `确认测试方案`
|
||||
- `确认执行`
|
||||
|
||||
如果用户对方案提出修改意见，则先更新对应文档，再等待新的确认。
|
||||
|
||||
## 默认执行确认更新
|
||||
|
||||
- 2026-05-07-16-35-52 起，用户已确认“都确认，后续直接搞”。
|
||||
- 后续项目修改需求仍必须记录时间、创建需求分析、实现方案、测试方案、读取经验记录、执行后更新经验记录、备份 commit、重新部署。
|
||||
- 除非用户明确要求暂停或人工审核，后续不再在实现方案和测试方案阶段停等二次确认。
|
||||
- 汇报本次开始时间、修改文件、测试结果、部署地址和 commit 状态。
|
||||
- 如果某一步无法完成，必须说明原因、影响范围和建议下一步。
|
||||
|
||||
Reference in New Issue
Block a user