7 de jul. de 2025

Reunião em 7 de jul. de 2025 às 14:21 GMT-03:00

Registros da reunião Transcrição

Resumo

Pedro Ferreira e Guilherme Esteves confirmaram o funcionamento da notificação do botezinho, com Alan Lengruber explicando sua aquisição. Alan Lengruber apresentou o planejamento da V1 do Agent, focada em funcionalidades essenciais e nos "épicos" mapeados, incluindo Fundação de Forms, Agent V1, Experiência de Compartilhamento White Label e Knowledge Base. A Fundação de Forms visa unificar o sistema de gerenciamento de dados na Snack Prompt, abordando a falta de consistência na interface e a limitação de um sistema de input escalável, um problema recorrente para Éder. Pedro Ferreira e Alan Lengruber decidiram pausar a discussão e retomá-la no dia seguinte, pois o tema era complexo e afetava a visualização da edição e a estrutura das tabelas.

Detalhes

Notificação do Botezinho Pedro Ferreira e Guilherme Esteves confirmaram que o botezinho está notificando, com Alan Lengruber explicando que comprou o bot em um aplicativo de licenças vitalícias.
Planejamento da V1 do Agent Alan Lengruber apresentou um planejamento inicial, focado nos "épicos" mapeados para a V1 do Agent, buscando detalhar a parte técnica para estimar esforços e identificar lacunas, especialmente por eles terem uma visão mais abrangente do sistema. A V1 visa oferecer funcionalidades essenciais para aumentar a competitividade no mercado (00:00:50).
Conceito de MVP e Épicos da V1 Alan Lengruber explicou que a V1 não é o "mundo ideal", mas uma versão reduzida focada no que é necessário para vender o produto no mercado, seguindo o conceito de MVP. Ele listou quatro épicos: Fundação de Forms, Agent V1, Experiência de Compartilhamento White Label e Knowledge Base, todos com escopo definido e alguns requisitos não funcionais (00:02:29).
Fundação de Forms e Problemas Identificados A Fundação de Forms visa estabelecer um sistema unificado e escalável para gerenciamento de dados na Snack Prompt. Alan Lengruber destacou a falta de consistência na interface de inserção/edição de dados, um problema recorrente que incomoda Éder, e a limitação de um sistema de input escalável (00:04:54).
Princípios Orientadores da Fundação de Forms Os princípios orientadores para a Fundação de Forms incluem a independência dos dados da visualização, com o item e seus campos como entidade central (00:06:21). Também foi enfatizada a reutilização de componentes para evitar duplicação e garantir consistência na edição e interação, conforme foi reiterado por Éder (00:07:36).
Escopo da V1 da Fundação de Forms O escopo da V1 da Fundação de Forms prevê a criação de uma estrutura de dados com campos customizáveis, começando com apenas dois tipos: "text field" e "link to item" ou "link to list" (00:07:36). Guilherme Esteves explicou que o "link to item" permite adicionar itens dentro de outros itens, expandindo a funcionalidade que antes era exclusiva de listas, tornando os formulários mais flexíveis (00:08:54).
Discussão sobre o "Text Field" Guilherme Esteves esclareceu que o "text field" da V1 não será o campo "template" atual, mas um novo campo que o usuário poderá adicionar ilimitadamente, sem incluir inicialmente outros tipos como data ou dropdown. Pedro Ferreira questionou se a discussão era sobre formulários ou a sessão de widgets, pontuando que o "text field" seria uma célula de texto puro, diferente do "richtext" atual (00:10:00).
Definição do Elemento Principal do Item Pedro Ferreira e Guilherme Esteves discutiram a capacidade de definir um elemento principal para um item, que seria o campo exibido na tabela. A ideia é que o campo "template" seja o principal para documentos, enquanto o "text field" seria usado para entradas simples (00:11:03) (00:16:53).
Estrutura dos Campos de Formulário como Elementos Pedro Ferreira levantou a questão de que cada campo de um formulário seria um elemento, formando uma estrutura de tabela onde cada campo é uma coluna e os itens inseridos seguem o tipo da coluna. Ele exemplificou com a adição de uma nova imagem em uma pasta, que segue a mesma lógica de adicionar um novo "field" no formulário (00:13:36).
Saída dos Dados do Formulário Pedro Ferreira explicou que os dados de saída do formulário gerariam registros de elementos com respostas do tipo "text field". Ele argumentou que seria necessário um "field type" para cada célula, permitindo subtipos para elementos e controlando a criação de células de diferentes tipos, o que abordaria o problema de ter campos HTML em visualizações de texto simples (00:14:40).
Próximos Passos e Dúvidas sobre o Escopo da V1 Alan Lengruber propôs passar para as histórias de usuário para responder às perguntas pendentes. Ele reiterou que o escopo da V1 inclui os dois tipos de campos essenciais, a capacidade de definir um elemento principal para um item e a visualização dos dados em formulário e tabela, mantendo a edição via barra lateral (00:16:53).
Itens Fora do Escopo da V1 Alan Lengruber listou itens fora do escopo da V1, como tipos de campo avançados (rating, multiselect, upload de arquivo, data), lógica condicional em formulários, permissões detalhadas, compartilhamento público de formulários e visualização de dados do formulário como JSON. Pedro Ferreira mencionou que a visualização em JSON já era possível no agent, mas concordou em mantê-la fora do escopo para evitar complexidade na importação (00:17:52).
Criação de Novas Estruturas de Dados e Campos Alan Lengruber apresentou a história de usuário sobre a criação de novas estruturas de dados como formulários, onde adicionar um campo é equivalente a adicionar uma nova coluna em uma tabela (00:19:13). Ele mencionou a discussão sobre o Feed View, que visualizaria cada registro como um formulário para facilitar a edição (00:21:15).
Ambiguidade do Botão de Adicionar Campo/Registro Houve uma discussão sobre a ambiguidade do botão de "+" no formulário, que pode ser interpretado como adicionar um novo campo (coluna) no modo de edição ou um novo registro (linha) no modo de input (00:22:09). Pedro Ferreira e Guilherme Esteves concluíram que, em modo de edição, o botão adicionaria novas colunas que afetariam todos os registros, enquanto no feed view, adicionaria uma nova linha (00:26:41).
Dúvidas sobre o Tipo de Elemento Criado por Novos Campos Pedro Ferreira questionou qual elemento seria gerado ao adicionar um novo campo, já que "text field" e "link to item" são tipos de campo, não elementos (00:30:59). Alan Lengruber sugeriu que o elemento mais próximo seria um "documento", mas Pedro Ferreira apontou que um "documento" é muito grande para dados simples, preferindo uma célula com "content type" para textos simples, evitando formatação HTML (00:32:17).
Disputa sobre a Armazenagem de Campos Simples Pedro Ferreira expressou preocupação de que, ao usar "document" para campos simples, o sistema exibiria HTML em vez de texto puro, gerando inconsistência nas visualizações e problemas com automações (00:33:31). Guilherme Esteves argumentou que o sistema já permite extrair o campo puro para automações, sugerindo manter o "document" para evitar criar algo novo (00:35:33).
Necessidade de Tipos de Célula e Flexibilidade de Campos Pedro Ferreira defendeu a necessidade de um "field type" para as células, permitindo variações de tipo sem criar novos elementos (00:38:27) (00:41:15). Ele argumentou que elementos como "prompt" ou "automation" já definem o tipo de seus campos principais, e essa lógica poderia ser estendida para campos simples, tornando-os variantes do tipo "célula" (00:40:00).
Discussão sobre Mutabilidade de Elementos e Campo Principal Pedro Ferreira argumentou que, se um campo secundário de um elemento pudesse ser definido como o "campo principal", isso implicaria em uma mutabilidade do tipo do elemento, questionando a relevância do tipo base (00:52:13). Guilherme Esteves, por sua vez, sugeriu que a funcionalidade seria apenas para exibir o campo selecionado na tabela, não alterando o tipo fundamental do elemento (00:53:24). Alan Lengruber propôs chamar de "componente destaque" ou "campo destaque" para evitar a conotação de "principal" (00:57:50).
Definição de Campo de Destaque Alan Lengruber e Guilherme Esteves discutiram a definição de um campo de destaque, decidindo que seria um "campo" ao invés de um "componente". Eles concordaram que o elemento principal permaneceria o mesmo, mas teria um campo em destaque, permitindo que o usuário escolha o que destacar, como um prompt, vídeo ou imagem (00:59:12).
Liberdade de Escolha do Usuário Alan Lengruber afirmou que o usuário será livre para decidir o que fazer com o campo em destaque na plataforma, e a equipe fornecerá as ferramentas necessárias (00:59:12). Pedro Ferreira e Guilherme Esteves confirmaram que a exibição de um campo específico, como um vídeo, dependerá da escolha do usuário para aquele elemento (00:59:56).
Visualização e Edição de Formulários Pedro Ferreira e Guilherme Esteves discutiram como a side bar deve se comportar ao editar um campo, sugerindo que ela deve direcionar o usuário para o campo principal destacado (01:01:27). Eles também abordaram a questão de como as alterações no campo principal afetariam a estrutura do formulário, com Guilherme Esteves explicando que seria possível definir o campo principal por coluna ou por item individual (01:02:08).
Impacto no Payload da Tabela Pedro Ferreira expressou preocupação com o tamanho do payload da tabela, pois a nova funcionalidade exigiria que todos os campos fossem incluídos. Guilherme Esteves sugeriu que o backend poderia identificar o campo de destaque e enviar apenas o necessário, evitando o envio de todos os dados (01:04:16).
Validação de Ideias e Escopo Alan Lengruber mencionou que a equipe estava discutindo várias histórias dentro de uma só, e que o escopo deveria ser focado na criação da estrutura do formulário. Guilherme Esteves e Pedro Ferreira debateram a complexidade de adicionar campos customizáveis e alternar entre visualizações de formulário e tabela, o que aumentaria o esforço e o escopo do projeto (01:11:30) (01:14:42).
Estimativa de Esforço Alan Lengruber solicitou uma estimativa de esforço para a tarefa, com Guilherme Esteves sugerindo uma escala de 0 a 10, e Pedro Ferreira mencionando a utilização de pontos de história ou Fibonacci (01:05:53). Alan Lengruber expressou ceticismo em relação a esses métodos, preferindo uma abordagem mais simples de "tamanhos de bicho" para estimar o esforço (01:06:36).
Escala de Tamanhos de Tarefas Alan Lengruber explicou a escala de tamanhos de tarefas baseada em animais (cachorro, camelo, elefante), representando de 1 a 2 dias, 4 dias e 8 dias de trabalho, respectivamente (01:07:21). Luis Nascimento sugeriu usar dias ou horas para estimar, o que Alan Lengruber concordou ser mais adequado para tarefas menores e melhor para definir prazos para o Éder (01:08:01).
Tarefas para a Versão 1 (V1) Guilherme Esteves detalhou duas tarefas principais para a V1: liberar a funcionalidade de adicionar link para itens e destacar o campo principal do item (01:09:29). Ele ressaltou que a tarefa de destaque do campo exigiria uma nova forma de salvar e devolver os dados no front-end (01:10:17).
Discussão sobre a Criação de Formulários Alan Lengruber reiterou a história de usuário sobre a criação de uma nova estrutura de dados que pode ser vista como um formulário (01:11:30). Eles também discutiram a adição de tipos de campos como "text field" (múltiplas linhas) e "link to item" (01:12:40).
Responsabilidades de Back-end e Front-end Alan Lengruber afirmou que o back-end deve tratar os campos customizáveis de forma genérica, enquanto a atualização visual é responsabilidade do front-end. Guilherme Esteves concordou, indicando que a equipe já opera dessa forma (01:13:33).
Alternância entre Visualização de Formulário e Tabela Guilherme Esteves expressou confusão sobre o que aconteceria quando o usuário alternasse entre a visualização de tabela e formulário: se estaria adicionando um registro ou alterando a estrutura da tabela (01:14:42). Alan Lengruber explicou que, ao mudar para o modo de formulário, o usuário veria os registros como formulários preenchidos, e a edição da estrutura seria um modo separado (01:17:55).
Impacto da Alteração na Estrutura Guilherme Esteves e Pedro Ferreira debateram se a alteração da estrutura afetaria todos os usuários. Alan Lengruber confirmou que inserir um novo campo na estrutura afetaria a todos, adicionando um campo vazio aos registros existentes (01:18:52).
Visão de Feed em Modo Formulário Pedro Ferreira explicou que a visualização de feed em modo formulário permitiria editar registros rapidamente. Guilherme Esteves e Pedro Ferreira discutiram a complexidade de exibir diferentes campos principais para cada item nesse modo, dependendo da definição do campo principal por registro ou estrutura (01:19:52).
Remoção de Campos Principais Guilherme Esteves e Pedro Ferreira abordaram a questão de remover um campo principal e o que aconteceria com o campo principal em destaque (01:23:36). Eles concluíram que seria necessário definir uma lógica para determinar qual campo se tornaria o principal caso o campo atual fosse removido (01:24:20).
Prioridade de Custom Fields Guilherme Esteves expressou a preferência de incluir os "custom fields" desde o início para evitar retrabalho. No entanto, Alan Lengruber afirmou que a conversa com Éder prioriza a entrega rápida de uma V1 funcional com um campo de texto sem formatação e um campo "link to item", para que possam colher feedback e então reestruturar para React (01:24:20).
Tabela como Modo de Visualização Pedro Ferreira destacou que a tabela atualmente é um elemento, não um modo de visualização, e que o objetivo do Éder é que ela se torne um modo de visualização (01:25:12). Eles discutiram a possibilidade de visualizar elementos como prompts ou listas no formato de tabela ou formulário (01:26:19).
Impacto na Página Pública e Feed Alan Lengruber esclareceu que, na página pública e no feed, a ideia é que o campo principal definido apareça como a primeira informação visual (01:42:19). Pedro Ferreira apontou que o feed e a página pública não estão preparados para isso, o que adicionaria mais edições ao escopo (01:43:16).
Priorização de Entregas e MVP Alan Lengruber enfatizou a importância de focar no que precisa ser entregue agora, mesmo que isso signifique não ter tudo "pixel perfect" na V1 (01:45:51) (01:50:05). Ele defendeu a filosofia "go fast break things" (vá rápido e quebre coisas), priorizando o lançamento rápido para colher feedback e melhorar o produto iterativamente, comparando com exemplos de sucesso no mercado de criptomoedas como Ethereum versus Cardano (01:46:45).
Preocupação com a Qualidade vs. Velocidade Pedro Ferreira expressou preocupação com a qualidade das entregas, temendo que um lançamento "mal feito" pudesse comprometer a aceitação da ideia no mercado (01:46:45). Alan Lengruber reconheceu a contradição entre velocidade e polimento, e a necessidade de equilibrar esses fatores para a entrega consciente do produto (01:50:05).
Ordem de Implementação das Features Pedro Ferreira sugeriu começar criando formulários a partir de tabelas. Guilherme Esteves, no entanto, argumentou que seria mais eficiente implementar primeiro a funcionalidade de campo de destaque e depois usá-la nos formulários, para evitar retrabalho, pois atualmente o sistema só exibe o template como padrão e a nova funcionalidade permitiria ao usuário escolher o que exibir (01:51:45).
Definição do Campo de Destaque e Implicações Premium Pedro Ferreira e Guilherme Esteves discutiram o campo principal, ou de destaque, e sua relação com elementos premium. Levantou-se a questão de como o template se comportaria se o campo principal fosse uma imagem para um elemento premium, com Guilherme Esteves indicando que o template ainda seria exibido, escondendo apenas o conteúdo premium. Isso levaria à necessidade de reavaliar a segregação de conteúdo pago, mantendo o template visível mesmo para imagens, escondendo apenas o template se for pago (01:53:29).
Escopo e Esforço do Campo de Destaque Alan Lengruber sintetizou que o campo de destaque será implementado inicialmente apenas para a visualização em formato de tabela, sem contemplar feedview ou página pública. O esforço estimado para o front-end é M e para o back-end é P (01:54:26). Guilherme Esteves questionou o tamanho P para o back-end, sugerindo M, levando a uma discussão sobre a diferenciação entre esforço e prazo, com Alan Lengruber enfatizando que os tamanhos (P, M, G) se referem ao esforço em tempo integral para a tarefa (01:56:25).
Localização do Campo Principal no Figma Pedro Ferreira mencionou que não conseguiu encontrar no Figma onde alterar o campo principal na tabela. Guilherme Esteves explicou que o campo não está na tabela em si, mas na seção de componentes, sob o menu (01:55:37).
Definição de Formulário como Estrutura de Dados Pedro Ferreira e Alan Lengruber discutiram a criação de uma nova estrutura de dados visível como formulário, destacando que atualmente não existe um "formulário" na feature definida (02:00:24). Eles questionaram se o formulário deveria considerar apenas campos simples ou todos os campos existentes (02:01:15). Guilherme Esteves esclareceu que o formulário é uma forma de visualização da tabela, não um novo elemento, permitindo que a tabela seja aberta em modo de formulário para exibir colunas combinadas (02:02:15).
Visualização de Elementos em Modo Formulário Pedro Ferreira levantou o problema de como exibir diferentes tipos de dados, como prompts ou imagens, em um formulário, já que o formulário atual só suporta dois tipos de campo (link to e texto) (02:03:58). Alan Lengruber sugeriu restringir a exibição de tipos não preparados para o modo formulário (02:04:41). Pedro Ferreira argumentou que todos os tipos existentes não estão preparados e que o formulário deveria contemplar todos os tipos para permitir a construção de formulários personalizados, mencionando sua experiência anterior com um "engine de form building" (02:06:30).
Desafios da Exibição de Campos no Formulário Pedro Ferreira explicou que exibir um campo do tipo prompt em um formulário requer a visualização com o mesmo componente usado na edição da barra lateral, incluindo tags e formatação (02:04:41). Ele enfatizou a necessidade de trabalhar todos os campos para se encaixarem no formato do formulário, com Guilherme Esteves confirmando que o formulário deveria exibir os campos com seus placeholders (02:09:27).
Formulário: Elemento ou Visualização? Alan Lengruber questionou se o formulário deveria ser um elemento próprio, como uma tabela, onde o usuário pode arrastar e soltar campos (02:10:22) (02:12:56). Pedro Ferreira reiterou que qualquer elemento pode ser visto como uma tabela, e vice-versa, apenas com uma organização diferente, sendo o formulário um "template engine" para facilitar a inserção de dados (02:14:08) (02:17:49). Guilherme Esteves considerou que o formulário é uma forma de visualização de uma tabela (02:24:53).
Formulário e Páginas Públicas Pedro Ferreira destacou a importância de definir como um formulário criado será usado fora do ambiente de edição, especialmente em uma página pública (02:18:58). Ele enfatizou que a página pública do formulário faria os "submites" para a tabela, e que a página pública de uma tabela poderia ser o formulário em si (02:20:06).
Botão de Submit em Formulários Pedro Ferreira afirmou que os formulários devem ter um botão de "submit". Guilherme Esteves e Alan Lengruber concordaram, referindo-se a ele como "formulário intake" ou "página pública" (02:20:06).
Validação de Formulários na Página Pública Pedro Ferreira questionou se a página pública do formulário teria algum tipo de senha ou validação, ou se qualquer usuário autenticado poderia enviar dados. Alan Lengruber respondeu que, na versão inicial (V1), a página seria pública e qualquer um autenticado no Snack Prompt poderia preencher, desde que soubesse o endereço. Guilherme Esteves adicionou que a validação de campos (obrigatórios ou não) ainda não havia sido discutida (02:22:36).
Jornada do Usuário para Criação de Formulários Guilherme Esteves questionou se a criação de um formulário seria aleatória ou se estaria ligada a um "agent" (02:22:36). Alan Lengruber buscou clareza sobre a jornada do usuário para acessar um formulário, e Guilherme Esteves sugeriu que o início seria pelo "agent", ou seja, a ferramenta não seria para criar formulários em si, mas sim para criar "agents" que teriam uma "perna" para formulários (02:23:36).
Formulário como Visualização de Tabela Guilherme Esteves explicou que o formulário é apenas uma forma de visualizar uma tabela, e que se um usuário abrir uma tabela no modo formulário, ela será exibida nesse formato. Alan Lengruber questionou o que aconteceria se a tabela contivesse elementos como prompts, snippets ou imagens ao ser visualizada como formulário (02:24:53).
Exibição de Campos em Modo Formulário Guilherme Esteves reiterou que, no modo formulário, seriam exibidos vários blocos, cada um representando um registro, e que cada bloco mostraria apenas o campo principal de cada célula, e não todos os campos. Pedro Ferreira concordou com a ideia de que o formulário exibiria os campos de forma semelhante ao formulário de edição base, mas destacou que isso está "hardcoded" e precisa ser transformado em um item configurável (02:35:04) (02:43:47).
Campos Principais Padrão para Elementos Guilherme Esteves sugeriu que, se um campo principal não for explicitamente definido para um elemento, um padrão (default) deveria ser estabelecido, como o template para prompts, a imagem para elementos de imagem, e assim por diante (02:41:52) (02:46:08). Leonardo Sola concordou que definir um padrão ao criar os campos não seria difícil, mas o retroativo para os existentes demandaria mais atenção (02:47:17).
Complexidade do Produto para o Usuário Final Alan Lengruber expressou preocupação de que o conceito de formulários e elementos, conforme discutido, estava se tornando muito complexo para o usuário final (02:49:38). Guilherme Esteves defendeu que a complexidade estaria nos bastidores, e que o usuário final veria apenas um formulário simplificado, sem ter que lidar com conceitos como "itens" ou "prompts" diretamente (02:50:31).
Definição de Elementos e Campos Pedro Ferreira e Guilherme Esteves discutiram a confusão em torno da seleção de tipos pré-definidos versus campos para elementos, com Pedro Ferreira propondo que o que chamam de elementos são na verdade "templates de campos" (02:51:41). Eles concordaram que a ideia de templates faria sentido se tivessem todos os campos disponíveis e pudessem criar um prompt ou documento a partir de um template (02:53:41).
Revisão da Estrutura de Campos na Plataforma Pedro Ferreira enfatizou a necessidade de o "form builder" comportar todos os campos existentes na plataforma, incluindo "description" como um campo de texto e a possibilidade de ter "custom fields" em cima de um prompt (02:54:23). Ele visualiza um prompt como uma tabela de "custom fields" e que elementos são estruturas pré-definidas que não podem ter seus campos removidos (02:55:14).
Tabelas e Formulários Pedro Ferreira explicou que um formulário oferece ao usuário a capacidade de criar elementos em seu próprio modelo, sendo a página pública de um formulário semelhante às páginas públicas de elementos existentes, mas com um design mais simples (02:56:41). Ele comparou a plataforma a um CMS (Sistema de Gerenciamento de Conteúdo) com integração de IA, que permite modelar itens, integrar com webhooks e disparar eventos (02:57:37).
Agente e Workflow Pedro Ferreira descreveu o "agent" como uma interface para criar e compartilhar workflows, permitindo aos usuários configurar tabelas de entrada e saída para seus dados (02:58:42). Ele também mencionou a importância de trabalhar com todos os campos, tanto simples quanto complexos, no formulário para dinamizar a estrutura existente (02:59:59).
Desacoplamento de Itens e Edição de Campos Pedro Ferreira argumentou que o título é necessário para todos os elementos devido ao uso de "slug", e que o item precisa de um nome apenas quando desacoplado de uma tabela (03:01:11). Ele sugeriu que a edição de campos simples, como o tipo "rating", poderia ser feita diretamente na célula, sem a necessidade de abrir a barra lateral ("side bar"), para melhorar a usabilidade e reduzir o "payload" (03:07:52).
Desafios e Próximos Passos Alan Lengruber e Pedro Ferreira reconheceram a dificuldade de discutir os épicos, com Pedro Ferreira ressaltando que o primeiro épico é o mais crítico por definir todo o restante e entrar em conflito com a estrutura da plataforma. Eles decidiram pausar a discussão e retomá-la no dia seguinte, pois o tema era complexo e afetava a visualização da edição e a estrutura das tabelas (03:10:42) (03:12:46).

Revise as anotações do Gemini para checar se estão corretas. Confira dicas e saiba como o Gemini faz anotações

Envie feedback sobre o uso do Gemini para criar notas breve pesquisa.

Guilherme Esteves

18 Total Uses

4 Upvotes

0 Followers

5 Avg. Rating

18 Total Uses

4 Upvotes

0 Followers

5 Avg. Rating