Class KinematicSystem

Advances every tracked node's KinematicController once per fixed step (§39 step 4).

const system = new KinematicSystem();
registry.register(system);
node.addComponent(new KinematicController());
node.transformAuthority = "kinematic"; // §42
system.track(node);
Copy

Three components, one system, one authority (§42; PH-11 residue, 2026-08-21)

This system also advances §12's CharacterController and §44's FirstPersonLook, for ConstraintSystem's reason: all three components write a transform under the same "kinematic" authority, and §42's check compares the authority, not the system instance — so a second system would be a second writer that nothing could catch. Within a node the order is fixed:

1. locomotion — CharacterController (position and yaw);
2. free look — FirstPersonLook (rotation only);
3. commands — KinematicController (moveTo, rotateTo, followPath).

The command channel runs last deliberately: a scripted move is what takes a character away from the player, so an active command wins over locomotion for the steps it runs. They are alternatives, not layers — as an OrbitRig and a FollowRig on one node are.

A component is stepped only when it is active, and a node whose components are all idle is skipped before the §42 check, so it reports no conflict.

Tracking is explicit and mirrors MotionSystem's mechanism exactly, for the reasons documented there: the component is looked up every step (so attaching, detaching, or replacing it needs no re-tracking), the tracked set is iterated in insertion order (§33), a node with enabled === false is skipped, and mutating the set during a step follows Set iteration semantics. Stepping allocates nothing (plan D7).