Sync latest snap state and update Gitea remote IP

.vscode/settings.json

@@ -1,5 +1,5 @@
 {
-  "workbench.colorTheme": "Monokai Dimmed",
+  "workbench.colorTheme": "Light 2026",
   "files.autoSave": "afterDelay",
   "terminal.integrated.enableMultiLinePasteWarning": "never",
   "terminal.integrated.profiles.windows": {

docs/ARCHITECTURE.md

@@ -180,3 +180,71 @@ Aldri: direkte tråd-til-tråd
 
 ---
 EOF v1.2 — 2026-06-29 — OPS (osvauco-dev-vm + OSV-pipeline + Emma-eskaleringspolitikk lagt til)
+
+---
+
+## Dual-layer deploymodell: B over A
+
+# Vauco Architecture Manifest
+
+## Core Thesis
+
+Vauco should use a dual-layer deployment model in which **Model B governs Model A**. The internal OPAX-MCP control plane should own policy, approvals, orchestration, and capability boundaries, while the simpler Cloud Build trigger pattern remains the standardized execution path for services that benefit from a repeatable and low-friction deployment flow.
+
+This approach fits the documented profile model, where operator capabilities are broad and privileged while external, family, customer, or blueprint-driven profiles receive narrower and safer capabilities. It also matches the existing direction that OPAX-MCP is the external gateway and governance surface, while Gitea remains the source of truth for code.
+
+## Layer Model
+
+### Layer 1: Gitea as code truth
+
+Gitea is the intended primary source of truth for code, and the repository flow has already been shifted toward Gitea-first operation rather than GitHub-first day-to-day work. This means repository state, branches, commits, and promotion events should originate from Gitea even when downstream deployment mechanisms differ by service type.
+
+### Layer 2: Model A as standard execution plane
+
+Model A is the standardized deploy mechanism: a declarative Cloud Build pipeline builds the image, pushes it to Artifact Registry, renders a temporary service manifest from opax-mcp.yaml, and applies it with gcloud run services replace. This makes Model A suitable as the simple operational path for services that benefit from repeatable, low-drama deployment behavior.
+
+Model A should therefore be treated as the default execution substrate for client-facing or repeatable services, especially where simplicity, supportability, and low operator friction matter more than deep custom orchestration. It is an execution mechanism, not the long-term brain of the platform.
+
+### Layer 3: Model B as internal control organ
+
+Model B is the internal OPAX-MCP-owned control organ. Its documented architecture places webhook verification, approval handling, SMS-based HITL, and deploy orchestration inside OPAX-MCP itself, culminating in a controlled gcloud builds submit using the existing declarative pipeline file.
+
+In this architecture, Model B does not need to replace Model A everywhere. Instead, Model B should govern when Model A is created, updated, permitted, or bypassed, allowing Vauco to keep a proprietary control plane without forcing every service into the same high-complexity execution path.
+
+## Design Principle
+
+The key principle is **complexity in the core, simplicity at the edge**. OPAX-MCP should centralize policy, operator powers, capability boundaries, and architectural governance, while simpler deployment channels remain available for services that do not need bespoke orchestration.
+
+This is operationally healthier than making every deployment path equally advanced. A system where every service must go through the most complex path increases cognitive load and failure analysis burden, while a system with no internal control organ increases fragmentation across triggers, consoles, and undocumented workflows.
+
+## Why This Fits Vauco
+
+This dual model supports the existing profile strategy. The documented access model already distinguishes operator access from family, blueprint, and customer access, which implies a future where capabilities are governed centrally rather than exposed raw to every actor.
+
+It also supports the documented learning-loop strategy: quality should come from verified events, clear diffs, explicit blockers, and curated operational truth instead of uncontrolled growth in tools or context. A layered model makes it easier to preserve that discipline because the control plane can observe, gate, and record the simpler execution plane rather than becoming identical to it.
+
+## Trade-offs
+| Topic | Model A alone | Model B alone | Hybrid: B governs A |
+|---|---|---|---|
+| Speed to restore deploy flow | High | Low to medium | High for standard paths, medium for advanced paths |
+| Proprietary control | Lower | Higher | High where it matters, moderate where standardization is enough |
+| Cognitive load | Lower initially | Higher initially | Lower at edge, concentrated in operator core |
+| Platform value over time | Moderate | High | High, with incremental rollout |
+| Suitability for profiles/capabilities | Limited | Strong | Strong |
+
+## Governance Rules
+To avoid dual-truth drift, the following architectural rules should hold:
+
+- Gitea is the source of truth for code and repository events.
+
+- opax-mcp.yaml is the deploy configuration truth for opax-mcp and should not be bypassed by ad-hoc imperative deploys.
+
+- OPAX-MCP is the policy and control truth for operator-level orchestration and future capability governance.
+
+- Model A is a standard execution mechanism used by policy, not an independent architectural authority.
+
+## Recommended Path
+The recommended path is to restore and stabilize Model A first as the immediate execution layer, because the declarative pipeline file already exists and is the fastest way to stop manual deployment drift. After that, Model B should be built deliberately as the internal governance and orchestration layer that can manage or supersede Model A where appropriate.
+
+This sequence preserves momentum without giving up the proprietary direction. It creates a platform in which Vauco can scale simple services through standardized execution while reserving deeper operator control for the places where control, policy, and identity matter most.
+

docs/HANDOFF.md

@@ -322,3 +322,40 @@ Diagnose har avdekket at en aktiv Gitea-instans kjører på en midlertidig VM, o
 | `scripts/boot.sh` | Session-starter, aliaser, TUI-valg |
 | `scripts/vm-teardown.sh` | Cron 03:00 CEST — stopper dev-vm |
 | `docs/DNS-OG-INFRASTRUKTUR.md` | DNS-kart, IAP-routing |
+
+---
+
+### HANDOFF 2026-07-07: Etablering av autoritativ deploy-pipeline
+
+**Mål:** Gjøre `opax-mcp.yaml` til den eneste autoritative sannheten for deploy av `opax-mcp`-tjenesten, og fjerne den gamle, manuelle deploy-flyten.
+
+**1. Analyse og opprydding av `opax-mcp.yaml`**
+*   **Analyse:** En "diff" mellom live Cloud Run-tjenesten og `opax-mcp.yaml` avdekket avvik. Live hadde gamle GitHub-variabler, mens YAML-filen hadde mange nye (Gitea, Twilio, Gmail).
+*   **Beslutning:** For å gjøre første autoritative deploy så trygg som mulig, ble det besluttet å midlertidig fjerne Gitea-spesifikke variabler (`GITEA_URL`, `GITEA_TOKEN`) fra `opax-mcp.yaml`.
+*   **Resultat:** `opax-mcp.yaml` er patchet og committet. Den representerer nå en ren basis-konfigurasjon uten aktiv Gitea-runtime.
+
+**2. Opprettelse av deklarativ pipeline (`cloudbuild.deploy.yaml`)**
+*   **Analyse:** Den eksisterende `cloudbuild.mcp.yaml` brukte en imperativ `gcloud run deploy`-kommando som overstyrte manifest-filen.
+*   **Beslutning:** En ny, dedikert og deklarativ pipeline-fil ble opprettet.
+*   **Resultat:** `cloudbuild.deploy.yaml` er opprettet og committet. Den bygger et image med unik `$BUILD_ID`, rendrer en midlertidig kopi av `opax-mcp.yaml` med den nye image-taggen, og deployer med `gcloud run services replace`.
+
+**3. Rekonfigurering av Cloud Build Trigger (feilet)**
+*   **Mål:** Peker den eksisterende Gitea-webhook-triggeren (`gitea-osvauco-main`) fra den gamle `cloudbuild.mcp.yaml` til den nye `cloudbuild.deploy.yaml`.
+*   **Problem:** `gcloud`-CLIet for å oppdatere/gjenopprette webhook-triggere viste seg å være kantete og feilet gjentatte ganger.
+*   **Resultat:** Den gamle triggeren ble slettet i et forsøk på å gjenopprette den, men gjenopprettingen feilet. Plattformen er derfor **uten en aktiv CI/CD-trigger for `opax-mcp` akkurat nå.**
+
+**4. Strategisk avklaring og neste steg**
+*   **Vurdering:** Banen med Cloud Build webhooks er teknisk mulig, men føles som en unødvendig kompleks tilpasning. En egen, OPAX-styrt deploy-bro (Modell B) er et bedre langsiktig mål.
+*   **Beslutning:** Vi fullfører den enkle webhook-flyten (Modell A) nå for å få en automatisert pipeline raskt, men planlegger for Modell B senere.
+
+---
+### Status og neste konkrete handling
+
+| Artefakt | Status |
+|---|---|
+| `opax-mcp.yaml` | ✅ Klar for autoritativ deploy (midlertidig uten Gitea-vars) |
+| `cloudbuild.deploy.yaml` | ✅ Klar og committet |
+| **Cloud Build Trigger** | 🔴 **MANGLER.** Må gjenopprettes manuelt. |
+
+**Neste handling:** Gjenopprett `gitea-osvauco-main` manuelt i Cloud Console med den nye `cloudbuild.deploy.yaml` som byggefil for å re-aktivere CI/CD-pipelinen.
+