tryaida/aida-demo-data

Was macht aida-demo-data?

Modellstufe: Standard. Das Schreiben eines kleinen Skripts oder einer Sequenz von App-Aktionen erfordert Sorgfalt, ist aber Routine, sobald die Form der Daten aus der Übersichtskarte bekannt ist.

Standardpfad: durch die App selbst

1. Daten, die nur ein Rundgang verwendet (ein zweiter Konkurrent zur Auswahl): seine eigenen setup:-Schritte, in derselben do:/check:/actions:-Grammatik wie steps, werden vor der Aufnahme ausgeführt und nie gefilmt. setup: { as: admin, steps: [...] } meldet sich als eine andere Rolle für diese Schritte an.

2. Startdaten, die mehrere Rundgänge benötigen oder die kein Rundgang hinterlässt („Alex ist im Morgenblock“): ein Konfigurations-states-Eintrag mit Hooks, die über die eigene API der App eingefügt werden (Entscheidung 15), niemals über die Datenbank:

   states: {
     "alex-in-morning": {
       description: "Alex ist im Morgenblock",
       as: "admin",                                  // die eigene angemeldete Sitzung der Hooks
       setup: "./states/alex-in-morning.mjs",        // dessen `setup`-Export, sonst Standard
       check: "./states/alex-in-morning.mjs",        // dessen `check`-Export, sonst Standard
     },
   },
   

   Hooks erhalten ctx.request, einen API-Client, der die angemeldete Sitzung trägt (relative Pfade werden gegen baseUrl aufgelöst), sowie ctx.page, ctx.runId und ctx.env. check gibt true zurück, wenn der Zustand bereits besteht und nichts geändert wird. setup muss idempotent sein („Stelle sicher, dass es so ist“): Es wird bei jeder Aufnahme ausgeführt, die diesen Zustand benötigt, daher kann es zuerst eine Kopie eines früheren Laufs löschen. Ohne as: teilen die Hooks die eigene Sitzung des Rundgangs; ein Hook, der sich über die API anmeldet, benötigt as: auf eine andere Rolle gesetzt, da er sonst die Aufnahme abmeldet.

3. Von Setup erstellte Datensätze, die nicht kollidieren dürfen zwischen Läufen: Benenne sie mit {{run.id}} in den Setup-Daten (ctx.runId in einem Hook). Lasse sie niemals in getippten Text, Erzählungen oder Bildunterschriften gelangen: Screenshots würden sich bei jedem Lauf ändern.

4. Alle Werte folgen references/safety.md: @example.com-E-Mails, reservierte fiktive Telefonnummernbereiche, erfundene Namen. Kopiere niemals einen echten Datensatz, auch nicht mit geänderten Namen, als Ausgangspunkt.

5. Verwende ein dediziertes Demo-Konto oder einen Demo-Arbeitsbereich, wenn die App dies unterstützt, niemals ein Produktionskonto. Der Schnellmodus (keine dedizierte Demo-Umgebung) fragt die Person, bevor etwas gespeichert wird.

Seed-Skripte: nur auf explizite Anfrage eines Entwicklers

• Schreibe ein direktes Datenbank-Seed-Skript nur, wenn ein Entwickler explizit danach fragt (z. B. „Schreibe ein Seed-Skript für die Demo-DB“). Standard-Benutzer und Vibe-Coder erhalten niemals eines – der ganze Sinn ist, dass AIDA keinen Datenbankzugriff benötigt.
• Falls du eines schreibst: Es zielt nur auf eine Datenbank ab, deren eigene Sicherheitsprüfung der Aufnahme akzeptiert (auf diesem Rechner oder einem Zweig, den die Person als Wegwerf-Umgebung benannt hat; aida doctor zeigt welchen); es verwendet dieselben sicheren Demo-Datenwerte und lebt mit den eigenen Seed-Tools der App, nicht innerhalb einer Walkthrough-Datei.

Regeln

• Erstelle niemals Daten als Nebeneffekt eines als schreibgeschützt markierten Schritts in einem Rundgang. Wenn ein Rundgang Setup-Daten benötigt, mache dies explizit (needs, setup:), nicht als versteckten Zustand.
• Füge niemals Aufräumschritte zu einem aufgezeichneten Rundgang hinzu. Ein Rundgang, der Daten entfernt, gibt dies mit clears an; ein erneuter Lauf erhält seine Startdaten von einem idempotenten Setup-Hook oder dem Datenbank-Reset zurück.

Token-Regeln

Siehe references/tokens.md. Klein, gezielt: die Datenform der einen Karte, nicht das gesamte Schema oder die App.