Take the Debian step out of a plan that never needed one

The owner contradicted the plan, and the plan was wrong. It had the script
write Debian 13 and then had Task 4 turn that into a Proxmox host. In reality
you boot the provider's rescue system and install Proxmox directly — there is
no intermediate Debian for anyone to convert.

The section keys do NOT change. They are the only agreement with the platform
plan, and they are not worth touching for a rename — especially since they
still fit: Proxmox VE is Debian with the PVE kernel and packages on top. What
changes is what they mean, written down so the console labels them honestly:
debian_installed is "base system written", proxmox_installed is "PVE proven to
run".

Task 3 now uses installimage with a Proxmox image, and says the image name gets
pinned during acceptance instead of guessed here — the list belongs to the
provider and moves. No debootstrap and no hand-rolled partitioner: the provider
knows its own hardware, and a self-built boot path on someone else's metal only
comes back through their console. Hetzner dedicated only; a netcup path gets
written when there is a netcup machine to accept it on, because an unproven
fallback is exactly the assertion this plan avoids everywhere else (R22).

Task 4 keeps every line of knowledge from InstallProxmoxVe.php and needs all of
it — it just applies it to an image instead of a bare base. The codename table
now VERIFIES the pairing rather than creating it, and the enterprise repo that
ships with a Proxmox image has to go, because without a subscription it fails
every apt-get update and therefore every package install in the sections that
follow. Its acceptance now includes a clean apt-get update, which is the only
way to tell removal from overwriting.

Delivery is settled too, and was written down in neither document: a tar.gz
unpacked to /opt/clupilot/bootstrap. A curl | sh cannot carry a lib/, and the
separate files are load-bearing. A static archive is not an endpoint that
answers questions, so spec §5 stands.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

docs/superpowers/plans/2026-07-30-host-uebernahme-bootstrap-skript.md

@@ -58,6 +58,22 @@ Getrennte Dateien, weil `template.sh` und `network.sh` unabhängig voneinander
 geprüft und wiederholt werden — und weil ein Skript, das alles in einer Datei
 macht, beim Nachlesen im Fehlerfall unbrauchbar ist.
 
+**Wie es auf die Maschine kommt** (stand in keiner der beiden Fassungen, ist
+aber entschieden): als **Archiv**. Die kopierte Zeile aus dem Adminbereich holt
+`bootstrap.tar.gz`, packt es nach `/opt/clupilot/bootstrap` aus und startet von
+dort — ungefähr so:
+
+```sh
+curl -fsSL https://clupilot.cloud/bootstrap.tar.gz | tar xz -C /opt/clupilot \
+  && /opt/clupilot/bootstrap/clupilot-bootstrap.sh --code … --wg-private … …
+```
+
+Ein `curl … | sh` schied aus: es kann keine `lib/` haben, und die getrennten
+Dateien oben sind kein Schmuck. Das Archiv ist eine **statische Datei**, kein
+Endpunkt, der Auskunft gibt — Spec §5 bleibt damit unangetastet. Das Ausliefern
+selbst gehört zum Plattform-Plan (Task 7 zeigt die Zeile); dieser Plan setzt nur
+voraus, dass das Skript samt `lib/` unter `/opt/clupilot/bootstrap` liegt.
+
 ---
 
 ### Task 1: Gerüst, Melden und Nachreichen
@@ -121,9 +137,43 @@ genau hier seine einzige Gelegenheit, es nicht zu tun.
 
 - [ ] **Step 1: Schreiben**
 
-Debian 13 ins Zielsystem, **Root-Partition als letzte auf der Platte, kein LVM**
-(Falle 2 aus Block A — sie gilt für den Host genauso, weil die Vorlage später von
-hier aus gebaut wird). Danach Neustart aus dem Rettungssystem heraus.
+> **Korrigiert gegenüber der ersten Fassung.** Dort stand „Debian 13 ins
+> Zielsystem", und danach hätte Task 4 daraus einen Proxmox-Host gemacht. Der
+> Betreiber hat das bestritten, und er hat recht: aus dem Rettungssystem wird
+> **Proxmox direkt** installiert. Es gibt kein Debian-Zwischensystem, das
+> nachher jemand umbaut.
+>
+> **Die Abschnittsschlüssel bleiben trotzdem unverändert** — sie sind die
+> einzige Absprache mit dem Plattform-Plan und werden nicht wegen einer
+> Umbenennung angefasst. Sie passen auch weiterhin, denn Proxmox VE *ist*
+> Debian mit PVE-Kernel und -Paketen:
+>
+> - `debian_installed` = **Grundsystem geschrieben** (das Abbild liegt auf der
+>   Platte). Die Beschriftung in der Konsole heißt entsprechend
+>   „Grundsystem geschrieben", nicht „Debian installiert" — das ist Sache von
+>   Task 7 des Plattform-Plans (`hosts.section.*`).
+> - `proxmox_installed` = **PVE läuft nachweislich** (Task 4).
+
+Das Abbild schreibt **`installimage`** aus dem Hetzner-Rettungssystem, mit
+einem Proxmox-Abbild aus dessen Liste. Kein `debootstrap`, kein eigener
+Partitionierer: der Anbieter kennt seine Hardware besser als dieses Skript, und
+ein selbstgebauter Bootpfad auf fremdem Blech kommt bei einem Fehler nur über
+die Anbieterkonsole zurück.
+
+**Der genaue Abbildname wird bei der Abnahme festgehalten, nicht hier geraten.**
+Die Liste gehört dem Anbieter und ändert sich; das Skript sucht sie zur Laufzeit
+ab und **bricht ab, wenn es kein passendes Proxmox-Abbild findet** — dieselbe
+Regel wie beim unbekannten Release in Task 4.
+
+Die Partitionierung kommt aus den `PART`-Zeilen der `installimage`-Vorgabe:
+**Root-Partition als letzte auf der Platte, kein LVM** (Falle 2 aus Block A —
+sie gilt für den Host genauso, weil die Vorlage später von hier aus gebaut
+wird). Danach Neustart aus dem Rettungssystem heraus.
+
+**Anbieter:** heute nur Hetzner-dediziert. Ein zweiter Weg (netcup, kein
+`installimage`) wird erst geschrieben, wenn eine Maschine dasteht, auf der er
+abgenommen werden kann — ein ungeprüfter Rückfallpfad ist genau die Behauptung,
+die dieser Plan sonst überall vermeidet (R22).
 
 Der Neustart ist die erste Stelle, an der das Skript die Kontrolle verliert. Es
 hinterlässt deshalb einen systemd-Dienst, der es nach dem Hochfahren **selbst
