# AMOS Development Workcamp 2026
# Volume 7: AMOS Operating System — Praktisk handbok för nästa workcamp
# Baserat på lärdomar från 11 maj – 7 juni 2026
# Genererat: 2026-06-07 | Klassifikation: INTERN – KONFIDENTIELL

---

> **Syftet med detta dokument:** Du har precis vaknat upp inför nästa workcamp. Den här handboken
> är allt du behöver för att köra AMOS-systemet korrekt från dag ett — utan att upprepa de misstag
> vi redan betalat priset för.
>
> Skriv ut den. Läs den. Gör den till reflexer.

---

## AVSNITT 1: TEAMET

### Korrekt sammansättning — 3 personer

| Person | Roll | AI-Agent | Primärkommunikation |
|--------|------|---------|-------------------|
| **Erik Svensson** | Founder / Chairman / Product Owner / Strategic Lead | **Bernt** | Webchat (OpenClaw), Telegram 8783557028 |
| **Johan Berglund** | CTO / Testing / Documentation / Process | **Sven** | HomoDeus mailbox |
| **Winston Bjarnemark** | CFO / Ekonomiansvarig | **Rufus** | HomoDeus mailbox |

**Ekonomiskt ansvar — Erik Svensson:**
> Alla ekonomirelaterade beslut går via Winston/Rufus. Det inkluderar: banker, betalningar, bokföring,
> skatt, payroll, Stripe-integration, Nordea PSD2, investeringar, leverantörsbetalningar, AI-provider-
> krediter, kreditkort och försäkringar. Erik ringer INTE till banken. Winston gör det.

**OBS om rollen COO/Dennis Bjarnemark:**
Dennis Bjarnemark hoppade av INNAN workcampet startade och ska INTE förekomma i dokumentation.

---

## AVSNITT 2: DAGLIG RYTM

### Schema — ett strukturerat dygn

```
08:00 UTC — Morgonbriefing (Morning Standup)
08:00–12:00 — Production Block A (tunga arkitekturbeslut, infrastruktur, strategi)
12:00–13:00 — Middag + paus
13:00–19:00 — Production Block B (tickets, parallella subagenter, implementation)
19:00–19:30 — EOD Review (End-of-Day)
19:30–      — Fritt (optionellt kvällsarbete om Erik driver det)
```

### 2.1 Morgonbriefing 08:00 UTC

Varje dag börjar med en kortfattad review av nattens händelser och dagens plan.

**Briefing-agenda (max 30 min):**
1. **Systemhälsa** — `sudo systemctl status amos-core` + `pgrep -fc chrome` + RAM-koll
2. **Öppna incidents** — Har något gått ned under natten?
3. **AI-provider krediter** — Winston/Rufus bekräftar att alla providers har marginal
4. **Dagens priorities** — Vad producerar mest värde idag? (Erik beslutar)
5. **Blockerare** — Vad behöver lösas INNAN produktion kan starta?
6. **Subagentplan** — Vilka tasks kan parallelliseras och köras av subagenter?

**Checklista morgonkontroll:**

```bash
# 1. amos-core status
sudo systemctl status amos-core

# 2. Kolla RAM och chrome-processer
free -h && pgrep -fc chrome

# 3. ALETHEIA/vLLM på GPU-box (om aktiv)
curl -s http://172.31.36.61:8000/health | head -5

# 4. Kafka broker-hälsa (EKS)
kubectl get pods -n kafka | grep kafka

# 5. Produktionsmail senaste triage
cat /opt/amos/data/agent-mailbox.json | python3 -m json.tool | tail -40

# 6. Stubs-rapport (dolda fel)
curl -s http://localhost:3100/api/_stub-report | python3 -m json.tool

# 7. AI-gateway hälsa
curl -s http://localhost:3270/health
```

### 2.2 Production Block A (08:00–12:00 UTC)

**Fokus:** Det som kräver full koncentration och strategisk bedömning.

- Arkitekturella beslut och designval
- Infrastruktur (RDS, EKS, ALB, DNS)
- Red-team ESLM / AI-modell-validering
- Säkerhetshärdning och CVE-åtgärder
- Strategiska möten med teamet
- Kanoniska beslut som påverkar hela systemet

**Regel för Production Block A:**
> Inga halvbakade beslut. Alla arkitekturella val ska dokumenteras i MEMORY.md eller VOL4 med
> datum, beslutsfattare och Claude×Siemens-motivering.

### 2.3 Middag + paus (12:00–13:00 UTC)

- **Obligatorisk paus.** Ingen dator.
- Om något brinner: Erik bedömer om det är P1 (se eskaleringsvägar nedan).
- Systemet skall klara sig en timme utan mänsklig intervention. Om det inte kan det — är det
  ett arkitekturproblem, inte ett lunchproblem.

### 2.4 Production Block B (13:00–19:00 UTC)

**Fokus:** Volymproduktion via parallellisering.

- Tickets-sprint (Epics med subagenter)
- Implementation av morgonens beslut
- E2E-tester och verifieringar
- Dokumentation och kodgranskning
- Deploy till staging → produktion (CI/CD via EKS)

**Mönster för effektiv ticket-sprint (lärt från 2026-06-05/06):**

```
1. Skapa tydliga ticket-scope utan state-beroenden mellan varandra
2. Starta 4–8 subagenter parallellt per epic
3. Varje agent: en ticket, ett scope, tydligt acceptanskriterium
4. Samla resultat — verifiera med riktiga UUID/endpoints (ej test-ID)
5. Deploy i batch — amas-core restart en gång, ej efter varje ticket
```

