206 Commits (main)

Author	SHA1	Message	Date
nexxo	cfaea7dc82	Fill the hostname page from the installation, not from a blank form ... The page was empty, and that was a design fault rather than a missing button. I built a register that starts blank — while the installation already serves half a dozen names whose certificates were exactly what the operator wanted to see. An overview you have to populate first does not answer "what do I have". So the names are derived now, from the same configuration routes/web.php builds its domain bindings from: SITE_HOSTS, APP_HOST, FILES_HOST, ADMIN_HOSTS. If a name is in the environment, the application answers on it, and then it belongs in this list without anybody typing it a second time. Opening the page syncs them; the list is never empty again. Syncing and measuring are deliberately separate. The sync costs nothing and runs on page load. The measurement goes out over the network and runs on the button or on a schedule — doing it on page load would mean waiting through half a dozen TLS handshakes, and one of them is always the name that currently does not resolve. Which is the other half of what was missing: there was no overview because nothing measured unless somebody pressed a button. A daily run at 04:17 fills it, because the question that matters is not "is it valid right now" but "is renewal running" — a certificate expiring in forty days is fine, the same one at twenty means something has been broken for a week. Only a measurement taken while nobody is looking can tell those apart. The page now opens with four counts — total, valid, expiring soon, without a certificate — and says when it last measured. A name that comes from the environment is marked as such and cannot be removed here: it would come back at the next sync, and a button that does nothing is worse than no button, because it gets believed once. 2040 tests pass, assets build. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-31 00:53:12 +02:00
nexxo	006ce3568b	Manage hostnames and watch their certificates from the console ... files.clupilot.com is why this exists. DNS pointed at the right machine, the env var was set, the release was deployed — and there was still no certificate, because /etc/caddy/Caddyfile is maintained by hand and nobody thought of it as a second, separate step. Nothing in the console would have said so. Three settings looked correct and the address did not answer. So the page holds two things side by side. The WISH — which names should be served — and the REALITY: whether the name has a certificate and for how much longer. The second is measured by opening a TLS connection and reading the expiry, not by reading configuration, because the configuration is exactly what looked right while the address was dead. verify_peer stays on: a certificate that fails validation is not a certificate for this question, and a display that called it valid would be the fake R19 records. Applying goes through the existing agent, not a new channel. The console writes a request, the path unit wakes the agent within a second, and the agent calls one fixed command line of the root-owned helper. What that helper is allowed to do is the careful part. It fetches the list ITSELF rather than being handed one, and the list is HOSTNAMES, never Caddy blocks — `php artisan clupilot:proxy-hosts` prints `<name> <purpose>` and nothing else. Each name is matched against a strict pattern before it is used, and the template around it lives in the helper, which the service account cannot touch. install-agent.sh already states the principle for the sudoers grant: a grant is only worth anything if the holder cannot change what it grants. A service account that could write proxy configuration would have everything the proxy can do — redirects anywhere, files from any directory. Purpose is a column rather than a habit. A console name gets the network lock, a public one does not, and a console name published without it looks exactly like a working page. Removing takes the name out of the list and NOT out of the running proxy. Two decisions in one click, and the second one takes a site off the air. There is deliberately no "renew" button. Caddy renews on its own at two thirds of the lifetime; what an operator actually needs is a second attempt after an issuance has failed, and that is a reload — which is what Apply does. Thirty days is treated as a problem rather than a warning: at ninety days' lifetime, a renewal should long since have run, so anything under it is not a tight certificate but a renewal that is not happening. The ACME contact falls back to the owner's address, because a contact nobody reads is the step before expired customer certificates. CONTRACT and HOST_STEP_NEEDS both move to 2, which is what tells a server carrying the older helper to run the installer again — caught by the guard test that compares the two halves. 2035 tests pass, assets build. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-30 22:55:55 +02:00
nexxo	398028a57d	Rebuild Add host as a page with one job, and let downloads through the gate ... The page was a wall. Six paragraphs of procedure stacked above a form, so the thing the page actually asks for — four fields — sat underneath an essay about what would happen afterwards. It answered everything and showed nothing. It is now built the way the settings page is built, because that page was rebuilt for the same reason and there is no case for a second idiom: an eyebrow, a title, a sticky rail on the left and panels of rows on the right. The rail carries the six steps as two-word labels rather than paragraphs. That is what the question at this moment actually is — where am I, how much is left — and it fits in 232 pixels. The numbers carry the state; a tick beside them would be a second sign for one statement, and a number can be counted. What a step MEANS now appears in the row where it is due, not six times in advance. The two provider steps get a panel of their own above the form, because they have to be done before you save: the one-time code starts expiring the moment you do. Everything after the form waits until there is something to say. After saving the command becomes the page. Full width, its own framed block with the warning in the header strip rather than floating above, and the two remaining steps below it as ordinary rows. Two token bugs went with it. `bg-canvas` does not exist — it was a class that compiled to nothing, which is part of why the block looked wrong. And `text-accent` on white is 2.9:1; the config says in as many words to use accent-text for anything read, so the current step number does. Also fixed, and it would have broken every takeover in production: PublicSiteGate is appended to the whole web group, so while the site is hidden a server in a rescue system fetching the archive would have received the 503 placeholder and piped it into tar. The operator would have seen an unpack error on a machine only reachable through the provider's console, with nothing pointing at a switch in the admin area — and they are by definition neither on a management network nor signed in, since leaving that state is the whole point. Exempted by ROUTE NAME, not by hostname: the docblock rightly warns that exempting by host means trusting a header the caller picks, but that warning is about the entire portal. Behind these two routes are documents that are public anyway and an archive that 404s without a valid one-time code. 2026 tests pass, assets build. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-30 21:51:30 +02:00
nexxo	447d6fe0f3	Merge main into the host-takeover branch ... One real conflict, in SyncStripeCatalogue::handle(), and both sides were right. Main's parallel work resolves the adoption singletons and takes "before" counts so a run can tell created from adopted. The operating-mode work refuses a catalogue whose stored objects belong to the other mode, and records which mode the catalogue now belongs to. Kept both, with the mode guard first. It REFUSES, so it must not run behind anything that has already built state; the counters only need to be in place before the create loop, and they still are. Reversing that order would have the command resolve singletons and take counts on a catalogue it is about to reject. 2017 tests pass. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-30 21:21:45 +02:00
nexxo	2194ab8079	Put the instructions where somebody reads them before they start ... The previous commit shipped the guide AFTER the host was created. Its first two steps happen at the provider — order the machine, boot the rescue system — and whoever reads them there has the one-time code already in the clipboard with its 24-hour window running. The instructions were correct and in the wrong place, which is its own kind of wrong. Six steps now, not three, and the two provider ones are named rather than assumed. They are marked "first" so the list does not read as something you can start at the top of and work down: step 2 is half an hour of waiting, and doing it inside a running code is exactly the mistake the page should prevent. All six are visible the whole time, including the done ones and the ones still to come. A guide that shows only the current step cannot answer "how much is left", which is the question somebody has while a server they are paying for sits in a rescue system. It is on the hosts list too, collapsed. Somebody standing there may not have ordered the machine yet — and that is step 1. Requiring them to click "add host" to find out what the procedure is puts the answer behind the action it describes. One component, two places, so the archive address in the instructions is the same string the command line will carry. Two copies of that would drift, and the difference would surface on a server that has already been paid for. The step-4 command box moved into the guide rather than sitting beside it, so after creating a host the whole procedure stays on screen. Somebody stuck at step 5 should not be looking at a page that has become a single box. 1991 tests pass. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-30 20:51:47 +02:00
nexxo	903ebdd2b2	Give the operator one line to copy and three steps around it ... The console could describe a takeover it had no way to start. This is the vertical slice that closes that: a one-time code, the archive the rescue system fetches, and the page that says what to do with both. The command carries EVERYTHING the script needs before the tunnel exists, because there is nothing to fetch — that is the whole point of spec §5. Which means CluPilot generates the WireGuard keypair and admits the peer at the hub before the machine has ever booted, and hands the private half over in the line. It is worthless within minutes: task 9 of the script replaces it with one generated on the machine. Shown exactly once. The database holds only the code's hash and never the private key, so leaving the page does not bring it back — it mints a new code, which invalidates the old one. That is deliberate: a glance at somebody's screen should be worth nothing an hour later. Which is also why save() no longer redirects. Sending the operator to the host detail page sends them away from the only value they need, and an existing test asserted that redirect — it now asserts the opposite, with the reason written next to it. SHA-256 rather than bcrypt for the code, and the reason is not speed. Both endpoints have to FIND the host by the code; with bcrypt that means trying every row. The code is 32 characters of CSPRNG output, so it has the entropy that stretching exists to manufacture. resolve() and claim() are separate because progress reports arrive BEFORE registration. If reporting consumed the code, a host could never register after its first message. The archive URL is always the public hostname. The console runs under admin.…, but this line executes on a machine that must not reach the admin area — it is locked down for exactly that reason — so route() from the console would emit a hostname that 404s on a server only reachable through the provider's console. The page warns about missing tunnel settings BEFORE the host is created, not after. An empty hub key produces a line that looks clean, copies fine, runs, and ends in a tunnel that never handshakes — discovered on the machine, after somebody has already paid for it. The three steps lead with the rescue system, because that is the one nobody knows by heart, and it says enabling is not the same as booting into it — the script refuses a running production machine, which is what a half-done switch looks like from the inside. 1986 tests pass. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-30 20:40:19 +02:00
nexxo	5883989552	Give settings the shape a settings page actually has ... Four attempts, and this is what was wrong with the last one: full-width panels stacked down the page, each carrying its own title INSIDE it. Every group had two frames — the title bar and the border — so the page read as a column of long boxes with nothing saying where one topic ended and the next began, and a phone number got a field a thousand pixels wide. The shape now: - **A section list on the left**, sticky, so the sections stay reachable however far a form runs. Below `lg` it becomes a scrolling strip of chips, because a vertical list on a telephone is four rows of nothing. Under it, who is signed in — on a shared office machine that is a real question, and a settings page is where it gets asked. - **A content column of 820px**, not the whole 1240 shell. - **The heading OUTSIDE the card it belongs to.** A section is a heading, a sentence, and then a card of rows. That single move is what stops them reading as boxes: the border now frames the fields, not the topic. - **What cannot be undone is last, in a card whose border says so** — the deletion deadlines and the close button together, at the foot of the contract section, in danger colours. The rows are unchanged (label left, control right) and so is every binding; what changed is the frame around them. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-30 17:59:16 +02:00
nexxo	880b5f1998	Merge main into the operating-mode branch ... Three real conflicts, and one file that did not conflict and mattered more. Overview::notices(): both sides added notices. Kept all of them, and pointed main's mail check at MailboxTransport::NON_DELIVERING — its own comment already named the constant while the code carried a copy of the list. billing.blade.php: main wrapped the page in a contract branch. The "payment is not set up" error moved OUTSIDE it, because the customer most likely to meet that message is the one buying for the first time, who has no contract yet and would never have seen it from inside the @else. ConsoleReportsRealDataTest: kept both sides rather than choosing. The renamed test and its docblock explain why admin.systems_ok can no longer be asserted on a bare install; main's mail pin still keeps "clean" clean in the mail dimension. Picking one would have quietly weakened the other's claim. HostStepsTest: git combined main's config()->set('provisioning.dns.zone', 'clupilot.com') with this branch's assertion on clupilot.cloud, and produced a test that contradicted itself with no marker. Main's approach is the better one — it pins the zone in the test and asserts the SHAPE of the name rather than this box's domain — so its assertion stands. HttpStripeClient merged silently and correctly: secret() still throws, isConfigured() still reads the vault directly. Had it taken main's filled($this->secret()), six callers that ask in order NOT to get an exception would have become exception throwers, and the suite would have stayed green. CheckoutWithoutStripeKeyTest is the lock that would have caught it. StripeIdempotencyKeyTest (new on main) leaned on the environment fallback for stripe.secret. That entry is strict now — no fallback in either direction, so the .env cannot be a back door for a live key in test mode. It stores a real vault row instead. 1966 tests pass. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-30 17:53:20 +02:00
nexxo	2a97d76b2d	Rebuild the settings page out of panels and rows ... **The withdrawal was invisible in two different ways.** It rendered only while the fourteen days were still running, so the moment they expired the whole block vanished — indistinguishable from a feature nobody built. And the account it was looked for on has no contract at all: no package, no subscription, nothing to withdraw from, so there was never anything for it to be about. It is now a row for every CONSUMER who has a contract, open or not: while it runs, the deadline and the button; afterwards, the sentence saying why it is over. A business never sees it — WithdrawalRight answers that, and Settings::withdraw() refuses them again on the server. And an account with no package says so and offers the packages, instead of a dead sentence in a box. **The page is built out of two pieces now.** x-ui.panel is a group: a card with a header that names it. x-ui.row is a setting inside it: what it is on the left, the control on the right, dividers between rows. That is the shape every settings page worth copying uses, and it is the shape that uses the width — a 280px label column with the control beside it fills the line, where a stack of full-width inputs leaves two thirds of it empty and a grid of cards of different heights walks down the screen as a staircase. All four tabs are rebuilt on it, so the page reads as one designed thing rather than four pages that happen to share a tab bar. Below `sm` the rows stack, because on a telephone a label belongs above its field. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-30 17:38:57 +02:00
nexxo	18193a731d	Stop asking for a signature the law does not want, and lay out the tab ... **The owner is right about the agreement.** Art. 28 wants a CONTRACT, not a ceremony — and a contract is concluded by incorporating the agreement into the terms the customer accepts at checkout, which is exactly how every hoster they have bought from does it. Nothing in the regulation asks for a second, separate click. What it does ask is that the agreement is in writing (electronic form included, Art. 28(9)), that it is the version in force, and that the customer can obtain it. So: the terms now say the agreement is part of the contract and needs no separate signing, and name where it is. The card states that rather than flagging the customer as outstanding — the warning chip is gone. The button stays, reworded to "Zusätzlich bestätigen": a practice or a firm that gets audited often wants an explicit record, and it costs a click. The console's counter says how many confirmed rather than how many are "open", because none of them are. **The contract tab was a staircase** — a short card, a wide one spanning both columns, then a short one again. It is one column of full-width sections now, each with the same shape: a header row carrying the state and its action, then the body. Nothing tracks sideways any more. The package section states its own state in the header instead of a paragraph in the body, the withdrawal sits under it as a row rather than a second card, and the agreement's four files each have a button — reading and keeping, agreement and measures, which the single "Herunterladen" could not express. Also: the generated version no longer carries "Aus dem Repository erzeugt (clupilot:publish-dpa)" in the console's list. That is the command line, not information. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-30 17:30:55 +02:00
nexxo	52aacddc56	Store the agreement where the web process can actually read it ... Every link on the agreement page answered 404 — the download visibly, the two inline ones just as dead — and nothing anywhere said why. The files were there, whole and correct. An artisan run inside a container is root; PHP-FPM is www-data. Laravel's local disk creates a PRIVATE directory, which is 0700, so `dpa/` came out as root-only. The web process could not enter it, `Storage::exists()` answered false, and the routes did exactly what they were told: abort 404. No exception, no log line, a page full of links to nothing. Both writers — the command and the console's upload form — now store with "public" visibility, which is the file MODE and nothing to do with the web: 0755/0644 instead of 0700/0600. The disk's root is outside the document root either way, and the two routes still check who is asking. The command also warns if a file it just wrote is not readable, because the alternative is finding out from a customer. The download itself now looks like one: the `download` attribute on both anchors, and in the console a bordered control rather than a third link in a row of two. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-30 17:19:39 +02:00
nexxo	d04ea712c7	Write the processing agreement and its annex, and let it be downloaded ... The mechanism shipped without a document. Both are here now, generated from this repository rather than uploaded — so the company is named from CompanyProfile exactly as the invoices name it, the sub-processor list is the three places customer data really leaves this application, and the deletion deadlines are read off the commands that enforce them. A wording change is a diff somebody can review, not a file that appears. `clupilot:publish-dpa 1.0` renders both to PDF (TCPDF, the engine the invoices already use), stores them on the private disk and puts them in force; `--draft` stops short of that. The console's upload form is untouched: a lawyer's revision arrives as a PDF and becomes a version like any other. **The annex says what this installation does, not what it would like to.** Every measure in it was checked against the code first — the isolation is one VM per customer because that is what provisioning builds, the backup is a daily snapshot job at 02:00 because that is what RegisterBackup creates, the deletion deadlines are the two prune commands. Claims the system does not currently keep are NOT in the document, and they are named in the handover instead. A TOM that promises more than the machine does is the document an auditor reads before looking. **Downloading** now carries the version in the filename — CluPilot-AV-Vertrag-1.0.pdf — so "which fassung did I agree to" is answerable from a downloads folder months later without opening anything. Both sides get the button; inline stays the default, because a contract is read before it is filed. Placeholder register data is left off the document rather than printed: a "FN 000000a" on a contract looks like a real number and is not one. Also: the wordmark scan tripped on a paragraph whose first word is the company name, for the second time. It now looks for the name as the whole CONTENT of an element, which is what a lockup is, rather than for the name after a tag, which is also how a sentence starts. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-30 17:12:30 +02:00
nexxo	823eeaf413	Refuse a key that does not belong to the slot it sits in ... put('stripe.secret', 'sk_live_REALMONEY') in test mode was accepted, get() handed it out, billing.stripe_secret reported satisfied, and the badge above it said "Testbetrieb". The strict rule closed the automatic route into that state (no fallback); the typed one stayed open. The prefix decides it without touching the network, and that rule now lives in ONE place — OperatingMode::ofStripeKey() — called by the three that were answering it separately: the slot migration (unchanged verdict, `?? Live` for a value it cannot place), StripeCheck's `live` flag (unchanged verdict, null stays false), and the readiness check, which never asked at all. A key it cannot place is not reported as a contradiction: this check only says what it can prove. The two directions get their own `breaks` sentence, because the consequences are opposite — real money moving while the console says test, versus no money moving while the order looks paid. The "Prüfen" button no longer contradicts the check either: the page rendered only ok/reason, so a live key in the test slot answered "Geprüft: in Ordnung". It now names the account the key belongs to. Red first: ⨯ it refuses a live key sitting in the test slot ⨯ it refuses a test key sitting in the live slot ⨯ it says what the wrong key does, not that a field is empty Guard tests (ConfirmInModal, ModalHeight, IconLayout, DisplayTimezone) run with the blade change: green. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-30 17:05:58 +02:00
nexxo	5094f70c19	Say which slot the value in force is really coming from ... Mode test, dns.token only in the :live slot, HETZNER_DNS_TOKEN also in the .env — the state this installation is in the moment the migration runs: get() -> "live-token-value" (the stored live row is in force) source() -> "environment" -> card reads "Aus der Serverdatei" outline() -> null -> no "Hinterlegt" block at all So the console sent an operator to the .env to rotate a token that the database supplies, where the edit would have had no effect. R19's dummy, literally: a display that reads like an answer, is wrong, and stops the next person looking. source(), outline() and updatedAt() now ask the same one place get() does (inForce()/fallback()), and the answer gets a THIRD value, 'stored_live'. Not 'stored': that shows the Vergessen button, which would then have pointed at the empty test slot. Strict entries (Stripe) still have no fallback in either direction — pinned by its own test. Red first (before the vault changed): ⨯ it names the live slot as the source when it is the one in force -'stored_live' +'environment' ⨯ it shows the outline and the date of the value that is actually in force Two existing expectations moved from 'none' to 'stored_live' with the reason written beside them: 'none' meant "nichts hinterlegt" about a credential that was in use. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-30 17:01:33 +02:00
nexxo	955f1b874f	Deliver the processing agreement, and hold the proof it was accepted ... Art. 28(3) GDPR wants a contract wherever personal data is processed on somebody else's behalf, which is the whole of what this product does. "In writing" there includes electronic form (Art. 28(9)), so a document the customer can read plus a recorded acceptance is enough — no signature on paper. The website already promises "AV-Vertrag inklusive", which means it has to be obtainable without asking us for it. It was not obtainable at all. **The text is never this application's.** An operator uploads the document their lawyer wrote, names the version, and publishes it; the measures ride along as a second file, because they are an annex to the agreement and "which measures applied when this customer accepted" has to have one answer. Inventing the text here would have been worse than having none. **Uploading and publishing are two acts.** Acceptance is per version, so publishing leaves every customer who accepted the previous one outstanding again — correct, and far too expensive to trigger by dropping a file on a form. It goes through a confirmation modal that says exactly that (R23). **The customer's side** is a card in the contract tab: read the agreement, read the measures, one press to conclude it. What that press records is what makes it evidence rather than a flag — the version, the moment, the address it came from, and the login that pressed. Pressing twice is one agreement (unique index, not a check somebody can forget), and a superseded acceptance is kept rather than overwritten: it was true when it was made, and the history is the point. Nothing renders until a version is in force. A card offering an agreement that does not exist is worse than the silence. The files live on the private disk and are served through routes that check who is asking — an agreement is not a public asset, and a guessable URL to one would be a list of who our customers are. The customer route takes no version parameter: which document applies is ours to say. `dpa.manage` is its own capability on the OPERATOR guard. Whoever keeps the platform running does not thereby decide what every customer is asked to agree to — and a capability written under `web` since the 2026-07-29 move lands in a guard nothing authenticates against, which is how this one first shipped answering 403 to a role that visibly had it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-30 16:56:57 +02:00
nexxo	1056dddc62	Take the address by field, fix the customer type, ask why they leave ... **The billing address was one textarea**, so what landed in it was whatever somebody typed: a postcode on the street line, a city with no postcode, no country at all. It is four fields now — street, postcode, town, country — in the customer's settings and in the console's customer editor, which had its own free-text copy of the same field and would have had an operator's correction silently reverted the next time the customer saved. `customers.billing_address` is neither dropped nor parsed: guessing which line of an existing block is the street would put a postcode where a street belongs on a document nobody can correct afterwards. It becomes the COMPOSED form, rewritten from the fields on every save, so IssueInvoice and everything else that reads it keep working, and a record nobody has re-saved keeps the block it always had. **The customer type is fixed once it is on record.** It decides the fourteen-day right of withdrawal, and a business able to set itself to "Privatperson" on this page is a business able to withdraw from a contract it may not withdraw from. Registration asks the question; this page reports the answer, and saveProfile refuses to answer it a second time — in the component, not by hiding a radio, because a form that hides a control has never stopped anybody who can post to /livewire/update. A record created before the question existed may still be given one, once. The panel is a fact rather than a form now, which is also what was odd about it, and the sentence about who has the right of withdrawal is gone. **Cancelling asks why.** A reason from a fixed list, required, with a note beside it that "Sonstiges" cannot go without — the one fact worth having about a departure, asked at the only moment the customer is looking at the question. It lands on the contract (`cancel_reason`, `cancel_reason_note`). And where the fourteen days are still running, the dialogue offers the WITHDRAWAL as a way out of itself rather than as one more reason inside it: withdrawing ends the service the same day and sends the whole amount back, cancelling keeps the term that was paid for, and somebody entitled to the first should not lose it by taking the second unasked. A business is never offered it — WithdrawalRight answers that, not the template. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-30 16:41:32 +02:00
nexxo	49d528dbea	Fix round: point at the real tab, hide the button nobody can press, prove the quiet page load ... Fixes four Important findings from the review of Task 12. Corrected nine check `tab` values at the source (BillingChecks was already correct; OnboardingChecks/ProvisioningChecks/DeliveryChecks all carried the pre-redesign 'integrations' value, which is not a member of Integrations::TABS): four onboarding checks now point at 'platform' or 'env' depending on where their field actually is, five provisioning/delivery checks point at 'services'. checkUrl()'s match-block resolver — praised as correct for the six checks that point at a genuinely different admin page — is unchanged; its `default` arm is now a pure safety net, not a route any check actually relies on. Wrapped the "Prüfen" button in @can('secrets.manage'): mount() admits hosts.manage OR secrets.manage, but runCheck() requires secrets.manage alone, so an Admin-role operator could see a button that 403s on press. Fixed a docblock on HEARTBEAT_KEYS that asserted a staleness threshold was kept in sync with OperationChecks::STALE_AFTER_MINUTES — that constant is a key/settings-name map with no threshold of its own, and no such synchronisation exists. Three new tests, each confirmed red against a deliberately reintroduced version of the bug it covers before being confirmed green: every check's tab value against where its field actually lives, the run-check button hidden from an operator who cannot press it, and Http::assertNothingSent() after a plain page load. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-30 16:26:10 +02:00
nexxo	1d4e98eb06	Rebuild the customer's settings page as four tabs ... It was one column 768 pixels wide inside a 1240-pixel shell — a third of the window empty beside it — holding everything a customer might ever change: the company address, their password, two-factor, the devices they are signed in on, the branding of their cloud, the contract, and the button that closes the account. Two thousand pixels of scroll, and the way to a particular thing was knowing how far down it lived. Four tabs, by what somebody came to do: their details, security, the appearance of their cloud, the contract. The same tab bar the console uses, so one vocabulary holds on both sides of the login, and the choice lives in the query string — `#[Url(history: true)]`, no `except`, so the parameter is there from the first render and a link to this page can name the part it means. An unknown tab out of the address falls back to the first rather than rendering a settings page with no section on it. The width is used now. Inside a tab the short cards sit side by side instead of each taking a full row to hold three lines: the customer type beside the company form (it is one question, and beside the VAT field it was mistaken for it), the password beside two-factor, the logo beside the colours, the contract beside the closing of the account. Also: the subtitle listed the old sections by name. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-30 16:25:10 +02:00
nexxo	8479fc30f8	Fix the checkout link, and stop the switch moving under the cursor ... **Every package button led to "Dieses Paket steht nicht (mehr) zum Verkauf".** The link was built as route() plus "?term=" + term — but both are QUERY parameters on this route, so route() had already opened the query string and the result was `?plan=team?term=monthly`. The package arrived as the whole string "team?term=monthly", matched nothing in the catalogue, and the page said so politely while giving no hint why. The address now comes from route() in one piece with a placeholder swapped into it, and a test asserts every checkout link on the page contains exactly one question mark. **The saving moved the buttons it belonged to.** It hung under the switch and was hidden on the yearly view, so choosing a term shifted the very control that chooses it. It sits above now and never disappears: one line, two wordings — an offer while it is an offer, a statement once it is taken. Same on the public sheet, where its vanishing re-centred the row. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-30 16:05:56 +02:00
nexxo	ff92466b47	Give the order a checkout page, and stop hiding what a year costs ... **There was no checkout page.** The package list posted straight to Stripe, so the last thing a customer saw in this product's design was a grid of cards and the next was somebody else's form asking for a card number. What they were buying, what it costs in total, what happens afterwards and what they were agreeing to were never stated in one place. App\Livewire\Checkout is that place: the package and its figures on the left, a sticky summary on the right — net, the saving where there is one, the setup fee, the tax, what is due today, and what will be charged after it. Every figure comes from the catalogue, TaxTreatment and SetupFee, the same three the checkout itself reads; nothing is recomputed, because a summary that works out its own total is a second answer waiting to disagree with the one Stripe is handed. **The terms acceptance moved to where the money is spent.** It sat at the top of the package list as a condition of LOOKING at prices, with every button dead beneath it. It is a condition of buying, so it is now at the foot of the summary, directly above the button — after the total, which is the order those three things are read in. The package list has no form on it at all now; its buttons are links. **The page used the left half of a 1240px shell.** A 68-character title, a switch under it and an 80-character footnote, beside a grid that used the whole width. Now: a header band with the name left and the term switch right, where a control belongs, and a closing band of three columns instead of a paragraph trailing off. **The yearly view showed the monthly equivalent as its headline**, so on a package with no free months the big figure did not move at all when the switch was thrown — the page looked like it had ignored the click. The headline is the price of the term in the unit it is charged in; what a year works out to per month is said underneath. Same on the public sheet. **The switch was unreadable.** `text-on-ink` is not in this palette — the ink pairing is bg-ink/text-bg, as x-ui.button has always had it — so the label kept its inherited grey on a near-black pill. And its shell was rounded-lg with rounded-md options inside: two radius scales, one of them Tailwind's untokenised 6px. One scale now, nested. **The mails drew an empty orange tile.** The mark's ascent lives in an SVG the site loads and a mail cannot — Gmail strips inline SVG, Outlook renders with Word, and this layout carries no image by design. The shape is drawn with a character every mail font has, white on the accent tile, with the whole wordmark beside it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-30 16:00:08 +02:00
nexxo	e83b17ec37	Put every missing field on one page before a customer pays ... Admin\Readiness renders App\Support\Readiness::byGroup() end to end: state, label, breaks sentence and a fix link for every check, a button on the four that have to ask a real service (DnsTokenCheck, WireguardEndpointCheck, VmTemplateCheck, StripeCheck) and only ever run on demand, and one headline line — ready for the operator's current mode, or how many blocking items are still open. Wired into the nav and into Overview's own notice list beside the same gate as Admin\Integrations, since both halves it configures come back together on this page. Fixed two check keys the guard test caught for real: onboarding.ssh_key and delivery.inbound_password did not textually contain the vault key they check (ssh.private_key, inbound_mail.password), which is exactly the kind of silent gap this whole task exists to catch. Renamed to onboarding.ssh_private_key and delivery.inbound_mail_password, with the two existing test files that referenced the old keys updated to match. Also fixed the guard test's own assertion: Pest's toContain() is variadic, so a second string argument is a second required substring, not a failure message (the same trap tests/Feature/ModalHeightTest.php already documents about itself) — it failed on every entry, including ones already covered. Replaced with str_contains()+toBeTrue(), which keeps the check and the message both. Two pre-existing Overview tests assumed a bare install has nothing to report; it now correctly always starts with a readiness gap, so both were narrowed to what they actually test — no invented data, no invented incident. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-30 15:59:34 +02:00
nexxo	b32c6fc33f	Sell the year as well as the month, and say what it saves ... Both prices have existed since the catalogue did — one `plan_prices` row per term, each with its own Stripe Price, and the checkout has taken a `term` all along. Nothing ever sent one. The shop showed the monthly figure, the order page posted no term, and the yearly Price sat there being paid for by nobody. **The console asks for free months, not a second price.** It used to take the yearly TOTAL as its own free-form figure, so nothing in the system knew WHY 588 belonged to a package costing 49 a month — and no page could say "zwei Monate gratis" without a person working it out again and writing it somewhere it would then drift. Now: the monthly price and how many of the twelve months are free. The total is derived from the two (PlanVersions::yearlyCents), previewed live on the form, and written to the catalogue from the same arithmetic. `free_months` sits on the VERSION, beside the capabilities publication freezes, because that is what it is — part of the terms a customer bought. The migration reads it back out of the prices that already exist rather than defaulting to nought: an installation selling twelve-for-ten must not lose that on a deploy. Only an exact division counts; a hand-negotiated yearly figure keeps its amount and simply goes unexplained. **The customer chooses.** A switch on the order page and on the public sheet, both figures rendered and one shown, so switching costs no request. The headline stays "per month" in either term — a yearly total as one big number reads as five times dearer at a glance — with the amount actually taken, the net figure, the months free and what twelve monthly payments would have cost underneath. The form posts the term the customer was looking at, and the checkout picks that term's Stripe Price. The billing card now says which term is running. It states a monthly figure whatever the term, so a yearly customer was reading a number that never appears on a statement. Also: **a Blade comment must never spell a directive.** Blade compiles what is inside `{{-- --}}` too — the comment is stripped from the output, but its directives are compiled on the way there. A comment explaining why the parenthesised php directive had been avoided produced exactly the open PHP tag it warned about, and the rest of the file was swallowed as PHP source: no exception, no warning, the page one block short. That is how the term switch vanished after being written. BladeCommentsTest scans for the forms that open a tag. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-30 15:44:35 +02:00
nexxo	fe1110de71	Fix round: name the slot on the card, and cover the modal that already worked ... Names which of the two slots a card actually reads and writes right now, at the card an operator types into (not only the page-top badge) — save() and render() resolve without a mode argument, so the card looked identical in both modes while quietly acting on whichever slot was active. Also adds the ConfirmSwitchMode coverage IntegrationsPageTest already carries for ConfirmSaveSecret/ConfirmForgetSecret: a modal is reachable without the page's route middleware, and reading the code is not the same as testing it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-30 15:32:16 +02:00
nexxo	fed4acf31c	Accept terms instead of a start date, and fix the sender no server accepts ... **The test mail was rejected: "553 5.7.1 Sender address rejected: not owned by user no-reply@…".** Every purpose mailbox here has its own SMTP account, and a mail server lets an account send only from the address it owns. Mail::to() hands back a pending mail bound to the DEFAULT mailer and sendNow() then ignores the mailer the mailable asked for, so a mail addressed support@ went out over the no-reply@ login. It sends through the mailable's own mailer now, and the cloud-ready preview — the one mailable with no mailbox at all — takes the provisioning mailbox like the real notification does. Writing the test for that found the same bug in production code: **InvoiceMail and OrderConfirmationMail set their From to billing@ and never named a mailer**, so both went out over mail.default's no-reply@ login. On this installation no customer had ever received an invoice mail or an order confirmation; they rendered perfectly, queued without complaint and were refused at the door. MailSenderOwnershipTest now scans for the mismatch: a mail that takes a mailbox From must use that mailbox's mailer. **The box on the order page accepts the terms now**, not an immediate start. It used to carry the whole FAGG §16 sentence, which read like a choice between "now" and "in fourteen days" — and there is no second option. The terms are what regulate the sale, so they had to exist: resources/views/legal/terms.blade.php replaces the placeholder with fourteen sections written from what this software actually does — the delivery, the capacity queue, the full refund on withdrawal, the cancellation at period end, the deletion deadlines. The company data comes from CompanyProfile, so the page and the invoices cannot drift. No availability figure and no liability cap has been invented. No order goes through without it: the button is unusable until the box is ticked and says why, and CheckoutController still refuses server-side — the browser half refuses nothing. The request field is `terms_accepted`; the Stripe metadata key stays `immediate_start`, because a session opened before a deploy is paid after it and the webhook would find nothing under a new name. **"Wird der Account nach fünf Tagen gelöscht?"** Only an unconfirmed one. That was the whole of what we said, so the answer looked like yes. The second rule now exists and is stated: PruneDormantAccounts removes a confirmed account after a year when it never had a package — no customer record at all, which is where every order, contract and seven-year invoice hangs. A fortnight's notice goes out first, once, and `dormant_warned_at` is what permits the deletion: an account whose warning never went out is never removed. Signing in resets the clock, measured off the device rows because users has no last_login_at. Both deadlines are said in the portal settings, on the verification page, and in the terms — each reading the number off the command that enforces it. Also: the wordmark scan matched any element whose text merely BEGINS with the company name, which a paragraph of terms does. It looks for the lockup form now (no whitespace after the tag), which is what it was always about. The seven checkout tests in the parallel session's files were posting the old field name and now post the new one. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-30 15:22:35 +02:00
nexxo	96f171b3b3	Put the switch where it governs, and say when it is thrown ... Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-30 15:09:38 +02:00
nexxo	c354ad1463	Make mails readable on a phone, and let an operator look at one ... Three things the owner reported, and one sentence that promised something this product does not do. **The mails had a fixed width.** components/mail/layout.blade.php set width="600" and width:600px, so every phone showed a 600px canvas in a 390px window and one had to scroll sideways to read a sentence. Now the table is width="100%" with max-width:600px — fluid, with 600 as a ceiling rather than a floor. A mail cannot fix this with a media query (Outlook renders with Word and drops <style> blocks), which is why the whole file is inline attributes and why the shrinking has to be built in. Side padding went 40px -> 24px in the layout and in all nine mail views: 40 each side leaves 278px of a 390px screen to read in. **There was no way to look at a mail.** An invoice mail needs an invoice, a maintenance announcement needs a window, and "register an account to see whether the confirmation reads well" is not a workflow — which is how the fixed width survived for months. App\Services\Mail\MailPreviews builds all nine from sample data, every record with make() and never create(), so a preview leaves no invoice, order or window behind and draws no number from a series. Two ways to see one: in a tab as the document itself, or sent to the signed-in operator's own address. There is no recipient field — that would be a form for mailing strangers. sendNow(), not send(): every mailable here implements ShouldQueue, and send() defers to the queue for those, which would have put a failure in a worker's log while the button reported success to somebody waiting for the mail. The test caught that. **The booking page had no shell.** Order declared layouts.portal — the bare shell the sign-in pages use, no navigation and no padding — so the page sat flush against the top and bottom of the window with no way back to anything. layouts.portal-app, like every other portal page. **The consent box said something untrue.** Its refusal read "otherwise we can only build your cloud once the withdrawal period has ended", which describes a path that does not exist: nothing here delivers fourteen days later, and an unticked box simply means no order. Said plainly now, and said on the page before somebody runs into the refusal. Also: GrantedPlanPortalTest asserted assertDontSee('179'), which matches any id containing those digits — and ids climb through a suite run because a rolled-back transaction does not reset an auto-increment counter. It passed alone and failed in company. Asserts on '179,00' now, which is what a leaked price would actually look like. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-30 14:50:37 +02:00
nexxo	3e7026407b	Stop inventing a package, and rebuild the booking page ... Two pages said opposite things about one account, straight after registering: the dashboard said "noch keine Instanz", and Paket & Addons said "AKTUELLES PAKET Start — Status Aktiv". The dashboard was right. The package page fell back to `$instance?->plan ?? 'start'` and rendered that fallback as a contract the customer had entered into, complete with a status of Aktiv, on the one page somebody opens to find out what they pay. The contract is resolved from the CUSTOMER now, not from the instance — a paid order parked for want of a machine has a subscription and no instance yet, and asking the instance would tell somebody who has paid that they have no package. An instance counts as well, whatever its subscription row says. With neither, the page says so and points at the booking page: an "Upgrade" from nothing is a purchase, and that has its own page. The cart stays outside that gate. A customer can have something in it before they have any contract at all, and hiding it there would hide the thing they came to pay for — which is what my first version did, and seven existing tests said so. And the booking page. Five cards in a four-column grid left the fifth alone on its own row, reading as a mistake; the consent box sat at the BOTTOM with every buy button disabled until it was ticked, so the page arrived looking broken before anybody had done anything wrong; and the price ran across the card in one block with nothing to compare. Now the consent comes first, because it is the condition for everything under it, and it colours itself green once given. Three columns, so five plans read as 3 + 2. Each card is the same four rows in the same order — price, delivery, what you get, the button — so the eye can run across a row and compare like with like. The button stays ENABLED with the reason it will not go through said under it: a disabled control explains nothing, and the server is the gate either way. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-30 14:29:22 +02:00
nexxo	2321854967	Discard an unconfirmed registration, and sweep the abandoned ones ... "Abmelden und neu registrieren" was advice that could not work. Signing out frees nothing: the address is still held by the unique index, so registering again with the address somebody meant fails — and every abandoned attempt stayed in `users` for ever. Reported exactly that way, and it was right. The button discards the account instead. Only an UNCONFIRMED one, and only one with nothing behind it: the webhook creates a customer's login from a paid checkout, so a user can sit on this page unconfirmed while already having a contract, and deleting that is data loss dressed up as a convenience. It refuses and says where to go. A confirmed account is closed, not discarded — that is ConfirmCloseAccount, with an invoice history behind it. R23: confirmed in a modal. The modal mutates nothing; it dispatches the event the page listens for, so the checks stay in the one place they already are rather than being duplicated where they could drift. And nothing has to be discarded by hand. clupilot:prune-unverified removes registrations nobody confirmed after five days — long enough for somebody who signed up on a Friday and found the mail in a spam folder on Monday, short enough that a typo does not hold the correct address for a month. It skips a confirmed account whatever its age, and any account with a customer record behind it, matched on user_id AND on the address, because either link means somebody is a customer. Every removal is logged with the address: a line that disappears is what somebody asks about later, and a count answers nothing. The deadline is said on the page as well as in the mail. Somebody who never received the mail is looking at the page, and the deadline is the reason they do not have to do anything about an attempt they abandon. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-30 14:08:02 +02:00
nexxo	f49f1dca09	Say when no mail is being delivered at all ... "Ich versuche mich zu registrieren, erhalte aber keine Verify-Mail, auch nicht beim erneuten Senden." Traced rather than guessed, and the evidence is in storage/logs: the address appears three times, so the mails were built and handed to a transport that writes them to a file. MAIL_MAILER=log. MailboxTransport::resolution() short-circuits on it — NON_DELIVERING is ['log', 'array', null] — so every purpose mailer becomes the log transport however well the five mailboxes are configured, which is correct for a development machine and exactly what was happening here. The reason it deserves a notice is that the failure is silent in every direction an operator would look. Mail::queue() succeeds. No job fails. The queue empties. And the console's own mailbox test reports SUCCESS, because MailboxTester builds its own transport on purpose — a check that honoured MAIL_MAILER=log would report success while writing to a file. So every instrument on the page said fine. Now the front page says it, linked to the mail page, and the mail page says it above the mailboxes it makes decorative. All three swallowing values are named, not only 'log': array and an unset default do the same thing, and a notice that only knew about one would be silent in the two cases nobody thinks to check. Two existing tests asserted that a clean installation raises no notice, and went red — correctly, because phpunit.xml forces MAIL_MAILER=array so a suite cannot send mail. They pin a delivering mailer now: the warning is about the environment, those tests are about the estate. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-30 13:55:55 +02:00
nexxo	f9993a1f48	Name the server variable under a credential, not the internal key ... Under each credential stood `stripe.secret`, `dns.token`, `inbound_mail.password`, `monitoring.token` — identifiers out of SecretVault::REGISTRY. They mean nothing on a settings page and there is nowhere an operator could type them; asked about directly, and the answer is no, that was not deliberate. The env variable name is the useful one: it is what stands in the server file, it is what the .env tab of this same page lists, and when the badge beside it says "Aus der Serverdatei" it answers the obvious next question — which line? The registry key stays where it belongs: in wire:key and in the modal arguments, as an identifier nobody reads. The test asserts on the text node rather than on the key's absence from the HTML, because absence would have demanded breaking the page to pass. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-30 13:20:29 +02:00
nexxo	a84251260c	Read the mailbox password where it actually is, and let the console test it ... The inbox kept saying no mailbox was set up while the password sat right there on the settings page. isConfigured() read config('services.inbound_mail.password'), which is only ever the .env value: this project deliberately does not overlay stored secrets onto config at boot — SecretVault's own docblock says so, and HttpMonitoringClient reads its token at the point of use for exactly that reason. My docblock even asserted the opposite mechanism, which I never verified. It reads the vault now, and falls back to .env because SecretVault::get() already does. And a way to find out. "Verbindung prüfen" saves the form first — testing what is on screen while the server still holds the previous values would report on a mailbox nobody configured — then performs the same four verbs the real fetch performs: LOGIN, SELECT, SEARCH UNSEEN. A check that proves something easier than the actual job is worse than none. What it reports back is one of five fixed words, never the server's own prose: an IMAP error carries the command it failed on, and for LOGIN that command contains the password. Each word maps to a sentence an operator can act on — address and port, mailbox and password, the folder. The line saying when the mailbox was last reached is on both pages, and it is written by the SCHEDULED run as well as by the button. Otherwise "last checked" would mean "last time somebody pressed a button", which is the less interesting of the two: a mailbox that stopped answering at three in the morning is the one worth seeing, and nobody presses a button at three in the morning. It is also shown when the answer is "never" — an empty inbox and a mailbox that stopped answering look identical, and this line is the whole difference. A fetch against a mailbox that just refused the login now takes nothing in and records the refusal, rather than reporting "nothing new" — which was true and useless. Also: HostStepsTest asserted the literal clupilot.com for a host name. That was true until CLUPILOT_DNS_ZONE was set to clupilot.cloud on this installation, and then a correct configuration failed a test. The zone is pinned in the test now; what it is about is the shape of the name and which address it carries. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-30 13:12:29 +02:00
nexxo	32a8bd9a88	Refuse the sale instead of reaching Stripe without a key ... Task 5: Billing::purchase() now checks SecretVault for a stripe.secret before touching anything else — no customer, no plan lookup, no Order row — and the customer reads a plain sentence instead of a 500 page. HttpStripeClient's own secret() throws the same StripeNotConfigured exception rather than sending a request with an empty bearer token and letting Stripe's 401 stand in for the real cause. isConfigured() was fixed alongside it: it used to call secret() too, which would have turned every "is Stripe set up?" check (the checkout controller, the catalogue sync commands) into an uncaught exception the moment a key went missing — the opposite of what this task is for. It now reads the vault directly. The new guard is unconditional, including for the cart-only purchase types (storage, addon, plan changes) that never call Stripe themselves — a cart order nobody can ever pay for is pointless to create. That broke every existing Billing/Cart/Downgrade test that calls purchase() without a stored key; each affected fixture now deposits one via the new withStripeSecret() Pest helper. A few of those tests (CustomDomainAccessTest, DowngradeTest) were passing already but for the wrong reason — the new guard, not the check they were named for — since both only assert an order was NOT created; they get the same fixture fix so they still prove what they claim. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-30 11:58:01 +02:00
nexxo	9da1358802	Stop charging VAT to the customers who owe us none ... A verified EU business outside Austria gets reverse charge — rate 0, no VAT line, the note on the invoice — and was still charged 214,80 € for a 179,00 € package, because one Stripe Price carried the domestic gross for everybody. There is no VAT line on their document to reclaim, so it was a flat 20 % surcharge on exactly the customers who read their invoices, and the document then stated the whole 214,80 € as net at 0 %, so they self-accounted their own VAT on a base a fifth too large. A Stripe Price can ask who is buying after all: there are two per sellable thing now, the domestic gross and the bare net, both live on one Product, and the checkout picks by TaxTreatment. The rule is Austria B2B 20 %, other EU B2B without VAT — a domestic business still pays the gross, reclaims it as input tax, and the price on the website is still the price charged for them. - stripe:sync-catalogue mints and archives both halves of every pair, per plan and per module; `reverse_charge` on stripe_plan_prices/stripe_addon_prices says which is which, and joining it on subscriptions.stripe_price_id says which one a running contract is billed on. A rate change moves the gross Price and leaves the net one alone, because the net owes nothing to the rate. - A status that changes after the sale converges: a verification (or a lapse) makes stripe:reprice-subscriptions move the contract onto the other Price with PRORATE_NONE, because the term is already paid for. The module items follow the same way. - Downstream follows: the invoice total equals what was taken, the proof register expects the figure this customer is actually charged (so a correct reverse-charge sale is no longer flagged as a mismatch, and an overcharged one is), the setup fee obeys the same rule, and the booking page quotes what it will charge. - StripeClient gained activatePrice(). Archived Prices were brought back in our own table and left inactive at Stripe, so a rate that moved and moved back pointed the catalogue at a Price no checkout could be opened for. An unverified number is still charged the gross — an unchecked string must never be a discount — and where the net Price is missing the checkout refuses rather than reaching for the domestic one. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-30 02:15:41 +02:00
nexxo	8ca0d4d257	Say the same thing to the customer, the register and the bank ... Five places where the product told somebody a figure that nothing behind it produced. **The invoice page showed five invoices nobody was ever issued.** A mock that outlived its purpose: CP-2026-0003 to CP-2026-0007, a prefix belonging to no configured series, all "paid", a spend curve from 179 to 198 € and a next charge of 198 € on 01.08.2026 — behind ['auth','verified','customer.active'], so every signed-in customer saw it. Their real invoices existed in `invoices`, were rendered as PDFs and mailed to them, and appeared nowhere in the portal at all. The page now lists their own documents, newest first, with the numbers, dates and totals off the frozen snapshot, a Storno marked as one, and a download. The PDF route resolves the document against the signed-in customer in the query — a URL anybody can type is not made private by not printing it. No next charge and no chart: nothing here computes what Stripe will take next cycle, and a figure nobody has worked out is worse than a blank space. **The setup fee was quoted everywhere and charged nowhere.** On the price sheet, on the booking page, set by the operator in the console — and CompanyProfile::setupFeeCents() had no reader outside the two sentences that quoted it. It is charged now, as a second non-recurring line on the same checkout session, which Stripe puts on the initial invoice only. `orders.setup_fee_cents` records how much of the charge it was, so the whole total still goes back on a withdrawal while the register holds the PACKAGE's charge against the contract price and the invoice prints the fee as a line of its own. The booking page was also quoting the fee NET under the same sentence the website quotes GROSS — 99,00 against 118,80 — and now quotes what will be taken. **An upgrade click cancelled a booked downgrade and delivered nothing.** Nothing in this application marks a cart order paid, so the customer traded a downgrade they had genuinely booked for a cart line that would never be fulfilled. The booking now stands until the upgrade actually lands on the contract, where ApplyPlanChange clears it. The fulfilment seam is reachable for every type that can be paid — a module and a storage pack book through BookAddon, which was the missing path from a paid order to a SubscriptionAddon and left AddonPrices, SyncStripeAddonItems and clupilot:end-cancelled-addons with no caller behind a payment. A paid traffic pack logs an error rather than pretending: the metered allowance is a standing count of packs while a top-up is sold for one month, and which of the two is meant is not a guess to make here. That no path to `paid` exists yet is now stated in both places rather than in one. **The proof register called correct charges wrong.** expected_gross_cents used the CUSTOMER's rate, which is zero under reverse charge, against the domestic gross Stripe actually took — so matches_catalogue was false for every EU business sale charged exactly the advertised amount, and for every renewal on a contract with a module, which was held against `price_cents` alone. It compares against TaxTreatment::chargedCents() and against the whole term now. Where no money moved, charged and the flag are null instead of the expected figure agreeing with itself, and a plan change records the terms with the pro-rata figures in the snapshot rather than money that arrives again on Stripe's proration invoice. **The seller's own VAT id was on the invoice, unlabelled**, between the register number and the court. Labelled — and the footer's composition moved out of the TCPDF method, because inside one the only way to read what it says is to render a PDF and un-subset its fonts. One test enshrined a figure the code does not produce: a reverse-charge purchase recorded with no charged amount, asserting 17900/0/17900, where OpenSubscription always passes the charged figure and a real one records 21480/0/21480. Another asserted that an upgrade click cancels a booked downgrade. Full suite: 1676 passed. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-30 01:30:24 +02:00
nexxo	0a89695189	R24: a modal is never taller than the screen ... A modal grew with its content, so a form ran off the bottom of the window and took its own save button with it — reachable only by scrolling the page BEHIND the backdrop, which on a phone means not reachable at all. The customer form with its eight fields is what made it obvious, but it was true of every long modal in the console. Two halves. The panel is capped once, in the published package view, so no modal can opt out of it and none has to remember to: max-h in dvh rather than vh, because on a phone the browser's own chrome counts towards vh and that is exactly the case where the last centimetre decides whether the button can be reached. And x-ui.modal is the other half — a header slot, a scrolling body, a footer slot. min-h-0 on the body is the line that makes it work: a flex child will not shrink below its content without it, and the overflow never engages. Fourteen modals converted: the ones that carry a field, which are the ones that can grow. A two-line confirmation with one button has nothing that needs to stay put, and the rule says so rather than leaving a footnote — the test's criterion is the field, so the moment somebody adds an input to a confirmation it fails and tells them. A submit button in a footer sits outside the form it submits, so it carries form="…". That is the price of a footer that does not scroll away, and an HTML attribute rather than a workaround; there is a test for it, because without it the button silently does nothing. Two traps met on the way, both now scanned for. A Blade directive in a component tag's attribute list (a conditional wire:poll on x-ui.modal) compiles into the attribute bag and breaks the view outright — the same mistake as @disabled on x-ui.button, which cost a debugging round earlier this session; such attributes go on an element of their own. And Pest's toContain() is variadic, so the second argument I passed as a failure message was read as another needle: the assertion demanded that a footer contain its own filename, and failed on a file that was correct. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-29 23:33:57 +02:00
nexxo	f00cbf18d3	Let an operator correct a customer's details ... The console could show them and not touch them, so a moved office or a new contact person meant impersonating the customer or editing the database by hand. Both are worse than a form. R20: a modal, opened from the Stammdaten tab, authorising again and reading the record itself rather than trusting anything the browser hydrated. Most of the work is in what saving must NOT quietly do. The customer type is never reset to "nobody asked". The field opens on "leave unchanged" precisely so that saving an address correction cannot undo it — that answer decides whether a withdrawal right exists, and losing it silently would be the expensive kind of quiet. A changed VAT number is unverified from the moment it is stored — the verification is bound to the value, so that happens by itself — but `vat_id_verified_value` is left alone: it is the record of what WAS checked, and clearing it would destroy the evidence rather than the claim. The address is also the sign-in address and the key inbound mail is matched by, so changing it moves the linked portal login in the same transaction and puts it back to unverified, which is what Laravel's own profile update does for the same reason: nobody has shown they can read the new address. No mail is sent from here — the portal asks for the confirmation at the next sign-in, and a mail an operator did not knowingly send is a surprise. Three addresses are refused: one belonging to an operator (R21 — no index spans the two tables, so it is checked), one belonging to another customer, and one belonging to somebody else's user row, which can outlive or predate a matching customer. Not offered here, each for its own reason: `status`, because suspending has consequences for access and a lifecycle switch hidden among address fields is one somebody flips by accident; `stripe_customer_id`, because a wrong one does not move a contract, it points our records at somebody else's payments; the brand fields, because the customer sets those for themselves and an operator overwriting a logo is not a correction. There is a test that fails if any of them appears — with the comments stripped first, since the class documents at length why they are absent and that documentation is not the offence. This repository has fallen into that trap three times. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-29 23:18:46 +02:00
nexxo	57c6912987	Say that a click landed, and make moving one actually move it ... "Man klickt und sieht nicht was passiert." Every action in this console is a round trip, and a round trip with no sign of itself reads as a click that missed — so the answer is in three places, from the general to the specific. A thin bar at the top of the window for any Livewire request, in app.js. Delayed by 140 ms, because a request that answers faster than that is perceived as immediate and a bar flashing on every keystroke of a .live field is worse than none. It creeps to 70 % and only completes on the answer: a bar that reaches the end while the answer is still on its way is a lie about the thing it exists to report. Released on failure as well — the request somebody must not be left waiting on is precisely the one that went wrong — and on wire:navigate, which is not a request hook at all and would otherwise leave the bar behind on a page that is gone. Per button: a pressed state on the way down, disabled while its own request is out, scoped with wire:target to that button's own call so a row does not grey itself out because a neighbour is moving. The edit button carries its own spinner, because opening the modal is a request made by the MODAL component — wire:loading on this page never sees it. It clears when the package announces the modal is up, and on a six second timer as well, so a request that never answers cannot leave a row spinning for ever. And the reordering was not only slow to look at, it was wrong. It added or subtracted a fixed amount: with the seeded values ten apart that usually landed right, and sometimes landed on a value another template already had — or on the floor along with three others. Equal sort values fall back to the name, so a click could reorder something else, or nothing, which is indistinguishable from a click that never registered. It swaps with the neighbour now: exactly one place, or nothing at the ends, both of which are what an operator expects to see. Where two shared a value the swap leaves them distinct, or the next click would do nothing again. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-29 23:06:30 +02:00
nexxo	173f05c1bd	Fix a cancel button that did nothing, and fit the answers on one screen ... The cancel button on the template modal was written with Alpine's $dispatch, which fires a browser DOM event — and wire-elements/modal listens for a LIVEWIRE event of that name. So it did nothing at all, while saving worked, which is the combination that makes somebody click twice and then close the tab. Every other modal in the repo already used Livewire.dispatch; this one was the odd one out, and nothing would have caught it, so there is now a scan that fails on the Alpine form. Narrowed to Alpine handlers deliberately: wire:click="$dispatch('closeModal')" IS Livewire's own dispatcher and works. The list was one column of thirteen entries, each carrying a name, a subject, two clamped lines of body and two full-width buttons — four screens to find the one you want, with the body preview taking most of the height while being the least useful part of it. The whole text is one click away in the modal. Now: two columns of one-line entries — name and subject, which is what tells two similar answers apart — with the actions as icons that do not compete with the name. The create form is folded away behind the button that creates one, because a form that is always open is a screen of form between the operator and the thing they came for. And the placeholder list runs as a grid across the page instead of a tall sidebar that squeezed the entries into half the window. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-29 22:50:16 +02:00
nexxo	f02e86769b	Charge the price the website shows, and hand a withdrawal back in full ... Stripe was charging the catalogue's NET figure while the document added the domestic rate on top: a customer quoted 214,80 paid 179,00 and was then invoiced for VAT nobody had collected. Under para 11(12) UStG that VAT is owed to the tax office whether or not it ever arrived, so every document issued created a liability against revenue that did not contain it. The Stripe Price now carries the GROSS figure. price_cents stays net - it is frozen onto every contract and PlanChange prorates against it, so redefining it would corrupt every pro-rata sum ever computed. Only the amount at the till moved, and it is formed by the one call TaxTreatment already answers for the price sheet and for the invoice, so displayed, charged and invoiced cannot drift apart. Stripe's automatic_tax is deliberately not used. TaxTreatment is the single tax authority here, and a second rate computed by Stripe would take 19 % from a German consumer while our document said 20 %. A Stripe Price cannot be edited, so a changed figure means a new Price and the old one archived - which stops it being SOLD and leaves every subscription already on it billing the old amount for ever. stripe:reprice-subscriptions is the second half, and a command of its own because it touches live money. A withdrawing consumer is refunded in full, as the owner decided. That is more generous than FAGG para 16 requires, and it makes the express-request consent the statute hinges on irrelevant - so the gate is gone rather than left looking load-bearing. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-29 22:42:02 +02:00
nexxo	33566cd404	Show the customer, and write the answers once ... Two complaints, one cause: the customer page was a compose box with three lists under it. It showed nothing ABOUT the customer, and every answer was typed from scratch. The page is five tabs now. Stammdaten — contact, phone, since when, language, and the tax standing: consumer or business, with "nobody asked" saying so rather than passing for business, because that answer decides whether a withdrawal right exists at all. Paket — the contract's own FROZEN figures, the modules at the price they were booked at, and the machine: address, state, host, datacenter. Zahlungen — invoices with net, gross and their PDF, and the orders beside them, because an order is a purchase and an invoice is a document about one. Nachrichten — the portal requests in the customer's own words, the mail they sent, the mail we sent. Schreiben — last, because it is what you do after reading. The tab is in the query string, like Settings and Integrations: a reload, a bookmark and the back button all land where the operator was, and a link can point at the tab that matters. And templates, under Betrieb → E-Mail-Vorlagen. Most customer questions are the same five questions, and typing the answer again every time is how two customers get told two different things about one subject. A template is INSERTED into the compose field with the customer's own details filled in — never sent as it stands, because the last two sentences always belong to the person asking. What goes out is what the operator saw and edited. Three decisions worth naming. {{contact}} takes the contact person where one is on record and the company name otherwise, because "Guten Tag Beispiel GmbH" is the line that gives away a mail written by a database. {{amount}} is the gross figure — what the price sheet quoted them and what their bank statement says. And a typo comes out as {{kunde}}, standing there in the field where the operator sees it, rather than as an empty string that produces "Guten Tag ,". A placeholder with no value for this customer stays empty; nothing is invented. Placeholders are named in English because they are identifiers, not prose: a template has to survive somebody switching the console's language. The list the page documents is the renderer's own, so a token added in one place appears in the other without being written down twice. Blade's echo tag ends at the first }} it finds, which turned a literal placeholder in the documentation into compiled nonsense. Assembled in PHP now, and caught by the test that renders the page rather than by somebody opening it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-29 22:37:30 +02:00
nexxo	e376b571be	Read the support mailbox into the console ... No, not an API token: mailcow's API administers domains and mailboxes — it does not read mail. Reading a mailbox is IMAP whoever runs the server, so that is what this is. Host, user and folder are console settings; the password is a vault entry, like every other credential that opens something. IMAP by hand rather than a dependency. Four verbs are needed — LOGIN, SELECT, SEARCH UNSEEN, FETCH — and the parsing that follows is the real work either way. It is bounded by what the console shows: a sender, a subject, the words a person wrote, and the NAMES of anything attached. Real mail from real people arrives encoded, so it handles RFC 2047 subjects (every German subject with an umlaut in it), quoted-printable and base64 bodies, Windows charsets, and multipart — text wins over HTML, because a console is not a mail client and the words are in the text part. A message it cannot make sense of is skipped and logged, never guessed at: a garbled question in front of an operator is worse than one they go and read in the mailbox, where it still is. ATTACHMENTS ARE NOT STORED. Only their names and sizes, so an operator knows something was attached and can go and look if it matters. Keeping whatever a stranger chooses to send would make this application a malware store with a web interface in front of it. Whose a mail is, is decided by the sender's ADDRESS and by nothing else — not by a name in the subject, not by anything in the body. A mail is easy to write and this decision attaches a stranger's words to a real customer's file; there is a test that forges the name and the subject and still gets nothing. An address nobody recognises stays unassigned, shown FIRST and never hidden: that is a new enquiry, or a customer writing from their private account, and it is the mail that must not be missed. An operator can place it by hand from the same row. Nothing is deleted on the mail server, ever. Messages are flagged seen once the row is safely written — and only then, because flagging first and failing after would lose the message with no second copy anywhere. Filing one away is this console's own state; the mailbox is untouched. Two fixes on the way past: the customer page printed "customers.status.active" and "support.status.open" — a lang key with no file behind it renders as itself and Laravel says nothing — and the same page is now covered by a test proving each list is scoped to the customer in the URL, which was reported as "unterhalb steht immer das selbe". Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-29 21:41:29 +02:00
nexxo	e0c109c449	Ask for the express request to begin, and send it to Stripe ... The withdrawal machinery has always read `immediate_start` off the checkout session's metadata — StripeWebhookController stamps `immediate_start_consent_at` from it, WithdrawalRight refunds pro rata when it is there and in full when it is not. The checkout never put it there. So every contract concluded through this application carried no consent, and a withdrawal on day thirteen of a running cloud took back the whole amount however many days the machine had run. That is the lawful outcome without the consent, and it was the only outcome available. Now the checkout asks. The box is required — validated `accepted`, not `present`, because an empty field is what an unticked checkbox sends and a consent that can be produced by leaving something blank is not a consent — and the metadata carries exactly the string '1' the webhook compares against. One box for the page rather than one per card: the sentence is the statutory wording and four copies of it is a wall nobody reads. The forms carry it as a hidden field bound to that box, and the buy buttons stay disabled until it is ticked. With JavaScript off the field arrives empty and the server refuses with the sentence explaining why — the safe direction to fail in. Ticking a box in a browser was never the record anyway: the record is the timestamp taken when the payment lands. Tested at both seams and along the whole chain: refused without it, refused for '', '0' and a word that is not yes, carried to Stripe as '1', and a webhook carrying it lands as a timestamp on the order while one without it lands as null. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-29 21:19:03 +02:00
nexxo	6d7c2bdf35	Ask whether they are a consumer, and let one change their mind ... Three things the product owed its customers and did not have. **Who is on the other side.** There was no consumer/business flag anywhere, and `vat_id` was standing in for one — which it cannot: a business without a VAT number is an ordinary small business, and a consumer with one does not exist. It is asked at sign-up now, correctable in the portal, and NULL where nobody has been asked. Unknown is read as CONSUMER everywhere it decides a right, because that mistake costs us a refund while the other one takes a statutory right away from somebody who has it. Reverse charge asks the recorded type instead of the number: an explicit consumer is charged the domestic rate whatever `vat_id` says — previously they were not, and anyone could zero their own VAT by getting a number verified. An unrecorded type still falls back to the verified number, so no contract that is already running changes rate. **The fourteen-day right of withdrawal** (FAGG, §312g BGB), for consumers only, at every door: the window is stamped on the contract when it is concluded, the customer exercises it from the portal, an operator records one that arrived by telephone or post, and both go through one action that refuses a business customer on the server rather than by hiding a card. The money follows the paperwork rather than being computed beside it. The invoice is cancelled by a Storno with its own gapless number — nothing is ever edited or deleted — a new invoice states the pro-rata value of the service actually delivered (FAGG §16, by days over the term paid for), and the refund is exactly the difference between the two documents. Where the consumer never expressly asked for the service to begin at once, they owe nothing and the whole amount goes back. `StripeClient::refund()` is new, keyed so a retry cannot send the money twice. The service ends through EndInstanceService and the `cancellation_scheduled` machinery that was already there. **The cancel button for modules.** BookAddon::cancelAtPeriodEnd() had no caller in the interface at all, so a customer could book a recurring charge in two clicks and had no way to stop it. It is on the module card now, with the date it runs until and a way back while the cancellation is still pending — and putting a module back settles nothing, because the term it was cancelled for was paid for in advance. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-29 21:06:06 +02:00
nexxo	0e25fe88d4	Keep a register of what was sent, and answer the customer from here ... Three complaints, one shape: the console knew things and could not act on them, so the work happened somewhere else and left no trace. The header said "4 Hinweis(e)" and led nowhere. Whoever read it had to know that the list was a card further down the same page, and then go looking for the host or the failed run by hand. The count is a link now, every notice carries the page that shows the thing it is about, and the plural is a word rather than a bracket. Nothing recorded what this installation had sent. "Hat der Kunde die Zugangsdaten je bekommen, und wann?" was answered on the mail server — a different machine, a different program, and nothing an operator can put in front of somebody who says nothing ever arrived. Every mail now writes a row: when, to whom, which mailable, and the customer it belongs to. Written from MessageSent, so a row means the transport accepted it; that is the strongest thing an application can honestly claim, and a column called "delivered" would be pretending otherwise. Verification and reset mails are left out on purpose — they go to unconfirmed addresses and anybody who can type into a form can send them, so recording them would hand the register to whoever wants to fill it. And the customer list was the end of the road. There is a page behind it now: what they bought, what they asked in their own words, what we sent them, and a box to write the next message. It goes out from the support mailbox and is recorded on the way — with its body, because an operator typed it and "what exactly did I write to them in March" is a question the mail server's log cannot answer either. Answering a request from here closes it, which is the reason to answer from here at all: answering from a mail client leaves it open for ever, because nothing tells it otherwise. Found on the way, by a test that sent a real mail rather than asserting it was queued: resources/views/mail/reset-password.blade.php was missing its closing </x-mail.layout>. The component's contents were never terminated, the layout's own @if ran off the end of the file, and the mail raised a Blade syntax error instead of rendering. Password reset has therefore never delivered a link since it was built. Closed, plus a test that renders it and one that counts opening against closing tags across every mail view. Reading INCOMING mail in the console is not in this: it needs the mailbox polled over IMAP, which is a credential and a dependency. Requests filed through the portal appear here in full; a customer who writes by mail instead still has to be read in the mail client. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-29 21:02:36 +02:00
nexxo	559a466630	Show that the update is running, and stop showing the rsync log ... The maintenance screen answered a question nobody was asking. Under the headline sat a card with the deployment's raw output in it — rsync listing every font file it had copied — and, before a step was known, a box drawn around the words "Wird jetzt gestartet." A person waiting on this page wants one thing settled: is anything happening, or am I looking at a dead page. So: an indeterminate bar, in CSS. Indeterminate because a deployment has no honest percentage and a bar that claims one always stalls at 90 %; in CSS because this page is served while the application is down, so it may not depend on JavaScript having loaded or on the server answering another request. Motion off gets a steady bar rather than none — the point is to show the page is alive, and a still bar says that better than a gap. Shown to everybody, not only in the console: a customer on the 503 is asking exactly the same question. What is left of the operator detail is the current step, as one quiet line, because a run that stops on a step is worth seeing without a shell. The elapsed time and the log are gone from the overlay entirely — with them goes a file read on EVERY console page load, running or not. The settings page still shows the log, where somebody is actually looking for it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-29 20:33:02 +02:00
nexxo	6b8412f0c3	Write an invoice for work that came off no price list ... Not everything we are paid for is a package. Somebody asks whether their data can be moved into Nextcloud; we look at it, we say what it costs, we do it. That is a real invoice with no order and no contract behind it, and the only way to produce one was to write it somewhere else — which puts it outside the series. A numbered series with a document missing from it is worth nothing at an audit. So it goes through the same door as every other invoice: IssueInvoice::forService() draws from the same series and therefore the same consecutive number, applies the same TaxTreatment (a verified business in another member state gets its reverse charge and the note that makes a zero-rated document lawful), freezes the same immutable snapshot and dispatches the same archive jobs. The page under Rechnungen writes what the operator typed and nothing else. Amounts are in euro because it is a form — 12,95 becomes 1295 by round(), not by a cast that would make it 1294 — and quantities go to a thousandth because hours are billed in quarters. The total beside the lines is the same InvoiceMath the document uses; a preview doing its own arithmetic would be a second answer, and the first one anybody notices differs is on a document that cannot be changed. There is no draft: a "save as draft" that draws a number is an issued invoice with a friendlier name. The website's buy buttons go to the sign-in now, not to /order. Booking belongs in the panel, where the account exists and its address has been confirmed — which matters because that address is where the finished cloud's credentials are sent. Sending an anonymous visitor at a page behind auth worked, but only via a middleware bounce off a page they never asked for. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-29 20:12:26 +02:00
nexxo	f85f57152e	Let the customer buy it themselves, and tab the integrations page ... Every path on the site ended in "anfragen": a mailto: link and a promise to answer the same working day. That is an afternoon of somebody's time per customer, for a product whose whole point is that the machine does the work — and it scales exactly as far as one inbox does. Now: sign in, pick a package, pay, and provisioning starts by itself. The pieces were already there — Stripe holds a Price per plan version (the catalogue sync writes the ids), the webhook opens the contract, the pipeline builds the VM — and what was missing was the checkout session between them. CheckoutController opens one and gets out of the way; the purchase becomes real on the webhook, which stays the only place allowed to believe a payment happened. The success URL is a redirect target and therefore a URL anybody can type, so it says "we are building it", not "you have paid". Nothing in the request may decide the price. The plan key arrives from a form and everything else is re-derived from the catalogue, including the plan VERSION, so a version published while the customer types their card number cannot change what they were quoted. Two cases that are not errors: no capacity is a parked order (already built), and an existing customer is sent to the plan change rather than sold a second, empty cloud that bills twice. The site says what it can keep. "danach wissen Sie … wie Ihre Daten sicher umziehen" was a promise made before seeing the thing it is about: we do not know where a visitor's data is, what shape it is in, or whether it can be moved at all. Migration is named as its own question, looked at first and quoted afterwards. The integrations page gets the settings page's treatment for the same reason: it was one narrow column of six cards, so an operator connecting DNS scrolled past Stripe to reach it and the raw .env editor sat at the bottom of everything. Three tabs by what a section is FOR — services we buy from outside, our own machines, the file underneath — the same axis the page was rebuilt around when it stopped being split by storage mechanism. The tab is in the query string; unlocking survives a switch, because a confirmed password is a session fact and not a property of a tab. The .env tab is Owner-only, like the editor it holds. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-29 19:42:28 +02:00
nexxo	7265799881	Quote what a person pays, and tab the settings page ... Prices. The sheet quoted net, which is the wrong number for one of its two readers: a private customer has no way to add 20 % in their head and no business being surprised by it at checkout. The gross figure is now the big one, with the net underneath for a company's books, and the same rule applies to the module prices further down — a sheet that quotes the package with VAT and the module without it is a sheet whose numbers cannot be added up. The rate is the one on the Finance page, the same one an invoice uses; a percentage written into the template would be the second source that makes the two disagree. "zzgl. einmaliger Einrichtung" had run for months without ever naming a figure, which leaves a visitor knowing only that there is one. It is a field on the Finance page now and prints with the price. Zero removes the sentence — and the comparison card that listed the fee as the honest downside of the offer — rather than admitting to a cost that is not charged. Layout. Four packages in 1120px left each card 202px of text, which is what broke "Bereitstellung in 2-3 Werktagen" over two lines and made the cards look pressed against each other. The pricing section is wider than the rest of the page (only it: the reading columns elsewhere are narrow on purpose, a price sheet is four columns that must be comparable at a glance), the gap between cards is larger, and the delivery line is short enough to fit with whitespace-nowrap to keep it that way. Navigation. VPN moves from Betrieb to System: the tunnel is not a task of the day, it is how the console reaches the estate at all. Settings. The page had grown to three headed sections in one column with the operator's own password somewhere in the middle. It is tabbed now, and two-factor enrolment is one of the tabs instead of a menu entry of its own — it is a setting, and it was the one thing an operator had to leave this page to change about their own access. Same component, no second copy of the enrolment logic; it still answers at its own route because RequireOperatorTwoFactor sends an operator there who may not open anything else yet, this page included. The open tab lives in the query string, so a reload, a bookmark and the back button all land where the operator was. That matters here more than elsewhere: the installation tab refreshes itself while an update runs, and a tab kept only in the component would drop them back to the first one mid-deployment. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-29 19:18:10 +02:00
nexxo	5b63fdb86c	Deliver the storage a customer actually buys ... A booked storage pack was a row in `subscription_addons` and nothing else: priced, frozen, charged every month, and delivered nowhere. Nextcloud's quota came from `instances.quota_gb`, which is the package alone; the disk was sized for the package alone; and on the one occasion a disk did grow — a plan upgrade — the guest never saw it, because nothing stretched the partition or the filesystem over the new space. One authority for the allowance. StorageAllowance adds the package and the booked packs, and everything that needs the figure asks it: the quota step, the downgrade check, the portal, the console, the repair command. It is DERIVED rather than stored — a column would have to be rewritten by booking, cancelling, granting, a grant expiring and a plan change, and the day one of those paths forgot it would be silently wrong in whichever direction costs somebody money. `quota_applied_gb` keeps its own meaning: what the guest was last actually told, which is how a machine with the allowance enforced is told from one where the figure has only ever been a row in our database. Buying it delivers it. BookAddon asks ApplyStorageAllowance for a run on booking AND on cancellation; the new `storage` pipeline grows the virtual disk to the allowance plus the package's own overhead (read off the package — 20/40/50/100 GB on the four catalogue packages — never a ratio invented here), then GrowGuestFilesystem makes the guest see it, then the quota is applied. No cold boot is involved: the data disk is scsi0 and Proxmox's resize on a running guest is a qemu block_resize, so the capacity reaches the guest while it runs. The new step rescans, growparts and grows the filesystem with the tool its type actually needs — ext2/3/4, xfs, btrfs — and fails loudly on one it does not know rather than handing it to resize2fs and hoping. Idempotent end to end: NOCHANGE from growpart is not a failure, and every tool here exits 0 when there is nothing left to grow. The same step now runs in the plan-change pipeline, where an upgrade used to stop one step short of the customer. A downgrade blocked by data gets a way out. The block stays — it is correct — but the check now measures against the target package PLUS the packs the customer already owns, and reports the numbers behind the refusal: what is stored, what would be allowed, how much has to go, and how many packs would cover it instead. The portal offers both routes: book exactly those packs (confirmed in a modal, R23), or delete data and have the fill level measured on demand rather than waiting for the nightly sampler. That reading is taken by DiskUsageProbe, which CollectInstanceTraffic now uses too, so there is one notion of "how full is it" and not two. A plan change keeps booked packs. They were paid for separately and have nothing to do with which package the customer is on; the new package's disk and quota are sized with them included. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-29 19:13:10 +02:00
nexxo	ec8675861e	Take the order, park it, and say when it will be delivered ... A paid order that no host has room for used to FAIL at the reservation step. The customer has paid by then, so that turned a sale into an incident and left somebody holding money against nothing. The estate is finite and booked thick, so "no host has room right now" is an ordinary Tuesday — it means a machine has to be bought, which takes days. So the order waits instead. poll(), not retry(): the wait is measured in days and must not eat the run's attempt budget. It only fails after PARK_DAYS (14) — long enough to buy, rack and onboard a server over a weekend, short enough that a forgotten order surfaces instead of waiting for ever. Then say so, in the same words on both sides of the payment: - The price sheet marks each package "wird sofort ausgeliefert" or "Bereitstellung in 2-3 Werktagen", read from free capacity rather than written into the page. - The customer's own overview says their cloud is being prepared while it is parked, instead of a stepper standing still for two days under "wird eingerichtet" — which reads as broken. - The console front page shows the same per-package answer, so an operator can see what visitors are being promised. And a capacity page for the decision that follows: who is waiting, what the roomiest host still has, what the queue needs ("3x Start, 1x Business" - the LARGEST parked package sets the minimum machine, because an instance lives on one host), and what such a machine costs today from the provider's live list. It orders nothing: buying a server is a contract, and a bug in a capacity calculation must not sign one. The operator can also say where each parked order goes. A pin is honoured or it waits — never quietly redirected — because placing it elsewhere answers a different question than the one they answered, and they would find out from the finished instance. Two things this shook out: - `current_step` is an INDEX into the pipeline, not the step's key, and it is cast to integer. `where('current_step', 'reserve_resources')` reads as correct and matches step 0 of EVERY pipeline instead. Both lookups go through HostCapacity::parkedRuns() now, which resolves the index and filters by pipeline. - The auction feed sends `hdd_hr` as a list, not a string. Casting it printed "Array" into the console and raised a warning that took the page down with it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-29 18:50:46 +02:00