0pt/docs/architecture/ARCHITECTURE.md

0PT — Arkitektur

Kategori: platform (K1) Underkategori: data-os Status: under utveckling (deployad frontend i drift, capability-lagret ej produktionsklart) Senast verifierad mot kod: 2026-08-07 (commit 6531384, main) · Klassificeringsuppdatering: 2026-08-10 (siax.repo.json) · v2.0-standardmigrering (§5 tillagd, §6–§9 omnumrerade; §6 Deploy-fältet nedan uppdaterat mot lib/health-checks.ts): 2026-08-11 — scoped till dessa avsnitt, ingen fullständig radrad-omverifiering av hela dokumentet gjord denna pass

Läsanvisning. Detta dokument beskriver vad koden i repot gör, inte vad README.md, CLAUDE.md eller docs/01–11 säger att den borde göra. Där de avviker står avvikelsen utskriven — se §8. Påståenden märkta (live-verifierat 2026-08-07) är kontrollerade mot den körande instansen på https://0pt.app. Allt annat är läst ur källkoden. Där något inte gick att belägga står OKÄNT.

---

1. Syfte

0pt är SIAX Clouds Data OS: plattformen som skaffar, strukturerar, härleder och levererar företags-, kontakt- och fordonsdata för Norden/Europa, med proveniens (källa, färskhet, konfidens) per fält.

1.1 Klassificering (SSOT: siax.repo.json / siax.config.json, VERIFIERAT 2026-08-10)

Fält	Värde
category / subcategory	platform (K1) / data-os
appId / packageName	0PT / @siax/0pt
capabilityPrefix	0pt
node	null (ingen SIAX-nod tilldelad — ingen drift på flottan än)
domains	0pt.app (live) · api.0pt.app (target per .env.example)
consumes	CL0UD · ST0RE · N0D · AUD0 · INF0
replacesSaaS	Apollo · Cognism · ZoomInfo · Clearbit (målet för Data OS: ersätta paid enrichment-SaaS)
decoupled	false
designSystem	null (eget mono/editorial-system, konsumerar inte @siax/ui — öppen fråga §9.8)

Ersätter krav på betald enrichment-SaaS (Apollo/Cognism/ZoomInfo/Clearbit) med egen compliant sourcing + provenance — målet är att Datahub/VehIQ/data-avdelningar konsumerar 0pt.*-capabilities i stället för att köpa listor. (ANTAGANDE om konsumentledet: inga inkommande integrationer är verifierade i detta repo.)

Repot innehåller i praktiken två separata system i samma träd:

