tryaida/aida-demo-data

¿Qué hace aida-demo-data?

Nivel de modelo: estándar. Escribir un script pequeño o una secuencia de acciones de la aplicación requiere cuidado, pero es rutinario una vez que se conoce la forma de los datos a partir de la tarjeta de esquema.

Ruta predeterminada: a través de la propia aplicación

1. Datos que solo usa un recorrido (un segundo competidor para elegir): sus propios pasos setup:, en la misma gramática do:/check:/actions: que steps, se ejecutan antes de la captura y nunca se filman. setup: { as: admin, steps: [...] } inicia sesión como otro rol para ellos.

2. Datos iniciales que necesitan varios recorridos, o que ningún recorrido deja ("Alex está en el bloque de la mañana"): una entrada states de configuración con hooks, insertada a través de la propia API de la aplicación (decisión 15), nunca la base de datos:

   states: {
     "alex-in-morning": {
       description: "Alex está en el bloque de la mañana",
       as: "admin",                                  // la sesión iniciada de los propios hooks
       setup: "./states/alex-in-morning.mjs",        // su exportación `setup`, si no, por defecto
       check: "./states/alex-in-morning.mjs",        // su exportación `check`, si no, por defecto
     },
   },
   

   Los hooks reciben ctx.request, un cliente API que lleva la sesión iniciada (las rutas relativas se resuelven contra baseUrl), además de ctx.page, ctx.runId y ctx.env. check devuelve verdadero cuando el estado ya se cumple y no cambia nada. setup debe ser idempotente ("asegurarse de que sea así"): se ejecuta en cada captura que necesita el estado, por lo que primero puede eliminar una copia de una ejecución anterior. Sin as:, los hooks comparten la sesión del propio recorrido; un hook que inicia sesión a través de la API necesita as: configurado con un rol diferente, o cerrará la sesión de la grabación.

3. Registros que el setup crea y que no deben colisionar entre ejecuciones: nómbralos con {{run.id}} en los datos de setup (ctx.runId en un hook). Nunca permitas que llegue a texto escrito, narración o subtítulos: las capturas de pantalla cambiarían en cada ejecución.

4. Todos los valores siguen references/safety.md: correos @example.com, rangos telefónicos ficticios reservados, nombres inventados. Nunca copies un registro real, ni siquiera con nombres cambiados, como punto de partida.

5. Utiliza una cuenta o espacio de trabajo demo dedicado donde la aplicación lo admita, nunca una cuenta de producción. El modo rápido (sin entorno demo dedicado) pregunta a la persona antes de guardar cualquier cosa.

Scripts de semilla: solo bajo solicitud explícita de un ingeniero

• Escribe un script de semilla directo a la base de datos solo cuando un ingeniero lo solicite por su nombre (por ejemplo, "escribe un script de semilla para la base de datos demo"). Los usuarios predeterminados y los codificadores de "vibe" nunca obtienen uno — el punto clave es que AIDA no necesita acceso a la base de datos.
• Si escribes uno: debe estar dirigido solo a una base de datos que la comprobación de seguridad de la propia captura acepte (en esta máquina, o una rama que la persona haya nombrado como desechable; aida doctor muestra cuál), utiliza los mismos valores demo seguros, y reside dentro de las herramientas de semilla de la propia aplicación, no dentro de un archivo de recorrido.

Reglas

• Nunca crees datos como efecto secundario de un paso marcado como solo lectura en un recorrido. Si un recorrido necesita datos de configuración, hazlo explícito (needs, setup:), no como estado oculto.
• Nunca agregues pasos de limpieza a un recorrido grabado. Un recorrido que elimina datos lo indica con clears; una re-ejecución recupera sus datos iniciales desde un hook de configuración idempotente o el reinicio de la base de datos.

Reglas de tokens

Consulta references/tokens.md. Pequeño y específico: la forma de datos de la tarjeta única, no todo el esquema o la aplicación.