63 lines
2.7 KiB
Markdown
63 lines
2.7 KiB
Markdown
# 项目修改工作流
|
|
|
|
本仓库后续所有项目修改相关需求，都必须遵循以下流程。若用户临时提出的要求与本文件冲突，应先向用户说明冲突点并等待确认。
|
|
|
|
## 强制时间戳
|
|
|
|
- 每次开始处理项目修改需求前，先记录开始时间，格式为 `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`
|
|
- 若部署方式发生变化，应同步更新 `工程分析/工程整体分析.md`。
|