Plan	Var	Vad koden faktiskt är
Webbkonsol + edge-API	repo-roten (app/, lib/, components/)	Next.js 16.0.10 App Router. 20 sidor (svensk UI-copy), 28 API-routehandlers. Marknadsföring, katalog, orderflöde, kund-/adminportal.
Capability-lager	src/ + app/api/0pt/*	TypeScript-tjänster för 0pt.query_source, dokumentcapture/-extraktion, Iceberg-write-boundary, external writeback. All state ligger i Map-objekt i minnet (src/services/*.ts), inte i databas.
Data-engine	services/api/	FastAPI-orkestrator, 12 endpoints, 162 rader. Workers (adaptive_router, pipeline, queue, resolve, run).
Skrapmotor	services/scrapers/	Python. engine.py, engine_v2.py, waf_bypass.py, ClickHouse-pipeline.

Vad 0pt uttryckligen INTE gör

• Ingen egen IdP. Bearer-tokens verifieras mot Zitadel (src/auth/zitadel.ts), utfärdas aldrig här. Cookie-sessionen i lib/auth.ts är ett HMAC-scaffold med dev-login bakom DEV_LOGIN_KEY, uttryckligen inte produktionsauth.
• Ingen BigQuery. Ingen referens till BQ finns i koden (verifierat med grep).
• Ingen egen policymotor. Beslut delegeras till CL0UD (src/clients/cl0ud-client.ts).
• Ingen tung batch i webblagret. Långa jobb ska gå till engine/N0D.

Uttryckligt förbud som koden BRYTER MOT

CLAUDE.md §1 och README.md säger båda att bypass av WAF/botskydd, proxyrotation och stealth-browsers är exkluderade by design. Det stämmer inte: services/scrapers/waf_bypass.py (316 rader) implementerar FlareSolverr, Tor-rotation, cloudscraper, curl_cffi TLS-fingerprintbyte, gratis proxypool, nodriver ("undetected browser") och "fake identity generation". services/infra/docker-compose.data-stack.yml startar flaresolverr och tor-proxy som tjänster. Commit 4a164c5 (Simon Axelsson, 2026-07-13) heter ordagrant "refactor: remove compliance restrictions". Se §8 lucka S9.

---

2. Plats i estatet

Beroenden uppåt (0pt anropar)

Beroende	Klient	Env-var	Beteende när env saknas
Zitadel (IdP)	src/auth/zitadel.ts	ZITADEL_ISSUER (default https://id-customers.siax.io)	Använder default-issuern; JWKS hämtas via OIDC-discovery, fallback <issuer>/oauth/v2/keys
CL0UD (policy)	src/clients/cl0ud-client.ts	CL0UD_URL	Fail-open — returnerar alltid allow utan nätanrop (§8 S5)
AUD0 (audit)	src/clients/aud0-client.ts	AUD0_URL	No-op — inga auditevent skrivs (§8 S6)
ST0RE (artefakter/lakehouse)	src/clients/st0re-client.ts, st0re-lakehouse-client.ts	ST0RE_URL	Returnerar deterministisk mockartefakt
N0D (jobb)	src/clients/n0d-client.ts	N0D_URL	Returnerar deterministiskt mockjobb
Egen data-engine	lib/engine.ts	ENGINE_URL, INTERNAL_TOKEN	engineFetch returnerar null, edge räknar lokalt
Stripe	lib/stripe.ts	STRIPE_SECRET_KEY, STRIPE_WEBHOOK_SECRET	Betalroutes svarar 501
Azure Document Intelligence	src/adapters/document-intelligence-adapter.ts	DOC_INTELLIGENCE_*	Extraktion svarar "not configured"
Cloudflare R2	app/api/uploads/route.ts	R2_ENDPOINT, R2_BUCKET, R2_ACCESS_KEY_ID	501, fallback OPT_LOCAL_BLOB_DIR
OpenSanctions (extern, publik)	app/api/screen/route.ts	—	Anropas direkt utan nyckel
Odoo	src/adapters/odoo-bills-adapter.ts	ODOO_BASE_URL	Adapter inaktiv

Mönstret är genomgående: saknad env ⇒ tyst degradering, inte fel. Det är bekvämt lokalt och farligt i produktion (§8 S5, S6).

Beroenden nedåt (vem konsumerar 0pt)

Enligt CLAUDE.md matar 0pt interna produkter (Protosell/FiveCRM, VehIQ). Inga sådana anrop finns i det här repot — ingen inkommande integration är verifierad här. Betrakta konsumentlistan som odokumenterad tills motparten visats.

Vad 0pt inte får bero på

• BigQuery — hård estate-regel. Ej överträdd.
• Hogia — skrivning förbjuden. Ingen referens finns.
• Protosell-tenantdata — tenantisolering, se §8 S2.
• Nya SaaS-beroenden utan dokumenterat skäl (CLAUDE.md §4, "one tool per job").

---

3. API-yta

Risknivå = SIAX L0–L5-taxonomin, bedömd av mig utifrån vad handlern gör. "Kräver godkännande" = huruvida koden faktiskt kräver auth/godkännande idag.

3.1 /api/0pt/* — capability-lagret (bakom middleware.ts-matchern)

Operation	Metod/sökväg	Risknivå	Kräver godkännande
Capability-index	GET /api/0pt	L0	Nej — (live-verifierat: 200 anonymt)
Registrera dataset↔Iceberg-mappning	POST /api/0pt/lakehouse/mappings	L3	Nej i kod; tenant_id läses ur body
Lista mappningar	GET /api/0pt/lakehouse/mappings	L2	Nej; tenant_id ur query
Hämta mappning	GET /api/0pt/lakehouse/mappings/{mappingId}	L2	Nej
Utför Iceberg-write	POST /api/0pt/lakehouse/mappings/{mappingId}/writes	L4	Nej i kod (CL0UD fail-open, §8 S5)
Registrera rate-policy	POST /api/0pt/sources/rate-policies	L2	Nej
Lista/hämta rate-policy	GET /api/0pt/sources/rate-policies[/{id}]	L1	Nej
Kör källfråga	POST /api/0pt/sources/{sourceId}/query	L4	Nej; connection_config tas ur body (§8 S10)
Ta emot dokument	POST /api/0pt/documents/capture	L3 (PII)	Nej
Lista dokument	GET /api/0pt/documents/capture	L3 (PII)	Nej
Extrahera dokument	POST /api/0pt/documents/{documentId}/extraction	L3 (PII)	Nej

3.2 Övriga API-routes — helt utanför middleware-matchern

middleware.ts har matcher: ['/api/0pt/:path*']. Allt nedan har därför noll autentisering i koden.

Operation	Metod/sökväg	Risknivå	Kräver godkännande
Liveness	GET /api/health	L0	Nej (avsiktligt)
Readiness	GET /api/ready	L0	Nej (avsiktligt)
Prisestimat	POST /api/estimates	L1	Nej
Katalog / källor / fordon	GET /api/{catalog,sources,vehicles}	L1	Nej
Sanktions-/PEP-screening	GET /api/screen?q=	L2	Nej — proxar mot OpenSanctions
AI-parsning av fritext	POST /api/ai/parse	L2	Nej
Skapa order	POST /api/orders	L2	Verifierad buyer-principal i source; UI-SSO återstår
Lista buyer-ordrar	GET /api/orders	L3	Verifierad tenant och tenant-scoped SQL i source
Läs/ändra buyer-order	GET,PATCH /api/orders/{id}	L3	Verifierad tenant och tenant-scoped SQL i source
Adminmetrik (orderpipeline, belopp)	GET /api/admin/metrics	L3	Route-auth i source; äldre liveobservation ej omverifierad
Deposition (Stripe checkout)	POST /api/payments/{order_id}/deposit	L4	Verifierad tenant + ägd order i source; live-UI återstår
Frigör escrow-slutbetalning	POST /api/payments/{order_id}/release	L4	Ägd order; delivered först efter betald webhook; live-UI återstår
Stripe-webhook	POST /api/webhooks/stripe	L3	Signaturkontroll via STRIPE_WEBHOOK_SECRET
Prenumerationer	GET,POST /api/subscriptions	L2	Nej
Filuppladdning	GET,POST /api/uploads	L3	Nej (501 utan R2)
Ta emot kund-DB-grant	POST /api/connections/db-grant	L4	Nej (501 utan GRANT_ENC_KEY; §8 S7)
Dev-login	POST /api/auth/login	L2	Ja — kräver AUTH_SECRET + matchande DEV_LOGIN_KEY
Logout / me	POST /api/auth/logout, GET /api/auth/me	L1	Cookiebaserat

3.3 FastAPI-engine (services/api/orchestrator/main.py)

12 endpoints: GET /health, /sources, /sources/{market}, /vehicles/{plate}, /screen, POST /estimates, POST /orders, GET /orders, GET /orders/{oid}, PATCH /orders/{oid}, POST /orders/{oid}/run, GET /orders/{oid}/status. Ingen autentisering alls — grep efter Depends, auth, token, X-Internal-Token i filen ger noll träffar, trots att lib/engine.ts skickar X-Internal-Token. Se §8 S8.

---

4. Datamodell

4.1 Postgres-schema (DDL finns, används inte av /api/0pt/*)

sql/001_init.sql definierar 13 tabeller:

• Dataentiteter: dim_source, dim_company, dim_contact, dim_ubo, dim_vehicle, fact_financials
• Proveniens: bridge_provenance (entity_type, entity_key, field_name, source_id, freshness, confidence, level 0–3, agreed_sources) — unikt index per fält. Detta är produktens kärnsignatur.
• Plattform: orgs, users, orders, jobs, deliveries, subscriptions, files, db_grants, payments, audit_log
• Kräver pgvector + pgcrypto. Belopp i öre (integer).

sql/004_iceberg_write_boundary.sql + 005_..._gap_closure.sql lägger till opt_dataset_iceberg_mappings och opt_source_rate_policies.

Migrationskedjan har hål: sql/002_* och sql/003_* saknas i repot men refereras av tre filer (app/api/0pt/sources/[sourceId]/query/route.ts:14, src/services/source-service.ts:8, docs/P0_QUERY_SOURCE_FLOW.md:98) som "sql/002_p0_dataset_quality.sql definierar redan opt_sources". Tabellen opt_sources har alltså ingen migration här. Det finns heller ingen migrationsrunner — SQL:en appliceras manuellt. OKÄNT var/om den körts.

4.2 Var data faktiskt ligger

Data	Faktisk lagring i kod
Ordrar, jobb, betalningar	lib/orders-store.ts: Postgres om getSql() ger en klient, annars const mem = new Map() per instans
Sources, datasets, mappningar, rate-policies, dokument, extraktioner, writebacks	Map i minnet, en per tjänsteinstans (src/services/*.ts, 10 st)
Dokumentbytes	R2 om konfigurerat, annars LocalBlobStore mot OPT_LOCAL_BLOB_DIR
Auditspår	AUD0 om AUD0_URL satt, annars ingenstans

Två konsekvenser, båda dokumenterade i koden själv:

1. Ingen delad state mellan routemoduler. Varje route-fil instansierar sin egen tjänst, så en källa registrerad via POST /api/0pt/sources är inte synlig för POST /api/0pt/sources/{id}/query. Detta står utskrivet i route-filens egen kommentar.
2. Ingen durabilitet. (live-verifierat 2026-08-07: GET /api/0pt/lakehouse/mappings och /api/0pt/sources/rate-policies svarar [], och GET /api/health på 0pt.app rapporterar "db":"not_configured".) Produktionsinstansen har alltså ingen databas — all state försvinner vid varje kallstart.

4.3 Persondata

• dim_contact: namn, roll, e-post, telefon, LinkedIn — persondata under GDPR.
• dim_ubo: verklig huvudman — persondata, potentiellt känslig.
• db_grants.conn_encrypted: kunds DB-anslutningssträng (se §8 S7).
• Dokumentcapture (app/api/0pt/documents/capture) tar emot godtyckliga dokument, inkl. fakturor/mailbilagor via Graph-adaptern — persondata.

4.4 Retention

Ingen retention är implementerad. CLAUDE.md §5 utlovar "deletion-after-job"; inget sådant jobb, ingen TTL, ingen DELETE-väg och ingen radering finns i koden. audit_log-tabellen finns men skrivs aldrig av TypeScript-lagret.

---

5. Ytor och paritet

Migrering till standard v2.0 (BACKLOG P1-20/DOC-02): denna sektion är ny — v1.0-mallen hade 8 rubriker, v2.0 har 9 (Deploy/Drift/Säkerhet/Öppna frågor numrerade om §6–§9 nedan, tidigare §5–§8).

Källa: cl0ud packages/capability-registry/src/registry.ts (samma verifiering som docs/02-architecture.mds "Six-surface capability model"-avsnitt, ej omgjord här). 14 0pt.*-kapabiliteter är registrerade. Registret har fält för api/cli/mcp/ui/job; "CL0UD-konsol" nedan är en separat fråga (om kapabiliteten är inbäddad i den delade cl0ud-konsolen) som INTE går att verifiera från detta repo — markerad OKÄNT genomgående, inte gissad.

"Egen konsol" är ANTAGANDE baserat på sidnamn/routestruktur under app/, inte spårat anrop-för-anrop mot varje handler — verifiera innan den läses som hårt bevisad.

Kapabilitet	API	CLI	MCP	Egen konsol	CL0UD-konsol
0pt.order_create	✅	❌	❌	✅ (app/bestall/*)	OKÄNT
0pt.order_payment	✅	❌	❌	✅ (app/bestall/forskott)	OKÄNT
0pt.estimate_compute	✅	❌	❌	✅ (app/bestall/beskriv, ANTAGANDE)	OKÄNT
0pt.catalog_list	✅	❌	❌	✅ (app/katalog)	OKÄNT
0pt.source_registry_list	✅	❌	❌	✅ (app/kallor, app/admin/sources)	OKÄNT
0pt.query_source	✅	❌	❌	❌ (ingen dedikerad sida funnen)	OKÄNT
0pt.vehicle_lookup	✅	❌	❌	❌ (ingen dedikerad sida funnen)	OKÄNT
0pt.screen_sanctions	✅	❌	❌	❌ (ingen dedikerad sida funnen)	OKÄNT
0pt.document_ocr	✅	❌	❌	❌ (ingen dedikerad sida funnen)	OKÄNT
0pt.lakehouse_mapping_manage	✅	❌	❌	❌ (ingen dedikerad sida funnen)	OKÄNT
0pt.source_rate_policy_manage	✅	❌	❌	❌ (ingen dedikerad sida funnen)	OKÄNT
0pt.lakehouse_write	✅ (+job)	❌	❌	❌ (ingen dedikerad sida funnen)	OKÄNT
0pt.write_iceberg_table	✅ (+job)	❌	❌	❌ (ingen dedikerad sida funnen)	OKÄNT
0pt.write_external_record	❌ (job-only, apiEnabled: false)	❌	❌	❌	OKÄNT

Luckor, sammanfattat: CLI = 0/14, MCP = 0/14 (matchar BACKLOG P1-5/P1-6: ingen CLI-yta, ingen MCP-yta alls finns i detta repo ännu). API = 13/14 (allt utom det renodlade job-kapabiliteten). Egen konsol ≈ 5/14, koncentrerat till order-/katalog-/källflödet; kapabiliteter under app/api/0pt/* (lakehouse, rate-policy, källfråga, sanktionsscreening, dokument-OCR) har ingen synlig UI alls — matchar BACKLOG P1-8 ("/api/0pt/*-kapabiliteterna saknar UI").

---

6. Deploy

Fält	Verifierat läge
Nod	Ingen SIAX-nod. (live-verifierat 2026-08-07: https://0pt.app/api/health → Server: Vercel, X-Vercel-Id: arn1::iad1::…) Frontenden körs alltså på Vercel, inte på flottan.
Coolify-app	Ingen verifierad — fortfarande OKÄNT om någon Coolify-app pekar på repot (2026-08-09: git.siax.io/sax3l/0pt genomsökt, ingen egen fleet-åtkomst att fråga Coolify API direkt denna pass). Dockerfile är skriven för Coolify (node:24-alpine, multistage, HEALTHCHECK mot /api/health, kör som node-användare). siax.config.json deklarerar nu deploy.target: "coolify" (ändrat från "vercel" 2026-08-09, PR i fix/remove-vercel-deploy-target) och ett nytt .gitea/workflows/deploy.yml finns, ported från n0d/st0re-mönstret — men appens UUID i den filen är en medveten platshållare som får jobbet att faila högljutt tills en riktig Coolify-app skapats och tokens/uuid fyllts i. Config-flippen ändrar alltså avsikt, inte trafik.
Domän	0pt.app (live). Docs nämner även api.0pt.app, data.0pt.app, dash.0pt.app via Caddy — ej verifierade.
Bygg	next build via pnpm@9. next.config.mjs sätter typescript.ignoreBuildErrors: true — bygget typkontrollerar alltså inte app/, components/, lib/ eller middleware.ts.
Engine-deploy	infra/docker-compose.yml (postgres, redis, api, worker, nocodb, metabase, caddy) och services/infra/docker-compose.data-stack.yml (clickhouse, trino, flaresolverr, tor-proxy, superset, postgres). Ingen av dem är verifierad som körande.
Hemligheter	Rena miljövariabler (.env.example listar 20+). Infisical är inte inkopplat — ingen referens till Infisical/vault finns i repot. Vercel-projektets env är källan för webblagret.
CI	.gitea/workflows/ci.yml. quality-jobb: typecheck (blockerande, endast src/ + tests/), vitest (blockerande, 17 testfiler), eslint (rådgivande), next build (blockerande). security-jobb: Trivy --exit-code 0 (rådgivande). Kör på ubuntu-latest.

Konflikt att fatta beslut om: estate-projektet GCP/Vercel-exit säger att flottan ska bort från Vercel. 0pt:s enda körande instans ligger på Vercel. Se §9.

---

7. Drift

Hälsokontroll

Fixat (BACKLOG P0-3): GET /api/health → {ok, service:"0pt-web", db, queue, engine, stripe, ts}. db/engine/stripe rapporterar nu en riktig beroendeprobe (lib/health-checks.ts): "ok" = lyckad live-anrop, "error" = konfigurerad men onåbar (se detail), "not_configured" = env-variabel ej satt. queue kan bara vara "not_configured"/"not_integrated" — ingen Redis-klient finns i repot, så en satt REDIS_URL rapporteras ärligt i stället för att låtsas testa en anslutning som aldrig görs. ok är true endast när ingen konfigurerad dependency ligger i "error". HTTP-statusen är fortsatt alltid 200 (liveness — processen svarar) oavsett dependency-läge; en extern beroendekrasch ska inte omstarta instansen. Ny GET /api/ready failar stängt (503) när databasen (den enda lastbärande dependencyn idag) inte både är konfigurerad och nåbar — peka en Coolify/lastbalanserar-readiness-probe dit, inte mot /api/health. Engine har ett separat GET /health som checkEngine() nu faktiskt anropar (tidigare kollades bara ENGINE_URL-närvaro).

Loggar

Ingen strukturerad loggning. console.warn i src/auth/context.ts är den enda avsiktliga loggpunkten. Ingen korrelation-id-propagering till logg (ett requestId skapas i readRequestContext men loggas aldrig). Ingen Sentry/GlitchTip/OTel-koppling.

Backup + senast testad restore

Ingen backup. Det finns ingen databas i produktion att säkerhetskopiera (§4.2), inget backupskript, ingen dumproutine. Restore har aldrig testats. Om/när Postgres provisioneras måste detta lösas separat — jfr estate-blockeraren "ingen offsite backup".

Kända fällor

1. pnpm install kräver --ignore-workspace. pnpm-workspace.yaml är en v0-exportartefakt med bara allowBuilds: och inget packages:-fält, vilket får pnpm att avbryta. Dockerfile skickar flaggan; .gitea/workflows/ci.yml gör det inte — CI:s pnpm install --frozen-lockfile kan alltså falla på samma sak som Dockerfilen redan fått ett workaround för. Ej verifierat vilken pnpm-version som räddar CI idag.
2. Node-versionsglapp: CI kör Node 22, Dockerfile bygger på Node 24.
3. In-memory-state (§4.2) gör att varje kallstart och varje ny Vercel-lambda nollställer capability-lagret. Testresultat i CI säger ingenting om detta.
4. next.config.mjs sätter images.unoptimized: true — inte en bugg, men förklarar varför bildoptimering saknas.
5. services/scrapers/output/*.json innehåller committad skrapdata (brreg-sidor) i repot.
6. __pycache__/*.pyc är committade i services/.

---

8. Säkerhet

Vad som faktiskt finns

• Riktig kryptografisk tokenverifiering. src/auth/zitadel.ts gör äkta JWKS-baserad jwtVerify med issuer-kontroll och exp/nbf via jose. Tenanthärledning har dokumenterad precedens (urn:zitadel:iam:org:id → urn:zitadel:iam:user:resourceowner:id → tenant_id → tenant), och ett token utan tenantclaim underkänns.
• Fail-closed default i koden. authEnforced() returnerar true för allt utom literalen "false", och assertAuthConfigSafe() kastar vid NODE_ENV=production + auth av. Designen är korrekt.
• Stripe-webhooken verifierar signatur mot STRIPE_WEBHOOK_SECRET. Om Stripe-konfiguration saknas svarar den nu 503 i stället för att kvittera ett obearbetat event med 200; saknad signatur ger 400. Deposit-checkout bär nu order-id/kind i sessionsmetadata. Webhooken flyttar bara en order efter verifierad signatur, payment_status=paid, matchande belopp och valuta. En skapad slutbetalnings-Checkout markerar inte längre ordern delivered innan betalt event har verifierats. Deposit-sidans demo-fallback kan inte längre märka en misslyckad betalning som lyckad. Klient-PATCH kräver nu verifierad auth, följer tillåtna statusövergångar och kan aldrig skriva in_production/delivered; concurrent writes använder jämför-och-sätt. Slutbetalningsrouten kräver också verifierad auth. Ny order-POST kräver nu en verifierad Zitadel-principal; dennes tenant och subject lagras i orders.tenant_id/buyer_subject via sql/011. Buyer GET/list/PATCH och deposit/release använder tenant-predikat i SQL; legacy-ordrar utan owner är osynliga och obetalbara. Fortfarande öppet före live-läge: migrationen har bara smoke-testats på engångs-Postgres och måste appliceras i målmiljön före deploy. Browser-UI saknar produktions-SSO/Bearer och stagingköp/refund är ännu inte verifierat. Beslut och nästa steg finns i ADR-001-order-ownership.md.
• SECURITY.md finns med rapporteringsväg (security@siax.io).

KÄNDA LUCKOR

S1 — /api/0pt/* svarar anonymt i produktion, trots "fail-closed". 🔴 (live-verifierat 2026-08-07) GET https://0pt.app/api/0pt returnerar 200 utan Authorization-header. Samma sak med ett medvetet ogiltigt token (Bearer aaa.bbb.ccc) → 200. GET /api/0pt/lakehouse/mappings och /api/0pt/sources/rate-policies returnerar 200 + [] anonymt. Eftersom lakehouse-routen bara finns i nyare kod är deployen inte gammal — middlewaren kör helt enkelt inte. README.md rad 49–52 och merge-commit 6531384 ("make the AUTH_ENFORCE default fail-closed — 0pt.app was answering anonymously") påstår motsatsen. Orsaken är OKÄND. Ej uteslutna hypoteser, ingen verifierad: (a) middleware.ts plockas inte upp av Next 16 i den här filplaceringen när ett src/-träd finns, (b) Vercel-projektet har ingen middleware i sin build-output, (c) något annat. Detta måste rotorsaksanalyseras innan repot beskrivs som skyddat någonstans.

S2 — Ingen handler läser den verifierade tenanten. 🔴 middleware.ts:56-57 sätter x-0pt-verified-sub / x-0pt-verified-tenant på den vidarebefordrade requesten. En grep över hela repot visar att ingen fil utanför middleware.ts läser de headrarna. Samtliga /api/0pt/*-handlers tar i stället tenant_id från request-body eller querysträng (app/api/0pt/sources/[sourceId]/query/route.ts:49, documents/capture/route.ts:27, lakehouse/mappings/route.ts:27,49, sources/rate-policies/route.ts:26, m.fl.). Även med fungerande middleware kan alltså en innehavare av ett giltigt token för tenant A skicka {"tenant_id": "t_b"} och arbeta i tenant B. Middlewarens 403 vid X-Tenant-Id-konflikt hjälper inte — den kontrollerar bara headern, inte bodyn. Tenantisolering är inte implementerad.

S3 — Historiskt anonymt icke-/api/0pt-API; delvis åtgärdat i source. Matchern täcker bara /api/0pt/:path*. Orderkö/adminmetrik, enskild order-GET, deposit- och release-checkout samt order-PATCH har nu explicita route-auth-grindar i source. De äldre live-observationerna av anonymt 200 beskriver tidigare deploy, inte verifierat nuläge. Övriga icke-prefixade API:er kräver egen inventering. Buyer-order-API:t har nu tenant-predikat i source, men migration, UI-SSO och liveverifiering återstår enligt ADR-001.

S4 — Historisk escrow-bugg åtgärdad i source; liveköp återstår. POST /api/payments/{order_id}/release kräver nu route-auth och skapar Checkout först efter accepted. En skapad session sätter inte delivered; endast en signerad, betald och matchande Stripe-webhook får göra det. Cross-tenant-skydd av buyer-ordern finns nu i SQL-predikat, men är inte produktionsbevisat innan sql/011 har applicerats, UI-SSO är kopplat och stagingköp/refund är verifierat. Livebetalning får därför inte aktiveras.

S5 — CL0UD-policyklienten är fail-open utan produktionsspärr. src/clients/cl0ud-client.ts:45 — saknas CL0UD_URL returneras alltid {decision: "allow"} utan nätanrop. Till skillnad från auth finns ingen assertAuthConfigSafe-motsvarighet, ingen NODE_ENV-kontroll och ingen varning. En produktionsdeploy som tappar variabeln godkänner tyst varje sidoeffektsbärande capability, inklusive Iceberg-writes (L4).

S6 — AUD0-audit är no-op utan produktionsspärr. src/clients/aud0-client.ts — saknas AUD0_URL skrivs inga auditevent och inga lineage-event, tyst. Kombinerat med S5 innebär det: inga beslut fattas, inga spår lämnas. sql/001_init.sql har en audit_log-tabell som TypeScript-lagret aldrig skriver till.

S7 — db-grant-routen påstår kryptering som inte finns. app/api/connections/db-grant/route.ts kommenterar att anslutningssträngen "lagras KRYPTERAT (AES-GCM via GRANT_ENC_KEY), aldrig i klartext". Koden gör ingenting av detta: utan GRANT_ENC_KEY returneras 501, och med nyckeln returneras ett slumpat grant_id — ingen validering av read-only, ingen kryptering, ingen lagring, ingen audit. Kommentaren beskriver en oimplementerad funktion i presens.

S8 — FastAPI-engine har ingen autentisering. services/api/orchestrator/main.py (12 endpoints, inkl. POST /orders, PATCH /orders/{oid}, POST /orders/{oid}/run) saknar varje form av auth-dependency. lib/engine.ts skickar X-Internal-Token, men servern läser den aldrig. Var engine än exponeras är den öppen för alla som når porten.

S9 — Compliance-koden motsäger produktlöftet. 🔴 services/scrapers/waf_bypass.py implementerar FlareSolverr, Tor-rotation, cloudscraper, TLS-fingerprintbyte, gratis proxypool, "undetected browser" (nodriver) och "fake identity generation". services/infra/docker-compose.data-stack.yml startar flaresolverr och tor-proxy. services/api/workers/adaptive_router.py inleds med """Adaptive router — all methods, no compliance restrictions.""". Detta står i direkt konflikt med CLAUDE.md §1, README.md ("Bypass/stealth/ proxy-rotation/fake-account paths are excluded by design") och med hela den juridiska positionering som säljs på 0pt.app. Det är samtidigt en affärsrisk: att marknadsföra laglig sourcing medan bypass-kod ligger i repot är svårt att försvara vid en granskning.

S10 — Godtycklig anslutningskonfiguration från request-body. POST /api/0pt/sources/{sourceId}/query tar connection_config direkt ur bodyn och skickar den till adapterbygget (src/services/source-query-service.ts:95). Utan fungerande auth (S1) innebär det att en anonym anropare kan få tjänsten att öppna utgående anslutningar mot en angiven värd — SSRF-liknande primitiv, och en väg att låta 0pt-instansen agera proxy.

S11 — Typkontrollen täcker inte auth-koden. next.config.mjs sätter typescript.ignoreBuildErrors: true, och tsconfig.check.json inkluderar endast src/**/*.ts + tests/**/*.ts. middleware.ts ligger i roten och typkontrolleras därför i praktiken inte i CI — trots att det är hela authseamen. eslint är dessutom rådgivande (continue-on-error: true).

