2026-05-04-02-38-48 建立代码编纂工作流文档

This commit is contained in:
2026-05-04 02:40:57 +08:00
commit 9106b4d3ea
8 changed files with 362 additions and 0 deletions

30
.gitignore vendored Normal file
View File

@@ -0,0 +1,30 @@
# Dependencies
node_modules/
WebSite/node_modules/
# Build output
dist/
WebSite/dist/
# Local env
.env
.env.*
WebSite/.env
WebSite/.env.*
# Logs
*.log
npm-debug.log*
yarn-debug.log*
yarn-error.log*
pnpm-debug.log*
# Medical/source data assets are excluded from document backup commits by default.
Head_CT_DICOM/
Head_CT_ReConstruct/
# OS/editor noise
.DS_Store
Thumbs.db
.vscode/
.idea/

5
README.md Normal file
View File

@@ -0,0 +1,5 @@
# ReVoxelSeg DICOM
基于模型逆向体素化及 DICOM 分割标注系统。
工程流程与分析文档位于 `工程分析/`

View File

@@ -0,0 +1,96 @@
# 代码编纂工作流
本工作流适用于后续所有项目修改相关需求。除非用户明确说明跳过流程,否则每次修改都按以下步骤执行。
## 0. 记录开始时间
- 每次执行前先记录问题开始时间,格式为 `{Year}-{Mon}-{Day}-{Hour}-{Min}-{Sec}`
- 本时间戳用于贯穿需求分析、实现方案、测试方案、经验记录和 Git 提交信息。
## 1. 阅读工程分析
- 每次修改前阅读或创建 `工程分析/` 文件夹。
- 优先阅读:
- `工程分析/工程整体分析.md`
- `工程分析/经验记录.md`
- 与当前需求相关的历史 `需求分析-*``实现方案-*``测试方案-*` 文档
## 2. 写入需求分析
- 将用户当次需求整理写入:
- `工程分析/需求分析-{Year}-{Mon}-{Day}-{Hour}-{Min}-{Sec}.md`
- 内容至少包括:
- 原始需求摘要
- 业务目标
- 输入与输出
- 影响范围
- 风险点
- 待确认问题
## 3. 写入实现方案并等待人工审核
- 将实现方案写入:
- `工程分析/实现方案-{Year}-{Mon}-{Day}-{Hour}-{Min}-{Sec}.md`
- 文档必须包含:
- 修改目标
- 涉及路径
- 技术路线
- 数据流或交互流程
- 兼容性与回滚方案
- 预计文件变更
- 人工审核状态
- 实现方案写完后必须等待用户二次人工审核确认。
- 未收到明确确认前,不执行项目业务代码修改。
## 4. 写入测试方案并等待人工审核
- 将测试方案写入:
- `工程分析/测试方案-{Year}-{Mon}-{Day}-{Hour}-{Min}-{Sec}.md`
- 文档必须包含:
- 静态检查
- 单元或集成测试
- 关键业务场景验证
- 医学影像数据相关边界验证
- 回归风险
- 人工审核状态
- 测试方案写完后必须等待用户二次人工审核确认。
- 未收到明确确认前,不执行最终修改方案。
## 5. 执行前后维护经验记录
- 最终执行整个修改方案前,必须阅读:
- `工程分析/经验记录.md`
- 修改完成后,将关键问题与解决方案追加到 `工程分析/经验记录.md`
- 每条经验使用四段式结构:
- A. 具体问题
- B. 产生问题原因
- C. 解决问题方案
- D. 后续如何避免问题
## 6. 文档备份提交
- 最终执行后,使用 Git/Gitea 对文档进行备份提交。
- Commit message 必须同时包含:
- `{Year}-{Mon}-{Day}-{Hour}-{Min}-{Sec}` 时间戳
- 本次修改简要描述
- 备份完成后提醒用户:文档备份 commit 已完成。
- 默认远程仓库:
- `http://192.168.31.5:5002/admin/REVOXELSEG_DICOM.git`
## 7. 重新部署
- 最终修改完成并通过测试后,重新部署本项目。
- 若项目只有前端开发环境,默认使用 `WebSite/` 下的脚本:
- `npm run build`
- `npm run dev`
- 若已有服务进程或部署脚本,优先沿用现有部署方式。
## 人工确认口令
后续当我完成实现方案和测试方案文档后,需要用户明确回复类似以下内容才继续:
- `确认实现方案`
- `确认测试方案`
- `确认执行`
如果用户对方案提出修改意见,则先更新对应文档,再等待新的确认。

