# 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-22 03:55 CEST

### ✅ FASE 0–5 — FERDIG
### ✅ FASE 6 – CPU-optimalisering — FERDIG
### ✅ FASE 6-TILLEGG – Boot-warming — FERDIG
### ✅ DNS – NS-bytte utført — FERDIG 2026-07-21 23:44 CEST
### ✅ OPAX-MCP – GITEA_URL permanent + deploy — FERDIG 2026-07-21 23:53 CEST
### ✅ SMOKE-TEST – Alle 37 tools — FERDIG 2026-07-22 00:25 CEST
### ✅ FASE 6.5 – VM-oppgradering + modellarkitektur — VERIFISERT 2026-07-22
### 🟡 FASE 7 – 14B-validering utført, arkitektur justeres — PÅGÅR
### ⏳ GPG-SIGNERING – Commits verified — PÅGÅR
### ⏳ FASE 8 – Backup / snapshot-strategi — PLANLAGT

---

## FASE 6.5 — OPPDATERT LOKAL LLM-STACK (2026-07-22)

### Bekreftet drift
- `gitea-cpu-vm` er oppe i `us-central1-b`
- VM kjører nå på `e2-highmem-4` (4 vCPU / 32 GB RAM)
- Statisk IP beholdt: `34.170.51.84`
- Gitea svarer på port `3000`
- Ollama svarer på port `11434`

### Bekreftet ressursstatus
- Disk: ca. 99 GB total
- Ny modellstack etter 14B-nedlasting: ca. 29 GB modeller totalt
- Systemet har fortsatt god diskmargin, men CPU er nå den reelle begrensningen

### Faktisk modeller lokalt per 2026-07-22
- `gemma3:4b`
- `gemma3:12b`
- `qwen2.5:3b`
- `qwen2.5:14b`
- `qwen2.5-coder:14b`

### Verifisert ytelsesfunn
- `gemma3:4b` holder ca. `4.9–5.0 tok/s` varm og fungerer interaktivt
- `qwen2.5:14b` målte ca. `1.4 tok/s` varm på faktisk VM
- Kort prompt ga ca. `249s` eval-duration på varm modell ved `stream: false`
- Konklusjon: `qwen2.5:14b` er for treg som standard interaktiv agent på nåværende CPU-VM

### Revidert anbefalt modellarkitektur
- **Frontmodell:** `gemma3:4b`
  - Brukes for raske svar, enkel resonnering og billig default
- **Lett tool-/agentmodell:** `qwen2.5:3b`
  - Brukes for tool calling som må være responsivt nok i praksis
- **Neste kandidat for mellomlag:** `qwen2.5:7b`
  - Skal testes som mulig erstatning for `qwen2.5:14b` som standard Qwen-lag
- **Kode-/repo batch-modell:** `qwen2.5-coder:14b`
  - Beholdes for repo-forståelse, patching, refaktorering og tyngre asynkrone kodeoppgaver
- **Ikke anbefalt nå:** `qwen2.5:14b` som interaktiv standardmodell
  - For treg på CPU til primær bruk
- **Ikke anbefalt nå:** `gemma3:27b`
  - Uaktuell før videre CPU-/ytelsesløft; forventes tregere enn 14B-laget

### Operativ ruting
1. Start med `gemma3:4b`
2. Eskaler til `qwen2.5:3b` når oppgaven trenger tools og respons fortsatt må være praktisk
3. Bruk `qwen2.5-coder:14b` kun når oppgaven er tydelig kode-/repo-orientert og kan tåle høy latency
4. Test `qwen2.5:7b` som mulig nytt mellomlag før eventuell fjerning av `qwen2.5:14b`
5. Ikke last ned `gemma3:27b` nå

### Viktige vurderinger
- CPU, ikke RAM eller disk, er nå flaskehalsen
- `qwen2.5:14b` ga svak praktisk interaktiv ytelse til tross for vellykket installasjon
- `qwen2.5-coder:14b` beholdes foreløpig fordi use casen er batch/dev-assistanse, ikke chat-latency
- `qwen2.5:7b` er neste rasjonelle kandidat for bedre balanse mellom kvalitet og fart
- `qwen2.5-coder:32b` og `gemma3:27b` utsettes

