Arch Platform — Case

Arch Platform — Intern plattform for autonomi med governance

Et flerlags AI-agent-orkestreringssystem der governance, secrets og knowledge er førsteklasses borgere — ikke ettertanke.

76 %Health Score

7Packages

4Data Adapters

14Registrerte prosjekter

Arkitektur — Seks spesialiserte agenter under Hermes (Chief Architect)

┌─────────────────────────────────────────────────────────────┐
│                    HERMES (Chief Architect)                   │
│         Governance · Secrets · Knowledge · Deploy             │
└─────────────────────────┬─────────────────────────────────────┘
                          │
        ┌─────────────────┼─────────────────┐
        ▼                 ▼                 ▼
┌───────────────┐ ┌───────────────┐ ┌───────────────┐
│  Project      │ │  Health       │ │  Knowledge    │
│  Factory      │ │  Score v2.1   │ │  Engine       │
│  (analyze +   │ │  (Governance  │ │  (failures,   │
│   init)       │ │   20, Sec 25, │ │   patterns,   │
└───────────────┘ │   Eng 25,     │ │   lessons,    │
        ▲         │   Ops 20,     │ │   decisions,  │
        │         │   Doc 10)     │ │   customers)  │
        │         └───────────────┘ └───────────────┘
        │                 ▲                 ▲
        │                 │                 │
        ▼                 ▼                 ▼
┌───────────────┐ ┌───────────────┐ ┌───────────────┐
│  Data         │ │  Audit        │ │  Governance   │
│  Adapters     │ │  (F4.1/F4.2B) │ │  (projects.json│
│  (GitHub,     │ │  Repo +       │ │  SSoT, secrets│
│   Linear,     │ │  Website      │ │  registry)    │
│   Knowledge,  │ │  Audit v1/v2) │ │               │
│   Hermes)     │ │               │ └───────────────┘
└───────────────┘ └───────────────┘
        │                 ▲
        └─────────────────┘
                          ▼
              ┌───────────────────────┐
              │  CI/CD → Cloudflare   │
              │  Pages (governed)     │
              └───────────────────────┘

Governance-modell — Hvorfor det skiller seg ut

Prinsipp	Implementasjon	Hvorfor
Agenter endrer aldri sikkerhetsgrenser	Policy: `Arch lærer av systemet, men endrer aldri sikkerhetsgrenser automatisk`	Produksjonssikkerhet krever menneskelig dømmekraft på risiko
Linear = eneste oppgave-SSoT	Team `ARC` (Arch) + `KLA` (Klarpakke), workflow: Triage → Ready for Tom → Approved → In Progress → In Review → Done	Ingen dobbel bokføring, ingen tapte oppgaver, audit-spor
Git workflow: Issue → Branch → Review → Main	Commit-melding må referere Linear-issue. Push til `main` kun etter grønne gates	Traceability fra beslutning til kode
Deploy = Tom-governed	`workflow_dispatch` only, 12 gates (build → leak-audit → deploy-ready-check → smoke → rollback)	Ingen overraskelser i prod, rollback alltid tilgjengelig
Secrets governance	`.arch/secrets/registry.yaml` (referanser kun), verdier i BWS/wrangler/GH secrets	Ingen hemmeligheter i git, rotasjon uten kodeendringer
Knowledge monotonicitet	Append-only `.arch/knowledge/{failures,patterns,lessons,decisions}`	Læring akkumuleres, aldri overskrives — evidence vinner over heuristikk

Secrets-standard — Konkrete regler

Ingen secrets i config-filer som committes — alltid wrangler secret put eller BWS
Stripe har ingen key-rotasjons-API — rotasjon = planlagt økt med passkey step-up
Resend API-nøkkel-API støtter full rotasjon uten dashboard
Ved rotasjon med utløpstimer: propager NY nøkkel FØR timeren settes
Nøkkelverdier limes aldri i chat — sikker kanal (1Password/direkte filoverføring)

Linear som eneste SSO for oppgaver — Arkitektonisk valg

Vi valgte Linear ikke for "issue tracking", men som eneste kilde til sannhet for hva som jobbes på:

To team (ARC, KLA) med separate workflows — unngår "state from different team"-feil ved transitions
Approved-state finnes KUN i KLA-teamet — ARC går direkte Ready for Tom → Done/In Progress
GraphQL-mutasjoner med stateId/teamId (ikke navn) for deterministiske transitions
Factory (init-project.mjs) oppretter Linear-prosjekt/team kun med --approve — ingen auto-oppretting av eksterne ressurser

Knowledge Graph — 7 domener, append-only

Failures
8 hendelser — incident-rapporter med rotårsak, blast radius, guard + regresjonstest

Patterns
4 mønster — vertikale demoer, governede deploys, evidence-ledger, secrets-registry

Lessons
12 læringer — edge→nodejs, route-handler, wrangler env, kapital kun aktive, registry SSoT, gov deploy verifiser verktøy

Decisions
10 arkitekturvalg — COMBO-strategi, OKX live, Beta-policy, Arch-navn, Selskapsnavn, Deploy-gates, Linear-graphQL

Customers
1 ekte kunde (Autoglass) + 8 prospects med audit-score

Architectures
1 referansearkitektur (Klarpakke Health Score 98 %)

Deploy-pipeline — 12 gates, alle må være grønne

Syntaks-sjekk (alle .mjs)
Build (collect — degraderer grasiøst uten secrets)
Leakage-audit (publikumsartefakter: lokale stier, tokens, secret://)
Deploy Ready Gate (12 bevis: registry, adapters, provenance, intern/publik split, health v2.1, auto-refresh, leakage=0, intern beskyttet, public sanitert, rollback-plan, CI-gates)
Deploy Customer Portal (sanitert, KUN kunde-flate)
HTTP smoke (prod + assets)
Privacy smoke (0 lekkasjer i live data.js)
Rollback (ved rød smoke → forrige production-deployment via CF API)
Alert (Linear ARC-team ved feil)

TLS-håndtrykk på nytt .pages.dev-domene tar ~60–90s — ikke kodefeil, vent og retry.