boc/workcamp/VOL6-Lessons-Learned.md

# AMOS Development Workcamp 2026
# Volume 6: Lessons Learned and Continuous Improvement
# Period: 2026-06-04 – 2026-06-07 (intensiv fas)
# Genererat: 2026-06-07 | Klassifikation: INTERN – KONFIDENTIELL

---

## INLEDNING

Denna volym dokumenterar incidenter, rotorsaksanalyser (5 Why), förbättringar (Kaizen-register) och
lärdomar från AMOS Workcamp 2026. Målet är att nästa workcamp inte upprepar samma misstag.

Claude × Siemens-linsen gäller för detta dokument: var incident dokumenteras ärligt, inklusive
obekväma fynd. "Surface:a verkliga fynd (även obekväma)" – Claude-sidan av beslutslinsen.

---

## AVSNITT 1: INCIDENTANALYS – 5 WHY

### INCIDENT 1: LandveX = bostad-incidenten

**Symptom:** ESLM (ALETHEIA i test) och produktionschatten (`/api/aamos/chat`) svarade att LandveX
säljer bostäder. Gravt faktafel med potentiell kundpåverkan om det gått live.

**Tidpunkt:** Upptäckt 2026-06-06 under systematisk systemkunskaps-härdning.

**5 Why-analys:**

| Nivå | Varför? | Svar |
|------|---------|------|
| 1 | Varför svarade AI att LandveX säljer bostäder? | Produktionschatten hade ingen aktuell LandveX-definition. |
| 2 | Varför saknade chatten korrekt definition? | `/api/aamos/chat` anropade `getEnrichedPrompt()` → `getFactsContext()` → hårdkodad `wavult-facts.mjs`. Den filen hade LandveX-def som proptech/fastighet. |
| 3 | Varför hade `wavult-facts.mjs` fel definition? | Ingen process för att hålla filen synkad med kanonisk AAMOS_CANON.md. Filen skrevs manuellt vid ett tidigt skede och uppdaterades aldrig. |
| 4 | Varför fanns det 39 konkurrerande truth-filer? | Ingen utsedd kanonisk sanningskälla. Varje session/feature kunde skapa en ny "truth"-fil. |
| 5 | Varför saknade RAG en kanonisk källa? | RAG-index skapades ad-hoc, läste bara 3 filer, och RAG-stubs svarade `ok:true` även när index var tomt – felet doldes. |

**Rotorsak:** Avsaknad av en enda kanonisk sanningskälla + stubs som dolde att systemet var trasigt.

**Åtgärder vidtagna:**
- Skapade `/opt/amos/data/AAMOS_CANON.md` (ENDA kanoniska sanningskällan, E4-klassad)
- Patchade `rag.mjs` (CANON tier-1, alltid läst)
- Byggde om RAG-index (94 chunks)
- Rättade `wavult-facts.mjs` med korrekt LandveX-definition
- Ändrade `LOCKED RULES` i produktionschatten (fakta alltid-injicerad)
- Neutraliserade bostad-orphan (`landvex-landing.html` → redirect)
- Arkiverade 8 dubblett-truth-filer

**Verifierat resultat:** "Säljer LandveX bostäder?" → AI: "Nej... infrastrukturkontroll." HTTP 200.

**Lärdom för nästa workcamp:**
> En enda CANON-fil är bättre än tio semi-korrekta truth-filer. Stubs ska ALDRIG svara `ok:true` på
> tomma svar – det döljer att systemet är trasigt.

---

### INCIDENT 2: OOM-kraschen via SocialAuto restart-storm (2026-06-05)

**Symptom:** Alla domäner mot port 3100 gav timeout (000). amos-core nådde 5.2GB/6.0GB RAM,
1850 aktiva tasks, NATS 503-flood. Systemet var i praktiken nere.

**Tidpunkt:** 2026-06-05 (exakt tid ej loggad i dagbok, men under nattens arbete).

**5 Why-analys:**

