Some checks are pending
Check Python Version Consistency / Check Python Version (push) Waiting to run
135 lines
5.6 KiB
Markdown
135 lines
5.6 KiB
Markdown
# 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 styringsdokumentet for sporet "lokal LLM-fabrikk + OPAX-MCP + Gitea stabilisering + blueprinting til Gitea-VM".
|
||
|
||
---
|
||
|
||
## OPPDATERINGSLOGG
|
||
|
||
### 2026-07-21 ~19:45 CEST — Perplexity/MCP-sesjon
|
||
|
||
**Hva som ble fikset:**
|
||
- `GITEA_URL=http://34.170.51.84:3000` lagt til i `opax-mcp.yaml` — løste Gitea read-only blokkering
|
||
- `EMMA_MODEL=gemma3:4b`, `EMMA_FAST_MODEL=gemma3:4b`, `EMMA_LIGHT_MODEL=qwen2.5:3b`, `OLLAMA_BASE_URL=http://34.170.51.84:11434` lagt til i `opax-mcp.yaml`
|
||
- Deploy kjørt: commit `ae2a38d`
|
||
|
||
**Verifisert grønt i dag:**
|
||
- `list_commits` ✅
|
||
- `get_file_content` ✅
|
||
- `list_repo_files` ✅
|
||
- `list_emma_models` ✅ — `gemma3:4b` og `qwen2.5:3b` lever på `34.170.51.84:11434`
|
||
- `get_connector_status` ✅ — Gitea online, 37 tools
|
||
|
||
**Fortsatt blokkerende:**
|
||
- `run_emma` feiler — rotårsak ikke bekreftet ennå. Mulig timeout (Cloud Run 60s vs httpx 120s). Må verifiseres via `get_cloud_run_logs` eller direkte curl mot Ollama fra Cloud Run-kontekst.
|
||
- Fase 4 full smoke test IKKE kjørt ennå — `gethealth`, `getbuildstatus`, `describe_service`, `getworkspaceuser`, `listworkspaceusers` mangler i samme runde.
|
||
|
||
**Kjente kodeproblem (ikke fikset ennå):**
|
||
- `server.py` linje ~tools/call: `handler, _, _ = entry` krasjer på 4-element tuples (start/stop_gce_instance)
|
||
- `start_gce_instance` / `stop_gce_instance` dobbeldefinerert — andre def overstyrer confirm-dialog
|
||
- `trigger_build` hardkodet lokal path `/home/chris_christiansen/OSVauco` — feiler fra Cloud Run
|
||
|
||
**Neste steg per handoff:**
|
||
1. Kjør Fase 4 smoke test — alle 10 tools i én runde
|
||
2. Logg resultat her
|
||
3. Først deretter: vurder kodefikser i server.py
|
||
|
||
---
|
||
|
||
## 1. STRATEGISK MÅL
|
||
Målet er å etablere en komplett, stabil og replikerbar lokal driftsmodell på dev-snap/GPU-VM som kan fungere som en blueprint for en senere overføring til Gitea-VM. Dev-snap/GPU-VM brukes nå som en verifikasjons- og byggeflate for å få fart i arbeidet.
|
||
|
||
Den endelige målplattformen, Gitea-VM, er en CPU-VM med 16 GB RAM og 50 GB disk. Modellvalgene må derfor være optimalisert for CPU, RAM og disk. `gemma3:27b` og andre tunge modeller er uaktuelle for Gitea-VM. Målet er å låse et mindre, replikerbart modelloppsett.
|
||
|
||
En lettvekts tre-lags arkitektur (Gemma/Qwen/Gemma eller lignende) skal vurderes, med `qwen2.5:3b` som et sannsynlig mellomledd.
|
||
|
||
## 2. FASTE SANNHETER
|
||
- Gitea er source of truth. GitHub er kun mirror/backup.
|
||
- Lokale modeller er hovedretning. API-basert agentvei er avleggs som primærbane.
|
||
- Dev-snap/GPU-VM er nåværende verifikasjonsflate. Gitea-VM er planlagt permanent målmaskin.
|
||
- Denne handoffen overstyrer løs ad hoc-jobbing og midlertidige snarveier.
|
||
|
||
## 3. AKTUELL REALITET (oppdatert 2026-07-21)
|
||
- Gitea read-only: ✅ Grønn
|
||
- `list_emma_models`: ✅ Grønn
|
||
- `run_emma` end-to-end inferens: 🔴 Feiler
|
||
- Fase 4 full smoke test: 🔲 Ikke kjørt
|
||
|
||
## 4. HOVEDREGEL
|
||
Ingen fase får passere på grunnlag av håp. Kun eksplisitt verifisert grønn status teller.
|
||
|
||
## 5. FORBUDTE AVSPORINGER
|
||
- Ingen blueprinting til Gitea-VM før dev-snap/GPU-VM er 100 % verifisert.
|
||
- Ingen write-capabilities i Gitea før read-only er helt grønne.
|
||
- Ingen ny featureutvikling i MCP mens kritiske feil fortsatt står åpne.
|
||
- Ingen GitHub-først arbeidsflyt.
|
||
- Ingen skjult eller udokumentert env-var-, secret- eller path-magi.
|
||
|
||
## 6. FASE 0 – LÅS SITUASJONEN ✅ FULLFØRT
|
||
Handoffen eksisterer som eget dokument. Gitea er source of truth. Dev-snap er verifikasjonsbase.
|
||
|
||
## 7. FASE 1 – LOKALE MODELLER SKAL LEVE
|
||
**Status: Delvis grønn**
|
||
- `list_emma_models` ✅
|
||
- `run_emma` faktisk inferens 🔴
|
||
|
||
Exit-kriterium: Minst én enkel prompt mot lokal modell lykkes.
|
||
|
||
## 8. FASE 2 – MCP MÅ PEKE KORREKT TIL LOKAL MODELLSTI
|
||
**Status: Konfigurert, ikke verifisert end-to-end**
|
||
- `OLLAMA_BASE_URL=http://34.170.51.84:11434` ✅ i yaml
|
||
- `EMMA_MODEL=gemma3:4b` ✅ i yaml
|
||
- `run_emma` faktisk svar: 🔴
|
||
|
||
## 9. FASE 3 – GITEA READ-ONLY ✅ FULLFØRT
|
||
- `list_commits` ✅
|
||
- `get_file` (ikke testet separat, men samme sti)
|
||
- `get_file_content` ✅
|
||
- `list_repo_files` ✅
|
||
|
||
## 10. FASE 4 – HEL KJEDE MÅ VÆRE SAMTIDIG GRØNN
|
||
**Status: Ikke kjørt**
|
||
|
||
Smoke test som gjenstår i én runde:
|
||
- `get_connector_status` ✅ (kjørt tidligere)
|
||
- `get_health` 🔲
|
||
- `get_build_status` 🔲
|
||
- `describe_service` 🔲
|
||
- `get_workspace_user` 🔲
|
||
- `list_workspace_users` 🔲
|
||
- `list_emma_models` ✅
|
||
- `list_commits` ✅
|
||
- `get_file_content` ✅
|
||
- `list_repo_files` ✅
|
||
|
||
## 11. FASE 5 – FRYS BLUEPRINT PÅ DEV-SNAP
|
||
Ikke påbegynt. Venter på Fase 4.
|
||
|
||
## 12. 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 (ikke verifisert i dag)
|
||
- konfigurasjon er konsolidert
|
||
- ingen skjult API-/agentavhengighet
|
||
- dev-snap-oppsettet er dokumentert godt nok til blueprinting
|
||
|
||
## 13. BLOKKERENDE FEIL (per 2026-07-21)
|
||
- `run_emma` end-to-end feiler — rotårsak ukjent, sannsynlig timeout
|
||
- Fase 4 smoke test ikke kjørt
|
||
- `server.py` dobbeldefinererte start/stop_gce_instance
|
||
- `trigger_build` hardkodet lokal path
|
||
|
||
## 14. OPERATIV PRIORITET
|
||
1. Kjør Fase 4 smoke test
|
||
2. Avklar `run_emma` rotårsak via logger
|
||
3. Fiks server.py (dobbeldef + tuple-unpacking)
|
||
4. Frys blueprint
|
||
|
||
## 15. ENDRINGSREGLER
|
||
Enhver endring loggføres i OPPDATERINGSLOGG øverst med: hva som var feil, hva som ble endret, hvordan verifisert, risiko for regresjon, hvilken fase som er påvirket.
|