CAPVCO v0.6.1 Surviving clusterctl move. Four defects found by an external Sylva integration run against v0.6.0, three of which made an unattended pivot impossible — and a Sylva management bootstrap ends in a clusterctl move by design. - #40 providerID was recomputed from machine.UID on every reconcile, so a move rewrote it while the Node kept the original and CAPI reported healthy Nodes as NodeDeleted. Kubernetes forbids correcting a Node's providerID, making it a one-way door. Now assigned once and never changed. - #39 ensureLoadBalancer created what it should have discovered. A move drops status by design, so it retried CreateServerPool against a pool that already existed, forever. The backend is now the source of truth and status a cache: both objects are discovered by name, and a create conflict resolves by discovery. - #44 adopting a cloudspace by name had no ownership check, so a duplicate VCOCluster could adopt live infrastructure and destroy it on delete. Not blocked — the backend cannot distinguish a duplicate from a legitimate recovery — but now recorded in status.cloudspaces[].adopted and surfaced as an AdoptedLiveCloudspace warning event when the adopted cloudspace already runs VMs. - #41 a credential value with a trailing newline broke Authorization header construction. All credential fields are now trimmed at ingestion. Also: a e2e scenario, the twelfth feature-matrix cell. Nothing had ever performed a clusterctl move, which is exactly why #39 and #40 reached a release. It moves a loadbalancer-exposed cluster to a second management cluster and asserts the infrastructure is adopted rather than recreated and that no provider id changes on either side. Green on real hardware. Documented: installing CAPVCO with GitOps instead of clusterctl (#47, #50) — clusterctl move refuses without Provider inventory records, and a manager image override must match the post-transformation name. Still open and not ours to land: the VCO backend 502 (#42) and Sylva chart support (#43). Unchanged known limitations: RWO volumes are not single-node-safe (#22) and encrypted volumes need cryptsetup in the CSI image (#32).