# Die Sandbox — deine Entwicklungs- und Testumgebung

*(Quelle: `docs/core/module-developer-sandbox-concept.md` §2–§9, interne LIVE-Infrastrukturdetails entfernt)*

## Was die Sandbox ist

Eine **komplett eigenständige, isolierte Umgebung**, die sich für dich wie die echte Core-API
verhält, aber strukturell nichts mit unseren echten Kundendaten, echten Secrets oder der echten
Datenbank zu tun hat. Ein Sandbox-Zugang funktioniert **nur** gegen die Sandbox — es gibt keinen
Konfigurationsfehler, der dir versehentlich echten Zugriff verschafft, weil es dafür keinen
Netzwerkpfad gibt.

- **Daten:** rein synthetisch (Fake-Mandanten, Fake-Postfächer, Beispiel-E-Mails).
- **KI-Anbindung:** zwei Modi — ein deterministischer Stub (kostenlos, reproduzierbar, Standard)
  oder ein budgetierter Echt-LLM-Testmodus, wenn du die fachliche Qualität deiner
  Prompt-Anbindung prüfen willst (fester Kosten-/Rate-Limit-Deckel pro Account).
- **E-Mail-Versand:** wird nur geloggt simuliert, es geht nie eine echte Mail raus.

## Wie du Zugang bekommst

Nach deiner Freischaltung (siehe [06-submission-review-process.md](06-submission-review-process.md))
wird automatisch eine eigene, isolierte n8n-Instanz für dich bereitgestellt. Du bekommst:

- Ein **eigenes n8n-Login** (eigene URL, nur du siehst deine eigenen Workflows)
- Einen **Sandbox-Core-API-Token** (bereits als Credential in deiner n8n-Instanz vorkonfiguriert)
- Optional **SFTP-Zugang** zu deinem eigenen Workspace (Workflow-Exporte, Paket-Dateien)
- Optional **direkten, read-only Datenbank-Zugriff** auf dein eigenes Fake-Schema — **nur für dich
  persönlich zum Nachschauen während der Entwicklung.** Dein Modul-*Code* nutzt diesen Zugang nie —
  er spricht auch in der Sandbox ausschließlich über die Core-API (`mod/data/*`), damit er in LIVE
  identisch funktioniert.

Alle Zugänge betreffen ausschließlich deine eigene, isolierte Umgebung — du siehst nie Workflows,
Daten oder Dateien eines anderen Entwicklers.

## Was lokal geht, was zwingend in der Sandbox passieren muss

**Lokal, auf deinem eigenen Rechner** (siehe auch die SDK-Dokumentation):
Frontend, `manifest.json`, `db/schema.sql`-Entwurf, lokale Validierung, lokaler Core-API-Mock.

**Zwingend in der Sandbox:**
- Schema/Felder anlegen — du hast keine direkten Schreibrechte auf die Datenbank-Struktur, sondern
  löst über das Portal eine Migration deiner `db/schema.sql` aus, die geprüft und dann angewendet
  wird (nur dein eigenes Schema, keine Core-Tabellen).
- Der eigentliche Automations-Workflow — gebaut, ausgeführt und debuggt direkt im n8n-Canvas
  deiner Sandbox-Instanz, mit echten Ausführungs-Logs.
- Fachliche Prüfung deiner KI-Anbindung (Echt-LLM-Testmodus) — ein lokaler Mock kann nur prüfen,
  ob der Aufruf technisch funktioniert, nicht ob die Antwort inhaltlich sinnvoll ist.

Dein fertiger Workflow wird als JSON exportiert und in dein eigenes Git-Repository
zurückgeführt — du verlierst also keine Versionskontrolle, nur der Bau-/Testvorgang selbst
läuft zwingend in der Sandbox.

## Lifecycle deiner Sandbox

| Zustand | Zeitraum | Was passiert |
|---|---|---|
| Aktiv | solange du eingeloggt bist/arbeitest | voller Zugriff |
| Inaktiv | > 7 Tage ohne Login | pausiert (Daten bleiben erhalten, startet beim nächsten Login neu) |
| Lange inaktiv | > 30 Tage ohne Aktivität | Benachrichtigung: „wird in 7 Tagen gelöscht" |
| Gelöscht | > 37 Tage komplett inaktiv | Sandbox-Daten entfernt, dein Portal-Konto bleibt bestehen |

Weiter mit [08-revenue-share.md](08-revenue-share.md).