- 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
34 KiB
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):
- Systemhälsa —
sudo systemctl status amos-core+pgrep -fc chrome+ RAM-koll - Öppna incidents — Har något gått ned under natten?
- AI-provider krediter — Winston/Rufus bekräftar att alla providers har marginal
- Dagens priorities — Vad producerar mest värde idag? (Erik beslutar)
- Blockerare — Vad behöver lösas INNAN produktion kan starta?
- 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: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:
- Vad levererades idag? (lista konkret)
- Vad blockerade? (ärlig analys)
- Öppna incidents? (eskalering om nödvändigt)
- Morgondagens prioritering (Erik beslutar)
- Uppdatera MEMORY.md med dagens beslut
- Kolla provider-krediter inför natten
- 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:
⚠️ ALDRIGhå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årbarhetjwt.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 → Groqsearch: Perplexity sonar-pro → Geminidefault: 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):
- 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ärdei 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 (
unsetAWS_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:
- STANNA INTE amos-core utan att avbryta jobb först
- Cancellera queued/running jobb i social-account-jobs.json
- Verifiera
pgrep -fc chrome< 5 innan restart - 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 auxellersystemctl statusvilken 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 = 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:
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