### Neste konkrete steg
- Test / vurder:
  - `ollama rm qwen2.5:14b`
  - `ollama pull qwen2.5:7b`
- Test deretter:
  - enkel chat-latency
  - tool calling
  - RAM- og diskpåvirkning
  - om `qwen2.5:7b` kan overta rollen som standard Qwen-lag

```bash
# Foreslått neste endring
ollama rm qwen2.5:14b
ollama pull qwen2.5:7b

# Bekreft etterpå
curl http://localhost:11434/api/tags
free -h
du -sh /usr/share/ollama/.ollama/models
```

---

## LÅST SYSTEMKONFIGURASJON – GITEA-CPU-VM (komplett)

### VM-spesifikasjon (oppdatert 2026-07-22)
- **Maskintype:** `e2-highmem-4` (4 vCPU / 32 GB RAM)
- **Zone:** `us-central1-b`
- **Statisk IP:** `34.170.51.84`

### Systemd-dropins
```
override.conf    — OLLAMA_HOST=0.0.0.0:11434
max-models.conf  — MAX_LOADED_MODELS=2 + KEEP_ALIVE=-1
warmup.conf      — ExecStartPost=/usr/local/bin/ollama-warmup.sh
```

### Operative parametere for Emma-kall
```
num_ctx            = 2048
num_batch          = 256
OLLAMA_NUM_THREADS = ikke satt (autodetect)
```

### Ytelsesbudsjett per Emma-turn (varm)
```
3-kall turn:   ~23.5s
5-kall turn:   ~42.5s
Boot-penalty:  ~0s (warmup-skript)
Tok/s:         4.9–5.0 (gemma3:4b)
```

### Gitea-dataplassering
```
/opt/gitea/data/repositories/chris/OSVauco.git/   ← Bare repo
/opt/gitea/data/gitea.db                          ← SQLite metadata
/opt/gitea/data/custom/conf/app.ini               ← Konfig
```

---

## OPAX-MCP KONFIGURASJON – LÅST

| Variabel | Verdi |
|---|---|
| `GITEA_URL` | `http://34.67.252.59:3000` |
| `OLLAMA_BASE_URL` | `http://34.67.252.59:11434` |
| `EMMA_MODEL` | `gemma3:4b` |
| `EMMA_FAST_MODEL` | `gemma3:4b` |
| `EMMA_LIGHT_MODEL` | `qwen2.5:3b` |
| `OSVAUCO_AGENT_URL` | `https://osvauco-agent-357036551735.us-central1.run.app` |

Deploy verifisert: `get_connector_status` → `live`, `gitea: online`, `tool_count: 37`

---

## DNS – FULLFØRT 2026-07-21

NS-bytte: Proisp → Google Cloud DNS **23:44 CEST**

| Record | Type | Verdi |
|---|---|---|
| `vauco.no.` | A | `34.98.77.173` (LB) |
| `www.vauco.no.` | A | `34.98.77.173` (LB) |
| `opax.vauco.no.` | A | `34.98.77.173` (LB) |
| `git.vauco.no.` | A | `34.67.252.59` |
| MX / SPF / DKIM / DMARC | TXT/MX | Google Workspace komplett |

---

## SMOKE-TEST – FULLFØRT 2026-07-22 00:25 CEST

| Kategori | Status | Merknad |
|---|---|---|
| ✅ Ollama / Emma | Grønn | gemma3:4b varm, 14s respons |
| ✅ Connector | Grønn | live, 37 tools |
| ✅ Gitea read + write | Grønn | Commits og push OK |
| ✅ GCP / Cloud Run | Grønn | osvauco-agent Ready, rev 00695 |
| ✅ Workspace / Gmail | Grønn | 3 brukere, kalender, e-post OK |
| ✅ Terminal / Billing | Grønn | Billing dramatisk ned fra 5. juli |
| 🟡 Jason | Grønn m/merknad | Kjører gemini-2.5-flash (ikke Pro) |

### Smoke-test observasjoner
- `qwen2.5:3b` har tool-calling capabilities — `gemma3:4b` har det ikke
- GCE `list_instances` tom — ikke kritisk, Cloud Console på mobil
- Jason `mode`-parameter gir 400 — bruk kun `prompt`
- GPG-signering pågår — commits fortsatt unverified

---

## FASE 7 – LOKAL HJERNE / DERIVAT-MODELL (pågår)

