207 Commits (main)

Author	SHA1	Message	Date
nexxo	d76de5ada3	Restart a machine, enforce the quota that was sold, end a route that ended ... Three places where the product said one thing and did another. **Nothing could restart a virtual machine.** ProxmoxClient had startVm and no way to stop anything, so `restart_required_since` — set by every plan change that grows a running guest — could only ever be cleared by a resize step that happened to find the machine stopped, which nothing in the product could arrange. A paid upgrade's cores and RAM could stay unreached for the life of the contract, and the cloud page's "Neu starten" was a toast. There is now a `restart` pipeline: shutdown, start, wait for the agent, confirm. A shutdown and a start rather than a reboot, because only a cold boot makes qemu read the VM definition again — a reset would take the machine round and bring it back exactly as small as it was. The shutdown is a REQUEST, bounded at ten minutes, and there is no escalation: ProxmoxClient deliberately does not expose Proxmox's forceStop, because the guest is a Nextcloud and cutting power to a database mid-write to apply a CPU change trades an inconvenience for a restore from backup. A guest that ignores ACPI for ten minutes fails the run instead, and a person decides what happens to it. `restart_required_since` is cleared by the last step, from what the RUNNING guest reports (`cpus`/`maxmem`) — not by the button, and not by the run merely finishing. A machine that comes back smaller than it was sold fails the run. Started by App\Actions\RestartInstance, which re-checks authorisation itself rather than trusting a hidden button: an operator holding the new `instances.restart` may restart anything, a portal user their own machine and nothing else. Refused while another run is in flight against the same order. Confirmed in a modal on both sides (R23), addressed by uuid (R11). **Existing instances had no storage quota.** ApplyStorageQuota reaches new and changed machines; everything built before it kept the whole disk whatever it had paid for, and nothing recorded which was which. `instances.quota_applied_gb` is now what the guest was actually told, written by the step only after the occ call succeeds — so "sold" and "enforced" are separate facts and can be compared. `clupilot:apply-quotas` sweeps the estate: one `quota` run per instance through the same step the pipelines use, skipping what it should and saying why, a no-op once an allowance is enforced, and inert under --dry-run. Deliberately NOT scheduled — a nightly sweep would quietly cover for the pipeline step the day it stopped working, which is how the original hole survived this long. **A Traefik router was never torn down.** TraefikWriter::remove() had no caller anywhere. What was missing was the moment: ConfirmCancelPackage wrote a date into `service_ends_at` and nothing ever went back to it, so every route this platform ever wrote was written for good — pointing at a guest address the host is free to reassign. `clupilot:end-due-services` (hourly) keeps that appointment through App\Actions\EndInstanceService. "Ended" means cancellation_scheduled AND `service_ends_at` passed, never the day a cancellation is scheduled: that customer has paid to the end of the term and is working in it. The DNS record goes with the route — it is in our zone, pointing at a host that serves other people, which is the shape of every subdomain takeover there has ever been. The customer's own domain is in their zone and is not ours to touch; the virtual machine is left alone, because the cancellation flow promises a data export first and destroying disks is not this change's decision. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-29 18:28:28 +02:00
nexxo	8f2252e81b	Book a downgrade for a date that cannot move, and sell a module once ... Two ways of charging a customer for something they did not get. A downgrade was due when `subscriptions.current_period_end` said so, and Stripe pushes that column forward on every renewal. So a downgrade booked in March was deferred to the end of April by April's renewal, and to the end of May by May's — each time by a whole term, and each time the customer was billed again for the package they had asked to leave. The due date was being re-derived from a moving target on every scheduler tick. It is decided once now, at the moment the customer decides, and stamped onto the contract: `pending_plan` and `pending_effective_at`, the two columns that have been in the schema since the first migration and were written by nothing at all. The shop stamps them, PlanChange reads them instead of the period end when a move is already booked, and clupilot:apply-due-plan-changes finds contracts by the stamped date rather than orders by a date it recomputes. The order stays what it always was — the customer's own record of the request, what the cart shows them and what they remove to change their mind — so it is still consumed with the change, and removing it unbooks the change. What it no longer does is decide when. A second downgrade replaces the first rather than queueing behind it; an upgrade clears one, or it would come due months later and undo the bigger package; a contract cancelled before the date takes the booking with it; and a customer with no contract can no longer place a downgrade at all, which was accepted before and could never be carried out. A booked change is now visible where the contract is read: on the plan card in the portal, because the cart entry disappears when it is paid for and the booking does not, and on the customer row in the console, because that is where an operator answers "what is this customer on". The second defect is the same money in one step: BookAddon guarded duplicates per ORDER — the unique index on (order_id, addon_key) — so two orders for the same module on one contract both went through. A stale tab or a double click bought priority support twice. But storage is deliberately sold in packs, and AddonCatalogue sums the quantities for exactly that reason, so "refuse the second" is only right for some of them. Which is which is declared beside each price in config/provisioning.php (`sold_as`), because it is a commercial decision about each module and not something to infer from a key: storage is a quantity; off-site backups are on or off, support is prioritised or it is not, Collabora Pro is one licence, and a machine answers to one own domain. An undeclared module counts as an entitlement — the cheaper of the two mistakes — and a test refuses to let one ship undeclared. Enforced in the action, where the portal, the console's grant screen and a webhook all pass, with the sentence the customer is shown rather than a developer's. A retried webhook for the SAME order still gets its one booking back; that is one purchase arriving twice, not two purchases. The portal stops offering what would be refused — booked, or already waiting in the cart — and goes on offering the pack. What is missing is on the Stripe side and is not invented here: nothing moves the subscription's item onto the new Price, so the renewal after a plan change still bills the old plan at Stripe. StripeClient only creates and archives catalogue objects, and swapping a price also needs the subscription ITEM id, which nothing stores. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-29 17:51:37 +02:00
nexxo	82f95df04c	Stop the 503 page appearing during an update ... Reported with the network panel open: `update` and `state` both answering 503, then the overlay, then Laravel's 503 page, then a reload. Three different screens for one event. Livewire's default on a failed request is to render the response body. So a wire:poll that happened to fire while the application was in maintenance mode swapped the whole console for the 503 page — the panel the operator was watching, replaced by an error page, for something that is not an error. A deployment IS maintenance mode; that is the event, not a fault. Three changes, and they are three because the request came from three places: The status endpoint is exempt from maintenance mode. It is the deployment's own status, read by the overlay every three seconds, and behind maintenance mode it answered 503 for the entire run — so the overlay could never name the step it was on. Safe to exempt: version, commit and a step name, behind the console's host and network guards, and it writes nothing. Livewire swallows a 503 instead of rendering it. For every request, not only the poll: any action taken in that window did the same thing. And the settings card stops polling for the duration. The overlay's own watcher is a plain fetch with no component state behind it, which is why it survives the restart; this poll cannot, and every attempt was a request that answered 503. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-29 17:50:15 +02:00
nexxo	98afd1d7e0	Re-apply what the last release commit silently reverted ... The English paths and the zone migration went out in 5f74a5f and were gone again in the tag. Reported for the fourth time, and the fourth report was right: nothing had changed on the server. What happened is mine and worth writing down. I have been building commits in a private index (GIT_INDEX_FILE) to avoid staging a parallel session's in-flight work, and moving the branch with `git update-ref`. That moves HEAD without touching the shared index — so the index still described the PREVIOUS commit. The very next ordinary `git commit` (the version bump) wrote that stale index as a tree, which reverted every file of the commit before it. The tag was cut from the revert. Two things follow. The private-index technique is only safe while the branch is not checked out; once it is, `git branch -f` refuses for exactly this reason and `update-ref` is the same operation with the safety removed. And a release is not verified by a green push — it is verified by reading the tag, which is what finally found this. Content unchanged from 5f74a5f: English fragments and legal paths with permanent redirects, the guarded zone migration, and the test that walks every route and fragment so a German path fails the suite instead of being reported again. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-29 17:36:43 +02:00
nexxo	1620cb9395	Release 1.3.22 ... v1.3.21 was taken by a parallel release between reading main and writing the commit; the version file went out saying 1.3.21 on a commit that is not that tag. Corrected here rather than by rewriting a pushed commit. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-29 17:26:46 +02:00
nexxo	5f74a5f370	Move the zone by migration, and put every path in English ... ── The zone, for the fourth time ──────────────────────────────────────────── "Change it in the console" was the wrong answer three times running. An installation with nothing to migrate should simply arrive on the new zone, so a migration does it — guarded by exactly the condition clupilot:check-zone reports on: no instance in service, therefore nothing carrying the old name in DNS, in a certificate or in trusted_domains. With even one instance it does nothing and logs why, because re-addressing a running Nextcloud is a migration with an outage and a migration is not the place to start one. It leaves an installation already on another zone alone: the setting exists so somebody else can run this on their own domain. That fixes both reports at once — the security page and the price sheet read the same setting, which is the entire reason neither of them has the domain typed into it. ── R13, applied to all of them this time ──────────────────────────────────── "Ich schreibe das nun zum dritten Mal" — fair. The rule was cited, I changed the one route that had been pointed at, and left every other German path standing. A fragment is part of a URL too. #produkt → #product /legal/impressum → /legal/imprint #ablauf → #process /legal/datenschutz → /legal/privacy #preise → #pricing /legal/agb → /legal/terms #fragen → #faq (old paths redirect, permanently — they have been #kontakt → #contact in the footer and in mail for weeks) The headings stay German. "Impressum" is the legal term an Austrian company has to use; the address is not part of the copy. A test now walks every registered route and every fragment the site links to, so the next German path fails the suite instead of being reported a fourth time. Three existing tests set config('provisioning.dns.zone') and read it back through the accessor. That worked while the setting was empty and stopped the moment the migration filled it — they set the setting now, and the one whose premise is "nothing saved yet" establishes that premise itself. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-29 17:26:20 +02:00
nexxo	34874adec3	Apply a bought plan change instead of only pricing it ... PlanChange could say what a move would cost and whether it was allowed, and that was all it could do. Billing::purchase() wrote an upgrade order and nothing ever consumed it: same snapshot, same machine, same quota. A customer could pay for a bigger package and receive nothing. ApplyPlanChange is now the single place a change lands — it moves the contract onto the target's current version, writes one register row, settles the custom domain, and starts a run that resizes the machine. Applying the same order twice is a no-op, enforced by a unique event key rather than by a check two callers could both pass. Two things a plan change must not do, and now does not. A disk is never shrunk — Proxmox cannot, so the QUOTA shrinks instead, which is what was sold anyway. And a live machine is never rebooted as a side effect: cores and RAM are written, and where they need a restart the instance says so where an operator and the customer can both see it. The storage allowance also joins the build pipeline. ApplyStorageQuota was written for plan changes and ran only there, so a brand-new customer still got no quota at all — quota_gb reached the instance row and stopped, and every package delivered the whole disk. The test guarding that pipeline only counted its steps, which is how a list missing the one step that makes a package's storage real stayed green for its whole life. It now names the step. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-29 17:18:55 +02:00
nexxo	d5b2612e24	Always name the host we are being served from, and stop promising a duration ... ── Why the domain list looked wrong ───────────────────────────────────────── Reported three times, and it was not only the setting. The list came from `admin_access.site_hosts` and the instance zone — and where SITE_HOST is not configured, site_hosts is EMPTY. So an installation reached by a name nobody wrote into the config listed ONLY the instance zone, and described it as the customers' domain: the page a visitor opened to check our addresses omitted the address they had just typed, and named the wrong thing as ours. The host serving the request is now always in the list. It is the one address that is true by construction and needs no configuration to be right. (The zone itself is still one setting, and it is now clupilot.cloud on this machine. On another installation it is Konsole → Integrationen → DNS-Zone.) ── The clock ──────────────────────────────────────────────────────────────── "Eine Zeit angeben geht nicht — wenn es fertig ist, ist es fertig." Correct, and it was claimed three times over: an eyebrow saying "In 20 Minuten betriebsbereit", a provisioning log with minute marks down the side, and a closing line repeating it. A run waits on a hypervisor, on a certificate authority and on DNS propagating. A customer who once waits forty minutes has been told something untrue by their supplier, and the page cannot take it back. What replaces it is what actually IS promised and kept: the order of the steps, ticked off, numbered 1/5 to 5/5 — and then the sentence that answers the real question behind "how long", which is not a number but "do I have to sit here": you get an email with the address and the credentials when it is ready. The same claim is gone from the hero meta ("< 20 Min." → "automatisch"), from the figure line ("20 Minuten bis zum Betrieb" → "0 Termine bis zum Start") and from the FAQ, which now says outright that we do not name a duration and why. Kept deliberately: the 45-minute training session and the three-to-seven working days for setup. Those are appointments we schedule and commitments we control, not predictions about a machine. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-29 17:10:06 +02:00
nexxo	3a4324fb6f	Give people a way back in, and put the URL in English ... ── The hole ──────────────────────────────────────────────────────────────── There was no password reset. Fortify's feature was commented out, so there was no link on the sign-in form, no page and no route — a customer who forgot their password was locked out of their own cloud until somebody opened a shell. On a product whose selling point is that you can ring somebody, that is a support call a week and an embarrassing one. Two pages of ours under Fortify's route names (R1/R2), because with views off Fortify registers only the POST endpoints. The mail is a Mailable in this product's design rather than the framework's MailMessage: somebody who has just been locked out is exactly the person a phishing mail is aimed at, and a message that looks nothing like the rest of our post is one they cannot check — ours carries the footer that names our domains. Three decisions worth stating, each with a test: The answer is identical whether the address is known or not. "No account with that address" turns the form into a way of finding out who is a customer. The reset kills every other session. Whoever knew the old password may still be signed in somewhere, and a reset that leaves them there has fixed nothing. It does NOT sign the visitor in. The link arrived by email, and a mailbox somebody else can read would otherwise be a session somebody else gets. ── /sicherheit → /security ───────────────────────────────────────────────── R13: paths are English. Mine was not. The old path stays as a permanent redirect because it has already gone out in mail footers. ── One wordmark ──────────────────────────────────────────────────────────── "Sometimes it says Cloud and sometimes it does not" — correct. It was on the footer, the placeholder and the maintenance screen, and absent from the header, the sidebar and the sign-in plate. The product is called CluPilot Cloud; that is the name on the invoices and in every mail, so it is now the name everywhere. The console sidebar takes the small size so the lockup, the ADMIN badge and the close button still share one line (R18). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-29 16:50:29 +02:00
nexxo	712803edd6	Serve the custom domain, not just announce it ... A verified custom domain was reported as the customer's address by Instance::address(), by the portal and by the credentials mail while nothing on the platform routed it: the Traefik router's rule was hard-coded to {subdomain}.{zone}. The address a customer was handed answered nothing, and a withdrawn domain stayed in Nextcloud's trusted_domains forever, because the only thing that ever wrote either was the initial provisioning run. - TraefikWriter::write() takes a LIST of hostnames under one stable router name — the platform address always, the verified domain as well when there is one. One file per instance, so a withdrawal is a rewrite rather than a second thing somebody has to remember. - ConfigureDnsAndTls records the custom domain's certificate instead of waiting on it: it depends on an A record in the customer's own zone, which may never appear, and must never fail a run. The platform address keeps its 840s deadline. instances.domain_cert_ok tells "proven" apart from "answering", and the portal now says which. - ConfigureNextcloud deletes trusted_domains 2 when there is no verified domain, so a withdrawn one stops being trusted. - New `address` pipeline (those two steps) plus ReapplyInstanceAddress, which starts one against the order and refuses to start a second while any run is in flight. The route is rewritten when the hostname list differs from what the router carries — not on route_written, which would short-circuit exactly the case a re-apply exists for. - Triggered where the address changes: verification flipping either way in clupilot:verify-domains, the customer's own domain page, and CustomDomainAccess::deactivate() on a package downgrade. - A maintenance run no longer condemns its subject: an address run that failed used to mark the order failed and release the live instance with it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-29 16:44:52 +02:00
nexxo	085b110e7f	Link the phishing page from the section people look in ... Reported: "I cannot find that under Sicherheit on the website." Fair — the page was linked from the site footer, from every mail footer and from under the sign-in form, and none of those is where somebody goes when the thought "is this really them?" occurs. They go to the section called Sicherheit. It is now the last thing in that section, as its own card: what the page is for, in one line, and where it leads. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-29 16:30:29 +02:00
nexxo	6ef9b510ce	Merge branch 'feat/plan-reopen' ... # Conflicts: # app/Http/Controllers/LandingController.php	2026-07-29 16:20:07 +02:00
nexxo	f8874f32ea	Put customer instances on their own domain, and say which domains are ours ... ── The zone ──────────────────────────────────────────────────────────────── A fresh install now addresses customer instances under clupilot.cloud rather than clupilot.com. Not branding: a Nextcloud is third-party software that strangers sign in to, and on the same registrable domain as the portal it shares cookie scope, document.domain and CAA with it. The same reason googleusercontent.com and vercel.app exist. Existing installations keep whatever the console says — the zone has been a setting all along. `clupilot:check-zone <zone>` reports what a change would touch before anything is touched: the DNS records, the monitoring targets, the certificates and Nextcloud's trusted_domains all carry the old name and the setting reaches none of them. With no instances in service it says so and stops. Changing it later is a migration with an outage, and the command says that too. ── Which addresses are ours ──────────────────────────────────────────────── A new public page at /sicherheit: the domains that belong to us, the rule for reading an address bar, what we never do, and — the part that matters — what to do if you have already typed your password into a copy of our sign-in form. Change it, end every other session, change it wherever else you use it, tell us. In that order. Reachable without an account, deliberately: somebody who has just given their password away is signed in nowhere, and the page they need cannot be behind the thing they lost. Linked from the three places a person is when the question comes up: every mail footer (the mail is the vector), the sign-in form (this is the page a phishing kit copies, so the real one says which host you are on), and the site footer. The domain list is DERIVED from configuration and keyed by what each domain is for. A list typed into a page would eventually tell a customer that a phishing domain is one of ours, or that one of ours is not — the same two-sources-of-truth failure that had the price sheet promising an address on a domain the company does not own. The operator console is deliberately absent from it: naming it on a public page tells an attacker where to aim. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-29 16:03:13 +02:00
nexxo	b3651a14be	Decide who may have their own domain, and decide it in one place ... The domain page shipped with no access control at all: the `custom_domain` plan feature was checked nowhere in the codebase, and every customer on every package could point a domain at their instance. This is the owner's rule, built as one authority that everything else asks. Start impossible — not bookable, not upgradable, not offered Team optional, via the `custom_domain` module Business included, because the plan version carries the feature Enterprise included, likewise App\Services\Billing\CustomDomainAccess answers all of it: may this contract use one, may it book the module, why not in words a customer can be shown, what a downgrade would do to a domain they have, and — after a change lands — making the state match. Read against the FROZEN plan version, never today's catalogue, so a feature added to a package later cannot reach into a contract signed before it. Which packages cannot have one at all is an explicit list in config/provisioning.php, beside the module's price. The catalogue cannot answer it: plan versions model what a package HAS, and nothing models what a package may BUY. Both available proxies are dishonest — "the lowest tier on sale" hands the right to a grandfathered Start customer the day the owner stops selling Start or adds something cheaper below it, and reading it off `branding` would sell a domain to anyone allowed to upload a logo. The config comment says so. Enforced where it can be enforced today: - BookAddon refuses the module, with the sentence the customer is shown. GrantAddon now writes its synthetic order inside the transaction, so a refusal cannot leave a paid order for a module nobody got. - The portal drops the card where it cannot be booked and shows it as included where the package carries it — no price, no button. - Billing::purchase() re-checks, because a hidden button is markup. - DowngradeCheck reports the consequence beside the blockers, so the customer reads it above the button rather than after it: losing the domain (Team -> Start), or the choice (Business -> Team, where keeping it means booking the module). - PlanChange::settleCustomDomain() applies it once a change lands: the module stops being charged for and the instance goes back to its platform address. It clears the whole domain, not only the verified flag — clupilot:verify-domains re-reads every row that still has a domain and a token, and would switch it back on the next night. - The price sheet's own-domain row now reads dash / optional + price / included, from the same authority; the three cell states already existed and the view is unchanged. STILL TO APPLY, ONCE THIS AND THE CUSTOM-DOMAIN BRANCH MEET — one line at the top of App\Livewire\CustomDomain::mount(), which belongs to the other session and is deliberately untouched here: abort_unless(app(\App\Services\Billing\CustomDomainAccess::class)->allowsCustomer($this->customer()), 403); routes/web.php is left alone for the same reason. The mount() guard covers the route and the component both; a middleware would only repeat it. Follow-ups, named rather than built: - Nothing applies a plan change anywhere yet, so settleCustomDomain() has no caller. Whoever builds that must call it after the new contract opens, and must decide whether a booked module is carried onto the new contract — enforce() cancels the booking on the contract it is given. - Deactivation sets the state; it does not re-run provisioning. Traefik and Nextcloud's trusted_domains still name the old address until ConfigureDnsAndTls / ConfigureNextcloud run again. - App\Support\Navigation still shows the Domain tab to every customer; it can ask allowsCustomer() the same way. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-29 15:59:04 +02:00
nexxo	a4626d2569	Stop root workers breaking every page, and let the panel be closed ... ── The 500 ───────────────────────────────────────────────────────────────── "touch(): Utime failed: Operation not permitted", from BladeCompiler, on every request for the affected view. Blade compiles a view and then touch()es the compiled file to the source's mtime. touch() with an explicit time needs ownership of the file. A compose service without `user:` runs as ROOT — and queue, scheduler and reverb had none — so the first worker to render a view wrote a root-owned compiled file that the web process, as www-data, could never refresh again. The queue is what renders mails, which is why this surfaced now. queue, reverb and scheduler run as www-data. queue-provisioning stays root and says why: it brings wg0 up and runs `wg set` for every peer change, which needs NET_ADMIN on the running process. It renders no mail. And update.sh normalises ownership at the END of a run as well as at the start. The first call heals what a previous run left; the second heals what this one made — `git checkout` rewrites the tree as the service account while the old build is still serving. ── The panel that would not go away ───────────────────────────────────────── The same 500 is why it kept coming back: every poll failed, the watcher treats a failed request as "still restarting" (which it normally is), and the overlay stayed up over a console nobody could then reach to find out why. A restart is seconds. After two minutes of nothing the panel now says so and offers a way out — for an operator only, behind the same flag as the step and the log, so a customer on the 503 page is not shown a button suggesting they can call the deployment off. A successful answer clears it again: one bad minute must not leave a "something is wrong" notice sitting there for the rest of the run. Not an always-present close button. The deployment does not stop because somebody dismissed a panel, and offering that at the wrong moment is a lie. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-29 15:43:54 +02:00
nexxo	da76a260fb	Give the settings page an outline ... Reported as cramped boxes with empty space either side, and it was: one column half the window wide, eight cards of identical weight stacked in an order nobody chose — the operator's own password sitting between two platform-wide switches — and every card taking a full row to hold three lines of text. The page is wider now and has three groups, each with a heading: what belongs to the installation, what belongs to the signed-in operator, and the team. Short cards sit side by side instead of one per row. The two-factor policy moved into the installation group, where it belongs: it is a rule for everybody who signs in, set by the owner, not a setting on one account — and it fills the space the short website card was leaving beside the long allow-list. Fields are sized to what goes in them. The three password boxes were laid out three across inside a narrow card; they stack in a half-width one. The window times are four characters and were as wide as their column. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-29 15:29:07 +02:00
nexxo	517606b4db	Split the price sheet into what everyone gets, what differs, and what costs extra ... One boolean matrix was carrying three different kinds of statement, and it made all three unreadable. Updates, backup and monitoring were a tick in every column — a comparison that compares nothing — and the same promises were repeated in a prose line under the table. They are now stated once, above it, together with the platform address in the shape a customer will actually type (ihrefirma.<zone>, from the configured zone) rather than as the phrase "eigene Subdomain", which said nothing and was modelled as though an own domain replaced it. Provisioning issues both. Support was two independent booleans on one axis, so enterprise — which carries the SLA and not the priority flag — rendered "Bevorzugter Support —" beside team's tick: the top plan looking worse than the middle one. It is one row of levels now, and a plan with neither shows Standard, because standard support is a level and not an absence. A cell had two states, so a dash meant both "you cannot have this" and "you can have this for nine euros". There are three now, and the middle one quotes AddonCatalogue — which is also how the modules we have been selling all along finally appear on the page at all. Nothing is invented: where we sell no module for a missing feature, the cell stays a dash. custom_domain joins the module list at the owner's figure so the two plans without it can be quoted a price instead of told no. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-29 15:25:20 +02:00
nexxo	6c92aa5dd7	Let an incident be deleted, and start measuring whether the hosts answer ... Three things, all from trying to actually use the incident page. ── Where the later entries go ─────────────────────────────────────────────── The form only ever creates the first one, and nothing said so — so it looked as though the stage had to be chosen up front and there was only a dropdown for the impact. The field now says what it becomes ("wird untersucht") and where the rest are added: on the incident itself, once it exists. ── Deleting ──────────────────────────────────────────────────────────────── Asked for in order to test the thing at all, and right. A whole incident can now be removed, with its entries, behind a confirmation in the product's own dialog (R23). Deliberately not the same as editing an entry, which there is still no way to do: an update is a statement made at a time, and rewriting one afterwards is what the record exists to prevent. Removing the whole incident is a different act — it is how a test entry, or one published against the wrong service, is taken back, and it leaves nothing half-standing behind. A test holds that distinction so the delete button does not quietly become an exception to it. ── The hosts, which nothing was watching ──────────────────────────────────── `hosts.last_seen_at` drove the health dot in the console and was written exactly once, at onboarding — RegisterCapacity stamped it and that was the only write in the codebase. So every host read "offline" thirty minutes after it was added, permanently, and the dot meant nothing. It is also why host reachability could not appear on the status page: it was never being measured. PingHosts asks every host's API the cheapest question it answers, once a minute, and stamps the timestamp on success. Failure writes nothing on purpose: absence IS the signal, and a second column counting failures would be a second version of the same fact. The status page has a fifth component for it. Counts only — never a host name, never an address; the page is world-readable and the estate is not public information. A host between five and thirty minutes silent reads as degraded, not as healthy: "stale" is one of three answers healthState() gives and it is not the good one. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-29 15:16:48 +02:00
nexxo	0e3c50d9a1	Update on a schedule if the owner wants one, and say where incidents go ... ── Where the status page gets its data ────────────────────────────────────── Asked in as many words, and fairly: the page for maintaining incidents exists (console → Betrieb → Störungen) and nothing anywhere said so. The page now carries the answer at the top — what is written there appears publicly at once, the four components measure themselves, and there is a link straight to the live status page. ── Automatic updates, inside a window, switchable ─────────────────────────── Tick it and name the days and hours; leave it alone and nothing changes. The button stays either way: manual is always possible, at any hour. It leaves exactly the same request the button leaves — same file, same agent, same run. A second path into a deployment would be a second set of rules to keep in step with the first, and the automation must not be able to do what an operator is prevented from doing by hand: it checks the same three things the button is disabled by (agent alive, something released, nothing running). Nothing guards against having already updated by hand, and nothing needs to: an installation that is current has nothing available, so pressing the button at four leaves the five o'clock window with nothing to do. That was the owner's own question and it answers itself. Defaults are Tuesday to Thursday, 05:00–06:00. Not Monday — the week starts and every fault costs double. Not Friday — nobody wants to repair a deployment on a Friday afternoon. Not three in the morning: if it goes wrong, the person who has to fix it is asleep. A window whose end is before its start wraps past midnight, because 23:00 to 02:00 is a reasonable thing to ask for and reading it as an empty range would silently mean "never". Switched on with no weekday selected is refused rather than corrected — it is a configuration that reads as working and does nothing. The clock is the wall clock (R19): an operator who writes 05:00 means five in the morning where they live, and a window that drifts by an hour twice a year is a window nobody trusts. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-29 15:01:54 +02:00
nexxo	d4e8822dbb	Paketversionen: Verkauf wieder aufnehmen und saubere Übergabe ... Eine geschlossene Version konnte nie wieder in den Verkauf. Schlimmer: um ein Paket zu ändern, musste die laufende Version zuerst beendet werden — und wenn die Nachfolgerin dann nicht sofort veröffentlicht wurde, war das Paket dauerhaft dunkel. - PlanCatalogue::reopen() setzt available_until zurück auf null, über schedule(), damit Family-Lock und Überlappungsprüfung dieselben bleiben. Ein nie veröffentlichter Entwurf wird abgelehnt. - PlanCatalogue::publish() übergibt eine laufende Version an ihre Nachfolgerin (available_until = deren Start) statt die Überlappung abzulehnen — unter demselben Lock, in derselben Transaktion. Nur die unmittelbare Vorgängerin, und nur wenn es genau eine gibt. - Konsole: Knopf „Wieder verkaufen", übersetzte Ablehnung statt der englischen Ausnahme, und die Übergabe wird im Veröffentlichen-Formular vorher angekündigt (Version und Zeitpunkt, ->local()). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-29 14:58:11 +02:00
nexxo	ea643b5e73	Prove a custom domain before serving it, and keep proving it ... Two things. ── The update screen, still opening twice ─────────────────────────────────── Reported again on 1.3.9, and the cause was not the one fixed in 1.3.8. The agent consumes the request file BEFORE it resolves the release — deliberately, because update.sh may kill the shell and a request left in place would loop — and writes `state: running` only once it has decided to go ahead. In between, the request is gone and the status does not say running yet, so the endpoint honestly answers "nothing is running". The watcher read that as "the run has finished" and reloaded the page: overlay on the click, gone a poll later, 503 after it. The overlay now closes only once the server has BOTH confirmed a run and then stopped reporting it. Before the confirmation, silence means the agent has not got there yet. Bounded at twenty polls so a request the agent refuses does not leave the console covered forever. ── Custom domains, proven and re-proven ───────────────────────────────────── `custom_domain` was a free-text field and everything downstream believed it: the proxy served it, the certificate was issued for it, Nextcloud trusted it. Anyone who pointed any hostname at the platform got somebody else's files under their own name. The proof is a TXT record at _clupilot-challenge.<domain> holding a token only this instance has. Nothing is served until it has been read. Every reader now goes through Instance::address(), which is the one place the decision is made — `custom_domain ?: subdomain` was the hole, written out four times. It is re-read every night at 03:40, because a token checked once can be taken straight back out and a domain that later lapses keeps resolving here. Three consecutive misses before a live domain is withdrawn: one failed lookup is a nameserver having a bad minute, and withdrawing takes a working Nextcloud off its own address. The domain and its token stay on the row so the customer can put the record back rather than start over. Changing the domain mints a NEW token. Reusing it would let somebody who once verified example.com claim any other domain later without touching its DNS — the old record is still sitting there and only the value is compared. The domain is changeable at any time, and removable. Fixing it once set was considered and rejected: adding or moving an address is a proxy entry, a certificate and one line in trusted_domains. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-29 14:47:51 +02:00
nexxo	8c105c17d6	Move each plan's marketing copy from the controller into the console ... Audience line and note were LandingController::COPY, a hardcoded array keyed on exactly the four plan keys the seed migration created — a plan made under any other key rendered with no copy at all. They move onto the family for the same reason the recommendation mark does: they are a stance about the product line, not a capability that changes with a price, so they must not be frozen per version. Backfilled in the migration from the controller's own strings, so the public page prints exactly what it printed a moment ago. A family with no copy yet renders without the audience line rather than an empty gap. Feature labels (managed_updates, daily_backups, ...) stay in the controller: they name catalogue features, not individual plans, so there is no per-plan or per-version place to hang an editable customer-facing label without re-introducing a shared feature table. That table existed once and was deliberately removed when the plan catalogue closed its pricing split-brain; bringing it back for wording alone is a bigger, separate decision.	2026-07-29 14:31:44 +02:00
nexxo	17a6fabcc2	One wordmark, one typeface, and the address the server actually issues ... Reported as "logo and font are different everywhere" — maintenance page, customer panel, console, homepage. They were. Counting them up: the site header set the name in ink at -0.02em, the sidebar split it into "Clu" plus an orange "Pilot", the sign-in plate set it white at a third size, the customer two-factor page set it in MONO with no mark at all, the error pages and the placeholder each inlined their own — and the maintenance screen had no wordmark whatsoever. Nine surfaces, seven ideas of the brand. There is one now: resources/views/components/ui/brand.blade.php. Mark plus wordmark in one piece, in ink, with an optional muted "Cloud". No orange half — that made the accent a permanent fixture instead of something used sparingly. The four places that cannot use a Blade component (the two self-contained pages, the error layout, the mail layout) inline it and are held to the same shape by a test. The typeface. The console loads IBM Plex through Vite; the 503 page has no stylesheet at all, so the maintenance screen — the one page shown when somebody is already worried — was rendering in the system sans. It declares the fonts itself now. And the bold weight was missing from public/fonts entirely: the placeholder and the error pages both asked for ibm-plex-sans-latin-700-normal.woff2, which was not there. A @font-face pointing at nothing fails silently, which is why nobody noticed. The error pages carried the same two faults the placeholder shipped with: an empty gradient tile where the mark belongs, and `gap` on an inline-flex row spacing "Clu", "Pilot" and "Cloud" apart as three separate words. And the price sheet promised "Adresse auf clupilot.cloud" — a domain the company does not own — while provisioning was issuing addresses under whatever CLUPILOT_DNS_ZONE says. It is assembled from that setting now, the same reason the prices are read from the catalogue rather than typed into the page. welcome.blade.php removed: Laravel's leftover, reachable from no route. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-29 14:30:44 +02:00
nexxo	4ef5b9519c	Let the owner mark one plan as recommended, from the console ... Recommended lives on the plan family, not a version: it is a stance about the product line ("which plan we point a visitor towards"), not a capability that changes with a price, and freezing it per version would make the mark silently vanish every time a new version publishes. Setting a plan recommended clears whichever other plan carried the mark, inside one transaction locking the whole table — two operators recommending two different plans at once must not both win. The public price sheet already had the highlighted-card treatment for this (it was driven by a hardcoded "team" constant); it now reads the family instead.	2026-07-29 14:22:22 +02:00
nexxo	012d0f5092	Say EU, and stop promising to fix somebody else's deleted folder ... Two corrections from a read of the live pages. The location. Three public places named countries or a city — "aus deutschen und finnischen Rechenzentren" on the placeholder, "in Österreich und Deutschland" in the FAQ, "EU · Wien" in the product panel — and they did not even agree with each other. They all say EU now, which is the thing that is promised, the thing the AV-Vertrag pins down, and the thing that stays true when a host moves. The same string in the customer dashboard was worse: 'EU · Rechenzentrum Falkenstein' was hard-coded and shown to every customer whatever host their instance actually runs on. A specific claim nobody derived from the record. The closing headline asked who you call when a folder is missing on a Monday morning. It promised the wrong thing: what happens inside a customer's own Nextcloud is their own house — the recycle bin and the version history are right there — and presenting ourselves as the first call for somebody else's user error offers a service we do not run. It now asks who looks after updates, backups and outages, which is what the comparison section already says in the operator's own words and what the product is actually for. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-29 14:17:30 +02:00
nexxo	b843c10ec3	Give the update screen the product's colours, and only one window ... Two complaints, both correct, both mine. Dark blue. The panel carried a `prefers-color-scheme: dark` block — the only one in a product that has no dark mode. On a phone set to dark the update screen, and nothing else, turned dark blue. A dark mode for one page is not a dark mode; it is one page that does not match. It is gone. And even in daylight the panel was not this product's colours: it used Tailwind's slate ramp (#0f172a, #64748b, #e2e8f0), which is blue-tinted, against neutrals that are warm. Every value is now a copy of a token from portal-tokens.css, with the comment saying so, because this file cannot import them — it renders when the asset build may not exist. The small window then the big one. The settings card grew its own little "läuft gerade" block the instant a run started; up to three seconds later the full-page overlay covered it and said the same thing in a different size. The card no longer says it at all, and the overlay now opens on the button's own click — requestUpdate dispatches an event, but only once a run is actually pending, so a refused second press does not black out the console. Two more things found while looking: The panel had `min-height: 100%`, which resolves against the parent's height. On the 503 page the parent is <body>, whose height is auto — so it computed to zero, the panel was only as tall as its text, and the bottom two thirds of the screen stayed the browser's default white. Viewport units now, dvh so a phone's collapsing address bar leaves no strip either. And the mark was a plain orange tile again, the same empty-square that was just fixed on the placeholder. The real logo is inlined. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-29 14:11:01 +02:00
nexxo	4755a4f362	Redesign the pre-launch placeholder, and fix its wordmark and mark ... Reported from a phone on status.clupilot.com, which serves this page because the site is still switched to private. Two real defects behind the complaint: The wordmark read "Clu Pilot Cloud". `gap` on a flex container applies between EVERY child and a bare text node is a child — so an inline-flex row wrapped around "Clu", <i>Pilot</i> and " Cloud" put nine pixels between each of them. The wordmark is one element now and the gap only ever separates it from the mark. The logo was a plain gradient tile with nothing in it, which reads as an image that failed to load. That is a poor thing to leave somebody with on a page whose whole message is "we are building this properly". The real mark — cloud plus autopilot ascent — is inlined; it has to be in the file because this page renders when the asset build may not exist at all. The redesign itself: the card is gone. The page is now a centred composition on the open ground — the state as a pill above everything, the mark, the headline at the size the rest of the site uses, and the three promises the paragraph was already making set as their own line so there is something to look at besides one block of text. One warm bloom behind it, drawn as a gradient rather than a blurred disc, which banded into visible rings. Still self-contained, and still the only page exempt from the shared stylesheet: it is served mid-deploy and on a fresh install, where @vite would throw instead of rendering the reassurance somebody came for. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-29 13:43:56 +02:00
nexxo	b85df4c141	Rebuild the status page as a status page ... Asked for after looking at how real ones are built. The shape they all share is a convention, and a convention is what lets somebody find the answer without being taught the page: banner, components each with ninety days of uptime, then the written record underneath. This page had only the banner — the version that is of no use the morning after, because "Alle Dienste in Betrieb" is true and says nothing to somebody who was locked out the evening before. Three things are new. The ninety-day bar. It cannot be reconstructed after the fact: the monitoring table holds the last verdict per instance, not a history. So a sampler (clupilot:sample-status, every five minutes beside the monitoring sync) writes counts into one row per component per day, and the page divides them. A day with no row is drawn as a gap and says "nicht aufgezeichnet" — never green. Degraded samples count as reachable in the percentage but still colour the day: folding them into downtime reports a slow morning as an outage, ignoring them loses the only trace of it. The incident record. An operator reports a disruption in the console, posts updates as it develops, and the entry that says "behoben" is the same action that closes it — two separate steps is how a page ends up with a resolved note under an incident that still reports as ongoing. There is deliberately no way to edit an update: it is a statement made at a time, corrections are a further entry. An open incident may make a component look worse than the probes found it, never better. Scheduled maintenance, from the windows the console already keeps rather than a second list somebody has to remember to fill in. The measurement moved out of the controller into ServiceHealth, shared with the sampler, so the banner and the bars cannot disagree about what "healthy" means. The page now uses the shared design system and the site's header and footer. Its self-contained stylesheet was there to survive a broken asset build; it does not survive one — if the stylesheet cannot be served the application serving this page is already failing, and mid-deployment every route answers with the maintenance page. What the exemption bought was a third design nobody maintained. Found while building: durationMinutes had its operands the wrong way round, and diffInMinutes is signed, so the public page printed "Dauer -86 Minuten". Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-29 12:45:18 +02:00
nexxo	3b85e8f1d1	Grant a package or module from the customer's row in the console ... GrantPlan is a modal (R20), opened from a "Schenken" button on the customer's own row in Admin\Customers, gated by customers.grant_plan rather than merely hidden. It offers a whole package (plan, term, datacenter, an optional quota bonus baked into the frozen snapshot) or a module on an existing contract, either free or at a discount the operator sets against today's catalogue price. Existing grants show on the same modal — who gave what, when, and until when — with a warning once a dated grant is nearing its end; nothing lapses on its own, exactly as decided. The customers list also badges a granted plan in the Paket column.	2026-07-29 12:42:21 +02:00
nexxo	c71b2c362b	Skip the invoice for a full gift, keep it out of revenue, hide its price ... IssueInvoice now rejects free-grant orders before it will consume an invoice number for them — a full gift produces no invoice at all, while a discounted grant still charges something and is invoiced exactly like an ordinary sale. Keyed on the linked subscription/add-on's own provenance, not on the amount being zero, so a genuinely fully-discounted Stripe checkout is unaffected. Revenue excludes granted contracts from MRR/ARR/ARPU and the contracts count — a gift at 0 must not drag the average down — and shows their number as its own KPI instead of folding it in, since the owner measures himself on it. The portal (Cloud, Billing) shows a granted package or module without a price at all: not "free", not struck through, just the service, so a later conversion to paid does not read as a negotiation.	2026-07-29 12:41:32 +02:00
nexxo	696c8834b8	Redesign the public website instead of recolouring it ... Correctly rejected: the last pass was the old page in new paint. It kept the skeleton — eight numbered sections, a split hero, a twelve-row comparison matrix — and changed only the palette. A palette is not a design. What is actually different now: - The § numbering is gone. Numbered sections with a drawn rule are a document convention, and the document voice is exactly what the product's design system dropped. - The hero shows the product instead of describing it: centred type, then a wide panel built from the real console's own tokens, cropped by the section below. The old hero put a table of facts beside the headline, so a visitor read two columns before seeing anything. - Six identical cards, then six more, then six more became one asymmetric grid — a large panel, a dark tile, an accent tile, a wide module row — so the important thing is allowed to be bigger than the rest. - The industries are one dense two-column list instead of six cards repeating each other's shape. - The page has one dark hinge in the middle (the deployment) rather than a dark section among seven light ones. - The evidence table became rows that pair the measure with the piece of paper you can hand somebody, which is what it is for. - Prices are cards, with the full matrix folded away underneath. The matrix used to be the first thing a visitor met: twelve rows of ticks before a single price was legible. - The FAQ heading sits still while the questions scroll past it. - The footer is a real footer. The header is a floating bar rather than a full-width band, and opaque in both states — translucency plus backdrop-blur reads as a rendering fault over the dark panels that scroll under it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-29 11:43:25 +02:00
nexxo	43d58de7f8	Rebuild the public website in the shared design system ... Reported plainly: the site is still in the old style. It was — it was the last of the three surfaces the token file describes that had never been converted. landing.blade.php carried its own complete design system inside a <style> block: warm paper, IBM Plex Serif headlines, 3px corners, its own scale of greys, written before the tokens existed. Somebody who clicked "Anmelden" left one company and arrived at another. The page now draws from resources/css/portal-tokens.css like the portal and the console: same surfaces, same radii, same button hierarchy, same small-caps label, one family at weight 700 instead of a serif. What still differs is rhythm, which is what a marketing page is allowed to differ in. Content is unchanged. New: components/layouts/site.blade.php holds the header and footer for every public page, and legal.blade.php uses it too — the imprint used to be a stranded card in a third style again. Two things found on the way: - .lbl set `color: var(--muted)`, which is not a token. An undefined var() in `color` computes to `unset`, so every small-caps label on every surface was whatever colour its container happened to be. - The big figures were set in mono. Mono gives the decimal comma a full glyph cell, so "99,95" read as three separate numbers. coming-soon and the status page stay self-contained on purpose — both are served when the application may not have a built stylesheet at all. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-29 11:26:35 +02:00
nexxo	0671e8e119	Show one design while updating, not two swapping mid-run ... Reported from live: pressing update showed a blue panel first, which then vanished and was replaced by a completely different "we are updating" screen. Both were mine. The console drew its own overlay in the app's light tokens; a moment later the containers went down and Laravel's 503 page took over with its own standalone styling. One event, two faces, swapping while an operator watches. There is now one panel — resources/views/partials/updating-panel.blade.php — rendered by both. It carries its own inline CSS and cpu- prefixed class names because the 503 page is served with the application down: no compiled stylesheet, no Tailwind, nothing but what is in that file. Dark mode comes from prefers-color-scheme for the same reason. The operator detail (step, running since, log tail) rides inside the panel behind a flag, since the same file is shown to customers on the 503 page. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-29 10:20:40 +02:00
nexxo	15b536f393	Mint the archive collection key from the console instead of by hand ... Setting a NAS up to collect the invoice archive meant three machines and a dozen commands: generate a keypair there, carry the public half to the server, write it into authorized_keys with a restriction, install rsync, and get every path right on the first try. Every one of those steps was a place to be told "permission denied" with no clue which of the three was wrong. It was, and several times over. One button now. The panel asks, the host does it — because the host is where all of it lives: the home directory, ssh-keygen, rrsync, and the archive itself. The panel is www-data in a container and owns none of that, so it uses the mailbox it already uses for updates. The private half is shown exactly once, alongside the finished rsync command, and is never written to the database: it exists to be copied into a NAS, and storing it "for convenience" would put a working credential in every backup of that database. rrsync does the restricting, not a pinned rsync option string. That string differs between rsync versions and fails silently — a refusal with no reason given, which is the shape of the afternoon this replaces. If rrsync is missing the agent refuses rather than issuing an unrestricted key while the panel says it is restricted. rsync now comes with install-agent.sh, which already runs as root once per machine. It has to be on the HOST: a NAS connects by ssh and sshd starts `rsync --server` here, so without it the pull fails with "command not found" from a NAS whose own setup is perfectly correct. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-29 10:08:32 +02:00
nexxo	d8ff717cb5	Let a destination say how it is laid out and how long anything stays ... Two destinations doing two jobs. A handover directory a NAS collects from wants a folder per day and wants emptying — thirty days is enough to notice a NAS that stopped collecting, and keeping more only hides it. An archive on the NAS itself wants a folder per year and wants nothing deleted, ever. So both are per destination rather than global. Deleting is safe here in a way it usually is not, and that is worth saying plainly: the invoice is a frozen document in the database and its PDF is rendered from that on demand. Nothing is moved anywhere — it is copied, and anything removed from a directory can be produced again and re-exported. The directory is a handover point, not the record. keep_days is null by default and stays null unless somebody sets it: a retention rule nobody asked for is a deletion nobody expected. The prune only touches folders whose NAME is one of the two shapes this application writes, and leaves everything else alone — a prune that deletes what it does not recognise is how an archive loses something nobody was watching. It also skips a destination whose path is missing rather than acting on whatever is underneath an absent mountpoint. The shape is matched with a pattern before parsing rather than by handing nonsense to Carbon: under strict mode createFromFormat throws instead of returning false, so one folder somebody made by hand would have ended the whole prune instead of being skipped. The test with a foreign folder in it found that. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-29 03:08:27 +02:00
nexxo	0528b56a32	Name no vendor in the export settings ... A destination is a kind of connection, not a product. The wording said "Hetzner Storage Box" and the host field suggested one particular provider's hostname format, which reads as a requirement rather than an example — and the whole point of the directory kind is that whatever is behind it is nobody's business here. Both kinds stay. A directory is how an NFS 4.1 mount is used: the mount is made on the server, and the application writes into the path it produces. SFTP is for a destination that is not mounted. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-29 02:49:33 +02:00
nexxo	b3081a544b	Let the export have as many destinations as somebody wants ... One path and one exported_at could not say "on the office NAS, not yet on the off-site box" — which is the only interesting question once there is more than one destination, and the reason for a second is precisely that any single one can fail. A row per destination now, and a row per (invoice, destination) pair. Two kinds, and the difference is where the protocol lives. 'local' is a directory this machine can already write to: a NAS mounted over NFS 4.1, a bind mount, a disk. The application knows nothing about the protocol, the target changes without code changing with it, and the whole thing stays testable against a temporary directory. 'sftp' is for something reachable with credentials — a Hetzner Storage Box being the obvious one — and the password goes into the secret vault with only its key on the row, because a credential in a settings table is a credential in every database dump. An empty password field on an existing target means unchanged, not cleared: the field cannot show what is stored, so blank-means-delete would wipe it on every unrelated edit. One job per pair rather than one per invoice. A job writing to both would retry the one that worked every time the other did not, and report one outcome for two different things. The ordering fix the tests found: Laravel's local adapter creates its root when it is CONSTRUCTED, so the "never create the root" guard was checking a directory the disk had just made for it. It runs before the disk is built now. That guard is the difference between an archive and a hole in the ground — mkdir on an absent mountpoint succeeds, writes onto the container's own disk and reports success, and an archive that silently is not the archive is worse than none. The single path from the previous commit is migrated into a destination called "Archiv" rather than dropped. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-29 02:43:15 +02:00
nexxo	ab4b0311d4	Copy every invoice to the archive when it is issued, and notice when that fails ... The application knows nothing about NFS and should not. It writes to a directory; whether that is a local disk, a bind mount or a NAS over NFS 4.1 belongs to the mount. No protocol library, the target changes without code changing with it, and the whole thing is testable against a temp directory. The finding that shaped it: mkdir -p on a path whose mount is NOT there succeeds. It creates the empty directory beneath the mountpoint, writes the invoice onto the container's own disk and reports success — so an unmounted NAS would quietly collect invoices locally while every check said it worked. An archive that silently is not the archive is worse than none. The root is therefore never created, only used: a missing root means a missing mount, and that is a failure. Only the year subdirectory is created, inside a root already proven to exist. Written to a .part and renamed. A rename within one filesystem is atomic, so whatever watches that folder never sees a truncated PDF and takes it for a finished invoice. The size is read back afterwards rather than the write being trusted: over a network mount a short write can report success, and an archive of truncated files looks exactly like one that worked. Queued, not done during the request. A network mount can block for its whole timeout, and an invoice must not fail to be issued because a NAS is rebooting. Dispatched after the commit, or a worker could look for an invoice that has not landed yet. And copy-on-issue is not enough on its own: an invoice issued while the office connection was down never arrives, the queue eventually gives up, and nobody opens an archive to check whether last Tuesday is in it. An hourly sweep re-queues whatever is still missing, the failure is recorded on the invoice rather than only in a log, and the Finance page says how many are outstanding. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-29 02:32:08 +02:00
nexxo	33e5b15099	Restart the workers automatically after saving .env, instead of handing the operator back to the shell ... Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-29 02:26:34 +02:00
nexxo	86bf4f26e0	List issued invoices in the console, with no way to change one ... Read-only by design, and the absence is the feature: an issued invoice is corrected by cancelling it and issuing another, which is the only lawful way to correct one. There is no edit button here whose absence needs explaining, and a test asserts there is none. The PDF is a plain route rather than a Livewire action. A download is a download, and routing one through a component round-trip only adds a way for it to fail. Two findings on the way, and both were mine. The year filter used YEAR() in raw SQL, which is MySQL's. SQLite has no such function, so the page worked against the real database and threw against the test one — a query that only runs on one engine makes the test database a different product from the one being shipped. The years are derived in PHP now. And a test put a User on the operator guard, where EnsureAdmin calls isActive() on it and a 403 becomes a 500. Not a code defect: actingAs() calls Auth::shouldUse(), so a second actingAs() in the same test with no guard named lands on whichever guard the FIRST one named. That trap is written up in CLAUDE.md, I quoted it earlier today, and I walked into it anyway. The tests are split now and both name their guard. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-29 02:21:15 +02:00
nexxo	92bcdcd186	Send the invoice with the invoice attached ... The PDF is rendered when the mail goes out rather than fetched from anywhere, because nothing stores it — and rendering from the frozen snapshot means the attachment is the document as issued no matter when the queue gets to it or how often it retries. fromData rather than fromPath: there is no path. Three attempts at testing it, and the first two were wrong in ways worth recording. Attachment::$data does not exist — the closure lives in a protected $resolver, and reaching for it was me testing the framework's internals rather than my own code. And a byte comparison of the PDF cannot work at all: TCPDF embeds a creation time and a document id, so two renders of one invoice differ. Split into the two things that can actually go wrong. The mail carries an attachment with the right filename and type — that is metadata, and it is asserted as metadata. And the renderer produces a real PDF rather than an empty one, asserted where the renderer is, because an attachment closure that returns nothing still makes a perfectly valid mail with a nought-byte file on it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-29 02:13:41 +02:00
nexxo	cd54212b34	Issue an invoice from what somebody bought, and freeze it there ... One invoice per purchase rather than per order: a customer who buys a plan and two add-ons in one go has bought once, and three invoices for one purchase is three times the paperwork for the same money. Each order becomes a line, which is also how the add-ons get listed individually. Everything the document says is copied into the snapshot at the moment the number is assigned — issuer, recipient, lines, rate, the reason for the rate. A test changes the company name and the customer name afterwards and asserts the invoice still says what it said. That is the whole reason no PDF is stored. The number and the invoice commit in one transaction. A number taken and then lost to a failure is a gap in a series that must not have one, and the refusal test asserts that a rejected invoice leaves the counter where it was. It refuses outright until the company details are complete. An invoice without a registered name, an address or a VAT number is not a valid invoice here, and issuing one consumes a number that can never be handed out again. VAT comes from TaxTreatment, which already existed and already handles a verified EU VAT ID correctly — including the reverse-charge note, without which a zero-rated invoice says nothing about why no VAT was charged. The billing address is carried as the lines it was written as. It is one free-text field today, and guessing which line is the postcode would put it where the street belongs, on a document nobody can correct afterwards. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-29 02:09:05 +02:00
nexxo	4646880b90	Print every line at full price and take the discount off once, in euros ... Second correction to the same block, and this one came from the right place: a line reading 202,50 beside "Rabatt 10 %" does not say whether the discount is in that number or still to come. It was unreadable, and unreadable on the one figure a customer checks. Lines are at full price now. Discounts are still entered per line — that is where they belong and where somebody decides them — but they are summed and shown once, in euros, under a subtotal that the "Gesamt netto" column adds up to. Subtotal, one subtraction, VAT, total: a sum anybody can follow without being told which figures are already adjusted. The gross line-total column is gone and a gross UNIT price takes its place. Full-price gross totals would sum to 315,60 against a total of 288,60 — the same contradiction in a different column. Nobody adds up unit prices, and a consumer reading this wants to know what one of the things costs. lineTotal() and adjustmentLabel() went with it. Nothing calls them any more, and a helper kept for a layout that no longer exists is the next person's wrong turn. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-29 01:59:56 +02:00
nexxo	d21e4f0eb2	Put a discount on the line it belongs to, so the columns add up ... With one discount applied under the table, the gross column summed to 315,60 against a total of 284,04. Nothing was miscalculated — the discount simply came after — but a reader who adds up a column found a document that does not agree with itself, and no way to tell which figure was the real one. On an invoice that is not a presentation detail. A discount or surcharge now sits on its line, percentage or fixed amount, and is inside that line's total. The label under the line is built from the same value that did the arithmetic, so the words cannot end up describing a different number than the one printed beside them. The invoice-wide adjustment stays in the arithmetic for anything that genuinely applies to the whole document, but nothing uses it by default. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-29 01:52:16 +02:00
nexxo	90131f088a	Add a raw .env editor to the Integrations page, with a net under it ... Everything the console has no field for is still real — MAIL_*, DB_*, APP_KEY, whichever key nobody has built a form for yet — and without a way to touch it from here, the operator needs a shell and the console page misses its own point. EnvFileEditor is the net, not just the warning: 1. Validates before writing. A line that is neither blank, nor a comment, nor KEY=value is rejected outright, and an empty file (syntactically "valid" by that rule, but not survivable) is refused too. write() never touches the file before checking the new content. 2. Backs up before every write that actually happens — a timestamped copy beside .env, before the new content lands. Never pruned automatically; the page says so, next to where it says where they land. 3. Names the keys a mistake here can lock an operator out with — APP_KEY, DB_*, REDIS_*, SESSION_* — rather than a blanket warning nobody reads. 4. Gated by secrets.manage and the same confirmed password the vault entries use — this is the one place on the page that can reach every credential the vault otherwise keeps write-only. 5. Says plainly what saving does not do: queue, queue-provisioning, scheduler and reverb only read .env at their own startup, and names the restart command plus config:clear. 6. Marks which .env keys SecretVault currently overrides, so editing a line that a stored vault value already shadows does not look broken. Two issues surfaced by Codex review and fixed before this commit: the raw file content stayed in the Livewire component snapshot after the password confirmation window expired on its own (not only on an explicit re-lock), and the first save on an installation with no .env yet failed trying to back up a file that was never there. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-29 01:51:27 +02:00
nexxo	3fadaa14b0	Merge credentials and infrastructure into one Integrations page ... Zugangsdaten and Infrastruktur split the same subject by storage mechanism — SecretVault vs App\Support\Settings — instead of by what each field configures, which is not a distinction an operator setting up Stripe or DNS should have to know or care about. One page now, grouped by integration: Zahlungen (Stripe), DNS (Hetzner), Monitoring, VPN/WireGuard, SSH-Identität. A secret and a plain setting sit side by side within a section; the difference stays visible — a vault entry is write-only and shows only an outline, a setting shows its value in full — as a property of the field, not a reason for a separate page. Both storage mechanisms are unchanged underneath: this is a presentation change, not a data migration. The vault keeps its own gate (secrets.manage + a recently confirmed password); plain settings keep theirs (hosts.manage alone). Reachable with either capability, since the two are no longer two pages a role happens to see one, both, or neither of — every section and every save action still checks its own capability server-side. admin.secrets and admin.infrastructure redirect here permanently rather than 404ing a bookmark. The nav entry that replaces both is visible to either capability — Navigation's capability field now accepts an array meaning "any of these", not only a single ability. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-29 01:49:39 +02:00
nexxo	f8c923b48a	Stop the invoice printing my own indentation ... TCPDF takes leading whitespace in HTML literally, so every line of the address and every line description came out indented by however far the Blade template happened to be nested — and the one line that had no indentation, the VAT number, sat flush against the margin looking like the mistake. It was the only correct one. Also puts the title and the invoice number in one block. As an h1 with a paragraph beneath it, TCPDF gave the heading a margin of its own and the two drifted a centimetre apart. Found by rendering the page and looking at it, which is the only way any of this is ever found. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-29 01:45:55 +02:00
nexxo	c1896e70fc	Render an invoice, with the arithmetic held to integer cents ... TCPDF 6, deliberately, after installing 7 and finding out what it is. Version 7 is not a newer TCPDF; it is a compatibility shim over tc-lib-pdf whose own mapping table lists 115 of 293 methods as stubs, and whose font package ships no font files at all — the first render died on a missing helvetica.json. The 6.x line carries a hundred and sixty-five fonts, a working writeHTML and real header and footer hooks, and is what everybody means by TCPDF. The body is a Blade template handed to writeHTML rather than a hundred Cell() calls with millimetre coordinates, because this table has to be adjusted the first time somebody sees it on paper, and nobody adjusts the second kind. InvoiceMath is integer cents end to end, and rounds once. A percentage applied line by line and rounded each time drifts from the same percentage applied to the sum — three lines at 3,33 € less 10 % is 99 cents that way and 100 cents the honest way, and the customer's calculator is what finds it. Gross is always derived from net and never the reverse: taking VAT back out of a gross figure returns a different number often enough to matter. A discount and a surcharge are one operation with opposite signs, so nothing has to remember which of two flags means which. Quantities are thousandths, because hours, gigabytes and part-months are all real, and are printed with the trailing zeroes stripped — "12,000 Std." reads as a defect. Every line shows quantity, unit price net, total net AND total gross: this goes to businesses and to consumers, and each reads a different column first. Verifying it took two goes and both failures were mine. `strings` over a PDF set in a Unicode font finds nothing, because the text is stored as subset glyph ids — the check has to render in a core font to be a check at all. And two of the strings I then declared missing were simply expectations I had got wrong. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-29 01:41:46 +02:00
nexxo	77bd30ca56	Answer on every name for the website, and send them all to one ... SITE_HOST takes a comma-separated list now, the first name canonical. It serves the site; every other name in the list redirects there permanently, path and query intact. An apex domain and its www are two names for one thing, and answering on both without picking one splits search rankings and cookies between them. The redirect is a host-bound catch-all rather than middleware. Middleware that only some routes carry is the same half-measure this file already made once, and a catch-all registered without a host would swallow every path in the application — which is what the third test is there to stop. The test harness needed fixing too, and the fix is the finding. Router::dispatch on a standalone router does not rebind the container's request, so a route reading one — through the helper OR through an injected parameter, both of which resolve from the container — gets the test's request rather than the one being answered. The redirect silently lost its query string in the test while working in production. dispatchOn() binds it where the framework would. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-29 01:29:33 +02:00
nexxo	e6d2e6dc33	Give the console a Finance tab: company details, VAT rate, invoice series ... Its own tab rather than a section of Settings, as asked. What is set here appears on a legal document, and burying it beside the site-visibility switch invites somebody to change one in passing. Everything the printed invoice needs — registered name, address, Firmenbuch number and court, VAT ID, bank details, payment terms, logo — with the logo replaceable, because a company changes its mark. None of it reaches an invoice that already exists: the values are copied into each document when its number is assigned, so a corrected address is correct from the next one onwards and cannot rewrite an old one. The console refuses to consider itself ready while a name, an address or a VAT number is missing, and says which. An invoice without them is not a valid invoice in Austria, and issuing one is worse than refusing to. The series editor carries the same shape as EditDatacenter and for the same reason. The prefix is free while the series is empty and frozen once a document carries it: changing RE to AR renames nothing and leaves a series whose past says RE and whose future says AR, with no record they belong together. The counter may be raised — an operator migrating from another system needs exactly that — but never lowered, because a lower number is one already printed on a document somebody holds. Both rules are recomputed from the database on save rather than read back from the properties the browser returns. CompanyProfile drops keys that are not part of the profile. It is fed from a form, and a forged key must not be able to write an arbitrary setting into the same table the site-visibility switch lives in. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-29 01:18:43 +02:00
nexxo	864126ec7f	Add the SSH identity to the vault, and give deployment config a console page ... The SSH private key CluPilot deploys to every host is now stored through SecretVault (ssh.private_key), preferred over CLUPILOT_SSH_PRIVATE_KEY(_PATH) at all three real consumers — SshTraefikWriter and HostStep::keyLogin. kuma.password/kuma.totp stay in .env: they authenticate a separate Python container at boot, and nothing in this app reads them, so the vault would have nothing to wire them to. A new /admin/infrastructure page, backed by App\Support\ProvisioningSettings, makes the non-secret deployment settings that used to force a shell — DNS zone, WireGuard hub endpoint and public key, Traefik's dynamic-config path, the SSH public key, and the monitoring bridge URL — visible and editable from the console, each wired to every real consumer. WG subnet/hub IP and Kuma's own connection details stay in .env: the compose file and a separate container read those before this application ever does.	2026-07-29 00:52:44 +02:00
nexxo	7a5a71dc89	Read VPN host state from the synced peer table, not a live hub call	2026-07-29 00:18:21 +02:00
nexxo	b1ab0f7f31	Put every mail in one design, and confirm an order when the money arrives ... Four templates, one layout. Two of them — the maintenance announcement and its cancellation — still wore Laravel's markdown component, which brings its own logo, its own button and its own footer: the product was sending mail that looked like two different companies, one of which was the framework. New: an order confirmation, sent when the payment lands rather than when provisioning finishes. Those are minutes apart at best and can be much longer, and somebody who has just been charged and heard nothing assumes the worst about both the charge and the product. It deliberately promises no time for the cloud itself — provisioning takes what it takes, CloudReady announces the end, and a promised minute that slips is worse than no promise. Queued after the transaction, never inside it, and never allowed to fail the webhook: Stripe retries anything that is not a 2xx, and a retry would re-enter provisioning over a mail server having a bad minute. The finished-cloud mail now names what was actually built — address, plan, storage, location — because somebody who ordered a fortnight ago is checking it against what they bought, and that is a comparison rather than a sentence. Still no credential in it. Two tests earn their place. One holds every template on the shared layout, so a new one written in a hurry cannot copy-paste its way back to the framework's. The other proves the finished-cloud mail carries no password — asserted against the data the mail is given and the HTML it renders, not against the template's source, because the first version of that test tripped over the word in a comment and would have passed a template that leaked the value through a variable. It tested the prose, not the mail. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-29 00:14:04 +02:00
nexxo	eb743d34ed	Show WireGuard tunnel state per host in the hosts list	2026-07-29 00:10:15 +02:00
nexxo	5b8c28595a	Require a confirmed address before an account can use anything ... Registration opened an account that could sign in immediately on an address nobody had proved was theirs — and anybody can type a stranger's into a registration form. Both halves were commented out: the Fortify feature and MustVerifyEmail on the model. `verified` sits on the whole portal group rather than on the pages that spend money. An unconfirmed address is not a billing problem to be caught at checkout; it is an account that may not belong to the person holding it, and the servers, the users and the backups behind it are worth as much to whoever typed the address as to whoever owns it. The mail is a Mailable in this product's design rather than Laravel's notification, which would arrive with the framework's logo, button and footer as the first thing anybody ever receives from CluPilot. It also has to leave through the SYSTEM mailbox like every other account mail, which the notification path does not do on its own. The link is signed and expires, and the address is part of what is signed — so a link issued to a mistyped address stops working the moment the address is corrected, rather than confirming an address nobody can read. Tests cover the tampered link, the expired one, the corrected address, and one account trying to confirm another. The waiting page is ours (Fortify has views off) and offers the only two things that move somebody forward: send it again, or sign out and register with the address they meant. The resend is throttled, because otherwise it is a button that makes the server send mail to an arbitrary address as fast as it can be clicked. Somebody already confirmed is redirected away from it — the `verified` middleware only guards the other direction. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-28 23:43:20 +02:00
nexxo	07141a96bf	Show where an account is signed in, and let it sign the other places out ... Completes the device work: the warning mail now has somewhere to send people. A warning whose only advice is "if this was not you, take action" names a problem and hands back nothing to do about it. Both sides get their own component rather than one shared with the guard passed in. Operators and customers are two guards and two tables (R21) — a component taking the guard as input is one forged property away from listing and ending the other side's sessions. Every query in SessionRegistry is scoped by guard as well as by id for the same reason, and three tests hold that line, because the unscoped version looks exactly like a working feature while doing it. TouchLoginSession keeps each row pointing at the session it describes. Both sign-in paths raise the Login event BEFORE session()->regenerate(), so the row is written against an id that is dead a moment later — and the once-a-minute throttle would have held the correction back for the first minute of every session, hiding the session its reader is sitting in. A changed id is therefore never throttled. A session counts as live only if the framework's row exists AND was touched within the session lifetime. The join alone is not enough: Laravel collects expired sessions by lottery, so on a quiet installation rows sit there for days and the list would offer somebody a laptop they shut last month. Ending the others goes through the product's own modal (R23) and leaves the asking session alone: signing somebody out of the page they are using to sign other people out is not what the button says. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-28 23:38:17 +02:00
nexxo	2609393e3a	Recognise the devices an account signs in from, and warn about a new one ... Sessions lived in Redis, where they cannot be enumerated — one key per session, no index by user — so "where am I signed in" and "end that one" were not answerable at all. The database driver keeps a row per session and makes ending one a delete. It costs every currently signed-in person one forced sign-in, once, which is why it is happening now rather than later. The warning is only worth anything if it is rare, so the two obvious signals are deliberately not used. Not the IP: it changes on every train, every café, every mobile handover, and behind a VPN it is not theirs to begin with. Not the user-agent: Chrome ships every four weeks and the string changes each time, which would be twelve warnings a year per customer, describing nothing. A device is a long-lived signed cookie holding a random token, and nothing else is consulted. The honest cost — cleared cookies, a private window, a second browser — is written into the mail itself, because a reader who thinks the warning is wrong stops reading the next one. Three things the tests found or hold: The first device on an account is new and must not warn. Replying to somebody creating an account by telling them they signed in from a new device is noise on the one message that has to stay worth reading. token_hash was globally unique, and the shared-browser test failed on it. Two people on one machine share one cookie and must each own a device row against it; the obvious repair — issue a fresh token for the second — would orphan the first person's row and warn them about their own desk. Unique is now per identity. Recording a device may never block a sign-in. A safeguard that locks the owner out when it breaks has stopped being one, so the listener logs and swallows, and a test drops the tables to prove it. Sessions are linked by a uuid carried inside the session payload rather than by the session id, which Laravel rotates on every sign-in and every regenerate(). Laravel's own sessions.user_id cannot carry the link either: it is filled from the default guard, while operators and customers are two guards and two tables (R21) — operator 1 and customer 1 would each be offered the other's sessions. Also lands the shared mail layout the rest of the templates will use: tables and inline styles for Outlook, no image and no web font because half of all clients block remote content, and the button in --accent-active rather than the brand orange, which is 2.9:1 against white. Not tagged: the session list is not built yet, and without a tag no server can install this. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-28 23:28:34 +02:00
nexxo	75b4a47768	Stop mailing the initial admin password, hold it in the panel until noted ... The password no longer travels through third-party mail servers or sits forever in an inbox: it moves onto the instance (encrypted, same as nc_admin_ref) and shows on the dashboard until the customer clicks "Notiert", which deletes it for good.	2026-07-28 23:19:20 +02:00
nexxo	21b7aaca42	Update only to a released version, never to whatever landed on main ... Asked for directly: a commit on main must change nothing on a server, and only a tag whose version is higher than the installed one may be installed. The agent asked two different questions before this. A pinned server compared tags; everything else counted commits on its branch — so a console following main offered an update for every push, verified or not, and "Jetzt aktualisieren" meant "take whatever is on the branch right now". Landing on main and being released are different events, and only the second is a decision somebody made. It is one question now, regardless of what the checkout is attached to: is there a tag whose version is higher than the deployed one? Compared with sort -V against the version in the deployment manifest — not the VERSION file, which an update moves before it migrates, so a run that failed in between would leave the checkout claiming a version it never finished installing. A run always targets that tag; the branch path is gone. A request that arrives with nothing to install is answered rather than obeyed, before anything announces a run. The console follows: the button is disabled with nothing released, says so in a line rather than leaving a grey button to be guessed at, names the version it would install rather than a count, and refuses the action server-side as well — a Livewire action is a public endpoint, and one place a rule may not live is only in the disabled attribute of a button. VERSION becomes 1.1.0, to be tagged as the first release this mechanism can see. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-28 22:32:44 +02:00
nexxo	184350494d	Let a half-finished two-factor enrolment be cancelled, and rework the setup page ... Found uncommitted in the working tree at the start of this session and carried in as its own commit so it can be reverted on its own. Not written here: a cancel action that clears an unconfirmed secret, the wording for every state of the page, and a rebuilt setup view. The suite is green with it in place, including the R18-R23 scan tests.	2026-07-28 22:25:27 +02:00
nexxo	d65ab71029	Let a datacenter code be corrected while nothing depends on it, and say which building ... The code was immutable, which made a typo permanent. It cannot be freely mutable either, and not only because hosts.datacenter references it: each host's DNS name was minted from it and registered at the provider, the machine's own hostname was set from it as it was built, the counter handing out those numbers is keyed by it, and every past order stores it as plain text with no foreign key to follow. Renaming a code with hosts in it is not a rename — it is a datacenter called hel full of machines called fsn-01. So it is editable exactly while nothing references it, which is the case that matters: a typo noticed shortly after creating one. Once a host or an order depends on it the field is disabled and says what is holding it, with the numbers. The lock is recomputed from the database on every save, never read back from the property the browser returns. Alongside it, an optional free-text field for the specific datacenter — fsn-dc-15. A provider runs several within one location, on separate power and separate uplinks, and two entries both reading "Falkenstein (fsn)" are not a choice anybody can make. Nothing keys off it; the code remains the identifier. Also renames the country loop variables in the edit modal. They were $code and $name — the component's own properties — and shadowed them for the rest of the file. Harmless while nothing below the loop read them, which stopped being true the moment the code became an editable field above it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-28 22:25:21 +02:00
nexxo	07634c8a1d	Answer a check at once, start an update at once, and count down to neither ... Checking for updates was a request written into the same mailbox as a real update, collected by the same agent on the same systemd timer — so asking what was new was answered on the next tick, and the console, having nothing else to show, counted down to it. An operator who asked a question was told an update would start in 3:44. A systemd path unit now wakes the agent the moment the request file is written, for a check and for a run alike. PathChanged, not PathExists: PathExists re-arms as soon as the service goes inactive, so a request the agent could not consume — it holds a lock for the length of an update — would restart it in a tight loop. The timer stays as the fallback, and a drop-in disables systemd's start rate limit, because two triggers on one oneshot service can otherwise wedge the unit and leave neither of them able to run. The countdown is gone from both the settings card and the maintenance overlay. It could not be made honest: its target was recomputed on every poll, and where the interval the agent reports is shorter than the timer actually installed on that host it had already gone by, so the fallback moved it forward again each time. It ran backwards four seconds and snapped back to a full minute, forever — reported exactly that way. A queued run says it is starting; a queued check says nothing beyond its badge, because a check starts nothing. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-28 22:25:07 +02:00
nexxo	64efe45f0d	Recover silently from an expired session, and show a connection banner when offline ... Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-28 21:36:21 +02:00
nexxo	bda61ca560	Pin the sidebar header and footer so only the nav list scrolls, and shorten two action labels that wrapped	2026-07-28 20:52:12 +02:00
nexxo	f05547921d	Separate checking for updates from applying them, and show live progress	2026-07-28 20:23:06 +02:00
nexxo	973fcb3f2d	Replace native confirm() dialogs with the app's own modal pattern	2026-07-28 19:34:27 +02:00
nexxo	c2681f2801	Show a full-screen overlay on every console page while an update runs ... Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-28 18:50:45 +02:00
nexxo	254674f456	Bound the mail test-send and real send to a timeout instead of hanging ... A blocked outbound port (587 filtered at a firewall, as on the live server) left both MailboxTester and MailboxTransport blocking until PHP's default_socket_timeout (60s) or the reverse proxy cut the request — a 504 with no error the operator ever saw. Mail::build() honours a 'timeout' config key by calling SocketStream::setTimeout() (confirmed by reading MailManager::configureSmtpTransport() and by an end-to-end run against a genuinely unroutable host), so MailboxTester now passes 'timeout' => 10 through it. MailboxTransport builds its EsmtpTransport directly rather than through Mail::build(), so it sets the same call on the transport's stream, at 30s — a queue worker can afford to wait longer than an operator watching a browser, and a timed-out send is retried rather than lost. The test button also now shows a visible "sending" state while the request is in flight, matching the wire:loading span pattern already used on admin/host-create's save button — previously only wire:loading.attr="disabled" fired, leaving a greyed-out button with no other sign anything was happening. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-28 16:36:14 +02:00
nexxo	27292237c3	Move operator two-factor enrolment off admin.settings onto its own page ... RequireOperatorTwoFactor exempted the whole of admin.settings while compulsory two-factor was on, on the theory that it was "the page where two-factor is set up". That component also carries staff management, site visibility, network restrictions, account changes, and the two-factor policy switch itself, so an unenrolled operator got unrestricted access to all of that, not just enrolment. Enrolment (secret, QR, confirm, recovery codes, regenerate, disable) moves to its own route and component, admin.two-factor-setup / Admin\TwoFactorSetup, reachable by every operator regardless of capability. That is now the only page the middleware exempts besides logout, and its redirect points there instead. admin.settings goes back behind the policy like every other console page; only the policy switch itself stays there, since only someone who already satisfies it should be the one changing it.	2026-07-28 15:11:20 +02:00
nexxo	20329b176b	Refuse a portal login for an address that already belongs to an operator ... Customer::ensureUser() enforced uniqueness only within users, so a customer provisioned (or registering publicly) with an operator's email got a second, colliding identity for the same address — the exact thing R21 exists to prevent. Checks Operator by address now, not by session (the deleted assertNotAdmin() checked who was signed in, which could never be the right question). Public registration gets the same guard via a plain unique() validation rule, reusing Laravel's stock "already taken" message rather than a dedicated one — naming the collision specifically would tell a public visitor an address belongs to staff, a worse leak than the generic refusal every other collision here already gives them. Impersonation answers 409 instead of crashing into it. The Stripe webhook keeps recording the paid order (same principle as openContract()'s own comment: the order is proof money changed hands) and withholds only the colliding login, logged for an operator to resolve by hand. Verified the reverse direction Codex flagged as already covered: two Admin\Settings actions and the clupilot:create-operator command all already refuse an operator email that collides with a customer's, and that check is sound today because every users row is created in lockstep with a customers row of the same email (CreateNewUser and ensureUser are the only two creation sites, both confirmed by grep) and nothing in this app can change a user's email afterwards (Fortify's updateProfileInformation feature is disabled, and no other code calls that action).	2026-07-28 14:42:16 +02:00
nexxo	913d19d39c	Give operators somewhere to actually set up two-factor ... console.require_2fa exempted admin.settings from the redirect it forces on an unconfirmed operator, but that page only ever configured the global policy — nobody could enrol behind it. A newly invited operator stayed permanently redirected to a page with no way to satisfy the requirement, the opposite of what the switch was for. Adds enable/confirm/regenerate/disable to Admin\Settings, reusing Fortify's own actions exactly as the portal's Settings already does — they only ever touch the model they're handed, no guard or auth() call inside them, so pointing ConfirmsPassword's guard at 'operator' is the only change needed. The new card is deliberately not gated behind the site.manage capability that hides the rest of this page's Owner-only sections: the compulsory switch applies to every operator, so enrolment has to be reachable by every operator too. Dropped the account card's stale hint pointing at a "separate security area" that never existed.	2026-07-28 14:21:02 +02:00
nexxo	e519653f66	Let the owner make two-factor compulsory, without locking themselves out	2026-07-28 12:08:08 +02:00
nexxo	3f318c3f6a	Give the console a front door of its own	2026-07-28 11:45:22 +02:00
nexxo	87c49de6e5	Move the console's identity out of the customer table	2026-07-28 10:31:43 +02:00
nexxo	2a06b5dfb2	Say EU and stop there, as the approved template does	2026-07-28 09:19:24 +02:00
nexxo	5d306fce31	Let a mailbox send without a password when it never needed one ... An SMTP relay with a host and a from address but no username or password - a trusted local or private-network relay - always used to be seeded as a placeholder, because the takeover required a username to treat an account as real, and Mailbox::isConfigured() always required a stored password. Laravel's own SMTP mailer has supported unauthenticated relays all along. Add mailboxes.authenticates (default true, so every existing row keeps its current behaviour) to tell "does not authenticate" apart from "authenticates, but nobody has typed the password yet" - the same empty password column used to mean both. The takeover migration now seeds the real account off the host/address alone and marks it authenticates=false only when neither a username nor a password resolved; isConfigured(), MailboxTransport and MailboxTester all read it before requiring or sending a password; the edit modal gets a checkbox for it with the password field's hint updated to match, in both languages.	2026-07-28 05:54:21 +02:00
nexxo	5de1f45703	Close two ways a mail.manage session could take over outgoing mail ... I3: nothing stopped an operator unchecking Aktiv on the mailbox that mail.purpose.system points at. MailboxResolver::active() filters an inactive mailbox at BOTH the direct lookup and the system fallback, so that one checkbox could take mail.purpose.system to null and every purpose without its own mapping down with it — the existing system_required guard on savePurposes() reads as if this were covered, but it only blocks the empty-mapping path, not this one. EditMailbox::save() now refuses active=false against the mailbox 'system' currently points at, the same way savePurposes() already refuses to leave 'system' empty. I4: Admin\Mail::saveServer() writes mail.host — the platform's outbound relay for every purpose mailbox at once — and CloudReady::toMail() puts a customer's Nextcloud admin password in cleartext in the message body. So a signed-in mail.manage session was already a credential-interception primitive, the same threat Admin\Secrets' second gate exists for. Both saveServer() and EditMailbox::save() (only when a new password is actually being typed) now also require passwordRecentlyConfirmed(), following the ConfirmsPassword pattern Secrets.php and Settings.php's two-factor actions already use — including their per-action UI shape (an inline confirm form scoped to the gated action), not a whole-page lock, so address, display name, username, no-reply, active and the purpose mapping stay reachable without confirming, per the brief's capability split. Both gated and ungated paths are covered by tests, and both guards were mutated away and confirmed to fail before being restored.	2026-07-28 03:50:19 +02:00
nexxo	befb67327f	Prove a mailbox works by actually sending from it	2026-07-28 02:56:47 +02:00
nexxo	4211f3dfab	Give the mailboxes a page, and the support sender its own capability	2026-07-28 01:57:11 +02:00
nexxo	9b8d5dfd1e	Editing in modals, an update button that is not gated on a stale reading, and a support page that is real ... Three things reported together. ── Editing belongs in a modal (R20) The seats table grew its input fields into the row. It worked and it looked broken: the row grew, the columns beside it jumped, and a table half in edit mode reads as a rendering fault rather than as a form. The project already had the answer — EditDatacenter, whose own header comment says it avoids exactly that row-height jump — and the seats table simply did not use it. EditSeat is now a ModalComponent. A modal is reachable WITHOUT the page's route middleware, so it resolves the customer itself and re-reads the record rather than trusting a hydrated property: a forged addressEditable would otherwise open the address of an accepted seat, and the address is the person — editing it hands one employee's access to another with nobody told. Only an invitation still in flight can have its address corrected, which is the case that actually comes up. The actions column is now always drawn. It used to disappear when the only seat was the owner, on the reasoning that there was nothing to act on. But every seat can be renamed, and a column that vanishes does not read as "not applicable here" — it reads as "this product cannot do that", which is how it was reported, three times. The owner's row says "Geschützt" rather than leaving an empty cell. Also caught here: the edit fields carried class-wide #[Validate] attributes, so an empty edit form made the INVITE button fail on a field the invite form does not have. Rules for an action belong to the action. ── The update button "I cannot run an update, it says everything is current." `behind` is a READING taken by the agent every five minutes, not the state of the world — push a commit and the console insists it is up to date and refuses to act. The agent does its own fetch before deciding, so asking against a stale reading costs one fetch and finds nothing; being locked out costs the deployment. The button is now offered whenever an agent is alive and no run is in flight, labelled for what it does rather than for what the last reading said. ── The update never announced that it had finished Because the thing being watched restarts the thing doing the watching. Mid-run every wire:poll request fails, and what answers afterwards is a new build being questioned by the old page's JavaScript — so the card sat on "läuft" until somebody reloaded by hand. A small Alpine watcher now asks a plain JSON endpoint (no Livewire, no component state, no assets), treats a failed request as the restart rather than as a fault worth giving up over, and reloads once the build it is looking at is no longer the build it started with. ── Support The page was a decorated placeholder: a button that raised a toast saying the form was "only hinted at in the prototype", three invented ticket titles living in the translation file, and no way to see what became of anything. It looked thin because nothing on it was real. It now leads with the customer's own requests — what somebody arriving here wants to know is what they asked and whether anyone answered — with contact details moved to the side where they belong. The form attaches the plan, the instance and who is asking automatically: making a customer describe their own server back to the people who built it is the part of support people hate. FAQ answers end where the thing can actually be done, and "is it me or is it you" is answered by a link to the status page. 637 tests. R20 recorded in CLAUDE.md and enforced by EditInModalTest: no page view may grow an input field inside a <td>. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-27 17:55:49 +02:00
nexxo	bd779f00e5	Show times on the operator's clock, keep storing them in UTC ... The console announced an update for "spätestens um 15:21" while the clock on the wall said 17:21. Not a formatting slip in one string: fourteen views and four components printed database values straight out, so every absolute time in the product was two hours out all summer and one hour out all winter. Two of those views looked as though they had handled it. They called ->timezone(config('app.timezone')) which reads like "convert to local time" and, app.timezone being the STORAGE zone that must stay UTC, converts to UTC — a no-op wearing the costume of a fix, which is worse than no call at all because it stops the next person looking. That exact string is now banned by test. Worse than the labels were two FORMS. Maintenance windows and plan versions filled their datetime-local fields from UTC and parsed what came back as UTC. A datetime-local field carries no offset — it is the digits a person reads off their own clock — so an operator typing 21:00 scheduled a window for 23:00 their time, and nothing anywhere said so. App\Support\LocalTime now holds toField() and fromField() side by side, because getting one end right is not half a fix, it is a fresh bug. The mechanism is one Carbon macro, ->local(). It copies before converting: Illuminate\Support\Carbon is mutable, so without that, rendering a timestamp would rewrite the model attribute as a side effect and anything comparing or saving it afterwards would be an hour or two out. Both Carbon classes get the same body — Carbon keeps macros in one global table, so the second registration replaces the first for every Carbon class, and two different bodies meant the immutable version, safe for itself, silently became the mutable one's implementation too. My own test caught that. The existing tests had not caught any of this because they built their expected values with the same wrong call the views used — a test that recomputes the implementation asserts nothing. They now assert the wall clock, and the queued update additionally asserts that the UTC time is NOT shown. Recorded as R19 in CLAUDE.md and enforced by tests/Feature/DisplayTimezoneTest: no Blade or Livewire component may format an absolute time without ->local(), the UTC no-op is banned, storage stays UTC, both sides of the DST boundary are checked, ->local() must not mutate, and a form field must round-trip to the same instant. APP_DISPLAY_TIMEZONE, default Europe/Vienna. 615 tests. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-27 17:32:21 +02:00
nexxo	435a202fdd	Match the panel to the approved template, measured rather than assumed ... The panel had been built by reading the template and believing the result. Every round of review found the same class of defect, so this round the template was rendered in a browser and measured with getComputedStyle, and the implementation measured the same way — two number columns instead of an opinion. That immediately settled a disagreement: a review of the template's SOURCE said the metric grid used a 20px gap. Rendered, it is 14px. The measurement wins. Brought to the template's figures: label 11.5px (it was 11px in three separate places, which is how it drifted — it is now one .lbl rule), value tracking -0.02em, unit weight 450, metric row 6px above and 14px between, page head centred with a 14px gap, grid gap 14px, columns switching at 1101/561px and the h1 at 901px to match the template's own breakpoints, ring 62px, bar 5px. The shared button now takes its height from min-height (40px) rather than vertical padding, at 14px/600 with 0 18px padding and a 10px radius — a button keeps its height whatever sits inside it, icon, spinner or bare text. Also here, from the same round of review: - The chart's blue border was Tailwind's own `ring` utility colliding with a component class of the same name. Renamed to `.metric-ring`. This was dismissed once as a screenshot artefact; it was real. - Page titles lost the `sm:text-3xl` (40px) an earlier bulk edit had appended to 23 of them. The template's h1 is 30px. - The users table has its actions back — edit, suspend, lock and delete — for every seat that is not the owner, with the owner refused in the action itself and not merely hidden in the markup. DemoCustomerSeeder writes one complete customer as real rows: instance, subscription, six seats across four roles, a backup, current-period traffic and thirty days of samples with a deliberate wobble and one day at 286/288 checks. Nothing in the panel is drawn from a fixture any more, so anything missing shows up as missing. Removing the demo is one deletion. Verified: 607 tests, and a Codex comparison of the two measurement sets — "a person would call them the same design", the only difference a 1px gap. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-27 17:08:05 +02:00
nexxo	85fcc154b8	Measure availability, and let a customer move down again ... Availability is now counted from our own monitoring answers. Uptime Kuma knows the figure, but the REST bridge in front of it only answers "healthy, yes or no", and waiting for the bridge to grow an endpoint would have left the panel without the number indefinitely. The sync already asks on a schedule; counting the answers gives a percentage that is ours and explainable. An unanswered check is not a failed one — the counter only moves when a real answer arrived, so our monitoring going down does not become the customer's outage on the one figure they are asked to trust. An instance nobody has ever checked shows no availability rather than 100 %. The downgrade path existed nowhere. Going down is not the mirror of going up: it can ask an instance to hold more than the target plan allows. Smaller plans are now listed even when they cannot be taken, with the obstacle in the customer's own numbers — "you have 31 users, this package allows 10" — because a greyed-out button that does not name what is in the way is the thing people ring about. Storage is checked against the last real reading rather than the contractual allowance, or anyone who once bought a large plan could never leave it. The limit is re-checked in the action: a rule enforced only in markup is not enforced. And the smaller corrections from this round: - The cloud tab carried a hardcoded "B" as the instance's initial, and the PHP and MariaDB versions, which tell a tenant nothing they can act on. - "EU — Serverstandort im Angebot festgehalten" under a label already reading "Serverstandort" was two sentences saying nothing. It is the country. - Support promised a reply "binnen 4 Std." with nothing behind it. What is true everywhere else is an answer on the same working day. - The actions column appeared even when no row in the table had an action. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-27 16:41:15 +02:00
nexxo	ee5e92c0ed	Measure what the template draws ... The panel could not show the storage ring or the transfer trend because nothing measured them. instance_traffic keeps one row per billing period — right for an allowance, useless as a series — and storage consumption was never sampled at all, so the card could only ever state what was sold rather than what is used. instance_metrics holds one row per instance per day, written by the traffic collector on the visit it already makes. A second scheduler entry against the same Proxmox API would have doubled the load and the failure modes for no gain. Disk usage comes from `df` inside the guest rather than from Proxmox's own disk figure, which reports the allocated image: that would show every customer a full 500 GB from their first day. The rule the whole thing is built on: a reading that could not be taken is not a reading of zero. The disk columns are nullable and left untouched when the guest agent does not answer, so yesterday's figure stands instead of the ring dropping to empty — which would tell a customer their data had vanished. Missing days stay missing in the series rather than being filled with zeroes, which would draw an outage that never happened. Both are covered by tests. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-27 16:29:28 +02:00
nexxo	c2a56382e1	Build the dashboard cards to the template, and name what has no source ... Card by card against the approved template: label with a chevron, the figure and its unit on one line, a line of context underneath, a bar across the foot. The order matches too — storage, seats, transfer, then the fourth slot. Three of the template's four visuals have no data behind them, and the code now says so where someone will read it rather than leaving the next person to wonder why the charts are missing: - Storage consumption is never sampled. The card states the contractually agreed allowance instead of drawing a ring at an invented level. - instance_traffic keeps one row per period, not a daily series, so there is nothing to draw a sparkline from. The share of the allowance is real, so that card carries a bar. - monitoring_targets records a state and a check time but no uptime figure, so there is no availability percentage to show. That slot carries the last backup — the thing this product is about and can actually prove. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-27 16:21:27 +02:00
nexxo	676c38643c	Follow the approved template, and stop showing invented records ... The dashboard was built to my own idea of the layout rather than to the template that was signed off: a coloured pill where the template has a stamped mono line, bare figures where it has a label with a chevron, a unit on its own line instead of beside the number, and no ring at all. There is no point agreeing a design and then building something adjacent to it. The metric card is now a component that draws the template's form, and the pages use it. Two more places were still showing data that does not exist: - Support listed three tickets to every customer, complete with reference numbers and dates. There is no ticket model; it was fixture text. A request list also belongs in the console, where an operator can see who filed what. Removed until there is something real behind it. - The datacentre name reached the customer through the cloud tab's copy as well. Customer surfaces name the jurisdiction; the building is operator information. And the actions column rendered an empty cell for the owner, who can be neither re-invited nor revoked. An empty cell reads as a missing feature; it now says so with a dash and a title. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-27 16:17:06 +02:00
nexxo	21d8dc310a	One definition of the navigation, and the country instead of the building ... The breadcrumb said Übersicht on every page. The sidebar and the breadcrumb each built their own copy of the structure, so the layout had no way to know which entry was current and fell back to the first one. Navigation::portal() and ::console() are now the single definition, and currentLabel() matches on the route name — which matters for the console, whose PATH changes between host-bound and fallback mode while its route names do not. The datacentre name is out of everything a customer sees, for the third time and now at the source rather than in a template. Falkenstein is how an operator places an instance; a customer's processing record names the jurisdiction, and putting the building in customer copy means editing that copy every time the estate grows. Also swept the views onto the new scale: --text-faint is 2.8:1 and a decoration token, but it was carrying table headers, hints and timestamps — text people have to read. All of it moved to --muted, which is 5.0:1 and passes AA. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-27 16:09:39 +02:00
nexxo	6376f5e9fa	One design system for every surface ... The console was a second product. admin-tokens.css held a complete dark set — its own surfaces, its own orange, its own status triad — so every shared component had to work in two worlds, and the two halves of the application drifted apart in ways nobody could see from inside either one. That file now carries density and nothing else: smaller type, tighter rows, tighter corners. Colour comes from one place. The tokens themselves are rebuilt around what the redesign settled on: - Radii scaled to object size (9/11/16/22) instead of one value everywhere, which is what made the interface read as a design-system specification rather than as a product. - Warm, broad, low shadows. A neutral grey drop shadow belongs to a different design language and reads as cold on this ground. - --accent-press, which several rules already referenced and nothing defined. An undefined var() does not make a browser skip the declaration; it computes to , and for background-color that is transparent — the accent button lost its fill on hover and left white text on white. - No serif. A serif headline is what made every page read as a document, which is the impression the whole redesign exists to remove. --font-serif now points at the sans so nothing breaks while call sites are cleaned up. The two shells are one shell with two configurations, and both finally have a mobile navigation: the sidebar used to simply disappear below 900px, leaving no way to move around the application at all on a phone. The customer dashboard is bound to real records — instance, seats, traffic, backups, contract — instead of the fixtures it shipped with. Where something is not measured, storage consumption, it says what was contractually agreed rather than inventing a figure. This is the sheet a customer forwards to their auditor. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-27 16:03:47 +02:00
nexxo	be082b7bf9	Stop iOS zooming the page on every tap into a field ... Safari zooms when a focused input is smaller than 16px, and then leaves the page zoomed — so on an iPhone every form throws the layout about, and the way back is a pinch. The usual fix is the meta-viewport switch, which suppresses the zoom by disabling pinch-zoom entirely: it takes a real accessibility feature away from everyone to solve a cosmetic problem for some. Sizing the fields at 16px on touch devices removes the reason instead. !important on purpose: it has to beat every text-size utility on every field in the application, and a rule that loses to `text-sm` on one form is worth nothing. Checkboxes and radios are left alone — no text to inflate, and sizing them there breaks the box. Also -webkit-text-size-adjust, so iOS stops inflating body copy in landscape. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-27 14:59:12 +02:00
nexxo	3699c7cdb9	Ask the tunnel gateway where it actually listens ... The console has been unreachable over the VPN, and the cause was the readiness probe rather than the tunnel. The gateway binds to the WireGuard hub address alone; the probe asked 127.0.0.1, where nothing has ever listened. It could only fail, so VPN_READY stayed false, and on that basis the application withheld the `DNS = 10.66.0.1` line from every client config it issued. A phone then built the tunnel, asked its normal resolver for the console hostname, got the public address and had its connection closed — indistinguishable from "this site does not exist", which is exactly what it looked like. Probing over TLS on the bare address would not have worked either: the site matches on the console's hostname, so a request without SNI is offered no certificate. The gateway now answers a plain-HTTP health port on the hub address, which removes TLS, SNI and name resolution from the question and answers only what is being asked — is this gateway listening, in this network namespace, right now. Caddy refuses to start when the certificate is unreadable, so a health port that answers still proves the whole file loaded. Also here, all found while looking: - Icons pushed their label onto a second line and rendered a size larger than asked for. Tailwind's preflight makes an svg display:block, and `.size-4` and `.size-5` have equal specificity, so stylesheet order decided — and it emits size-4 first. Every icon written as 16px was silently 20px. Recorded as R18. - Four error pages printed `errors.404.hint` in place of a sentence: the lang files give those codes a null hint and Laravel returns the key for a null line. - The Developer role had no label in either language, so the dropdown showed `admin_settings.role_developer`. - The secrets area held one key, which is not worth a password gate. It now carries the credentials that actually stop the business when they expire — DNS, monitoring, SMTP — and the test button appears only where a checker exists, instead of reporting on Stripe whatever was being looked at. - The update button said nothing about when a queued run would start or where a running one had got to; both are now shown, and a failure names its step. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-27 14:43:23 +02:00
Claude	99715989aa	Dress the placeholder page, and record why the obvious VPN fix cannot work ... The page shown while the site is hidden was still in the old style — a coloured square and system fonts — on the two hostnames a visitor is most likely to try. It now uses the site's own plate, typeface and registration marks, still entirely self-contained because it is shown precisely when the asset build may not exist. Both it and the error pages lighten the accent in dark mode: the tone is chosen for contrast against paper, and on the ink plate the small text is the first thing to stop being readable. The VPN investigation ended somewhere useful, and not where it started. The blank page on the phone is the reverse proxy refusing the request — `respond 404` sends no body. It refuses because the phone is not on the tunnel: the client config lists only the management subnet in AllowedIPs, so a request to the console's public hostname goes out over the mobile network and arrives from a carrier address. It also explains "last contact: never", since WireGuard only performs a handshake when it has traffic to send, and nothing is ever routed into the tunnel. The obvious fix — add the server's public address to AllowedIPs — is written down here as a comment and a test rather than as code, because it cannot work. The WireGuard endpoint is that same address, so routing it into the tunnel routes the handshake packets into the tunnel they are trying to establish. The result is a loop and a connection that never comes up: the same blank page, now with no way in at all. Reaching the console over the VPN needs an address INSIDE the subnet — the proxy answering on the hub address, and a name that resolves to it. That is a deployment change, not something a config line can express. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-27 09:19:30 +02:00
Claude	a58faf3f85	Manage the Stripe key from the console, behind a password and a test ... Changing a key meant a shell, a file edit and a cache rebuild — and the person who owns the Stripe account is not necessarily the person who owns the server. Two gates, not one. The capability decides who may open the page; every operator has console.view, and that must not mean "can read the payment key". The password decides whether this SESSION may see or change anything, because the realistic threat is not a stranger but an unlocked machine, and a session is exactly what that hands over. Both are re-checked server-side on every action — a Livewire action is reachable by anyone who can post to /livewire/update. The value is stored encrypted under a key of its own, SECRETS_KEY, and the vault refuses to work without it rather than falling back to APP_KEY: rotating APP_KEY is ordinary maintenance and would otherwise destroy every stored credential, discovered when Stripe stops answering. It is read where it is used, not overlaid onto config at boot — an overlay adds a query to every request including the public site, and leaves queue workers holding whatever was true when they started. It is never shown again, only outlined, and never enters a Livewire property that would carry it to the browser and back in the snapshot. A registry, not an env editor: a form that can set any environment variable is a privilege-escalation primitive, and one bad value bricks the installation with no way back through that same form. The test button is the part that matters. It reports which Stripe account the key belongs to, whether it is LIVE or test — the most expensive mistake here is pasting one where the other belongs, and both look identical in a form — and which webhook endpoints exist with the events each subscribes to. A key can be perfectly valid while the endpoint listens for the wrong five events, and nothing fails until a payment goes unrecorded. The webhook signing secret deliberately stays in .env. It is read on every incoming payment event; in the database, a database problem becomes silently failing signature checks. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-27 09:01:16 +02:00
Claude	f6b9181ed8	Give customers two-factor, and stop every button on the settings page reacting at once ... Clicking Save made every button on the console's settings page appear to fire. Seven `wire:loading.attr="disabled"` had no `wire:target`, and without one Livewire applies the loading state to ANY request on the component — so one save put all of them into their disabled state simultaneously. Each names its own action now. Two-factor for customers. Fortify's endpoints already existed; only the screen was missing. Setting up requires re-entering the password first, and every action re-checks that server-side rather than relying on the button not being on screen — a Livewire action is reachable by anyone who can post to /livewire/update. The confirmation marker is Laravel's own session key, so it and the framework's password.confirm middleware mean the same thing rather than drifting apart. The secret never enters a Livewire property. Component state travels to the browser and back in the snapshot; the QR image is derived from the secret, the secret is not in it — and there is a test that says so. The status page moves to the ROOT of its hostname: status.clupilot.com/status says the same word twice. That needed the domain-bound `/` registered BEFORE the landing page, because Laravel takes the first match and the landing route is host-agnostic — so the status host would have served the marketing site. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-27 08:48:34 +02:00
Claude	935c9ae6ac	Let people change their own password, and a location be switched off while editing it ... Three gaps, all of the "half-built" kind. Nobody could change a password. Fortify's updatePasswords feature was switched off, so an account created with a generated password kept it until someone opened a shell on the server — including the owner's own. Both settings pages have the form now, sharing one concern, because two copies of a password rule is how one of them ends up weaker. It goes through Fortify's own action rather than hashing here, and the current password is required: an unlocked machine should not be two keystrokes away from locking its owner out. The datacenter edit form had no active switch. The column and the scope existed, and the list page has a toggle — but the form you open to change the thing did not offer the one lifecycle action a location actually needs. Switching one off now says what it does NOT do: existing hosts keep running. Once, on the actual transition, and as the only message — the generic "saved" toast would otherwise replace it, and an already-inactive location would have announced its own deactivation every time its name was edited. The staff table's actions cell is empty for your own row, because you cannot revoke yourself. With a one-person team the column was therefore always blank and read as broken rather than as a rule. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-27 07:49:07 +02:00
Claude	bc8bbc56a5	Make the console's access list reach the proxy, price in euros, and answer errors ... The console was unreachable, and not for the reason it looked like. Two causes, both mine. A failed `artisan optimize` — the one that hit duplicate route names — left a broken route cache behind, so every request to the console host answered 500. Rebuilt. Underneath that: the reverse proxy has its own console allowlist, hard-coded, and it runs BEFORE the application. Everything added on the console's own access page was therefore ineffective, and when the owner's address changed they were turned away by the proxy before reaching the page that would have fixed it. The proxy now imports a fragment generated from the same list the console manages, regenerated by the host agent and reloaded when it changes. Getting that safe took most of the review. It refuses to rewrite an ambiguous Caddyfile rather than replacing some other site's matcher; it never falls back to a loopback-only list when the application cannot be reached, because that list validates cleanly and locks out every remote operator; it retries a reload that failed instead of assuming it worked; and an installation that upgrades without rerunning the installer is told, because otherwise the whole mechanism is invisibly absent. Prices are entered in euros. The form asked for cents, so €799 was typed as 79900 and one slipped digit was a factor of ten on an invoice. Conversion happens in one place, on the string rather than through a float — (float) '79.90' × 100 is 7989.999… and casting truncates to 7989, one cent short on exactly the prices people charge — and it refuses an amount the column cannot hold instead of failing at the database. Every error code has a page now, in the site's own language and typeface, self-contained so it still renders when the asset manifest is the thing that broke. There was only a bare white 404. The VPN list stops being a seven-column table nobody could fit: names broke across two lines and so did the headings. These are attributes of one access, not quantities compared down a column, so each access is a row — identity on one line, measurements in mono on the next. The status page says what it measures rather than what it promises. "New orders are delivered without failures" read as a marketing claim on a page whose only job is to be believed, and said nothing about the last 24 hours. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-27 06:51:05 +02:00
Claude	233fc73430	Let the console keep its recovery hostnames without breaking route caching ... Registering the console once per accepted hostname reused one set of route names, and Laravel refuses to serialise two routes under the same name — so `artisan optimize` failed on the live server the moment the separation was switched on, mid-deploy. Only the canonical registration carries the `admin.` names now; the alternates answer under `admin.viaN.*`. They exist to be MATCHED — they are the addresses someone locked out reaches for — never to have URLs generated for them, so route() keeps producing the canonical hostname. That renaming then broke every exact route-name check, which is how the console navigation decides what is active: reached through a recovery address, nothing in the sidebar was marked, exactly when something is already going wrong. The check goes through AdminArea now and matches either form. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-27 06:20:44 +02:00
Claude	de6821b53e	Move the console off /admin, give the status page its own address, and measure monitoring ... Three things the owner asked for, and one the review found underneath them. The console leaves /admin. It has its own route file now, registered before routes/web.php because once it has a hostname to itself it sits at the ROOT of that host — where `/` and `/settings` also exist for the portal, and the first matching route wins. Where it mounts is one decision in one place: `/` on the console hostname where it has one to itself, `/admin` on any host otherwise. Names stay admin.* in both modes, so nothing that builds a URL has to know. Exclusivity is its own switch, not a consequence of having a hostname. The first attempt made "this host is the console" follow from ADMIN_HOSTS, and a development machine lists its own IP there so the console works without DNS — which took the public site and the portal off that machine entirely. The switch also registers the console on every listed hostname, canonical last, so the alternates that exist as recovery paths keep working. The status page moves out of /legal, where it sat beside the imprint and the terms. Nothing about the current health of the platform is a legal document. It is a real page now: portal, instances, provisioning and backups, each derived from records, aggregate only, and a component with no signal reports "unknown" rather than "operational". That last rule is what exposed the real bug. monitoring_targets.status was written once — 'up', at provisioning — and nothing ever updated it. Both the console's notices and the new public page read it, so an outage would have been published as healthy indefinitely. There is a sync job now, on a five-minute schedule, and a checked_at column so a verdict can go stale instead of standing forever. The monitoring contract had to grow a third state for that to be honest. isHealthy() answers true when no monitoring is configured and false when the monitor is unreachable; recording that boolean would have published either a fleet-wide all-clear nobody measured or a fleet-wide outage that was really one broken monitor. health() returns null for both, the recorder leaves the old verdict to go stale, and isHealthy() keeps its forgiving semantics for the one caller that wants them — the provisioning acceptance check, which must not fail a delivery because monitoring is not set up. Backups are counted from the instances that need protecting rather than from the backup rows that exist, so an instance with no schedule at all cannot be missing from the arithmetic that declares the estate protected. Also: the update panel polls itself, offers the button only when there is something to install, and opens the log while a run is in progress. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-27 06:05:40 +02:00
Claude	276f926d57	Add the update button, and give it a host-side agent that can actually update ... The panel had no way to update the installation, and could not have one on its own: it runs as www-data inside a container, and the update restarts that container. A button that shelled out would kill its own web server mid-response, and would need the application to hold host-level credentials — a far worse thing to own than an out-of-date checkout. So the button is a mailbox. The panel writes a request into the checkout; a systemd timer on the host, running as the service account, consumes it, runs deploy/update.sh and writes back what happened. The same timer answers the question the panel cannot answer alone — is there anything to update — which needs a git fetch, and therefore credentials the application does not have. The parts that were wrong before review, all of which would have shipped as a button that looks fine and does nothing: - The agent was only installed by install.sh, which the installed base never runs again. Every existing server would have shown the button permanently disabled. It has its own root entry point now, install.sh delegates to it, and update.sh says so when the unit is missing. - On a release-pinned server the checkout is detached, so it followed "origin/HEAD" and then ran an update that deliberately stays on the pinned tag: updates advertised, nothing applied. It now compares TAGS in release mode and passes the target release through. - On a branch other than main it advertised that branch's commits and then deployed main's, because update.sh defaults to main. - A request written while the agent was down was executed whenever the agent next started, days later. - A single status file meant the routine five-minute check overwrote a failed update with "idle" before anyone saw it. - An agent that had been stopped left the button enabled forever, because a status file written once counted as an agent. - The agent's error messages were German strings rendered into an English interface; it reports codes now and the panel translates them. Also: the add-address button in the console-access panel was as tall as the field plus its hint, because the hint was a sibling inside the flex row. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-27 05:33:17 +02:00
Claude	30a80b6c15	Report the estate from the database, and print the traffic that is sold ... Three console pages were fiction. The front page claimed 42 customers, 39 instances, four hosts named pve-fsn-1..3 and €7,842 a month, over a twelve-month growth curve; the instance list held seven invented machines; the revenue page reported churn and a trend for a business with no recorded history. All of it was hard-coded. It read like a running company and measured nothing. They now read the database. Two figures are gone rather than approximated — the revenue trend, which needs a monthly history nobody records, and churn, which needs a base the data cannot supply. ARR stays, labelled as the projection it is. The green "all systems normal" badge is computed from the notice list instead of asserted, and the notices themselves come from failed runs, hosts reporting errors or gone quiet, and monitoring that is down. Host load is the one number that had to agree with something else: placement counts the VM disk allocation, ignores a failed instance that never got a VM, and subtracts the host's reserve. A dashboard doing its own arithmetic would show a host as comfortable while orders were already being refused on it, so it uses the host's own accounting — with the filter moved into a scope both share, and the sum preloaded so listing hosts stays one query. The instance list drops the Nextcloud version column: that version is not recorded anywhere, and a column filled with a plausible number is worse than no column. Statuses the lifecycle writes but nobody had translated no longer render as "admin.status.failed". The price sheet also gains the included traffic, which the catalogue has always carried and the page simply never printed. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-27 04:48:51 +02:00
Claude	b844ff377d	Rebuild the public site as a document, and read prices from the catalogue ... The marketing page was a generic centred hero in the system font stack: it neither used the design system the console is built on nor looked like the product it sells. Rebuilt around what CluPilot actually promises — security you can produce evidence for — so the page reads as a controlled technical document: a specification plate instead of a hero image, numbered sections, an audit register with rhythm and proof per measure, and a price sheet rather than floating cards. IBM Plex Serif joins Sans and Mono as the display voice, self hosted as static files so the public page renders even without the Vite build. The prices were written into the page by hand, and the page and the catalogue had already drifted apart on three of four plans: the site advertised 249 € for a plan the checkout charges 399 € for. The sheet now reads the catalogue, like every other caller — including the currency, which is configurable and was also hard-coded here. The catalogue fails loudly on purpose; a public website must not. A broken or overlapping catalogue is caught in the controller alone: the page still renders, the sheet is replaced by "on request", and nobody is quoted a number the checkout would not honour. The sign-in and registration panels shared a copy-pasted orange gradient. They now share one component and the same ink plate as the site, so the two halves of the product no longer look like two companies. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-27 03:52:25 +02:00