Propose, review, and modify dependencies within the current Work Item, then return to threejs-game-workflow-control audit. When the user permits required plugins, dependencies proven necessary by requirements may be installed; paid services, external services, or publishing are not enabled by default.
First read Capability and Integration Table, and select the minimal set according to gameplay. three/addons and three must come from the same locked version; development tools do not enter the runtime bundle. For each adopted capability, record its purpose, exact version/lockfile, applicable renderer, initialization order, destruction responsibility, bundle/memory budget, and verification command.
When Android/iOS native hosts or platform capabilities are involved, follow the architecture Skill'sNative Platform Plugin Selection: reuse existing plugins → official plugins → community plugins → minimal in-house builds for clear capability gaps. Versions, permissions, licenses, lifecycles, platform adaptation layers, and necessary host configuration are governed by that rule.
Acceptance for physics plugin integration is fixed timestep, collision filtering, motion body types, coordinate units, and pause/resume; for navigation it is reachability, dynamic obstacles, and NavMesh updates; for model decoders it is loading actual compressed samples and deployment paths; for post-processing it is worst-case GPU cost and quality tiers. Successful installation only proves that dependencies can be resolved.
Existing React projects may choose React Three Fiber with a matching drei; new projects default to using three.js directly. Do not install multiple physics engines, audio libraries, or rendering post-processing systems that serve the same role at the same time.