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

# HANDOFF-LOKAL-LLM-GITEA-MCP.md
# EGEN HANDOFF – UFRAVIKELIG STYRINGSDOKUMENT
# GJELDER FRA NÅ OG FREM TIL 100 % FERDIGSTILLELSE

## 0. STATUS OG KOMMANDO
Denne handoffen er det eneste autoritative arbeidsdokumentet for sporet "lokal LLM-fabrikk + OPAX-MCP + Gitea stabilisering + blueprinting til Gitea-VM".

---

## FREMDRIFT – OPPDATERT 2026-07-21 22:22 CEST

### ✅ FASE 0 – Lås situasjonen — FERDIG
- Handoff opprettet som eget dokument
- dev-snap/GPU-VM er aktiv verifikasjonsbase
- Gitea er eneste source of truth
- Lokal LLM-bane er primær retning

### ✅ FASE 1 – Lokale modeller lever — FERDIG
- Ollama kjører på Gitea-CPU-VM (34.67.252.59:11434)
- Modeller tilgjengelig via MCP: `gemma3:4b`, `qwen2.5:3b`
- Modeller på dev-snap localhost: `qwen2.5:7b`, `gemma3:4b`, `llama3.2`, `nomic-embed-text`
- `list_emma_models` via MCP: GRØNN ✅

### ✅ FASE 2 – MCP peker korrekt til lokal modellsti — FERDIG
- `OLLAMA_BASE_URL` peker til Gitea-CPU-VM Ollama
- `OSVAUCO_AGENT_URL` fikset til kanonisk URL (commit a171a58)
  - Rotårsak: Cloud Run krever regional URL som audience for identity tokens
  - Feil: `zjbqp3prqq-uc.a.run.app` → Riktig: `osvauco-agent-357036551735.us-central1.run.app`
- 5 filer oppdatert av Gemini-agent, build SUCCESS 55182237 (21. juli 18:38)
- opax-mcp revisjon: opax-mcp-00122-m4n

### ✅ FASE 3 – Gitea read-only grønn — FERDIG
- Rotårsak: `GITEA_URL` var ikke satt i opax-mcp Cloud Run service
- Gitea kjører på: `http://34.67.252.59:3000` (Gitea-CPU-VM)
- Fix: `gcloud run services update opax-mcp --update-env-vars GITEA_URL=http://34.67.252.59:3000`
- opax-mcp revisjon etter fix: opax-mcp-00123-g7d
- Alle 4 read-only tools GRØNNE:
  - ✅ `list_commits`
  - ✅ `get_file`
  - ✅ `get_file_content`
  - ✅ `list_repo_files`
- `get_connector_status`: `gitea_status: online` ✅

### ✅ FASE 4 – Hel kjede samtidig grønn — FERDIG 2026-07-21 20:57 CEST
Full smoke test kjørt og alle tools grønne samtidig:

| Tool | Status | Resultat |
|---|---|---|
| `get_connector_status` | ✅ | live, gitea online, 37 tools |
| `get_health` | ✅ | OK |
| `get_build_status` | ✅ | Siste build SUCCESS 55182237 |
| `describe_service` | ✅ | osvauco-agent-00695-8lk Ready |
| `list_workspace_users` | ✅ | 3 brukere returnert |
| `list_emma_models` | ✅ | gemma3:4b, qwen2.5:3b |
| `list_commits` | ✅ | Siste commits returnert |
| `list_repo_files` | ✅ | Rotmappe listert |

Ingen regresjon på tidligere grønne tools. Hele kjeden er verifisert i samme runde.

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

### ⏳ FASE 6 – CPU-optimalisering før permanent migrering — PÅGÅR
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 utføres direkte på gitea-cpu-vm (ikke dev-snap, da `num_gpu 0` ignoreres av Ollama der)
- alle resultater føres tilbake i OPPDATERINGSLOGG samme dag

Testrekkefølge:
1. ✅ Kaldstart / keep_alive baseline — FERDIG 2026-07-21
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

---

## FASE 6.1 – KALDSTART / KEEP_ALIVE BASELINE — RESULTATER 2026-07-21

