185 Commits (main)

Author	SHA1	Message	Date
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	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	4f037c8264	Mahnwesen: Einstellungen und die zwei Eingriffe von Hand	2026-07-31 22:43:52 +02:00
nexxo	fb1ef3fc63	Rollen: aufklappbare Karten, gruppierte Rechte, Knopf im Raster	2026-07-31 22:39:46 +02:00
nexxo	29c2718235	R20: Begruendung im Modal, und der Waechter sieht jetzt auch Listenzeilen	2026-07-31 22:09:05 +02:00
nexxo	7f7b654fcb	Zahlungsprobleme: geplatzte Kaeufe aufzeichnen, beide Arten an einer Stelle	2026-07-31 21:58:52 +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	b8a774b604	Portal: Karte tauschen, offene Rechnungen begleichen, Hinweis bei Faelligkeit	2026-07-31 21:12:31 +02:00
nexxo	0944de7cfa	Passwortrichtlinie einstellbar, doppelte Anmelde-Mail behoben	2026-07-31 20:53:19 +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	d321719180	Only a real zones array counts as an answer ... Measured on the live server: a token with read AND write, the zone clupilot.cloud present with fifteen records — and the console insisting the account held no zones at all. Both screenshots contradict the message, so the message was wrong, and the previous fix did not go far enough. successful() is not enough. Something in the middle — a portal, a filter, a proxy — answers with 200 and an HTML page. That body has no `zones` key, `?? []` turned it into no zones, and the display concluded the Hetzner account was empty. A 200 is not a promise about who answered. So the body has to answer the question, not merely arrive: `{"zones": [...]}` with an actual array, or it is reported as something else having spoken, with the status and the first 120 characters of what came back. That last part is what turns it from a verdict into a diagnosis — an operator who sees "Blocked by policy" knows in one line what nothing else here could have told them. A genuine `{"zones": []}` still means what it always meant. 2053 tests pass, assets build. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-31 15:42:31 +02:00
nexxo	c81a89ce5a	A failed zone list is not an empty Hetzner account ... The owner asked whether an empty token was being sent. It was not — an empty one returns `missing` — but the question was worth following, and it found a fault in the message I had just added. The check classified 401 and 403 as `rejected` and then read the body. Every OTHER unsuccessful response — 404, 429, 500, a cache's status page — has no `zones` key, `?? []` turned that into no zones, and the console then stated "this account holds no zones at all. The token probably belongs to a different Hetzner project." A claim about somebody's account, derived from an error nobody looked at, delivered with more confidence than the working case gets. `successful()` is asked first now, and an unexpected status is reported as what it is, with the number beside it: it says nothing about the zones, and it says so. That is the distinction this check already draws between `unreachable` and `read_only` — both are failures, only one of them tells you anything about the token. A genuinely empty list still means what it meant: 200 with zero zones is a token for a project without zones. The test uses a dataset rather than a loop. Http::fake() ADDS stubs instead of replacing them, so a loop would have had the first status answer all four iterations and the test would have proved one case three times over. 2050 tests pass, assets build. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-31 15:36:47 +02:00
nexxo	0543a5a542	Let a failed measurement beat a green badge, and say which zone was missing ... Three findings from the live readiness page, and the worst of them is the one that looks like nothing. Green "Erfüllt" sat directly above red "nicht in Ordnung", in the same row, twice — for the DNS token and for the VM template. The badge came from `satisfied` alone, the passive check that only establishes something IS configured, and the measurement was rendered beside it without being allowed to overrule it. Somebody scanning that list reads the badge, not the small print, and walks away with "all green" while a measurement said it does not work. R19 names this exact shape — a call that reads as an assurance and is not one — as worse than no check at all. The measurement wins now, for the badge, the icon and the reason line. zone_not_found was a dead end. It reads like "the token is wrong", so the operator replaces the token — but a wrong token never gets that far: it comes back as `rejected` from the 401 above. The token had just successfully listed the zones. What is missing is the ZONE. The check now returns the zones it did see, and the page puts them next to the one it wanted: looked for clupilot.cloud, this account holds clupilot.com. The question answers itself. An empty list says something else again, and gets its own sentence: the token belongs to a different Hetzner project. And two traffic tests were failing on main, unrelated to any of this, which is why they were checked against a clean checkout before being touched. They build "last month" as now()->subMonth()->format('Y-m'), and Carbon resolves that calendrically: on 31 July it lands on 1 July, so the row meant to be last period lands in the current one. Red on the 29th, 30th and 31st of every long month, and today is the 31st. The production code does not have the trap — currentPeriod() is now()->format('Y-m') with no arithmetic, and the two places that do compute months already guard it — so this is the tests, and only the tests. 2045 tests pass. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-31 15:26:27 +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	447d6fe0f3	Merge main into the host-takeover branch ... One real conflict, in SyncStripeCatalogue::handle(), and both sides were right. Main's parallel work resolves the adoption singletons and takes "before" counts so a run can tell created from adopted. The operating-mode work refuses a catalogue whose stored objects belong to the other mode, and records which mode the catalogue now belongs to. Kept both, with the mode guard first. It REFUSES, so it must not run behind anything that has already built state; the counters only need to be in place before the create loop, and they still are. Reversing that order would have the command resolve singletons and take counts on a catalogue it is about to reject. 2017 tests pass. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-30 21:21:45 +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	5883989552	Give settings the shape a settings page actually has ... Four attempts, and this is what was wrong with the last one: full-width panels stacked down the page, each carrying its own title INSIDE it. Every group had two frames — the title bar and the border — so the page read as a column of long boxes with nothing saying where one topic ended and the next began, and a phone number got a field a thousand pixels wide. The shape now: - **A section list on the left**, sticky, so the sections stay reachable however far a form runs. Below `lg` it becomes a scrolling strip of chips, because a vertical list on a telephone is four rows of nothing. Under it, who is signed in — on a shared office machine that is a real question, and a settings page is where it gets asked. - **A content column of 820px**, not the whole 1240 shell. - **The heading OUTSIDE the card it belongs to.** A section is a heading, a sentence, and then a card of rows. That single move is what stops them reading as boxes: the border now frames the fields, not the topic. - **What cannot be undone is last, in a card whose border says so** — the deletion deadlines and the close button together, at the foot of the contract section, in danger colours. The rows are unchanged (label left, control right) and so is every binding; what changed is the frame around them. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-30 17:59:16 +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	2a97d76b2d	Rebuild the settings page out of panels and rows ... **The withdrawal was invisible in two different ways.** It rendered only while the fourteen days were still running, so the moment they expired the whole block vanished — indistinguishable from a feature nobody built. And the account it was looked for on has no contract at all: no package, no subscription, nothing to withdraw from, so there was never anything for it to be about. It is now a row for every CONSUMER who has a contract, open or not: while it runs, the deadline and the button; afterwards, the sentence saying why it is over. A business never sees it — WithdrawalRight answers that, and Settings::withdraw() refuses them again on the server. And an account with no package says so and offers the packages, instead of a dead sentence in a box. **The page is built out of two pieces now.** x-ui.panel is a group: a card with a header that names it. x-ui.row is a setting inside it: what it is on the left, the control on the right, dividers between rows. That is the shape every settings page worth copying uses, and it is the shape that uses the width — a 280px label column with the control beside it fills the line, where a stack of full-width inputs leaves two thirds of it empty and a grid of cards of different heights walks down the screen as a staircase. All four tabs are rebuilt on it, so the page reads as one designed thing rather than four pages that happen to share a tab bar. Below `sm` the rows stack, because on a telephone a label belongs above its field. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-30 17:38:57 +02:00
nexxo	18193a731d	Stop asking for a signature the law does not want, and lay out the tab ... **The owner is right about the agreement.** Art. 28 wants a CONTRACT, not a ceremony — and a contract is concluded by incorporating the agreement into the terms the customer accepts at checkout, which is exactly how every hoster they have bought from does it. Nothing in the regulation asks for a second, separate click. What it does ask is that the agreement is in writing (electronic form included, Art. 28(9)), that it is the version in force, and that the customer can obtain it. So: the terms now say the agreement is part of the contract and needs no separate signing, and name where it is. The card states that rather than flagging the customer as outstanding — the warning chip is gone. The button stays, reworded to "Zusätzlich bestätigen": a practice or a firm that gets audited often wants an explicit record, and it costs a click. The console's counter says how many confirmed rather than how many are "open", because none of them are. **The contract tab was a staircase** — a short card, a wide one spanning both columns, then a short one again. It is one column of full-width sections now, each with the same shape: a header row carrying the state and its action, then the body. Nothing tracks sideways any more. The package section states its own state in the header instead of a paragraph in the body, the withdrawal sits under it as a row rather than a second card, and the agreement's four files each have a button — reading and keeping, agreement and measures, which the single "Herunterladen" could not express. Also: the generated version no longer carries "Aus dem Repository erzeugt (clupilot:publish-dpa)" in the console's list. That is the command line, not information. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-30 17:30:55 +02:00
nexxo	52aacddc56	Store the agreement where the web process can actually read it ... Every link on the agreement page answered 404 — the download visibly, the two inline ones just as dead — and nothing anywhere said why. The files were there, whole and correct. An artisan run inside a container is root; PHP-FPM is www-data. Laravel's local disk creates a PRIVATE directory, which is 0700, so `dpa/` came out as root-only. The web process could not enter it, `Storage::exists()` answered false, and the routes did exactly what they were told: abort 404. No exception, no log line, a page full of links to nothing. Both writers — the command and the console's upload form — now store with "public" visibility, which is the file MODE and nothing to do with the web: 0755/0644 instead of 0700/0600. The disk's root is outside the document root either way, and the two routes still check who is asking. The command also warns if a file it just wrote is not readable, because the alternative is finding out from a customer. The download itself now looks like one: the `download` attribute on both anchors, and in the console a bordered control rather than a third link in a row of two. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-30 17:19:39 +02:00
nexxo	d04ea712c7	Write the processing agreement and its annex, and let it be downloaded ... The mechanism shipped without a document. Both are here now, generated from this repository rather than uploaded — so the company is named from CompanyProfile exactly as the invoices name it, the sub-processor list is the three places customer data really leaves this application, and the deletion deadlines are read off the commands that enforce them. A wording change is a diff somebody can review, not a file that appears. `clupilot:publish-dpa 1.0` renders both to PDF (TCPDF, the engine the invoices already use), stores them on the private disk and puts them in force; `--draft` stops short of that. The console's upload form is untouched: a lawyer's revision arrives as a PDF and becomes a version like any other. **The annex says what this installation does, not what it would like to.** Every measure in it was checked against the code first — the isolation is one VM per customer because that is what provisioning builds, the backup is a daily snapshot job at 02:00 because that is what RegisterBackup creates, the deletion deadlines are the two prune commands. Claims the system does not currently keep are NOT in the document, and they are named in the handover instead. A TOM that promises more than the machine does is the document an auditor reads before looking. **Downloading** now carries the version in the filename — CluPilot-AV-Vertrag-1.0.pdf — so "which fassung did I agree to" is answerable from a downloads folder months later without opening anything. Both sides get the button; inline stays the default, because a contract is read before it is filed. Placeholder register data is left off the document rather than printed: a "FN 000000a" on a contract looks like a real number and is not one. Also: the wordmark scan tripped on a paragraph whose first word is the company name, for the second time. It now looks for the name as the whole CONTENT of an element, which is what a lockup is, rather than for the name after a tag, which is also how a sentence starts. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-30 17:12:30 +02:00
nexxo	823eeaf413	Refuse a key that does not belong to the slot it sits in ... put('stripe.secret', 'sk_live_REALMONEY') in test mode was accepted, get() handed it out, billing.stripe_secret reported satisfied, and the badge above it said "Testbetrieb". The strict rule closed the automatic route into that state (no fallback); the typed one stayed open. The prefix decides it without touching the network, and that rule now lives in ONE place — OperatingMode::ofStripeKey() — called by the three that were answering it separately: the slot migration (unchanged verdict, `?? Live` for a value it cannot place), StripeCheck's `live` flag (unchanged verdict, null stays false), and the readiness check, which never asked at all. A key it cannot place is not reported as a contradiction: this check only says what it can prove. The two directions get their own `breaks` sentence, because the consequences are opposite — real money moving while the console says test, versus no money moving while the order looks paid. The "Prüfen" button no longer contradicts the check either: the page rendered only ok/reason, so a live key in the test slot answered "Geprüft: in Ordnung". It now names the account the key belongs to. Red first: ⨯ it refuses a live key sitting in the test slot ⨯ it refuses a test key sitting in the live slot ⨯ it says what the wrong key does, not that a field is empty Guard tests (ConfirmInModal, ModalHeight, IconLayout, DisplayTimezone) run with the blade change: green. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-30 17:05:58 +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	49d528dbea	Fix round: point at the real tab, hide the button nobody can press, prove the quiet page load ... Fixes four Important findings from the review of Task 12. Corrected nine check `tab` values at the source (BillingChecks was already correct; OnboardingChecks/ProvisioningChecks/DeliveryChecks all carried the pre-redesign 'integrations' value, which is not a member of Integrations::TABS): four onboarding checks now point at 'platform' or 'env' depending on where their field actually is, five provisioning/delivery checks point at 'services'. checkUrl()'s match-block resolver — praised as correct for the six checks that point at a genuinely different admin page — is unchanged; its `default` arm is now a pure safety net, not a route any check actually relies on. Wrapped the "Prüfen" button in @can('secrets.manage'): mount() admits hosts.manage OR secrets.manage, but runCheck() requires secrets.manage alone, so an Admin-role operator could see a button that 403s on press. Fixed a docblock on HEARTBEAT_KEYS that asserted a staleness threshold was kept in sync with OperationChecks::STALE_AFTER_MINUTES — that constant is a key/settings-name map with no threshold of its own, and no such synchronisation exists. Three new tests, each confirmed red against a deliberately reintroduced version of the bug it covers before being confirmed green: every check's tab value against where its field actually lives, the run-check button hidden from an operator who cannot press it, and Http::assertNothingSent() after a plain page load. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-30 16:26:10 +02:00
nexxo	1d4e98eb06	Rebuild the customer's settings page as four tabs ... It was one column 768 pixels wide inside a 1240-pixel shell — a third of the window empty beside it — holding everything a customer might ever change: the company address, their password, two-factor, the devices they are signed in on, the branding of their cloud, the contract, and the button that closes the account. Two thousand pixels of scroll, and the way to a particular thing was knowing how far down it lived. Four tabs, by what somebody came to do: their details, security, the appearance of their cloud, the contract. The same tab bar the console uses, so one vocabulary holds on both sides of the login, and the choice lives in the query string — `#[Url(history: true)]`, no `except`, so the parameter is there from the first render and a link to this page can name the part it means. An unknown tab out of the address falls back to the first rather than rendering a settings page with no section on it. The width is used now. Inside a tab the short cards sit side by side instead of each taking a full row to hold three lines: the customer type beside the company form (it is one question, and beside the VAT field it was mistaken for it), the password beside two-factor, the logo beside the colours, the contract beside the closing of the account. Also: the subtitle listed the old sections by name. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-30 16:25:10 +02:00
nexxo	8479fc30f8	Fix the checkout link, and stop the switch moving under the cursor ... **Every package button led to "Dieses Paket steht nicht (mehr) zum Verkauf".** The link was built as route() plus "?term=" + term — but both are QUERY parameters on this route, so route() had already opened the query string and the result was `?plan=team?term=monthly`. The package arrived as the whole string "team?term=monthly", matched nothing in the catalogue, and the page said so politely while giving no hint why. The address now comes from route() in one piece with a placeholder swapped into it, and a test asserts every checkout link on the page contains exactly one question mark. **The saving moved the buttons it belonged to.** It hung under the switch and was hidden on the yearly view, so choosing a term shifted the very control that chooses it. It sits above now and never disappears: one line, two wordings — an offer while it is an offer, a statement once it is taken. Same on the public sheet, where its vanishing re-centred the row. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-30 16:05:56 +02:00
nexxo	ff92466b47	Give the order a checkout page, and stop hiding what a year costs ... **There was no checkout page.** The package list posted straight to Stripe, so the last thing a customer saw in this product's design was a grid of cards and the next was somebody else's form asking for a card number. What they were buying, what it costs in total, what happens afterwards and what they were agreeing to were never stated in one place. App\Livewire\Checkout is that place: the package and its figures on the left, a sticky summary on the right — net, the saving where there is one, the setup fee, the tax, what is due today, and what will be charged after it. Every figure comes from the catalogue, TaxTreatment and SetupFee, the same three the checkout itself reads; nothing is recomputed, because a summary that works out its own total is a second answer waiting to disagree with the one Stripe is handed. **The terms acceptance moved to where the money is spent.** It sat at the top of the package list as a condition of LOOKING at prices, with every button dead beneath it. It is a condition of buying, so it is now at the foot of the summary, directly above the button — after the total, which is the order those three things are read in. The package list has no form on it at all now; its buttons are links. **The page used the left half of a 1240px shell.** A 68-character title, a switch under it and an 80-character footnote, beside a grid that used the whole width. Now: a header band with the name left and the term switch right, where a control belongs, and a closing band of three columns instead of a paragraph trailing off. **The yearly view showed the monthly equivalent as its headline**, so on a package with no free months the big figure did not move at all when the switch was thrown — the page looked like it had ignored the click. The headline is the price of the term in the unit it is charged in; what a year works out to per month is said underneath. Same on the public sheet. **The switch was unreadable.** `text-on-ink` is not in this palette — the ink pairing is bg-ink/text-bg, as x-ui.button has always had it — so the label kept its inherited grey on a near-black pill. And its shell was rounded-lg with rounded-md options inside: two radius scales, one of them Tailwind's untokenised 6px. One scale now, nested. **The mails drew an empty orange tile.** The mark's ascent lives in an SVG the site loads and a mail cannot — Gmail strips inline SVG, Outlook renders with Word, and this layout carries no image by design. The shape is drawn with a character every mail font has, white on the accent tile, with the whole wordmark beside it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-30 16:00:08 +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	fe1110de71	Fix round: name the slot on the card, and cover the modal that already worked ... Names which of the two slots a card actually reads and writes right now, at the card an operator types into (not only the page-top badge) — save() and render() resolve without a mode argument, so the card looked identical in both modes while quietly acting on whichever slot was active. Also adds the ConfirmSwitchMode coverage IntegrationsPageTest already carries for ConfirmSaveSecret/ConfirmForgetSecret: a modal is reachable without the page's route middleware, and reading the code is not the same as testing it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-30 15:32:16 +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	96f171b3b3	Put the switch where it governs, and say when it is thrown ... Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-30 15:09:38 +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	2321854967	Discard an unconfirmed registration, and sweep the abandoned ones ... "Abmelden und neu registrieren" was advice that could not work. Signing out frees nothing: the address is still held by the unique index, so registering again with the address somebody meant fails — and every abandoned attempt stayed in `users` for ever. Reported exactly that way, and it was right. The button discards the account instead. Only an UNCONFIRMED one, and only one with nothing behind it: the webhook creates a customer's login from a paid checkout, so a user can sit on this page unconfirmed while already having a contract, and deleting that is data loss dressed up as a convenience. It refuses and says where to go. A confirmed account is closed, not discarded — that is ConfirmCloseAccount, with an invoice history behind it. R23: confirmed in a modal. The modal mutates nothing; it dispatches the event the page listens for, so the checks stay in the one place they already are rather than being duplicated where they could drift. And nothing has to be discarded by hand. clupilot:prune-unverified removes registrations nobody confirmed after five days — long enough for somebody who signed up on a Friday and found the mail in a spam folder on Monday, short enough that a typo does not hold the correct address for a month. It skips a confirmed account whatever its age, and any account with a customer record behind it, matched on user_id AND on the address, because either link means somebody is a customer. Every removal is logged with the address: a line that disappears is what somebody asks about later, and a count answers nothing. The deadline is said on the page as well as in the mail. Somebody who never received the mail is looking at the page, and the deadline is the reason they do not have to do anything about an attempt they abandon. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-30 14:08:02 +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	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	32a8bd9a88	Refuse the sale instead of reaching Stripe without a key ... Task 5: Billing::purchase() now checks SecretVault for a stripe.secret before touching anything else — no customer, no plan lookup, no Order row — and the customer reads a plain sentence instead of a 500 page. HttpStripeClient's own secret() throws the same StripeNotConfigured exception rather than sending a request with an empty bearer token and letting Stripe's 401 stand in for the real cause. isConfigured() was fixed alongside it: it used to call secret() too, which would have turned every "is Stripe set up?" check (the checkout controller, the catalogue sync commands) into an uncaught exception the moment a key went missing — the opposite of what this task is for. It now reads the vault directly. The new guard is unconditional, including for the cart-only purchase types (storage, addon, plan changes) that never call Stripe themselves — a cart order nobody can ever pay for is pointless to create. That broke every existing Billing/Cart/Downgrade test that calls purchase() without a stored key; each affected fixture now deposits one via the new withStripeSecret() Pest helper. A few of those tests (CustomDomainAccessTest, DowngradeTest) were passing already but for the wrong reason — the new guard, not the check they were named for — since both only assert an order was NOT created; they get the same fixture fix so they still prove what they claim. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-30 11:58:01 +02:00
nexxo	9da1358802	Stop charging VAT to the customers who owe us none ... A verified EU business outside Austria gets reverse charge — rate 0, no VAT line, the note on the invoice — and was still charged 214,80 € for a 179,00 € package, because one Stripe Price carried the domestic gross for everybody. There is no VAT line on their document to reclaim, so it was a flat 20 % surcharge on exactly the customers who read their invoices, and the document then stated the whole 214,80 € as net at 0 %, so they self-accounted their own VAT on a base a fifth too large. A Stripe Price can ask who is buying after all: there are two per sellable thing now, the domestic gross and the bare net, both live on one Product, and the checkout picks by TaxTreatment. The rule is Austria B2B 20 %, other EU B2B without VAT — a domestic business still pays the gross, reclaims it as input tax, and the price on the website is still the price charged for them. - stripe:sync-catalogue mints and archives both halves of every pair, per plan and per module; `reverse_charge` on stripe_plan_prices/stripe_addon_prices says which is which, and joining it on subscriptions.stripe_price_id says which one a running contract is billed on. A rate change moves the gross Price and leaves the net one alone, because the net owes nothing to the rate. - A status that changes after the sale converges: a verification (or a lapse) makes stripe:reprice-subscriptions move the contract onto the other Price with PRORATE_NONE, because the term is already paid for. The module items follow the same way. - Downstream follows: the invoice total equals what was taken, the proof register expects the figure this customer is actually charged (so a correct reverse-charge sale is no longer flagged as a mismatch, and an overcharged one is), the setup fee obeys the same rule, and the booking page quotes what it will charge. - StripeClient gained activatePrice(). Archived Prices were brought back in our own table and left inactive at Stripe, so a rate that moved and moved back pointed the catalogue at a Price no checkout could be opened for. An unverified number is still charged the gross — an unchecked string must never be a discount — and where the net Price is missing the checkout refuses rather than reaching for the domestic one. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-30 02:15:41 +02:00