developer-rules/07-sandbox-usage.md

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) 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.