| Nivå | Varför? | Svar |
|------|---------|------|
| 1 | Varför kraschade amos-core med OOM? | 5.2GB RAM → 6.0GB limit. Systemet hade 1850 tasks. |
| 2 | Varför var det 1850 tasks? | 137 parallella Chromium-instanser (stealth-mode) körde simultaneously, vardera ~100MB. |
| 3 | Varför körde 137 Chromium-instanser? | SocialAuto (apifly job-posting, `social-account-automation.mjs`) relanserade ALLA queued/failed-jobb vid varje omstart – utan concurrency-tak. |
| 4 | Varför relanserades alla jobb vid omstart? | Kod saknade global semafor/concurrency-limit. Vid restart = ny storm av parallella Chromium-launches. |
| 5 | Varför fanns ingen concurrency-limit? | Funktionen byggdes utan att ta hänsyn till restart-scenariot. Ingen review av resursförbrukning per job. |

**Rotorsak:** SocialAuto's restart-beteende (amplifiering: varje omstart = ny storm) kombinerat
med avsaknad av global concurrency-begränsning.

**Åtgärder vidtagna:**
1. Cancellerade 274 skenande jobb i `/opt/amos/data/social-account-jobs.json`
2. PATCH: global semafor `SOCIALAUTO_MAX_CONCURRENT=3` runt `runAutomation()`, wrapper `_runAutomationCore`

**Verifierat resultat:** amos-core 200, 1.7GB RAM, load 2.0. Stabilt.

**Diagnostisk lärdom:**
> Vid amos-core-strul: kolla ALLTID `pgrep -fc chrome` och `social-account-jobs.json` status-counts FÖRST.
> Restart utan att cancellera jobb förvärrar situationen.

---

### INCIDENT 3: Provider-kredithaveri (xAI/Grok, 2026-06-04)

**Symptom:** Grok/xAI tog slut på krediter mitt i en orkestrering. Erik beskrev det som "generalhaveri".
Orkestreringen kunde inte slutföras. Allt som förlitade sig på Grok som provider blockerades.

**Tidpunkt:** 2026-06-04 under dagsarbete.

**5 Why-analys:**

| Nivå | Varför? | Svar |
|------|---------|------|
| 1 | Varför havererade orkestreringen? | Grok/xAI-kontot var tomt på krediter. |
| 2 | Varför var kontot tomt utan förvarning? | Ingen kredit-monitor för xAI-kontot. |
| 3 | Varför saknades kredit-monitor? | Varje provider behandlades manuellt. Ingen systemisk kreditövervakning. |
| 4 | Varför saknades systemisk kreditövervakning? | AI-gateway (som byggdes natten efter) existerade inte ännu. |
| 5 | Varför byggdes inte AI-gateway tidigare? | Multi-provider failover var inte prioriterat tills haveriet bevisade behovet. |

**Rotorsak:** Avsaknad av proaktiv kreditövervakning och automatisk failover.

**Åtgärder vidtagna (natten 2026-06-04 → 06-05):**
- Byggde AI-gateway (`/opt/amos/data/ai-gateway/gateway.mjs`, port 3270, PM2)
- 6 providers med auto-failover + circuit-breaker
- FAILOVER BEVISAD LIVE (trasig provider → groq, 1 hopp)
- Provider-monitor (`monitor.mjs`, PM2): pollar 7 providers var 5:e min
- Auto-larm CRITICAL till Winston (kredit) och Johan (nedtid) via HomoDeus
- Tickets utfärdade: Johan PROV-001..006, Winston PROV-W1..6
- Grok exkluderades från gateway tills påfylld

**Absolut regel (Erik, CAPS):**
> "ALDRIG I PRODUKTION. VARJE PROVIDER: PRIMÄRT REVOLUT + FALLBACK ANNAN BANK + AUTO-TOPUP + BUFFERT."

**Ansvarig framåt:**
- Johan/Sven: teknisk setup/monitor/failover
- Winston/Rufus: kort/konton/påfyllning

---

### INCIDENT 4: Leon/Vincento-kontaminering av träningsdata (2026-06-06)

**Symptom:** v3 och v4 av ESLM-träningsdata innehöll 90+129 Leon/Vincento-referenser (train) och
17+18 (validation). Modellen lärde sig en simulerad persona som aldrig existerat. Träningen stoppades.

**Tidpunkt:** Upptäckt 2026-06-06 22:18 efter Eriks klargörande att Leon = simulering.

**5 Why-analys:**