### Mål
Erstatte stor API-modell (Gemini/Claude/Perplexity) med lokal modell som hjerne i OPAX-arkitekturen. Redusere API-avhengighet på sikt.

### Arkitektur (nå vs mål)
```
NÅ:
Perplexity/Gemini  ←  Hjerne (stor API-modell)
       ↓ tool calls
   OPAX-MCP
       ↓
Emma gemma3:4b    ←  Lokal inferens (svak)

MÅL:
Lokal stor modell  ←  Hjerne (lokal, gratis)
       ↓ tool calls
   OPAX-MCP
       ↓
Emma gemma3:4b    ←  Lokal inferens (rask)
```

### Kandidatmodeller for e2-highmem-4 (32 GB RAM) — oppdatert 2026-07-22 03:55

| Modell | RAM | Tok/s CPU | Agentevne | Vurdering |
|---|---|---|---|---|
| `gemma3:4b` (nå) | 2.9 GB | ~5 | Svak | Front/hurtig default |
| `qwen2.5:3b` | ~2.0–2.5 GB | ~3–4 | God | **Beste raske tool-kandidat nå** |
| `gemma3:12b` | ~8 GB | ~1.5–2 | God | Allsidig, men ikke tool-modell |
| `qwen2.5:7b` | ~5.5–6 GB | forventet ~2.5–3 | God | **Neste kandidat som mellomlag** |
| `qwen2.5:14b` | ~9 GB | målt ~1.4 | Sterk | **For treg som interaktiv agent** |
| `qwen2.5-coder:14b` | ~9 GB | forventet ~1.4 | Kode-sterk | Batch / async kodebruk |
| `gemma3:27b` | ~17 GB | forventet <1 | Tilnærmet god | Ikke aktuell nå |
| `qwen2.5-coder:32b` | ~20 GB | <1 | Svært sterk | Utsatt — for tung |

### Validerte funn
- `qwen2.5:14b` installert og verifisert
- Varm enkel chat-test ga ca. `249.3s` eval-duration og `1.4 tok/s`
- Resultatet vurderes som for tregt for interaktiv standardbruk
- Dette flytter `qwen2.5:14b` fra planlagt standardmodell til mulig batch-/asynkronmodell
- `qwen2.5:7b` er neste kandidat som må testes før modellstack fryses

### Exit-kriterier Fase 7
- [x] `qwen2.5:14b` installert og testet
- [ ] `qwen2.5:7b` installert og testet
- [ ] Beslutning tatt: fjern eller behold `qwen2.5:14b`
- [ ] `qwen2.5-coder:14b` testet på konkret kode-/repo-oppgave
- [ ] Ytelsesmåling: RAM-bruk, swap=0
- [ ] Endelig ruting besluttet for fast / light / coder / batch
- [ ] GEMINI.md-lignende systemd-prompt/konfig for Emma laget

### Derivat-strategi
Emma skal få eget identitetsdokument (tilsvarende GEMINI.md for Jason) med:
- Personlighet og tone
- Arbeidsregler og prioriteringer
- Tool-bruksprinsipper
- Vauco OS-kontekst

---

## FASE 8 – BACKUP / SNAPSHOT-STRATEGI (planlagt)

### Mål
Sikre at Gitea-CPU-VM (`34.67.252.59`) aldri er single point of failure for source of truth.

### Strategi: Daglig GCP Disk Snapshot

```
Kilde:    Gitea-CPU-VM persistent disk
Frekvens: Daglig (02:00 CEST)
Bevaring: 7 snapshots (rullerende — siste 7 dager)
Kostnad:  ~$0.026/GB/mnd — 50 GB disk = ~$1.30/mnd
```

### Implementasjon

```bash
# Opprett snapshot-policy
gcloud compute resource-policies create snapshot-schedule gitea-daily-backup \
  --region=us-central1 \
  --max-retention-days=7 \
  --on-source-disk-delete=keep-auto-snapshots \
  --daily-schedule \
  --start-time=00:00 \
  --storage-location=us-central1

# Koble policy til disk
gcloud compute disks add-resource-policies gitea-cpu-vm \
  --resource-policies=gitea-daily-backup \
  --zone=us-central1-b
```