Kjørt på: **gitea-cpu-vm** (34.67.252.59) — ekte CPU, ingen GPU
Merk: dev-snap ignorerer `num_gpu 0` i options-feltet — GPU brukes uansett der. Alle tester kjørt direkte på gitea-cpu-vm.

### Kaldstart-målinger

| Test | Modell | load_s | eval_s | tok/s | Processor | Status |
|---|---|---|---|---|---|---|
| 1.1 Ekte kaldstart | gemma3:4b | **117.69s** | 1.02s | 4.9 | 100% CPU | ✅ PASS |
| 1.2 Ekte kaldstart | qwen2.5:3b | **71.13s** | 1.73s | 6.4 | 100% CPU | ✅ PASS |
| 1.3 keep_alive=-1 load | gemma3:4b | 76.93s (kald→varm) | — | 5.9 | 100% CPU | ✅ PASS |

### keep_alive=-1 verifikasjon

| Test | Resultat | Status |
|---|---|---|
| 1.4 UNTIL=Forever | gemma3:4b: **Forever** ✅ / qwen2.5:3b: ~2 min ⚠️ (ikke satt keep_alive=-1) | ✅ PASS |
| 1.5 Varme kall ×5 | load_s: 0.984–1.048s (ikke 0, men ikke 117s) | ✅ PASS |

### RAM-tilstand etter Fase 1

```
               total        used        free      shared  buff/cache   available
Mem:            15Gi       6.8Gi       3.8Gi       492Ki       5.3Gi       8.8Gi
Swap:             0B          0B          0B

NAME          SIZE      PROCESSOR    UNTIL
gemma3:4b     2.9 GB    100% CPU     Forever
qwen2.5:3b    2.2 GB    100% CPU     ~1 min (utløper)
```

**RAM med 2 modeller lastet:** 6.8 GB used / 8.8 GB available — god margin, ingen swap ✅

### Konklusjoner Fase 6.1

1. **Kaldstart-range bekreftet:** gemma3:4b = 117s, qwen2.5:3b = 71s (verre enn antatt 48–79s for gemma3)
2. **`OLLAMA_KEEP_ALIVE=-1` er bevist nødvendig og effektiv** — eliminerer 117s kaldstart fra kall 2+
3. **Varme kall koster ~1s load + ~0.9s eval = ~2s per kall** — 4–6 kall per Emma-turn = 8–12s ren LLM-tid
4. **keep_alive=-1 må settes eksplisitt per kall per modell** — arves ikke automatisk
5. **`num_gpu 0` i options ignoreres på dev-snap** — fremtidige CPU-tester kjøres direkte på gitea-cpu-vm
6. **RAM-margin er god med 2 modeller:** 5.1 GB (2.9+2.2) i Ollama + 8.8 GB available — ingen OOM-risiko ved normal last

---

## ÅPNE PUNKTER SOM MÅ LØSES FØR BLUEPRINT
- `GITEA_URL` satt runtime via `gcloud run services update` — **må også legges permanent inn i `opax-mcp.yaml` i repo og rebuildes**
- `git.vauco.no` er planlagt som permanent domene for Gitea (ref: docs/DNS-OG-INFRASTRUKTUR.md) — erstatter IP når DNS er oppe
- Gitea-commits er ikke GPG-signert — vurder om dette skal fikses

## FASTE SANNHETER (uendret)
- Gitea er source of truth
- Lokale modeller er hovedretning
- dev-snap/GPU-VM er nåværende verifikasjonsflate
- Gitea-VM (34.67.252.59) er planlagt permanent målmaskin
- Denne handoffen overstyrer alt annet

## DEFINITION OF DONE
- ✅ Lokale modeller lever og kan brukes lokalt
- ✅ OPAX-MCP bruker lokal modellbackend korrekt
- ✅ `list_emma_models` er grønn
- ✅ Gitea read-only tools er grønne
- ✅ 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 FERDIG
- ⏳ CPU-optimalisering verifisert på Gitea-VM — FASE 6 pågår

## 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 |
| 2026-07-21 | FASE 6.1 | Kaldstart/keep_alive baseline fullført: gemma3:4b=117s, qwen2.5:3b=71s, varme kall ~1s, keep_alive=-1 bevist effektiv, RAM OK |