| Nivå | Varför? | Svar |
|------|---------|------|
| 1 | Varför var träningsdata kontaminerad med Leon/Vincento? | Varje träningsexempel hade AAMOS-systemets kontext i system-prompten, inklusive team-mappning med Leon. |
| 2 | Varför fanns Leon i system-prompten? | Leon behandlades som verklig anställd i alla systemfiler. Ingen markering som simulering. |
| 3 | Varför behandlades Leon som verklig? | Ingen kontroll av personas mot HR-register. Leon hade e-post, agent-mappning, payroll-post (EMP-004) och kodade roller. |
| 4 | Varför hade en simulering alla verkliga attribut? | Simuleringen designades för realism – men ingen distinktion skapades mellan "simulerad test-persona" och "verklig anställd". |
| 5 | Varför saknades distinktionen? | Systemet hade ingen metadata-tagg för simulerade vs. verkliga entiteter. |

**Rotorsak:** Avsaknad av entitetstyp-distinktion (simulerad vs. verklig) i systemet, kombinerat med
att Leon hade alla attribut av en verklig anställd (e-post, payroll, kod-routing, agent).

**Åtgärder vidtagna:**
- v3 och v4 kasserades omedelbart
- v5 skapades: droppade 12 371 train + 1 357 val företagsspecifika exempel
- ALLA system-prompts byttes mot neutral generell ("evidensbaserad assistent för verksamhetsdrift")
- 3 parallella purge-agenter kördes (purge1_api, purge2_data, purge3_scripts)
- EMP-004 "Leon Magnusson" (alias för Leon Russo, samma syntetiska pnr) raderades ur payroll/HR
- Slutkoll: Leon Russo=0, Leon Magnusson=0, vincento=0, 900510-3456=0 i aktiv kod

**Effekt på arkitektur:**
Incidenten ledde direkt till principen **Separation of weights & facts** (SD-003):
> "Modellen bär ALDRIG företagsdetalj. Fakta injiceras via MNEMOSYNE vid runtime."

---

### INCIDENT 5: JWT Algorithm Confusion (CVSS 10.0) – Identifierad och åtgärdad 2026-05-08

**Symptom:** Alla `authMiddleware`-instanser använde `jwt.decode()` istället för `jwt.verify()`.
Vem som helst kunde förfalska admin-JWT utan att känna till secret.

**Tidpunkt:** 2026-05-08 under red-team/hardening-arbete.

**5 Why-analys:**

| Nivå | Varför? | Svar |
|------|---------|------|
| 1 | Varför kunde JWT:er förfalskas? | `jwt.decode()` verifierar INTE signaturen – bara decodes base64. |
| 2 | Varför användes `jwt.decode()` istället för `jwt.verify()`? | Förväxling av metodnamn/syfte vid initial implementation. |
| 3 | Varför spreds felet till 6 filer? | Copy-paste av auth-middleware utan review. Ingen centraliserad auth-hjälpfunktion. |
| 4 | Varför fångades det inte i review? | Ingen security review-process eller automatiserad SAST (static analysis). |
| 5 | Varför saknades security review? | Arbetstempon under byggfasen prioriterade features före säkerhetsreviews. |

**Rotorsak:** Copy-paste + avsaknad av centraliserad auth-hjälpfunktion + ingen security review.

**Åtgärder:** Fixad i 6 filer. `alg:none`-attack blockerad. Rate limiting, security headers, input validation tillagda.

---

### INCIDENT 6: Kafka-backbone degraderad i 8 dagar (2026-06-07)

**Symptom:** Kafka-klustret (3-broker KRaft StatefulSet) körde i degraderat läge med 2/3 brokers i
8 dagar utan att det uppmärksammades. kafka-1 saknades.

**Tidpunkt:** Upptäckt 2026-06-07 14:45 under infrastrukturinventering.

**5 Why-analys:**

| Nivå | Varför? | Svar |
|------|---------|------|
| 1 | Varför körde Kafka med 2/3 brokers? | kafka-1 kunde ej skapas pga ResourceQuota-blockering och borttagen EBS-volym. |
| 2 | Varför blockerade ResourceQuota? | init-container `fix-volume` saknade resource limits → `wavult-quota` blockerade (FailedCreate ×721 över 8 dagar). |
| 3 | Varför var EBS-volymen borttagen? | kafka-1:s PVC var bunden till vol-0891ca1531dc90def som raderats (InvalidVolume.NotFound). |
| 4 | Varför uppmärksammades det inte? | Ingen monitoring av Kafka broker-hälsa. Degraderat läge genererade inga larm. |
| 5 | Varför saknades Kafka-monitoring? | Observability-gap. Fokus på app-hälsa, ej backbone-hälsa. |