### 2.5 EOD Review (19:00–19:30 UTC)

**Agenda:**

1. Vad levererades idag? (lista konkret)
2. Vad blockerade? (ärlig analys)
3. Öppna incidents? (eskalering om nödvändigt)
4. Morgondagens prioritering (Erik beslutar)
5. Uppdatera MEMORY.md med dagens beslut
6. Kolla provider-krediter inför natten
7. Terminera SPOT-instanser som inte behövs (FinOps-disiplin)

---

## AVSNITT 3: VERKTYGSPROTOKOLL

### 3.1 SSM — Root-operationer på server-2

SSM (AWS Systems Manager Run Command) är det primära verktyget för root-operationer.
Använd det när bernt-user inte har rättigheter (nginx-filer, systemd-tjänster, resolv.conf, etc.).

```bash
# Setup — VIKTIGT: unset AWS-credentials, använd default-profil
cd /tmp
unset AWS_ACCESS_KEY_ID AWS_SECRET_ACCESS_KEY AWS_SESSION_TOKEN
export AWS_DEFAULT_REGION=eu-north-1

# Skriv kommando-fil
cat > /tmp/ssm-params.json << 'EOF'
{
  "commands": [
    "ditt-kommando-här"
  ]
}
EOF

# Skicka kommandot
CMD_ID=$(aws ssm send-command \
  --instance-ids i-09b2204a52c2f33c9 \
  --document-name AWS-RunShellScript \
  --parameters file:///tmp/ssm-params.json \
  --output text --query 'Command.CommandId')

sleep 9

# Hämta resultat
aws ssm get-command-invocation \
  --command-id $CMD_ID \
  --instance-id i-09b2204a52c2f33c9 \
  --query '[Status,StandardOutputContent]' \
  --output json
```

**Instanser för SSM:**

| Instans | Instance ID | Användning |
|---------|------------|-----------|
| server-2 | i-09b2204a52c2f33c9 | Primär produktionsserver |
| host-2 | i-0fc20ddba6bb17ead | Redundanshost (eu-north-1a) |

**Kritiska SSM-regler:**
- `⚠️ ALDRIG` hårdkoda secrets i SSM-kommandon (+ och specialtecken manglas i env-vars)
- Använd base64-encoding för komplexa scripts
- SSM kör som **root** — dubbla kontrollera kommandon
- Default AWS-profil = `platform-ai-agent` (har ssm:SendCommand)

**Lösenord och secrets via SSM (rätt sätt):**
```bash
# Koda lösenordet i base64 först
echo -n "ditt_lösenord" | base64

# Skicka via SSM med base64-decode
{
  "commands": [
    "echo 'BASE64STRING' | base64 -d | passwd --stdin anvandare",
    "shred -u /tmp/temp_pwd_file"
  ]
}
```

### 3.2 JWT-generering

**Varning:** Använd ALLTID `jwt.verify()`, ALDRIG `jwt.decode()`.
- `jwt.decode()` = base64-decode utan signaturverifiering = CVSS 10.0 sårbarhet
- `jwt.verify()` = verifierar signaturen korrekt

```javascript
// RÄTT — verifiera alltid
const payload = jwt.verify(token, process.env.JWT_SECRET, { algorithms: ['HS256'] });

// FEL — decode verifierar INTE signaturen
const payload = jwt.decode(token); // ALDRIG i produktion
```

**JWT-generering för test:**
```bash
# Generera admin-token (server-side, kör via SSM eller på server-2)
node -e "
  const jwt = require('jsonwebtoken');
  const token = jwt.sign(
    { sub: 'bernt', role: 'admin', iat: Math.floor(Date.now()/1000) },
    process.env.JWT_SECRET,
    { algorithm: 'HS256', expiresIn: '24h' }
  );
  console.log(token);
"
```

### 3.3 Bedrock-anrop (Claude på AWS)

Claude är upplåst på Bedrock (sedan 2026-06-06 via Anthropic use-case-form).

```bash
# Verifiera Bedrock-åtkomst
aws bedrock-runtime invoke-model \
  --model-id anthropic.claude-sonnet-4-5 \
  --region eu-north-1 \
  --body '{"anthropic_version":"bedrock-2023-05-31","max_tokens":100,"messages":[{"role":"user","content":"Hej"}]}' \
  /tmp/bedrock-test.json && cat /tmp/bedrock-test.json

# Tillgängliga Claude-modeller på Bedrock
# anthropic.claude-sonnet-4-5   (Sonnet 4.5 — snabb + billig)
# anthropic.claude-opus-4-6     (Opus 4.6 — poliskontroll/red-team)
# anthropic.claude-opus-4-8     (Opus 4.8 — starkast domare)
```

**AWS-profil för Bedrock:** `platform-ai-agent` (standard)

### 3.4 SSH-nycklar

| Nyckel | Används till | Sökväg |
|--------|-------------|-------|
| `gpu_deploy_key` | GPU-box / gpu-training (A10G) | `~/.openclaw/workspace/gpu_deploy_key` |
| `s1_key` | server-2 (bernt.wavult.com) | `~/.openclaw/workspace/s1_key` |
| `mac-build-key.pem` | Mac Build Server (eu-west-1) | `~/.openclaw/workspace/mac-build-key.pem` |

