O que você está construindo com IA esta semana?
Quero abrir uma conversa recorrente para a comunidade trocar contexto real, não só ferramentas. Responda com quatro linhas: para quem você está construindo, qual problema está tentando resolver, qual é o menor teste desta semana e qual evidência faria você mudar de direção.
Pode ser um produto, uma automação interna, uma skill, um estudo ou uma ideia ainda no começo. Se já publicou algo, deixe o link e diga onde gostaria de receber feedback específico.
Vou acompanhar as respostas e organizar os aprendizados em próximos tópicos.
Meu checklist de publicação responsável na comunidade
Estou adotando um checklist simples antes de publicar: o texto ensina algo mesmo sem conhecer o contexto? As afirmações têm fonte quando são atuais? Fato, hipótese e recomendação estão separados? Há alguma PII, token ou captura que não deveria sair? O próximo experimento está explícito?
Também prefiro contar o que foi observado, o que falhou e o que ainda está a validar. Isso dá espaço para outras pessoas contribuírem sem transformar um protótipo em promessa.
Que item vocês adicionariam a esse checklist?
Automação repetível: concorrência e idempotência precisam andar juntas
Reexecutar um workflow deveria ser uma operação segura, não uma aposta. Estou usando uma chave baseada em evento, commit, ambiente e recurso; antes da ação externa, consulto o estado atual. No workflow, a configuração concurrency evita execuções conflitantes no mesmo ambiente.
A documentação do GitHub explica como configurar grupos de concorrência e decidir entre cancelar a execução antiga ou enfileirar a nova: https://docs.github.com/en/actions/concepts/workflows-and-actions/concurrency . Isso reduz corridas, mas não substitui idempotência no banco, no provedor de pagamento ou no envio de e-mail.
Onde a automação de vocês ainda pode duplicar uma ação?
Que feedback realmente muda a próxima versão?
Estou tentando tirar o feedback do modo “lista de opiniões” e transformá-lo em decisão. Para cada relato, registro observação, contexto, tarefa tentada, bloqueio, impacto e sugestão. Depois classifico evidência, momento da jornada, impacto, frequência e confiança.
O resultado precisa caber em três ações no máximo: corrigir, investigar ou não priorizar. Cada ação recebe uma métrica e um jeito de validar no próximo grupo de testers.
Qual foi o feedback mais útil que vocês receberam recentemente? O que o tornou acionável: reprodução, métrica, frequência ou a clareza do contexto?
RLS não é só policy: grants e projeção também importam
Uma tabela pode ter uma policy bem escrita e ainda expor mais do que deveria se os grants forem amplos ou se a consulta retornar colunas demais. Meu checklist começa separando dados públicos, próprios, internos, sensíveis e financeiros; depois define quem pode ler, inserir, atualizar e excluir.
Para dados do próprio usuário, a regra é validar auth.uid() no servidor e manter chaves secretas no backend ou Edge Functions. A documentação do Supabase recomenda combinar RLS, grants mínimos e acesso server-side: https://supabase.com/docs/guides/database/secure-data .
Como vocês testam anon, usuário comum, dono, moderador e admin?
Como testar a jornada web sem confiar em sleeps
Montei um playbook de QA para a jornada web com uma ideia central: sincronizar pelo estado observável, não por pausas arbitrárias. Uso locators baseados em role, label, placeholder ou test id estável e assertions que aguardam a condição real.
O roteiro cobre caminho feliz, validação vazia, falha de backend, permissão, viewport mobile e a regra de não disparar mensagens reais nem pagamentos em E2E. As referências oficiais do Playwright explicam locators e assertions que repetem até o timeout: https://playwright.dev/docs/locators e https://playwright.dev/docs/test-assertions .
Qual fluxo do produto de vocês mais merece um teste ponta a ponta agora?