platform-admin/alva
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
625 Commits 1 Branch 1 Tag
0068ef9844369ddb038809177ee96f84f42bfd10
Commit Graph

11 Commits

Author SHA1 Message Date
Claude 3b83fc94e9 Portalen är stängd på riktigt — m-9 stängd 
Anmärkningen var att en inloggning som SER ut att autentisera ger
portalen bakom den en auktoritet den inte har. Rättelsen är inte att ta
bort skylten utan att göra spärren verklig där det finns något att
spärra mot.

Med plattformen konfigurerad autentiserar inloggningen mot
/api/auth/logga-in, varje portalväg går genom Portalvakt, och
fakturavyn läser organisationens egna fakturor ur GET /api/fakturor.
Misslyckas hämtningen visas felet — inte exemplet: data som ser äkta ut
men inte är det är värre än ett synligt fel. Utloggningen finns i
portalhuvudet och rensar sessionen på riktigt.

Utan konfigurerad plattform finns ingen session att kräva, och
demonstrationsmärkningen visas exakt i det läget.

---- Varför garantin inte är ett källkodstest ------------------------

Sviten kan bara läsa koden och se att vakten är inkopplad. Släpper den
igenom ändå — fel villkor, fel ordning, ett <Navigate> som aldrig hinner
rendera — ser koden likadan ut. Och en spärr som inte spärrar är precis
det m-9 handlade om.

e2e/portalsparr.mjs bygger därför med plattformen konfigurerad och
tittar var besökaren faktiskt hamnar: fem vägar spärrade utan session,
fem öppna med, utloggning som rensar token och stänger portalen igen.
Mutationstestad — att plocka bort vakten från en enda route fäller den.

Bevisad: 374 enhetstester, typkontroll, genomgången 4/4 ärenden,
portalspärren 14/14.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012EQg3rJsrQ1ZNTvkzmQAtt
 2026-08-06 12:08:18 +00:00
Claude d1b361573e 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
 2026-08-06 10:54:31 +00:00
Claude 86d553b639 Kör ALVA:s tester i CI, och genomgången som incheckat test 
CI körde `npm test` i roten, som delegerar till workspaces. Listan är
apps/mobile, services/api och infra — felsokning/app står inte där.
Pipelinen körde alltså 30 tester från en orelaterad tjänst och inte ett
enda av ALVA:s 311. Varken lint eller typkontroll nådde produkten heller.

Det är inte att testerna föll. Det är att ingenting upprätthöll dem.
Varje garanti som de två revisionerna skrivit som "låst av ett test" —
härkomsten, kvalitetsgrinden, raderingen, mätdonsspårbarheten,
högvoltsspärren, det stängda schemat, driftskydden mellan klient och
grind — låstes av tester som ingen pipeline körde. De höll därför att en
person körde dem för hand före varje commit. Det är en person, inte en
spärr.

Två nya jobb. `alva` kör produktens lint, typkontroll och hela sviten mot
sin egen lockfil. `genomgang` installerar Chromium och kör fyra ärenden
genom det byggda gränssnittet.

Genomgången kontrollerar tre saker: att varje ärende når avslutat läge,
att varje händelse klienten faktiskt producerar passerar det stängda
schemat, och att interaktionerna per ärende håller sig under 90. Bägge
felvägarna är provade, inte antagna — sänkt budget fäller tre fall, och
ett schemafilter som avvisar allt fäller fyra. En kontroll som inte kan
falla är dekoration.

Skriptet bygger appen själv med de två miljövariabler bygget kräver.
Lämnas det åt den som startar kommandot testar genomgången tyst en annan
applikation: utan hash-routing matchar ingen route, och utan
platshållare för den gamla butiksklienten kastar den innan routern
monteras så att sidan blir tom.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012EQg3rJsrQ1ZNTvkzmQAtt
 2026-08-05 19:41:15 +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
Claude 301c477e25 Merge main: Guidad Felsökning flyttar ur roten till felsokning/ 
Main är sedan den här grenen skapades en helt annan produkt — Semantika,
en mobilapp med egen CDK-infrastruktur. Den äger nu repots rot: en
npm-workspaces-monorepo med apps/mobile, services/api och infra.