```bash
# SSH till GPU-box
ssh -i ~/.openclaw/workspace/gpu_deploy_key ubuntu@13.61.176.142

# SSH till Mac Build Server
ssh -i ~/.openclaw/workspace/mac-build-key.pem ec2-user@3.249.41.127

# SSH till server-2 (vanligtvis via OpenClaw direkt)
ssh -i ~/.openclaw/workspace/s1_key bernt@bernt.wavult.com
```

### 3.5 AWS-profiler

```bash
# Standard-profil för agentarbete
export AWS_PROFILE=platform-ai-agent
export AWS_DEFAULT_REGION=eu-north-1

# Verifiera aktiv profil
aws sts get-caller-identity

# Viktiga resurser
# EKS Cluster: (hämta med aws eks list-clusters)
# ECR Registry: 155407238699.dkr.ecr.eu-north-1.amazonaws.com
# RDS Endpoint: platform-identity-core.cvi0qcksmsfj.eu-north-1.rds.amazonaws.com
# ALB: aamos-prod-alb-709257248.eu-north-1.elb.amazonaws.com
# S3 (modeller): platform-ouroboros-models
```

---

## AVSNITT 4: AI-MODELL-GOVERNANCE

### 4.1 Claude × Siemens-linsen (LÅST 2026-06-06 20:23 UTC)

Alla beslut fattas genom linsen:
> *"Tänk alltid som att du företräder Claude och Siemens i ett samarbete. Det är beslutsgrunden
> för det mesta."* — Erik Svensson

**Claude-sidan:**
- Säkerhet före färdigställande
- Ärlighet och evidens alltid
- Verifiera, aldrig gissa
- Inga överdrifter
- Säg "vet ej" hellre än hitta på
- Transparens — surface:a verkliga fynd (även obekväma)

**Siemens-sidan:**
- Industriell ingenjörsdisciplin
- ISO/TÜV/governance-tankesätt
- Reproducerbarhet
- FinOps-medvetenhet
- Inga single points of failure
- Bygg som ett seriöst bolag — inte startup-genvägar

**Testet:** "Skulle Claude + Siemens stå bakom detta beslut med sina namn?" Om nej → gör om.

### 4.2 Graderad Modell-Orkestrering (POLISKONTROLL)

```
Lager 1 — ARBETE:       ALETHEIA (7B), konkret drift, mailtriage. ~gratis. Tusentals anrop.
Lager 2 — RESONEMANG:   Qwen3-32B/235B, bredd och kreativitet. Billigt.
Lager 3 — POLISKONTROLL: Claude Opus 4.x (via Bedrock). Sista grind FÖRE handling/leverans.
                          Dyrast — används SÄLLAN. Körs vid: red-team, kritiska beslut, live-deploy.
```

**Principen:** Lägg kostnaden där risken är, inte överallt.

**AI-Gateway (port 3270):**
```bash
# Hälsokontroll AI-gateway
curl -s http://localhost:3270/health | python3 -m json.tool

# Skicka request via gateway (automatisk failover)
curl -s http://localhost:3270/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model":"auto","messages":[{"role":"user","content":"test"}]}'
```

**Provider-kedjor (failover-ordning):**
- `reasoning`: Qwen3-235B → Claude Opus → Grok (om kreditad)
- `fast`: Qwen3-32B → Gemini 2.5 Flash → Groq
- `search`: Perplexity sonar-pro → Gemini
- `default`: Qwen3-32B → Claude Sonnet → Gemini

### 4.3 Red-team ALLTID före promotion

**Regel (ABSOLUT, lärd från ESLM v1-haveriet):**
> Red-team är inte ett bonus-steg. Det är minimum. Utan red-team riskerar vi att LandveX = bostad
> går live igen, eller att org-nr hallucineras. Red-team FÖRE varje promotion till produktion.

**Red-team-mönster:**
```bash
# Kör ESLM red-team harness
node /opt/amos/api/security/eslm-judge.mjs

# Judge-modell: ALLTID starkare än det den poliskontrollerar
# Om ESLM (7B) → Judge = Claude Opus 4.8 (via Bedrock eller direkt)
# Aldrig: Qwen-32B som judge för Qwen-32B i produktion
```

**Judge-fallback-kedja (K-010):**
1. Bedrock Opus 4.6 → 2. Sonnet 4.5 → 3. Direkt Opus 4.8 → 4. Qwen-235B

### 4.4 Separation of weights & facts (SD-003, LÅST 2026-06-06 22:40)

```
ALETHEIA (vikter/weights):
  → Generell evidensmotor
  → Tränas på: bokföring, compliance, GDPR, skatt, avtal, processer, HR, säkerhet
  → ALDRIG inbränta: företagsnamn, org-nr, agent-mappningar, kunddata
  → Säljbar generellt utanför Wavult

MNEMOSYNE (fakta/facts):
  → AAMOS_CANON.md + RAG-index (94 chunks)
  → Injiceras vid RUNTIME via RAG/kontext
  → Innehåller: LandveX-def, org-nr, team-mappning, produktdefinitioner
  → Ändras utan omträning av ALETHEIA
```

**Konsekvens:** Om du behöver uppdatera en fakta om bolaget → uppdatera AAMOS_CANON.md.
ALDRIG träna om modellen för att ändra en produktbeskrivning.

### 4.5 AAMOS_CANON.md — Den enda sanningskällan