**Rotorsak:** Avsaknad av Kafka broker-hälsoövervakning. 8 dagar = oacceptabelt för produktionsbackbone.

**Åtgärder:**
- Patchade init-container med resource limits (25m/64Mi requests, 100m/128Mi limits)
- Raderade orphaned PVC → EBS-CSI provisionerade ny 20Gi gp3
- Broker rejoinade via replikation (RF=3 tålde det)
- Rolling restart av hela STS
- **RESULTAT:** 3/3 brokers Running, 0 under-replicated partitions, ISR fullständig

---

### INCIDENT 7: host-2 DNS-beroende på Tailscale MagicDNS

**Symptom:** host-2 (AMI-klon av server-2) kunde inte resolva RDS-DNS och gav ENOTFOUND.
`/health/ready` = DEGRADED. Hade registrerats i target group (tur att djup health-check stoppade det).

**Tidpunkt:** 2026-06-05 02:38–03:09 UTC.

**5 Why-analys:**

| Nivå | Varför? | Svar |
|------|---------|------|
| 1 | Varför kunde inte host-2 resolva RDS? | `/etc/resolv.conf` pekade på 100.100.100.100 (Tailscale MagicDNS). host-2 hade ingen Tailscale. |
| 2 | Varför pekade resolv.conf på Tailscale? | AMI skapades från server-2 som kör Tailscale. Statisk resolv.conf kopierades. |
| 3 | Varför använder server-2 Tailscale som primär DNS? | Tailscale MagicDNS installerades tidigt för dev-convenience och ersatte VPC-resolver. |
| 4 | Varför byggdes ingen DNS-resiliens in? | Ingen policy för DNS-konfiguration på prod-hostar. |
| 5 | Varför saknades DNS-policy? | Det fungerade på server-2 – problemet syntes bara vid skalning till ytterligare host. |

**Rotorsak:** Prod-DB-resolution beroende av Tailscale. Ej synligt på en host, kritiskt på två.

**Åtgärder:**
- host-2 v2: user-data skriver `/etc/resolv.conf` → nameserver 172.31.0.2 (VPC-resolver) + `chattr +i`
- server-2: systemd-resolved drop-in `/etc/systemd/resolved.conf.d/99-vpc-fallback.conf` (FallbackDNS=172.31.0.2)
- **ALB-lärdom:** Deep health-check (`/health/ready` med DB-check) förhindrade att degraderad host fick trafik.

---

## AVSNITT 2: KAIZEN-REGISTER

Kaizen = kontinuerliga förbättringar som identifierades och genomfördes under workcampet.

### K-001: env-preload.mjs löser ESM-import-ordningsproblematik
**Problem:** Stripe och APNS lästes vid ESM-import-tid (rad 11) FÖRE env-loadern (rad 34+) → låstes i MOCK_MODE.
**Förbättring:** `env-preload.mjs` importeras som ALLRA FÖRSTA rad i `index.mjs` – laddas hela env-filen innan någon route-import.
**Effekt:** End-to-end Stripe-session skapad (cs_test_…). Inga kodändringar vid sk_live_-switch.

### K-002: ALB health-check → /health/ready (djup, DB-check)
**Problem:** ALB health-check mot `/health` (liveness) = process up men ej DB. En degraderad host fick trafik.
**Förbättring:** Health-check ändrad till `/health/ready` som gör faktisk DB-round-trip.
**Effekt:** host-2 (ENOTFOUND på RDS) hölls automatiskt utanför rotation. Self-protecting arkitektur.

### K-003: Idempotent Stripe-webhook med processed_stripe_events-tabell
**Problem:** Dubbel webhook (Stripe-retry ELLER 2 hosts) → dubbel kreditering möjlig.
**Förbättring:** Ny tabell `quixzoom.processed_stripe_events` (event_id PK), `INSERT ON CONFLICT DO NOTHING` + atomisk `balance = balance + credits`.
**Effekt:** Dubbel-kreditering matematiskt omöjlig oavsett antal hostar eller Stripe-retries.

### K-004: Concurrent-tak för SocialAuto (SOCIALAUTO_MAX_CONCURRENT=3)
**Problem:** SocialAuto relanserade alla queued jobs vid restart utan tak → OOM.
**Förbättring:** Global semafor runt `runAutomation()`, wrapper `_runAutomationCore`.
**Effekt:** Max 3 Chromium-instanser simultant. Restart = ingen storm.

