Fix/shaderlab

[luzhuang]

Please check if the PR fulfills these requirements

• The commit message follows our guidelines
• Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features)

What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)

What is the current behavior? (You can also link to an open issue here)

What is the new behavior (if this is a feature change)?

Does this PR introduce a breaking change? (What changes might users need to make in their application due to this PR?)

Other information:

[GuoLei1990]

审查（2026-05-15）

总结

本轮新增两个 commit（5ec7e3f + ab190ac）：

• 5ec7e3f fix(physics): route kinematic transform sync through setKinematicTarget + fix Transform._cloneTo world-flag dispatch — 将 per-frame transform 同步路径拆分为 _teleportToEntityTransform（init/clone）和 _syncEntityTransformToNative（每帧），DynamicCollider 覆盖后者，kinematic 时走 move()（即 setKinematicTarget）而非 setGlobalPose，解决 kine-kine/kine-dynamic onCollisionEnter 不触发问题；同时修复 Transform._cloneTo 漏发 world-flag 导致 clone 后 collider 位置 stale 的 bug。
• ab190ac chore: release — 版本号 game.11 → game.12，无逻辑改动

方向完全正确，PhysX setKinematicTarget vs setGlobalPose 的区别是核心问题所在，修复直指根因。Transform dirty-flag 传播修复也准确。

---

问题

[P1] Transform._cloneTo 测试绕过公开 entity.clone() 链路

// tests/src/core/Transform.test.ts
// @ts-ignore
source.transform._cloneTo(target.transform);  // 直接调用私有方法
expect(target.transform.worldPosition).deepEqual({ x: 1, y: 2, z: 3 });

这个 bug 的触发链路是：entity.clone() → 组件 ctor 提前读 worldPosition（清 dirty flag） → _cloneTo 写新值 → Collider 读到 stale (0,0,0)。测试却直接调 _cloneTo，绕过了 entity.clone() 的完整 clone 流程（包括组件的 _cloneFrom 顺序）。

这带来两个问题：

1. 如果有人重构 entity.clone() 内部调度顺序，导致 bug 复现，测试仍然绿——因为它不走 entity.clone() 路径。
2. 测试的实质是验证"直接调 _cloneTo 后 worldPosition 正确"，而非"clone 后 collider 不读到 stale position"。

建议改为从公开 API 测：

// 源 entity 在 (1,2,3)
const src = rootEntity.createChild("src");
src.transform.setPosition(1, 2, 3);
src.addComponent(DynamicCollider);  // DynamicCollider ctor 会读 worldPosition

const cloned = src.clone();
// 断言 cloned 上的 DynamicCollider 收到正确的 worldPosition 通知
// （可通过检查 native actor 位置或注册 worldChangeFlag 来断言）

---

[P2] Collision.test.ts — "frozen + teleport" 测试只有 resolve 无 reject，失败机制是 expect.fail() 意外 throw

it("dynamic + frozen-6 + teleport: ...", function () {
  return new Promise<void>((resolve) => {  // ← 缺少 reject 参数
    // ...
    if (!fired) {
      expect.fail("expected onCollisionEnter to fire...");  // ← throw 导致 Promise 隐式 reject
    }
  });
});

当前偶然能工作（expect.fail() throw 被 Promise 构造器捕获后隐式 reject），但这不是标准写法。正确形式：

return new Promise<void>((resolve, reject) => {
  // ...
  if (!fired) {
    reject(new Error("expected onCollisionEnter to fire for dynamic-frozen pair after teleport"));
  }
});

与同文件中其他 probeKinematicCallback 测试（显式传 reject）保持一致。

---

[P0] e2e/config.ts 删除后 e2e/tests/index.spec.ts 仍然 import "../config" — CI 必然报错（已提 2 轮，仍未修复）

PR diff 删除 e2e/config.ts，但 e2e/tests/index.spec.ts 仍 import { E2E_CONFIG } from "../config"（硬依赖，无降级），合并后 playwright suite 无法启动。

---

[P1] UIPointerEventEmitter._bubble — 冒泡结束后 currentTarget 未清空（已提 5 轮，仍未修复）

for (let i = 0; i < length; i++) {
  eventData.currentTarget = path[i];
  fireEvent(path[i], eventData);
}
// 缺少：eventData.currentTarget = null;

---

[P1] Collider._onUpdate — _onPhysicsUpdate 每帧对所有 shape 无条件调用（已提 3 轮，仍未修复）

_onUpdate(): void {
  if (this._updateFlag.flag) {
    // ... transform sync ...
  }
  for (let i = 0, n = shapes.length; i < n; i++) {  // ← 在 guard 块外，每帧无条件调用
    shapes[i]._onPhysicsUpdate();
  }
}

---

[P1] findAnimatorState 返回类型 breaking change 且语义错误（已提 2 轮，仍未修复）

state 未在播放时，返回的是当前播放的 srcPlayData（其 .state 是另一个动画），语义错误。应返回 null。

---

[P2] PointerEventData.target / currentTarget 类型声明不含 null（已提 5 轮，仍未修复）

target: Entity = null;        // 应为 Entity | null
currentTarget: Entity = null; // 应为 Entity | null

[GuoLei1990]

说明

PR #2983（Fix/shaderlab）是一个大型综合 PR，包含多个方向的改动（ShaderLab、动画、GLTF 加载器、物理、UI 等）。从 PR 描述来看，其中的动画+GLTF 修复已被抽离到 #2999，物理 raycast/sweep 修复已被抽离到 #2998。

建议继续将剩余改动拆分成独立 PR 再逐一合入 dev/2.0，而不是合并这个全量 PR。原因：

1. 混合多个功能域的 PR 难以做 code review（注意力稀释）
2. 如果其中某个方向有问题，回滚代价高
3. PR 描述模板中的 checklist 全部未填写，缺少变更说明

如果后续有独立拆分的 PR，请在各 PR 上发起 review。此 PR 暂不做详细 diff 审查。