# Implementeringsplan: www.opax.work

## Fase 0 — Manglende beslutningsgrunnlag

**Forutsetninger:** Tilgang til Gitea-repo og Google Cloud-prosjektet.

**Endringer:**

1.  **Lokaliser `opax-hub` kildekode:**
    *   Identifiser Gitea-repo og commit/tag som matcher det aktive `opax-hub` container-imaget.
2.  **Verifiser `osvauco-agent` internt API:**
    *   Gjennomgå kildekoden for `osvauco-agent` for å verifisere dets interne API og om det har MCP-rutingslogikk.

**Beslutningskriterier:**

*   Basert på kildekodetilgang og -kvalitet for `opax-hub`, avgjør om den skal videreføres og herdes, eller om `opax-web` skal bygges som en ny tjeneste.

**Risiko:** Lav. Read-only operasjoner.

**Godkjenningspunkt:** Presentasjon av funn og anbefaling for Fase 2.

## Fase 1 — Sikkerhetsopprydding (separat fra webterminalen)

**Forutsetninger:** Eierskap og avhengigheter for de usikre tjenestene er kjent.

**Endringer:**

1.  **Roter `gitea-chat-bridge` webhook:**
    *   Opprett ny webhook.
    *   Oppdater `gitea-chat-bridge` distribusjonskonfigurasjon til å bruke den nye webhooken fra Secret Manager.
    *   Verifiser at den nye webhooken fungerer.
    *   Tilbakekall den gamle webhooken.
2.  **Håndter `osvx-mcp` tjenester:**
    *   Lag en plan for å enten avvikle, stramme inn IAM, eller migrere funksjonaliteten til en sikker tjeneste.
3.  **Oppdater incident-notat:**
    *   Tildel eier og sett tidsfrister for opprydding.

**Risiko:** Medium–høy. Rotasjon av en brukt webhook og endring av Cloud Run-konfigurasjon kan bryte varslinger eller drift dersom avhengigheter ikke er kjent. 

**Rollback:** Behold fungerende erstatter verifisert før gammel webhook tilbakekalles, og dokumenter påvirkede integrasjoner.

**Godkjenningspunkt:** Godkjenning av planen for hver av de tre endringene.

## Fase 2 — Web-lag

**Forutsetninger:** Beslutning fra Fase 0 er tatt.

**Endringer:**

1.  **Harden `opax-hub` eller bygg `opax-web`:**
    *   Implementer nødvendige endringer for å sikre applikasjonen.
2.  **Konfigurer OAuth for produksjon:**
    *   Sett OAuth callback til `https://www.opax.work/auth/callback`.
3.  **Stram inn CORS:**
    *   Sett `ALLOWED_ORIGINS` til `https://www.opax.work`.
4.  **Dedikert Service Account:**
    *   Opprett en dedikert service account for weblaget med minimalt med rettigheter.

**Risiko:** Medium. Ny offentlig OAuth-webapp kan påvirke callback-registrering, cookie-domene, CORS, brukerinnlogging og domeneruting.

**Godkjenningspunkt:** En eksplisitt pre-go-live sikkerhetstest.

## Fase 3 — Intern kjede

**Forutsetninger:** Kildekodegjennomgang har bekreftet call graphen.

**Endringer (betinget av kodegjennomgang):**

1.  **Implementer `opax-web/hub` → `osvauco-agent` kall:**
    *   Hvis kodegjennomgang bekrefter dette, implementer sikker service-to-service kall med ID-token.
2.  **Implementer `osvauco-agent` → MCP-gateway kall:**
    *   Hvis kodegjennomgang bekrefter dette, implementer kall til den herdede MCP-gatewayen.
3.  **IAM-herding:**
    *   Forbered og gjennomgå en eksakt, reverserbar IAM-diff som fjerner `allUsers` først etter at navngitte service accounts er verifisert med minst nødvendige invoker-rettigheter og call path er testet.

**Risiko:** Høy. Endringer i IAM kan påvirke eksisterende integrasjoner.

**Rollback:** Gjenopprett den forrige policyen fra en lagret policy-eksport.

**Godkjenningspunkt:** Godkjenning av IAM-diff før anvendelse.

## Fase 4.0 / pre-go-live sjekkliste

- [ ] Riktig OAuth redirect URI er registrert
- [ ] Allowlist og autorisasjon er testet server-side
- [ ] Cookies bruker Secure, HttpOnly og bevisst SameSite-policy
- [ ] CORS/origin-regler er begrenset til godkjente origins
- [ ] Ingen secretverdier finnes i klientbundle, Git, Cloud Run literal env eller logger
- [ ] IAM-policyer er eksportert og gjennomgått før og etter endring
- [ ] Rollback-eier, DNS TTL og verifisert rollback-prosedyre er fastsatt
- [ ] Observability, feilhåndtering og health checks er på plass

## Fase 4 — Domene og deploy

**Forutsetninger:** Alle tidligere faser er fullført og godkjent.

**Endringer:**

1.  **Undersøk domene/sertifikat-mekanisme:**
    *   Avgjør den beste måten å håndtere domene og sertifikat basert på eksisterende DNS, Cloud Run domain mapping, eller en eksisterende global HTTPS load balancer.
2.  **Deploy til produksjon:**
    *   Deploy den nye/herdede webtjenesten til Cloud Run.
3.  **Konfigurer DNS:**
    *   Konfigurer DNS for `www.opax.work` til å peke til den nye tjenesten.

**Risiko:** Høy. Feilkonfigurering kan føre til nedetid.

**Testing:**

*   Verifiser først mot godkjent preview-/staging-endepunkt eller Cloud Run-URL; etter eksplisitt go-live-godkjenning verifiseres `www.opax.work`.

**Godkjenningspunkt:** Godkjenning av DNS-endringer.