chore: update docs/HANDOFF-LOCAL-LLM-GITEA-MCP.md via opax-mcp

docs/HANDOFF-LOCAL-LLM-GITEA-MCP.md

@@ -7,7 +7,7 @@ Denne handoffen er det eneste autoritative arbeidsdokumentet for sporet "lokal L
 
 ---
 
-## FREMDRIFT – OPPDATERT 2026-07-21 20:57 CEST
+## FREMDRIFT – OPPDATERT 2026-07-21 21:57 CEST
 
 ### ✅ FASE 0 – Lås situasjonen — FERDIG
 - Handoff opprettet som eget dokument
@@ -57,17 +57,38 @@ Full smoke test kjørt og alle tools grønne samtidig:
 
 Ingen regresjon på tidligere grønne tools. Hele kjeden er verifisert i samme runde.
 
-### ⏳ FASE 5 – Frys blueprint på dev-snap — NESTE
-Formål: Gjøre det fungerende oppsettet om til en presis og flyttbar mal for Gitea-VM.
+### ✅ FASE 5 – Frys blueprint på dev-snap — FERDIG
+- Blueprint dokumentert i `docs/BLUEPRINT-DEV-SNAP.md`
+- Full env-var, modell- og serviceoversikt frosset
+- Avklart at nåværende `OLLAMA_BASE_URL` og `GITEA_URL` i praksis har pekt mot dev-snap i aktiv verifikasjonsperiode
+- Gitea-CPU-VM står fast som permanent målmaskin
 
-Skal dokumenteres:
-- Alle env vars og secrets i opax-mcp Cloud Run
-- Alle modellnavn og roller (Emma, Emma Fast, Light)
-- OLLAMA_BASE_URL og hvilken VM Ollama faktisk kjører på
-- GITEA_URL — midlertidig IP vs planlagt git.vauco.no
-- Alle Cloud Run services og revisjoner
-- Testkommandoer for rask verifisering
-- Hva som må være identisk på Gitea-VM vs hva som er maskinspesifikt
+### ⏳ FASE 6 – CPU-optimalisering før permanent migrering — NESTE
+Formål: Verifisere at Emma-arkitekturen fungerer akseptabelt på Gitea-CPU-VM før permanent cutover fra dev-snap.
+
+Bakgrunn:
+Research og testprotokoll viser at problemet ikke bare er VM-spesifikasjoner, men Emma-loopen selv. Emma MCoT gjør typisk 4–6 sekvensielle LLM-kall per brukerturn (embed → think → choose_action → execute_action, evt. compress). På gitea-cpu-vm er kaldstart målt til ca. 48–79 sekunder per modell, noe som gjør resident modellstrategi og keep_alive kritisk.
+
+Bekreftede regler:
+- `OLLAMA_KEEP_ALIVE=-1` er obligatorisk baseline
+- resident modellstrategi må avklares eksplisitt (1 varm modell vs 2 varme modeller)
+- `qwen2.5:7b` er ikke baseline-kandidat på gitea-cpu-vm
+- CPU-optimalisering skal skje på dev-snap først (simulert CPU / `num_gpu 0`), deretter verifiseres på gitea-cpu-vm
+- alle resultater føres tilbake i OPPDATERINGSLOGG samme dag
+
+Testrekkefølge:
+1. Kaldstart / keep_alive baseline
+2. Resident modell-strategi (1 vs 2 modeller)
+3. Parameter-matrise (`num_ctx`, `num_batch`, `OLLAMA_NUM_THREADS`)
+4. Full Emma MCoT end-to-end
+5. Belastningstest med samtidig Gitea + agent-last
+
+Exit-kriterium:
+- keep_alive-strategi bevist effektiv
+- resident modellvalg låst
+- optimal parameterkombinasjon dokumentert
+- full Emma-loop latency akseptert
+- 2-timers belastningstest bestått uten OOM og uten swap
 
 ---
 
@@ -91,4 +112,12 @@ Skal dokumenteres:
 - ✅ GCP/Workspace-kjernen er fortsatt grønn
 - ⚠️ Konfigurasjon konsolidert — delvis (GITEA_URL må inn i repo)
 - ⏳ Ingen skjult API-/agentavhengighet som hovedbane — ikke verifisert
-- ⏳ dev-snap-oppsettet dokumentert godt nok til blueprinting — FASE 5
+- ✅ dev-snap-oppsettet dokumentert godt nok til blueprinting — FASE 5 FERDIG
+- ⏳ CPU-optimalisering verifisert på Gitea-VM — FASE 6
+
+## OPPDATERINGSLOGG
+| Dato | Fase | Handling |
+|---|---|---|
+| 2026-07-21 | FASE 4 | Full smoke test grønn, alle 8 tools OK |
+| 2026-07-21 | FASE 5 | Blueprint frosset, FASE 5 lukket |
+| 2026-07-21 | FASE 6 | FASE 6 åpnet — CPU-optimalisering neste |