190 Commits (c0f83ab957c280d24e705f22e548591820d46074)

Author	SHA1	Message	Date
nexxo	c0f83ab957	Seitenleiste neu geordnet: Betrieb trug zwoelf Eintraege aus drei Themen	2026-08-02 00:29:14 +02:00
nexxo	1207182662	Ein angehefteter Host umging die Reservierung ... Heftet ein Betreiber eine geparkte Bestellung an einen Host, prüfte der Anheft-Zweig nur die Kapazität — nicht, ob die Maschine jemand anderem reserviert ist. Die frisch gebaute Reservierung ließ sich damit über einen ganz normalen Weg durch die Oberfläche aushebeln, denn das Auswahlfeld auf der Kapazitätsseite bot weiterhin alle aktiven Hosts an. Der Schritt stellt jetzt dieselbe Bedingung wie die freie Platzierung — unreserviert oder dem Kunden dieser Bestellung reserviert — über Host::scopeUnreserved(), statt sie ein zweites Mal zu formulieren. Ein Pin auf eine fremde Maschine wird nicht umgeleitet, sondern wartet (awaiting_pinned_host): zu korrigieren ist die Wahl, nicht die Maschine. Und die Ursache eine Ebene höher: das Auswahlfeld stellt fremd reservierte Hosts gar nicht mehr zur Wahl, pin() lehnt sie zusätzlich ab, und ein Pin, der seit dem Anheften reserviert wurde, sagt das in der Zeile — ein Auswahlfeld, das dann kommentarlos wieder "Automatisch" zeigte, verschwiege, warum die Bestellung weiter wartet. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-01 18:53:11 +02:00
nexxo	b95cae1669	Test für den Normalfall der Statusanzeige: "Im Verkauf" ... Drei der vier Zustände waren belegt, der häufigste nicht. Eine reine assertSee() wäre nicht falsifizierbar gewesen: die Spaltenüberschrift "plans.live_version" übersetzt zufällig auf denselben Satz wie die Plakette "plans.on_sale" und stünde selbst dann auf der Seite, wenn keine Zeile die Plakette zeigte — deshalb über die Häufigkeit geprüft (Überschrift kommt genau einmal vor, mehr als das beweist eine echte Zeile). Mit einer Mutation (sellable-Prüfung stumpf auf false) probeweise als rot bestätigt, dann zurückgesetzt. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-01 18:04:28 +02:00
nexxo	6314bb60fb	Schalter je Paket, ehrliche Statusanzeige, Reste der alten Leiter ... Die Umschaltmigration verglich beim Erkennen eines bereits umgeschalteten Bestands nur Kontingent und Platte. Bei Intern waren beide schon vorher richtig (5/20 GB), also hielt sie das Paket für erledigt und ließ RAM, Kerne und Plätze auf ihren alten Werten stehen (1024 MB/1 Kern/5 statt 4096 MB/2/3). Die Prüfung vergleicht jetzt alle neun Vorgaben; eine zweite, kleine Migration hebt einen Bestand nach, auf dem die erste schon lief, und tut nichts auf einer Neuinstallation. Die Statusanzeige unterschied bisher nicht zwischen "kein Angebot" und "läuft, aber nicht im Laden" — ein internes Paket zeigte "Nichts verfügbar" in der Liste und "Im Verkauf" auf der Versionsseite darunter. Vier Zustände statt zwei, mit fester Reihenfolge: der Notausschalter (sales_enabled) schlägt die Konsolen-Kennzeichnung (internal). Ein zweiter Schalter je Paketfamilie nimmt sie aus dem Preisblatt, ohne sie unverkäuflich zu machen — nach dem Vorbild des vorhandenen Verkaufsschalters, ohne Bestätigungsmodal, weil reversibel. Enterprise wechselt von sales_enabled=false (weder käuflich noch verschenkbar) auf internal=true, wie das Testpaket. Dazu die liegengebliebenen Zahlen der alten Leiter in Produktattrappe, Mail-Vorschau, Fabrik-Vorgaben und Seedern, sowie eine Testzusicherung, die auf eine wandernde ID statt auf den berechneten Wert hätte treffen können. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-01 17:53:06 +02:00
nexxo	f961205512	Die neue Leiter: Start 39, Team 79, Business 139 ... Zugeschnitten auf die Maschine, die dasteht. 388 GB vergebbar geteilt durch 40 GB Platte sind neun Startkunden statt drei — Speicher und RAM gehen damit gleichzeitig aus, wo vorher sechs RAM-Plaetze verfielen. 351 Euro Umsatz je Server statt 147. Umgeschaltet wird durch Beenden und Nachfolgen, nicht durch Aendern: eine veroeffentlichte Version ist unveraenderlich, und laufende Vertraege tragen ihren eigenen Schnappschuss. Als Migration und nicht als Befehl, weil der Katalog von einer Migration gesetzt wird — sonst blieben Neuinstallation und Testsuite auf einer Leiter, die wir nicht mehr verkaufen. Enterprise verlaesst den Verkauf (2000 GB finden auf 388 GB keinen Host), das Testpaket heisst Intern und wird intern — es steht ausserdem zum ersten Mal im Katalog einer frischen Installation, statt von Hand angelegt werden zu muessen. Dreissig Testdateien nennen die neuen Zahlen. Drei Faelle waren keine Zahlen: Vertraege auf Enterprise entstehen nur noch als Bestandsvertraege (Helfer asGrandfathered() in tests/Pest.php), die Preisblatt-Stufe "Premium" haengt am Paket, das den Laden verlassen hat, und ein Katalogleser, der die einzige Preiszeile einer Familie suchte, findet seit der Handreichung zwei. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-01 17:05:58 +02:00
nexxo	ce7d0426cb	Fix-Runde: preferredDatacenter() blind fuer Reservierung, Loeschen hob sie auf ... preferredDatacenter() waehlte das Rechenzentrum ueber Host::availableGb() ohne ->unreserved() - ein Rechenzentrum mit einem grossen, aber komplett reservierten Host sah geraeumiger aus als eines mit echtem allgemeinem Bestand. Der Checkout haette die Bestellung dorthin gelegt, placeableIn() haette dort niemanden gefunden, und sie waere geparkt, obwohl anderswo Platz war. Jetzt ->unreserved(), derselbe Bestand wie largestPlaceableGb(). Die Migration nutzte nullOnDelete() und tat damit das Gegenteil der eigenen Vorgabe: die Reservierung sollte einen Kundenaustritt nicht stillschweigend ueberleben, loeste sich mit nullOnDelete() aber genau so auf, sobald der Kunde verschwindet. restrictOnDelete() macht das Loeschen eines Kunden mit eigener Maschine zum Fehler, bis ein Operator die Reservierung von Hand gelöst hat - Migration und Modellkommentar sagen jetzt dasselbe. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-01 16:21:46 +02:00
nexxo	4ad1828f27	Ein reservierter Host gehoert seinem Kunden ... placeableIn() nahm jeden aktiven Host im Rechenzentrum, und hasRoomFor() sowie largestPlaceableGb() zaehlten eine exklusiv verkaufte Maschine obendrein mit — der Shop versprach damit Platz, der bereits vergeben war. Ohne diese Markierung ist 'eigener Server' ein Satz im Angebot und nirgends eine Tatsache. hosts.reserved_for_customer_id (nullable, ueberlebt den Kunden) markiert die Maschine; Host::placeableIn() und HostCapacity zaehlen sie nur noch fuer den eigenen Mieter oder gar nicht mehr zum allgemeinen Bestand. Auf der Host-Detailseite kann ein Operator reservieren und wieder loesen — Loesen laeuft ueber ein eigenes Bestaetigungsmodal (R23), das selbst nichts aendert, sondern nur an HostDetail::releaseReservation() zurueckmeldet. Host-Liste und Kapazitaetsseite weisen eine reservierte Maschine als solche aus, statt sie kommentarlos verschwinden zu lassen. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-01 16:06:14 +02:00
nexxo	c3c05ff9f8	Interne Pakete verschwinden aus dem Laden und bleiben in der Konsole ... sales_enabled waere der falsche Hebel gewesen: es schaltet auch das Verschenken ab. Das Testpaket ist fuer Abnahmelaeufe da und muss verschenkbar bleiben, also zwei Felder fuer zwei Fragen. Der Checkout lehnt einen internen Schluessel ausdruecklich ab, ueber denselben Fang wie einen unbekannten — eine URL ist keine Liste, und die Antwort darf keinen Unterschied verraten. GrantPlan las bislang dieselbe sellable()-Liste wie Preisblatt und Warenkorb, sowohl fuer sein Dropdown als auch fuer die Validierung des Formularfelds — ein interner Schluessel waere dort ebenso abgelehnt worden wie im Checkout, und das Verschenken haette sein einziges Tor verloren. PlanCatalogue bekommt deshalb grantable() als zweiten Leser derselben Abfrage. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-01 15:31:46 +02:00
nexxo	11ba7ee34f	Hostdetailseite: die Adresse steht neben den IPs und ist ein Klick zur Proxmox-Oberflaeche	2026-08-01 14:12:03 +02:00
nexxo	c815aee0b5	Fix-Runde 1: Vorabpruefung vor dem Unique-Index, zwei Praezisierungen, ein fehlender Test ... Migration: die Reihenfolge in up() stellte den unwiderruflichsten Schritt (app_settings loeschen, dns_name-Spalte weg) VOR den einzigen Schritt, der an vorhandenen Daten scheitern kann (unique('name') - hosts.name trug noch nie einen eindeutigen Index). Schlug der auf MariaDB fehl, war der Schaden nicht mehr rueckgaengig zu machen: DDL committet dort implizit, die Migration gilt aber mangels Eintrag in der Migrationstabelle als nicht gelaufen, und ein zweiter up()-Versuch stirbt an der bereits fehlenden dns_name-Spalte. Jetzt steht eine reine Vorabpruefung ganz am Anfang, die simuliert, was die Uebertragung schreiben wuerde, und mit einer RuntimeException abbricht, bevor irgendetwas angefasst ist; das Loeschen der app_settings-Zeilen steht jetzt hinter dem Unique-Index, nicht davor. Gegen echtes MariaDB geprueft, einschliesslich eines Laufs mit zwei absichtlich kollidierenden Hostnamen. HostStepsTest: Titel und ein Kommentar praezisiert - der Schritt vergibt den Namen nicht mehr, er veroeffentlicht ihn nur noch. HostNamingTest: ungenutzten Import entfernt (Pint), Rueckfall-Test fuer HostName::label() bei einem Code ohne gueltige Zeichen ergaenzt. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-01 14:03:35 +02:00
nexxo	d62a2c8ff8	Hostnamen vergibt CluPilot: ein Name statt zweier, und der Zaehler ueberlebt das Loeschen ... HostName::claim() haengt den Namen jetzt an die Rechenzentrums-Zeile (next_host_number), nicht an MAX(hosts.name)+1: der Zaehler ueberlebt so das Loeschen des zuletzt angelegten Hosts. hosts.dns_name faellt weg - name ist ab jetzt der einzige Name, den Konsole, DNS, /etc/hosts und Proxmox-Node teilen. RegisterHostDns veroeffentlicht nur noch, was StartHostOnboarding beim Anlegen vergeben hat, statt selbst zu nummerieren; PrepareBaseSystem baut den FQDN ueber HostName::fqdn() statt ueber die nirgends konfigurierte clupilot.net. Zwei Testdateien ausserhalb der Aufgabenliste (DatacenterTest, HostTakeoverPageTest) setzten ->set('name', ...) auf HostCreate, das Feld jetzt aber nicht mehr hat - im vollen Testlauf nachgezogen. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-01 13:45:43 +02:00
nexxo	55b749c129	Release v1.3.94 — die Kurven zeigen wieder, wie ausgelastet der Host ist ... Drei Punkte des Besitzers, und der dritte hat den eigentlichen Fehler freigelegt. Die Verlaufslinien sahen komisch aus, weil sie auf ihr EIGENES Minimum und Maximum skalierten. Ein Host mit 0,2 % CPU, der zwischen 0,1 und 0,3 schwankt, zeichnete damit einen Seismographen über die volle Höhe — und widersprach flach der Zahl direkt daneben. Dieselbe Regel stand im Chart.js-Entwurf schon ausformuliert ("eine automatisch skalierte Achse lässt 3 % wie eine Wand aussehen") und ging beim Umstieg auf die Kacheln verloren. x-ui.spark bekommt deshalb `min`/`max`. Ohne Angabe bleibt alles wie bisher — das ist, was jeder bestehende Aufrufer übergibt. Die Prozent-Kacheln geben 0 und 100 mit, die Netz-Kacheln nur die 0, weil MiB/s keine natürliche Obergrenze haben. Ein untätiger Host zeichnet jetzt vier ruhige Linien statt zweier wogender und zweier flacher — vorher wirkte CPU (0,2 %) belebter als RAM (3,6 %), also genau verkehrt herum. Dazu: Werte außerhalb der Grenzen werden geklemmt statt aus dem Kasten gezeichnet, die Fläche ist ein Verlauf statt einer harten Kante, und die Linien sind mit 120×40 statt 80×32 lesbar. Ich hatte max=100 zwischendurch selbst verworfen, weil es "zu tot" aussah — auf einem Bild, auf dem die Füllung wegen eines CSS-Fehlers gar nicht gezeichnet wurde. Ein Vergleich mit einem kaputten Bild. Der Fehler: `.spark path { fill: none }` schlägt als CSS-Regel das Präsentationsattribut fill="url(#…)". `fill: none` gehört an die Linie, nicht an jeden Pfad. Die Ausstattung ist wieder einzeilig. Sechs Felder, sechs Spalten — und die Bau-Kennung steht nur noch im Titel: als eigene Zeile zwang sie die ganze Tafel in eine zweite Reihe, für eine Zeichenkette, die fast niemand liest. Und die Wartezeit: die Seite stößt beim Öffnen eine Sammlung an, wenn noch keine Messwerte da sind, statt bis zum nächsten minütlichen Lauf leer zu bleiben. Ein leerer Kasten liest sich als "kaputt", nicht als "gleich". Der Job ist ShouldBeUnique, zwei geöffnete Seiten reihen also keine zwei ein. Codex-Befund dazu (P2): das galt auch für Hosts, die der Sammler ohnehin überspringt — ein Host mitten in der Übernahme hat keinen Token, und seine Seite hätte die ganze Flotte abgeklappert und die eigenen Kacheln trotzdem leer gelassen. Wer gesammelt wird, steht jetzt einmal am Modell (Host::collectable), gelesen von Job und Seite. Zwei Fassungen dieser Frage waren genau der Grund. Geprüft: 2307 Tests grün, Pint sauber, Codex ohne Befund. Der Test für den Maßstab prüft jetzt auch die echten Aufrufstellen und nicht nur das Bauteil — gegengeprobt durch Entfernen von max=100, dann fällt er. Im Browser beide Fälle angesehen: ruhiger Host vier flache Linien, ausgelasteter Host lesbare Form, null Konsolenfehler. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-01 11:56:10 +02:00
nexxo	dc35e5310f	Release v1.3.93 — die Seite konnte den Host gar nicht fragen ... Auf echter Hardware blieb jede Messkachel leer, während der Host sichtbar online war und vor zwei Minuten geantwortet hatte. Kein Zufall und kein Aussetzer: ein Entwurfsfehler. Nur der queue-provisioning-Container hängt im WireGuard-Netz — NET_ADMIN, /dev/net/tun, das wireguard-Volume. Der app-Container, der die Konsole rendert, hat überhaupt keine Route zu 10.66.0.x. Ich hatte den Proxmox-Aufruf in render() gelegt, also in den einen Container, der die Management-Adresse nicht erreichen kann. Ein Aufruf von dort konnte nie etwas anderes sein als eine Zeitüberschreitung. PingHosts schreibt dieselbe Regel seit Langem in seinen Kopf: "runs on the provisioning queue, which is where the Proxmox credentials are usable." Ich habe sie gelesen und nicht angewendet. Verschlimmert hat es mein eigenes catch (Throwable): der Grund wurde verschluckt, und die Kachel sagte "keine Messwerte" — ununterscheidbar davon, dass der Host schweigt. Auf dem Testhost fiel nichts auf, weil TEST-NET ohnehin nie antwortet. Jetzt zwei Hälften: - HostLoadSeries::collect() holt und legt ab, aus Jobs\CollectHostLoad auf der provisioning-Warteschlange, minütlich — der Takt, in dem Proxmox einen frischen Messwert schreibt. Ein Fehlschlag wird protokolliert, mit Host, Node und Grund. - HostLoadSeries::forHost() liest nur aus dem Zwischenspeicher und öffnet nie eine Verbindung. Ein Test hält das mit Http::assertNothingSent() fest. Der Eintrag lebt fünf Minuten bei minütlichem Sammeln: länger als der Takt, damit ein ausgefallener Lauf keine Seite leert, die eine Sekunde vorher in Ordnung war — und kurz genug, dass ein stehengebliebener Sammler die Zahlen mitnimmt, statt eine alte Stunde als aktuell stehenzulassen. Der Sammler ist ShouldBeUnique (Codex-Befund, P1). Die provisioning-Warteschlange ist DIESELBE, auf der Kunden-Bereitstellung läuft; ein stiller Host kostet den vollen HTTP-Zeitablauf, und ohne diese Sperre stauten sich minütlich neue Läufe hinter dem alten und verzögerten bezahlte Arbeit. Dasselbe Mittel, das CollectInstanceTraffic nebenan schon benutzt. Dazu: der Zustands-Punkt war mit 62 px so groß wie der Speicher-Ring nebenan. Eine gefüllte Scheibe wiegt optisch weit mehr als ein dünner Ring und erschlug die Kachel — jetzt 32 px. Und ein Test, der aus Versehen recht behielt: die Kachel-Prüfung verglich mit "50", was auch die 500 GB in der Instanzenliste darunter trifft. Sie prüft jetzt Zahlen, die sonst nirgends auf der Seite vorkommen. Noch offen, nicht hier angefasst: VmTemplateCheck fragt die Proxmox-API ebenfalls aus dem app-Container heraus, von der Bereitschaftsseite aus. Selber Fehler, Bestand, eigener Punkt. Geprüft: 2299 Tests grün, Pint sauber, Codex ohne Befund. Im Browser mit eingespielten Messwerten: sechs gefüllte Kacheln, Zustands-Scheibe in Proportion. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-01 11:23:00 +02:00
nexxo	589489a9fc	Release v1.3.92 — sechs Kacheln statt dreier ungleicher Kästen ... Nach der Vorlage des Besitzers. Zustand, Speicher und die gemeinsame Kurve standen nebeneinander: zwei davon halb leer, die dritte überfüllt, und die gemeinsame Kurve brauchte eine Legende, um zu sagen, welche Linie welche ist. Eine Reihe je Kachel löst alle drei Beschwerden auf einmal. Die Beschriftung der Kachel benennt die Reihe, also braucht es keine Legende mehr. Die Höhen sind durch das Raster gleich statt zufällig. Und der leere Platz ist mit Messwerten gefüllt, die es ohnehin schon gab: Proxmox' Aufzeichnung liefert Netzdurchsatz in beide Richtungen mit, ungefragt. Sechs Kacheln: CPU-Auslastung, RAM-Auslastung, Speicher (als Ring), Eingehend, Ausgehend, Zustand. Gebaut mit x-ui.metric, x-ui.spark und x-ui.ring — die gab es alle schon, und der Kopfkommentar von x-ui.metric sagt selbst "exactly as the approved template draws it". Nichts daneben neu gebaut. Die öffentliche IP steht jetzt auf der Seite. Sie stand vorher NUR klein unter der Überschrift — die Adresse, unter der der Host wirklich erreichbar ist, war in der Detailseite nirgends ein Feld. Sie führt jetzt die Ausstattungs-Tafel an, und die Reserve-Eingabe ist mit dorthin gezogen: die Kacheln zeigen, was gemessen wurde, die Tafel, was eingestellt ist. Ein Eingabefeld zwischen Messwerten sähe aus, als ließe sich eine Messung ändern. Alle vier Verlaufslinien tragen denselben Ton. Die Regel steht im Bauteil selbst — "muted where the figure is observed, accent where it can be acted on" —, und hier ist keine Zahl anzufassen. Vier verschiedene Töne nebeneinander behaupten einen Unterschied, den es nicht gibt. Zwei Funde aus der Prüfung -------------------------- - x-ui.spark warf fehlende Messwerte per array_filter heraus und verband die Nachbarn. Zwei Fehler auf einmal: die Linie behauptete eine Messung, die es nicht gab, und alles danach rutschte nach links — eine Stunde mit zwei Lücken zeichnete sich als achtundfünfzig Minuten. Die x-Lage kommt jetzt aus dem Platz in der URSPRÜNGLICHEN Reihe, und zusammenhängende Messwerte werden als eigene Züge gezeichnet. Eine saubere Reihe ergibt genau einen Zug und dasselbe Bild wie vorher, was alle bisherigen Aufrufer liefern. - Der Zwischenspeicher überlebt einen Deploy. Ein Eintrag aus v1.3.91 kennt netin/netout nicht, und die Host-Seite wäre 55 Sekunden lang an einem fehlenden Schlüssel gestorben — genau in der Minute, in der jemand nachsieht, ob das Update durch ist. Der Schlüssel heißt jetzt host-load:v2:<id> und wandert mit der Form mit. Und einer, den kein Prüfer gemeldet hat: beim Zerlegen in Züge stand im Flächenpfad ein `L` unmittelbar vor einem `M`. Gültig gelesen, nicht gezeichnet — die Füllung verschwand still. Aufgefallen ist es beim Ansehen der Seite, nicht durch eine Meldung; jetzt prüft ein Test, dass jeder Flächenpfad mit M anfängt, mit Z endet und keinen Befehl direkt hinter einem anderen trägt. x-ui.chart behält seinen update-on-Weg, obwohl diese Seite ihn nicht mehr benutzt: er ist eine geprüfte Fähigkeit des gemeinsamen Bauteils, und der darunterliegende Fix (Instanz aus dem reaktiven Alpine-Objekt) gilt für jeden Chart. Geprüft: 2291 Tests grün, Pint sauber, Codex ohne Befund. Im Browser mit eingespielten Messwerten: sechs Kacheln, Lücke als echte Aussparung in Linie UND Fläche, Leerzustand zeigt "—" statt einer Null, null Konsolenfehler über einen vollen Poll-Zyklus. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-01 11:02:55 +02:00
nexxo	665a0c4e08	Release v1.3.91 — die Host-Seite zeigt Last statt Ausstattung ... Die Karte "Rechenleistung" zeigte keine Leistung. 12 Kerne und 63 GB sind die Ausstattung des Blechs und ändern sich nie — sie standen aber im selben Kartenraster wie "Zustand" und "Speicher", die beide leben. Wer die Seite öffnete, um zu sehen, wie es dem Host geht, las dort eine Zahl, die das nie sagen konnte. An ihrer Stelle steht jetzt die Last: CPU und RAM als Stundenkurve, beide in Prozent auf EINER Achse, dazu die aktuellen Werte als beschriftete Zahlen. Die Geschichte kommt aus Proxmox' eigener Aufzeichnung (/nodes/{node}/rrddata), nicht aus einem eigenen Sampler. Ein Sampler hieße neue Tabelle, minütlicher Job, Aufräum-Job und ~1440 Zeilen je Host und Tag — um weniger genau nachzubauen, was ohnehin auf der Platte liegt. Die RRD ist ab der ersten Sekunde gefüllt, auch für die Stunde vor dem ersten Hinsehen, und kann nicht von dem abweichen, was Proxmox' eigene Oberfläche zeigt. Eine Lücke bleibt eine Lücke: ein Punkt ohne Messwert wird null, nie 0, und spanGaps steht auf false. Dieselbe Regel wie in instance_metrics. Antwortet der Host gar nicht, sagt die Tafel das in einem Satz, statt eine ruhige Stunde zu zeichnen — auf dem Testhost live bestätigt. Der Fehler, den das ans Licht gebracht hat ------------------------------------------ x-ui.chart steht überall unter wire:ignore, sonst zerstört Livewire das Canvas. Ein Poll erreicht den Chart also nie. Dafür bekam das Bauteil ein optionales update-on: es hört auf ein Fenster-Ereignis und tauscht die Daten IM bestehenden Chart.js-Objekt. Das lief nicht. Die Zahlen neben der Kurve wanderten, die Kurve nicht, und chart.update() starb still im Legenden-Plugin: TypeError: Cannot set properties of undefined (setting 'fullSize') Grund: die Chart.js-Instanz lag als Eigenschaft im Alpine-Objekt und wurde damit reaktiv umhüllt. Chart.js' Plugin-Innenleben überlebt das Proxy nicht. Gemessen statt geschlossen: dieselbe Instanz wirft über das Proxy und läuft über Alpine.raw(). Sie liegt jetzt in der Closure. Aufgefallen ist es nie, weil bis zum ersten Live-Chart kein einziger Chart in diesem Repo je update() gerufen hat — konstruieren und Erstzeichnen gehen durch die Hülle noch. tests/Feature/ChartLiveUpdateTest.php hält die Regel fest, damit der nächste Live-Chart nicht denselben Nachmittag kostet. Der Rest -------- - Version lesbar: "Proxmox VE 9.2.6" statt pve-manager/9.2.6/7f8d…, mitten in der Bau-Kennung abgeschnitten. Die Kennung steht klein darunter. Eine unerwartete Form wird unverändert durchgereicht statt verschluckt. - Vier Kleinkarten (Mgmt-IP, Node, Version, Instanzen) sind eine Ausstattungs-Tafel geworden. Die Instanzen-Anzahl steht in der Überschrift der Liste, die sie ohnehin zeigt. - Der Übernahme-Fortschritt klappt zu, sobald sie durch ist. Fünfzehn abgehakte Schritte sind auf einem laufenden Host kein Dauerinhalt — aufklappbar über <details>, ohne JavaScript. - PlanVersion::requiredTemplateVmids() ersetzt die dritte Kopie derselben Fensterlogik. - BuildVmTemplate sagt nicht mehr "this takes 10–20 minutes". Das war eine Schätzung vor dem ersten Lauf; gemessen waren es unter zwei. Eine Konsole, die falsch vorhersagt, erzieht dazu, sie zu ignorieren. Geprüft: 2281 Tests grün, Pint sauber, Codex ohne Befund. Die Farbwahl gegen den Validator gerechnet (ΔE 28,3 protan / 39,2 normal; der Akzent liegt unter 3:1 gegen die Fläche, deshalb tragen beide Reihen sichtbare Beschriftung). Im Browser: null Konsolenfehler über einen vollen Poll-Zyklus, und die Kurve wandert auf dem echten Poll ohne Neuladen — mit eingespielten Messwerten belegt, weil die Testhosts in TEST-NET liegen und nie antworten. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-01 10:24:21 +02:00
nexxo	b9fb401823	Release v1.3.85 — Handshake-Prüfung hing an einem Programm, das es nicht gibt ... Die Übernahme brach in "WireGuard einrichten" ab: fünf Wiederholungen, "WireGuard handshake not up yet". Geprüft wurde mit `ping -c1 -W2 <hub-ip>`. Das fragte drei Dinge auf einmal und nannte nur eines: ob der Handshake steht, ob ICMP durchkommt — und ob es `ping` auf der Maschine überhaupt GIBT. Auf Hetzners `Debian-trixie-latest-amd64-base` gibt es das nicht. `iputils-ping` ist im Image nicht dabei, und PrepareBaseSystem installiert `curl gnupg ifupdown2 chrony`. Der Schritt scheiterte damit über einem Tunnel, der stehen konnte. Auf dem alten Proxmox-Image war ping dabei, deshalb lief es dort durch — dieselbe Pipeline, anderes Grundsystem. Gefragt wird jetzt WireGuard selbst: `date +%s; wg show wg0 latest-handshakes`. Die Uhr des HOSTS kommt in derselben Antwort mit, weil `latest-handshakes` eine absolute Zeit ausgibt und ein Vergleich gegen UNSERE Uhr eine Zeitverschiebung zwischen zwei Maschinen als Tunnelzustand läse. `date` ist in coreutils und überall da. Codex, zwei Runden: - P1: `> 0` hiesse "hat jemals". WireGuard behält den Zeitstempel unbegrenzt, also meldete ein Wiederholungslauf über einem toten Tunnel "steht", und die Schritte danach wählten die Tunneladresse für SSH. Jetzt muss der Handshake frisch sein (180 s) und vom KONFIGURIERTEN Hub kommen — ein fremder Peer auf wg0 ist kein Beweis dafür, dass wir erreichbar sind. - P1: Der neue Host-Versatz (.100) liess die Vergabe in einem Subnetz kleiner als /26 "erschöpft" melden, obwohl unten alles frei war. Der Versatz ist eine Bevorzugung, keine Bedingung: zweiter Durchgang von vorn. Ausserdem, wie gewünscht: Hosts bekommen ihre Tunneladresse ab .100 (CLUPILOT_WG_HOST_OFFSET), Personen zählen weiter von unten. Fortlaufend vergeben landete der erste Host zwischen zwei Notebooks, und wer eine Adresse in einem Protokoll las, konnte nicht sagen, ob dahinter ein Mensch oder eine Maschine steht. 2243 Tests grün. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-01 03:00:19 +02:00
nexxo	2f15d1e7a4	Release v1.3.84 — VPN-Zugänge nach Personen und Hosts getrennt ... Personen und Hosts standen gemischt untereinander, nach Verbindungszustand sortiert — ein Host-Zugang konnte also zwischen zwei Mitarbeitern stehen. Beide sind Peers im selben Netz und haben dieselben Messwerte, aber es sind zwei verschiedene Fragen: "wer von uns ist im Netz" und "welche Maschinen hängen dran". Wer die eine stellt, liest die Antworten der anderen als Rauschen. Jetzt zwei Gruppen mit Überschrift und Anzahl. Eine Gruppe ohne Einträge wird gar nicht erst gezeichnet — auf einer frischen Installation stünde sonst "Hosts" über einer Lücke, bevor je einer angelegt wurde. Getrennt wird nach der geladenen host-Beziehung, nicht nach `kind`: die Plakette in der Zeile fragt dasselbe, und wer einen "Host-Zugang" liest, soll ihn auch unter den Hosts finden. Ein adoptierter Peer (kind=system) mit host_id gehört zu den Hosts, obwohl seine Art etwas anderes sagt. Die Zeile selbst ist nach resources/views/components/admin/vpn-peer-row.blade.php gewandert. Sie zweimal hinzuschreiben hätte geheissen, sie ab dem nächsten Knopf an zwei Stellen zu pflegen — und die zweite fällt erst auf, wenn jemand einen Host-Zugang sucht und ihn anders aussehen sieht als seinen eigenen. Die Plakette bleibt trotz der Überschrift daneben: eine Zeile wandert beim Suchen aus ihrer Überschrift heraus, und dann steht sie ohne sie da. Codex: keine Befunde. 2237 Tests grün. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-01 02:34:15 +02:00
nexxo	ac81bc5b98	Release v1.3.82 — Übernahme-Befehlszeile neu ausstellen ... Die Zeile gab es genau einmal: auf der Seite direkt nach dem Anlegen. Wer sie dort nicht kopierte — oder wem sie wegbrach, wie beim WireGuard-Fehler bis 1.3.80 — hatte danach einen Host in der Liste, für den es keinen Weg zu einer Befehlszeile mehr gab. Ein zweites Anlegen scheitert an der eindeutigen IP, also blieb nur Entfernen und von vorn. HostTakeoverCommand behauptet in seinem Kopfkommentar, die Zeile werde "an zwei Stellen gezeigt (beim Anlegen und beim Neuausstellen eines Codes)". Das Zweite gab es nie — ein Kommentar, der eine Absicht beschreibt und wie eine Beschreibung des Gebauten klingt. Neu: ReissueTakeover als Modal auf der Host-Detailseite. Bestätigen zuerst (R23), denn ein bisher ausgegebener Code wird dabei wertlos; danach steht die ganze Zeile mit Kopieren-Knopf darin, nicht nur der Code. Codex, zwei Runden, beide Male dieselbe Sorte Fehler von mir — die Ansicht versteckt den Knopf, die Methode prüft nichts: - P1: `issue()` erzwingt jetzt selbst, welcher Zustand zulässig ist. Ein Modal, das offen blieb, während der Host aktiv wurde, rief die Methode trotzdem; eine Livewire-Methode ist ohnehin von aussen aufrufbar. - P2: `issue()` prüft die Tunnel-Einstellungen erneut. Sonst wird ein gültiger Code entwertet und dafür eine Zeile ausgegeben, der die WireGuard-Angaben fehlen — genau die kaputte Zeile, vor der die Warnung daneben steht. - P1 der zweiten Runde: `disabled` gehörte nicht in die Liste der zulässigen Zustände. Es sieht aus wie "noch nicht fertig" und ist das Gegenteil — toggleMaintenance() schaltet einen LAUFENDEN Host so still. Der Knopf hätte eine Produktionsmaschine zur Neuinstallation angeboten. Die Bedingung steht deshalb einmal am Bauteil (ReissueTakeover::eligible) und wird von Ansicht und Methode gefragt: zwei Fassungen liefen auseinander, sobald jemand eine ändert. 2231 Tests grün. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-01 01:00:53 +02:00
nexxo	fb1ef3fc63	Rollen: aufklappbare Karten, gruppierte Rechte, Knopf im Raster	2026-07-31 22:39:46 +02:00
nexxo	93e848d3f9	Rollen und Rechte in der Konsole zuweisbar	2026-07-31 21:46:22 +02:00
nexxo	6a6a672c11	Pruefergebnis als Modal statt am Seitenende	2026-07-31 21:36:43 +02:00
nexxo	f91726d078	Testergebnis erscheint am Feld statt am Seitenende; DNS-Token bekommt einen Testknopf	2026-07-31 21:26:14 +02:00
nexxo	82c6d62057	Stripe-Client: offene Rechnungen listen und einziehen	2026-07-31 20:04:09 +02:00
nexxo	200df30b9d	Hetzner-Cloud-DNS, Bereitschaftsseite aus sich heraus behebbar ... Die alte Hetzner-DNS-API ist abgeschaltet (301 auf die Weboberflaeche). Jede Bereitstellung starb in ConfigureDnsAndTls, nachdem der Kunde bezahlt hatte. HttpHetznerDnsClient und DnsTokenCheck sprechen jetzt die Cloud-API: Bearer statt Auth-API-Token, RRSets ueber {name}/{typ} statt Record-IDs, der Zonen-Lookup entfaellt. Gegen das Live-Konto gemessen, nicht geraten. Drei Fallen, die am Konto gemessen wurden: TXT-Werte muessen in Anfuehrungszeichen (sonst 422, was als read_only gemeldet worden waere), ein Name mit Zonensuffix wird STILL angenommen (201), und der Fake gab andere IDs aus als der echte Client -- zwoelf Tests waren gruen ueber einem Abbau, der im Betrieb geworfen haette. Bereitschaftspunkte, die nur eine Shell beheben konnte, sind jetzt bedienbar: SSH-Schluesselpaar erzeugen (Ed25519 ueber phpseclib, privater Teil direkt in den Tresor), Stripe-Katalog abgleichen (Warteschlange, Trockenlauf, Ausgabe wortgleich), Mailzustellung als Schalter statt MAIL_MAILER, Neustart der Arbeiterprozesse. Stripe hat jetzt alle drei Werte in der Konsole: Secret Key, Signatur-Secret (Tresor, je Modus getrennt) und Publishable Key (Klartext). Codex-Review (R15), zwei P1 behoben: der Signaturschluessel faellt nicht mehr vom Live- in den Testplatz, und eine Record-ID aus der alten API macht einen Host nicht mehr unloeschbar -- was adressierbar ist, wandelt eine Migration um, der Rest wird beim Loeschen laut uebergangen statt geworfen. 2109 Tests gruen. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-31 19:50:01 +02:00
nexxo	272cfe45e8	Keep IP addresses out of a certificate overview ... 127.0.0.1 was in the list on the live server, marked as console, showing "no valid certificate: Connection refused" in red. It came from ADMIN_HOSTS, where a bare IP is deliberately allowed — it is the way back into the console when a name does not resolve. My filter only asked for a dot, and 127.0.0.1 has three. Let's Encrypt does not issue for IP addresses, so that row was permanently red and nobody could ever fix it. A red line that cannot be acted on is worse than no line: it teaches the reader to skip the colour, which is the one thing the overview needs them not to do. Two checks now, not one: the address test, and a last label that is not numeric. A TLD is never a number, and that also catches the forms FILTER_VALIDATE_IP lets through. The row already in the database goes away on the next sync, because otherwise my mistake would sit on every installation that has already updated. Vanished config rows are handled by what they carry: one that never had a certificate was a mistake and is deleted; one that HAS a live certificate becomes a manual entry instead, so nothing with a running expiry disappears without the operator deciding. That is a change of mind from the previous commit, which said config rows are never removed — this case showed the cost of that rule where the row should never have existed. 2043 tests pass. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-31 01:01:47 +02:00
nexxo	cfaea7dc82	Fill the hostname page from the installation, not from a blank form ... The page was empty, and that was a design fault rather than a missing button. I built a register that starts blank — while the installation already serves half a dozen names whose certificates were exactly what the operator wanted to see. An overview you have to populate first does not answer "what do I have". So the names are derived now, from the same configuration routes/web.php builds its domain bindings from: SITE_HOSTS, APP_HOST, FILES_HOST, ADMIN_HOSTS. If a name is in the environment, the application answers on it, and then it belongs in this list without anybody typing it a second time. Opening the page syncs them; the list is never empty again. Syncing and measuring are deliberately separate. The sync costs nothing and runs on page load. The measurement goes out over the network and runs on the button or on a schedule — doing it on page load would mean waiting through half a dozen TLS handshakes, and one of them is always the name that currently does not resolve. Which is the other half of what was missing: there was no overview because nothing measured unless somebody pressed a button. A daily run at 04:17 fills it, because the question that matters is not "is it valid right now" but "is renewal running" — a certificate expiring in forty days is fine, the same one at twenty means something has been broken for a week. Only a measurement taken while nobody is looking can tell those apart. The page now opens with four counts — total, valid, expiring soon, without a certificate — and says when it last measured. A name that comes from the environment is marked as such and cannot be removed here: it would come back at the next sync, and a button that does nothing is worse than no button, because it gets believed once. 2040 tests pass, assets build. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-31 00:53:12 +02:00
nexxo	006ce3568b	Manage hostnames and watch their certificates from the console ... files.clupilot.com is why this exists. DNS pointed at the right machine, the env var was set, the release was deployed — and there was still no certificate, because /etc/caddy/Caddyfile is maintained by hand and nobody thought of it as a second, separate step. Nothing in the console would have said so. Three settings looked correct and the address did not answer. So the page holds two things side by side. The WISH — which names should be served — and the REALITY: whether the name has a certificate and for how much longer. The second is measured by opening a TLS connection and reading the expiry, not by reading configuration, because the configuration is exactly what looked right while the address was dead. verify_peer stays on: a certificate that fails validation is not a certificate for this question, and a display that called it valid would be the fake R19 records. Applying goes through the existing agent, not a new channel. The console writes a request, the path unit wakes the agent within a second, and the agent calls one fixed command line of the root-owned helper. What that helper is allowed to do is the careful part. It fetches the list ITSELF rather than being handed one, and the list is HOSTNAMES, never Caddy blocks — `php artisan clupilot:proxy-hosts` prints `<name> <purpose>` and nothing else. Each name is matched against a strict pattern before it is used, and the template around it lives in the helper, which the service account cannot touch. install-agent.sh already states the principle for the sudoers grant: a grant is only worth anything if the holder cannot change what it grants. A service account that could write proxy configuration would have everything the proxy can do — redirects anywhere, files from any directory. Purpose is a column rather than a habit. A console name gets the network lock, a public one does not, and a console name published without it looks exactly like a working page. Removing takes the name out of the list and NOT out of the running proxy. Two decisions in one click, and the second one takes a site off the air. There is deliberately no "renew" button. Caddy renews on its own at two thirds of the lifetime; what an operator actually needs is a second attempt after an issuance has failed, and that is a reload — which is what Apply does. Thirty days is treated as a problem rather than a warning: at ninety days' lifetime, a renewal should long since have run, so anything under it is not a tight certificate but a renewal that is not happening. The ACME contact falls back to the owner's address, because a contact nobody reads is the step before expired customer certificates. CONTRACT and HOST_STEP_NEEDS both move to 2, which is what tells a server carrying the older helper to run the installer again — caught by the guard test that compares the two halves. 2035 tests pass, assets build. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-30 22:55:55 +02:00
nexxo	398028a57d	Rebuild Add host as a page with one job, and let downloads through the gate ... The page was a wall. Six paragraphs of procedure stacked above a form, so the thing the page actually asks for — four fields — sat underneath an essay about what would happen afterwards. It answered everything and showed nothing. It is now built the way the settings page is built, because that page was rebuilt for the same reason and there is no case for a second idiom: an eyebrow, a title, a sticky rail on the left and panels of rows on the right. The rail carries the six steps as two-word labels rather than paragraphs. That is what the question at this moment actually is — where am I, how much is left — and it fits in 232 pixels. The numbers carry the state; a tick beside them would be a second sign for one statement, and a number can be counted. What a step MEANS now appears in the row where it is due, not six times in advance. The two provider steps get a panel of their own above the form, because they have to be done before you save: the one-time code starts expiring the moment you do. Everything after the form waits until there is something to say. After saving the command becomes the page. Full width, its own framed block with the warning in the header strip rather than floating above, and the two remaining steps below it as ordinary rows. Two token bugs went with it. `bg-canvas` does not exist — it was a class that compiled to nothing, which is part of why the block looked wrong. And `text-accent` on white is 2.9:1; the config says in as many words to use accent-text for anything read, so the current step number does. Also fixed, and it would have broken every takeover in production: PublicSiteGate is appended to the whole web group, so while the site is hidden a server in a rescue system fetching the archive would have received the 503 placeholder and piped it into tar. The operator would have seen an unpack error on a machine only reachable through the provider's console, with nothing pointing at a switch in the admin area — and they are by definition neither on a management network nor signed in, since leaving that state is the whole point. Exempted by ROUTE NAME, not by hostname: the docblock rightly warns that exempting by host means trusting a header the caller picks, but that warning is about the entire portal. Behind these two routes are documents that are public anyway and an archive that 404s without a valid one-time code. 2026 tests pass, assets build. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-30 21:51:30 +02:00
nexxo	156de12c8c	Give the downloads a hostname of their own, with two halves ... A domain that exists only to serve one installer is not worth a certificate. One that also carries the AGB, the AV and the TOM is — those addresses go into contracts and onto invoices and have to still resolve in three years, which an address that moves with the next rebuild of the portal cannot promise. That reason is what changed the answer. files.… over cdn./storage./archiv.: a CDN is an edge network and this is not one, so the name would be a lie the day a real CDN goes in front of it. "storage" reads like object storage or customer data, and a customer seeing it will wonder whether their files live there. "archiv" says superseded, which the terms currently in force are not — and R13 keeps paths and names English anyway. Two halves on that host, with opposite rules, and that is the whole point of giving it its own name: Public — storage/app/files/public/, served to anyone, indexable, because somebody looking for the terms should find them. Versioned filenames: agb-2026-01.pdf, never agb.pdf, so a contract signed in January cannot come to point at conditions written in July. The rule is written where somebody will look for it rather than enforced, because a upload that rejects a filename helps nobody. Private — the installer, and it is not a file in that directory at all: it is built from deploy/bootstrap on demand. The gate is the one-time enrolment code that is ALREADY in the pasted line, resolved without being consumed, because the code is still needed for every progress report and for the registration at the end. No second secret: a dedicated download token would never expire, would sit in shell histories forever, and would travel in the same line as the WireGuard private key — protecting the least sensitive thing with the exposure of the most sensitive one. 404 rather than 403 on a bad code, and noindex on the response. Path traversal is answered before it starts: basename() only, no directory tree under public/ by design, and dotfiles refused. The test walks ../../.env three different ways. Empty FILES_HOST keeps the archive on the portal host exactly as before, so nothing breaks in the window between setting the variable and the DNS record existing. The hostname had to move into phpunit.xml rather than a config()->set(): routes are bound at boot, so a test that sets it afterwards is setting it too late. 2025 tests pass. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-30 21:37:47 +02:00
nexxo	ba4996f316	Keep the platform on .com and the customers on .cloud ... The owner caught me putting the archive on clupilot.cloud. That is the customer zone, and looking into it turned up the same confusion already sitting in the code — in the one place that matters most. RegisterHostDns says "fsn-01.node.clupilot.com" in its own docblock. The validation comment in Datacenters says it. ServicesTest writes it out verbatim. The step itself built the name from config('provisioning.dns.zone') — the CUSTOMER zone — so on this installation a host was actually called fsn-01.node.clupilot.cloud. Three places asserting one thing and the code doing another. OfficialDomains explains why that matters and is worth not weakening: two registrable domains by design, the company's for site, portal and console, the instance zone for customer workloads. A Nextcloud is third-party software that strangers sign into, and on the same registrable domain as the portal it shares cookie scope with it. A host name in that zone does not break the separation, but it puts it in question, and the next slip is more expensive. So there is now a platform_zone, derived from APP_URL when unset, and RegisterHostDns uses it. My own archiveUrl was broken for a second reason. It fell back to url() when APP_HOST is empty — and APP_HOST is empty on most installations, because empty means "the portal answers on any hostname" and that is the default. Called from the console, url() would have produced the CONSOLE hostname, and the line would have 404'd on a machine that is not allowed to reach the admin area at all. It takes the host from APP_URL now. The script no longer guesses its own name. It used reverse DNS, then the tunnel address, then a hard-coded clupilot.net — a third domain that appears nowhere else in this project and was simply invented. PrepareBaseSystem has the same invention. A guessed name does not stay guessed: it ends up in /etc/hostname, in /etc/hosts, in every log line and in every certificate request the machine ever makes. CluPilot knows the name because it just assigned it, so it passes --fqdn and the script refuses without it. The value now also survives the reboot in the arguments file, which it would not have. The ACME contact moved to .com for the same reason it was wrong: the operator does not live in the customer zone. Open, and NOT decided here: the owner also wants the host to get a public DNS record and a certificate on the .com name. RegisterHostDns deliberately writes host names only into the tunnel's dnsmasq, and says why — publishing them hands every scanner the internal subnet and roughly how many hosts sit behind it. Nothing in the current design needs a public certificate for a host's own name; Traefik serves customer domains, not this one. Reversing that is a security decision and belongs to the owner, not to this commit. 1992 tests pass. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-30 21:04:08 +02:00
nexxo	2194ab8079	Put the instructions where somebody reads them before they start ... The previous commit shipped the guide AFTER the host was created. Its first two steps happen at the provider — order the machine, boot the rescue system — and whoever reads them there has the one-time code already in the clipboard with its 24-hour window running. The instructions were correct and in the wrong place, which is its own kind of wrong. Six steps now, not three, and the two provider ones are named rather than assumed. They are marked "first" so the list does not read as something you can start at the top of and work down: step 2 is half an hour of waiting, and doing it inside a running code is exactly the mistake the page should prevent. All six are visible the whole time, including the done ones and the ones still to come. A guide that shows only the current step cannot answer "how much is left", which is the question somebody has while a server they are paying for sits in a rescue system. It is on the hosts list too, collapsed. Somebody standing there may not have ordered the machine yet — and that is step 1. Requiring them to click "add host" to find out what the procedure is puts the answer behind the action it describes. One component, two places, so the archive address in the instructions is the same string the command line will carry. Two copies of that would drift, and the difference would surface on a server that has already been paid for. The step-4 command box moved into the guide rather than sitting beside it, so after creating a host the whole procedure stays on screen. Somebody stuck at step 5 should not be looking at a page that has become a single box. 1991 tests pass. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-30 20:51:47 +02:00
nexxo	903ebdd2b2	Give the operator one line to copy and three steps around it ... The console could describe a takeover it had no way to start. This is the vertical slice that closes that: a one-time code, the archive the rescue system fetches, and the page that says what to do with both. The command carries EVERYTHING the script needs before the tunnel exists, because there is nothing to fetch — that is the whole point of spec §5. Which means CluPilot generates the WireGuard keypair and admits the peer at the hub before the machine has ever booted, and hands the private half over in the line. It is worthless within minutes: task 9 of the script replaces it with one generated on the machine. Shown exactly once. The database holds only the code's hash and never the private key, so leaving the page does not bring it back — it mints a new code, which invalidates the old one. That is deliberate: a glance at somebody's screen should be worth nothing an hour later. Which is also why save() no longer redirects. Sending the operator to the host detail page sends them away from the only value they need, and an existing test asserted that redirect — it now asserts the opposite, with the reason written next to it. SHA-256 rather than bcrypt for the code, and the reason is not speed. Both endpoints have to FIND the host by the code; with bcrypt that means trying every row. The code is 32 characters of CSPRNG output, so it has the entropy that stretching exists to manufacture. resolve() and claim() are separate because progress reports arrive BEFORE registration. If reporting consumed the code, a host could never register after its first message. The archive URL is always the public hostname. The console runs under admin.…, but this line executes on a machine that must not reach the admin area — it is locked down for exactly that reason — so route() from the console would emit a hostname that 404s on a server only reachable through the provider's console. The page warns about missing tunnel settings BEFORE the host is created, not after. An empty hub key produces a line that looks clean, copies fine, runs, and ends in a tunnel that never handshakes — discovered on the machine, after somebody has already paid for it. The three steps lead with the rescue system, because that is the one nobody knows by heart, and it says enabling is not the same as booting into it — the script refuses a running production machine, which is what a half-done switch looks like from the inside. 1986 tests pass. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-30 20:40:19 +02:00
nexxo	880b5f1998	Merge main into the operating-mode branch ... Three real conflicts, and one file that did not conflict and mattered more. Overview::notices(): both sides added notices. Kept all of them, and pointed main's mail check at MailboxTransport::NON_DELIVERING — its own comment already named the constant while the code carried a copy of the list. billing.blade.php: main wrapped the page in a contract branch. The "payment is not set up" error moved OUTSIDE it, because the customer most likely to meet that message is the one buying for the first time, who has no contract yet and would never have seen it from inside the @else. ConsoleReportsRealDataTest: kept both sides rather than choosing. The renamed test and its docblock explain why admin.systems_ok can no longer be asserted on a bare install; main's mail pin still keeps "clean" clean in the mail dimension. Picking one would have quietly weakened the other's claim. HostStepsTest: git combined main's config()->set('provisioning.dns.zone', 'clupilot.com') with this branch's assertion on clupilot.cloud, and produced a test that contradicted itself with no marker. Main's approach is the better one — it pins the zone in the test and asserts the SHAPE of the name rather than this box's domain — so its assertion stands. HttpStripeClient merged silently and correctly: secret() still throws, isConfigured() still reads the vault directly. Had it taken main's filled($this->secret()), six callers that ask in order NOT to get an exception would have become exception throwers, and the suite would have stayed green. CheckoutWithoutStripeKeyTest is the lock that would have caught it. StripeIdempotencyKeyTest (new on main) leaned on the environment fallback for stripe.secret. That entry is strict now — no fallback in either direction, so the .env cannot be a back door for a live key in test mode. It stores a real vault row instead. 1966 tests pass. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-30 17:53:20 +02:00
nexxo	955f1b874f	Deliver the processing agreement, and hold the proof it was accepted ... Art. 28(3) GDPR wants a contract wherever personal data is processed on somebody else's behalf, which is the whole of what this product does. "In writing" there includes electronic form (Art. 28(9)), so a document the customer can read plus a recorded acceptance is enough — no signature on paper. The website already promises "AV-Vertrag inklusive", which means it has to be obtainable without asking us for it. It was not obtainable at all. **The text is never this application's.** An operator uploads the document their lawyer wrote, names the version, and publishes it; the measures ride along as a second file, because they are an annex to the agreement and "which measures applied when this customer accepted" has to have one answer. Inventing the text here would have been worse than having none. **Uploading and publishing are two acts.** Acceptance is per version, so publishing leaves every customer who accepted the previous one outstanding again — correct, and far too expensive to trigger by dropping a file on a form. It goes through a confirmation modal that says exactly that (R23). **The customer's side** is a card in the contract tab: read the agreement, read the measures, one press to conclude it. What that press records is what makes it evidence rather than a flag — the version, the moment, the address it came from, and the login that pressed. Pressing twice is one agreement (unique index, not a check somebody can forget), and a superseded acceptance is kept rather than overwritten: it was true when it was made, and the history is the point. Nothing renders until a version is in force. A card offering an agreement that does not exist is worse than the silence. The files live on the private disk and are served through routes that check who is asking — an agreement is not a public asset, and a guessable URL to one would be a list of who our customers are. The customer route takes no version parameter: which document applies is ours to say. `dpa.manage` is its own capability on the OPERATOR guard. Whoever keeps the platform running does not thereby decide what every customer is asked to agree to — and a capability written under `web` since the 2026-07-29 move lands in a guard nothing authenticates against, which is how this one first shipped answering 403 to a role that visibly had it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-30 16:56:57 +02:00
nexxo	1056dddc62	Take the address by field, fix the customer type, ask why they leave ... **The billing address was one textarea**, so what landed in it was whatever somebody typed: a postcode on the street line, a city with no postcode, no country at all. It is four fields now — street, postcode, town, country — in the customer's settings and in the console's customer editor, which had its own free-text copy of the same field and would have had an operator's correction silently reverted the next time the customer saved. `customers.billing_address` is neither dropped nor parsed: guessing which line of an existing block is the street would put a postcode where a street belongs on a document nobody can correct afterwards. It becomes the COMPOSED form, rewritten from the fields on every save, so IssueInvoice and everything else that reads it keep working, and a record nobody has re-saved keeps the block it always had. **The customer type is fixed once it is on record.** It decides the fourteen-day right of withdrawal, and a business able to set itself to "Privatperson" on this page is a business able to withdraw from a contract it may not withdraw from. Registration asks the question; this page reports the answer, and saveProfile refuses to answer it a second time — in the component, not by hiding a radio, because a form that hides a control has never stopped anybody who can post to /livewire/update. A record created before the question existed may still be given one, once. The panel is a fact rather than a form now, which is also what was odd about it, and the sentence about who has the right of withdrawal is gone. **Cancelling asks why.** A reason from a fixed list, required, with a note beside it that "Sonstiges" cannot go without — the one fact worth having about a departure, asked at the only moment the customer is looking at the question. It lands on the contract (`cancel_reason`, `cancel_reason_note`). And where the fourteen days are still running, the dialogue offers the WITHDRAWAL as a way out of itself rather than as one more reason inside it: withdrawing ends the service the same day and sends the whole amount back, cancelling keeps the term that was paid for, and somebody entitled to the first should not lose it by taking the second unasked. A business is never offered it — WithdrawalRight answers that, not the template. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-30 16:41:32 +02:00
nexxo	e83b17ec37	Put every missing field on one page before a customer pays ... Admin\Readiness renders App\Support\Readiness::byGroup() end to end: state, label, breaks sentence and a fix link for every check, a button on the four that have to ask a real service (DnsTokenCheck, WireguardEndpointCheck, VmTemplateCheck, StripeCheck) and only ever run on demand, and one headline line — ready for the operator's current mode, or how many blocking items are still open. Wired into the nav and into Overview's own notice list beside the same gate as Admin\Integrations, since both halves it configures come back together on this page. Fixed two check keys the guard test caught for real: onboarding.ssh_key and delivery.inbound_password did not textually contain the vault key they check (ssh.private_key, inbound_mail.password), which is exactly the kind of silent gap this whole task exists to catch. Renamed to onboarding.ssh_private_key and delivery.inbound_mail_password, with the two existing test files that referenced the old keys updated to match. Also fixed the guard test's own assertion: Pest's toContain() is variadic, so a second string argument is a second required substring, not a failure message (the same trap tests/Feature/ModalHeightTest.php already documents about itself) — it failed on every entry, including ones already covered. Replaced with str_contains()+toBeTrue(), which keeps the check and the message both. Two pre-existing Overview tests assumed a bare install has nothing to report; it now correctly always starts with a readiness gap, so both were narrowed to what they actually test — no invented data, no invented incident. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-30 15:59:34 +02:00
nexxo	b32c6fc33f	Sell the year as well as the month, and say what it saves ... Both prices have existed since the catalogue did — one `plan_prices` row per term, each with its own Stripe Price, and the checkout has taken a `term` all along. Nothing ever sent one. The shop showed the monthly figure, the order page posted no term, and the yearly Price sat there being paid for by nobody. **The console asks for free months, not a second price.** It used to take the yearly TOTAL as its own free-form figure, so nothing in the system knew WHY 588 belonged to a package costing 49 a month — and no page could say "zwei Monate gratis" without a person working it out again and writing it somewhere it would then drift. Now: the monthly price and how many of the twelve months are free. The total is derived from the two (PlanVersions::yearlyCents), previewed live on the form, and written to the catalogue from the same arithmetic. `free_months` sits on the VERSION, beside the capabilities publication freezes, because that is what it is — part of the terms a customer bought. The migration reads it back out of the prices that already exist rather than defaulting to nought: an installation selling twelve-for-ten must not lose that on a deploy. Only an exact division counts; a hand-negotiated yearly figure keeps its amount and simply goes unexplained. **The customer chooses.** A switch on the order page and on the public sheet, both figures rendered and one shown, so switching costs no request. The headline stays "per month" in either term — a yearly total as one big number reads as five times dearer at a glance — with the amount actually taken, the net figure, the months free and what twelve monthly payments would have cost underneath. The form posts the term the customer was looking at, and the checkout picks that term's Stripe Price. The billing card now says which term is running. It states a monthly figure whatever the term, so a yearly customer was reading a number that never appears on a statement. Also: **a Blade comment must never spell a directive.** Blade compiles what is inside `{{-- --}}` too — the comment is stripped from the output, but its directives are compiled on the way there. A comment explaining why the parenthesised php directive had been avoided produced exactly the open PHP tag it warned about, and the rest of the file was swallowed as PHP source: no exception, no warning, the page one block short. That is how the term switch vanished after being written. BladeCommentsTest scans for the forms that open a tag. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-30 15:44:35 +02:00
nexxo	fed4acf31c	Accept terms instead of a start date, and fix the sender no server accepts ... **The test mail was rejected: "553 5.7.1 Sender address rejected: not owned by user no-reply@…".** Every purpose mailbox here has its own SMTP account, and a mail server lets an account send only from the address it owns. Mail::to() hands back a pending mail bound to the DEFAULT mailer and sendNow() then ignores the mailer the mailable asked for, so a mail addressed support@ went out over the no-reply@ login. It sends through the mailable's own mailer now, and the cloud-ready preview — the one mailable with no mailbox at all — takes the provisioning mailbox like the real notification does. Writing the test for that found the same bug in production code: **InvoiceMail and OrderConfirmationMail set their From to billing@ and never named a mailer**, so both went out over mail.default's no-reply@ login. On this installation no customer had ever received an invoice mail or an order confirmation; they rendered perfectly, queued without complaint and were refused at the door. MailSenderOwnershipTest now scans for the mismatch: a mail that takes a mailbox From must use that mailbox's mailer. **The box on the order page accepts the terms now**, not an immediate start. It used to carry the whole FAGG §16 sentence, which read like a choice between "now" and "in fourteen days" — and there is no second option. The terms are what regulate the sale, so they had to exist: resources/views/legal/terms.blade.php replaces the placeholder with fourteen sections written from what this software actually does — the delivery, the capacity queue, the full refund on withdrawal, the cancellation at period end, the deletion deadlines. The company data comes from CompanyProfile, so the page and the invoices cannot drift. No availability figure and no liability cap has been invented. No order goes through without it: the button is unusable until the box is ticked and says why, and CheckoutController still refuses server-side — the browser half refuses nothing. The request field is `terms_accepted`; the Stripe metadata key stays `immediate_start`, because a session opened before a deploy is paid after it and the webhook would find nothing under a new name. **"Wird der Account nach fünf Tagen gelöscht?"** Only an unconfirmed one. That was the whole of what we said, so the answer looked like yes. The second rule now exists and is stated: PruneDormantAccounts removes a confirmed account after a year when it never had a package — no customer record at all, which is where every order, contract and seven-year invoice hangs. A fortnight's notice goes out first, once, and `dormant_warned_at` is what permits the deletion: an account whose warning never went out is never removed. Signing in resets the clock, measured off the device rows because users has no last_login_at. Both deadlines are said in the portal settings, on the verification page, and in the terms — each reading the number off the command that enforces it. Also: the wordmark scan matched any element whose text merely BEGINS with the company name, which a paragraph of terms does. It looks for the lockup form now (no whitespace after the tag), which is what it was always about. The seven checkout tests in the parallel session's files were posting the old field name and now post the new one. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-30 15:22:35 +02:00
nexxo	c354ad1463	Make mails readable on a phone, and let an operator look at one ... Three things the owner reported, and one sentence that promised something this product does not do. **The mails had a fixed width.** components/mail/layout.blade.php set width="600" and width:600px, so every phone showed a 600px canvas in a 390px window and one had to scroll sideways to read a sentence. Now the table is width="100%" with max-width:600px — fluid, with 600 as a ceiling rather than a floor. A mail cannot fix this with a media query (Outlook renders with Word and drops <style> blocks), which is why the whole file is inline attributes and why the shrinking has to be built in. Side padding went 40px -> 24px in the layout and in all nine mail views: 40 each side leaves 278px of a 390px screen to read in. **There was no way to look at a mail.** An invoice mail needs an invoice, a maintenance announcement needs a window, and "register an account to see whether the confirmation reads well" is not a workflow — which is how the fixed width survived for months. App\Services\Mail\MailPreviews builds all nine from sample data, every record with make() and never create(), so a preview leaves no invoice, order or window behind and draws no number from a series. Two ways to see one: in a tab as the document itself, or sent to the signed-in operator's own address. There is no recipient field — that would be a form for mailing strangers. sendNow(), not send(): every mailable here implements ShouldQueue, and send() defers to the queue for those, which would have put a failure in a worker's log while the button reported success to somebody waiting for the mail. The test caught that. **The booking page had no shell.** Order declared layouts.portal — the bare shell the sign-in pages use, no navigation and no padding — so the page sat flush against the top and bottom of the window with no way back to anything. layouts.portal-app, like every other portal page. **The consent box said something untrue.** Its refusal read "otherwise we can only build your cloud once the withdrawal period has ended", which describes a path that does not exist: nothing here delivers fourteen days later, and an unticked box simply means no order. Said plainly now, and said on the page before somebody runs into the refusal. Also: GrantedPlanPortalTest asserted assertDontSee('179'), which matches any id containing those digits — and ids climb through a suite run because a rolled-back transaction does not reset an auto-increment counter. It passed alone and failed in company. Asserts on '179,00' now, which is what a leaked price would actually look like. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-30 14:50:37 +02:00
nexxo	3e7026407b	Stop inventing a package, and rebuild the booking page ... Two pages said opposite things about one account, straight after registering: the dashboard said "noch keine Instanz", and Paket & Addons said "AKTUELLES PAKET Start — Status Aktiv". The dashboard was right. The package page fell back to `$instance?->plan ?? 'start'` and rendered that fallback as a contract the customer had entered into, complete with a status of Aktiv, on the one page somebody opens to find out what they pay. The contract is resolved from the CUSTOMER now, not from the instance — a paid order parked for want of a machine has a subscription and no instance yet, and asking the instance would tell somebody who has paid that they have no package. An instance counts as well, whatever its subscription row says. With neither, the page says so and points at the booking page: an "Upgrade" from nothing is a purchase, and that has its own page. The cart stays outside that gate. A customer can have something in it before they have any contract at all, and hiding it there would hide the thing they came to pay for — which is what my first version did, and seven existing tests said so. And the booking page. Five cards in a four-column grid left the fifth alone on its own row, reading as a mistake; the consent box sat at the BOTTOM with every buy button disabled until it was ticked, so the page arrived looking broken before anybody had done anything wrong; and the price ran across the card in one block with nothing to compare. Now the consent comes first, because it is the condition for everything under it, and it colours itself green once given. Three columns, so five plans read as 3 + 2. Each card is the same four rows in the same order — price, delivery, what you get, the button — so the eye can run across a row and compare like with like. The button stays ENABLED with the reason it will not go through said under it: a disabled control explains nothing, and the server is the gate either way. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-30 14:29:22 +02:00
nexxo	f49f1dca09	Say when no mail is being delivered at all ... "Ich versuche mich zu registrieren, erhalte aber keine Verify-Mail, auch nicht beim erneuten Senden." Traced rather than guessed, and the evidence is in storage/logs: the address appears three times, so the mails were built and handed to a transport that writes them to a file. MAIL_MAILER=log. MailboxTransport::resolution() short-circuits on it — NON_DELIVERING is ['log', 'array', null] — so every purpose mailer becomes the log transport however well the five mailboxes are configured, which is correct for a development machine and exactly what was happening here. The reason it deserves a notice is that the failure is silent in every direction an operator would look. Mail::queue() succeeds. No job fails. The queue empties. And the console's own mailbox test reports SUCCESS, because MailboxTester builds its own transport on purpose — a check that honoured MAIL_MAILER=log would report success while writing to a file. So every instrument on the page said fine. Now the front page says it, linked to the mail page, and the mail page says it above the mailboxes it makes decorative. All three swallowing values are named, not only 'log': array and an unset default do the same thing, and a notice that only knew about one would be silent in the two cases nobody thinks to check. Two existing tests asserted that a clean installation raises no notice, and went red — correctly, because phpunit.xml forces MAIL_MAILER=array so a suite cannot send mail. They pin a delivering mailer now: the warning is about the environment, those tests are about the estate. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-30 13:55:55 +02:00
nexxo	70fa136e22	Say on the front page that the site is switched off ... "Ich komme auf dem lokalen Dev-Server nicht auf www.dev." Diagnosed rather than guessed: Laravel answers 200 on that host, and the request never reaches it — site.public is false, so PublicSiteGate returns the placeholder with a 503 to every visitor who is not on the management VPN and not signed in as an operator. Which is precisely what a broken deployment looks like from outside, and the only place that said so was the switch itself, on another page. So the console says it now, on the page an operator opens when something looks wrong, and the notice links to the switch. The second half of the same report — being sent to app.… — is the missing SITE_HOST. Without it the marketing site is registered without a hostname: it answers on the PORTAL's host as well, and every route() it generates points at APP_URL, so a link on the site lands on the portal's domain. Also said, also with the host named. Only where the installation is host-separated at all, though. A fresh checkout binds nothing to a hostname by design — RestrictAdminHost: "upgrading must not lock anyone out of a system that was working" — and a warning there is furniture. My first version fired on every clean installation and two existing tests said so immediately; they were right. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-30 13:36:42 +02:00
nexxo	f9993a1f48	Name the server variable under a credential, not the internal key ... Under each credential stood `stripe.secret`, `dns.token`, `inbound_mail.password`, `monitoring.token` — identifiers out of SecretVault::REGISTRY. They mean nothing on a settings page and there is nowhere an operator could type them; asked about directly, and the answer is no, that was not deliberate. The env variable name is the useful one: it is what stands in the server file, it is what the .env tab of this same page lists, and when the badge beside it says "Aus der Serverdatei" it answers the obvious next question — which line? The registry key stays where it belongs: in wire:key and in the modal arguments, as an identifier nobody reads. The test asserts on the text node rather than on the key's absence from the HTML, because absence would have demanded breaking the page to pass. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-30 13:20:29 +02:00
nexxo	a84251260c	Read the mailbox password where it actually is, and let the console test it ... The inbox kept saying no mailbox was set up while the password sat right there on the settings page. isConfigured() read config('services.inbound_mail.password'), which is only ever the .env value: this project deliberately does not overlay stored secrets onto config at boot — SecretVault's own docblock says so, and HttpMonitoringClient reads its token at the point of use for exactly that reason. My docblock even asserted the opposite mechanism, which I never verified. It reads the vault now, and falls back to .env because SecretVault::get() already does. And a way to find out. "Verbindung prüfen" saves the form first — testing what is on screen while the server still holds the previous values would report on a mailbox nobody configured — then performs the same four verbs the real fetch performs: LOGIN, SELECT, SEARCH UNSEEN. A check that proves something easier than the actual job is worse than none. What it reports back is one of five fixed words, never the server's own prose: an IMAP error carries the command it failed on, and for LOGIN that command contains the password. Each word maps to a sentence an operator can act on — address and port, mailbox and password, the folder. The line saying when the mailbox was last reached is on both pages, and it is written by the SCHEDULED run as well as by the button. Otherwise "last checked" would mean "last time somebody pressed a button", which is the less interesting of the two: a mailbox that stopped answering at three in the morning is the one worth seeing, and nobody presses a button at three in the morning. It is also shown when the answer is "never" — an empty inbox and a mailbox that stopped answering look identical, and this line is the whole difference. A fetch against a mailbox that just refused the login now takes nothing in and records the refusal, rather than reporting "nothing new" — which was true and useless. Also: HostStepsTest asserted the literal clupilot.com for a host name. That was true until CLUPILOT_DNS_ZONE was set to clupilot.cloud on this installation, and then a correct configuration failed a test. The zone is pinned in the test now; what it is about is the shape of the name and which address it carries. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-30 13:12:29 +02:00
nexxo	727f2e41db	Make source() respect strict entries like get() does ... Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-30 11:21:07 +02:00
nexxo	bc6eee4dc3	Give every credential a test slot beside its live one ... Each entry in the vault now stores under key:mode instead of a bare key, and get() resolves the active mode internally — falling back from an empty test slot to live (never the reverse) so test operation works before anyone has filled in test credentials, but live operation never silently reaches for a test one. get()'s signature is unchanged on purpose: its three callers (HttpStripeClient, StripeCheck, SshTraefikWriter) have no business knowing which mode is active. put()/forget()/source()/outline()/ updatedAt() take an optional trailing $mode for the console, which will use it in a later task. SecretVaultTest's raw app_secrets queries assumed the old bare key and needed the :live suffix plus a pinned OperatingMode — otherwise they'd depend on whatever mode an earlier test file left in the array cache. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-30 10:53:17 +02:00
nexxo	889b401faf	Fix nine defects in the provisioning pipelines ... The capacity park could not survive its own first poll. ReserveResources polls every 120 s and declared a maxDuration of 60, and RunRunner measures a step's budget from a started_at it deliberately does not reset on a poll — so every re-entry was ruled timed out before the body ran, a timeout consumes an attempt, and five of them failed a paid order in about six minutes. The fourteen-day promise, the console's capacity queue and the "go and buy a server" workflow were unreachable code. maxDuration is now the whole park plus one poll interval, and a test drives a park through the runner rather than calling execute() directly, which is why this was invisible. Every guest occ call ran as root. `docker compose exec` defaults to root and the Nextcloud image's console.php exits 1 unless the caller owns config/config.php, so all five call sites were failing on every instance. There is now one builder, App\Support\NextcloudOcc, and a test refuses a second: nothing in app/ may spell the invocation out by hand. deploy/ update.sh had learned this for our own container and nobody carried it across. RunAcceptanceChecks was terminal on the first no. certReachable() answers false for a connect timeout as readily as for a missing certificate, so one bad second ended a finished, certified Nextcloud as a failed order with the instance released. The probes retry now and the run still fails for good with the probe's own reason once the budget is spent; the two facts a retry cannot change stay terminal. The in-flight guard asked whether anything was running, not whether it would do the work. App\Provisioning\WorkInFlight asks the second question, reading the step lists the runner executes: a domain proven during a restart is routed, and a storage pack booked during an address run is delivered instead of charged monthly and forgotten. The address pipeline ran its steps in the wrong order for the direction it exists for. Nextcloud before the router in `address` and `plan-change`, as in `customer`, because a run that got the certificate and then failed left the customer's own domain serving an untrusted-domain error under a valid certificate while the portal called it live. Safe in both directions; the reasoning is written above the pipeline. A stale guest_ip could never be corrected. ConfigureDnsAndTls compared the hostnames but never the backend, and nothing re-read the address after the build. It now records and compares `routed_backend`, and ConfigureNetwork joins the `restart` pipeline — a cold boot is what moves a DHCP lease — and asks for the address to be re-applied when the guest has actually moved. Also: HetznerDnsClient::upsertRecord read only the first page of a zone that pages at 100, so past a hundred records it created a second A record for the same name and the cloud was up about half the time; the console's retry left a live customer's order in `provisioning` for ever for any maintenance pipeline; and a revived run's first pass burned an attempt on a timeout that had already happened, because the clause written for it used `??=`. Seven test sites wrote config('provisioning.plans.*'), a key that has not existed since the catalogue moved into the database. Every write was a no-op, so each test proved something other than its name: the missing template, the two snapshot regressions and the grandfathered-price scenario are now actually constructed, ValidateOrder's reasons are asserted rather than only its type, and the end-to-end run checks that the quota step delivered something. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-30 01:34:55 +02:00
nexxo	518bc9aa41	Put the open tab in the address bar, including the first one ... Reported as "die Tabs fehlen in der Query beim Kunden". The binding was there and identical to the settings page — checked in the rendered snapshot, which is where Livewire's JS reads it from — but `except` hid the parameter while the DEFAULT tab was open. So arriving on a customer showed no ?tab= at all, and a link to the page could not say which tab it meant unless the tab happened not to be the first one. From the address bar that is indistinguishable from the feature not existing. No `except` now, on all three tabbed pages: the parameter is there from the first render. And `history: true`, so each tab is a step the back button can take rather than a silent replaceState — which also makes the change unmistakable while clicking. Asserted against the rendered page rather than the component, because the parameter is written client-side from the `url` memo in the snapshot: the memo IS the behaviour, and asserting the property would have passed throughout the bug. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-29 23:46:13 +02:00
nexxo	f00cbf18d3	Let an operator correct a customer's details ... The console could show them and not touch them, so a moved office or a new contact person meant impersonating the customer or editing the database by hand. Both are worse than a form. R20: a modal, opened from the Stammdaten tab, authorising again and reading the record itself rather than trusting anything the browser hydrated. Most of the work is in what saving must NOT quietly do. The customer type is never reset to "nobody asked". The field opens on "leave unchanged" precisely so that saving an address correction cannot undo it — that answer decides whether a withdrawal right exists, and losing it silently would be the expensive kind of quiet. A changed VAT number is unverified from the moment it is stored — the verification is bound to the value, so that happens by itself — but `vat_id_verified_value` is left alone: it is the record of what WAS checked, and clearing it would destroy the evidence rather than the claim. The address is also the sign-in address and the key inbound mail is matched by, so changing it moves the linked portal login in the same transaction and puts it back to unverified, which is what Laravel's own profile update does for the same reason: nobody has shown they can read the new address. No mail is sent from here — the portal asks for the confirmation at the next sign-in, and a mail an operator did not knowingly send is a surprise. Three addresses are refused: one belonging to an operator (R21 — no index spans the two tables, so it is checked), one belonging to another customer, and one belonging to somebody else's user row, which can outlive or predate a matching customer. Not offered here, each for its own reason: `status`, because suspending has consequences for access and a lifecycle switch hidden among address fields is one somebody flips by accident; `stripe_customer_id`, because a wrong one does not move a contract, it points our records at somebody else's payments; the brand fields, because the customer sets those for themselves and an operator overwriting a logo is not a correction. There is a test that fails if any of them appears — with the comments stripped first, since the class documents at length why they are absent and that documentation is not the offence. This repository has fallen into that trap three times. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-29 23:18:46 +02:00
nexxo	57c6912987	Say that a click landed, and make moving one actually move it ... "Man klickt und sieht nicht was passiert." Every action in this console is a round trip, and a round trip with no sign of itself reads as a click that missed — so the answer is in three places, from the general to the specific. A thin bar at the top of the window for any Livewire request, in app.js. Delayed by 140 ms, because a request that answers faster than that is perceived as immediate and a bar flashing on every keystroke of a .live field is worse than none. It creeps to 70 % and only completes on the answer: a bar that reaches the end while the answer is still on its way is a lie about the thing it exists to report. Released on failure as well — the request somebody must not be left waiting on is precisely the one that went wrong — and on wire:navigate, which is not a request hook at all and would otherwise leave the bar behind on a page that is gone. Per button: a pressed state on the way down, disabled while its own request is out, scoped with wire:target to that button's own call so a row does not grey itself out because a neighbour is moving. The edit button carries its own spinner, because opening the modal is a request made by the MODAL component — wire:loading on this page never sees it. It clears when the package announces the modal is up, and on a six second timer as well, so a request that never answers cannot leave a row spinning for ever. And the reordering was not only slow to look at, it was wrong. It added or subtracted a fixed amount: with the seeded values ten apart that usually landed right, and sometimes landed on a value another template already had — or on the floor along with three others. Equal sort values fall back to the name, so a click could reorder something else, or nothing, which is indistinguishable from a click that never registered. It swaps with the neighbour now: exactly one place, or nothing at the ends, both of which are what an operator expects to see. Where two shared a value the swap leaves them distinct, or the next click would do nothing again. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-29 23:06:30 +02:00