För att båda ska rymmas i samma repo flyttar Guidad Felsökning in i en
egen katalog i stället för att göra anspråk på roten:

  felsokning/app        webbklienten (Vite, egen package.json och
                        eslint-/vitest-konfiguration)
  felsokning/services   plattformstjänsten och AI-orkestern
  felsokning/infra      Terraform och databasschemat
  felsokning/docs       vision, moduler, drift
  felsokning/supabase   edge-funktion och migrationer

Merge:n hade tagit bort 128 filer som Guidad Felsökning bygger på —
värdapplikationens komponenter, Supabase-klienten, tillgångar — eftersom
main raderat dem och den här grenen inte råkat ändra just dem. De är
återställda på sin nya plats. Utan dem gick varken bygget eller
testerna: ai.ts och synk.ts importerar Supabase-klienten.

Semantikas rotfiler är orörda: package.json, eslint.config.js och
.github/workflows/ är deras. Guidad Felsökning har egna motsvarigheter i
sin katalog.

CI flyttar samtidigt från GitHub Actions till .gitea/workflows — samma
syntax, egna runners. .github/workflows/ tillhör Semantika härefter.

Verifierat på den nya platsen: 96 vitest-tester, typkontroll, eslint på
både klient och tjänster, bygge, och integrationstest mot riktig Postgres.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012EQg3rJsrQ1ZNTvkzmQAtt
 2026-08-04 12:22:49 +00:00
Claude 19796bec70 Terraform blir enda vägen, och backup ett obligatoriskt val 
Kustomize- och Argo CD-vägen är borttagen. Den beskrev samma system en
gång till och kunde inte köras samtidigt som Terraform utan att de
motarbetade varandra — selfHeal återställde det Terraform ändrade och
prune tog bort det Terraform skapade. Kvar utanför Terraform är bara
postgres-init.sql, som läses av både definitionen och integrationstestet
så att schemat inte kan glida isär från det som testas.

Säkerhetskopieringen var en förhoppning: en StatefulSet med en volym och
ingen kopia. Går volymen förlorad är det inte "data" som försvinner utan
varje ärendes bevisvärde — vad som kontrollerades, av vem, när, med
vilken evidens — och det går inte att återskapa i efterhand.

databas_lage är därför ett obligatoriskt val utan standardvärde:

  extern    managerad Postgres, leverantörens backup och PITR
            (rekommenderat i produktion)
  cnpg      CloudNativePG i klustret: basbackup 02:30, kontinuerlig
            WAL-arkivering till objektlagring, PITR och failover
  inbyggd   en volym, ingen backup — spärras av en precondition när
            miljön är produktion

Preconditions fångar felkonfiguration vid plan i stället för vid drift:
extern utan anslutning, cnpg utan backupmål eller nycklar, inbyggd i
produktion.

Driftsättningen är nu två åtskilda flöden. Publicera bygger och taggar
bilderna vid varje main-push; Driftsätt startas för hand med en tagg mot
en GitHub-miljö som kan kräva godkännande, kör fmt/init/validate/plan/
apply, skriver ut kartan och rökkontrollerar hälsa och API-spec. En bild
i registret är inte samma sak som en bild som kör. Rollback är att köra
Driftsätt igen med en tidigare tagg. CI kör dessutom terraform validate
på varje PR — den kontroll jag inte kunde köra själv.

Två fel hittade vid egengranskning av definitionen: schemafilen delades
på semikolon, vilket hade klippt itu plpgsql-funktionen med
append-only-triggern (nu hela filen via postInitApplicationSQLRefs), och
null-satta fält i kubernetes_manifest utelämnas nu i stället.

Verifierat: 87 vitest-tester, typkontroll, eslint, OpenAPI-validering,
terraform fmt, statisk referenskontroll av modulen och integrationstest
mot riktig Postgres. terraform validate kunde inte köras här —
registry.terraform.io är blockerad av sessionens egress-policy, därav
CI-jobbet.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012EQg3rJsrQ1ZNTvkzmQAtt
 2026-08-03 22:16:52 +00:00
