From e2f43391549a1950f081aa1bc9c1b2ecd3582ef5 Mon Sep 17 00:00:00 2001 From: Gemini Agent Date: Thu, 16 Jul 2026 05:05:02 +0000 Subject: [PATCH] Sync latest snap state and update Gitea remote IP --- .vscode/settings.json | 2 +- docs/ARCHITECTURE.md | 68 +++++++++++++++++++++++++++++++++++++++++++ docs/HANDOFF.md | 37 +++++++++++++++++++++++ pricing.html | 0 4 files changed, 106 insertions(+), 1 deletion(-) create mode 100644 pricing.html diff --git a/.vscode/settings.json b/.vscode/settings.json index 38e51d7..baef7ce 100644 --- a/.vscode/settings.json +++ b/.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": { diff --git a/docs/ARCHITECTURE.md b/docs/ARCHITECTURE.md index ad663d9..075523e 100644 --- a/docs/ARCHITECTURE.md +++ b/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. + diff --git a/docs/HANDOFF.md b/docs/HANDOFF.md index f3193fb..07321f7 100644 --- a/docs/HANDOFF.md +++ b/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. + diff --git a/pricing.html b/pricing.html new file mode 100644 index 0000000..e69de29