 zijunchiang
|
6ea2c93d66
|
fix(pack): 编码取整与参考实现对齐 + 产物不再夹带测试夹具（v0.2.4）
两个缺陷，都由上一轮的验收机制暴露：
1) 编码取整与契约参考实现不一致（T-WIN-022）
KeypointFrame.encode() 用 GDScript 的 roundi（半数远离零），而契约参考实现
（Web 的 keypoint-codec.ts）与**生产发送方 Android**（Kotlin Math.round）都是
「半数朝 +∞」：-2.5 分别是 -3 与 -2。实测在 12 个跨实现向量里 1 例 33 字节不同。
本端是接收方、encode() 只用于自测与协议回归，对产品无影响；但它让「跨实现一致性」
只能停留在宽松口径（"差异仅限 .5 取整边界"），而宽松口径会退化成没人看的已知差异。
修复：新增 _round_like_js(v) = floor(v + 0.5)，用于 4 处取整（坐标 ×3 + 置信度）；
夹紧顺序对任意实数与参考实现等价。
收紧：accept-frame-vectors.sh 的编码口径改为「必须为 0 项差异」。
新增单测（+11 断言）：_round_like_js 的 5 个取值、端到端 -0.5/32767 → 0（roundi
会给 -1，是有效判别用例），以及 test_reference_vectors_decode_and_encode_exactly
—— 直接读锁定的参考向量逐值解码 + 用 f32InputPoints 重编码与 f32Hex 逐字节比对，
让 verify.sh（只跑源码、无需 pck）也覆盖「Web ↔ Windows」这条边。
2) 产物里夹带开发/验收工具（T-WIN-023）
export_filter="all_resources" 且 exclude_filter 没有 build/*，于是每次新增
构建/验收脚本都被编译进 pck —— 包括**故意不合规**的坏服务端夹具 probe-ws-bad.gd
与 frame-vectors.json。实测 OpenDance.pck 315,464 B →（排除后）145,400 B，
即 54% 的 pck 是测试夹具。已发布的 v0.2.3 同样带着这些残留。
修复：exclude_filter 增加 build/*；
新增产物级防线 build/integration/list-pck.gd（遍历包内条目、标出
res://build/ tests/ _scratch/ dist-release/ 与 *.md 残留，有残留即退出码 1），
并接进 accept-release.sh（打印条目总数并断言「无开发残留」）——否则下次加个新
工具目录又会重演。顺带确认 pck 没有把上一次导出的 pck 自嵌套进去。
实测（v0.2.4 发布包，三条产物级验收全绿）：
* accept-release.sh：pck 58 项无开发残留 / PE 版本资源 0.2.4 / pck 启动 180 帧无错 /
运行时探针（包内版本号 0.2.4、AboutScreen 显示值、15 项关键资源、契约表比对）
* accept-ws.sh：客户端 30 通过 / 0 失败 + 服务端侧 16 项事实
* accept-frame-vectors.sh：解码 12/12、396 点 0 差异，
**编码器字节与参考实现完全一致（0 项差异）**
* verify.sh：785 通过 / 0 失败（原 774）
踩坑：给 -0.5/32767 这类值写断言时，第一版按"理想有理数"期望（2.5/32767 → 3）而
失败 —— PackedVector3Array 存的是 float32，乘回 32767 后略小于半整数，与 JS 对同一
float32 输入的行为其实完全一致。断言必须基于实际存储精度，或改用有效判别用例。
|
2026-09-17 05:59:54 +08:00 |
|
|
zijunchiang
|
ba988f6ca6
|
fix(packaging): 发布包 exe 的 PE 版本资源必须等于发布版本（v0.2.2）
缺陷（v0.2.1 实测）：把 opendance-windows-v0.2.1.zip 解开、在 Windows 上
「右键 → 属性 → 详细信息」，显示的是
文件版本 0.1.0
产品版本 0.1.0
而产物名、Git tag、README 全是 v0.2.1 —— 正是文档 §11.2 要禁止的
「不可核对的发布」。
根因：export_presets.cfg 的 application/file_version /
application/product_version 被硬编码在 0.1.0，而它们**不会**跟随
project.godot 的 application/config/version 自动更新；check-version.sh 当时
只比 project.godot ↔ project.yaml（两处一致），所以静态校验全绿、产物却是错的。
漂移发生在没人看的第三个位置 —— 校验位置少一个，等于没校验。
证据：
strings -a -el OpenDance.exe -> FileVersion 0.1.0 / ProductVersion 0.1.0
VS_FIXEDFILEINFO @0x67b976c -> FileVersion 0.1.0.0 / ProductVersion 0.0.0.0
对照组：官方模板 windows_release_x86_64.exe 的 FileVersion = 4.7.2，
说明本机 rcedit 改写是生效的，问题纯粹在预设的值本身。
修复：
* build/sync-export-version.sh（新增）：导出前把版本号写进导出预设，
幂等、拒绝非 X.Y.Z；
* build/check-pe-version.sh（新增）：直接读 exe 的 PE 版本资源 ——
VS_FIXEDFILEINFO（签名 0xFEEF04BD 后 16 字节，grep -abo 取偏移约 40 ms）
与 StringFileInfo（strings -el，资源管理器属性页显示的就是它）。
两处都查：实测固定信息里的 ProductVersion 恒为 0.0.0.0；
* build/check-version.sh：新增导出预设两个键的校验；
* build/export-windows.sh：导出前同步、导出后直接复核产物；
* build/package-release.sh：打包前校验源 exe、解包后再校验包内 exe；
* build/verify.sh：新增步骤 1/5「产物 PE 版本资源」（未导出则跳过）；
* tests/test_about.gd：新增 test_export_preset_version_matches_project_version。
反向验证：把预设 file_version 改回 0.1.0 →
check-version.sh 退出码 1（报出两处不一致）；
无头测试 753 通过 / 1 失败，失败项正是
「导出预设的 file_version 与版本号唯一来源一致」。
实测 v0.2.2 产物：PE FileVersion 0.2.2.0 / StringFileInfo 0.2.2，
版本号在 project.godot / project.yaml / export_presets.cfg / exe 元数据 /
产物名 / tag 六处一致。verify.sh 全绿（754 通过 / 0 失败 / 5 跳过）。
同时把 LZMA 压缩的取舍写清楚：deflate 包 38,248,818 B 仍超 IIS
30,000,000 B 上限，故 Release 资产仍是 LZMA 整包（26,628,529 B，不拆分卷）；
若上限放开或改由 Web /static 分发，用 ZIP_METHOD=deflate 重打包即可得到
资源管理器可直接双击解压的包。
|
2026-09-17 04:22:57 +08:00 |
|