60 lines
2.7 KiB
Markdown
60 lines
2.7 KiB
Markdown
# 实现方案-2026-05-25-12-30-27
|
||
|
||
## 实现方案文档路径
|
||
|
||
`工程分析/实现方案-2026-05-25-12-30-27.md`
|
||
|
||
## 修改目标
|
||
|
||
将 `3. 代码汇总.docx` 整理为约 10000 行真实、连续、无省略占位的项目源码汇总文档，避免出现以 `...` 表示删减的软著材料风险。
|
||
|
||
## 涉及路径
|
||
|
||
- `3. 代码汇总.docx`
|
||
- `WebSite/server.ts`
|
||
- `WebSite/src/components/ReverseWorkspace.tsx`
|
||
- `WebSite/src/components/ProjectLibrary.tsx`
|
||
- `工程分析/需求分析-2026-05-25-12-30-27.md`
|
||
- `工程分析/实现方案-2026-05-25-12-30-27.md`
|
||
- `工程分析/测试方案-2026-05-25-12-30-27.md`
|
||
- `工程分析/经验记录.md`
|
||
|
||
## 技术路线
|
||
|
||
1. 读取既有工程分析、整体分析和经验记录，确认项目约束。
|
||
2. 统计可选源码文件行数，优先选择完整文件而非局部摘录。
|
||
3. 使用 `python-docx` 读取并重写 docx 正文，保留为 `.docx` 格式。
|
||
4. 正文中写入标题、整理说明、文件清单和完整源码内容；每个源码文件从第一行到最后一行连续写入。
|
||
5. 对生成后的 docx 做结构可读性检查、行数检查和省略占位检查。
|
||
6. 执行构建、重新启动 `tmux` 服务并验证 `/api/health` 和首页。
|
||
7. 追加经验记录，并对本次相关文档和 docx 做 Git 备份 commit。
|
||
|
||
## 执行步骤
|
||
|
||
1. 确认 `工程分析/经验记录.md` 在执行修改前已再次阅读。
|
||
2. 选定完整源码文件组合，控制总行数约 10000 行。
|
||
3. 生成 docx：使用等宽字体、小字号、紧凑段落，每行保留行号和原始源码文本。
|
||
4. 检查 docx 中是否存在以独立 `...` 表示的省略占位；若源码语法中存在合法 `...`，评估是否需要改选文件或在材料说明中避免误判。
|
||
5. 运行 `npm run build`。
|
||
6. 使用 `tmux` 会话 `revoxelseg-dicom` 运行 `npm run serve -- --host 0.0.0.0 --port 4000`。
|
||
7. 使用 `curl` 验证本地 API 与页面。
|
||
8. 追加经验记录并提交备份 commit。
|
||
|
||
## 兼容性与回滚方案
|
||
|
||
- 若 docx 生成异常，可从 Git 工作区或修改前备份文件恢复。
|
||
- 若选定文件中合法 `...` 过多导致材料观感不佳，可改为选择不含该字符或更少使用扩展运算符的完整源码文件组合。
|
||
- 本次不修改项目运行源码；构建和部署异常按既有服务回滚方式恢复上一版服务。
|
||
|
||
## 预计文件变更
|
||
|
||
- 更新：`3. 代码汇总.docx`
|
||
- 更新：`工程分析/经验记录.md`
|
||
- 新增：本次需求分析、实现方案、测试方案三件套
|
||
|
||
## 提交与部署策略
|
||
|
||
- Git commit message 包含 `2026-05-25-12-30-27` 和“整理软著代码汇总文档”。
|
||
- 只暂存本次相关文件，避免提交无关未跟踪或运行态文件。
|
||
- 构建成功后重启本地 4000 服务，并验证健康检查和首页响应。
|