Faktureringens serverdel — och två fel den grävde fram

Fakturering fanns som modell, vy och tester men aldrig som något en
server kunde utfärda. Nu finns tabellerna, vägarna och gränsen mellan
kund och utfärdare.

Beloppet tas aldrig emot. Det härleds ur organisationens faktiska
tillstånd — de konton som verkligen kan logga in, de moduler som
verkligen är påslagna — och ett anrop som ändå skickar rader eller
totalt avvisas med 400 i stället för att tigas ihjäl. Samma hållning som
mot okända fält i händelseschemat.

Fakturaraden är oföränderlig, skyddad av samma trigger som loggen. Det
får en följd som är lätt att missa: "betald" kan då inte vara en kolumn
som uppdateras. Betalningen är en egen händelse och statusen en
projektion av händelserna. En felaktig faktura rättas inte heller — den
bemöts av en kreditfaktura med omvänt tecken och ett granskbart skäl.

Utfärdaren är inte en användare. Ingen av rollerna i en verkstad är
motpart i avtalet, så en kunds administratör kan varken utfärda sin egen
faktura eller bokföra den som betald; utfärdandet kräver en egen nyckel,
och utan den i miljön utfärdas ingenting alls. Nummerserien är utan
luckor — en sequence hade varit billigare men lämnar hål vid rollback,
och ett underlag med hål i är en lista.

---- Vad som föll ut när sviten faktiskt kördes ------------------------

integrationstest.sh fanns men låg utanför CI, och den föll på andra
raden — i kod som inte hade med fakturering att göra:

C-7  Append-only-triggern på felsokning_arenden förbjöd ALL update. Två
     av radens kolumner är härledda efteråt: gallringsdatumet vid avslut
     och det blindade fordonsindexet. Alltså föll varje avslut med 500,
     efter att kvalitetsgrinden redan godkänt ärendet. Skyddet är nu
     kolumnvis: identitet och ursprung är fortfarande låsta, radering
     fortfarande omöjlig, men de fält systemet självt härleder får
     skrivas.

C-8  Fordonshistoriken sökte i klartext efter en identifierare som
     krypteras i vila. Jämförelsen kunde aldrig träffa: historiken
     svarade tomt på varje fordon, med 200. Det blindade indexet fanns
     just för den frågan och var aldrig inkopplat.

Bägge ligger i backenden till produktens centrala löfte — att ett
avslutat ärende är ett varaktigt underlag — och ingen av dem kunde synas
i en grön enhetssvit, eftersom ingen av dem kan falla utan en databas.
Sviten är därför ett eget CI-jobb nu.

Bevisad: 364 enhetstester, 100+ integrationskontroller mot riktig
Postgres, genomgången 4/4 ärenden. Spärren mot angivet belopp
mutationstestad — borttagen ger den 201 i stället för 400.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012EQg3rJsrQ1ZNTvkzmQAtt
This commit is contained in:
Claude
2026-08-06 10:54:31 +00:00
parent c9fdef27c9
commit d1b361573e
9 changed files with 832 additions and 7 deletions
+23
View File
@@ -506,6 +506,29 @@ walkthrough would quietly start testing a different application.
| Rev 1 · m-6 | Manual accessibility review | Automated tooling finds malformation, not usability. |
| Rev 2 · m-9 | The portal mock | A product decision about what the portal is for. |
### Two backend defects found by running the suite that was never run
Building the invoicing endpoints meant running `integrationstest.sh` — the
platform service against a real Postgres. It had never been part of CI. It
failed on the second assertion, on code untouched by that work:
| # | Defect | Why it survived |
| --- | --- | --- |
| **C-7** | The `arenden_append_only` trigger forbade **all** `UPDATE` on `felsokning_arenden`. But two of its columns are derived *after* creation: the retention date, set at close from the case type, and the blinded vehicle index, written when the object is identified. So closing a case made the server attempt an update, the database refused, and the whole sync failed with `500`*after* the quality gate had already passed the case. | No test exercised close against a real database. The unit suite uses the in-memory projection, where no trigger exists. |
| **C-8** | Vehicle history matched `handelse->'objekt'->>'identifierare'` in cleartext. Identifiers are encrypted at rest under crypto-shredding, so the comparison could never match: history answered **empty for every vehicle, with `200`**. The blinded index exists for exactly this query and was never wired into it. | An empty result is indistinguishable from "no previous cases" unless a test writes two cases and demands two back. The integration test did — and never ran. |
C-7 is repaired by making the protection column-wise instead of total: identity,
ownership and origin are still immutable, deletion is still impossible, but the
fields the system derives itself may be written. C-8 is repaired by querying the
blinded index. Both now have assertions, and the suite runs in CI as the
`plattform` job.
The pattern is the same one M-7 exposed, one layer down. A guarantee nothing
executes is not a guarantee. Both defects were in the *backend of the product's
central promise* — that a closed case is a durable record — and both were
invisible from a green unit suite, because neither could fail without a
database.
### Re-audit verdict
The finding that decided this revision — C-5 — is closed at the point where it