# BuilderLab: do aprendizado individual a um fluxo de trabalho de engenharia compartilhado HTML canônico: https://dsti.school/pt/techblog/builderlab-fluxo-engenharia-compartilhado Esta versão em português brasileiro é gerada pelo mesmo build do site estático da DSTI que a página HTML canônica. Ela se destina à leitura por máquinas e à consulta concisa. [DSTI TechBlog](https://dsti.school/pt/techblog) / Estudantes Estudantes Engenharia de software na prática Beta ao vivo Estou construindo o BuilderLab para examinar um problema prático de aprendizado: como os alunos podem passar de exercícios isolados para as restrições sociais, técnicas e operacionais de entregar software com outras pessoas? RM Por Richie Mouhouadi Estudante do MSc in Data Science & AI na DSTI no momento da publicação Junho de 2026 · 12 min de leitura · BuilderLab v0.5.0 ![Interface do BuilderLab mostrando um fluxo de trabalho de projeto colaborativo](https://dsti.school/assets/dsti-techblog-builderlab.7de28cb47f.png) ## Uma plataforma organizada em torno do ciclo de vida do projeto A versão beta atual conecta descoberta, formação de equipes, coordenação de projetos e um registro público do progresso. Algumas funções de revisão permanecem planejadas em vez de implementadas. Núcleo Encontre colaboradores HiveOS Organize a entrega HiveCheck Revise o trabalho ## Neste artigo 01 — Um problema testável 02 — Ciclo de vida do produto 03 — Arquitetura de aplicativos 04 — Modelo de domínio e estado 05 — Limites de confiança 06 — Aprendendo por meio da manutenção 07 — Evidências e próximos experimentos 08 — Evidência aberta O BuilderLab começou com uma observação simples: a forma atual de aprender não reflete a dinâmica real depois da contratação. Projetos individuais ou tutoriais raramente reproduzem as condições de entrega em equipe. O BuilderLab é, portanto, uma tentativa de reduzir a distância entre aprendizagem e trabalho. O BuilderLab trata essa experiência de equipe perdida como um problema de produto, em vez de outro exercício isolado. Ele permite que os alunos proponham projetos, encontrem colaboradores, coordenem o trabalho, mantenham um registro de construção e exponham o suficiente do processo para que outra pessoa entenda como o resultado foi alcançado — não apenas a aparência da interface final. O método por trás disso é deliberadamente iterativo: declarar um problema , implementar uma solução restrita , observar suas fragilidades e decidir o que testar em seguida. O BuilderLab é útil para mim justamente porque não está concluído. ## 01 A lacuna de colaboração é um problema de engenharia testável Os alunos podem praticar SQL, Git, Linux, implantação em nuvem ou apenas uma linguagem de programação. As partes difíceis da engenharia profissional geralmente estão em outros lugares: negociar o escopo, dividir responsabilidades, lidar com divergências, documentar decisões, se recuperar de bloqueios e manter um sistema compartilhado após seu primeiro lançamento. Lacuna de aprendizado ### Conhecer uma ferramenta não é o mesmo que trabalhar em equipe Um tutorial individual pode ensinar sintaxe e APIs. Ele não pode reproduzir totalmente a propriedade, as transferências, o controle de acesso ou as consequências da mudança de outra pessoa. Lacuna de evidências ### A captura de tela final esconde a maior parte do trabalho Uma página de projeto pode preservar marcos, atualizações, bloqueadores, decisões, colaboradores e feedback para que o caminho até o resultado permaneça inspecionável. Uma vez contratados como engenheiros, trabalhamos com outras pessoas todos os dias. O BuilderLab transforma esse fato comum na restrição organizacional do produto. Etapa 1 Observe Identifique um problema recorrente de aprendizado ou colaboração. Etapa 2 modelo Traduza o problema em funções, estados e transições. Etapa 3 Implementar Crie o menor fluxo coerente e exponha-o ao uso real. Etapa 4 Revise Registre falhas, estreite limites e defina o próximo experimento. ## 02 Três camadas de produto acompanham um projeto, da ideia à análise O produto é dividido em três camadas conectadas. Eu uso a separação para manter problemas distintos visíveis, em vez de escondê-los por trás de uma ideia ampla de “colaboração”. Camada 01 Núcleo do BuilderLab Perfis, ideias de projetos, descobertas, solicitações de participação, associação à equipe, seguidores e páginas públicas do projeto. Ao vivo Camada 02 HiveOS Tarefas, marcos, bate-papo em equipe e atualizações do Build Log dentro do espaço de trabalho do projeto. Ao vivo/em evolução Camada 03 HiveCheck Um índice de projetos concluídos está ativo; as avaliações estruturadas por pares e seu método de pontuação permanecem planejados. Parcialmente ao vivo/planejado O ciclo de vida pretendido é mais do que a correspondência de projetos. Uma solicitação pode se tornar associação; a associação abre um espaço de trabalho; transições de tarefas selecionadas podem criar entradas públicas no Build Log; a conclusão do projeto pode levar à classificação de colaboradores; e um projeto concluído pode permanecer disponível como prova. Cada etapa exige uma transição de estado explícita em vez de apenas uma nova tela. ## 03 O aplicativo separa a descoberta pública do trabalho autenticado O repositório atual usa o Next.js App Router com TypeScript. Os grupos de rotas separam a superfície pública do espaço de trabalho do aplicativo sem alterar os URLs públicos. Os componentes do servidor obtêm os dados iniciais da página; os componentes do cliente lidam com formulários, filtros, modais, bate-papo, alterações de tarefas e atualizações otimistas da interface. Grupo de rotas públicas Página inicial, visão, documentação e contato. Grupo de rotas de aplicativos Feed, perfis, projetos, conexões, notificações e HiveCheck. Manipuladores de rotas Retorno de chamada de autenticação, envio de contato e notificações selecionadas. Limite do servidor Next.js Os componentes do servidor buscam dados e renderizam o HTML inicial. Limite do cliente React O estado interativo permanece em componentes focados no cliente. Supabase PostgreSQL Projetos, perfis, associações, tarefas e registros de projetos. Autenticação Supabase + RLS Sessões baseadas em cookies e políticas de acesso em nível de banco de dados. Resend + Vercel E-mail transacional e implantação do aplicativo Next.js. O fluxo de página típico é um componente de servidor lendo linhas e contexto de identidade antes de entregar o resultado a um componente cliente para interação. Isso é visível nos fluxos de feed e detalhes do projeto. Página do servidor app/(app)/feed/page.tsx buscar projetos + usuário atual Estado do cliente components/Feed.tsx pesquisa, filtros, contexto de propriedade Interação ProjectCard + InterestModal participe de solicitações e siga as ações ## 04 O modelo de dados acompanha a vida social e técnica de um projeto A decisão de modelagem mais importante foi evitar tratar um projeto apenas como um título e uma descrição. O BuilderLab representa identidade, descoberta, formação de equipe, execução, conclusão e feedback como preocupações relacionadas, mas diferentes. Identidade e capacidade profiles user_skills builder_type institution program Descoberta e formação de equipe projects project_skills connections project_members project_followers Registro de execução milestones tasks project_updates project_messages Conclusão e feedback ratings project_comments notifications contact_messages Uma conexão é uma solicitação, não uma associação. Um seguidor pode inspecionar seções restritas do projeto, mas não pode atuar como membro. Um membro pode sair sem desaparecer do registro histórico. Uma tarefa pode ser atribuída, bloqueada ou vinculada a um marco. Uma atualização pública é diferente de uma mensagem de equipe. Essas distinções tornam a ideia do produto visível no esquema e fornecem às políticas de acesso algo preciso para aplicar. Transição controlada pelo banco de dados. Quando uma conexão muda de `pending` para `accepted`, um gatilho PostgreSQL insere o remetente em `project_members`. A transição é atômica e não depende de um cliente realizar com êxito uma segunda solicitação. ## 05 Os limites de confiança devem sobreviver a uma chamada direta à API Autenticação não é o mesmo que autorização. Ocultar um botão pode guiar o usuário, mas não pode proteger um banco de dados. Para os fluxos abaixo, a interface e Row Level Security do PostgreSQL compartilham a responsabilidade: a interface apresenta as ações válidas, enquanto as políticas de banco de dados rejeitam operações fora da função do usuário autenticado. ### Q1 Quem pode mudar uma tarefa? O proprietário do projeto pode criar, modificar ou excluir qualquer tarefa. O proprietário pode delegar a função de gerente do HiveOS a um membro ativo por vez, dando a essa pessoa os mesmos direitos de gerenciamento de tarefas. Um membro regular pode atualizar o status de uma tarefa atribuída a ele. A política verifica as identidades do proprietário, do gerente e do destinatário no nível do banco de dados. Limitação atual: o banco de dados controla quem pode atualizar uma tarefa atribuída, mas o conjunto detalhado de transições de status permitidas ainda é amplamente orientado pela interface. Uma política de transição mais rigorosa reduziria a confiança remanescente no comportamento do cliente. ### Q2 Como uma solicitação aceita se torna membro? Uma solicitação começa como uma linha em `connections`. Depois que o proprietário a aceita, um gatilho PostgreSQL cria a linha ativa em `project_members`, com proteção contra conflitos. Isso mantém a aceitação e a associação consistentes, mesmo que um chamador ignore a interface. ### Q3 O que acontece quando um membro sai? A saída voluntária e a remoção pelo proprietário exigem um motivo de 10 a 300 caracteres. A linha de associação muda para `left` em vez de ser excluída, o requisito de avaliação é removido, o acesso às funções exclusivas da equipe é revogado e as tarefas restantes deixam de estar atribuídas. O motivo não é mostrado à equipe em geral. A especificação atual também expõe um caso de limpeza: se o membro que saiu foi o HiveOS Manager, a bandeira do gerente pode permanecer armazenada mesmo que o membro não tenha mais acesso. Automatizar essa limpeza é uma próxima alteração razoável no banco de dados. ### Q4 Quais seções do projeto são públicas? As seções de marcos, Build Log, bate-papo da equipe e membros têm, cada uma, um controle independente administrado pelo proprietário e são públicas por padrão. Quando restritas, permanecem visíveis para o proprietário, membros ativos e seguidores. Os seguidores, portanto, formam um nível de confiança intermediário: podem consultar mais contexto, mas não podem publicar atualizações, conversar nem usar o HiveOS. Isso significa que “privado” atualmente significa restrito a um público definido do projeto, não visível apenas para a equipe ativa. O texto e a interface precisam manter essa distinção clara. ### Q5 Como as notificações são enviadas sem expor os endereços de e-mail? As notificações por e-mail e no aplicativo são criadas por manipuladores de rotas no servidor, com a chave de função de serviço do Supabase, que nunca é enviada ao navegador. O roteador lê o e-mail do destinatário no servidor, envia a mensagem por meio de Resend e cria uma notificação no aplicativo. Por meio do RLS, cada linha de notificação só pode ser lida pelo destinatário previsto. Manter a chave do lado do servidor é necessário, mas não suficiente. Essas rotas devem continuar obtendo verificação explícita do chamador e do fluxo de trabalho, validação de entrada, limitação de taxa e registro operacional. ### Q6 Como a documentação permanece alinhada com o banco de dados? Atualmente, o alinhamento depende da disciplina e não de uma prova automatizada. Eu aplico cada migração a um projeto Supabase de desenvolvimento, atualizo a documentação do banco de dados imediatamente, registro a alteração do produto no changelog e confirmo a migração, a documentação e o código do aplicativo juntos. Esse é o limite mais fraco do processo atual, porque nada demonstra automaticamente que a documentação corresponde ao esquema ativo. A introspecção do esquema e a comparação automática com a documentação são os próximos experimentos naturais. ## 06 Um produto ao vivo transforma aulas em mudanças no método A base de código cresceu enquanto eu aprendia. Isso aparece em recursos úteis, mas também em arquivos que se tornaram grandes demais, um histórico de migração que ainda não oferece um caminho reproduzível completo, consultas ao bate-papo da equipe a cada cinco segundos e um antigo guia de início rápido que menciona arquivos de configuração SQL ausentes do pacote fornecido. Os testes são o exemplo mais claro de uma mudança de método. Eu não comecei o BuilderLab com uma estratégia de testes automatizados. Isso foi um descuido. Durante uma aula de MLOps, o conselho de introduzir testes cedo, em vez de acrescentá-los depois que o sistema se torna difícil de alterar, tornou mais claro o custo dessa decisão. Desde então, escrevi uma estratégia de testes no ramo de desenvolvimento. É um começo, ainda não uma suíte automatizada completa nem um gate de integração contínua. Estou adotando uma abordagem semelhante para a infraestrutura. Eu poderia corrigir imediatamente o antigo guia de início rápido em SQL, mas a direção pretendida é um ambiente declarativo construído com Terraform. Prefiro estabelecer esse processo depois de estudar os conceitos relevantes e então substituir de uma só vez o caminho de configuração obsoleto, em vez de atualizar instruções que já espero descartar. Construir em público deve incluir mudanças no processo. A evidência útil não é apenas uma lista de recursos completos. Também inclui um descuido reconhecido, a lição que mudou minha abordagem, a correção parcial agora em desenvolvimento e um plano testável para a próxima versão. ## 07 O que a versão beta demonstra — e o que eu testaria a seguir ### Evidência atual - As rotas públicas e autenticadas são separadas sem alterar a estrutura do URL externo. - Os clientes Supabase de servidor, navegador e função de serviço representam diferentes limites de confiança. - O modelo de domínio distingue solicitações, seguidores, membros, proprietários, gerentes, tarefas, marcos, atualizações, bate-papos e classificações. - O HiveOS transforma eventos de tarefas selecionados em evidências do Build Log sem publicar todas as ações internas. - Os gatilhos do banco de dados protegem transições importantes, como a criação de perfil e a aceitação de solicitações de associação. - O produto é implantado como uma versão beta ao vivo com documentação pública e código-fonte. ### Restrições conhecidas - O histórico de migração deve se tornar a fonte da verdade reproduzível do esquema atual. - Vários componentes interativos precisam ser decompostos antes de se tornarem mais difíceis de testar e manter. - A consulta periódica do bate-papo da equipe deve ser substituída ou tornada incremental à medida que o uso aumenta. - A estratégia de teste deve se tornar testes executáveis e um gate automatizado. - O guia de início rápido deve ser substituído por um caminho de provisionamento declarativo, em vez de receber correções indefinidamente. - O alinhamento entre documentação e esquema ainda precisa de uma verificação automática. Testes de política O proprietário do exercício, o gerente, o responsável, o seguidor e as chamadas de API não autorizadas de acordo com as políticas de RLS. Testes de transição Verifique as solicitações aceitas, as saídas, a desatribuição de tarefas e a limpeza do gerente à medida que o estado do banco de dados muda. Testes de rota de notificação Verifique a identidade do chamador, o estado esperado do fluxo de trabalho, o isolamento do destinatário e o comportamento de falha antes de enviar o e-mail. Verificação de desvio do esquema Faça uma introspecção do esquema de desenvolvimento e compare-o com as migrações e a documentação gerada. Ambiente declarativo Use Terraform para tornar a configuração de desenvolvimento repetível e desative o guia obsoleto de início rápido em SQL. Entrega de bate-papo medida Compare a entrega em tempo real ou incremental com a consulta atual a cada cinco segundos, sob um nível realista de atividade. Nenhuma dessas etapas é valiosa simplesmente porque usa outra ferramenta. Cada uma deve responder a uma pergunta específica: a política rejeita o ator errado, o ambiente pode ser reproduzido, a documentação detecta desvios ou um novo mecanismo de mensagens reduz as leituras sem enfraquecer a entrega? O valor educacional do BuilderLab não é que todas as decisões arquitetônicas sejam concluídas. É que o projeto me dá um lugar para praticar formação de equipe , modelagem de estados , controle de acesso , testes , entrega e manutenção como um sistema conectado. ## 08 Evidência aberta O BuilderLab continua sendo uma versão beta ao vivo. Os links abaixo apresentam o produto, a documentação para usuários e o repositório do código-fonte, permitindo verificar as afirmações deste artigo em vez de aceitá-las apenas com base na descrição. [Beta ao vivo Interface atual do produto e acesso ao aplicativo.](https://builderlab-tau.vercel.app/) [Documentação do usuário Criação de projetos, funções, HiveOS e fluxo de trabalho previsto.](https://builderlab-tau.vercel.app/docs) [Repositório do código-fonte Estrutura do aplicativo, notas de arquitetura, documentação do banco de dados e registro de alterações.](https://github.com/rdmouhouadi/BuilderLab) [Richie Mouhouadi Estudante do MSc in Data Science & AI na DSTI e autor do BuilderLab.](https://www.linkedin.com/in/richie-mouhouadi/) --- © DSTI School of Engineering 2026 - Todos os direitos reservados. Instituição privada de ensino superior - V350 - 2 de agosto de 2026