### K-005: AI-gateway med auto-failover (circuit-breaker)
**Problem:** En provider (Grok) tar slut → hela orkestreringen havererar.
**Förbättring:** AI-gateway med 6 providers, task-kedjor (reasoning/fast/search/creative/financial/default), circuit-breaker.
**Effekt:** FAILOVER BEVISAD LIVE: trasig provider → groq, 1 hopp, 0 avbrott i orkestrering.

### K-006: Provider-monitor var 5:e minut med auto-larm
**Problem:** Ingen visste att xAI/Grok var tomt förrän orkestrering havererade.
**Förbättring:** `monitor.mjs` (PM2) pollar 7 providers var 5:e min. Auto-larm CRITICAL till Winston (kredit) och Johan (nedtid) via HomoDeus.
**Effekt:** Reaktiv → proaktiv kreditövervakning.

### K-007: AAMOS_CANON.md som enda kanonisk sanningskälla
**Problem:** 39 konkurrerande truth-filer → LandveX=bostad-incidenten.
**Förbättring:** En enda CANON-fil (E4), tier-1 i RAG, alltid-injicerad i produktionschat.
**Effekt:** Systemet svarar korrekt om LandveX. Fakta uppdateras på ett ställe.

### K-008: Stub-transparens (X-AAMOS-Stub header + Warning + _stub:true)
**Problem:** 432 stubs svarade `ok:true` på tomma svar → dolde att subsystem var döda.
**Förbättring:** Varje stub-träff loggas + `X-AAMOS-Stub:true` + `Warning`-header + `_stub:true` i body + ny `/api/_stub-report`.
**Effekt:** Konfigurerad förmåga som ej är ansluten syns nu i instrumenteringen.

### K-009: SSM Run Command för root-operationer (nginx/systemd utan sudo-beroende)
**Problem:** nginx-filer ägdes av root/ec2-user → bernt kunde ej skriva → blockerade nginx-tickets till Johan.
**Förbättring:** AWS SSM Run Command via IAM-roll `platform-ec2-ssm-role`. Mönster: `aws ssm send-command --document AWS-RunShellScript`, base64-encoda komplexa script.
**Effekt:** Kan nu ändra nginx, systemd, certs via SSM. Inga fler "väntar på Johan för root"-blockeringar.

### K-010: LLM-as-judge med 4-lagers fallback
**Problem:** Keyword-matchning för svenska för trubbig. Qwen-32B som domare för svag (trodde "PASS" = EU-direktiv).
**Förbättring:** Judge-v2: Bedrock-Opus-4-6 → Sonnet-4-5 → direkt-Opus-4-8 → Qwen-235B. LLM-schema-agnostisk parser.
**Effekt:** En poliskontroll är nu aldrig svagare än det den vaktar.

### K-011: Separation of weights & facts (arkitekturprincip)
**Problem:** Företagsdetaljer inbränt i modellvikter = säkerhetsrisk, kräver omträning vid ändring.
**Förbättring:** ALETHEIA (modellvikter) = generell evidensmotor. MNEMOSYNE (CANON/RAG) = runtime-fakta.
**Effekt:** Ingen faktaläcka via vikter. Fakta ändras utan omträning. ESLM säljbar generellt.

### K-012: POS→Ledger automatisk bokföring (idempotent)
**Problem:** Restaurangförsäljning postades ej automatiskt till aamos-ledger → SIE4 var tom.
**Förbättring:** `POST /pos/ledger/post-day {fecha}` + cron 03:15 Europe/Madrid. Tracking-tabell `restaurant_ledger_postings` (UNIQUE tenant+datum). Idempotent.
**Effekt:** "Säljer jag en paella, hamnar den i böckerna?" = JA. Automatiskt, utan handpåläggning.

### K-013: Ticket-system för felrapportering (aamos-restaurant-tickets:3318)
**Problem:** Ingen strukturerad väg för restaurangtjänster att rapportera integrationsproblem.
**Förbättring:** Ny Rust/axum-tjänst med severity (low/medium/high/critical), status-flöde, källa (staff/system/customer/agent), HTML-dashboard.
**Effekt:** POS auto-skapar high-severity accounting-ticket när ledger-postning failar. Systemintelligens istället för stum kraschtystnad.

### K-014: Webhook-idempotens som förutsättning för multi-host
**Problem:** Multi-host (host-2) blockerades av att Stripe-webhooks ej var idempotenta.
**Förbättring:** Löstes som prerequisite för RES-004. Multi-host + idempotens = sann redundans.
**Effekt:** Systemet är nu multi-host-redo utan risk för ekonomisk data-korruption.

### K-015: Jurisdiktionsmedveten onboarding (ES/SE och fler)
**Problem:** Onboarding-tjänst hårdkodad för Sverige → spansk CIF och IVA-satser avvisades.
**Förbättring:** `country` (ISO-3166, default "SE") i register + DB-kolumn. ES→CIF/NIF + IVA {4,10,21}, SE→orgnr + moms {12,25}.
**Effekt:** Spansk chiringuito kan slutföra alla 7 onboarding-steg. Global skalning möjlig.

### K-016: Gravation arm64/Graviton-only för EKS (deterministisk flotta)
**Problem:** Preferred (80/20 arm64/x86-fallback) lämnar en variabel som kan överraska i prod.
**Förbättring:** Required arm64-only (nodeSelector + requiredDuringScheduling). Alla images: `--platform linux/arm64`.
**Effekt:** Homogen flotta, reproducerbart beteende, ~20% billigare. Inga edge-cases från mixed architectures.

### K-017: Django E2E-simuleringen (986 orders, €146.5k, 24/24 OK)
**Problem:** Restaurang-stacken hade 6 oupptäckta integrationsbuggar (VAT overflow, analytics-paths, decimal-parsing, etc.).
**Förbättring:** Fullständig månads-driftsimulering med 986 orders, 15 tjänster, ~130 endpoints, 14 verifieringsfaser.
**Effekt:** Alla 6 buggar hittades och fixades. SIE4-kedjeavstämning POS→Modelo303→Ledger→SIE4 perfekt.

---

## AVSNITT 3: TEKNISKA LÄRDOMAR

### TL-001: Verifiera ALLTID den körande filen, inte filen på disk
**Källa:** Produktionschat-fix (2026-06-06)
> Körande `amos-core` = `services/amos-core/server.mjs`. `scripts/server.mjs` KÖRS INTE.
> Hade nära håll på att fixa fel fil. Kontrollera alltid med `ps aux` eller `systemctl status`.

### TL-002: Stubs som svarar ok:true döljer döda subsystem
**Källa:** LandveX-incidenten + 432 stubs-audit (2026-06-06)
> Instrumentering ska visa sanningen, inte dölja den. En stub som svarar `ok:true` på tom respons är
> aktivt skadlig – det ger en falsk bild av systemhälsan.

### TL-003: ESM import-ordning är deterministisk och kan bita
**Källa:** Stripe env-preload.mjs fix (2026-06-05)
> I ES modules körs importerade moduler vid import-tid, inte vid runtime. Variabler som läses tidigt
> (t.ex. env-variabler) måste finnas INNAN importen. Lösning: preload-modul som allra första import.

### TL-004: AMI-kloning kopierar statisk konfiguration inklusive resolver
**Källa:** host-2 DNS-incidenten (2026-06-05)
> AMI-snapshot fryser in all konfiguration inklusive `/etc/resolv.conf`. Om produktionsmiljön beror
> på ett sidoverktyg (Tailscale) som inte finns på alla hostar, sprids beroendet vid kloning.
> Lösning: user-data-script som skriver DNS-konfiguration vid boot.

### TL-005: `pgrep -fc chrome` är första diagnostiksteg vid amos-core-strul
**Källa:** OOM-incidenten (2026-06-05)
> Kolla antalet Chromium-instanser och social-account-jobs.json status-counts INNAN restart.
> Restart utan job-avbrottning förvärrar storm-beteende exponentiellt.

### TL-006: LLM-as-judge måste vara starkare än det den poliskontrollerar
**Källa:** ESLM red-team, judge-evolution (2026-06-06)
> Qwen-32B som domare klassade "PASS" som ett EU-direktiv och godkände felaktiga svar.
> En poliskontroll som är svagare än systemet den granskar ger falsk säkerhet.
> Regel: judge-modellen ska ALLTID vara starkare än production-modellen.

### TL-007: Keyword-matchning för svenska är för trubbig som red-team
**Källa:** ESLM red-team v1 vs v2 (2026-06-06)
> Keyword-matchning fångade inte subtila felaktigheter i svenska svar. Ersattes av LLM-as-judge (v2).
> Lärdom: för komplexa domäner krävs semantisk bedömning, inte mönstermatchning.

