diff --git a/docs/runbooks/kubernetes-talos.md b/docs/runbooks/kubernetes-talos.md
index 4825156..6c338df 100644
--- a/docs/runbooks/kubernetes-talos.md
+++ b/docs/runbooks/kubernetes-talos.md
@@ -368,29 +368,33 @@ merge gate, so the workflow deploys without re-running the checks.
 
 **Prerequisite: the VM must have been installed with the §1 patch.** A stock Talos config
 gives you a node that still carries the control-plane taint and knows nothing about the
-plain-HTTP registry, which the deploy hits in that order: the `registry` pod sits `Pending`
-until `rollout status` times out, and once that's fixed every repo image fails to pull. Both
-are one patch, applied live — no reboot:
+plain-HTTP registry, and the deploy hits those in that order: the `registry` pod sits
+`Pending` until `rollout status` times out, and once that is fixed every repo image fails to
+pull. Two separate fixes:
 
 ```bash
-# on the Fedora host
-cat > /tmp/talos-patch.yaml <<'YAML'
-cluster:
-  allowSchedulingOnControlPlanes: true
+# on the Fedora host — 1. let workloads onto the only node (§1)
+export KUBECONFIG=~/talos-kubeconfig-local
+kubectl taint node --all node-role.kubernetes.io/control-plane-
+
+# 2. trust the in-cluster registry over plain HTTP (§2)
+cat > /tmp/registry-patch.yaml <<'YAML'
 machine:
-  certSANs:
-    - <TALOS_VM_IP>
   registries:
     mirrors:
       "<TALOS_VM_IP>:30500":
         endpoints:
           - http://<TALOS_VM_IP>:30500
 YAML
-talosctl -n <TALOS_VM_IP> -e <TALOS_VM_IP> patch mc --patch @/tmp/talos-patch.yaml
+talosctl -n <TALOS_VM_IP> -e <TALOS_VM_IP> patch mc --patch @/tmp/registry-patch.yaml
 ```
 
-`allowSchedulingOnControlPlanes` rather than `kubectl taint node --all …-` because the
-controller puts the taint back; the patch is what makes it stick across a reboot.
+Keep those two apart. On Talos 1.14 a patch that also sets
+`cluster.allowSchedulingOnControlPlanes` is rejected with *".cluster.allowSchedulingOnControlPlanes
+is already set in v1alpha1 config"* — the field moved out of the v1alpha1 schema, the same way
+`machine.install` did (§1) — and the rejection takes the whole patch with it, so the mirror
+silently doesn't land either. `kubectl taint` is the documented way (§1); it is undone if the
+node ever re-registers, which is a reboot, not a deploy.
 
 The cluster's API and registry are not exposed publicly, so the job forwards them over the
 same SSH hop the Gitea-runner pipeline uses: