Zentrales Datenmodell

Das Schema von SupaCloud ist umfangreich (200+ Migrationen), aber die Mandanten- und Ressourcen-Grundstruktur ist klein und stabil. Diese Seite dokumentiert diesen Kern; das vollständige DDL liegt in server/migrations/ (siehe den Migrationsindex).

Entitätsbeziehungen

Kern-Datenmodell-ERD: Organisationen besitzen Workspaces und haben organization_members; Workspaces enthalten workspace_members, projects, task_schedules und audit_events; projects enthalten tasks und workflows; tasks erzeugen runs; workflows haben workflow_nodes und workflow_edges und erzeugen ebenfalls runs.

Mandanten

Tabelle	Rolle	Wichtige Spalten
`organizations`	Oberster Mandant — Abrechnung, Seats, SSO, Einladungen	`id`, `slug`, `kind` (`personal`/`team`) — Plan liegt auf `subscriptions` (`organization_id` PK, `plan_id`)
`organization_members`	Einzige Organisations-Mitgliedschaft eines Nutzers	`user_id` (UNIQUE), `organization_id`, `role`, `seat_type_id`
`workspaces`	Ressource-Container des Mandanten (vormals `teams`)	`id`, `slug`, `organization_id`
`workspace_members`	Workspace-Mitgliedschaft	`workspace_id`, `user_id`, `role` (`owner`/`admin`/`member`)

Ein Nutzer gehört genau einer Organisation; die aktive Organisation wird aus dem aktiven Workspace abgeleitet (kein Organisations-Umschalter). Siehe Editionen und Berechtigungen.

Ressourcen

Tabelle	Rolle	Besitzender Scope
`projects`	Ein Repository- bzw. Codebasis-Ziel	`workspace_id`
`tasks`	Ein Agenten-Task	`project_id`
`runs`	Eine erstklassige Ausführung (Task, Workflow, Connector, …)	`workspace_id` + `task_id`/`workflow_id`
`workflows`	Ein Knoten-/Kanten-Orchestrierungsgraph	`project_id`
`workflow_nodes` / `workflow_edges`	Der typisierte Graph	`workflow_id`
`task_schedules`	Cron-/Intervall-Trigger	`workspace_id` (project_id ist eine optionale, nullable Verknüpfung)
`agent_profiles`	Wiederverwendbare Agenten-Konfiguration und Ausführungsmodus	`workspace_id`
`agent_capabilities`	Skills/Tools (`kind='skill'` Markdown)	`workspace_id`

Geheimnisse

Jede Zugangsdaten-Tabelle enthält eine explizite organization_id sowie eine <table>_scope_xor_team_org-CHECK-Bedingung und löst per einheitlicher SQL-Präzedenz auf (ADR 0038). Siehe Geheimnisse verwalten.

Alle fünf Envelope-Tabellen lösen nach der einheitlichen ADR-0038-Präzedenz auf — eine locked-Organisations-Zeile gewinnt org-weit; andernfalls gilt: persönlich (Nutzer) › Workspace › Organisation. Eine Geteilt-vs.-Identität-Aufteilung gibt es nicht mehr.

Tabelle	Präzedenz
`api_key_refs`, `env_vars`, `git_credentials`, `claude_oauth_tokens`, `tracker_oauth_credentials`	persönlich (Nutzer) › Workspace › Organisation (locked Org gewinnt org-weit)

Auditierung

audit_events protokolliert jede Organisations-/Workspace-Mutation (services::audit::record) — Akteur, Aktion, Ziel und ein JSON-Detailblob.