2026-05-20-12-29-06 软著完整截图与下载核查

工程分析/实现方案-2026-05-20-12-29-06.md

@@ -0,0 +1,64 @@
+# 实现方案：完整页面截图替换与下载内容核查
+
+实现方案文档路径：`工程分析/实现方案-2026-05-20-12-29-06.md`
+
+## 修改目标
+
+把软著说明书每个章节配图替换为未裁剪的完整页面截图，并核查说明书中涉及下载、导出和文件保存的内容。
+
+## 涉及路径
+
+- `新撰写软著文档/1. 软著说明书.md`
+- `新撰写软著文档/1. 软著说明书.docx`
+- `新撰写软著文档/images/chapter-*.png`
+- `新撰写软著文档/功能验证与素材清单.md`
+- `工程分析/需求分析-2026-05-20-12-29-06.md`
+- `工程分析/实现方案-2026-05-20-12-29-06.md`
+- `工程分析/测试方案-2026-05-20-12-29-06.md`
+- `工程分析/经验记录.md`
+
+## 技术路线
+
+1. 使用全文搜索定位说明书中的“下载”“导出”“保存”“NII.GZ”等相关表述。
+2. 使用 Chrome DevTools Protocol 自动化打开系统并截取完整视口截图。
+3. 对登录、总体概况、项目库、DICOM、STL、分割结果、逆向工作区、导出选项、系统管理、退出等章节生成对应完整图。
+4. 保持 Markdown 图片引用路径不变，仅覆盖图片文件内容。
+5. 重新生成 `1. 软著说明书.docx`，保证 23 张图片嵌入 Word。
+6. 更新素材清单，标注图片为完整页面截图。
+
+## 执行步骤
+
+- 检查当前服务是否可访问。
+- 运行自动化截图脚本生成 23 张完整页面截图。
+- 对 DICOM 信息截图做必要脱敏。
+- 重新生成 Word。
+- 验证章节数、图片数、图片尺寸、Word 媒体数量和下载相关文本命中结果。
+- 构建与重新部署项目。
+- 提交工程分析文档与经验记录并推送到 Gitea。
+
+## 兼容性与回滚方案
+
+- 若某个截图失败，可重新运行自动化截图脚本覆盖对应图片。
+- 若 Word 生成失败，保留 Markdown 和图片，可再次用 `python-docx` 生成。
+- 若下载相关内容需要后续删除，可基于本轮搜索结果进一步调整说明书正文。
+
+## 预计文件变更
+
+本地软著材料：
+
+- `新撰写软著文档/images/chapter-*.png`
+- `新撰写软著文档/1. 软著说明书.docx`
+- `新撰写软著文档/功能验证与素材清单.md`
+
+Gitea 备份：
+
+- 本轮工程分析三份文档。
+- `工程分析/经验记录.md`。
+
+## 提交与部署策略
+
+- 不提交 `新撰写软著文档/`。
+- 不提交 `head-ct-demo-pose-data.json`。
+- 仅暂存本轮工程分析文档与经验记录。
+- commit message 包含 `2026-05-20-12-29-06`。
+- 重新部署后验证 `/api/health` 和首页。

工程分析/测试方案-2026-05-20-12-29-06.md

@@ -0,0 +1,62 @@
+# 测试方案：完整截图与下载内容核查验证
+
+测试方案文档路径：`工程分析/测试方案-2026-05-20-12-29-06.md`
+
+## 静态检查
+
+- 检查说明书 `## X.` 章节数量为 23。
+- 检查每个章节均有图片引用。
+- 检查 23 张 `chapter-*.png` 文件存在。
+- 检查 23 张章节图尺寸为完整视口截图尺寸，不再是局部裁剪图。
+- 使用全文搜索列出“下载”“导出”“保存”“NII.GZ”等相关表述。
+
+## 构建检查
+
+- 在 `WebSite/` 执行 `npm run build`。
+
+## 关键业务场景验证
+
+- 完整截图覆盖登录、总体概况、项目库、DICOM 浏览、DICOM 信息、STL 模型、构件层级、分割结果、逆向工作区、位姿导入、映射视图、导出选项、系统管理和退出。
+- 逆向工作区截图使用软件 WebGL，避免三维视图空白。
+
+## 医学影像数据相关边界验证
+
+- DICOM 信息截图继续遮盖患者姓名和患者编号。
+- 不执行删除项目、重置环境、真实导出下载等破坏性或大量下载操作。
+
+## Word 与素材验证
+
+- 重新生成 `1. 软著说明书.docx`。
+- 使用 `unzip -t` 验证 Word 完整性。
+- 使用 `unzip -l` 检查 Word 内嵌图片数量为 23。
+- 更新 `功能验证与素材清单.md`。
+
+## 部署验证
+
+- 验证 `http://127.0.0.1:4000/api/health`。
+- 验证 `http://127.0.0.1:4000/` 返回 200。
+
+## Git/Gitea 备份验证
+
+- commit message 包含 `2026-05-20-12-29-06`。
+- 推送 Gitea 成功后记录 commit。
+- 确认软著材料未被暂存或提交。
+
+## 风险与回归关注点
+
+- 不把软著图片和 Word 纳入 Gitea。
+- 不处理已有历史工程分析文档删除状态。
+
+## 实际验证记录
+
+- 说明书章节检查：`新撰写软著文档/1. 软著说明书.md` 中共有 23 个 `## X.` 章节。
+- 图片引用检查：23 个章节均存在图片引用，引用文件全部存在。
+- 完整截图尺寸检查：23 张 `chapter-*.png` 均为 1680x1050，未再使用局部裁剪尺寸图片。
+- DICOM 信息脱敏检查：`chapter-09-dicom-info.png` 保留完整页面截图，仅遮盖患者姓名和患者编号的值。
+- Word 完整性检查：`unzip -t 新撰写软著文档/1. 软著说明书.docx` 通过。
+- Word 图片位置检查：`word/document.xml` 中 `<wp:inline>` 数量为 23，说明 Word 正文中仍有 23 个图片位置；`word/media` 为 12 个，原因是 Word 对相同图片二进制做了内部复用。
+- 下载/导出内容核查：说明书中存在下载/导出相关内容，主要命中位置包括第 1、2、3、6、8、9、11、12、16、18、19、20、22、23 节，其中直接“下载”表述位于第 8 节 DICOM 影像浏览，主要“导出”表述集中在第 18、19、20、23 节。
+- 素材清单检查：`新撰写软著文档/功能验证与素材清单.md` 已更新为“完整视口截图”和 1680x1050 说明。
+- 构建检查：`WebSite/ npm run build` 通过，Vite 仅提示 chunk size warning。
+- 重新部署检查：已重启 `tmux` 会话 `revoxelseg-dicom`，服务日志显示 `ReVoxelSeg DICOM server ready at http://0.0.0.0:4000/`。
+- 服务检查：`http://127.0.0.1:4000/api/health` 返回 200，`http://127.0.0.1:4000/` 返回 200。

