diff --git a/Game/GigLine/GigLine.uproject b/Game/GigLine/GigLine.uproject
index fe0b5d4..ac358ac 100644
--- a/Game/GigLine/GigLine.uproject
+++ b/Game/GigLine/GigLine.uproject
@@ -14,6 +14,10 @@
 		{
 			"Name": "EnhancedInput",
 			"Enabled": true
+		},
+		{
+			"Name": "ChaosVehiclesPlugin",
+			"Enabled": true
 		}
 	]
 }
diff --git a/Game/GigLine/Source/GigLine/GigLineVehicle.cpp b/Game/GigLine/Source/GigLine/GigLineVehicle.cpp
index bfd7fb9..07a9b4e 100644
--- a/Game/GigLine/Source/GigLine/GigLineVehicle.cpp
+++ b/Game/GigLine/Source/GigLine/GigLineVehicle.cpp
@@ -65,9 +65,12 @@ AGigLineVehicle::AGigLineVehicle(const FObjectInitializer& ObjectInitializer)
 		{
 			Body->SetSkeletalMesh(MeshFinder.Object);
 		}
-		Body->SetCollisionEnabled(ECollisionEnabled::QueryAndPhysics);
-		Body->SetCollisionProfileName(TEXT("PhysicsActor"));
-		Body->SetSimulatePhysics(true);
+		// The Chaos vehicle movement component drives this mesh through its async physics; it
+		// calls CreateVehicle() on the movement component, which builds the wheels and the
+		// vehicle state. Calling SetSimulatePhysics(true) here instead put the mesh into the
+		// REGULAR rigid-body solver, which is why CreateVehicle() never ran (output null,
+		// wheels 0) and why the plain body then teleported upward in DemoMap. Leave the physics
+		// to the movement component.
 	}
 
 	if (UChaosWheeledVehicleMovementComponent* Movement =
diff --git a/MEMORY.md b/MEMORY.md
index 5b8efea..ca3d94f 100644
--- a/MEMORY.md
+++ b/MEMORY.md
@@ -708,3 +708,10 @@ Rebuilt and re-ran the `ue_vehicle_probe_map.py` workflow (after `chmod u+w` the
 - The `1 cm` bounds (`extent 1,1,1`) persist in the diagnostic and are a **stale component read**, not the mesh (the imported `SK_Vehicle_Sedan` bounds are the correct 476 × 228 × 144 cm).
 
 Next: the bisect plan step 2 — spawn a **stock `AWheeledVehiclePawn`** with `SK_Vehicle_Sedan` beside `AGigLineVehicle` in the terrain probe map. If the stock pawn also rises, the asset + terrain interaction is at fault; if it settles, `AGigLineVehicle`'s setup (movement subclass, mass override, panel attachment) is.
+
+## 2026-11-10 — Vehicle "0 wheels" root cause: ChaosVehiclesPlugin was disabled
+
+- **The Chaos vehicle never existed because `ChaosVehiclesPlugin` was not enabled.** It is `EnabledByDefault: false`, it was absent from `GigLine.uproject` (only `EnhancedInput`), and absent from `Config/*.ini`. Consequence, read straight from the engine source (`ChaosVehicleMovementComponent.cpp` `OnCreatePhysicsState`): `CreateVehicle()` runs only when `World->IsGameWorld() && GetPhysicsScene() && FChaosVehicleManager::GetVehicleManagerFromScene(PhysScene)` — and the manager is null when the plugin module never started. So the vehicle stayed at `setups=4 wheels=0 output=null`, and the mesh fell back to **regular** rigid-body physics (the constructor's `SetSimulatePhysics(true)`), which is what teleported upward.
+- **Fix:** add `{"Name": "ChaosVehiclesPlugin", "Enabled": true}` to `GigLine.uproject`. Result: `CreateVehicle() entered → wheels 4`, `first UpdateState - output present`, `diag ... setups=4 wheels=4`.
+- **Also removed** `SetSimulatePhysics(true)` / `SetCollisionProfileName("PhysicsActor")` / `SetCollisionEnabled` from the `AGigLineVehicle` constructor: the Chaos movement component drives the mesh through its async physics, and forcing the regular rigid-body solver is what kept the body out of the vehicle solver.
+- **The plugin fix converts "teleport up" into "float at Z 545".** With 4 wheels the pawn now settles at a stable Z 545 (540 cm above the ReviewMap floor at Z 5) in *both* the control and terrain probe maps — no teleport, but the suspension holds the chassis ~5 m too high. That is the next bug: wheel radius / suspension rest-length / chassis-box offset, not the vehicle creation.