zijunchiang
2433cd22a5
两个都是**只有真正启动服务才会暴露**的缺陷，v0.7.0 / v0.7.1 的产物受影响。 1. 【致命】CatalogModule 漏 import ScenesModule CatalogService 因为 catalog/export 要下发 scenes[] 而注入 ScenesService，但 CatalogModule 的 imports 只列了 SongsModule / MotionsModule / ModelsModule。 Nest 的 DI 按模块解析，于是 node dist/main.js 在 bootstrap 阶段直接抛 UnknownDependenciesException: Nest can't resolve dependencies of the CatalogService (... ? ...) —— 服务完全起不来（装得上、起不来）。 为什么三层检查全绿：nest build/tsc 看不出运行时 DI；258 项单元测试直接 new 服务或测纯函数，从不编译 AppModule；打包脚本只校验文件清单与压缩包完整性。 修复：CatalogModule.imports 补上 ScenesModule。 2. /health 的 version 在原生部署下永远是 0.1.0 原实现 process.env.npm_package_version ?? '0.1.0'，而该变量只在 npm 脚本下 存在；正式部署是原生服务（ExecStart=node dist/main.js），npm 不参与 -> 恒为 undefined -> 回退到硬编码 0.1.0，与管理端左下角展示的 vX.Y.Z 冲突， 违反文档 11.2 第 4 条「可核对：Web 端至少与 GET /health 的 version 一致」。 修复：新增 src/config/app-version.ts 作为运行时唯一解析点 （APP_VERSION -> 运行入口旁/工作目录的 package.json（带包名校验） -> npm_package_version -> 显式 0.0.0），/health 改用 resolveAppVersion()， main.ts 启动首行也打印版本号。新增 12 项测试，其中一项显式模拟无 npm 环境变量的原生部署。 防线（都挂进了 verify 与打包脚本） - scripts/check-bootstrap.mjs：以正式部署方式（node dist/main.js、无 npm 环境 变量、不需要数据库）拉起真实产物，断言①无依赖解析类错误②启动日志的应用版本 等于 package.json ③已推进到数据库连接阶段。已做反向验证：删掉 ScenesModule 后该检查立刻失败。 - scripts/check-version.mjs（并入 contracts:check）：校验 web-server/package.json = admin/package.json = project.yaml，正则禁止 health.controller.ts 再出现硬编码版本回退，管理端已构建时断言产物 JS 含 vX.Y.Z。 - npm run verify 现在包含 bootstrap:check；package-release.sh 在构建后、打包前 各跑一次（构建管理端后再跑 version:check，因为此时才需要校验产物内版本）。 文档：README.md / README.txt 增加 v0.7.2 修订说明； tasks/011-version-display.md 与 tasks/015-scene-management.md 补「缺陷修复记录」 （含为什么当时没被发现的三层检查对照表）。 验证：npm run verify 通过（契约六项一致、35 条路由、258 项测试、nest build、 启动冒烟）；产物 opendance-web-v0.7.2.tar.gz sha256 f04ecc85d17517ec00754238616eb1237cdb2fe17440af6dce731827c0922b26。
76 lines
4.1 KiB
Markdown
76 lines
4.1 KiB
Markdown
# T-WEB-015 场景管理（新增模块）
|
||
|
||
- **状态**: done
|
||
- **依赖**: T-WEB-007（审核流程）
|
||
- **文档**: v1.6 §4.12
|
||
- **契约**: `rest-api 0.5.0`、`data-models 0.7.0`、`database 0.4.0`
|
||
|
||
## 目标
|
||
|
||
新增**场景**这一类资源：客户端跟练时的 3D 环境（GLB）+ 物理参数
|
||
（重力 / 风 / 地面 / 碰撞体 / 环境 / 出生点 / 相机）。
|
||
服务端**只存参数、不跑物理**，仿真在客户端（Windows 端用 Godot 内置物理）。
|
||
|
||
## 与模型的区别
|
||
|
||
| 项 | 模型 | 场景 |
|
||
|--|--|--|
|
||
| 主力格式 | **VRM**（humanoid 重绑定） | **GLB**（不做重绑定、不转 VRM） |
|
||
| 转换 | PMX/FBX/zip → GLB → VRM | `.glb`/`.gltf` 直接导入；`.zip`/`.pmx`/`.fbx` → GLB |
|
||
| 附加数据 | 骨骼 / 材质 / 缩略图 | **物理参数** `SceneConfig` |
|
||
|
||
## 交付物
|
||
|
||
| 文件 | 说明 |
|
||
|--|--|
|
||
| `contracts/data-models.md` §7 | `Scene` 与冻结的 `SceneConfig` 结构 |
|
||
| `contracts/rest-api.yaml` | `/api/scenes` 增删改查 + 审核复用 `/api/reviews/scene/:id/approve\|reject` + `catalog/export.scenes[]` |
|
||
| `migrations/1789650000000-AddScenes.ts` | `scenes` 表；`config` / `stats` 用 **MEDIUMTEXT** |
|
||
| `src/scenes/scene-config.ts` | `normalizeSceneConfig()`：缺项默认、越界夹紧、非法枚举回退，**永不抛错** |
|
||
| `src/scenes/{scenes.service,scene.serializer,scenes.controller,scenes.module}.ts` | 业务实现（上传一律 `pending`；删除时清理源文件/GLB/缩略图） |
|
||
| `src/models/model-inspector.ts` | 场景复用模型检查器做 GLB 分析 |
|
||
| `src/models/model-thumbnail.ts` | 场景复用模型光栅化器出缩略图 |
|
||
| `admin/src/pages/Scenes.tsx` | 列表 / 上传 / 审核 / 删除 / 物理参数编辑（编辑期即按同一规则夹紧） |
|
||
| `admin/src/lib/scene-physics.ts` | 与后端同规则的收敛（保存前就不会产生非法枚举） |
|
||
|
||
> **MEDIUMTEXT 的原因**：`models.stats` 曾在 TEXT（65,535 字节）上溢出
|
||
> （实测 70,980 字节 → MySQL 1406 → 500）。场景的 `stats` 与 `config` 同样可能很大，
|
||
> 因此**一开始就用 MEDIUMTEXT**，并保留 `shrinkStatsForStorage()` 兜底。
|
||
|
||
## 验收
|
||
|
||
| 验收项 | 结果 |
|
||
|--|--|
|
||
| 场景可上传（GLB 直传 / zip 自动解包 / PMX 转换） | ✅ 与模型同一套转换管线 |
|
||
| 物理参数可在管理端可视化编辑 | ✅ 重力 / 风 / 摩擦 / 弹性 / 碰撞体 / 环境 / 出生点 / 相机 |
|
||
| 非法参数不会入库 | ✅ 前后端同规则收敛；`test/scene-config.spec.ts` 9 项边界用例 |
|
||
| 客户端能拿到场景 | ✅ `catalog/export.scenes[]`；目录指纹纳入场景变更 |
|
||
| 路由与契约一致 | ✅ `check-routes` 共 **35** 条 |
|
||
|
||
## 缺陷修复记录（v0.7.2）
|
||
|
||
**缺陷**：`CatalogModule` 的 `imports` 里漏了 `ScenesModule`。
|
||
|
||
`CatalogService` 因为 `catalog/export` 要下发 `scenes[]` 而注入了 `ScenesService`，
|
||
但 Nest 的 DI 是**按模块**解析的 —— 不在同一个模块的 `imports` 里，就解析不到。
|
||
后果是 `node dist/main.js` 在 bootstrap 阶段直接抛
|
||
`UnknownDependenciesException: Nest can't resolve dependencies of the CatalogService (... ? ...)`，
|
||
**服务完全起不来**（v0.7.0 / v0.7.1 的产物都是这样）。
|
||
|
||
**为什么当时没被发现**：三层检查全都"绿"——
|
||
|
||
| 检查 | 为什么没抓到 |
|
||
|--|--|
|
||
| `nest build` / `tsc --noEmit` | 模块 import 缺失是**运行时** DI 问题，类型系统看不出来 |
|
||
| 258 项单元测试 | 它们直接 new 服务或测纯函数，**从不编译 `AppModule`** |
|
||
| 打包脚本的产物完整性校验 | 只校验文件清单、压缩包结构与 PE/魔数，不启动服务 |
|
||
|
||
**修复**：在 `CatalogModule.imports` 中补上 `ScenesModule`。
|
||
|
||
**防线**：新增 `scripts/check-bootstrap.mjs`，以正式部署方式
|
||
（`ExecStart=node dist/main.js`、**不带任何 npm 环境变量**、**不需要数据库**）
|
||
拉起真实产物，断言①无依赖解析类错误②启动日志里的应用版本等于 `package.json`
|
||
③启动确实推进到数据库连接阶段。已挂进 `npm run verify` 与
|
||
`scripts/package-release.sh`（构建后、打包前），并做过**反向验证**：
|
||
把 `ScenesModule` 删除后该检查立刻失败。
|