Atualização de 16 de outubro: a primeira implantação em UAT e novas etapas de aceitação já ocorreram. Este texto preserva o estado de 7 de outubro; veja o progresso atual e as pendências.
O que foi entregue
Em 7 de outubro concluímos uma nova etapa de desenvolvimento da autenticação e da autorização do Kulinaryos. As alterações coordenadas da API Go, do app, do CRM, do ADM e do FIC GARA foram incorporadas aos repositórios de UAT. Os cinco pipelines concluíram com sucesso e publicaram imagens imutáveis. A existência de cada imagem e seu digest foi confirmada no registro.
Essa etapa ainda não foi implantada em UAT nem promovida para PROD. A publicação das imagens prepara a entrega, mas a consolidação de ponta a ponta depende da migração revisada, da implantação via GitOps e dos testes autenticados no ambiente. Este post dá continuidade ao registro de 3 de outubro, que tratou do login e da recuperação já publicados naquela ocasião.
Uma pessoa, permissões explícitas
A nova implementação usa o identificador interno da pessoa e o vínculo com a identidade emitida pelo ZITADEL. O e-mail é um contato que pode mudar; licenças, participação em organizações e poderes administrativos seguem vínculos explícitos com a pessoa. Trocar o contato ou escolher outro método de login não transfere esses direitos.
O cadastro de uma pessoa também cria seu perfil no CRM na mesma transação. O CRM registra a origem comercial e o ciclo das licenças; a API Go verifica os direitos atuais a cada requisição. O acesso considera organização, módulo, situação e validade. Quando os direitos não podem ser confirmados, o acesso é negado.
Login, recuperação e sessões
App, CRM, ADM e FIC receberam fluxos coordenados de Google via ZITADEL e de vínculo pelo próprio titular. O vínculo automático exige as comprovações de contato previstas pela política. Quando os contatos diferem, o titular pode demonstrar a posse da conta existente, sem uma fila de aprovações individuais.
As sessões usam cookies protegidos e validação de revogação no servidor. A saída e a recuperação de senha atualizam o estado da sessão; a recuperação considera o contato atual e links de uso único. Os testes também cobrem operações concorrentes de troca de contato e senha. Brevo continua sendo o serviço de e-mail transacional.
Licenças e delegações
A emissão passou a exigir uma autorização com escopo explícito: beneficiário, produto, país, prazo e limite de emissão. Delegações, emissão e revogação deixam registros de auditoria. Os caminhos comerciais verificam a confirmação necessária antes de ativar direitos; um pagamento pendente não basta para liberar o produto.
Suspensão, expiração e revogação são verificadas durante o uso. A interface acompanha a decisão da API, inclusive quando uma sessão já está aberta. A proposta de infraestrutura restringe as origens de UAT e inclui o FIC nas verificações de promoção e de imagens.
Evidência desta etapa
- O harness da API, com PostgreSQL descartável, OIDC sintético e captura de e-mail, passou 1.624 testes para o código de UAT e 1.607 para o código preparado para PROD, sem falhas nem testes ignorados. Os testes sintéticos não comprovam entrega real pelo Google ou pelo Brevo.
- Os checks, testes e builds locais dos frontends de UAT passaram: 1.264 testes no app, 61 no CRM, 55 no ADM e 98 no FIC. Os pipelines de publicação também concluíram com sucesso.
- Os preflights somente de leitura inventariaram os ambientes atuais. Renderização, schema dos manifests e verificações de arquitetura passaram para a proposta de infraestrutura. As sondagens públicas comprovaram saúde e negação de acesso anônimo; não comprovam a matriz autenticada.
O que falta para concluir
A próxima etapa é revisar os vínculos administrativos por UUID, as associações de equipe e a reconciliação das licenças existentes. Depois vêm a migração autorizada de UAT e a promoção das cinco imagens por GitOps, com coordenadas de rollback registradas.
Com as versões implantadas, a aceitação deve exercitar contas controladas: senha, Google real, vínculo do titular, recuperação entregue pelo Brevo, delegação, emissão, suspensão e revogação. Também deve provar a negação entre organizações e módulos, e o comportamento de app, CRM, ADM e FIC para a mesma pessoa com poderes diferentes. A preparação do código de PROD permanece separada de qualquer implantação em produção.