# 项目修改工作流

本仓库后续所有项目修改相关需求，都必须遵循以下流程。若用户临时提出的要求与本文件冲突，应先向用户说明冲突点并等待确认。

## 强制时间戳

- 每次开始处理项目修改需求前，先记录开始时间，格式为 `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`。