@@ -153,7 +203,9 @@ bewiesen, bevor neu gestartet wird, nicht danach gehofft.
   Neustart von allein weiterläuft. **Dazu: nach dem Hochfahren in
   `/var/lib/clupilot/progress.jsonl` nachsehen, dass die Zeilen von *vor* dem
   Neustart noch dort stehen, mit ihren ursprünglichen Zeitstempeln.**
-- [ ] **Step 3: Committen.** `Write Debian and survive the first reboot`
+- [ ] **Step 3: Committen.** `Write the image and survive the first reboot`
+  (war `Write Debian and survive the first reboot`, bevor klar war, dass kein
+  Debian-Zwischensystem entsteht)
 
 ---
 
@@ -161,14 +213,38 @@ bewiesen, bevor neu gestartet wird, nicht danach gehofft.
 
 - [ ] **Step 1: Schreiben**
 
+> **Korrigiert mit Task 3.** PVE kommt jetzt schon mit dem Abbild. Dieser
+> Abschnitt **installiert** es also nicht mehr, er **nimmt es ab und bringt
+> seine Paketquellen in Ordnung** — und genau dafür wird dasselbe Wissen
+> gebraucht, nur an anderer Stelle.
+
 **Lies zuerst `InstallProxmoxVe.php`.** Die Codename-Tabelle dort kennt Debian 13
 und PVE 9 und ist aus einem echten Fehler entstanden. Übernimm sie, statt die
 Paketquellen zu tippen — und übernimm auch, dass ein **unbekanntes Release
-abbricht** statt zu raten.
+abbricht** statt zu raten. Vier Dinge stehen dort, die hier alle gebraucht
+werden:
+
+1. **Die Zuordnung Codename → Suite und Release-Schlüssel.** Ein Abbild, dessen
+   PVE-Suite nicht zu seinem Debian passt, ist ein Fund und kein Schönheitsfehler
+   — PVE gegen eine andere libc gebaut. Passt es nicht, **abbrechen**.
+2. **Ein unbekannter Unterbau bricht ab.** Nicht „trixie ist das neueste, also
+   trixie". Das nächste Debian ist auch unbekannt, und dann sieht niemand hin.
+3. **Die Enterprise-Quelle muss weg.** Ein Proxmox-Abbild bringt
+   `/etc/apt/sources.list.d/pve-enterprise.list` mit, und die scheitert ohne
+   Abonnement bei **jedem** `apt-get update`. Das ist keine Schönheitskorrektur:
+   danach schlägt jede Paketinstallation der folgenden Abschnitte fehl.
+4. **`Signed-By` auf die Proxmox-Quelle begrenzen.** Sonst bürgt der
+   Proxmox-Schlüssel für alles, was später in `sources.list` auftaucht. Deshalb
+   die `.sources`-Datei (deb822) und nicht die alte `.list`-Zeile — und die alte
+   dabei entfernen, weil eine stehengebliebene `bookworm`-Zeile auf einer
+   trixie-Maschine genau die Vermischung ist, die Punkt 1 verbietet.
 
 - [ ] **Step 2: Auf echter Hardware prüfen.** `pveversion` antwortet, der PVE-Kernel
-  läuft.
-- [ ] **Step 3: Committen.** `Install Proxmox from the sources this Debian actually has`
+  läuft (`uname -r` enthält `-pve`), und **`apt-get update` läuft ohne Fehler
+  durch** — das ist der Beweis, dass die Enterprise-Quelle wirklich weg ist und
+  nicht nur überschrieben wurde.
+- [ ] **Step 3: Committen.** `Point Proxmox at the sources this Debian actually has`
+  (war `Install Proxmox …`, bevor das Abbild PVE schon mitbrachte)
 
 ---