2.7 KiB
2.7 KiB
项目修改工作流
本仓库后续所有项目修改相关需求，都必须遵循以下流程。若用户临时提出的要求与本文件冲突，应先向用户说明冲突点并等待确认。
强制时间戳
- 每次开始处理项目修改需求前，先记录开始时间，格式为
YYYY-MM-DD-HH-MM-SS。 - 同一轮需求内创建的
需求分析、实现方案、测试方案文件必须使用同一个开始时间戳。
工程分析目录
- 每次执行前先阅读或创建
工程分析/。 - 优先阅读
工程分析/工程整体分析.md，了解项目结构、运行方式和风险边界。 - 在最终执行修改前，必须阅读
工程分析/经验记录.md，避免重复犯错。
需求分析
- 每次用户提出项目修改需求后，先整理需求并写入：
工程分析/需求分析-YYYY-MM-DD-HH-MM-SS.md - 文档至少包含：原始需求、目标、影响范围、约束、风险点、待确认事项。
实现方案
- 每次进入代码修改前，先将实现方案写入：
工程分析/实现方案-YYYY-MM-DD-HH-MM-SS.md - 文档至少包含：方案路径、涉及文件、执行步骤、回滚思路、风险控制。
- 实现方案写完后必须等待用户二次人工审核确认；未经确认不得修改业务代码。
测试方案
- 每次执行代码修改前，先将测试方案写入：
工程分析/测试方案-YYYY-MM-DD-HH-MM-SS.md - 文档至少包含：测试范围、测试命令、手工验证点、验收标准、无法测试的风险。
- 测试方案写完后必须等待用户二次人工审核确认；未经确认不得修改业务代码。
执行与经验记录
- 用户确认实现方案和测试方案后，方可执行完整修改。
- 执行过程中遇到的关键问题及解决方案，必须追加到
工程分析/经验记录.md。 - 经验记录统一使用四段式：
- A. 具体问题
- B. 产生问题原因
- C. 解决问题方案
- D. 后续如何避免问题
Gitea 备份
- 每次最终执行后，必须将本次文档变更提交到 Gitea。
- commit 信息格式：
YYYY-MM-DD-HH-MM-SS 简要描述 - 远程仓库：
http://admin@192.168.31.5:5002/admin/Head_CT_Morph.git - 不得把 Gitea 密码、令牌或其他凭据写入仓库文件、提交信息、日志文档或可追踪脚本。
- 完成 commit 后，必须提醒用户文档备份 commit 已完成。
重新部署
- 每次最终执行项目修改后，重新部署或重启本项目。
- 当前项目通常需要：
- Python 后端：
cd WebSite && npm run backend - 前端开发服务：
cd WebSite && npm run dev
- Python 后端：
- 若部署方式发生变化，应同步更新
工程分析/工程整体分析.md。