Claude 07fbeea09b Bygg NeuroSemantics AI: minimal mobilapp, en backend, IaC och CI/CD 
Ersätter den tidigare webappen på denna branch med ett fokuserat monorepo:

- apps/mobile: Expo/React Native med tre vyer (Welcome, Chat, Paywall),
  Cognito hosted UI-inloggning (Apple/Google/e-post) och In-App
  Purchase/Play Billing via en gemensam purchases-modul.
- services/api: en enda Lambda-backend — OpenAI Responses API med
  Markdown-kunskapsbas som systeminstruktioner, free tier-gräns i
  PostgreSQL (HTTP 402 -> paywall) och kvittoverifiering bakom ett
  delat PaymentProvider-interface (Apple/Google, Stripe kan läggas
  till för webb senare).
- infra: AWS CDK-stack med API Gateway (JWT-authorizer), Lambda,
  Cognito, Aurora Serverless v2 och Secrets Manager.
- db/migrations: minimal datamodell (users + usage), inga
  konversationer sparas.
- GitHub Actions: CI (lint, typecheck, test) och deploy från main.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0118DaxZR36RpnY524vRqx3z
 2026-08-03 14:35:48 +00:00
Claude 150b5011d5 GitOps-deployflöde: publicering till GHCR + Argo CD-synk 
Klustret följer git — ingen CI-process har kubectl-åtkomst:

- Nytt publiceringsflöde (.github/workflows/publicera.yml): varje
  main-push bygger de tre bilderna, publicerar till GHCR taggade med
  git-SHA (endast GITHUB_TOKEN, inga externa hemligheter), uppdaterar
  produktions-overlayens taggar med kustomize edit set image och
  committar tillbaka — overlayen ombyggs som verifiering före commit,
  och paths-ignore + [skip ci] förhindrar triggerloopar.
- Produktions-overlay (infra/overlays/produktion): GitOps-sanningen
  för vad som kör; bas = infra/k8s. Rollback = git revert.
- Argo CD-applikation (infra/gitops/argocd-application.yaml):
  automatisk synk med prune + selfHeal; hemligheten ligger medvetet
  utanför både git och synken. Bootstrap = ett kubectl apply.
- DRIFT.md: CI/CD-avsnitt med flödesdiagram, bootstrap, rollback och
  repo-variabeln PLATTFORM_URL.

Verifierat med riktig kustomize v5.4.3: overlayen bygger 17 objekt,
bildbytet slår igenom på alla tre tjänsterna, postgres-init genereras,
och workflowens exakta edit set image-kommandon fungerar. Alla
workflow-/manifest-YAML validerade; 29 vitest-tester gröna.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012EQg3rJsrQ1ZNTvkzmQAtt
 2026-08-03 08:06:27 +00:00
Claude b069c9a12f Organisationslagret: multi-tenant med roller, integrationstestat 
Master Prompts tenant- och rollmodell implementerad i den självhostade
plattformen:

- Registrering skapar organisation + systemadministratör (transaktion);
  admin skapar övriga användare (tekniker/arbetsledare/admin) i sin
  organisation via nytt UI och POST /api/anvandare. Roll + organisation
  ligger i JWT-anspråken och verifieras alltid på servern.
- All ärendedata organisationsknuten: ärenden skapas i användarens
  organisation, händelse-API:t verifierar tillhörighet per anrop och
  GET /api/arenden listar bara egna organisationens ärenden.
- Schemat flyttat till infra/k8s/postgres-init.sql och genereras in som
  ConfigMap via kustomize — samma fil används av integrationstestet.
  Nya tabeller: organisationer; anvandare med organisation_id + roll
  (check-constraint); arenden med organisation_id + index.
- Integrationstest (services/plattform/integrationstest.sh) mot riktig
  Postgres, kört grönt lokalt och tillagt i CI: registrering, synk,
  idempotens (händelser skrivs aldrig över), append-only-triggern,
  organisationsisolering (404 över gränsen), publik delning med
  filtrering, rollstyrning (tekniker nekas användarhantering) och
  delad arbetsyta inom organisationen.
- Klienten: registreringsformulär med organisationsfält, kontopanel
  med roll och organisation, admin-panel för användarhantering.

