Files
boc/workcamp/VOL7-AMOS-Operating-System.md
T
Bernt bae705aa97 ARCHITECTURE: NFC roadmap, edge AI, audit logging
- Add NFC ePassport roadmap (ICAO 9303, eIDAS)
- Add TensorFlow.js edge face detection (BlazeFace)
- Add structured audit logger (GDPR-compliant)
- Risk scoring support

Part of KYC Apple Native UX v1.1.0
2026-06-29 16:24:48 +00:00

34 KiB
Raw Blame History

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:0012:00 — Production Block A (tunga arkitekturbeslut, infrastruktur, strategi)
12:0013:00 — Middag + paus
13:0019:00 — Production Block B (tickets, parallella subagenter, implementation)
19:0019: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älsasudo 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:

# 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:0012: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:0013: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:0019: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 48 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:0019: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.).

# 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):

# 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
// 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:

# 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).

# 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
# 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

# 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):

# 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:

# 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

# 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)

# 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:

# 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:

-- 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

// 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

# ALB health-check mot /health/ready (djup, DB-check)
# ALDRIG mot /health (liveness) — det ger falsk trygghet
// /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

# 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

# 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

# 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:

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:

// 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:

// 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:

# 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:

# 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):

// 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';
// ...
// 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:

// 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 = 810h 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:

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:

# 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:

#!/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