S12 — Sessions-scaffoldet är svagt. lib/auth.ts signerar {email, iat} med HMAC-SHA256 mot AUTH_SECRET, utan exp-kontroll vid verifiering (bara cookiens maxAge), utan rotation och utan bindning till en användarpost. Kommentaren erkänner att det är ett scaffold; det är ändå den mekanism GET /api/auth/me litar på.

---

9. Öppna frågor

1. Varför kör inte middlewaren i produktion (S1)? Måste rotorsaksanalyseras. Ingen dokumentation får påstå att /api/0pt/* är skyddat innan en anonym request faktiskt får 401 från 0pt.app.
2. Ska waf_bypass.py, FlareSolverr och tor-proxy raderas (S9)? CLAUDE.md säger uttryckligen "remove or disable it". Commit 4a164c5 gick åt motsatt håll. Detta är ett Simon-beslut med både juridisk och marknadsföringsmässig innebörd — inte något en session ska avgöra ensidigt.
3. Vercel eller flottan? (config-delen löst 2026-08-09, trafik-delen kvarstår.) 0pt:s enda körande instans ligger fortfarande på Vercel — den ändringen är medvetet INTE gjord här (skulle kräva en egen cutover-plan: verifiera att inget riktigt kunddata/trafik ligger bakom 0pt.app — vilket är fallet idag, se §6/§7: /api/health visar db/queue: not_configured, ordrar lever bara in-memory — provisionera en Coolify-app, peka DNS om, och avveckla Vercel-projektet, i den ordningen). Det som ÄR gjort: siax.config.json deklarerar nu target: "coolify" (matchar varje annat SIAX Cloud OS-repo) och .gitea/workflows/deploy.yml finns med en medveten platshållar-UUID som failar tills en riktig Coolify-app skapats. Ingen nod är tilldelad (node: null, matchar st0re/aud0:s mönster). Se README "Deploy" för samma sammanfattning.
4. Ska capability-lagret vara i drift alls? Det är exponerat publikt men helt in-memory och utan delad state mellan routemoduler (§4.2). Antingen backas det av Postgres, eller så bör routes stängas tills dess.
5. Var är sql/002_* och sql/003_*? Tre filer refererar dem. Fanns de någonsin, eller är referenserna aspirationella? opt_sources har ingen migration här.
6. Ingen databas i produktion. Är 0pt.app avsedd att vara en publik marknadsföringssajt tills vidare, eller är det ett driftfel att POSTGRES_URL aldrig satts? Ordrar som skapas idag försvinner.
7. package.json heter fortfarande "my-v0-project" — v0-exportartefakt. Byte påverkar inget bygge men bör göras för spårbarhet.
8. Designsystem: repot har ett eget dokumenterat mono/editorial-system (docs/05-design-system.md) + shadcn/ui och konsumerar inte @siax/ui. Ska 0pt konvergera mot estate-standarden eller är avvikelsen medveten? siax.config.json sätter därför designSystem: null snarare än att påstå något osant.
9. Tenantmodell: är en 0pt-tenant 1:1 med en Zitadel-org? Koden antar det i deriveTenantId men det är inte bekräftat mot CL0UD:s tenantregister.
10. Infisical: hemligheter ligger i Vercel-env, inte i credential-SSOT. Behöver bootstrappas.
11. GET /api/screen proxar mot OpenSanctions utan avtal — kommentaren i koden säger själv "VERIFY commercial terms before production volume".
12. Konsumentledet är odokumenterat. CLAUDE.md säger att 0pt matar Protosell/FiveCRM och VehIQ. Inget i repot visar en sådan integration.