 zijunchiang
|
2433cd22a5
|
fix(boot): CatalogModule 漏 import ScenesModule 导致产物起不来 + /health 版本号错
两个都是**只有真正启动服务才会暴露**的缺陷，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。
|
2026-09-17 01:49:52 +08:00 |
|
 opendance
|
584b7eaca9
|
feat(scenes): 场景管理后端 + 契约 0.5.0/0.7.0/0.4.0（T-WEB-015）
契约先行（三端逐字节一致，已同步 windows/android）：
- rest-api -> 0.5.0：新增 GET/POST /api/scenes、GET/PATCH/DELETE /api/scenes/{id}
- data-models -> 0.7.0：新增 §7 Scene 与 7.1 SceneConfig（物理/环境/出生点/相机）
- database -> 0.4.0：新增 scenes 表（config/stats 用 MEDIUMTEXT，迁移可逆）
后端：
- entities/scene.entity.ts + 迁移 AddScenes1789650000000（scenes 表）
- scenes/scene-config.ts：SceneConfig 定义 + 默认值 + **边界收敛**（越界夹紧、
非法枚举回退），保证客户端拿到的参数一定可解释；服务端只存参数不跑物理
- scenes/scenes.service.ts：上传（.glb/.gltf 直接导入；.zip/.pmx/.fbx 转 GLB，
场景不做 humanoid 重绑定、不转 VRM）、列表/详情/更新/软删除、缩略图复用模型
光栅化器、分析复用模型检查器、config 同时接受 JSON 字符串与平铺字段
- scenes/scenes.controller.ts + scenes.module.ts（app.module 注册）
- 审核复用 /api/reviews/:type/:id：TargetType.Scene 接入待审列表与状态流转
- catalog/export 增 scenes[]，目录指纹纳入场景变更
- 枚举：TargetType.Scene、AssetKind.Scene / SceneThumbnail
测试：新增 test/scene-config.spec.ts 6 项（默认值/夹紧/枚举回退/出生点上限/颜色/
序列化）；规模 19 文件 / 243 项；check-routes 35 条一致。版本 0.6.0。
注：管理端场景页（GLB 预览 + 物理参数可视化）与 Windows 场景选择留待下一轮。
|
2026-09-17 00:27:08 +08:00 |
|
|
opendance
|
39bfd390e3
|
feat(models): 模型一律转 VRM（契约 0.5.0）+ 可用性门槛 + 管理端版本号展示
按《DSH 开发文档 v1.6》4.9 与第十一章实现，Web 端第一步：
1. 契约先行（先改 contracts/ 再同步三端）：
* model-formats.md -> 0.5.0：模型主力格式改为 VRM，所有上传模型一律转 VRM
（.pmx/.fbx: assimp -> GLB -> VRM；glb/gltf: 包装为 VRM）；
新增 humanoid 硬门槛与"不达标回退 GLB + usable=false"的交付表；
* data-models.md -> 0.5.0：Model 新增 usable / unusableReason，明确
usable=false 不进入 catalog/export；format 说明改为主力 vrm；
* VERSION 与 contract-versions.ts 同步（三端契约文件逐字节一致）。
2. 实现：
* MODEL_CONVERT_FORMAT 默认改为 vrm（deploy/.env.example 同步）；
* 新增 isUsableModel()/unusableReason()：usable 等价于"已产出 VRM"，
原因从 stats 里带出 humanoid 覆盖度；
* catalog/export 与 catalog/version 指纹都只统计 format=vrm 的已发布模型，
resolveDefaultModelId 同样只在可用模型中选；
* 管理端：模型列表与审核面板显示「不可用」及原因；
* 管理端左下角展示当前版本号（构建期从 web-server/package.json 注入
__APP_VERSION__，与 GET /health 同源），并去掉写死的"契约 rest-api 0.1.0"。
3. 测试：新增 test/model-usability.spec.ts 5 项；规模 16 文件 / 225 项。
4. 版本 0.3.0。
|
2026-09-17 00:05:02 +08:00 |
|
|
zijunchiang
|
0f66b53480
|
feat(web): 客户端目录导出 /api/catalog/export 与版本指纹
|
2026-09-14 19:00:55 +08:00 |
|