View File

@@ -0,0 +1,47 @@
# 实现方案
时间戳2026-05-04-02-38-48
## 修改目标
建立项目级代码编纂工作流,并生成初始工程分析文档,使后续项目修改需求有固定执行路径。
## 涉及路径
- `工程分析/代码编纂工作流.md`
- `工程分析/工程整体分析.md`
- `工程分析/需求分析-2026-05-04-02-38-48.md`
- `工程分析/实现方案-2026-05-04-02-38-48.md`
- `工程分析/测试方案-2026-05-04-02-38-48.md`
- `工程分析/经验记录.md`
- `.gitignore`
- `README.md`
## 技术路线
1. 创建 `工程分析/` 目录及工作流文档。
2. 根据当前项目结构写入工程整体分析。
3. 按时间戳写入本次需求、实现、测试文档。
4. 创建经验记录知识库。
5. 初始化 Git 仓库。
6. 配置 Gitea 远程仓库。
7. 提交文档备份 commit。
8.`WebSite/` 执行构建验证。
9. 启动或重启开发部署服务。
## 数据与提交策略
- 默认提交工程文档、项目说明和必要 Git 配置。
- 默认不提交 `Head_CT_DICOM/``Head_CT_ReConstruct/`,避免医学影像数据和 STL 模型进入普通文档备份。
- 默认不提交 `WebSite/node_modules/``WebSite/dist/` 等构建产物。
## 回滚方案
- 若文档内容需要调整,直接修改对应 Markdown 文档并追加新的 commit。
- 若 Gitea 推送失败,本地 commit 保留,可在网络或认证修复后重新 push。
- 若部署失败,保留错误信息并写入经验记录。
## 人工审核状态
- 本文档用于建立工作流基线。
- 后续业务代码修改时,必须在实现方案完成后等待用户二次确认。

View File

@@ -0,0 +1,57 @@
# 工程整体分析
更新时间2026-05-04-02-38-48
## 项目定位
本项目计划建设为“基于模型逆向体素化及 DICOM 分割标注系统”。
目标能力:
- 输入头部 DICOM 序列。
- 对 DICOM 进行三维重建或读取已有重建模型。
- 从重建后的 STL 模型反向生成体素级分割 Mask。
- 面向医学影像分割标注流程提供可视化、管理和结果导出能力。
## 当前目录结构
- `WebSite/`:前端应用主体,基于 Vite、React、TypeScript。
- `WebSite/src/`:主要页面和组件代码。
- `Head_CT_DICOM/`:头部 CT DICOM 文件目录。
- `Head_CT_ReConstruct/`:已重建 STL 文件目录,包括头部、头颅、气管、肿瘤等结构。
- `工程分析/`:工程分析、需求分析、实现方案、测试方案和经验记录目录。
## 前端技术栈
- React 19
- TypeScript
- Vite 6
- Tailwind CSS 4
- Three.js、React Three Fiber、Drei
- Framer Motion / Motion
- Recharts
- Lucide React
## 已知脚本
`WebSite/package.json` 中已有脚本:
- `npm run dev`:启动 Vite 开发服务器,端口 3000监听 `0.0.0.0`
- `npm run build`:生产构建。
- `npm run preview`:预览构建结果。
- `npm run clean`:删除 `dist`
- `npm run lint`:执行 `tsc --noEmit` 类型检查。
## 数据资产
- DICOM 数据位于 `Head_CT_DICOM/`
- STL 重建模型位于 `Head_CT_ReConstruct/`
- 医学数据和模型文件体积可能较大Git 备份时应谨慎,默认不将原始影像与重建模型纳入普通文档备份提交。
## 后续重点
- 明确 DICOM 读取、排序、空间信息解析方式。
- 明确 STL 到体素 Mask 的坐标对齐策略。
- 明确 Mask 输出格式,例如 NIfTI、NRRD、DICOM SEG、PNG 序列或项目自定义格式。
- 明确前端是否只做可视化,还是需要增加后端处理服务。
- 对医学影像处理流程建立可复现测试样例和数据校验。

View File

