Everything was built — numbering, the frozen snapshot, the PDF, the mail, the
archive and its retention — and none of it was connected to anything. IssueInvoice
was called from nowhere but its own tests. So on a real server no invoice had
ever been created, the handover directory was empty, and rsync was correctly
copying nothing. Reported as "nothing gets copied", which it was.
One mail, not two. The invoice is issued the moment the payment lands, so an
order confirmation and an invoice mail would otherwise go out in the same second
for the same event — a defect rather than a preference. The invoice mail carries
the document and says everything the confirmation said, so it replaces it
whenever there is an invoice; the confirmation stays for when there cannot be
one.
Issuing is allowed to fail without taking the purchase with it. IssueInvoice
refuses while the company details are incomplete, and that refusal is correct —
an invoice without a registered name or a VAT number is not a valid invoice, and
issuing one consumes a number that can never be handed out again. The order
still stands, the machine is still built, and the invoice can be issued later.
Nothing here may throw at the webhook either: Stripe retries anything that is
not a 2xx, and a retry would re-enter provisioning and build a second machine
over a missing VAT number.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Four templates, one layout. Two of them — the maintenance announcement and its
cancellation — still wore Laravel's markdown component, which brings its own
logo, its own button and its own footer: the product was sending mail that
looked like two different companies, one of which was the framework.
New: an order confirmation, sent when the payment lands rather than when
provisioning finishes. Those are minutes apart at best and can be much longer,
and somebody who has just been charged and heard nothing assumes the worst
about both the charge and the product. It deliberately promises no time for the
cloud itself — provisioning takes what it takes, CloudReady announces the end,
and a promised minute that slips is worse than no promise. Queued after the
transaction, never inside it, and never allowed to fail the webhook: Stripe
retries anything that is not a 2xx, and a retry would re-enter provisioning
over a mail server having a bad minute.
The finished-cloud mail now names what was actually built — address, plan,
storage, location — because somebody who ordered a fortnight ago is checking it
against what they bought, and that is a comparison rather than a sentence. Still
no credential in it.
Two tests earn their place. One holds every template on the shared layout, so a
new one written in a hurry cannot copy-paste its way back to the framework's.
The other proves the finished-cloud mail carries no password — asserted against
the data the mail is given and the HTML it renders, not against the template's
source, because the first version of that test tripped over the word in a
comment and would have passed a template that leaked the value through a
variable. It tested the prose, not the mail.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
nexxo