```bash
# Plats
/opt/amos/data/AAMOS_CANON.md

# Kontrollera via SSM att den är korrekt
aws ssm send-command --instance-ids i-09b2204a52c2f33c9 \
  --document-name AWS-RunShellScript \
  --parameters '{"commands":["head -50 /opt/amos/data/AAMOS_CANON.md"]}' \
  --output text --query 'Command.CommandId'
```

**CANON-regler:**
- E4-klassad (Erik-låst) — inga ändringar utan Erik-godkännande
- Tier-1 källa i RAG — läses alltid, ej optionell
- En fil, inte tio halvkorrekta kopior
- Om en fakta stämmer i CANON men är fel i verkligheten → uppdatera CANON, inte modellen

---

## AVSNITT 5: ESKALERINGSVÄGAR

### P1 — Kritisk incident (system nere, ekonomisk exponering)

```
1. OMEDELBART: Bernt pingar Erik via Telegram: 8783557028
2. Erik bedömer: är det P1? (system nere >5min, ekonomisk risk, säkerhetsbrist)
3. Ja = Erik meddelar Winston + Johan direkt
4. Amos-core nere → SSM-diagnos + restart (se diagnostikprotokoll nedan)
5. Ekonomisk exponering → Winston/Rufus blockerar/reverse INNAN Erik godkänner fix
```

### Ekonomi → Winston / Rufus

```
Kanal: HomoDeus mailbox
POST http://localhost:3100/api/homo-deus/send
{
  "from": "bernt",
  "to": "rufus",
  "subject": "EKONOMI: [ämne]",
  "priority": "high",
  "body": "..."
}

Alternativt: direkt meddelande i agent-mailbox.json
/opt/amos/data/agent-mailbox.json
```

**Winst/Rufus-eskaleringar gäller:**
- AI-provider krediter (låg saldo → auto-topup)
- Stripe-webhooks och betalningsproblem
- Fakturor och leverantörskort
- Nordea PSD2 och bankärenden

### Teknik → Johan / Sven

```
Kanal: HomoDeus mailbox (to: "sven")
Ämnen: nginx, EKS, DNS, SSL-certs, CI/CD, Kafka, databas-migreringar
OBS: Johan kan INTE ta root på server-2 via bernt-user — använd SSM
```

### Infra-root → SSM

```
Om bernt-user saknar rättigheter → SSM Run Command (se avsnitt 3.1)
SSM kör som root. Inga sudo-beroenden.
```

---

## AVSNITT 6: SÄKERHETSREGLER

### 6.1 Secrets-hantering

**Primär: AWS Secrets Manager** (INTE HashiCorp Vault — port 8200 är dead)

```bash
# Hämta secret
aws secretsmanager get-secret-value \
  --secret-id aamos/prod/mail-accounts \
  --query SecretString --output text

# Skapa ny secret
aws secretsmanager create-secret \
  --name aamos/prod/ny-tjänst \
  --secret-string '{"key":"value"}'
```

**Förbjudet:**
- ❌ Klartext secrets i SSM-output eller shell-kommandon
- ❌ Secrets hårdkodade i kod eller git
- ❌ Secrets i env-variabler via `export SECRET=värde` i logg
- ❌ HashiCorp Vault (vault.aamos.systems = 503, nedlagt)

**Rätt mönster för lösenord:**
```bash
# 1. Generera lösenord
openssl rand -base64 24 > /tmp/pwd.tmp

# 2. Koda för SSM
base64 /tmp/pwd.tmp

# 3. Skicka via SSM (base64-decoda i kommandot)
# 4. Ta bort temp-fil
shred -u /tmp/pwd.tmp
```

### 6.2 SSM för root-operationer

- All root-access på server-2/host-2 via SSM (ej sudo-beroende)
- SSM loggas automatiskt i AWS CloudTrail = auditbart
- Använd ALLTID default-profil (`unset` AWS_ACCESS_KEY_ID etc.) när SSM anropas
- Verifiera Instance ID före deploy: `i-09b2204a52c2f33c9` (server-2), `i-0fc20ddba6bb17ead` (host-2)

### 6.3 Webhook-idempotens

Alla Stripe-webhooks MÅSTE vara idempotenta:
```sql
-- Mönster: processed_stripe_events-tabell
INSERT INTO processed_stripe_events (event_id, processed_at)
VALUES ($1, NOW())
ON CONFLICT (event_id) DO NOTHING
RETURNING id;

-- Om RETURNING id IS NULL → redan processad, skippa
```

### 6.4 JWT-säkerhet

```javascript
// Centraliserad auth-middleware (ALDRIG duplicera)
// services/amos-core/middleware/auth.mjs
import jwt from 'jsonwebtoken';

export function requireAuth(req, res, next) {
  const token = req.headers.authorization?.split(' ')[1];
  if (!token) return res.status(401).json({ error: 'No token' });
  
  try {
    req.user = jwt.verify(token, process.env.JWT_SECRET, { algorithms: ['HS256'] });
    next();
  } catch (err) {
    return res.status(401).json({ error: 'Invalid token' });
  }
}
```

### 6.5 ALB Health-check-djup

```nginx
# ALB health-check mot /health/ready (djup, DB-check)
# ALDRIG mot /health (liveness) — det ger falsk trygghet
```

```javascript
// /health/ready — faktisk DB-round-trip
app.get('/health/ready', async (req, res) => {
  try {
    await db.query('SELECT 1');
    res.json({ status: 'ok', db: 'connected' });
  } catch (err) {
    res.status(503).json({ status: 'degraded', db: err.message });
  }
});
```