@@ -0,0 +1,53 @@
# 测试方案
时间戳2026-05-04-02-38-48
## 测试目标
验证本次工作流文档和项目基线是否可用,并确认前端项目仍可构建。
## 静态检查
- 检查 `工程分析/` 目录是否存在。
- 检查本次需求分析、实现方案、测试方案和经验记录是否存在。
- 检查工作流是否包含人工审核确认节点。
- 检查 `.gitignore` 是否排除医学影像数据、重建模型、依赖目录和构建产物。
## 构建验证
`WebSite/` 下执行:
```bash
npm run build
```
预期结果:
- TypeScript/Vite 构建通过。
- 生成 `WebSite/dist/`
## 部署验证
`WebSite/` 下执行:
```bash
npm run dev
```
预期结果:
- Vite 开发服务器启动。
- 默认端口为 `3000`
- 若端口占用,则记录实际端口或改用可用端口。
## Gitea 备份验证
- 初始化 Git 仓库或复用现有仓库。
- 提交文档备份 commit。
- 添加远程仓库 `origin`
- 推送到 Gitea。
## 人工审核状态
- 本文档用于建立工作流基线。
- 后续业务代码修改时,必须在测试方案完成后等待用户二次确认。

View File

@@ -0,0 +1,21 @@
# 经验记录
本文件用于记录项目修改过程中的关键问题与解决方案。每条经验使用四段式结构。
## 2026-05-04-02-38-48 建立代码编纂工作流
A. 具体问题
当前项目尚无统一的需求分析、实现方案、测试方案、经验沉淀和备份提交流程,后续修改容易缺少可追溯记录。
B. 产生问题原因
项目仍处于早期建设阶段,已有前端工程和医学影像数据资产,但尚未建立工程治理文档与固定执行规范。
C. 解决问题方案
创建 `工程分析/` 目录,新增工程整体分析、代码编纂工作流、本次需求分析、实现方案、测试方案和经验记录文档。后续项目修改必须先写文档,并在实现方案和测试方案阶段等待用户二次人工审核确认。
D. 后续如何避免问题
每次项目修改前先记录时间戳并阅读 `工程分析/工程整体分析.md``工程分析/经验记录.md`。修改前写入需求、实现和测试文档,确认后再执行,完成后追加经验记录并提交 Gitea 备份。

View File

@@ -0,0 +1,53 @@
# 需求分析
时间戳2026-05-04-02-38-48
## 原始需求摘要
用户要求新建一套完整的代码编纂工作流。后续只要提出项目修改相关需求,都必须按该工作流执行。
## 业务目标
- 建立固定的需求分析、实现方案、测试方案、经验沉淀、备份提交和重新部署流程。
- 将项目整体分析集中保存在 `工程分析/` 目录。
- 每次项目修改都形成可追溯文档。
- 在执行实现和测试前加入用户二次人工审核确认。
- 执行后将关键问题沉淀到统一知识库。
- 使用 Gitea 备份文档 commit。
## 项目背景
用户计划建设“基于模型逆向体素化及 DICOM 分割标注系统”:
- `Head_CT_DICOM/`:头部 DICOM 文件。
- `Head_CT_ReConstruct/`:重建后的 STL 文件。
- 目标是从重建文件反向得到分割 Mask。
## 本次交付内容
- 创建 `工程分析/` 文件夹。
- 创建工程整体分析文档。
- 创建代码编纂工作流文档。
- 创建本次需求分析文档。
- 创建本次实现方案文档。
- 创建本次测试方案文档。
- 创建经验记录文档。
- 建立 Git/Gitea 文档备份基线。
## 影响范围
- 新增文档目录和流程文档。
- 不修改业务源代码。
- 可能新增 Git 配置文件,用于避免误提交医学影像数据、重建模型和构建产物。
## 风险点
- 当前根目录不是 Git 仓库,需要初始化。
- DICOM 和 STL 文件可能较大,不适合在文档备份 commit 中默认提交。
- Gitea 远程仓库可能需要认证或已有历史,需要处理 push 冲突。
- 当前请求是建立工作流本身,后续业务修改需严格等待人工确认。
## 待确认问题
- 后续是否需要把 DICOM/STL 原始数据纳入独立数据版本管理。
- 最终部署方式是否仅为 Vite 开发服务器,还是已有生产服务。