工程分析/经验记录.md

@@ -1225,3 +1225,21 @@ C. 解决问题方案
 D. 后续如何避免问题
 
 软著说明书增加、删除或改名章节后，应重新跑“章节数、图片数、图片文件存在、Word 媒体数量、视频信息”五类检查。涉及医学影像信息截图时必须先确认是否存在患者姓名、编号等敏感字段；涉及位姿展示时必须记录所用 JSON 文件，并在截图或视频中保留导入成功状态。
+
+## 2026-05-20-12-29-06 软著截图应区分完整页面与章节聚焦图
+
+A. 具体问题
+
+用户指出软著说明书中的图片不要截取。上一轮为了让章节主题更聚焦，将部分完整截图裁成局部卡片或面板，导致 Markdown 预览中图片像是只展示了页面片段。
+
+B. 产生问题原因
+
+软著说明书截图既要图文对应，又要保持审查材料中的界面完整性。局部裁剪虽然能突出功能区，但会丢失导航、模块位置和完整操作上下文，不符合用户对“完整截图”的预期。
+
+C. 解决问题方案
+
+重新使用 Chrome 自动化生成 23 张 1680x1050 完整视口截图，仅对 DICOM 信息截图中的患者姓名和患者编号值做遮盖脱敏，不再裁剪功能卡片或局部区域。重新生成 `1. 软著说明书.docx`，并通过章节图片引用、图片尺寸、Word 图片位置和服务部署检查。
+
+D. 后续如何避免问题
+
+软著截图默认采用完整页面截图；只有用户明确要求“局部图”“放大细节图”时才裁剪。若同一完整页面用于多个章节，校验 Word 时应统计正文图片位置数量，而不能只看 `word/media` 文件数，因为 Word 会复用相同图片二进制。

工程分析/需求分析-2026-05-20-12-29-06.md

@@ -0,0 +1,51 @@
+# 需求分析：软著说明书图片改为完整截图并核查下载内容
+
+开始时间：`2026-05-20-12-29-06`
+
+## 原始需求摘要
+
+用户反馈当前软著说明书中的图片被截取为局部图，要求“每个图片不要截取”。同时询问当前软著说明书中是否包含下载相关内容。
+
+## 业务目标
+
+- 将软著说明书中的章节配图更新为完整界面截图，避免局部裁剪导致画面信息不足。
+- 核查 `新撰写软著文档/1. 软著说明书.md` 中关于下载、导出、保存文件等内容的表述位置。
+- 重新生成说明书 Word，使 Word 交付版与 Markdown 图片一致。
+
+## 输入与输出
+
+输入：
+
+- `新撰写软著文档/1. 软著说明书.md`
+- `新撰写软著文档/images/`
+- 当前运行系统 `http://127.0.0.1:4000/`
+
+输出：
+
+- 更新 `新撰写软著文档/images/chapter-*.png` 为完整页面截图。
+- 更新 `新撰写软著文档/1. 软著说明书.docx`。
+- 更新 `新撰写软著文档/功能验证与素材清单.md`。
+- 输出下载/导出相关内容核查结果。
+
+## 影响范围
+
+- 仅影响本地软著材料与本轮工程分析记录。
+- 不修改产品源码。
+- 软著材料继续不纳入 Gitea，仅工程分析文档和经验记录做备份提交。
+
+## 关键约束
+
+- 图片必须是完整界面截图，不再使用局部裁剪图。
+- 保留每个 `## X.` 章节均有图片的结构。
+- 涉及 DICOM 信息截图时继续遮盖患者姓名和患者编号。
+- 说明书中是否有“下载/导出”相关内容需要明确列出。
+
+## 风险点
+
+- Headless 环境可能导致逆向工作区 WebGL 截图空白，需要继续使用软件 WebGL 参数。
+- 重新生成截图可能覆盖原有局部图，需要验证图片尺寸和数量。
+- 当前工作区存在历史工程分析文档删除状态与软著未跟踪目录，提交时必须精确暂存。
+
+## 默认假设
+
+- 用户当前不是要求删除“下载/导出”内容，而是先询问说明书中是否存在相关内容；本轮先核查并汇报，不主动删除业务说明。