### TL-008: `gpt-5.5-pro` kräver `/v1/responses`, ej `/chat/completions`
**Källa:** Infra-fakta 2026-06-05
> OpenAI:s nya API-endpoint är inte bakåtkompatibel. Mycket långsam (>20 min öppna promptar).
> Undvik för tidskänsliga körningar.

### TL-009: sqlx compile-time-makron (`query!`) kräver live DATABASE_URL vid build-tid
**Källa:** EKS-migration compliance-tjänst (2026-06-07)
> 14/15 Rust-tjänster byggde direkt. Compliance: enda med `query!`-makron → krasch utan DATABASE_URL.
> Lösning: `--build-arg DATABASE_URL` vid Docker build. Alternativt: använd `query()` (runtime) istället.

### TL-010: ResourceQuota blockerar pod-skapande tyst (FailedCreate-events)
**Källa:** Kafka-degraderingen (2026-06-07)
> kafka-1 fick FailedCreate ×721 utan larm. ResourceQuota stoppade init-containern pga saknade resource limits.
> Lärdom: Resource limits ska finnas på ALLA init-containers. Övervaka FailedCreate-events.

### TL-011: RDS SSL-konfiguration krävs i Node.js-connections mot AWS RDS
**Källa:** tool-registry SSL-fix (2026-06-05)
> `new Pool({connectionString: AMOS_DB_URL})` utan SSL-config → RDS avvisade med "no pg_hba.conf entry".
> Lösning: `ssl: {rejectUnauthorized: false}` i Pool-konfiguration.

### TL-012: Providermodellnamn förändras – håll dem uppdaterade
**Källa:** Gemini 2.0→2.5 fix (2026-06-05)
> Gamla modellnamn (Gemini 2.0, gammal Haiku) kraschade tyst. Orsakade dold instabilitet i orkestrering.
> Lärdom: API-modellnamn är ej stabila – håll en provider-modell-förteckning uppdaterad.

---

## AVSNITT 4: PROCESSLÄRDOMAR

### PL-001: Parallellisering med tickets och subagenter är kraftfullt
**Källa:** 2026-06-06 parallellbygge (14 tickets, 4 epics, 8 subagenter)
> 90/100 tickets lösta på en session. Erikmönstret: "gör tickets, starta agenter." Fungerar för
> parallella epics som inte delar state. Kräver tydlig tickets-struktur och agent-scope.

### PL-002: Red-team FÖRE promotion är inte valfritt
**Källa:** ESLM-processen (2026-06-06)
> ALETHEIA-baslinjen: 33% passerade, 5 kritiska brister. Utan red-team hade modellen gått live med
> LandveX=bostad och hallucinerande org-nr. Red-team är minimikravet, inte ett bonus-steg.

### PL-003: Ekonomifunktionen måste ha proaktiv förvarning
**Källa:** xAI/Grok-haveriet (2026-06-04)
> Reaktiv hantering (Erik ringer Winston när Grok är tomt) är oacceptabelt. Systemet måste larma
> INNAN kontot är tomt. Auto-topup + buffert + 5-min kreditkoll är miniminivå.

### PL-004: Kör simuleringen INNAN du berättar för kunden att det är redo
**Källa:** Restaurang-plattformens 6-buggars-fynd (2026-06-07)
> Erik trodde restaurang-stacken var "100% redo för onboarding". E2E-test avslöjade BLOCKER (spansk CIF).
> Lärdom: "100% redo" valideras av systemet, inte av en persons uppskattning. Kör alltid simulering.

### PL-005: Behörighetshierarkier ska tydliggöras i agentmailboxen
**Källa:** Beroende av Johan för nginx (2026-06-04/05)
> Bernt (bernt-user) kan ej skriva nginx-filer (root/ec2-user). Blockade i veckor tills SSM-mönstret
> upptäcktes. Lärdom: dokumentera åtkomstgränser och eskaleringsvägar tydligt från start.

### PL-006: Kanoniska namn ska låsas tidigt, inte sent
**Källa:** Hermes→Hephaistos-omdöpning (2026-06-07)
> Hermes behövde döpas om (76 filer) pga namnkollision med externa bibliotek i träningsdata.
> Lärdom: namnkonflikter med populära bibliotek är dyrare att fixa sent. Välj ovanliga egennamn.

---

