diff --git a/MEMORY.md b/MEMORY.md
index ca3d94f..340e78b 100644
--- a/MEMORY.md
+++ b/MEMORY.md
@@ -715,3 +715,62 @@ Next: the bisect plan step 2 — spawn a **stock `AWheeledVehiclePawn`** with `S
 - **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.
+
+## 2026-11-10 — Vehicle: the physics-asset recreation fixed the float; box-centre +32.4 is wrong
+
+After the plugin enablement gave 4 wheels, the pawn still floated at Z 545 in both probe
+maps. Two more findings close that:
+
+- **Regenerating the physics asset fixed the float.** The committed `PA_Vehicle_Sedan`
+  was a stale body (the prior "one chassis body" commit `5dd53ac` changed the builder but
+  the asset was never re-generated). Rebuilding it through the current
+  `UGigLineVehicleBuilder::build_physics_asset` (one `root` body, box 452x205x40 at
+  centre 0,0,−18) and assigning it back to `SK_Vehicle_Sedan.physics_asset` made the pawn
+  **fall and settle at Z 78** (≈ wheel radius + suspension above the floor) in both the
+  control and terrain probe maps. `create_vehicle` → `wheels 4`, `output present`.
+
+- **Box centre +32.4 is wrong.** I tried moving the chassis box from −18 to
+  `+Extent.Z*0.45` (=+32.4) on the theory that −18 put the body below the ground. It made
+  it **worse**: the box then overlaps the wheel bones (at +33), the Chaos vehicle fails to
+  set up, and the pawn reports `simulating=0` and stays at spawn (Z 300). Reverted. The
+  working value is the original **−18**, because `GetWheelRestingPosition`/`LocateBoneOffset`
+  measures wheel position against the root **bone** (origin), not the box, so the box
+  centre is effectively ignored by the suspension — and +32.4 breaks the wheel/chassis
+  separation. Do not "correct" the box centre without re-testing settle.
+
+- **The regeneration is not wired into any script.** `build_physics_asset` is a
+  `UBlueprintFunctionLibrary` (callable from Python as
+  `unreal.GigLineVehicleBuilder.build_physics_asset(mesh, dest, "PA_Vehicle_Sedan")`), but
+  `ue_vehicle_import.py` imports the skeletal mesh and never creates/assigns the physics
+  asset. Next step is to add that call to the import (delete + rebuild + assign + save) so
+  the asset is reproducible, then re-run the `-drivetest` (driving is still untested).
+
+- **Editor vs game target:** `build_physics_asset` is `#if WITH_EDITOR`, so it lives in the
+  **editor** module (`libUnrealEditor-GigLine.so`). `Build.sh GigLine Linux Development`
+  does **not** recompile it — you must build `GigLineEditor`. The box-centre change I made
+  looked like a no-op because the editor module was stale; the `.so` mtime is the tell.
+
+Uncommitted when pausing: `PA_Vehicle_Sedan.uasset` is currently at the **+32.4** box
+(wrong — regenerate at −18), `SK_Vehicle_Sedan.uasset` points at it, and the four
+`VehicleProbe*.umap` churn should be reverted. `GigLineVehicleBuilder.cpp` is reverted/clean.
+
+## 2026-11-10 — Vehicle float: the delete+recreate physics asset is fragile
+
+The "settle at Z 78" result was transient. Recreating `PA_Vehicle_Sedan` again (the
+second/third delete + rebuild + assign cycle) flipped the pawn to **`simulating=0` and
+stuck at spawn Z 300**, with the same box centre −18 that had settled minutes earlier.
+So the box centre is not what flips settle↔stuck; the **delete + recreate cycle is** —
+the same failure shape as the material `delete_asset` bug earlier: `delete_asset` does not
+fully release the package, `NewObject`/`CreatePackage` then reuses stale state, and the
+rebuilt body ends up not simulating (`PhysicsType` left at default, not `Simulated`).
+
+- The plugin enablement (`5e328f5`) remains the solid fix: `CreateVehicle` → 4 wheels.
+- The physics asset still needs a **proper** fix, not delete+recreate: set
+  `BodySetup->PhysicsType = EPhysicsType::PhysType_Simulated` (and any Chaos-required
+  flags) in `GigLineVehicleBuilder::BuildPhysicsAsset`, and update the asset **in place**
+  rather than deleting it.
+- `ue_vehicle_import.py` was wired to regenerate the asset, but its `SOURCE` is stale
+  (`/tmp/gigline/hatch` — the static template) while the skeletal FBX lives in
+  `/tmp/gigline/vehicle`; the wired block is therefore never reached. Fix the source path
+  (or move the FBX) before relying on the import to rebuild the physics asset.
+- Driving (`-drivetest`) is still untested; settling worked only in the transient run.