2026-05-04-02-38-48 建立代码编纂工作流文档
This commit is contained in:
30
.gitignore
vendored
Normal file
30
.gitignore
vendored
Normal 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
5
README.md
Normal file
@@ -0,0 +1,5 @@
|
||||
# ReVoxelSeg DICOM
|
||||
|
||||
基于模型逆向体素化及 DICOM 分割标注系统。
|
||||
|
||||
工程流程与分析文档位于 `工程分析/`。
|
||||
96
工程分析/代码编纂工作流.md
Normal file
96
工程分析/代码编纂工作流.md
Normal 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`
|
||||
- 若已有服务进程或部署脚本,优先沿用现有部署方式。
|
||||
|
||||
## 人工确认口令
|
||||
|
||||
后续当我完成实现方案和测试方案文档后,需要用户明确回复类似以下内容才继续:
|
||||
|
||||
- `确认实现方案`
|
||||
- `确认测试方案`
|
||||
- `确认执行`
|
||||
|
||||
如果用户对方案提出修改意见,则先更新对应文档,再等待新的确认。
|
||||
47
工程分析/实现方案-2026-05-04-02-38-48.md
Normal file
47
工程分析/实现方案-2026-05-04-02-38-48.md
Normal 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。
|
||||
- 若部署失败,保留错误信息并写入经验记录。
|
||||
|
||||
## 人工审核状态
|
||||
|
||||
- 本文档用于建立工作流基线。
|
||||
- 后续业务代码修改时,必须在实现方案完成后等待用户二次确认。
|
||||
57
工程分析/工程整体分析.md
Normal file
57
工程分析/工程整体分析.md
Normal 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 序列或项目自定义格式。
|
||||
- 明确前端是否只做可视化,还是需要增加后端处理服务。
|
||||
- 对医学影像处理流程建立可复现测试样例和数据校验。
|
||||
53
工程分析/测试方案-2026-05-04-02-38-48.md
Normal file
53
工程分析/测试方案-2026-05-04-02-38-48.md
Normal 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。
|
||||
|
||||
## 人工审核状态
|
||||
|
||||
- 本文档用于建立工作流基线。
|
||||
- 后续业务代码修改时,必须在测试方案完成后等待用户二次确认。
|
||||
21
工程分析/经验记录.md
Normal file
21
工程分析/经验记录.md
Normal file
@@ -0,0 +1,21 @@
|
||||
# 经验记录
|
||||
|
||||
本文件用于记录项目修改过程中的关键问题与解决方案。每条经验使用四段式结构。
|
||||
|
||||
## 2026-05-04-02-38-48 建立代码编纂工作流
|
||||
|
||||
A. 具体问题
|
||||
|
||||
当前项目尚无统一的需求分析、实现方案、测试方案、经验沉淀和备份提交流程,后续修改容易缺少可追溯记录。
|
||||
|
||||
B. 产生问题原因
|
||||
|
||||
项目仍处于早期建设阶段,已有前端工程和医学影像数据资产,但尚未建立工程治理文档与固定执行规范。
|
||||
|
||||
C. 解决问题方案
|
||||
|
||||
创建 `工程分析/` 目录,新增工程整体分析、代码编纂工作流、本次需求分析、实现方案、测试方案和经验记录文档。后续项目修改必须先写文档,并在实现方案和测试方案阶段等待用户二次人工审核确认。
|
||||
|
||||
D. 后续如何避免问题
|
||||
|
||||
每次项目修改前先记录时间戳并阅读 `工程分析/工程整体分析.md` 与 `工程分析/经验记录.md`。修改前写入需求、实现和测试文档,确认后再执行,完成后追加经验记录并提交 Gitea 备份。
|
||||
53
工程分析/需求分析-2026-05-04-02-38-48.md
Normal file
53
工程分析/需求分析-2026-05-04-02-38-48.md
Normal 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 开发服务器,还是已有生产服务。
|
||||
Reference in New Issue
Block a user