4 Commits

Author	SHA1	Message	Date
Claude	b147694e31	Härdning av hela TÜV-revisionen ... Tio av tolv fynd stängda, två reducerade med skälen utskrivna. Varje stängning prövas av integrationssviten mot riktig Postgres — 144 kontroller, upp från 100. T-1 Händelsenyckeln är nu (arende_id, id). Det finns inget delat namnrum kvar att ockupera, så attacken saknar yta i stället för att vara mildrad. Inom ett ärende bedöms en kollision på klientens avtryck — en hash av det kanoniserade innehåll klienten skickade, taget före serverns egna fält och före krypteringen, eftersom varken raden eller nyttolasten går att jämföra. Identiskt innehåll är fortfarande idempotent; samma id med annat innehåll ger 409 och skriver ingenting alls, inte heller resten av satsen. Samma attack en nivå upp — ärende-id är lika förutsägbart — stängs separat: ett id som ägs av en annan organisation ger 409 i stället för att tyst låta bli, vilket tidigare lämnade offrets ärende oskapat och varje senare synk svarande 404. T-2 Mätdonet slås upp i registret. Beteckning och kalibrering HÄRLEDS därifrån och skriver över det klienten skickade. Okänt mätdon ger 400. Utgånget avvisas inte — mätningen gjordes — men registrets datum följer med, så graderingen faller på registrets uppgift. Ett mätvärde utan mätdon får sina påstådda uppgifter borttagna. T-3 Reducerad, inte stängd. Personnycklarna kuverteras under en huvudnyckel utanför databasen. En återställd dump ger nycklar som inte öppnas — verifierat genom att starta om utan huvudnyckeln. Vad som återstår står utskrivet: en backup tagen FÖRE en radering, plus huvudnyckeln, återställer fortfarande uppgifterna. Därtill: gallringen verkställs nu av ett eget jobb och grupperar på det blindade fordonsindexet så att en delad nyckel inte gallras för tidigt (T-4) · AI-avlästa mätvärden bär härkomst (T-5) · bcrypt kostnad 12 (T-6) · åtkomstloggen och raderingsregistret är append-only, med en smalare regel för personnycklarna som måste kunna förstöras (T-7) · åtkomstloggen dokumenterad (T-8) · ett externt regelpaket utan signatur spärrar avslut (T-9) · CORS faller inte längre öppet (T-10) · exp krävs i token (T-11) · react-router 7 (T-12, med den kvarvarande avvikelsen motiverad). Den motspelande hyresgästen som revisionen efterlyste finns nu som testform och körs i CI. ---- Vad härdningen själv avslöjade ----------------------------------- Två av rättelserna var kortvarigt fel på samma sätt som fynden, och bägge fångades bara av att jag försökte bevisa dem: T-7-testet var grönt mot en TOM tabell. En radnivåtrigger har inga rader att fyra på, så delete lyckades och kontrollen mätte ingenting. T-6-testet påstod anropet, inte kostnaden. toContain("gen_salt('bf')") hade accepterat kostnad 6 för evigt — och gjorde det, så länge det fanns. Bägge är mönstret revisionen namngav: en kontroll som är riktig i sina egna termer och oprövad vid sin gräns. Det gäller tester lika mycket som kod. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_012EQg3rJsrQ1ZNTvkzmQAtt	2026-08-06 13:05:16 +00:00
Claude	69a519be75	Observation: se var tiden går, utan ett enda nytt beroende ... CloudWatch gav loggar och mätvärden men svarade inte på frågan man faktiskt har när något är långsamt: var tog tiden vägen. Tjänsterna har medvetet nästan inga beroenden — plattformen har pg-drivrutinen, orkestern har Claude-klienten. Att dra in ett OpenTelemetry-SDK med trettio paket för att mäta fyra saker vore fel avvägning. I stället två standarder som båda bara är text på stdout: W3C Trace Context. Klienten startar spåret och traceparent följer med genom plattformen till orkestern, så en teknikers handling går att följa hela vägen till modellsvaret i stället för att bli två orelaterade spår. CloudWatch EMF. Strukturerad JSON som CloudWatch själv extraherar mätvärden ur — ingen agent, ingen SDK, inget som kan sluta fungera tyst. Varje anrop ger en loggrad med nedbrytning av tiden per del: databasen, modellanropet, objektlagringen, kundens leverantör. Det svarar direkt på om ett långsamt ärende beror på S3 eller på Opus-granskningen, i stället för att någon ska korrelera fem loggrader. Vägen normaliseras innan den blir dimension, och organisation, ärende-id och spår-id blir aldrig dimensioner — varje unik kombination är en egen tidsserie som kostar. De ligger som vanliga fält, sökbara i Logs Insights. Ett test låser det, eftersom det är precis den sortens sak som smyger in senare. Tre larm på det teknikern märker: svarstid p95 över tre sekunder (medelvärdet döljer att var tjugonde tekniker väntar orimligt länge), serverfel med spår-id i loggraden, och att modellen avböjer — det senare tyder på att underlaget innehåller något oväntat, inte på ett driftfel. Modulen är delad mellan tjänsterna i stället för duplicerad. Byggkontexten flyttas därför till felsokning/services, och en symlänk gör att testerna och integrationstestet kör mot samma fil som bilderna. Verifierat: 106 vitest-tester (10 nya för spårning, EMF-format och att dimensionerna hålls få), typkontroll, eslint på klient och tjänster, rotens CI, terraform fmt och referenskontroll på båda lagren, samt integrationstest mot riktig Postgres där spårraderna syns live. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_012EQg3rJsrQ1ZNTvkzmQAtt	2026-08-04 13:36:47 +00:00
Claude	ac24938108	AWS-basen: allt eget, inget GitHub ... Guidad Felsökning får en egen AWS-grund i felsokning/infra/aws — nät, kluster, databas, objektlagring, register, hemligheter, domän och observation. Inget GHCR, ingen extern byggtjänst. Två lager i ordning, och uppdelningen är inte smak: en enda apply som både skapar ett EKS-kluster och schemalägger in i det är en känd fälla, eftersom kubernetes-leverantören måste konfigureras med uppgifter som inte finns förrän klustret existerar. Nätet ligger i tre lager. Publikt bara för lastbalanserare och NAT, privat för noderna, och ett eget datalager för Aurora utan routing ut alls — att databasen inte kan nå internet hänger då inte på att en säkerhetsgrupp är rätt konfigurerad. VPC-endpoints för S3, ECR, loggar, Secrets Manager, STS och ELB gör att bilddragningar och loggar aldrig lämnar nätet, vilket både är säkrare och sänker NAT-notan rejält. IRSA i stället för nodroller: plattformens tjänstekonto har en roll bunden till exakt en namnrymd och ett tjänstekonto, så grannpodden på samma nod får ingenting på köpet. IMDSv2 med hoppgräns 1 hindrar dessutom en pod från att låna nodens roll via metadatatjänsten. Bygge och drift har delade rättigheter. Byggrollen får publicera till ECR men inte röra klustret; driftrollen tvärtom. Ett komprometterat bygge kan därför inte driftsätta. Aurora PostgreSQL Serverless v2 med 30 dagars säkerhetskopiering och PITR ned till sekunden — det som gör den duglig för händelseloggen är inte prestandan utan att förlorad logg annars hade tagit varje ärendes bevisvärde med sig. S3-hinken för bilagor har versionshantering, SSE-KMS, TLS-krav och blockerad publik åtkomst; plattformens roll får läsa och skriva men aldrig radera, eftersom bilagorna hör till en append-only logg. Larmen är fyra och ett av dem larmar på saknad data: uteblir mätvärdet för säkerhetskopiering finns ingen backup, och en backup man tror finns är värre än ingen. Verifierat: terraform fmt och en statisk referenskontroll (88 resurser, 5 datakällor, inga dinglande referenser). terraform validate kunde inte köras här — registry.terraform.io är blockerad av sessionens egress-policy — så CI-jobbet kör den i stället. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_012EQg3rJsrQ1ZNTvkzmQAtt	2026-08-04 12:39:42 +00:00
Claude	c407aad58a	Varje produkt äger sitt eget träd — och GitHub-flödena bort ... Rot-CI:n föll med 107 lint-fel efter merge:n. Orsaken var inte kod som blivit sämre: Semantikas rot-eslint började granska felsokning/, ett träd med egen verktygskedja och andra regler. Felen låg i värdappens befintliga Supabase-funktioner, oförändrade sedan innan. Rätt åtgärd är att låta varje produkt äga sitt eget träd, inte att lätta på någons regler. felsokning/ ignoreras därför av Semantikas eslint och prettier — den har egen eslint-konfiguration, egna prettier-regler och eget CI-flöde. Ingen regel är försvagad för någon av produkterna. Samtidigt: mina GitHub-workflows för publicering och driftsättning är borttagna. Guidad Felsökning ska inte längre bero på GitHub Actions eller GHCR — bygge, publicering till eget ECR och terraform apply mot EKS ligger nu i .gitea/workflows/felsokning.yml och körs av egna runners. Driftsättningen är fortsatt ett eget, manuellt steg med en bildtagg; rollback är att köra igen med en tidigare tagg. .github/workflows/ci.yml är Semantikas och lämnas orörd. Verifierat: rotens lint, format:check, typecheck och test går igenom, och Guidad Felsöknings egna 96 tester, typkontroll, bygge och integrationstest mot riktig Postgres likaså. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_012EQg3rJsrQ1ZNTvkzmQAtt	2026-08-04 12:27:33 +00:00