258 Commits (b85c12e8b9a2f455040aa8a8a614595e98c256e6)

All Branches

Search

Author	SHA1	Message	Date
nexxo	b85c12e8b9	Give the readiness probe long enough for a restart to finish ... The gateway is restarted twice in a deployment — once by `up -d`, then again after the hub whose network namespace it lives in — and `docker compose exec` into a container that is still coming up fails outright rather than waiting. Twenty seconds did not cover that, so the first run of the new probe reported a gateway that answers as down, and the resolver stayed out of client configs for one more deployment. The health site also now binds the hub address instead of only matching on it. Nothing was published either way, but the file should do what its comment says. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-27 14:46:47 +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	2bb1d7cc3b	Make the private hostnames look like nothing is there, and close the way past the proxy ... An empty 404 is itself information: it says something terminates TLS here and chose not to answer. The console and the websocket endpoint now close the connection instead, which is what a hostname that serves nothing looks like. The websocket endpoint answers a genuine upgrade — verified live, 101 — and nothing else; a browser opening it gets a closed connection. Reviewing that turned up two holes that mattered more than the thing being reviewed. The compose defaults published the application and Reverb on every interface. Docker publishes ports ahead of UFW, so those backends were reachable from the internet with the firewall closed — and reaching a backend directly skips the proxy, and with it every hostname and address rule keeping the console private. The defaults are loopback now, and an update rebinds an existing installation that is behind a proxy actually running and holding 443. A development box without one is left alone, because taking its port away would look like the machine had broken. And the console's own "open" switch was emitting 0.0.0.0/0 into the proxy's allowlist. One click would have put the console on the public internet, which is the exact state the owner's rule exists to prevent. Switching it off relaxes the application's check; the proxy keeps its list, always. The reference proxy config carries the arrangement: QUIC early data off, since an address-based decision taken on 0-RTT can answer 425 and some browsers do not retry — an intermittent lockout from the console is the worst kind — and explicit handling for plain HTTP, whose automatic redirect otherwise announces both hidden names to anyone who asks. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-27 11:26:48 +02:00
Claude	c4649571df	Wait for the tunnel interface, and prove the gateway answers ... Two things reported success while the tunnel console was unreachable. The services were restarted the moment the hub container counted as started, but the hub brings wg0 up as part of its start command — so they were binding an address that did not exist yet. They now wait for the interface. And readiness was a container-state check. A container can be up and running while the process inside it listens in a network namespace that was torn down underneath it: nothing errors, the address simply refuses connections, and "running" reports everything fine. It asks the gateway now, and only a real answer counts — because the consequence of getting this wrong is a client config naming a resolver that is not there, which takes the device's whole name resolution with it for as long as the tunnel is up. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-27 10:24:29 +02:00
Claude	d2d79b4f5f	Restart the tunnel services after the hub they live inside ... Both VPN services share the provisioning container's network namespace, and a process holds the namespace it started in. Restarting the hub — which every deploy does, to pick up new code — therefore leaves them listening inside a namespace that no longer exists. Nothing errors. The containers stay up, Caddy's log still reports it is serving on the tunnel address, and connections to that address are simply refused. It looks precisely like a gateway that never worked, which is how it presented on the live server after the first successful start. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-27 10:22:19 +02:00
Claude	32ae64d5fd	Pin the resolver to a tag that exists ... The dnsmasq image was pinned to 2.90-r0, which is not published. The gateway therefore never started — correctly reported as not ready, so no client was handed a resolver that was not there, but the tunnel console did not come up either. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-27 10:17:20 +02:00
Claude	457eeeeaef	Serve the console inside the tunnel, without publishing the internal network ... The owner's phone shows a blank page on the VPN. That page is the reverse proxy refusing the request, and it refuses because the phone is not on the tunnel: the client config routes only the management subnet, so a request to the console's public hostname leaves over the mobile network and arrives from a carrier address. It is also why the peer reads "last contact: never" — WireGuard only handshakes when it has traffic to send, and nothing is ever routed in. The obvious fixes are both wrong. Adding the server's public address to AllowedIPs routes the WireGuard endpoint into the tunnel it is trying to establish. A public DNS record pointing at 10.66.0.1 publishes the internal subnet to anyone enumerating the domain — the owner raised that himself, and he was right. So the console is served INSIDE the tunnel instead. A small resolver and a small gateway share the hub container's network namespace, which is where wg0 lives, and answer on 10.66.0.1 directly. A client therefore needs no route beyond the subnet it already has, the host's docker bridge is never exposed, and the request reaches the application with its real 10.66.0.x source — which is what the console's own allowlist checks. The gateway reuses the certificate the public Caddy already renews: a certificate is bound to the name, not to the address serving it, so nothing new is issued and nothing internal reaches a public zone. Most of this commit is the arithmetic of not lying about it. Review found fourteen ways the arrangement could report itself working while it was not: enabling the compose profile after the services were started rather than before; starting a gateway with empty certificate paths, which can only crash; treating "container created" as "container running"; carrying a stale readiness marker through a failed restart; reusing the previous hostname's certificate after a rename; leaving the profile enabled when the hostname was cleared, in a script that exits early precisely when nothing else would fix it; reading the renewal timestamp as a user who cannot traverse Caddy's storage; and a `find | head` that aborts the whole installer under pipefail the moment two issuers hold a certificate for the same name. One of them was mine and worth naming: to let the container read the certificate, I had made the TLS private key world-readable. On a multi-user host that hands the console's identity to every local account. The client is told about the resolver only when both services are confirmed running, because a config naming a resolver that does not exist takes the device's entire name resolution with it for as long as the tunnel is up. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-27 10:14:33 +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	6082164f8b	Give the status page its own hostname, and name the right one for Stripe ... STATUS_HOST binds /status to a single hostname. Every other host redirects there rather than 404ing: a status page is the one address people keep in a bookmark and reach for when something is already wrong, so breaking old links to prove a point about separation would be exactly backwards. Unset, nothing changes. The /legal/status redirect goes through route() instead of a literal path. A relative redirect lands on whatever host the visitor is already on — which, once the page has a hostname of its own, is precisely where it no longer answers. The installer told the operator to point Stripe's webhook at the customer portal. Stripe posts server-to-server and never sees the portal; the endpoint is the api hostname, which the installer never even asked for. It asks now, and prints the address that actually receives the events. Getting this wrong does not fail loudly — payments simply stop being recorded. It also writes ADMIN_HOST_EXCLUSIVE=false on a fresh install. Switching the console onto its own hostname before the DNS for it exists makes the console unreachable under any other name, and that is not a thing to have on by default. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-27 08:08:57 +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	492b1925fb	Land a sign-in where it was performed, not always in the customer portal ... Fortify sends every successful sign-in to config('fortify.home') — /dashboard. That is why an operator signing in ended up in the customer portal, and once the console has a hostname to itself it stops being merely confusing: /dashboard does not exist on that host, so signing in would land on a 404. Three outcomes now, decided by where the sign-in happened and who signed in: the console for an operator on the console, the portal everywhere else, and for a non-operator on the console the session is taken away again at the moment it was created — a guard that merely refuses each page afterwards leaves that session in the browser. Four things the review caught, each of which would have left a hole: - Fortify never reaches LoginResponse when a two-factor challenge was involved. Binding only that one left exactly the accounts most likely to be operators on the old behaviour, so both exits are bound and share one decision. - The JSON branch ran before the authorization check, so a JSON client kept a session a browser would have lost. - The two exits do not share a JSON success contract — an ordinary sign-in answers {"two_factor":false}, a completed challenge answers an empty 204 — and merging them breaks a client keying off the status code. - In shared mode everyone posts to /login, so the request never looks like the console even when /admin is the destination. The intended URL is read too. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-27 06:15:16 +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	b860ce2e9b	Give the three console guards one answer to "is this the console?" ... The hostname guard, the network allowlist and the public-site switch each decided for themselves, by testing the path against admin/*. That works only while the console sits under /admin. It is also a trap: the moment the console moves to the root of its own hostname, PublicSiteGate stops recognising it, and with the public site hidden the console answers 503 to the very person trying to sign in and switch it back on. The guard does not fail loudly — it silently stops matching. AdminArea is now the single answer. It has two modes and no third: a console hostname is configured, in which case the console IS that host and answers at its root; or nothing is configured, in which case the console stays under /admin on any host exactly as before, so upgrading cannot lock anyone out of a system that was working. RestrictAdminHost gains the half it was missing. Binding console routes to a hostname does not stop the customer routes from answering there too, because they are registered without one — so the console's hostname would still serve portal pages wherever the paths did not collide. It now enforces both directions, with the endpoints both sides genuinely share written out as a list rather than inferred. Nothing changes yet for an installation with no ADMIN_HOSTS set, which is every development machine and every fresh checkout. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-27 04:52:21 +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
nexxo	0066b1c6a0	feat(security): a way back into the console that does not need the console ... The allowlist is managed in the console, which is fine until the address you manage it from changes — and then the page that would fix the problem is the page the problem blocks. Every gate needs a door that does not depend on itself, and on a server that door is a shell: php artisan clupilot:console-access show php artisan clupilot:console-access allow 203.0.113.7 php artisan clupilot:console-access open The address check moved to RestrictConsoleNetwork::isNetwork() so the command and the console apply the same rule. Codex caught the version that did not: a typo like 203.0.113.9/99 was stored, reported as success, and matched nothing — leaving whoever was recovering still locked out, now believing they were not. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-27 03:09:13 +02:00
nexxo	9ccd4f59d8	feat(security): the console decides who may reach it, and the owner keeps the list ... RestrictAdminHost answers under which NAME the console responds — and the caller picks the Host header, so it can never answer who is asking. This does: a network gate on the client address, which behind a trusted proxy is not something the client chooses. The management VPN is always in the list and cannot be removed — it is the one way in that survives a bad entry. Beyond that the owner keeps their own addresses in the console, because being away from the VPN should not mean being locked out, and the person who needs to change that list is the person sitting in front of it. Two refusals rather than warnings, since by the time a warning renders the request that would show it has already been rejected: switching the restriction ON is refused unless the address doing the switching is already covered, and removing the entry you are sitting behind is refused. Entries are validated as an address or CIDR — a typo that matches nothing is how someone locks themselves out while believing they have not. 404, never 403. Registered as persistent Livewire middleware, and verified in a browser that it holds there: with the settings page open, narrowing the list turned the next action from 200 into 404. Codex read the path guard as skipping /livewire/update; Livewire in fact replays middleware against a duplicate of the request carrying the original component's path, so the guard matches and the client address is preserved. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-26 20:27:26 +02:00
nexxo	5c2e481985	fix(security): console and account checks now survive a Livewire action ... Livewire re-applies only the middleware on its persistent list when an action posts to /livewire/update. Its defaults cover auth; ours were not on the list — only RestrictAdminHost had been added. So EnsureAdmin and EnsureCustomerActive guarded the PAGE and not the actions, and the page is not where the actions run: a signed-in non-operator who could reach the admin host could drive console components, and a suspended customer could keep driving the portal. Found by Codex while reviewing the domain-separation design, and confirmed against Livewire's own default list in vendor. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-26 20:04:34 +02:00
nexxo	5d64da1cb3	docs: hiding the site also hides the login page, and that has a consequence ... The gate exempts admin/* so the console keeps working, but /admin sends a guest to /login and /login is not the console — so with the site hidden and no VPN yet, an operator cannot sign in to flip the switch back. Found while bringing up the live server. The mechanism for it already exists and is the right one: TRUSTED_RANGES. What does NOT work is exempting the login flow by hostname, which was the obvious patch — a Host header is chosen by the caller, so one forged header would have lifted the gate for every route, portal included. Codex caught that; the comment now says why the narrow-looking option is the wrong one. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-26 19:27:51 +02:00
nexxo	875fd11982	fix(deploy): an answer file with a space in a value killed the install ... The file is sourced, so ADMIN_NAME=Boban Blaskovic is read as a command and dies with "Blaskovic: command not found" — naming neither the file nor the variable — and set -e ends the install there. A display name with a space is entirely ordinary; the example just happened to use "Administrator", one word, so nobody hit it. Found while installing on the live server. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-26 18:49:58 +02:00
nexxo	9352935b88	fix(nginx): the live hostnames were missing from the admin denylist ... The map listed only *.dev.clupilot.com, with the production names commented out under "add the real public hostnames here before launch". Launching without them removes the outer of the two layers that keep /admin off the public internet — the ADMIN_HOSTS check in the app would still answer 404, but the whole point of the pair is that neither is relied on alone. admin.clupilot.com stays out of the list on purpose: the list names the hosts that are PUBLIC, and the console is not one of them. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-26 18:43:44 +02:00
nexxo	35307e64cc	fix(deploy): the installer could never finish, twice over ... Found by running it on a fresh Debian 12 with systemd, no docker, no git and no users — which is the first time it has ever been run anywhere. `optional_env` ended in `[[ -n "$2" ]] && set_env …`. With an empty value the function returns 1, and under `set -e` that ends the install, silently, with a half-written root-owned .env. Absent is the NORMAL case for those variables — they are the optional ones — so this killed every installation that did not happen to supply a Hetzner token. An `if` returns 0 and does not. Then it waited for `php -v` before migrating. PHP answers in seconds; the entrypoint is still running `composer install` on a fresh checkout, which takes minutes. So `artisan migrate` ran against a checkout with no vendor/ and died on a missing autoload.php. It now waits for vendor/autoload.php, exactly as the dependent containers already do, and says where to look if it never appears. After both: exit 0, 59 migrations applied, the plan catalogue seeded and consistent, the Owner account created with its role, and the portal answering 200 while the console redirects to login and the unconfigured Stripe webhook fails closed with 400. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-26 17:42:26 +02:00
nexxo	e9240c1324	feat(deploy): releases you can pin to, and a version that tells the truth ... VERSION at the repository root is the release number and the only place it is written down — a file rather than `git describe`, because a source archive, a shallow CI checkout and a container built without .git have no tags to describe. Cutting a release is editing that file and merging it; CI creates the annotated v<VERSION> tag once green, only on the commit that raised the number, and never moves it. Servers are pinned to these. Two modes, and the difference is the point. RELEASE=v1.0.0 pins a server to an immutable tag, checked out detached: it moves when someone decides it moves. BRANCH=main follows the edge, where CI tags a commit only after it is pushed. The mode is remembered, so re-running the updater on a pinned box does not quietly walk it back onto main. Going backwards is refused, by commit ancestry rather than by comparing version strings — a tag can be cut from anywhere, and only ancestry says whether history is going back. The schema has already moved forward by then, and the migrations needed to reverse it are not in the older checkout at all. What the console reports comes from a manifest written atomically after every step succeeded, never from live git: git says what the files are, not whether the deployment came up. So a failed update keeps reporting the version that is actually serving — including its version number, not the newer one the checkout has already moved to. A deployment pinned to the tag reads "1.0.0 (abc1234)"; anything else reads "1.0.0-dev (abc1234) · main", because every commit after the tag still carries VERSION=1.0.0 and is not that release. Reporting it as one is how a bug gets filed against the wrong code. Codex reviewed the design before it was written and the result six times after. Its findings, all real: the version had to come from the manifest too, not just the commit; branch names need JSON escaping or the manifest silently vanishes; a `case` glob does not anchor and accepted 1x.2y.3garbage; pinning to the commit a server already sits on skipped recording the mode, and then skipped detaching; a manifest that failed to write would never be repaired; an unparseable timestamp would 500 every admin page; and an empty tag list read as a connectivity failure. 466 tests green. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-26 15:21:38 +02:00
nexxo	c119e8d96e	fix(deploy): say which branches exist instead of failing inside git ... The installer clones BRANCH, which defaults to main — and the repository has no main. Git's own "Remote branch not found" reads like a bad token or an unreachable server, and the branch is the one thing here that is routinely wrong. It now asks first and, when the branch is missing, prints the ones that do exist and how to pass one. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-26 14:48:49 +02:00
nexxo	4f3e11ae5e	docs(deploy): the installer's Stripe steps match what phase 5 actually needs ... It still named two webhook events; the application handles six, and the four new ones are the billing cycle itself — renewals, failed payments, status changes and endings. It also said nothing about stripe:sync-catalogue, without which Stripe has no prices and nothing can be sold at all. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-26 14:46:25 +02:00
nexxo	8c3a79e258	fix(billing): hold only what cannot be matched, and let migrations roll back ... Two findings from reviewing all five phases together rather than one at a time. The webhook held every event a handler answered `null` to — but `null` also means "already recorded" and "deliberately skipped", which is every checkout's own invoice and every redelivered renewal. Their contract is right there, so `replayHeldFor()` could never come back for them, and ordinary Stripe traffic silted up the holding area until the weekly prune. It now holds only what it genuinely cannot match — and if the contract appeared in the meantime, applies the event instead of dropping it: the creation race is narrow, but losing a cancellation to it would leave us serving someone who had left. Also fixes a rollback that predates this work and blocks `migrate:fresh` on MariaDB entirely: dropping the unique index on customers.user_id fails while the foreign key added one migration earlier still depends on it. Verified by building all 33 migrations from nothing on MariaDB, rolling every one of them back, and building them again. 458 tests green. Codex clean on the full branch diff. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-26 13:57:11 +02:00
nexxo	0560ae743d	feat(billing): Stripe owns the billing cycle, we own capability ... A Product per plan family and a Price per priced row of a published version, plus the four subscribed webhook events that were arriving and being ignored. `stripe:sync-catalogue` mirrors the catalogue. Idempotent twice over: a stored id is skipped, and each call carries an idempotency key derived from our own row, so a crash between Stripe creating a Price and us recording its id gives back the same object rather than a second one. That matters more here than usual — a Stripe Price cannot be edited or deleted, so a duplicate is permanent. Drafts are not synced at all: a version that has promised nothing has no business in a price list. --dry-run shows what would be created. The webhook now handles invoice.paid, invoice.payment_failed, customer.subscription.updated and customer.subscription.deleted. It never re-derives an amount: the invoice is the authority for what was charged, and recomputing it from our catalogue would produce a second, disagreeing answer. A failed payment is recorded and nothing else — Stripe runs the dunning schedule, and cutting a customer off on the first failure would punish an expired card as though it were a refusal to pay. Only a cycle renewal moves the term on. Stripe also sends paid invoices for prorations and manual charges, and the checkout's own invoice — which is already in the register as the purchase, and would otherwise double every customer's first payment. Stripe does not guarantee delivery order, which is the source of most of the care here: - state changes are judged and written in one transaction with the row held, so two deliveries cannot both pass a check made on a stale copy; - an older event never overwrites a newer one, with a rank breaking ties between events sharing a second — their timestamps have one-second resolution, and a failed attempt and its successful retry routinely do; - a term is never shortened, and an ended contract is never revived; - an event for a contract that does not exist yet is HELD and replayed the moment it appears, rather than acknowledged and forgotten. A cancellation dropped that way would leave us serving someone who had already left. Held rows that never match are pruned after a week. Register entries are keyed by what they are about — the invoice, the attempt, the subscription — with a unique index doing the work, because a check two concurrent deliveries can both pass is not idempotency. PlanChange is now documented as the preview shown before someone confirms, not the invoice: Stripe's proration accounts for tax, existing credit and the exact second the change lands, and ours cannot. Not run against the live account — `stripe:sync-catalogue` creates objects that cannot be deleted, so that is the owner's call. The dry run lists 12. 457 tests green. Codex review clean after seven rounds. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-26 13:36:28 +02:00
nexxo	7582df3de6	feat(billing): a proof register, and modules frozen at their booked price ... Two things the contract could not answer on its own: what happened, and what the customer's whole bill is. `subscription_records` is append-only, one row per commercial event. Flat columns for everything searched or relied on as evidence — event, customer, subscription, plan family and version, term, net/tax/gross, currency, tax rate, reverse charge, Stripe ids — PLUS a versioned JSON copy of the whole snapshot. Not JSON alone: you cannot query it, and "the amount is in there somewhere" is poor evidence. Copied, not joined, so a row still answers after the customer, the plan or the version have gone. The flat columns describe the TRANSACTION. Gross is what was actually taken; net and tax are that gross split by the rate that applied on the day. A discount lowers the taxable amount rather than creating negative VAT, and a free checkout is recorded as free instead of as paid in full. What was agreed sits beside it in the snapshot, so a charge that differs from the catalogue is preserved as a question rather than reconciled away. The register refuses to be rewritten, in bulk as well as one row at a time — model events do not fire for `query()->update()`, which is exactly the shape a careless data fix takes. `subscription_addons` carries the owner's rule: a customer's total is their subscription plus their modules, and all of it is frozen at what was agreed. Price protection covering only the plan would let a module quietly double for someone who booked it two years ago. A module they have NOT booked is a sale still to be made, at today's price — so the catalogue is consulted only for what is not in this table. Several bookings of one module are summed rather than reduced to one arbitrary row, or the page and the bill would disagree. Concurrency: one order books one module, enforced by a unique index rather than a lookup two retries can both pass; cancellation is an atomic claim; and each booking commits with its own register entry, so a failure cannot leave a sale without evidence and a retry that finds the booking cannot skip the event. Verified in the browser: with the module raised from 29,00 € to 59,00 € in the catalogue, the customer who booked it still sees 29,00 € and a total of 208,00 €, while a new customer is quoted 59,00 €. 436 tests green. Codex review clean after seven rounds. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-26 13:07:34 +02:00
nexxo	f6ddf45dc0	feat(admin): a console for creating, pricing and scheduling plans ... The owner can now do from the console what only a config edit could do before: create a plan line, draft a version, price it, publish it into a window, and pull a plan out of the shop. Two pages and one modal, because the catalogue has exactly two levels. The plan list is a name, a rank and a kill switch. Everything that can be got wrong — capabilities, prices, windows — lives on the versions, where the page is built around the one rule that matters: a draft is freely editable, a published version is not touchable at all. So drafting and publishing are separate acts, and publishing says plainly that it is final. The console refuses everything the catalogue refuses, on the form rather than as a stack trace: an overlapping window, a window that ends before it starts, a version with no price for a term we sell on, and — new here — a version with no VM template, which would be bought and then fail provisioning every time. Numbers are bounded on both sides, because a mistyped price otherwise overflows the column and answers with a 500 instead of saying which field was wrong. Performance class and features are picked from the keys we have labels for; free text would be frozen at publication and shown to customers as a raw translation key forever. Concurrency, since two admins share one catalogue: draft numbers are allocated under a lock on the family, publication is an atomic conditional claim, and discarding a draft is one statement conditional on it still being a draft — otherwise a draft published in the meantime could be deleted out from under the customers now contracted to it. `plans.manage` (Owner and Admin) guards the pages themselves, not only the buttons, and the modal authorises itself — prices, drafts and unreleased plans are not something to leave readable to anyone who types the URL. Also fixes the shared checkbox, which ticked in the browser's own blue on every page that used one: a native checkbox ignores text colour and needs accent-color. Verified in the browser: withdrawing a plan in the console removes it from the customer's billing page immediately, and restoring it brings it back. The public landing page carries no catalogue-driven plan list, so there is nothing there to hide. 421 tests green. Codex review clean after six rounds. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-26 12:41:51 +02:00
nexxo	6387c747d0	feat(billing): the plan catalogue becomes three tables, and config stops selling ... Plans lived in config/provisioning.php, where the owner cannot reach them and where a plan has no history. They now live in plan_families / plan_versions / plan_prices — a name that never moves, what the plan WAS at a point in time, and a price per version and term with its own Stripe Price id. - Availability is computed on every read (available_from <= now < until, half-open, UTC) plus a per-family sales kill switch. Nothing schedules a plan into or out of sale: a job that fails to run is a plan that silently misbehaves. - Overlaps crash rather than resolve. currentVersion() uses sole(), and scheduling takes a lock on the family and rejects an overlapping window — two versions on sale at once would decide a customer's price by row order. - A version is frozen from publication, not from first sale, and so is its price: a checkout is not instant, and an amount edited between the session opening and the webhook landing would contract someone at a price they were never quoted. Repricing publishes a new version, as Stripe requires anyway. - Neither a published version, its price, nor a family with customers can be deleted, and a family key cannot be renamed. All of those would null the provenance off existing contracts. - Subscriptions and orders record plan_version_id. A historical reference resolved by plan NAME hands back today's terms, which is the split-brain one level up. A checkout that carried its version is honoured even after the window closes — they paid for what they were shown. Switched atomically and failing closed: config('provisioning.plans') and plan_features are gone, and nothing falls back to them. A fallback would resurrect a plan the owner had just switched off. The seed lives in the migration, and PlanCatalogueTest pins what the config catalogue sold as the shadow comparison. `php artisan plans:check` reports overlaps, gaps and missing prices before a customer finds them. Contract-backed displays, which were reading the live catalogue: seat limits, the cloud card, the plan card, and admin MRR — the last three now divide a yearly contract down via Subscription::monthlyPriceCents(), since all three label the figure per month. Two recovery gaps closed along the way: the order now commits before the contract is opened (so a contract failure can never erase the record of a payment), a Stripe retry repairs a missing contract and restarts a run stranded with no_subscription, and TickProvisioning sweeps runs left pending by a crash rather than only running/waiting ones. 402 tests green. Codex review clean after thirteen rounds. Verified in the browser: portal, billing and console render unchanged off the new catalogue. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-26 12:05:56 +02:00
nexxo	52b41bb0d5	fix(billing): a paid order opens a contract, and provisioning obeys it ... The pipeline re-resolved config('provisioning.plans') by order.plan, so the subscription snapshot protected a customer's price but not their machine: shrinking a plan resized an existing customer's VM on its next run. Nothing created a subscription either, so closing this meant opening the contract at purchase and pointing provisioning at it. - OpenSubscription freezes the catalogue onto a subscription when a checkout is paid; StartCustomerProvisioning calls it inside the order transaction. - CustomerStep::plan() reads the frozen snapshot. ValidateOrder and ReserveResources fail closed with no_subscription rather than falling back to the catalogue, which is the bug itself. - template_vmid joins the snapshot so a re-clone cannot pick up a blueprint published after the sale. Deliberately outside FROZEN: it is how we build the machine, not a term the customer is owed, and a dead template must be replaceable without cancelling a contract. - TrafficMeter reads the allowance off the contract too — cutting a plan's traffic was otherwise enough to start throttling someone who bought more. - The migration backfills contracts for orders that already bought something, reconstructed from what was actually delivered where an instance exists, and adopts an existing order-less contract instead of opening a second. Orders paid in a currency the catalogue cannot price get none, matching the checkout path. price_cents stays the catalogue's NET price, which is what PlanChange prorates against — not Order::amount_cents, which holds Stripe's GROSS total. Reconciling the two belongs to the proof register and Stripe (phases 4/5). Also pins STRIPE_WEBHOOK_SECRET blank in phpunit.xml: the operator's real secret was reaching the suite from .env and rejecting every unsigned test payload, which is why 7 webhook tests failed before any of this. Verified in the browser: with team traffic cut from 3000 to 500 GB in the catalogue, the customer's portal still shows 3 TB. 373 tests green. Codex review clean after three rounds. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-26 11:10:00 +02:00
nexxo	0dde76ad55	docs: handoff for the plan catalogue rebuild ... Design is decided and Codex-reviewed; none of it is built. Records the live split-brain bug to fix first, the three-table catalogue, computed availability, the proof register with frozen add-ons, the Stripe split, what already exists, and the working rules that cost time this session. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-26 10:43:17 +02:00
nexxo	6119044669	fix(billing): no plan changes after cancellation, no unknown terms ... A cancelled subscription still reported an upgrade as allowed and priced it, so a caller trusting that would have provisioned and billed a customer who had already left. And any term string other than the two we support was silently priced monthly while keeping the unknown value — a subscription whose price and billing period disagree. Both are refused now. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-26 09:57:53 +02:00
nexxo	35324b986a	fix(billing): no free upgrade in the last hours of a term ... Flooring the remaining time made an upgrade with under a day left cost nothing, and an upgrade requested after the period had ended cost nothing while being applied immediately — the bigger plan for free. Remaining time now rounds up while any service is left, and an expired period defers the change to the next term instead of pricing it at zero. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-26 09:55:53 +02:00
nexxo	52b1acbb80	fix(billing): a scheduled downgrade must be applicable, and never cost money ... Once the term is over, the downgrade has to be allowed — otherwise the job that is supposed to carry it out never can, and the change waits forever for a date that has already passed. And a grandfathered plan can be cheaper than the smaller plan costs today, which made the goodwill credit negative: an invoice for the privilege of downgrading. Clamped to zero. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-26 09:54:16 +02:00
nexxo	460fac01b1	fix(billing): upgrade or downgrade is decided by rank, not by price ... With grandfathered prices the comparison inverts: a business plan bought when it cost less than today's team plan would have treated a move to team as an upgrade — charged immediately, while the customer loses resources. The plan's rank is frozen with the rest of the snapshot and decides the direction; prices only decide the amount. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-26 09:52:28 +02:00
nexxo	ac250071cb	feat(billing): immutable subscription snapshots and pro-rata plan changes ... The plan catalogue describes what we sell today; a customer who signed up last year bought last year's terms. Every commercially relevant condition — price, quotas, seats, the hardware behind the plan — is now frozen onto a subscription at signup, and the model refuses to let any of it be rewritten afterwards. A price rise applies to new subscriptions and cannot reach back into an existing contract. PlanChange holds the two rules, computed against the frozen price rather than today's catalogue: - Upgrading is immediate and pro rata: the new plan for the days left in the paid term, minus what the old plan was worth over those same days. On the last day of a month that is one day's difference, not a month's. - Downgrading waits for the end of the term. A yearly customer bought a year and can move down when it is up; a month is a month. A mid-term downgrade is a goodwill decision, not a self-service button, and its credit covers only the unused part of the difference. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-26 09:49:48 +02:00
nexxo	c36ea17b39	fix(billing): normalise both sides of the VAT comparison; cast the timestamp ... A verifier that returns the number in display form ("DE 811 907 980") would have failed the comparison against the normalised current value and silently switched a genuine reverse-charge customer back to domestic VAT. Both sides are normalised now, and vat_id_verified_at is a real datetime rather than a string. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-26 09:36:07 +02:00
nexxo	5aef5e693c	fix(billing): verification vouches for a value, not for a row ... A timestamp alone said "some number was checked once": editing the field left it intact, so a customer could swap a verified foreign VAT ID for any plausible-looking one and keep zero-VAT pricing. The verified value is stored and compared, which makes the rule self-enforcing — no writer has to remember to clear a flag, and there are several writers. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-26 09:34:40 +02:00
nexxo	42ceafb57f	fix(billing): a self-declared VAT ID must not zero the tax ... Any non-empty string starting with two characters other than AT switched the customer to reverse charge — typing "XX123" was a 20 % discount. Reverse charge now requires a VAT ID that is verified, belongs to an EU member state other than ours, and looks like a VAT number at all. Unverified is the normal state and means the domestic rate: over-collecting is correctable, under-collecting is a tax liability. Changing the number clears its verification. Verification itself (VIES) is not built yet, so reverse charge stays off until someone confirms a number — which is the safe direction to be wrong in. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-26 09:32:42 +02:00
nexxo	76510a59a3	fix(billing): VAT follows the customer, not a global setting ... Codex was right that this could misstate real charges: an EU business with a VAT ID registered in another country is billed under reverse charge, and we were adding 20 % Austrian VAT to their total anyway. TaxTreatment resolves it from the customer's VAT ID, and the whole page — cart, plan cards, add-on cards — now states one treatment instead of contradicting itself. Explicitly NOT handled: cross-border sales to private individuals, which are taxed at the buyer's national rate under OSS. That needs a maintained rate table and a tax adviser, not a guess, so those fall back to the domestic rate — over-collecting rather than under-collecting. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-26 09:30:17 +02:00
nexxo	ac3f429958	fix(billing): round the recurring figure the same way as the total ... The note rounded VAT after aggregating while the total rounded per order, so cent-level prices made the two disagree — and a customer who spots that stops trusting every other number on the page. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-26 09:27:02 +02:00
nexxo	9fab251fb3	fix(billing): make the one-plan-change rule hold under two clicks ... Both requests could finish their delete before either inserted, leaving exactly the two pending upgrades the rule exists to prevent. Replacement and insert now run in one transaction with the customer row locked. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-26 09:25:29 +02:00
nexxo	a87a4f512d	feat(billing): one plan change at a time, and every price says what it is ... Two contradicting plan upgrades sat in the cart at 799 and 399 € — no checkout could resolve which one the customer meant. Choosing another now replaces the pending one and says so; add-ons still stack, because buying 200 GB as two packs is a sensible thing to want. Every price now states net or gross and how often. The cart shows net per line with "pro Monat" or "einmalig", then subtotal, VAT and gross — and separates the monthly recurring amount from a one-off traffic top-up sharing the same cart, because those are two different commitments. The rate is configurable (CLUPILOT_TAX_PERCENT, 20 % default) since it follows the seller's country. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-26 09:23:49 +02:00
nexxo	55b1a1468f	fix(admin): the admin password is shown once, and means it ... The handoff stayed in the cache for its full ten minutes, so any replayed component request could fetch the plaintext again — "shown once" was a figure of speech. It is consumed on the first read and the token dropped; the payload reaches the view and nothing else. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-26 05:34:57 +02:00