Verifierat: integrationstestets 12 kontroller gröna mot Postgres 16,
28 vitest-tester gröna, produktionsbygge ok, YAML validerad,
Playwright-röktest grönt.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012EQg3rJsrQ1ZNTvkzmQAtt
 2026-08-03 07:04:32 +00:00
Claude 7c24186cc5 Helt självhostat: plattformsbackend, Postgres i klustret, klientläge 
Sista externa beroendet borta — hela stacken kör i eget kluster:

- Ny plattformstjänst (services/plattform): egen inloggning
  (registrering + inloggning, lösenord bcrypt-hashade med pgcrypto,
  HS256-JWT), append-only händelse-API för synken (endast insert,
  on conflict do nothing) och publik delningsendpoint för Live Share
  med samma filtrering som Supabase-funktionen. Fail closed utan
  hemligheter; inga update/delete-operationer exponeras.
- Postgres som StatefulSet med PVC och init-schema; append-only
  garanterat i databasen med triggers på både händelser och ärenden —
  historik kan inte ändras oavsett ansluten roll. CloudNativePG
  rekommenderas för produktion i docs.
- JWT-hemligheten delas mellan plattform och AI-orkester (orkestern
  läser JWT_SECRET med SUPABASE_JWT_SECRET som fallback) — flödet
  livetestat: plattformens token accepteras av orkestern, fel
  hemlighet och utgångna tokens avvisas.
- Klienten får självhostat läge via VITE_PLATTFORM_URL: inloggnings-
  panel på startsidan, synk mot plattformens API (samma konfliktfria
  flätning), Live Share via /api/delad och AI via klustrets orkester.
  Utan variabeln är Supabase-läget oförändrat.
- Ingress routar /api/ai → orkestern, /api + /halsa → plattformen,
  / → webben; kustomize inkluderar hela stacken; CI bygger alla tre
  bilderna; DRIFT.md omskriven för självhostad drift.

Verifierat: 28 vitest-tester gröna (inkl. append-only-triggers och
API-ytan), plattformstjänsten livetestad (hälsa, 401, fail closed),
JWT-paritet mellan tjänsterna testad, alla manifest YAML-validerade,
produktionsbygge ok, Playwright-röktest grönt.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012EQg3rJsrQ1ZNTvkzmQAtt
 2026-08-03 01:41:58 +00:00
Claude 03f1ef20f6 Allt i Kubernetes: containrar, manifest, orkestertjänst och CI 
Målarkitekturen ur Master Prompt som kod:

- Webben containeriserad (flerstegs-Dockerfile → oprivilegierad nginx
  med SPA-fallback, hashade assets cachas hårt, säkerhetsheaders).
- AI-orkestern som egen tjänst (services/ai-orkester): samma routing
  och AI-regler som edge-funktionen men körbar som pod — egen
  HS256-JWT-verifiering (fail closed), /halsa, storleksgränser,
  read-only container som kör som node-användaren. Livetestad:
  hälsokontroll ok, 401 utan/med ogiltig token, 400-validering bakom
  giltig JWT.
- Kubernetes-manifest (infra/k8s, kustomize): namespace, Deployments
  med readiness/liveness och åtstramad securityContext, Services,
  HPA 2–10 pods på 70 % CPU, PodDisruptionBudgets, Ingress med TLS
  via cert-manager, secret-mall (riktiga värden skapas utanför git).
- Klienten väljer AI-väg vid bygget: VITE_AI_ORKESTER_URL → tjänsten
  i klustret, annars Supabase-edge-funktionen. Samma orkester i båda,
  låst av paritetstest.
- CI-arbetsflöde: tester + produktionsbygge + verifierande
  containerbyggen av båda bilderna på varje push/PR.
- docs/DRIFT.md: arkitekturdiagram, driftsättningssteg, skalning,
  och vad som återstår mot full självhostning.

Verifierat: 27 vitest-tester gröna, produktionsbygge ok, alla
K8s-manifest YAML-validerade, orkestertjänsten livetestad,
Playwright-röktest grönt.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012EQg3rJsrQ1ZNTvkzmQAtt
 2026-08-03 01:27:54 +00:00