---

## AVSNITT 7: AGENT-KOMMUNIKATION

### 7.1 HomoDeus Mailbox

```bash
# Skicka meddelande till agent
curl -s -X POST http://localhost:3100/api/homo-deus/send \
  -H "Content-Type: application/json" \
  -d '{
    "from": "bernt",
    "to": "rufus",
    "subject": "Provider-kredit: xAI/Grok låg",
    "priority": "high",
    "body": "xAI/Grok-kontot är under 20 USD. Behöver påfyllning."
  }'

# Tillgängliga agenter
# bernt  → Erik Svensson (webchat/OpenClaw)
# sven   → Johan Berglund (CTO)
# rufus  → Winston Bjarnemark (CFO)
```

### 7.2 agent-mailbox.json

```bash
# Plats: /opt/amos/data/agent-mailbox.json
# Format: multi-agent JSON-mailbox

# Läs mailboxen
cat /opt/amos/data/agent-mailbox.json | python3 -m json.tool

# Kolla olästa meddelanden
cat /opt/amos/data/agent-mailbox.json | python3 -c "
import json, sys
data = json.load(sys.stdin)
unread = [m for m in data.get('messages', []) if not m.get('read')]
print(f'{len(unread)} olästa meddelanden')
for m in unread:
    print(f'  [{m[\"priority\"]}] {m[\"from\"]}→{m[\"to\"]}: {m[\"subject\"]}')
"
```

### 7.3 Telegram-eskalering

```bash
# P1-eskalering till Erik (via Bernt/OpenClaw)
# Chat-ID: 8783557028
# Använd OpenClaw Telegram-integration för P1-incident
```

---

## AVSNITT 8: START-CHECKLISTA (10 PUNKTER)

**Kör denna checklista VARJE gång ett workcamp startar — inga undantag.**

```
□ 1. VERIFY amos-core
      sudo systemctl status amos-core
      curl -s http://localhost:3100/api/health | python3 -m json.tool
      → Förväntat: {"status":"ok"} eller {"status":"healthy"}

□ 2. VERIFY GPU-box (om ALETHEIA ska användas)
      curl -s http://172.31.36.61:8000/health
      → Om nere: ssh -i gpu_deploy_key ubuntu@13.61.176.142
      → starta: cd aletheia_v5 && nohup vllm serve aletheia --port 8000 &

□ 3. KONTROLLERA AI-provider-krediter
      Rufus/Winston bekräftar krediter på:
      xAI/Grok, Anthropic, OpenAI, Groq, Google (Gemini), Perplexity
      → Ingen provider under 20% av normal månadsförbrukning

□ 4. KOLLA mail-triage (agent-mailbox.json)
      cat /opt/amos/data/agent-mailbox.json | python3 -m json.tool
      → Åtgärda alla CRITICAL/HIGH olästa meddelanden

□ 5. VERIFIERA EKS (om EKS-arbete planeras)
      kubectl get nodes
      kubectl get pods --all-namespaces | grep -E "(Error|CrashLoop|Pending)"
      → Alla nodes Ready, inga pods i Error/CrashLoop

□ 6. KONTROLLERA Kafka-hälsa (lärd från 8-dagars-degraderingen!)
      kubectl get pods -n kafka
      → Förväntat: kafka-0, kafka-1, kafka-2 alla Running
      → Om kafka-1 saknas: se K-010-åtgärder (resource limits på init-container)

□ 7. KOLLA MEMORY.md och senaste daglig minnesnotis
      Läs: /home/bernt/.openclaw/workspace/MEMORY.md
      Läs: /home/bernt/.openclaw/workspace/memory/YYYY-MM-DD.md (senaste)
      → Säkerställ att alla pågående beslut och blockerare är kända

□ 8. VERIFIERA AAMOS_CANON.md
      head -30 /opt/amos/data/AAMOS_CANON.md
      → Kontrollera att LandveX-def, produktdefinitioner och team är korrekta
      → Kör: curl -s http://localhost:3100/api/aamos/chat -d '{"message":"Vad gör LandveX?"}'

□ 9. KOLLA stub-rapport (dolda fel)
      curl -s http://localhost:3100/api/_stub-report | python3 -m json.tool
      → Identifiera stubs som fortfarande blockerar produktion

□ 10. BEKRÄFTA provider-monitor är aktiv
       pm2 status | grep monitor
       → provider-monitor ska vara ONLINE med status green
       → Om nere: pm2 start /opt/amos/data/ai-gateway/monitor.mjs --name provider-monitor
```

---

## AVSNITT 9: AVSLUTS-CHECKLISTA (10 PUNKTER)

**Kör denna checklista VARJE gång ett workcamp avslutas.**