## AVSNITT 5: ARKITEKTURLÄRDOMAR

### AL-001: Separation of concerns gäller även AI-modeller
**Källa:** ESLM-arkitektur, SD-003 (2026-06-06)
> Modellvikter (ALETHEIA) och faktabas (MNEMOSYNE) är separata ansvarsområden, precis som
> kod och konfiguration. En modell som bär konfiguration (företagsfakta) är svår att uppdatera.

### AL-002: Event-backbone (Kafka) ska väljas och övervaka från dag 1
**Källa:** Kafka-degraderingen 8 dagar (2026-06-07)
> Tre parallella event-mekanismer (Kafka, aamos-event-bus, NATS/Redis) skapade oklarheter.
> Kafka var productionstanken men 2/3 brokers – utan larm i 8 dagar. Välj en backbone, övervaka den.

### AL-003: Gitops + EKS + ExternalSecrets är rätt mönster (Siemens-standard)
**Källa:** EKS-migration referensmönster (2026-06-07)
> ArgoCD + external-secrets + ClusterSecretStore + AWS SSM = reproducerbar, auditbar deploy.
> Varje workload: ExternalSecret → Deployment → Service → Kong-route. Mönstret verifierades end-to-end.

### AL-004: Single point of truth gäller all systemkunskap
**Källa:** LandveX-incidenten (2026-06-06)
> 39 competing truth-filer → inkonsistens. AAMOS_CANON.md som enda E4-fil löste grundproblemet.
> Samma princip gäller all systemkunskap: en CANON, alla vet var de hittar sanningen.

### AL-005: Health-check-djup avgör om redundansen fungerar på riktigt
**Källa:** host-2 DNS-incidenten (2026-06-05)
> `/health` (liveness) = process up, men ej nödvändigtvis fungerande. `/health/ready` (readiness) med
> faktisk DB-round-trip är minimikravet för ALB-integrering. Ytlig health = falsk trygghet.

### AL-006: Multi-AZ är grundkrav, inte lyx
**Källa:** RES-001/003 (2026-06-05)
> Single-AZ RDS: RTO = timmar. Multi-AZ: RTO 60–120s. Diff = $700/mån. Erik: "Vi har inte alternativ."
> Lärdom: bygg multi-AZ från start. Eftermontage är dyrare (maintenance window, DNS-propagation).

### AL-007: Idempotens är förutsättning för horisontell skalning
**Källa:** Stripe-webhook-idempotens som Fas-2-prerequisite (2026-06-05)
> Kan inte lägga till fler hostar utan idempotenta webhooks. Idempotens är inte ett nice-to-have –
> det är det som gör horisontell skalning säker.

---

## AVSNITT 6: ERKÄNDANDEN

### Vad gick riktigt bra?

1. **Parallellisering med subagenter** – 90/100 tickets på en session bevisar att multi-agent-koordination fungerar.
2. **Deep health-check räddade produktionen** – host-2 med trasig DNS-resolution fick aldrig trafik tack vare `/health/ready`.
3. **Red-team-grinden fångade kritiska brister** – utan red-team hade LandveX=bostad gått live.
4. **SSM-mönstret löste root-beroendet** – månaders blockering av nginx-filer löst på en timme.
5. **EKS-migrationen gick smidigt** – 17 tjänster, 34 pods, alla på Graviton/arm64, alla friska.
6. **DDP-träningen fungerade** – från ~8h på A10G till ~1h på 8x A100. Ny hastighetstandard.
7. **Restaurang E2E-simulering** – hittade 6 riktiga integrationsbuggar och kvantifierade dem till öret.

### Vad var svårast?

1. **Leon/Vincento-purgen** – kräver precision (behåll andra Leons, radera bara rätt entiteter). 3 agenter parallellt krävdes.
2. **Kafka-degraderingen** – 8 dagar utan larm är ett allvarligt observability-gap. Fixades men borde ha fångats dag 1.
3. **Judge-modell-valet** – det tog tre iterationer (keyword → Qwen-32B → Opus-direkt) för att hitta rätt domar-nivå.
4. **Providermodell-avvecklingen** – gamla modellnamn kraschade tyst. Svårt att spåra utan centraliserad provider-förteckning.

---

*Volym 6 av 7 | AMOS Workcamp 2026 | Klassifikation: INTERN – KONFIDENTIELL*
*Nästa: VOL7-AMOS-Operating-System.md*