tryaida/aida-demo-data

O que aida-demo-data faz?

Nível do modelo: padrão. Escrever um pequeno script ou uma sequência de ações do aplicativo exige cuidado, mas é rotineiro uma vez que a forma dos dados é conhecida a partir do cartão de esboço.

Caminho padrão: através do próprio aplicativo

1. Dados usados por apenas um walkthrough (um segundo concorrente para escolher): seus próprios passos setup:, na mesma gramática do:/check:/actions: que os steps, executados antes da captura e nunca filmados. setup: { as: admin, steps: [...] } faz login como outra função para eles.

2. Dados iniciais que vários walkthroughs precisam, ou que nenhum walkthrough deixa ("Alex está no bloco da manhã"): uma entrada states na configuração com hooks, colocados através da própria API do aplicativo (decisão 15), nunca no banco de dados:

   states: {
     "alex-in-morning": {
       description: "Alex está no bloco da manhã",
       as: "admin",                                  // a sessão autenticada dos próprios hooks
       setup: "./states/alex-in-morning.mjs",        // sua exportação `setup`, senão padrão
       check: "./states/alex-in-morning.mjs",        // sua exportação `check`, senão padrão
     },
   },
   

   Os hooks recebem ctx.request, um cliente de API que carrega a sessão autenticada (caminhos relativos resolvem contra baseUrl), além de ctx.page, ctx.runId e ctx.env. check retorna verdadeiro se o estado já existir e não altera nada. setup deve ser idempotente ("garanta que seja assim"): ele executa em toda captura que precisa do estado, então pode primeiro excluir uma cópia de execução anterior. Sem as: os hooks compartilham a sessão do próprio walkthrough; um hook que faz login através da API precisa ter as: definido para uma função diferente, ou ele desconecta a gravação.

3. Registros que o setup cria e que não devem colidir entre execuções: nomeie-os com {{run.id}} nos dados de setup (ctx.runId em um hook). Nunca deixe que isso apareça em texto digitado, narração ou legendas: as capturas de tela mudariam a cada execução.

4. Todos os valores seguem references/safety.md: emails @example.com, números de telefone fictícios reservados, nomes inventados. Nunca copie um registro real, mesmo com nomes alterados, como ponto de partida.

5. Use uma conta ou workspace de demonstração dedicado, onde o aplicativo suportar um, nunca uma conta de produção. O modo rápido (sem ambiente de demonstração dedicado) pergunta à pessoa antes de salvar qualquer coisa.

Scripts de seed: somente sob solicitação explícita de um engenheiro

• Escreva um script de seed direto no banco de dados somente quando um engenheiro solicitar um pelo nome (por exemplo, "escreva um script de seed para o banco de dados de demonstração"). Usuários padrão e codificadores de vibe nunca recebem um — o objetivo é que a AIDA não precise de acesso ao banco de dados.
• Se você escrever um: ele tem como alvo apenas a verificação de segurança de uma captura de banco de dados que aceita (nesta máquina, ou um branch que a pessoa nomeou como descartável; aida doctor mostra qual), ele usa os mesmos valores seguros de dados de demonstração, e vive com as próprias ferramentas de seed do aplicativo, não dentro de um arquivo de walkthrough.

Regras

• Nunca crie dados como efeito colateral de um passo marcado como somente leitura em um walkthrough. Se um walkthrough precisar de dados de configuração, torne isso explícito (needs, setup:), nunca um estado oculto.
• Nunca adicione passos de limpeza a um walkthrough gravado. Um walkthrough que remove dados diz isso com clears; uma reexecução recupera seus dados iniciais de um hook de setup idempotente ou da reinicialização do banco de dados.

Regras de token

Veja references/tokens.md. Pequeno e direcionado: a forma dos dados de um único cartão, não todo o esquema ou aplicativo.