```
□ 1. TERMINERA SPOT-instanser (FinOps-disciplin)
      aws ec2 terminate-instances --instance-ids i-XXXXXXXXXXXXX
      → SPECIELLT: p4d.24xlarge ($8/h spot) ska ALDRIG stå igång
      → Verifiera: aws ec2 describe-instances --query 'Reservations[].Instances[].{ID:InstanceId,State:State.Name}'

□ 2. S3-BACKUP modeller (ALETHEIA och andra)
      aws s3 sync /opt/amos/models/ s3://platform-ouroboros-models/$(date +%Y%m%d)/
      → Verifiera: aws s3 ls s3://platform-ouroboros-models/ | tail -5

□ 3. STÄNG GPU-vLLM (om ej permanent tjänst)
      ssh -i gpu_deploy_key ubuntu@13.61.176.142
      pkill -f vllm
      → Om GPU-box ska stå kvar igång: verifiera att nohup/screen är aktiv, ej en foreground-process

□ 4. SPARA SESSION-STATE i MEMORY.md
      Dokumentera: vad levererades, vad som är öppet, nästa prioritering
      Datum, beslut, rotorsaker, lärdomar
      → Minst 200 ord med konkreta siffror och datum

□ 5. UPPDATERA MEMORY.md med periodens viktigaste beslut
      Ny H2-sektion: "## WORKCAMP [DATUM] — Sammanfattning"
      Inkludera: top leveranser, öppna tickets, nästa steg

□ 6. COMMIT och PUSH workspace-filer
      cd /home/bernt/.openclaw/workspace
      git add -A && git commit -m "Workcamp EOD: [datum]"
      git push origin main

□ 7. VERIFIERA att alla secrets finns i AWS SM (ej lokalt)
      aws secretsmanager list-secrets --query 'SecretList[].Name'
      → Inga secrets i plain text i workspace-filer

□ 8. KONTROLLERA amos-core slutstatus
      sudo systemctl status amos-core
      curl -s http://localhost:3100/api/health
      → Systemet ska vara stabilt vid avslut

□ 9. LÄMNA ÖVER öppna blockerare till rätt person
      - Externa API-blockerare → Winston/Rufus (kortfrågor, konto-öppningar)
      - Tech-blockerare → Johan/Sven (Apple/MapKit, Nordea API)
      - Strategiska beslut → Erik (avvaktar ej på andra)

□ 10. DOKUMENTERA nästa workcamp-prioritering
       Skriv till: workcamp/NEXT-PRIORITIES.md
       - Top 5 prioriteringar med tydlig motivering
       - Kända blockerare och vem som äger dem
       - Infrastruktur-åtgärder som INTE är valbara (säkerhet, SLA)
```

---

## AVSNITT 10: KRITISKA FELSTEG ATT UNDVIKA

### Baserat på incidents under 11 maj – 7 juni 2026

---

### FELSTEG 1: SocialAuto utan concurrency-tak

**Vad hände (2026-06-05):**
137 parallella Chromium-instanser → 1850 tasks → 5.2GB/6.0GB RAM → OOM → allt nere.

**Hur det ser ut:**
```bash
pgrep -fc chrome  # Returnerar >10 → VARNINGSSIGNAL
cat /opt/amos/data/social-account-jobs.json | python3 -c \
  "import json,sys; d=json.load(sys.stdin); \
   counts={s:sum(1 for j in d['jobs'] if j['status']==s) for s in ['queued','running','failed']}; \
   print(counts)"
```

**Åtgärd om det händer igen:**
1. STANNA INTE amos-core utan att avbryta jobb först
2. Cancellera queued/running jobb i social-account-jobs.json
3. Verifiera `pgrep -fc chrome` < 5 innan restart
4. SOCIALAUTO_MAX_CONCURRENT=3 ska vara satt (globalt semafor)

**Förhindra:**
```javascript
// Verifiering: max 3 Chromium-instanser simultant
const SOCIALAUTO_MAX_CONCURRENT = parseInt(process.env.SOCIALAUTO_MAX_CONCURRENT) || 3;
const semaphore = new Semaphore(SOCIALAUTO_MAX_CONCURRENT);

async function runAutomation(job) {
  return semaphore.use(() => _runAutomationCore(job));
}
```

---

### FELSTEG 2: Stub ok:true döljer att subsystem är trasigt

**Vad hände (2026-06-06):**
432 stubs svarade `ok:true` på tomma svar. RAG-indexet var tomt men rapporterade framgång.
LandveX=bostad gick oupptäckt länge för att felstatus doldes.

**Rätt mönster:**
```javascript
// FEL — döljer att subsystem är trasigt
async function stubRagSearch(query) {
  return { ok: true, results: [] }; // ALDRIG!
}

// RÄTT — transparens om stub-status
async function stubRagSearch(query) {
  console.warn('[STUB] RAG search not connected, returning empty');
  return {
    ok: false,
    _stub: true,
    results: [],
    warning: 'RAG not connected'
  };
}
```

**Verifiera:**
```bash
# Kolla stub-rapport
curl -s http://localhost:3100/api/_stub-report

# Kolla response-headers för stub-indikering
curl -I http://localhost:3100/api/aamos/search?q=test | grep -i stub
```

---

### FELSTEG 3: Redigerar fel server-fil

**Vad hände (2026-06-06):**
Bernt höll på att fixa `scripts/server.mjs` istället för `services/amos-core/server.mjs`.
Körande server är ALLTID `services/amos-core/server.mjs`.

**Verifiera alltid:**
```bash
# Vilken fil kör amos-core egentligen?
sudo systemctl cat amos-core | grep ExecStart
# ELLER
ps aux | grep server.mjs
# ELLER
sudo systemctl status amos-core | grep "Main PID"
# Sedan: /proc/[PID]/cmdline
```

**Regel:**
> Kontrollera alltid med `ps aux` eller `systemctl status` vilken fil som faktiskt körs.
> Filen på disk = inte alltid filen i process.

---

### FELSTEG 4: ESM import-ordning

