Multi tenant o que é no vibe coding: 1 e-mail, várias escolas

Jhonatan descreveu o cadastro das escolas com a regra de hoje: o usuário só pode ter escola quando o e-mail já pertence a uma, tenta entrar na escola B, o sistema bloqueia e a conta já é vinculada. O plano dele é criar o vínculo, cadastrar o e-mail na escola nova e deixar a pessoa escolher.

Ele falou o estado e o próximo passo no mesmo fôlego:

Hoje o usuário só pode ter escola quando e-mail já pertence a escola, tenta entrar na escola B, o sistema bloqueia e a conta já é vinculado. Então v criar a tabela de vínculos, manter a escola atual.

Tenta a escola B, o sistema bloqueia

Ter escola, na regra de hoje, depende de o e-mail já pertencer a uma escola. Ele falou isso como o estado atual do cadastro: o endereço já pertence e a conta já é vinculada.

A pessoa tenta entrar na escola B e o sistema bloqueia. Escola B é o nome que ele deu a essa tentativa. O sistema bloqueia porque a conta já é vinculada. Vale ver como isso terminou em produto escalavel.

O botão Criar conta e a página de cadastro são outro furo da mesma live. Aqui o ponto é o e-mail que já pertence a uma escola e não entra na escola B.

Criar a tabela de vínculos, manter a escola atual

O plano vem na sequência da fala: criar a tabela de vínculos e manter a escola atual. Na fala, o então liga o bloqueio à tabela. Criar a tabela de vínculos é o que ele pede depois do estado de hoje. Manter a escola atual vem na mesma frase. O e-mail e a escola atual ficam. O que ele pede de novo é a tabela de vínculos, e a escola nova entra nesse vínculo.

Isolamento e auditoria entre empresas é outra conversa.

Depois do cadastro, a lista para escolher a escola

Ele pediu o plano ao modelo com o caso já montado:

nós vamos agora desenvolver para caso aquele e-mail já tenha cadastrado em outra escola, vai aparecer para ele igual para admin e para ele escolher qual escola ele quer acessar. Então ele vai ser cadastrado numa nova escola e vai aparecer para ele qual escola ele quer acessar depois que ele fazer o cadastro, independente da maneira. Me diga se entendeu e qual vai ser o plano para isso.

Ele abriu com "nós vamos agora desenvolver": o trabalho ainda vai começar, e o caso que ele quer no código é o e-mail que já tenha cadastrado em outra escola.

Nesse caso vai aparecer para ele igual para admin, para escolher qual escola acessar. Ele disse a escolha 2 vezes, uma junto do igual para admin e outra depois do cadastro: o e-mail vai ser cadastrado numa nova escola e aparece qual escola ele quer acessar, independente da maneira.

"Igual para admin" é o jeito que ele descreveu a lista. O usuário vê as escolas e escolhe qual acessar depois que fizer o cadastro, independente da maneira. Isso aparece também em macbook air m1 para programar.

O pedido fecha pedindo ao modelo se entendeu e qual vai ser o plano. O caso já está na frase: e-mail cadastrado em outra escola, cadastro na nova, e a lista para escolher depois.

No vibe coding, o pedido já traz o caso

No vibe coding ele entrega o bloqueio da escola B e pede a tabela de vínculos com a escola atual mantida. O pedido que ele fez ao modelo foi a tabela de vínculos e a escolha da escola depois do cadastro. "Me diga se entendeu e qual vai ser o plano para isso" devolve a bola ao modelo com a escola B, o vínculo e a escolha já ditos. Isso aparece também em multi tenancy. O mesmo problema apareceu em multi agent.

Esse é o jeito do vibe coding quando o e-mail já pertence a uma escola. Você descreve o que acontece se o mesmo e-mail tenta a escola B.

Amanhã entre com o e-mail que já pertence a uma escola e tente a escola B. O bloqueio ainda é a regra de hoje.

Quem quiser ouvir o bloqueio e o plano no ar pode assistir à live.