tryaida/aida-demo-data

Que fait aida-demo-data ?

Niveau de modèle : standard. Écrire un petit script ou une séquence d'actions dans l'application demande de l'attention, mais c'est routinier une fois que la forme des données est connue depuis la fiche de description.

Chemin par défaut : via l'application elle-même

1. Données utilisées par une seule visite (un second concurrent à choisir) : ses propres étapes setup:, dans la même grammaire do:/check:/actions: que les steps, exécutées avant la capture et jamais filmées. setup: { as: admin, steps: [...] } se connecte sous un autre rôle pour elles.

2. Données de départ nécessaires à plusieurs visites, ou qu'aucune visite ne laisse (« Alex est dans le créneau du matin ») : une entrée states dans la configuration avec des hooks, insérée via l'API de l'application (décision 15), jamais la base de données :

   states: {
     "alex-in-morning": {
       description: "Alex est dans le créneau du matin",
       as: "admin",                                  // la session connectée des hooks
       setup: "./states/alex-in-morning.mjs",        // son export `setup`, sinon défaut
       check: "./states/alex-in-morning.mjs",        // son export `check`, sinon défaut
     },
   },
   

   Les hooks reçoivent ctx.request, un client API portant la session connectée (les chemins relatifs sont résolus par rapport à baseUrl), ainsi que ctx.page, ctx.runId et ctx.env. check renvoie true lorsque l'état existe déjà et ne change rien. setup doit être idempotent (« s'assurer que c'est le cas ») : il s'exécute à chaque capture qui a besoin de l'état, il peut donc d'abord supprimer une copie d'une exécution précédente. Sans as:, les hooks partagent la session de la visite elle-même ; un hook qui se connecte via l'API a besoin de as: défini sur un rôle différent, sinon il déconnecte l'enregistrement.

3. Données créées par le setup qui ne doivent pas entrer en collision entre les exécutions : nommez-les avec {{run.id}} dans les données du setup (ctx.runId dans un hook). Ne laissez jamais ces données apparaître dans le texte tapé, la narration ou les légendes : les captures d'écran changeraient à chaque exécution.

4. Toutes les valeurs suivent references/safety.md : e-mails @example.com, numéros de téléphone fictifs réservés, noms inventés. Ne copiez jamais un enregistrement réel, même avec des noms modifiés, comme point de départ.

5. Utilisez un compte ou un espace de travail de démonstration dédié lorsque l'application le permet, jamais un compte de production. Le mode rapide (pas d'environnement de démo dédié) demande à la personne avant d'enregistrer quoi que ce soit.

Scripts d'initialisation : uniquement sur demande explicite d'un ingénieur

• Écrivez un script d'initialisation directe en base de données uniquement lorsqu'un ingénieur le demande par son nom (par exemple « écris un script d'initialisation pour la base de démo »). Les utilisateurs par défaut et les « vibe coders » n'en reçoivent jamais — tout l'intérêt est qu'AIDA n'a pas besoin d'accès à la base de données.
• Si vous en écrivez un : il cible uniquement une base de données que le contrôle de sécurité d'une capture accepte (sur cette machine, ou une branche que la personne a nommée comme jetable ; aida doctor montre laquelle), il utilise les mêmes valeurs de données de démo sécurisées, et il réside avec les outils d'initialisation de l'application, pas dans un fichier de visite.

Règles

• Ne créez jamais de données comme effet secondaire d'une étape marquée en lecture seule dans une visite. Si une visite a besoin de données de configuration, rendez cela explicite (needs, setup:), pas comme un état caché.
• N'ajoutez jamais d'étapes de nettoyage à une visite enregistrée. Une visite qui supprime des données le dit avec clears ; une ré-exécution retrouve ses données de départ à partir d'un hook de configuration idempotent ou d'une réinitialisation de la base de données.

Règles pour les jetons

Voir references/tokens.md. Petit et ciblé : la forme des données de la fiche, pas tout le schéma ou l'application.