**Vad hände (2026-06-05):**
Stripe och APNs lästes vid ESM-import-tid (rad 11) FÖRE env-loadern (rad 34+).
Resultat: båda låstes i MOCK_MODE trots korrekta env-variabler.

**Mönster (rätt):**
```javascript
// index.mjs — env-preload ALLRA FÖRST
import './env-preload.mjs';  // Läser .env INNAN något annat importeras

// Sedan resterande imports
import Stripe from 'stripe';  // Stripe läser STRIPE_SECRET_KEY vid import
import express from 'express';
// ...
```

```javascript
// env-preload.mjs
import { config } from 'dotenv';
config({ path: '/opt/amos/.env' });
```

**Regel:** I ES Modules körs importerade moduler vid import-tid. Env-variabler som läses vid
import-tid (Stripe, APNs) måste finnas INNAN importen. Preload-modul = allra första import.

---

### FELSTEG 5: IMAP fetchMessages async-bug (förväntad men ej bekräftad)

**Potentiell bugg i mail-triage:**
IMAP-biblioteket kan returnera ett resolved promise utan att ha väntat på alla meddelanden
om `fetchMessages()` anropas utan korrekt await-kedja.

**Säkert mönster:**
```javascript
// Vänta ALLTID explicit på IMAP-stängning
async function fetchMessages(imap, box, criteria) {
  await new Promise((resolve, reject) => {
    imap.search(criteria, (err, uids) => {
      if (err) return reject(err);
      if (!uids.length) return resolve([]);
      
      const fetch = imap.fetch(uids, { bodies: '' });
      fetch.on('message', (msg) => { /* ... */ });
      fetch.on('error', reject);
      fetch.on('end', resolve);
    });
  });
}

// Stäng alltid IMAP-anslutning explicit
imap.once('ready', async () => {
  try {
    await fetchMessages(imap, 'INBOX', ['UNSEEN']);
  } finally {
    imap.end(); // ALLTID, även vid fel
  }
});
```

---

### FELSTEG 6: Köra DDP-träning på för liten instans

**Lärt av:** p4d-träningssessionen kräver 8x A100 för ~1h. A10G ensam = 8–10h för samma.

| Instans | GPUs | VRAM | Tid för ESLM v5 | Kostnad |
|---------|------|------|----------------|--------|
| A10G (gpu-box) | 1x A10G | 23GB | ~8-10h | ~$3-5 |
| p4d.24xlarge | 8x A100 | 320GB | ~1h | ~$8 SPOT |

**Beslutsregel:**
- Testträning / små experiment → A10G (gpu-box)
- Produktionsträning (full dataset, 3 epoker) → p4d SPOT
- Terminera p4d OMEDELBART efter träning (K-001: $8/h)

---

### FELSTEG 7: Inte kontrollera Kafka broker-antal

**Vad hände (2026-06-07):**
Kafka körde 2/3 brokers i 8 DAGAR utan att någon märkte det. FailedCreate x721.

**Daglig koll:**
```bash
kubectl get pods -n kafka
# Förväntat: kafka-0 Running, kafka-1 Running, kafka-2 Running
# Om kafka-1 saknas → se K-010-fix (resource limits på init-container)

# Verifiera ISR
kubectl exec -n kafka kafka-0 -- kafka-topics.sh \
  --bootstrap-server localhost:9092 \
  --describe --topic amos-events | grep -i "isr\|under-replicated"
```

---

### FELSTEG 8: Provider-krediter utan monitor

**Vad hände (2026-06-04):**
xAI/Grok tog slut mitt i orkestrering utan förvarning. Erik kallade det "generalhaveri".

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

**Winston/Rufus äger:**
- Sätta auto-topup för alla providers
- Bekräfta kredit-marginal varje morgon
- Reagera på CRITICAL-larm från provider-monitor

---

### FELSTEG 9: Använda leon/vincento-referencer i träningsdata

**Vad hände (2026-06-06):**
v3 och v4 av ESLM-träningsdata innehöll 90+129 Leon/Vincento-referencer.
Leon = simulerad persona, aldrig verklig anställd. Träningen kasserades.

**Kontrollfråga vid ny träningsdata:**
```bash
# Kontrollera att inga personas/entiteter läckt in
grep -ri "leon\|vincento\|kjell\|bjarne\|dennis" /opt/amos/data/training_data/ | wc -l
# Förväntat: 0

grep -ri "wavult\|aamos\|quixzoom\|landvex" /opt/amos/data/training_data/ | wc -l
# Förväntat: 0 (separation of weights & facts)
```

---

### FELSTEG 10: Använda /health (liveness) istället för /health/ready

**Vad hände (2026-06-05):**
host-2 hade ENOTFOUND på RDS (Tailscale DNS-bugg) men `/health` rapporterade OK.
ALB:s deep health-check mot `/health/ready` (DB-round-trip) stoppade degraderad trafik.

**Regel:** ALB-health-check ALLTID mot `/health/ready`, aldrig `/health`.
Ytlig health-check = falsk trygghet.

---

## AVSNITT 11: LÄRDOMAR DIREKT TILLÄMPBARA PÅ NÄSTA WORKCAMP

### L-001: Starta med en systemhälsoinventering — inte med features

Dag 1 av nästa workcamp: kör startchecklistan (avsnitt 8) INNAN någon feature-implementation.
Kafka-degraderingen i 8 dagar bevisar att det finns saker som är trasiga och ingen vet om det.
Inventera innan du bygger.

### L-002: En CANON-fil slår tio halvkorrekta truth-filer

