Compare commits
2 Commits
90727ab1b9
...
4a57fbe537
| Author | SHA1 | Date | |
|---|---|---|---|
| 4a57fbe537 | |||
| d75606568c |
49
工程分析/实现方案-2026-05-23-00-32-26.md
Normal file
49
工程分析/实现方案-2026-05-23-00-32-26.md
Normal file
@@ -0,0 +1,49 @@
|
||||
# 实现方案
|
||||
|
||||
实现方案文档路径:`工程分析/实现方案-2026-05-23-00-32-26.md`
|
||||
|
||||
## 修改目标
|
||||
|
||||
撰写一段准确、完整、可直接复用的系统功能文字描述,并完成工程分析流程留痕、备份提交、构建与部署验证。
|
||||
|
||||
## 涉及路径
|
||||
|
||||
- `工程分析/需求分析-2026-05-23-00-32-26.md`
|
||||
- `工程分析/实现方案-2026-05-23-00-32-26.md`
|
||||
- `工程分析/测试方案-2026-05-23-00-32-26.md`
|
||||
- `工程分析/系统功能描述-2026-05-23-00-32-26.md`
|
||||
- `工程分析/经验记录.md`
|
||||
|
||||
## 技术路线
|
||||
|
||||
1. 阅读工程工作流、整体分析、经验记录、README 与核心前端页面。
|
||||
2. 提炼系统定位、用户登录、项目库、DICOM 预览、STL 预览、三维融合、位姿调整、构件样式、Mask/NIfTI 导出、系统管理和部署能力。
|
||||
3. 将描述控制在 800-1300 字,并避免宣称当前尚未接入的真实医学级体素化能力。
|
||||
4. 写入文档后执行字数检查、构建检查、部署验证和 Git 备份提交。
|
||||
|
||||
## 执行步骤
|
||||
|
||||
- 记录开始时间并阅读核心工程分析资料。
|
||||
- 创建本次需求分析、实现方案、测试方案。
|
||||
- 最终执行前再次阅读 `工程分析/经验记录.md`。
|
||||
- 新增系统功能描述文档。
|
||||
- 追加经验记录 A/B/C/D。
|
||||
- 执行 `npm run build`。
|
||||
- 使用项目约定的 `tmux` 会话重新部署,并验证 `/api/health` 与首页。
|
||||
- 精确暂存本次文档并提交,commit message 包含时间戳和简要描述。
|
||||
|
||||
## 兼容性与回滚方案
|
||||
|
||||
- 本次不修改源码和配置,不影响系统运行兼容性。
|
||||
- 如需回滚,可删除本次新增文档并回退经验记录追加段落;业务系统无需回滚。
|
||||
|
||||
## 预计文件变更
|
||||
|
||||
- 新增 4 个工程分析文档。
|
||||
- 修改 1 个经验记录文档。
|
||||
|
||||
## 提交与部署策略
|
||||
|
||||
- Git 提交只包含本次相关文档。
|
||||
- 部署沿用 `WebSite` 下 `npm run build` 与 `npm run serve -- --host 0.0.0.0 --port 4000`,优先使用 `tmux` 会话 `revoxelseg-dicom`。
|
||||
- 若 4000 端口已由现有 Docker 正式服务占用,则不强行叠加 tmux 服务;记录占用来源,并对当前实际对外服务执行重建、重启和健康验证。
|
||||
74
工程分析/实现方案-2026-05-24-09-58-56.md
Normal file
74
工程分析/实现方案-2026-05-24-09-58-56.md
Normal file
@@ -0,0 +1,74 @@
|
||||
# 实现方案-2026-05-24-09-58-56
|
||||
|
||||
## 实现方案文档路径
|
||||
|
||||
`工程分析/实现方案-2026-05-24-09-58-56.md`
|
||||
|
||||
## 修改目标
|
||||
|
||||
- 阅读并梳理当前项目结构、技术栈、运行方式和 Docker 发布历史。
|
||||
- 恢复误删的 `Docker部署/` 文件夹。
|
||||
- 核查 Gitea 远端分支、tag 与 Release/附件关系;确认发布物仍由 tag/附件承载后,删除四个不再需要的发布辅助分支。
|
||||
- 构建并重新部署 `WebSite` 服务,验证本机与公网访问。
|
||||
- 完成工程分析记录、经验记录追加、Git/Gitea 备份提交。
|
||||
|
||||
## 涉及路径
|
||||
|
||||
- `Docker部署/`
|
||||
- `工程分析/需求分析-2026-05-24-09-58-56.md`
|
||||
- `工程分析/实现方案-2026-05-24-09-58-56.md`
|
||||
- `工程分析/测试方案-2026-05-24-09-58-56.md`
|
||||
- `工程分析/经验记录.md`
|
||||
- `WebSite/`
|
||||
|
||||
## 技术路线
|
||||
|
||||
1. 使用 `git status`、`README.md`、`WebSite/package.json`、历史工程分析文档了解项目现状。
|
||||
2. 通过 Git 历史或远端 `main` 恢复 `Docker部署/`,再核对恢复文件内容。
|
||||
3. 使用 `git ls-remote` 与 Gitea API 检查远端分支、tag、Release 和附件;发布项和附件确认存在后,删除仅用于固化发布配置的辅助分支。
|
||||
4. 执行 `npm run build` 验证前端生产构建。
|
||||
5. 使用 `tmux` 会话 `revoxelseg-dicom` 启动 `npm run serve -- --host 0.0.0.0 --port 4000`。
|
||||
6. 用健康接口、首页和公网域名做部署验证。
|
||||
7. 追加经验记录,暂存本次相关文件并提交,推送到 Gitea。
|
||||
|
||||
## 执行步骤
|
||||
|
||||
1. 记录开始时间并阅读 `代码编纂工作流.md`、`工程整体分析.md`、`经验记录.md`。
|
||||
2. 创建本次需求分析、实现方案、测试方案文档。
|
||||
3. 再次读取 `经验记录.md`,满足执行前确认要求。
|
||||
4. 恢复 `Docker部署/` 并检查 `Dockerfile`、`README.md`、本机 Compose、NAS Compose。
|
||||
5. 查询远端分支与发布 tag;若 Release 附件存在且 tag 可追溯,删除四个辅助分支。
|
||||
6. 执行构建和部署,检查端口与 tmux 会话状态。
|
||||
7. 验证 `http://127.0.0.1:4000/api/health`、`http://127.0.0.1:4000/`、`https://revoxel.huijutec.cn/`。
|
||||
8. 更新 `工程分析/经验记录.md`。
|
||||
9. `git add` 仅暂存本次相关文件,提交并推送到 Gitea。
|
||||
10. 最终汇报恢复文件、分支清理、部署验证与 commit 状态。
|
||||
|
||||
## 兼容性与回滚方案
|
||||
|
||||
- `Docker部署/` 若恢复异常,可从远端 `main` 或历史提交重新取回。
|
||||
- 远端分支删除后仍保留 tag、Release 和附件;如确需恢复,可从对应 tag 重新创建分支。
|
||||
- 部署失败时保留构建日志和 tmux 输出,必要时回退到此前可用的 Docker Compose 或旧 tmux 会话。
|
||||
- 不提交既有无关删除,避免扩大回滚范围。
|
||||
|
||||
## 预计文件变更
|
||||
|
||||
- 新增三份本次工程分析文档。
|
||||
- 恢复 `Docker部署/` 下 4 个文件。
|
||||
- 追加 `工程分析/经验记录.md`。
|
||||
- `WebSite/dist/` 可能因构建产生本地变化,但不作为本次备份提交重点。
|
||||
|
||||
## 提交与部署策略
|
||||
|
||||
- 提交信息使用:`2026-05-24-09-58-56 恢复Docker部署并清理发布分支`。
|
||||
- 暂存范围限定为本次工程分析文档、经验记录和恢复的 `Docker部署/` 文件。
|
||||
- 推送到用户提供的 Gitea 备份仓库对应 `main` 分支。
|
||||
- 部署使用 `tmux` 会话 `revoxelseg-dicom` 长期运行 `NODE_ENV=production npm run serve -- --host 0.0.0.0 --port 4000`,避免公网 Host 被 Vite 开发中间件拦截。
|
||||
- 公网访问另起 `revoxelseg-dicom-frpc` 容器,使用 host 网络把本机 `127.0.0.1:4000` 映射到 FRP 服务端 `10008`。
|
||||
|
||||
## 执行补充记录
|
||||
|
||||
- 初次按普通 `npm run serve` 启动后,本机 `/api/health`、`/` 与公网 API 正常,但公网根路径返回 `403 Blocked request. This host ("revoxel.huijutec.cn") is not allowed.`。
|
||||
- 原因是非生产模式会进入 Vite 中间件,Vite 对公网 Host 做 allowedHosts 校验。
|
||||
- 已改为 `NODE_ENV=production` 启动,服务直接返回 `WebSite/dist/` 生产构建产物。
|
||||
- 当前公网链路由 `tmux` Web 服务加独立 `revoxelseg-dicom-frpc` 容器组成。
|
||||
42
工程分析/测试方案-2026-05-23-00-32-26.md
Normal file
42
工程分析/测试方案-2026-05-23-00-32-26.md
Normal file
@@ -0,0 +1,42 @@
|
||||
# 测试方案
|
||||
|
||||
测试方案文档路径:`工程分析/测试方案-2026-05-23-00-32-26.md`
|
||||
|
||||
## 静态检查
|
||||
|
||||
- 检查系统功能描述是否包含当前系统主要功能模块。
|
||||
- 检查是否存在夸大真实医学级算法、诊断能力或临床结论的表述。
|
||||
- 检查正文规模是否落在 800-1300 字要求范围内。
|
||||
|
||||
## 构建检查
|
||||
|
||||
- 在 `WebSite/` 下执行 `npm run build`,确认前端与服务端构建通过。
|
||||
|
||||
## 关键业务场景验证
|
||||
|
||||
- 验证描述覆盖登录、总体概况、项目库、DICOM/STL 数据管理、逆向工作区、三维融合、构件配置、导出和系统管理。
|
||||
- 验证健康接口可访问。
|
||||
- 验证首页可访问。
|
||||
|
||||
## 医学影像数据相关边界验证
|
||||
|
||||
- 文案中明确系统面向 DICOM 序列、STL 重建模型、Label Map/NIfTI Mask 等医学影像数据流。
|
||||
- 文案避免承诺临床诊断和真实自动分割结果,只描述当前演示闭环与辅助标注能力。
|
||||
|
||||
## 部署验证
|
||||
|
||||
- 构建后使用 `tmux` 会话 `revoxelseg-dicom` 启动服务。
|
||||
- 若 `4000` 端口已由现有 Docker 服务占用,则沿用实际对外服务执行 `docker compose up -d --build`,避免端口冲突。
|
||||
- 验证 `http://127.0.0.1:4000/api/health`。
|
||||
- 验证 `http://127.0.0.1:4000/`。
|
||||
|
||||
## Git/Gitea 备份验证
|
||||
|
||||
- 使用 `git status --short` 确认仅暂存本次相关文件。
|
||||
- 提交信息包含 `2026-05-23-00-32-26` 和简要描述。
|
||||
|
||||
## 风险与回归关注点
|
||||
|
||||
- 当前工作区存在大量非本次变更,提交时不得混入。
|
||||
- 如果 4000 端口已有服务占用,需要先识别并按项目约定处理。
|
||||
- 本次不修改源码,回归风险主要来自部署过程而非文档内容。
|
||||
62
工程分析/测试方案-2026-05-24-09-58-56.md
Normal file
62
工程分析/测试方案-2026-05-24-09-58-56.md
Normal file
@@ -0,0 +1,62 @@
|
||||
# 测试方案-2026-05-24-09-58-56
|
||||
|
||||
## 测试方案文档路径
|
||||
|
||||
`工程分析/测试方案-2026-05-24-09-58-56.md`
|
||||
|
||||
## 静态检查
|
||||
|
||||
- `git status --short --branch`:确认只暂存本次相关文件,识别并保留既有无关删除状态。
|
||||
- `find Docker部署 -maxdepth 3 -type f | sort`:确认 Docker 部署目录恢复完整。
|
||||
- `git ls-remote --heads` / `git ls-remote --tags`:确认远端分支、tag 状态。
|
||||
|
||||
## 构建检查
|
||||
|
||||
- 在 `WebSite/` 执行 `npm run build`。
|
||||
- 如时间允许或构建前发现类型风险,执行 `npm run lint`。
|
||||
|
||||
## 关键业务场景验证
|
||||
|
||||
- 首页访问返回 200,页面包含前端入口。
|
||||
- `/api/health` 返回健康状态。
|
||||
- 公网页面 `https://revoxel.huijutec.cn/` 返回可访问响应。
|
||||
- 若可用,检查首页或登录页关键文本,确认不是代理错误页。
|
||||
|
||||
## 医学影像数据相关边界验证
|
||||
|
||||
- 本次不修改 DICOM/STL 解析、预览、融合或 Mask 导出逻辑。
|
||||
- 部署验证需确保服务仍可扫描默认 `Head_CT_DICOM/` 与 `Head_CT_ReConstruct/` 资源;可通过页面或 API 间接确认项目服务可启动。
|
||||
|
||||
## 部署验证
|
||||
|
||||
- 检查 `4000` 端口占用与 `tmux` 会话。
|
||||
- 启动或重启 `tmux` 会话 `revoxelseg-dicom`。
|
||||
- 验证:
|
||||
- `http://127.0.0.1:4000/api/health`
|
||||
- `http://127.0.0.1:4000/`
|
||||
- `https://revoxel.huijutec.cn/`
|
||||
|
||||
## Git/Gitea 备份验证
|
||||
|
||||
- 本地 commit message 包含 `2026-05-24-09-58-56`。
|
||||
- 推送后用 `git ls-remote` 确认远端 `main` 指向新 commit。
|
||||
- 删除发布辅助分支后,用 `git ls-remote --heads` 确认四个分支不再存在。
|
||||
- 用 tag 或 Release 检查确认发布包仍可追溯。
|
||||
|
||||
## 风险与回归关注点
|
||||
|
||||
- 避免提交大量已有历史文档删除。
|
||||
- 避免删除 Release、tag 或附件。
|
||||
- 避免 Docker 与 tmux 同时占用 `4000`。
|
||||
- 公网域名如仍异常,需要区分本机服务问题、FRP 问题和反向代理问题。
|
||||
|
||||
## 执行结果
|
||||
|
||||
- 静态检查:`Docker部署/` 已恢复 4 个文件,包括 `Dockerfile`、`README.md`、本机 Compose、威联通 NAS Compose。
|
||||
- 远端检查:Gitea 当前只剩 `main` 分支;`revoxelseg-docker-all-v2026.05.21` Release 仍存在,包含 3 个部署包附件;Docker 发布相关 tag 仍存在。
|
||||
- 类型检查:`npm run lint` 通过。
|
||||
- 构建检查:`npm run build` 通过,Vite 仅提示 chunk 体积超过 500 kB。
|
||||
- 部署检查:`tmux` 会话 `revoxelseg-dicom` 已用生产模式启动,`0.0.0.0:4000` 正常监听。
|
||||
- FRP 检查:`revoxelseg-dicom-frpc` 容器日志显示 `login to server success` 和 `start proxy success`。
|
||||
- 本机验证:`http://127.0.0.1:4000/api/health` 返回 `ok: true`,`http://127.0.0.1:4000/` 返回 200。
|
||||
- 公网验证:`https://revoxel.huijutec.cn/` 返回 200,页面标题为“模型逆向系统”;`/api/health` 返回 `ok: true`;`/api/projects` 可读取默认医学影像项目;登录接口验证成功。
|
||||
11
工程分析/系统功能描述-2026-05-23-00-32-26.md
Normal file
11
工程分析/系统功能描述-2026-05-23-00-32-26.md
Normal file
@@ -0,0 +1,11 @@
|
||||
# 系统功能文字描述
|
||||
|
||||
本系统是一套面向医学影像重建与分割标注场景的“基于模型逆向体素化及 DICOM 分割标注系统”。系统围绕 DICOM 影像序列、STL 三维重建模型和 NIfTI 分割结果三类核心数据,构建从项目管理、数据导入、影像预览、模型查看、三维融合、位姿校准到分割结果导出的完整演示流程,帮助使用者在浏览器中直观完成影像与模型的空间对应关系复核。
|
||||
|
||||
系统提供统一登录入口和共享会话管理,支持管理员进入总体概况、项目库、逆向工作区和系统管理工作区。总体概况页面集中展示项目数量、DICOM 切片数量、STL 模型数量、Mask 导出状态和近期处理趋势,使用户能够快速了解当前演示数据与项目进展。项目库负责承载病例项目和数据资产管理,用户可以查看项目基本信息,导入或覆盖 DICOM 影像、STL 模型及压缩包数据,并在上传过程中获得进度、处理阶段和失败原因反馈,降低大体量医学数据操作的不确定性。
|
||||
|
||||
在影像查看方面,系统支持轴向、矢状面、冠状面 DICOM 切片预览,并提供默认、骨窗、软组织、高对比等显示模式,便于从不同窗宽窗位风格复核组织结构。系统能够解析关键 DICOM 元数据、spacing、物理尺寸等信息,并支持下载原始影像归档。在模型查看方面,系统读取 STL 文件并生成抽样三角面预览,支持多构件显示、隐藏、颜色、透明度、Mask ID 和实体显示精度配置,使不同组织或结构模型能够以清晰的层级方式呈现。
|
||||
|
||||
逆向工作区是系统的核心操作区域,面向 DICOM 与 STL 的空间融合和逆向映射复核。用户可在三维视图中同时观察 DICOM 体数据、切片范围和 STL 模型,调整模型旋转、平移、缩放等位姿参数,并通过细粒度步进完成配准微调。系统提供自动拉伸、视角切换、切片范围控制、DICOM 透明度控制和 STL 切面展示,辅助用户判断模型是否落在影像空间的合理位置。二维映射视图可叠加显示 Label Map 结果统计,帮助用户检查可见构件、填充像素和分段数量。
|
||||
|
||||
系统支持按项目导出 DICOM 原始影像、STL 原始模型、位姿数据和分割影像结果。分割影像可按可见类别或全部类别导出,并支持构件整体导出为多标签 Label Map,或按构件分别导出为独立 NII.GZ 文件,便于后续接入医学影像分析工具进行复核。系统管理工作区提供用户新增、编辑、密码修改、删除和演示环境恢复能力,保证演示数据、用户状态和项目状态可统一维护。整体上,本系统强调医学影像数据的可视化管理、模型与影像的空间校准、分割结果的可追溯导出和演示环境的可重复运行,为后续接入真实医学级逆向体素化算法和临床级标注流程预留了清晰接口。
|
||||
36
工程分析/经验记录.md
36
工程分析/经验记录.md
@@ -1603,3 +1603,39 @@ C. 解决问题方案
|
||||
D. 后续如何避免问题
|
||||
|
||||
后续遇到“停止、暂停、下线、关闭服务”类请求时,工作流中的重新部署步骤应解释为“运行态验证”,而不是再次启动服务。最终汇报要明确服务已停、恢复命令是什么,以及哪些入口当前不可访问,避免把暂停请求处理成重启请求。
|
||||
|
||||
## 2026-05-23-00-32-26 系统功能描述要贴合演示系统真实边界
|
||||
|
||||
A. 具体问题
|
||||
|
||||
用户要求撰写 800-1300 字的系统功能文字描述,内容需要覆盖项目核心功能,同时不能把当前演示闭环写成已具备完整临床级自动分割或真实医学级体素化算法。
|
||||
|
||||
B. 产生问题原因
|
||||
|
||||
系统名称和目标包含“逆向体素化”“DICOM 分割标注”等较强算法语义,但工程整体分析已明确当前仍以演示闭环为主,真实医学级 STL 到 DICOM 空间体素化算法尚未接入。若只按目标愿景撰写,容易超出当前系统实际能力。
|
||||
|
||||
C. 解决问题方案
|
||||
|
||||
先阅读工作流、工程整体分析、经验记录、README 和核心页面源码,再提炼登录、总体概况、项目库、DICOM 预览、STL 预览、三维融合、位姿校准、构件样式、Label Map/NIfTI 导出和系统管理等真实功能。正文中特别使用“演示流程”“复核”“预留接口”等表述,避免承诺临床诊断或已完成真实算法接入,并用字符统计确认正文处于用户要求范围。
|
||||
|
||||
D. 后续如何避免问题
|
||||
|
||||
后续撰写项目介绍、软著说明、验收材料或宣传文案时,应先核对工程整体分析和最新源码功能,再区分“已实现能力”“演示能力”和“后续预留能力”。涉及医学影像、分割、诊断和算法效果的表述必须保守准确,不能为了文字完整性虚构尚未落地的临床级能力。
|
||||
|
||||
## 2026-05-24-09-58-56 Docker 发布分支清理与公网生产模式部署
|
||||
|
||||
A. 具体问题
|
||||
|
||||
用户误删了主工程 `Docker部署/` 目录,同时 Gitea 中遗留四个 Docker 发布辅助分支。恢复本机 `tmux` 服务后,本机页面和公网 API 正常,但公网根路径一度返回 `403 Blocked request. This host ("revoxel.huijutec.cn") is not allowed.`。
|
||||
|
||||
B. 产生问题原因
|
||||
|
||||
`Docker部署/` 是已跟踪目录,被工作区删除后可从 Git 历史恢复。四个远端分支只是用于固化 v2026.05.21 Docker 发布包配置,Release 已由 tag 和附件承载,不再需要分支长期保留。公网 403 则是因为普通 `npm run serve` 未设置 `NODE_ENV=production`,服务进入 Vite 开发中间件,Vite 对公网 Host 执行 allowedHosts 拦截;同时公网访问还依赖 frpc 隧道,单独启动 Web 服务不足以恢复域名入口。
|
||||
|
||||
C. 解决问题方案
|
||||
|
||||
使用 `git restore -- Docker部署` 恢复主工程 Docker 部署文件。确认 Gitea Release `ReVoxelSeg DICOM Docker 部署包 v2026.05.21` 及 3 个附件、相关 tag 均存在后,删除 `docker-standalone-20260521`、`release/docker-machine-20260521`、`release/docker-nas-20260521`、`release/docker-generic-20260521` 四个远端分支。部署时先执行 `npm run lint` 与 `npm run build`,再用 `tmux` 运行 `NODE_ENV=production npm run serve -- --host 0.0.0.0 --port 4000`,并单独启动 host 网络的 `revoxelseg-dicom-frpc` 容器将本机 `127.0.0.1:4000` 映射到 FRP 远端 `10008`。最终验证本机健康接口、首页、公网首页、公网 API、项目数据和登录接口均可用。
|
||||
|
||||
D. 后续如何避免问题
|
||||
|
||||
清理发布辅助分支前必须先确认对应 Release、tag 和附件均可读,再删除分支而不是删除 tag 或 Release。通过公网域名部署 `npm run serve` 时应使用 `NODE_ENV=production`,否则 Vite 开发中间件可能拦截公网 Host。公网域名验证要同时检查 Web 服务、frpc 登录与代理成功日志、`/api/health`、首页 HTML 和关键业务 API,避免只看本机 4000 端口。
|
||||
|
||||
42
工程分析/需求分析-2026-05-23-00-32-26.md
Normal file
42
工程分析/需求分析-2026-05-23-00-32-26.md
Normal file
@@ -0,0 +1,42 @@
|
||||
# 需求分析
|
||||
|
||||
开始时间:2026-05-23-00-32-26
|
||||
|
||||
## 原始需求摘要
|
||||
|
||||
用户要求撰写一段 800-1300 字的系统功能文字描述。
|
||||
|
||||
## 业务目标
|
||||
|
||||
形成一段可用于项目介绍、软著材料、验收材料或产品说明的系统功能描述,准确概括“基于模型逆向体素化及 DICOM 分割标注系统”的核心能力、使用流程和交付价值。
|
||||
|
||||
## 输入与输出
|
||||
|
||||
- 输入:用户提出的字数范围要求、现有工程整体分析、README、前端核心页面与经验记录。
|
||||
- 输出:一份 800-1300 字范围内的系统功能文字描述,并在工程分析目录留存本次流程文档。
|
||||
|
||||
## 影响范围
|
||||
|
||||
- 新增本次需求分析、实现方案、测试方案。
|
||||
- 新增系统功能描述文档。
|
||||
- 追加经验记录。
|
||||
- 不修改业务源码、医学影像数据、运行态数据和部署配置。
|
||||
|
||||
## 关键约束
|
||||
|
||||
- 必须执行 `工程分析/代码编纂工作流.md`。
|
||||
- 描述内容应与当前系统真实能力一致,不夸大为已经接入医学级真实体素化算法。
|
||||
- 字数需控制在 800-1300 字。
|
||||
- Git 备份提交只包含本次相关文档,避免混入工作区既有删除或未跟踪文件。
|
||||
- 按项目约定执行构建与重新部署验证。
|
||||
|
||||
## 风险点
|
||||
|
||||
- 若描述中过度强调自动分割或真实医学诊断能力,可能与当前演示系统定位不一致。
|
||||
- 当前工作区存在大量非本次变更,提交时需要精确暂存。
|
||||
- 服务可能已由 Docker 或其他方式占用 4000 端口,重新部署前需要检查。
|
||||
|
||||
## 待确认问题或默认假设
|
||||
|
||||
- 默认将文字描述保存为 `工程分析/系统功能描述-2026-05-23-00-32-26.md`,并在最终回复中直接提供正文。
|
||||
- 默认按中文“字数”理解为正文字符规模,控制在 800-1300 个汉字/字符附近。
|
||||
56
工程分析/需求分析-2026-05-24-09-58-56.md
Normal file
56
工程分析/需求分析-2026-05-24-09-58-56.md
Normal file
@@ -0,0 +1,56 @@
|
||||
# 需求分析-2026-05-24-09-58-56
|
||||
|
||||
## 开始时间
|
||||
|
||||
2026-05-24-09-58-56
|
||||
|
||||
## 原始需求摘要
|
||||
|
||||
用户要求阅读当前项目并了解整体内容;确认 Gitea 备份仓库 `https://gitea.huijutec.cn/admin/REVOXELSEG_DICOM`;恢复误删的 `Docker部署/` 文件夹;判断 Gitea 中除 `main` 以外的四个 Docker 发布辅助分支是否仍有影响,若不影响当前发布项“ReVoxelSeg DICOM Docker 部署包 v2026.05.21”服务则删除;最后重新部署项目并验证 `https://revoxel.huijutec.cn/` 是否可以正常访问和使用。
|
||||
|
||||
## 业务目标
|
||||
|
||||
- 恢复主工程中的 Docker 部署资料,保证本机、NAS 与公网隧道部署说明可追溯。
|
||||
- 清理不再需要的远端发布辅助分支,避免 Gitea 分支列表混乱,同时保留发布标签、Release 和附件可用性。
|
||||
- 重新启动当前服务并验证本机健康接口、页面入口和公网域名。
|
||||
- 按工程协作约束记录本次分析、方案、测试与经验,并提交 Gitea 备份。
|
||||
|
||||
## 输入与输出
|
||||
|
||||
- 输入:
|
||||
- 当前本地仓库 `/home/wkmgc/Desktop/ReVoxelSeg_DICOM`。
|
||||
- Gitea 仓库地址及用户提供的账号信息。
|
||||
- 既有 Docker 发布包与历史工程分析记录。
|
||||
- 输出:
|
||||
- 恢复后的 `Docker部署/` 目录。
|
||||
- 本次 `需求分析`、`实现方案`、`测试方案` 文档。
|
||||
- 追加后的 `工程分析/经验记录.md`。
|
||||
- 包含时间戳的 Git/Gitea 备份 commit。
|
||||
- 重新部署后的服务验证结果。
|
||||
|
||||
## 影响范围
|
||||
|
||||
- 本地文件:`Docker部署/`、`工程分析/需求分析-2026-05-24-09-58-56.md`、`工程分析/实现方案-2026-05-24-09-58-56.md`、`工程分析/测试方案-2026-05-24-09-58-56.md`、`工程分析/经验记录.md`。
|
||||
- 远端仓库:可能删除 `docker-standalone-20260521`、`release/docker-machine-20260521`、`release/docker-nas-20260521`、`release/docker-generic-20260521` 四个分支。
|
||||
- 运行服务:`WebSite` 构建产物、`tmux` 会话 `revoxelseg-dicom`、本机 `4000` 端口、公网域名 `https://revoxel.huijutec.cn/`。
|
||||
|
||||
## 关键约束
|
||||
|
||||
- 必须先执行 `工程分析/代码编纂工作流.md`。
|
||||
- 最终执行前需再次确认已读 `工程分析/经验记录.md`。
|
||||
- 文档备份 commit message 必须包含 `2026-05-24-09-58-56` 与简要描述。
|
||||
- 只暂存本次相关文件,避免把既有未确认删除的历史文档或运行态文件混入提交。
|
||||
- 部署优先使用 `WebSite && npm run build && npm run serve -- --host 0.0.0.0 --port 4000`,长期运行优先沿用 `tmux` 会话 `revoxelseg-dicom`。
|
||||
|
||||
## 风险点
|
||||
|
||||
- 当前工作区除 `Docker部署/` 外,还存在多份历史 `工程分析/*-2026-05-*` 文件删除状态,需避免误提交。
|
||||
- 删除远端分支属于不可逆清理操作,需先确认发布 Release/Tag/附件不依赖分支指针。
|
||||
- 本地 `origin` 指向 `http://192.168.31.5:5002/...`,用户提供的备份仓库为 `https://gitea.huijutec.cn/...`,提交与推送需确认目标一致。
|
||||
- 公网访问依赖反向代理、FRP 或现有外部链路,仅本机 `tmux` 服务启动不一定能修复公网链路。
|
||||
|
||||
## 待确认问题或默认假设
|
||||
|
||||
- 默认假设:用户已授权在确认无影响后删除四个 Docker 发布辅助分支,但不删除 `main`、tag、Release 和 Release 附件。
|
||||
- 默认假设:恢复 `Docker部署/` 可优先从当前 Git 历史或远端 `main` 中取回,不需要重写部署方案。
|
||||
- 默认假设:本次不恢复或提交既有历史 `工程分析` 文档删除状态,除非后续验证发现这些删除会影响本次工作流核心文档。
|
||||
Reference in New Issue
Block a user