opendance-web

63 Commits 2 Branches 17 Tags

3 Commits

Include renames

Author	SHA1	Message	Date
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
zijunchiang	53bf182476	feat(models): 发布 v0.2.0 —— GLB/VRM 主力格式、自动缩略图与分析、模型审核与骨骼预览需求 1：系统确定以 GLB / VRM 为模型主力格式 - 服务端新增支持库： - model-inspector.ts：解析 GLB/VRM 的面数、顶点、材质、贴图、形变目标、骨骼树（名称/层级/是否蒙皮/humanoid 映射/子节点数）、humanoid 覆盖率与可驱动性 - model-thumbnail.ts：纯 TS 软件光栅化（z-buffer + Lambert + 完整蒙皮矩阵）生成 512×512 PNG 缩略图，零原生依赖、不装 headless-gl - vrm-writer.ts：GLB → VRM 1.0（写入 VRMC_vrm 扩展与 humanoid 映射） - gltf-packer.ts：glTF（.gltf + .bin + 贴图）→ 单文件 GLB - humanoid 候选表与 Godot 客户端 humanoid_map.gd 逐字对齐，并有单测断言两边一致（服务端判定的"可驱动" = 客户端实际能否驱动）需求 2：模型管理 - .glb / .vrm / .gltf 直接导入（不重编码，GLB 含 VRM 扩展会自动识别为 VRM） - .pmx / .fbx 服务端转换：assimp → .glb →（失败）→ .gltf 后自行打包成 GLB →（MODEL_CONVERT_FORMAT=vrm 时）补 VRMC_vrm 产出 VRM 1.0；每步 assimp info 回读校验 - .zip 自动搜索包内可用模型：.vrm → .glb → .gltf（直接导入）优先，其次 .pmx → .fbx（转换）；同优先级内按"指名字 → 目录最浅 → 文件最大" - 入库后自动分析（models.stats）与生成缩略图（models.thumbnail_asset_id），失败均不阻断入库；管理端列表显示小缩略图、预览放开到 vrm/glb/gltf 需求 3：审核功能 - 上传的模型状态一律 pending（不再自动发布、不再自动设默认） - 审核界面新增模型面板：体积、面数、顶点、材质、贴图、骨骼、形变目标等指标， humanoid 覆盖进度、可驱动性结论（缺哪些必需骨骼）、warnings，以及骨骼详细预览（层级缩进、蒙皮/Humanoid 徽章、子节点数、搜索保留祖先链、仅看蒙皮、限高滚动 + 只渲染前 400 行） - 审核通过可带 setPrimary=true 一并设为默认模型（此时才写源码种子）； POST /api/models/:id/primary 仅允许 published（否则 409） - scripts/import-default-model.mjs 改为"上传 → 审核通过 + 设默认"流程其它： - models 新增 stats 列（迁移 AddModelStats1789460000000，已在真实库执行） - 契约升至 rest-api/data-models/model-formats 0.4.0、database 0.3.0（另两库已同步） - 版本号 0.1.0 → 0.2.0（package.json ×2 + lockfile + project.yaml） - 文档：README.txt / DSH.md / project.yaml / tasks 005·007·010 全面更新；顶层开发书更新为 v1.4 验证：168 项单测通过（10 文件）；契约 6 项与 29 条路由一致；typecheck/build 通过；真实端到端：MMD 压缩包 → GLB + 分析(面数 9071/骨骼 238/humanoid 0-22) + 缩略图(15KB PNG)； GLB 直接导入 sha256 与源文件一致；审核通过后 defaultModelId 由 VRM 变为该模型	2026-09-15 20:37:53 +08:00
zijunchiang	bd6cb9fa90	feat(web): T-WEB-001 NestJS 骨架 + 连接现有 MySQL 实例	2026-09-14 19:00:55 +08:00

Author

SHA1

Message

Date

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

zijunchiang

53bf182476

feat(models): 发布 v0.2.0 —— GLB/VRM 主力格式、自动缩略图与分析、模型审核与骨骼预览

需求 1：系统确定以 GLB / VRM 为模型主力格式
- 服务端新增支持库：
  - model-inspector.ts：解析 GLB/VRM 的面数、顶点、材质、贴图、形变目标、
    **骨骼树（名称/层级/是否蒙皮/humanoid 映射/子节点数）**、humanoid 覆盖率与可驱动性
  - model-thumbnail.ts：**纯 TS 软件光栅化**（z-buffer + Lambert + 完整蒙皮矩阵）
    生成 512×512 PNG 缩略图，零原生依赖、不装 headless-gl
  - vrm-writer.ts：GLB → VRM 1.0（写入 VRMC_vrm 扩展与 humanoid 映射）
  - gltf-packer.ts：glTF（.gltf + .bin + 贴图）→ 单文件 GLB
- humanoid 候选表与 Godot 客户端 humanoid_map.gd **逐字对齐**，并有单测断言两边一致
  （服务端判定的"可驱动" = 客户端实际能否驱动）

需求 2：模型管理
- .glb / .vrm / .gltf **直接导入**（不重编码，GLB 含 VRM 扩展会自动识别为 VRM）
- .pmx / .fbx 服务端转换：assimp → .glb →（失败）→ .gltf 后自行打包成 GLB
  →（MODEL_CONVERT_FORMAT=vrm 时）补 VRMC_vrm 产出 VRM 1.0；每步 assimp info 回读校验
- .zip **自动搜索包内可用模型**：.vrm → .glb → .gltf（直接导入）优先，
  其次 .pmx → .fbx（转换）；同优先级内按"指名字 → 目录最浅 → 文件最大"
- 入库后自动分析（models.stats）与生成缩略图（models.thumbnail_asset_id），
  失败均不阻断入库；管理端列表显示小缩略图、预览放开到 vrm/glb/gltf

需求 3：审核功能
- 上传的模型状态**一律 pending**（不再自动发布、不再自动设默认）
- 审核界面新增模型面板：体积、面数、顶点、材质、贴图、骨骼、形变目标等指标，
  humanoid 覆盖进度、可驱动性结论（缺哪些必需骨骼）、warnings，以及
  **骨骼详细预览**（层级缩进、蒙皮/Humanoid 徽章、子节点数、搜索保留祖先链、
  仅看蒙皮、限高滚动 + 只渲染前 400 行）
- 审核通过可带 setPrimary=true 一并设为默认模型（此时才写源码种子）；
  POST /api/models/:id/primary 仅允许 published（否则 409）
- scripts/import-default-model.mjs 改为"上传 → 审核通过 + 设默认"流程

其它：
- models 新增 stats 列（迁移 AddModelStats1789460000000，已在真实库执行）
- 契约升至 rest-api/data-models/model-formats 0.4.0、database 0.3.0（另两库已同步）
- 版本号 0.1.0 → 0.2.0（package.json ×2 + lockfile + project.yaml）
- 文档：README.txt / DSH.md / project.yaml / tasks 005·007·010 全面更新；
  顶层开发书更新为 v1.4

验证：168 项单测通过（10 文件）；契约 6 项与 29 条路由一致；typecheck/build 通过；
真实端到端：MMD 压缩包 → GLB + 分析(面数 9071/骨骼 238/humanoid 0-22) + 缩略图(15KB PNG)；
GLB 直接导入 sha256 与源文件一致；审核通过后 defaultModelId 由 VRM 变为该模型

2026-09-15 20:37:53 +08:00

zijunchiang

bd6cb9fa90

feat(web): T-WEB-001 NestJS 骨架 + 连接现有 MySQL 实例

2026-09-14 19:00:55 +08:00