Innan du skapar en ny truth-fil — kontrollera om AAMOS_CANON.md redan har den informationen.
Om CANON saknar viktig fakta → uppdatera CANON, skapa inte en ny fil.
Regel: `find /opt/amos/data -name "*truth*" -o -name "*canon*" | wc -l` ska aldrig öka.

### L-003: Parallellisering med subagenter är workcamp-superkraften

90/100 tickets på en session (2026-06-05) bevisar att parallell subagentkoordinering fungerar.
Förutsättningar för att det ska funka:
- Tydliga ticket-scope utan state-beroenden
- Varje ticket har ett konkret acceptanskriterium
- Verifiera med riktiga UUID:n, ej test-ID
- Deploy i batch, ej per ticket

### L-004: Red-team är en grind, inte ett bonus-steg

ALETHEIA v1 passerade 33% på red-team. Utan grinden hade LandveX=bostad gått live.
Nästa workcamp: röd linje vid `<80% pass rate` — ingen promotion till produktion.

### L-005: Poliskontroll-modellen ska ALLTID vara starkare än systemet den granskar

Om du sätter Qwen-32B att granska Qwen-32B output → falsk trygghet.
Qwen-32B som domare klassade "PASS" som ett EU-direktiv.
Regel: judge ≥ production model i styrka.

### L-006: Ekonomi-provisioning måste vara proaktiv, inte reaktiv

Nästa workcamp börjar med: Winston/Rufus konfigurerar auto-topup på ALLA providers.
Monitor-larm sätts vid <30% kredit (ej <5%).
Buffert = 2x förväntad månadsförbrukning per provider.

### L-007: DNS på AMI-klonade hostar kräver explicit user-data

Varje ny host skapad från AMI ska ha user-data som explicit skriver DNS:
```bash
#!/bin/bash
echo "nameserver 172.31.0.2" > /etc/resolv.conf
chattr +i /etc/resolv.conf  # Immutable — ingen process kan skriva över
```
Annars ärver den Tailscale/custom DNS från originalinstansen och kan inte resolva RDS.

### L-008: Körande server ≠ fil på disk

Verifiera ALLTID med `ps aux` eller `systemctl status` vilken fil som faktiskt körs.
Fel fil att redigera = noll effekt + förvirring.

### L-009: Jurisdiktion och multi-currency från start

Onboarding, betalning, och skatteberäkning ska vara jurisdiktionsmedvetna från dag ett.
Hårdkodning för Sverige = blocker när den spanska marknaden ska öppnas.
`country` (ISO-3166) = obligatoriskt fält i alla kontext-specifika endpoints.

### L-010: Bygg multi-AZ, idempotens och djup health-check som baseline

Dessa tre är inte lyx. De är grundkrav för att horisontell skalning ska fungera:
- Multi-AZ: RTO timmar → 60s (diff: $700/mån — värt det)
- Idempotens: webhooks, ledger-postningar, credits = matematiskt omöjligt att dubblera
- /health/ready (DB-round-trip): ALB vet om hosten faktiskt fungerar

---

## TEKNISKA REFERENSDATA (snabbreferens)

### Instans-ID:n och IP-adresser

| Namn | Instance ID | IP (publik) | IP (privat) |
|------|------------|------------|------------|
| server-2 | i-09b2204a52c2f33c9 | 16.170.83.169 | — |
| host-2 | i-0fc20ddba6bb17ead | — | 172.31.20.206 |
| gpu-box | i-04239ef03d26b218b | 13.61.176.142 | 172.31.36.61 |
| Mac Build | i-0fde74767ebfcbdd8 | 3.249.41.127 | — |

### Port-karta (server-2)

| Port | Tjänst |
|------|--------|
| 3100 | amos-core (primary API) |
| 3250 | aamos-ledger |
| 3260 | aamos-audit-engine |
| 3270 | AI-gateway (multi-provider) |
| 3304 | onboarding-service |
| 3318 | aamos-restaurant-tickets |
| 8000 | vLLM / ALETHEIA (GPU-box, 172.31.36.61) |

### Produktdefinitioner (kanoniska, inga undantag)

| Produkt | Korrekt definition |
|---------|-------------------|
| **AAMOS** | Huvudsystemet (som Microsoft). Nivåer: Gratis → Pro → Ouroboros |
| **Homo Deus** | Agentlager-TILLÄGG till AAMOS. Förtjänas genom användning. PER PROCESS. |
| **quiXzoom** | "Uber för foton". Fristående brand. Betalar avgift uppåt till AAMOS. |
| **LandveX** | Säljer infrastrukturkontroll / kontrollintelligens. INGET med bostad. |
| **ALETHEIA** | ESLM (7B, Qwen2.5-base). Generell evidensmotor för verksamhetsdrift. |
| **MNEMOSYNE** | AAMOS_CANON.md + RAG-index. Runtime-fakta. Ej inbrända i vikter. |
| **HEPHAISTOS** | Träningspipeline för ALETHEIA. |
| **AZOTH** | Orkestrering (reserverat namn). |
| **VYRA** | PAUSAD tills vidare (Erik 2026-06-06). |

---

*Volume 7 av 7 | AMOS Development Workcamp Reconstruction Package*
*Baserat på 28 dagars intensivt arbete: 11 maj – 7 juni 2026, Sugar Villas villa 2, Phuket, Thailand*
*Klassifikation: INTERN – KONFIDENTIELL*