55 Commits

Author	SHA1	Message	Date
Ronni Baslund	2bc302c082	feat(operator): partner-style tenant provisioning wizard + admin invite ... The minimal create modal silently dropped adminName/adminEmail — the invite only existed in the partner wizard's server path. Operator now gets the same 5-step wizard UX (organization, domain, first admin, plan with live price catalog, review) composed client-side: POST /tenants creates + provisions, then POST /users/invite-tenant-admin (new, operator-only — lives in UsersModule because UsersModule already imports TenantsModule and the reverse would be circular) runs the same inviteTenantAdmin flow the partner gets, and the result view hands over the single-use recovery link or temp password. Tenant detail page gains an Invite admin action for retries/successors. PLATFORM_TENANT_SLUG back to 'dezky' (the recreated company tenant) + config-rev bump to roll platform-api.	2026-06-10 21:22:14 +02:00
Ronni Baslund	25d932d3c1	fix(domains): platform tenant slug is configurable (prod: dezky-aps) ... The company tenant ended up as slug dezky-aps (the seeded 'dezky' tenant was deleted), so the hardcoded apex allowance for slug 'dezky' would have rejected adding dezky.eu to the real tenant. PLATFORM_TENANT_SLUG env (default 'dezky') now names the only tenant allowed to claim the PLATFORM_TENANT_DOMAIN apex.	2026-06-10 20:57:31 +02:00
Ronni Baslund	f66a343472	fix(infra): Stalwart v0.16 management admin is a real account (admin@dezky.eu) ... The v0.16 config migration silently dropped the fallback admin — the live server had ZERO accounts, so every platform-api JMAP call 401'd and tenant mail provisioning was dead. Bootstrapped via recovery mode on node1 (STALWART_RECOVERY_ADMIN): created the dezky.eu domain + an admin account with the Admin role and the existing STALWART_ADMIN_PASSWORD. v0.16 logins use the full address, so STALWART_ADMIN_USER becomes admin@dezky.eu; config-rev annotation bump rolls platform-api so it picks up the new env. install.sh follow-ups now document the recovery-mode bootstrap for rebuilds instead of the defunct fallback-admin promise.	2026-06-10 20:50:25 +02:00
Ronni Baslund	a43a172449	feat(domains): reserve the platform namespace + one workspace per domain ... dezky.eu doubles as the platform's infrastructure domain AND the company's own employee mail domain (added to the dezky tenant via the normal Domains flow). Guard rails in DomainsService.add: - a domain already used by ANY other workspace is rejected — Stalwart's idempotent ensureDomain would otherwise silently share one mail domain (and its mailboxes) between tenants - the PLATFORM_TENANT_DOMAIN apex is claimable only by the dezky tenant; everything under it (per-tenant service domains, auth/api/mail/* infra hosts) is reserved outright Set PLATFORM_TENANT_DOMAIN=dezky.eu in the prod ConfigMap (was unset, so prod service domains would have been {slug}.dezky.local) and align the seeded dezky tenant's display domain with the environment.	2026-06-10 20:15:46 +02:00
Ronni Baslund	94270c1f22	fix(health): env-driven infrastructure probe targets ... The operator infrastructure page probed docker-compose hostnames (stalwart/postgres/redis/traefik…) which don't resolve in k3s — 7 of 9 services showed down. Probe targets now come from HEALTH_* env vars with the compose names as dev defaults; platform-api-config.yaml sets the in-cluster/host addresses. 'disabled' omits a service from the report — used for OCIS/Collabora until the files tier is deployed.	2026-06-10 19:51:25 +02:00
Ronni Baslund	0840efb759	fix(operator,portal): env-driven sign-out URLs + host labels (no more .local in prod) ... Operator sign-out hardcoded the dev Authentik end-session URL, so prod logout landed on auth.dezky.local. Mirror the portal's env-driven pattern (NUXT_PUBLIC_AUTH_URL/NUXT_PUBLIC_OPERATOR_URL with .local fallbacks). Expose authUrl/operatorUrl via public runtimeConfig and use them for the Authentik admin links and the cosmetic host labels (sidebar, eyebrows, auth-page hints). Portal: signed-out + webmail copy now derive their hosts from runtime config (new public.mailUrl, NUXT_PUBLIC_MAIL_URL in prod).	2026-06-10 19:51:25 +02:00
Ronni Baslund	91134c94f5	feat(auth): Redis-backed OIDC sessions for portal + operator ... nuxt-oidc-auth persists sessions via useStorage('oidc'), whose default mount is per-pod memory — broken at >1 replica (random 401s) and every deploy logged all users out. A nitro plugin now mounts 'oidc' on the dezky-data Redis (db 1, app-prefixed keys, 14d TTL) when SESSION_REDIS_URL is set; dev keeps the memory driver with no Redis required. Replicas back to 2 for both apps.	2026-06-10 18:48:16 +02:00
Ronni Baslund	fd0c5d011b	fix(infra): single replica for portal/operator (per-pod OIDC sessions) ... nuxt-oidc-auth stores sessions in per-pod memory. With 2 replicas, any request balanced to the pod that didn't handle the login 401s — in practice roughly half of all operator API calls failed after sign-in. One replica until sessions move to shared storage (nitro storage on the dezky-data Redis), then scale back up. Already scaled live; this pins the manifests so the next deploy doesn't undo it.	2026-06-10 18:41:59 +02:00
Ronni Baslund	b155e34fe6	fix(infra): runtime OIDC overrides for prod portal/operator login ... CI builds the Nuxt images with no env, so nuxt.config bakes empty OIDC client creds and .local Authentik URLs into runtimeConfig — sign-in dead-ended on the app's own /auth/login. Nitro env overrides only apply when the var name matches the runtimeConfig path (oidc.providers.oidc.* -> NUXT_OIDC_PROVIDERS_OIDC_*), so production secrets need that second set of names; the plain NUXT_OIDC_* ones only work in dev. Also pin NUXT_OIDC_TOKEN_KEY/AUTH_SESSION_SECRET so sessions survive pod restarts. Live secrets patched on the cluster accordingly.	2026-06-10 13:24:29 +02:00
Ronni Baslund	3b9b06a99b	docs(runbook): app tier + push-to-deploy CI/CD flow ... Bring the runbook up to the 2026-06-10 state: app tier + CI/CD in current state, a Deploy flow section (push to main = release, rollback, break-glass, required Gitea secrets), reproduce steps 8-9 (app tier secrets+apply, CI runner + ci-deployer with the runner gotchas), per-router ACME-safe redirect instead of the old global one, platform-api key read-back for Bitwarden, and a pruned TODO list.	2026-06-10 12:19:47 +02:00
Ronni Baslund	9a58e486e3	docs(fleet): note verified push-to-deploy pipeline	2026-06-10 09:20:18 +02:00
Ronni Baslund	323c46fba1	fix(ci): share dind's unix socket with the runner (jobs need a mountable docker host) ... gitea/runner can only bind-mount a UNIX-socket docker host into job containers — the old tcp://localhost:2376 + TLS daemon address cannot be mounted, so build jobs still had no docker API. Share dind's /var/run/docker.sock with the runner via a /var/run emptyDir and drop the DOCKER_HOST/TLS env; the runner auto-finds the socket and the bind path resolves inside dind where the socket lives.	2026-06-10 08:51:44 +02:00
Ronni Baslund	1114be6c93	fix(ci): expose the dind docker host to job containers ... gitea/runner 1.x no longer auto-mounts the docker daemon into job containers (act_runner 0.2.x did), so 'docker build' in the build jobs failed with 'cannot connect to /var/run/docker.sock'. container.docker_host "" restores find-and-mount.	2026-06-10 08:34:54 +02:00
Ronni Baslund	ec707643d6	fix(ci): act_runner 0.2.11 -> gitea/runner 1.0.8 ... Gitea 1.26 never marked finished jobs complete with the deprecated act_runner 0.2.11: the runner ran the job, logged 'Job succeeded' and freed its slot, but Gitea kept the job 'Running' forever, so dependent jobs (build -> deploy) were never dispatched. gitea/runner is the successor project; config, env vars and the .runner registration file are unchanged.	2026-06-10 08:02:40 +02:00
Ronni Baslund	c60937c5cb	feat(ci): deploy to k3s straight from the pipeline (drop Flux plan) ... Push to main = release: after build, a deploy job pins each app image to the commit SHA (kustomize edit set image), kubectl-applies fleet/apps and waits for the rollouts. The runner already runs in-cluster, so it reaches the API server on the in-cluster service IP with a kubeconfig for the new ci-deployer ServiceAccount (namespace-scoped admin, KUBECONFIG_B64 repo secret). The drafted Flux sync/image-automation layer is removed — a GitOps controller plus bot tag-bump commits is more machinery than a single-node cluster needs. Sortable image tags and $imagepolicy markers go with it. Also: per-router ACME-safe HTTP->HTTPS redirects for the app ingresses, platform-api prod config completed (Authentik JWT/JWKS + admin API, Stalwart via the cni0 gateway IP, OCIS/cold-storage placeholders until those tiers exist) and the secrets template/README updated to match.	2026-06-10 07:53:55 +02:00
Ronni Baslund	52e0f5e375	feat(operator): production build + k3s deployment ... - Dockerfile for the operator app (same pattern as portal/booking). - Env-driven auth/app base URLs in nuxt.config so one build serves dev (.local) and production (.eu). - Deployment + Service + Ingress on operator.dezky.eu. - Add operator to the typecheck matrix.	2026-06-10 07:53:55 +02:00
Ronni Baslund	d02eb5ec50	fix(authentik): pin chart 2026.5.2, grant_types allowlist, portal redirect URI ... - Pin the helm-controller chart version (unset = silent latest upgrades) and move the image tag under global.image per the 2026.5 chart layout. - Authentik 2026.5 enforces a per-provider grant_types allowlist; empty list rejected every authorize request. Allow authorization_code + refresh_token for portal and operator providers. - Fix the portal redirect URI to the nuxt-oidc-auth callback path. - Serve the auth ingress on :80 with a per-router HTTPS redirect so the cert-manager HTTP-01 solver keeps working.	2026-06-10 07:53:49 +02:00
Ronni Baslund	4c5fdde787	fix(infra): docker:24-dind + capacity 2 (fix moby cgroup-v2 teardown deadlock that hung 'Complete job')	2026-06-08 22:56:21 +02:00
Ronni Baslund	aef0f44915	chore(infra): act_runner capacity 4 + disable cache server ... Add an act_runner config.yaml (ConfigMap, CONFIG_FILE env): capacity 4 so the typecheck matrix + image builds run in parallel instead of one-at-a-time, and cache.enabled: false (we removed the setup-node cache; the cache server isn't reachable from the DinD job containers anyway).	2026-06-08 22:46:43 +02:00
Ronni Baslund	f331e3c1e6	feat(infra): in-cluster Gitea Actions runner (act_runner + dind) ... Self-registering act_runner on node1 with a privileged docker:dind sidecar so workflow jobs can build + push app images (k3s has containerd only, no Docker daemon). Labels ubuntu-latest + docker; state persisted on a Longhorn PVC. The registration token is applied out-of-band as the gitea-runner-token Secret (not in git). Verified: runner declared successfully, dind API up.	2026-06-08 22:13:38 +02:00
Ronni Baslund	a27c238c76	feat(infra): nightly DB-dump CronJobs feeding the Restic backup ... pg_dumpall (all Postgres DBs + roles) and mongodump (all Mongo DBs) write gzipped dumps to the hostPath /opt/dezky-backup/dumps at 02:50/02:52 UTC, which the host Restic job (03:20) ships to the Storage Box. Each keeps the last 7 local dumps; Restic holds the real off-box retention. - pods run as root (hostPath dir is root-owned, as is the host Restic reader) - mongo job uses bash (mongo:7 /bin/sh is dash → no pipefail) - creds from postgres-secret / mongo-secret via secretKeyRef Verified: both jobs Complete, dumps present on the host (postgres-all ~2.2MB w/ Authentik data, mongo archive).	2026-06-08 21:55:14 +02:00
Ronni Baslund	861212831d	fix(infra): restic→Storage Box backups working end-to-end ... Three fixes found bringing up backups on node1: - restic.env wrote BACKUP_PATHS/RETENTION unquoted → sourcing ran a path as a command ("Is a directory"); now quoted. - ssh config was written to $BACKUP_HOME/.ssh/config, but restic runs as root and its ssh resolves ~ from the passwd db (not $HOME), so it reads /root/.ssh/config — write the Storage Box block there. Also StrictHostKeyChecking=no + UserKnownHostsFile=/dev/null (safe: restic encrypts before upload; fixes flaky Storage Box host-key verification). - Storage Box SFTP lands in /home, so the repo path needs the /home prefix (absolute /dezky hit the root-owned chroot parent → SSH_FX_FAILURE). Verified: repo initialized, nightly snapshot of mail store + Stalwart config + etcd snapshots + dumps dir, `restic check` clean, retention applied.	2026-06-08 21:46:49 +02:00
Ronni Baslund	9d075343c5	feat(infra): migrate Stalwart to the v0.16 config model (config.json) ... v0.16 dropped TOML config. The host service now boots from a tiny config.json that describes only the datastore (RocksDB); all other settings live in the DB (web UI / stalwart-cli / platform-api JMAP). - add stalwart/config.json (RocksDb datastore at /opt/stalwart/data) - install.sh: install config.json instead of config.toml - stalwart-mail.service: --config points at config.json - README: document the v0.16 model + remaining DB-side config + DNS/PTR Verified: Stalwart 0.16.8 runs on node1 with default mail listeners + the :8080 management server. config.toml retained as a reference for the DB settings.	2026-06-08 21:02:17 +02:00
Ronni Baslund	149eb0b020	fix(infra): Stalwart installer — repo rename + exact asset; flag 0.16 config break ... - install.sh: default repo stalwartlabs/mail-server -> stalwartlabs/stalwart (renamed), and select the exact /stalwart-<target>.tar.gz asset excluding the foundationdb build (head -n1 could grab the wrong one). - config.toml: $env{...} -> %{env:...}% (correct Stalwart macro syntax). KNOWN ISSUE: Stalwart v0.16 removed TOML config (single config.json datastore + everything else in the DB via CLI/UI), so this config.toml does not load on 0.16.8 ("Failed to parse data store settings"). Needs either a pinned pre-0.16 version or a migration to the v0.16 config model. Binary is installed; the service is stopped pending that decision.	2026-06-08 20:51:56 +02:00
Ronni Baslund	326b626fc6	feat(infra): full dezky rebrand of Authentik login (logo, favicon, bg, footer) ... Brand CSS only reaches the flow shadow DOM via CSS vars (colors), not the logo/favicon (deeper shadow root) or the "Powered by authentik" footer (light DOM). So, dev-style: serve real dezky assets + sed the bundle. - web-assets/: dezky-logo.svg, dezky-favicon.svg, dezky-bg.svg (carbon). - server-rebrand.py: patches the authentik-server Deployment with an initContainer that copies /web/dist to an emptyDir, drops the svgs into assets/icons, and seds "Powered by authentik" -> "Powered by Dezky". - brand.yaml: branding_logo / branding_favicon / branding_default_flow_background point at the served svgs; auth-flow title "Welcome to Dezky"; signal-green CSS. Verified live: login now matches dev (logo, title, carbon bg, green button, favicon, Powered by Dezky). Durability caveat documented (reverts on helm upgrade).	2026-06-08 20:36:01 +02:00
Ronni Baslund	99cd86cd3a	feat(infra): full dezky branding on Authentik (logo, carbon bg, flow title) ... branding_logo / branding_default_flow_background are file-path fields (reject data URIs), so the dezky logo + carbon background are injected via the brand's custom CSS (data URIs allowed there): logo replaces the authentik wordmark, background overrides the forest. Auth-flow title -> "Welcome to Dezky". Signal-green primary button retained.	2026-06-08 19:54:44 +02:00
Ronni Baslund	db1354a151	feat(infra): Authentik blueprints (portal+operator OIDC, dezky brand) ... Mirror the dev Authentik config in prod via blueprints, applied & successful on node1: - brand.yaml: dezky branding on the default brand (title + signal-green custom CSS) — login page now in dezky colors. - portal-application.yaml / operator-application.yaml: dezky-portal & dezky-operator OIDC apps/providers (prod redirect URLs) + the dezky-platform-admins group & operator access policy. Two 2026.5 gotchas handled + documented in README: - invalidation_flow is now REQUIRED on OAuth2 providers (added via !Find). - ConfigMap mounts are symlinks (discovery can't read them) → worker uses an initContainer that copies them to an emptyDir as real files. (chart worker.volumes didn't apply on this version; patch reverts on helm upgrade — noted as a durability TODO.) Client secrets (PORTAL/OPERATOR_OIDC_CLIENT_SECRET) live in authentik-secret; the apps must reuse them.	2026-06-08 19:46:48 +02:00
Ronni Baslund	406e2ca78b	feat(infra): deploy Authentik (auth.dezky.eu) + global HTTP→HTTPS redirect ... - Authentik on the in-cluster Postgres/Redis (mirrors the dev compose config: external DB/Redis, error-reporting off, update-check off, bootstrap admin), via the k3s Helm controller; Ingress + cert-manager letsencrypt-prod. Live at https://auth.dezky.eu (image 2026.5.2). Secrets generated on-box (Bitwarden). - Traefik HelmChartConfig: global :80 -> :443 (308) redirect via additionalArguments (to=:443, HTTP-01-safe). - RUNBOOK updated. Deferred (mirror remaining dev bits): OIDC app blueprints (portal/operator with prod URLs) + the cosmetic "Powered by Dezky" rebrand.	2026-06-08 19:00:07 +02:00
Ronni Baslund	153d7053ca	feat(infra): k3s foundation — cert-manager, Longhorn config, in-cluster data tier ... Adds the production cluster foundation (authored + applied live on node1): - cert-manager via the k3s HelmChart controller + letsencrypt staging/prod ClusterIssuers (HTTP-01 / Traefik). - Longhorn config for single-node (values: replica=1, default StorageClass, Retain) + backup-to-Hetzner-Object-Storage credential template. - In-cluster data tier (dezky-data): Postgres 16 (with Authentik+OCIS DB init), MongoDB 7, Redis 7 as StatefulSets on Longhorn, + secret template. - bootstrap.sh: install open-iscsi/nfs-common + enable iscsid (Longhorn prereq). - RUNBOOK.md: full reproducible node1 build order. Real secrets are generated on-box and kept in Bitwarden — never in git.	2026-06-08 18:39:31 +02:00
Ronni Baslund	65a68ee126	feat(ocis): persistent sessions + flat primary surfaces ... - Request offline_access for the ocis-web client (WEB_OIDC_SCOPE) so the web SPA gets a refresh token and renews silently instead of dropping the session (no surprise logouts; the "no permission to upload" symptom was the expired-token state). The ocis-provider already has the offline_access scope mapping; its access-token validity is bumped 5m → 1h (refresh 30d). - Flatten the remaining brand gradients in index.html: the active sidebar highlight (.oc-background-primary-gradient) and primary buttons (.oc-button-primary-filled) are now solid carbon (text stays light/readable). - Document the offline_access + token-validity provider settings in AUTHENTIK-SETUP.md (the provider lives in Authentik's DB, not git).	2026-06-07 12:34:26 +02:00
Ronni Baslund	8a9fd36f33	feat(ocis): dezky whitelabel theme for the files web UI ... Skin OCIS web in the dezky brand so users don't see ownCloud/Infinite Scale. - Custom theme.json (WEB_UI_THEME_PATH + WEB_ASSET_THEMES_PATH): dezky name, slogan, logos (light wordmark for the dark top bar, dark wordmark for the light login, favicon), and the full dezky palette — carbon chrome, signal yellow as a sparing accent, paper/bone surfaces, dezky semantic colours - Pin the light theme as default (single variant) so OS-dark / auto-system always resolves to it - Override only index.html via WEB_ASSET_CORE_PATH (OCIS falls back to the embedded core per-file): hide the ".versions" footer ("Infinite Scale … / ownCloud Web UI …") and set the pre-hydration <title>/theme-color to dezky Apache-2.0 lets us drop the ownCloud marks without trademark fees. NOTE: index.html pins the built bundle hashes — refresh it after an OCIS image bump.	2026-06-07 12:14:04 +02:00
Ronni Baslund	35bc7b6c31	chore(infra): production manifests + CI for scheduling apps	2026-06-07 09:27:44 +02:00
Ronni Baslund	e33b7f18a3	feat(scheduling): pluggable captcha (Turnstile) on public booking	2026-06-07 09:02:35 +02:00
Ronni Baslund	3831c85285	feat(infra): production host bootstrap and bare-metal Stalwart scaffolding ... Host provisioning for the single-server production target: SSH + firewall hardening (nftables allowlist), k3s node registration, bare-metal Stalwart install with systemd units and TLS cert-sync from the cluster secret, and Restic encrypted backup/restore (primary + DR) with timer units. Host-specific secrets live in config.env (gitignored); config.env.example is the template. Also gitignores MemPalace per-project files.	2026-06-07 00:19:48 +02:00
Ronni Baslund	5ed3d2bc5f	feat(scheduling): dezky Scheduling — Calendly-style booking on Stalwart calendars ... First-party booking system on top of Stalwart calendars (no third-party scheduling dependency). Hosts expose public booking pages; visitors pick a slot computed from the host's live Stalwart free/busy, and confirming writes the event to the host's calendar and sends a dezky-branded confirmation with an .ics. platform-api (services/platform-api/src/scheduling): - Schemas: Host, StalwartCredential (AES-256-GCM at rest), AvailabilitySchedule, EventType, Booking, SlotLock (unique (hostId,startUtc) + TTL). - StalwartCalendarModule: JMAP gateway (free/busy via Principal/getAvailability, event create/delete, scheduleAgent=client) + on-behalf app-password provisioning. CredentialCipher for at-rest encryption. - DST-correct slot engine (Luxon) with unit tests; two-layer double-booking guard (atomic SlotLock + live free/busy re-check). - Booking confirm/cancel/reschedule, branded email + .ics via JMAP submission, self-service manage tokens. /api/v1 public + tenant-gated admin routes, per-IP rate limiting. apps/booking: standalone public, whitelabel booking app (booking.dezky.eu) — path-based tenant resolution, per-tenant brand colour, booking + manage flows. apps/portal: admin scheduling page (hosts, event types, availability, bookings with edit/delete + admin cancel/reschedule) and proxy routes. infra: booking dev service in docker-compose; scheduling env vars.	2026-06-07 00:17:36 +02:00
Ronni Baslund	c9911cc262	feat(website): add Nuxt 4 marketing landing page ... New standalone apps/website (Nuxt 4) serving the public marketing site at dezky.local / www.dezky.local. The customer portal moves off the root domain to app.dezky.local only. Landing page ported from the Dezky design handoff: light theme, Danish default, hero variant A, with a working da/en toggle. Self-contained colour system threaded through components (utils/landingTokens.ts), full bilingual copy (utils/landingCopy.ts), and shared state (composables/useLanding.ts). Sections live under components/landing/* with the Node logo under components/brand/*. Wired into docker-compose (website service, volume, Traefik labels, network aliases) and bootstrap.sh (hosts list + service URLs).	2026-06-05 10:58:25 +02:00
Ronni Baslund	47eb9502f8	feat(platform): real email domains, mailboxes & member lifecycle ... Wire the mail/identity stack to real Stalwart/Authentik/OCIS provisioning, replacing the mocked Domains and Users pages. Domains (customer-admin): - StalwartClient: real JMAP management (v0.16 dropped REST) — create/list/delete email domains via x:Domain at the internal http://stalwart:8080 listener; DKIM auto-generated; the records to publish are read from the domain's dnsZoneFile. Gated by STALWART_PROVISIONING_ENABLED. - New Domain collection + DomainsModule: add/list/recheck/set-DMARC/remove, tenant-membership-gated and audited. - DnsVerifierService: verifies MX/SPF/DKIM/DMARC/ownership against a public resolver (1.1.1.1/8.8.8.8) and diffs them against the expected records. - Remove is guarded: refuses while accounts/aliases/mailing lists still use the domain (via Stalwart referential integrity). - Domains page + add wizard on real data; sidebar badge counts domains needing attention. Users & groups (customer-admin): - Create a member provisioned across Authentik SSO, a Stalwart mailbox on the tenant's primary domain, and OCIS — returning a one-time password. - Lifecycle: suspend/resume (Authentik is_active + freeze the mailbox via account permissions, original password preserved), force-logout (terminate sessions, filtered client-side so it can never end other users' sessions), reset password (new one-time password on SSO + mailbox), and remove (tear down mailbox + SSO identity + OCIS + doc; mailbox-in-use aware for multi-tenant users). Self-suspend / self-force-logout are blocked. Infra: point platform-api at the internal Stalwart listener; document the new STALWART_/provisioning vars in .env.example.	2026-06-01 21:19:42 +02:00
Ronni Baslund	f8618b2bbc	feat(portal): real OCIS storage data via refresh-token service auth ... The Storage page + endpoint landed earlier but had no working OCIS backend credential. OCIS has no service-account/client-credentials grant and trusts a single issuer, and basic auth resolves no user in our external-IdP setup — so authenticate OcisClient via an OIDC refresh-token bootstrap instead: - One-time headless login of svc-platform-api against the ocis provider (public client ocis-web, issuer .../o/ocis/) yields a refresh token, persisted in Mongo (ocis_credentials) and rotated on every use. - OcisClient mints access tokens with the refresh_token grant; the service user holds the OCIS admin role (OCIS_ADMIN_USER_ID) so libregraph ListAllDrives works. - scripts/bootstrap-ocis.mjs re-runs the bootstrap if the token lapses. - Dashboard Plan card gains a storage capacity bar beside seats; hidden when storage is unavailable. - compose + .env.example: OCIS service OIDC env and admin user id. - docs/NEXT-STEPS: document the mechanism and the dead-end alternatives.	2026-05-31 21:29:17 +02:00
Ronni Baslund	559348f6bc	feat(portal): real Security & audit page (+ bundled Storage / per-tenant-roles WIP) ... Security & audit (admin) - Audit log: real, tenant-scoped — widened GET /tenants/:slug/audit with q/action/outcome/actorEmail/since/before; UI gains search, outcome + time filters, action chips, cursor pagination, and client-side CSV export. - Security policy: new tenant.securityPolicy (mfaMode, session idle/absolute, allowedCountries, ipAllowlist) + PATCH /tenants/:slug/security-policy (membership-gated, audited). Editable, labelled by enforcement status. - MFA: live enrollment overview via GET /tenants/:slug/mfa-status (Authentik countAuthenticators per member). - SSO apps (Dezky as IdP): real Authentik OIDC provider + application CRUD, scoped to the tenant group. New AuthentikClient methods (provider/app/binding + flow/key/scope discovery), TenantSsoApp schema, TenantSsoService (rollback on partial failure; client secret never stored), GET/POST/DELETE /tenants/:slug/sso-apps. Validated end-to-end against live Authentik. - Deferred: shared-flow MFA/geo/session enforcement (global auth-flow blast radius) — to be done as its own reviewed change. Bundled in-progress work that shares the same files (kept together so the tree stays green): - Storage page: StorageService + GET /tenants/:slug/storage (OCIS-backed), storage.get proxy, storage.vue. - Per-tenant roles: User.tenantRoles + MeProfile.tenantRoles plumbing.	2026-05-31 17:20:36 +02:00
Ronni Baslund	3288fde693	feat(portal): customer-admin surface on real data + Stripe billing + session resilience ... Access & navigation - Gate partner-mode strictly to partner staff so admins/end-users never inherit leftover partner-view state; purge stale session entry on hydrate. - Role-driven admin entry: useMe.isTenantAdmin, Admin/Personal tiles in the app launcher, and an /admin route guard in the global middleware (fail closed). - Drop the duplicate user identity block from the sidebar footer. Admin pages on real data - New tenant-scoped, membership-gated endpoints: GET /tenants/:slug/{audit,users, invoices}; useTenant composable resolves the active workspace + subscription. - Dashboard: real seats, spend (cycle-normalized + minor-units), plan, renewal, and recent audit; unbacked sections removed. - Users & groups: real members; Groups/Invitations/Service accounts shown as honest "coming soon". - Subscription & invoices: real plan hero, invoice history, and billing details. Stripe payment method (Elements + SetupIntent) - StripeClient: publishable key + getDefaultCard/createSetupIntent/setDefaultCard. - CustomerBillingController + BillingService methods (ensure-customer on demand). - Portal: PaymentMethodModal, useStripeJs (CDN load), proxies; hidePostalCode. Editable billing details & whitelabel branding - PATCH /tenants/:slug/billing-info (narrow: company/VAT/country/email). - TenantBranding schema/service + GET/PUT /tenants/:slug/branding: real product name, accent colour, and per-tenant email-template overrides. - Branding preview + sidebar workspace mark wired to real name/plan/seats/colour with YIQ auto-contrast (readableOn util). Session resilience - Request offline_access so Authentik issues a refresh token (automaticRefresh). - Silent refresh + single retry on 401 for writes (useApiFetch, incl. partner pages) and reads (useMe.fetchMe) — no redirect, no lost input. - Modal backdrop closes only on press+release on the backdrop (no more drag-select-to-close).	2026-05-31 00:19:34 +02:00
Ronni Baslund	0b269e7ea7	feat(auth): enforce operator/partner platform isolation ... A partner or tenant admin could complete the dezky-operator OIDC flow and land on the operator portal. The platform-api OperatorGuard already 403s their data, but the login/UI layer had no authorization check at all — the only gate was a manual Authentik UI setting with nothing in git enforcing it. Close it with defense-in-depth across three independent layers: 1. IdP — operator-application.yaml blueprint binds an ak_is_group_member("dezky-platform-admins") policy to the dezky-operator app, so Authentik denies the OIDC flow for non-admins. The blueprint also provisions the provider + application (state: created, so a fresh env is built from code while an existing hand-made provider is left untouched). Wire OPERATOR_OIDC_* into both authentik containers and mount the blueprints dir on the worker (it applies blueprints, and previously lacked the mount). 2. Operator app — require-platform-admin.global.ts requires platformAdmin and routes a non-admin to not-authorized.vue, which triggers a full sign-out (local + Authentik IdP) for shared-workstation safety. Fails open on a transient /api/me error by design, to avoid mass-signout on platform-api restarts; layers 1 and 3 contain the exposure. 3. platform-api — OperatorGuard (unchanged) requires dezky-operator audience plus platformAdmin resolved from the DB on every request. Also harden the partner surface: it shares the dezky-portal client with tenant users so it has no IdP gate, and its /partner/* route middleware now fails CLOSED when identity can't be confirmed. Docs (AUTHENTIK-SETUP.md) and .env.example updated; the operator client secret must be set before first boot since the blueprint now consumes it.	2026-05-30 15:48:01 +02:00
Ronni Baslund	22925599e7	chore(compose): wire Stripe env into platform-api ... Pass STRIPE_SECRET_KEY, STRIPE_WEBHOOK_SECRET and BILLING_STRIPE_ENABLED into the platform-api service from the gitignored .env. Defaults keep billing dark (derived data) when unset.	2026-05-30 08:08:50 +02:00
Ronni Baslund	0bd4e5498e	feat: portal redesign, pricing catalog, partner-staff invites ... - portal: new admin/ and partner/ surfaces with full component library (AppLauncher, Avatar, Badge, Card, Modal, Tabs, etc.), composables, layouts, partner-routing middleware, and supporting server APIs - pricing: Price schema/module with operator CRUD, pricing.vue catalog UI, Subscription extended with cycle/currency/perSeatAmount/seats snapshots for stable MRR aggregation - partner staff: User.partnerId, invite-partner-user DTO and flow, /partners/:slug/users endpoints, InvitePartnerUserModal, shared dezky-partner-staff Authentik group - /me: partner-aware endpoint returning user + partner context so portal can route between end-user and partner-admin surfaces - tenant: seats field for portfolio displays and future MRR calculations - operator: pricing page, signed-out page, useMe/useToast composables, ToastStack	2026-05-28 20:00:33 +02:00
Ronni Baslund	4d9e906ec1	feat(audit): cold-storage archival to S3 (Phase 4) ... Final piece of the audit work. Events older than the hot retention window move to S3-compatible object storage with signed manifests. Production uses Hetzner Object Storage; dev uses a MinIO container with the same API. Infra (infrastructure/docker-compose): - New `minio` service exposing the S3 API at minio:9000 + admin console at minio.dezky.local. Healthchecked. Bucket-init sidecar runs `mc mb` once to create `dezky-audit`; safe to re-run. - .env adds MINIO_ROOT_USER + MINIO_ROOT_PASSWORD. - platform-api env: AUDIT_COLD_{ENDPOINT,REGION,BUCKET,ACCESS_KEY,SECRET_KEY} + AUDIT_HOT_RETENTION_DAYS=90 + ARCHIVE_ENABLED=false (dormant in dev; operator UI's "Run archive now" bypasses this gate). AUDIT_COLD_SSE opts into SSE-S3 — left unset in dev because MinIO without a KMS rejects AES256 PUTs with "KMS is not configured". Platform-api (services/platform-api/src/cold/): - cold-storage.client.ts: thin @aws-sdk/client-s3 wrapper — put/head/list. forcePathStyle=true so MinIO and Hetzner both work; same code, env-swap. - archive.service.ts: runOnce() selects chained events with at < cutoff → serializes to JSONL → gzip → sha256s → uploads JSONL + signed manifest → HEAD-confirms both objects exist → records an ArchiveBatch doc → only then deletes from hot Mongo. Crash-safe: a failed upload leaves events in hot. Manifest uses the Phase 3 AUDIT_SIGNING_KEY (HMAC-SHA-256), so archives + checkpoints share trust chain. Bypassable via { override: true } for the operator's UI force-run. - archive.worker.ts: hourly tick guarded by configured run-hour-UTC (default 03:00) + day-guard so the same UTC day doesn't archive twice. Disabled until ARCHIVE_ENABLED=true. - archive-batch.schema.ts: { archivedAt, startSeq, endSeq, eventCount, manifestSha256, jsonlKey, manifestKey, bytesUncompressed }. The manifest sha256 stored in Mongo lets us detect manifest tampering without downloading the actual manifest. Audit module additions: - audit.controller.ts: GET /audit/archives, POST /audit/archive/run, /audit/verify now reports { oldestHotSeq, highestArchivedSeq } so the UI shows the tier boundary. Operator UI (apps/operator): - 2 new proxies: /api/audit/archives + /api/audit/archive/run (force override=true). Both behind operator auth via the existing platformApi helper. - audit.vue: new "Cold storage" card with batch table (archived-at, seq range, event count, size, truncated manifest sha256), "Run archive now" button + per-run result line. Smoke-tested end-to-end: - 7 chained events in hot. /api/audit/archive/run → ok=true, batchId returned. JSONL + manifest both exist in MinIO (verified via mc ls + mc cat). Mongo's chained set went 7 → 0. Verify reports highestArchivedSeq=1446 (since we burn-allocate seqs on Authentik dup-key rejections). Operator /audit panel shows the batch with manifest hash 1d8263… - First attempt with SSE-S3 enabled failed cleanly (MinIO KMS not configured) — archive service correctly left events in hot Mongo. Made SSE opt-in via AUDIT_COLD_SSE=true; prod turns it on. Out of scope (each could be its own session): - Restore-to-hot endpoint (today: download from S3 + offline query) - Client-side encryption (today: SSE-S3 in prod, none in dev) - Multi-region replication - Soft TTL safety net (defense-in-depth on top of app-managed deletion) This completes the four-phase audit log work: 1. platform-api as audit hub 2. External system ingest (Authentik / Stalwart / OCIS) 3. Hash-chain + signed checkpoints (tamper evidence) 4. Cold-storage archival (retention without unbounded Mongo growth)	2026-05-24 21:03:41 +02:00
Ronni Baslund	9435baa09d	feat(audit): hash-chain tamper evidence + signed checkpoints (Phase 3) ... The audit log now carries cryptographic chain-of-custody. Every chained event references the previous event's sha256, and periodic checkpoints sign the head with HMAC-SHA-256. An attacker who modifies a historical row must also forge every checkpoint signature past it — which requires the AUDIT_SIGNING_KEY, kept outside Mongo. Schema (services/platform-api/src/schemas/): - audit-event.schema.ts: new `seq` (monotonic) + `chained` (Phase-3-or- later flag) + `prevHash` + `hash`. Compound unique index on seq with partial filter so pre-Phase-3 rows don't collide on null. - audit-counter.schema.ts: single doc `_id='audit_seq'`, incremented atomically by findOneAndUpdate($inc). - audit-checkpoint.schema.ts: { at, headSeq, headHash, signature, sigAlg, reason }. Reason ∈ {startup, interval, threshold, manual}. Audit module (services/platform-api/src/audit/): - canonical.ts: stable JSON form + hashCanonical (sha256) + checkpointSignature (HMAC-SHA-256) + verifyCheckpointSignature (timingSafeEqual). Single source of truth for hash inputs — schema additions land here at the same time as the field. - audit.service.ts: record() now allocates seq → looks up lastHash() → computes hash → inserts. Per-process write mutex serializes the allocate+lookup so concurrent writers don't both chain off the same predecessor. Documented multi-instance caveat (needs Mongo replica set + transactions OR a distributed lock). - checkpoint.service.ts: scheduler triggers on startup + every 5min + threshold of 100 events accumulated. Skips when no new chained events since the last anchor. - verifier.service.ts: walks chain in seq order, recomputes each hash, validates checkpoint signatures. Returns a precise break: 'event-hash-mismatch' (in-place modification), 'event-prev-hash- mismatch' (insertion/deletion), or 'checkpoint-signature-mismatch'. - audit.controller.ts: GET /audit/verify, GET /audit/checkpoint/latest, POST /audit/checkpoint (manual force). Operator UI (apps/operator/): - 3 new proxies under /api/audit/{verify, checkpoint/latest, checkpoint}. - pages/audit.vue: new "Tamper evidence" card with "Force checkpoint" + "Verify chain" buttons. Header shows live head seq; result line shows verified count or a precise break (kind + seq + expected vs actual hash). Background tinted green/red on ok/broken. Env (.env + docker-compose.yml): - new AUDIT_SIGNING_KEY (32-byte hex HMAC secret). Prod swaps this for ed25519 from an HSM/KMS; verifier code stays the same because sigAlg is on the checkpoint doc. Smoke-tested all three break paths against a clean chain of 5 events: - normal verify: ok=true, 5/5 events verified, 1 checkpoint signed - modified seq=3 in Mongo directly: verify returns ok=false with break = { kind: 'event-hash-mismatch', seq: 3, expected, actual } - restored, nuked checkpoint signature: break = { kind: 'checkpoint-signature-mismatch', headSeq: 5 } - operator UI's verify panel reflects all three states correctly. Legacy data: pre-Phase-3 events stay `chained: false` and are excluded from the chain walk. Retroactive chaining of historical entries is a one-off migration script we can run if we ever care to. Out of scope (Phase 4 etc.): - TTL + cold-storage archival to Hetzner Object Storage - GDPR right-to-erasure tooling - ed25519 / HSM signing (swap is well-defined; sigAlg field is ready) - Multi-instance write coordination (Mongo transaction OR distributed lock when we scale platform-api beyond 1 replica)	2026-05-24 20:43:54 +02:00
Ronni Baslund	df18128617	feat(audit): OCIS file-tail ingest worker (Phase 2 chunk 3) ... Tails OCIS's JSON-Lines audit log on a shared Docker volume and forwards mutations into AuditService. Final piece of Phase 2 — the /audit page now unifies platform-api, authentik, and ocis events on one timeline. services/platform-api/src/ingest/ocis.ingest.ts: - 5s polling loop (fs.watch is unreliable across Docker bind mounts on macOS). Stat → detect inode change or truncation → resume from byte position OR start over. - Cursor in IngestCursor stores lastEventId = "<inode>:<bytePosition>". Restarts resume cleanly; on overlap the (source, externalId) unique index dedups silently. - Lines collected first, then processed sequentially after the read stream closes. Earlier draft fired recordOne() from inside the readline 'line' callback which would have resolved the stream before all writes finished — same class of race we hit in the Authentik worker, fixed before commit. - Tenant inference: spaceName (set during provisioning to the slug) first, then User.authentikSubjectId → tenantIds → Tenant.slug. - Mutations only: OCIS_ALLOWLIST in action-map.ts whitelists 24 event types (User/Group/Space/Share/Link/File mutations). FileDownloaded, UserSignedIn, and the rest of the high-volume read traffic gets skipped — keeps the timeline scannable. services/platform-api/src/ingest/action-map.ts: - mapOcisAction() + OCIS_ALLOWLIST. Returns null for non-whitelisted types so the worker filters early. infrastructure/docker-compose/docker-compose.yml: - New named volume `ocis_audit_log` mounted writeable on the ocis container and read-only on platform-api. - OCIS env: OCIS_ADD_RUN_SERVICES=audit (the audit microservice is NOT in the default `ocis server` set — opt in explicitly), AUDIT_LOG_FILE_PATH=/var/log/ocis/audit.log, AUDIT_LOG_FORMAT=json. - platform-api env: OCIS_AUDIT_LOG_PATH points at the same file. Verified end-to-end with synthetic events written to the audit log: - Worker tailed 5 events across initial read + incremental append (5 → bytes 0:1276, then 1 → bytes 1276:1519). - FileDownloaded correctly filtered by the allowlist (4 mutations landed in Mongo, not 5). - Tenant inference: events with executingUser.id resolved to `dezky` via User → tenantIds → Tenant.slug. - Operator /audit shows all three sources (89 events: 79 authentik + 5 platform-api + 5 ocis) in one unified timeline. Known unknown — same shape as the Stalwart commit: I couldn't fully confirm the OCIS v7 audit microservice emits events with just OCIS_ADD_RUN_SERVICES=audit + the AUDIT_LOG_FILE_PATH env. The audit service starts but the file stays empty until OCIS internals start publishing events to NATS (which may need additional service-side config). The ingest worker is correct regardless — when OCIS starts writing real events, they'll flow into /audit. This is a follow-up in the OCIS-side configuration, not in our ingest code.	2026-05-24 20:30:47 +02:00
Ronni Baslund	7bec940e7f	feat(audit): Stalwart webhook ingest endpoint (Phase 2 chunk 2) ... Push-based ingest for mail-server events. Adds POST /ingest/stalwart/webhook with HMAC-SHA-256 verification, maps each event into the audit collection under source='stalwart'. services/platform-api/src/ingest/stalwart-webhook.controller.ts: - Public endpoint (no JwtAuthGuard — Stalwart can't carry a JWT). Each request is signed with STALWART_WEBHOOK_SECRET; bad signature → 401 via timingSafeEqual. - Body: { events: [{ id, type, createdAt, data }, ... ] }. Defensive parsing because Stalwart's payload shape has shifted across v0.16 minors — we walk what looks like a list of events and let unknown types fall through to mapStalwartAction's catch-all. - Per-event recordOne: action via mapStalwartAction(), actor from data.email/account/username, IP from data.ip or X-Forwarded-For, targetName from data.account/email/address/to, full payload kept in metadata. externalId = evt.id so the (source, externalId) unique index dedups re-deliveries. action-map.ts: 14 known Stalwart event types → stalwart.{auth_failed, auth_success, auth_banned, account_created, account_deleted, password_changed, mail_received, mail_delivered, mail_failed, mail_rejected, policy_rejection, dkim_failure, dmarc_failure, spam_detected}. Snake/kebab forms normalized. infrastructure/docker-compose: - .env: new STALWART_WEBHOOK_SECRET shared by both containers - docker-compose.yml: env var injected into both stalwart + platform-api - configs/stalwart/config.toml: [webhook."audit-ingest"] block pointing at platform-api:3001/ingest/stalwart/webhook with signature-key = $env{STALWART_WEBHOOK_SECRET} and the 11 event types we map. Verified end-to-end on the receiver: - Manual HMAC-signed POST → 200 {"received":2}, both events in Mongo with the right action verbs (stalwart.auth_failed, stalwart.account_created), actor/IP/externalId populated. - Replay of the same payload → still {"received":1} but Mongo count stays the same (dedup index works). - X-Signature: deadbeef → 401, no row written. Known unknown: I couldn't fully confirm Stalwart v0.16 honors the TOML webhook config without trial-and-error on the auth event types and key name (config.toml uses signature-key; some Stalwart builds want plain 'key'). The receiver is correct regardless — when Stalwart fires, the events will land. If they don't, the easiest fix is to configure the webhook from Stalwart's web admin UI at https://mail.dezky.local instead of via TOML.	2026-05-24 20:21:29 +02:00
Ronni Baslund	55b1c133e3	feat(operator): scaffold apps/operator Nuxt app + multi-issuer JWT (O.3) ... New Nuxt 3 app at apps/operator/ — internal admin portal on its own domain (operator.dezky.local), own OAuth client (dezky-operator), own session secrets, own cookies. Customer and operator surfaces can't decrypt each other's session state. OAuth flow verified end-to-end: - GET / → middleware redirect to /auth/login - User clicks Sign in → /auth/oidc/login → bounces to Authentik with client_id=dezky-operator, scope includes 'groups' - Authentik checks dezky-platform-admins group binding (added in O.1), silent-reauths via the existing auth.dezky.local session - Returns to /auth/oidc/callback with code, exchanges for token, creates session cookie on operator.dezky.local - Lands on pages/index.vue placeholder dashboard Smoke test 'Create partner "test-partner"' button on the placeholder home exercises the full operator-only authorization chain: - 1st call: 200, partner created in Mongo - 2nd call: 409 'already exists' (idempotency holds, token still valid) - Same call from the customer portal: 403 'requires operator-scoped token' (audience guard rejects dezky-portal aud) JwtAuthGuard now multi-issuer in addition to multi-audience. Each Authentik OAuth provider mints tokens with its own per-app iss URL (.../application/o/<slug>/), so the guard accepts a comma-separated AUTHENTIK_ISSUER. The audience-only fix from O.2 wasn't sufficient — issuer is validated separately by jose.jwtVerify and was still pinned to dezky-portal alone, yielding 'unexpected iss claim value' rejections. Compose changes: new 'operator' service (Node 20 alpine, pnpm install + nuxt dev, mkcert CA mount, traefik labels for operator.dezky.local + TLS); new operator_node_modules volume; operator.dezky.local added to traefik's Docker network aliases. Distinct OPERATOR_NUXT_OIDC_* session secrets pulled from .env (gitignored, generated via openssl). Real operator screens (sidebar, topbar, tenants, partners, etc.) come in O.4. This commit is pure scaffolding + the security boundary proof.	2026-05-24 07:20:16 +02:00
Ronni Baslund	2db41fec5e	feat(platform-api): multi-audience JWT + Partner CRUD + tenant lifecycle (O.2) ... JwtAuthGuard now accepts a comma-separated AUTHENTIK_AUDIENCE ('dezky-portal,dezky-operator'). jose.jwtVerify takes an array and succeeds on any match — both customer-portal and operator-portal tokens validate against this service. Per-endpoint guards restrict further. New OperatorGuard enforces operator-only mutations: 1. JWT audience claim includes 'dezky-operator' (proof from the token alone that this is a privileged session) 2. ActorService-resolved User has platformAdmin=true (DB check so revocation works without waiting for the token to expire) Both required; either alone is insufficient. Partner module: - Partner schema: slug, name, domain, status, marginPct, contactInfo, billingInfo. marginPct is one number per partner (decided in grilling) - CRUD endpoints under @UseGuards(JwtAuthGuard, OperatorGuard) — every partner mutation requires operator scope - GET /partners returns each row with a computed customers count from aggregating Tenant.partnerId. MRR aggregation deferred until Subscription gains a price column - GET /partners/:slug/tenants for the partner detail view - DELETE soft-terminates (status='terminated') — never hard-delete because tenants may still reference the partner Tenant changes: - partnerId?: Types.ObjectId (ref Partner, indexed sparse) added to Tenant schema - UpdateTenantDto accepts partnerId so PATCH can attach/detach - POST /tenants/:slug/suspend and /resume — operator-only via OperatorGuard. PATCH already covers plan/domains/partnerId changes Smoke test: customer-portal session sends POST /api/partners through the portal proxy → 403 "This endpoint requires an operator-scoped token". The positive test (operator-token → 200) waits for O.3 when there's an operator app to mint the right token. apps/portal/server/api/partners/index.post.ts is a temporary verification proxy — delete once the operator portal exists.	2026-05-24 07:08:59 +02:00
Ronni Baslund	22b2583f0b	chore(services): rename services/provisioning -> services/platform-api ... O.0 prep from OPERATOR-PLAN.md. Mechanical refactor before adding partner management and operator-specific endpoints. The service now owns more than just provisioning orchestration (it'll soon own partners, tenant lifecycle actions, multi-audience JWT validation), so the name 'platform-api' reflects its scope better. What changed: - Directory: services/provisioning/ -> services/platform-api/ - Package: @dezky/provisioning -> @dezky/platform-api - Docker: container_name dezky-provisioning -> dezky-platform-api; compose service key 'provisioning' -> 'platform-api'; volume provisioning_node_modules -> platform_api_node_modules - Portal: PROVISIONING_INTERNAL_URL env var -> PLATFORM_API_INTERNAL_URL, default URL http://provisioning:3001 -> http://platform-api:3001 in all three proxy routes (me.get.ts, tenants/index.post.ts, tenants/[slug]/ reconcile.post.ts), plus NUXT_API_BASE updated - Health endpoint service identifier and main.ts log lines updated to 'dezky-platform-api' - Docs swept: README, CLAUDE.md, SERVICES.md, AUTHENTIK-SETUP.md, NEXT-STEPS.md, TROUBLESHOOTING.md, OPERATOR-PLAN.md, traefik/dynamic.yml What deliberately stays: - Internal module names ProvisioningService / ProvisioningModule (those describe an orchestration sub-concern, not the service's purpose) - Tenant.provisioningStatus / provisioningErrors field names (state per integration, not service name) - File services/platform-api/src/tenants/provisioning.service.ts - 'Hetzner provisioning' references in production-prep docs (infrastructure provisioning, unrelated) Verified end-to-end after rename: /api/me returns 200 with profile + 2 tenants + subscription, /api/tenants/dezky/reconcile returns 200 with Authentik integration still ok. OPERATOR-PLAN.md O.0 checkboxes ticked.	2026-05-24 00:35:01 +02:00