From 220f418f4c8ff431828814eaa00971b700532f9b Mon Sep 17 00:00:00 2001 From: chris Date: Thu, 23 Jul 2026 20:15:15 +0000 Subject: [PATCH] chore: update docs/HANDOFF-LOCAL-LLM-GITEA-MCP.md via opax-mcp --- docs/HANDOFF-LOCAL-LLM-GITEA-MCP.md | 376 ++++++++-------------------- 1 file changed, 111 insertions(+), 265 deletions(-) diff --git a/docs/HANDOFF-LOCAL-LLM-GITEA-MCP.md b/docs/HANDOFF-LOCAL-LLM-GITEA-MCP.md index 48e455a..2f3bd52 100644 --- a/docs/HANDOFF-LOCAL-LLM-GITEA-MCP.md +++ b/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-22 03:55 CEST +## FREMDRIFT – OPPDATERT 2026-07-23 22:14 CEST ### ✅ FASE 0–5 — FERDIG ### ✅ FASE 6 – CPU-optimalisering — FERDIG @@ -16,12 +16,92 @@ Denne handoffen er det eneste autoritative arbeidsdokumentet for sporet "lokal L ### ✅ 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 +### ✅ DEV-SNAP UAVHENGIGHET – Verifisert 2026-07-22 19:30 CEST +### ✅ OSVauco arbeidskopi klonet til Gitea-VM — FERDIG 2026-07-22 19:25 CEST ### 🟡 FASE 7 – 14B-validering utført, arkitektur justeres — PÅGÅR +### ⏳ git.vauco.no HTTPS — PÅBEGYNT, blokkert av firewall ### ⏳ GPG-SIGNERING – Commits verified — PÅGÅR ### ⏳ FASE 8 – Backup / snapshot-strategi — PLANLAGT --- +## DEV-SNAP UAVHENGIGHET – VERIFISERT 2026-07-22 + +Alle 6 tester grønne: + +| Test | Status | Bevis | +|------|--------|-------| +| A — Gitea API | ✅ | list_commits svarer fra localhost:3000 | +| B — Repo-innhold | ✅ | Klon hentet 3545 objekter direkte | +| C — OPAX health | ✅ | opax_mcp_status: live | +| D — MCP tools/list | ✅ | 37 verktøy live | +| E — Git-sync | ✅ | nothing to commit, working tree clean | +| F — Ollama | ✅ | 5 modeller bekreftet | + +**Viktig:** Bruk alltid `localhost:3000` (ikke `34.67.252.59:3000`) når du jobber fra Gitea-VM selv. GCP NAT-er ikke loopback-trafikk. + +--- + +## git.vauco.no – STATUS OG NESTE STEG + +### Hva er gjort +- ✅ DNS: `git.vauco.no` A-record → `34.67.252.59` satt i Google Cloud DNS +- ✅ nginx installert og kjører på Gitea-VM (port 80 lytter) +- ✅ nginx konfig for `git.vauco.no` → proxy til `localhost:3000` opprettet +- ✅ Firewall-regel `allow-http-https` opprettet i `propane-will-491900-m5` +- ❌ certbot feiler — port 80 ikke nåbar eksternt (timeout) + +### Rotårsak +Firewall-regelen `allow-http-https` (prioritet 1000) blokkeres sannsynligvis av en annen regel med høyere prioritet. VM-taggen er `gitea-server`. + +### Neste steg når du er hjemme + +**Steg 1 — GCP Console eller Cloud Shell:** +Finn blokkerende regel: +```bash +gcloud compute firewall-rules list \ + --project=propane-will-491900-m5 \ + --format="table(name,direction,priority,allowed,denied,targetTags,disabled)" +``` + +**Steg 2 — Lag ny regel med prioritet 500:** +```bash +gcloud compute firewall-rules create allow-gitea-web \ + --project=propane-will-491900-m5 \ + --allow tcp:80,tcp:443 \ + --direction INGRESS \ + --priority=500 \ + --target-tags=gitea-server \ + --network=default \ + --source-ranges=0.0.0.0/0 +``` + +**Steg 3 — Gitea-VM: kjør certbot på nytt:** +```bash +sudo certbot --nginx -d git.vauco.no \ + --non-interactive --agree-tos \ + -m chris.christiansen@vauco.no +``` + +**Steg 4 — Verifiser:** +```bash +curl -s https://git.vauco.no/api/v1/version +``` + +**Steg 5 — Google OAuth2 i Gitea:** +- console.cloud.google.com → Credentials → OAuth 2.0 Client ID +- Redirect URI: `https://git.vauco.no/user/oauth2/google/callback` +- Legg til i Gitea: Site Administration → Authentication Sources → Add → OAuth2 → Google + +--- + +## SIKKERHET – ÅPNE PUNKTER +⚠️ GITEA_TOKEN eksponert i chat: `278c0b41df7dc4e8c99d6c479a8603105e56a0a9` +- Roter token i Gitea (localhost:3000 → Settings → Applications) +- Oppdater GITEA_TOKEN i Cloud Run miljøvariabler etter rotasjon + +--- + ## FASE 6.5 — OPPDATERT LOKAL LLM-STACK (2026-07-22) ### Bekreftet drift @@ -31,110 +111,19 @@ Denne handoffen er det eneste autoritative arbeidsdokumentet for sporet "lokal L - 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 +### Faktisk modeller lokalt per 2026-07-23 - `gemma3:4b` -- `gemma3:12b` - `qwen2.5:3b` -- `qwen2.5:14b` +- `qwen2.5:7b` +- `qwen2.5-coder:7b` - `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 -``` +- **Frontmodell:** `gemma3:4b` — raske svar, enkel resonnering +- **Lett tool-modell:** `qwen2.5:3b` — tool calling, responsivt +- **Standard mellomlag:** `qwen2.5:7b` — kvalitet + brukbar latency +- **Kode-modell:** `qwen2.5-coder:7b` — standard for repo/kodearbeid +- **Backup coder:** `qwen2.5-coder:14b` — batch/asynkrone kodeoppgaver --- @@ -155,8 +144,6 @@ Deploy verifisert: `get_connector_status` → `live`, `gitea: online`, `tool_cou ## 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) | @@ -167,180 +154,38 @@ NS-bytte: Proisp → Google Cloud DNS **23:44 CEST** --- -## 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= \ - --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 +1. ⚠️ Roter GITEA_TOKEN (eksponert i chat) +2. `git.vauco.no` HTTPS — firewall prioritet 500 + certbot +3. Google OAuth2 innlogging i Gitea +4. GPG-signering — få commits verified +5. Test `qwen2.5-coder:7b` 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) +9. opax.vauco.no domain mapping (Cloud Run → custom domain) ## 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 +- Lokale modeller er hovedretning +- Gitea-VM (`34.67.252.59`) er permanent målmaskin — alltid-på +- Bruk `localhost:3000` fra Gitea-VM, aldri ekstern IP mot seg selv +- Dev-snap er ikke lenger nødvendig for kjerneflyten +- CPU er primær flaskehals for tyngre lokale modeller ## 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 +- ✅ Gitea read/write 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 +- ✅ Dev-snap uavhengighet verifisert — FERDIG +- ✅ OSVauco arbeidskopi på Gitea-VM — FERDIG +- ⏳ `git.vauco.no` live med HTTPS — neste +- ⏳ Google OAuth2 innlogging Gitea — etter HTTPS +- ⏳ GITEA_TOKEN rotert — kritisk - ⏳ 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 @@ -350,8 +195,9 @@ gcloud compute disks create gitea-restore \ | 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 | +| 2026-07-22 03:55 | Handoff oppdatert etter 14B-validering | +| 2026-07-22 19:25 | OSVauco klonet til Gitea-VM via localhost:3000 | +| 2026-07-22 19:30 | Dev-snap uavhengighet bekreftet — alle 6 tester grønne | +| 2026-07-22 19:45 | nginx installert, git.vauco.no konfig opprettet, certbot blokkert av firewall | +| 2026-07-23 22:14 | Handoff oppdatert med full status, neste steg og sikkerhetsnotis om token |