### Hva snapshots dekker
- ✅ `/opt/gitea/data/repositories/` — alle git-objekter
- ✅ `/opt/gitea/data/gitea.db` — brukere, tokens, metadata
- ✅ `/opt/gitea/data/custom/conf/app.ini` — konfig
- ✅ Ollama-modeller (`/usr/share/ollama/`)
- ✅ Systemd-dropins og warmup-skript

### Restore-prosedyre (ved VM-tap)
```bash
# 1. Opprett ny disk fra snapshot
gcloud compute disks create gitea-restore \
  --source-snapshot=<snapshot-name> \
  --zone=us-central1-b

# 2. Koble til ny VM eller eksisterende
# 3. Gitea starter automatisk — alt er intakt
```

### Exit-kriterier Fase 8
- [ ] Snapshot-policy opprettet og koblet til disk
- [ ] Første snapshot verifisert i GCP Console
- [ ] Restore-prosedyre testet (restore til tmp-disk)
- [ ] Kostnad bekreftet (~$1.30/mnd)

---

## ÅPNE PUNKTER
1. GPG-signering — få commits verified (pågår)
2. `git.vauco.no` — verifiser propagering
3. Test `qwen2.5:7b` som nytt mellomlag
4. Beslutt om `qwen2.5:14b` skal fjernes etter 7B-test
5. Test `qwen2.5-coder:14b` på konkret kode-/repo-oppgave
6. Mål RAM/swap under modell-last
7. Emma derivat-dokument (tilsvarende GEMINI.md)
8. Fase 8: Snapshot-policy aktiveres
9. Gitea passord byttes (eksponert i chat)

## FASTE SANNHETER
- Gitea er source of truth
- Lokale modeller er hovedretning — mål er å fase ut API-avhengighet
- Gitea-VM (34.67.252.59) er permanent målmaskin
- Dev-snap (34.170.51.84) er Jason sin arbeidsstasjon — kan ikke stenges før lokal hjerne er verifisert
- Denne handoffen overstyrer alt annet
- CPU er nå primær flaskehals for tyngre lokale modeller på denne VM-en

## 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 — GITEA_URL permanent + deployed
- ✅ Boot-warming verifisert
- ✅ DNS migrert til Google Cloud DNS
- ✅ Smoke-test alle 37 tools — FERDIG
- ✅ VM oppgradert til e2-highmem-4 (32 GB RAM) — FERDIG
- ✅ `qwen2.5:14b` installert og ytelsestestet — FERDIG
- ⏳ `git.vauco.no` live — propagering pågår
- ⏳ GPG-signering verified — pågår
- ⏳ `qwen2.5:7b` testet og vurdert — planlagt
- ⏳ Endelig mellomlag valgt (`qwen2.5:7b` vs behold `qwen2.5:14b`) — planlagt
- ⏳ `qwen2.5-coder:14b` verifisert i konkret kodeflyt — planlagt
- ⏳ Fase 7: lokal hjerne verifisert — pågår
- ⏳ Fase 8: daglig snapshot-backup — planlagt

## OPPDATERINGSLOGG
| Dato | Handling |
|---|---|
| 2026-07-21 | FASE 4–6: CPU-optimalisering, boot-warming fullført |
| 2026-07-21 23:44 | DNS: NS-bytte utført hos Proisp |
| 2026-07-21 23:53 | OPAX-MCP: GITEA_URL + OLLAMA_BASE_URL → 34.67.252.59, deployed |
| 2026-07-22 00:05 | Smoke-test plan klar, Fase 7 (lokal hjerne) lagt inn |
| 2026-07-22 00:25 | Smoke-test fullført — alle kategorier grønne |
| 2026-07-22 00:55 | Fase 8 (backup/snapshot) lagt inn, GPG-signering pågår |
| 2026-07-22 03:29 | FASE 6.5 lagt inn: e2-highmem-4 verifisert, ny modellarkitektur (Gemma4b → Qwen14b → Qwen-coder-14b → Gemma27b), neste steg: pull qwen2.5:14b + qwen2.5-coder:14b |
| 2026-07-22 03:55 | Handoff oppdatert etter 14B-validering: qwen2.5:14b målt til ~1.4 tok/s varm og vurdert for treg som interaktiv standardmodell; qwen2.5:7b satt som neste kandidat; gemma3:27b og coder32b utsatt |