Signup público

modules/signup — cadastro público da empresa

Módulo de um arquivo só. É a casca pública sobre o mod-provision: valida a entrada, garante que o slug está livre, delega o trabalho pesado e traduz falha em código HTTP.

Contrato

POST /signup   → 201 { org_id, slug }

Sem autenticação. Sem Depends(get_db) — não há organização a resolver ainda.

Campo	Regra da API	Regra da tela
company_name	2–150 caracteres	obrigatório
slug	2–31 + ^[a-z][a-z0-9_]{1,30}$	mesmo padrão, com sugestão automática
admin_name	2–150 caracteres	obrigatório
admin_email	regex simples, normalizado para minúsculas sem espaços	type=email
admin_password	mínimo 8	mínimo 6 ⚠️

⚠️ A divergência de senha é real e visível para o usuário — ver tela-signup.

Respostas de erro

Código	Quando
409 slug já utilizado	Guarda explícita antes de provisionar (consulta o core).
409 e-mail do admin já cadastrado na plataforma	ValueError vindo do mod-provision — o e-mail já está no ent-user-directory.
500 falha no provisionamento	Qualquer outra exceção. Logada com logger.exception e o slug.
422	Validação do Pydantic (é onde a senha curta cai).

Decisão registrada no código

O ent-sync-token não sai na resposta. O comentário em route_signup.py:68 diz que “o admin o emite/consulta autenticado” — a intenção é certa (não vazar credencial de integração num endpoint público), mas o endpoint autenticado nunca foi construído. Hoje é um beco: o token existe, ninguém consegue lê-lo.

Estado real

O módulo em si é pequeno e correto. Os problemas são de superfície pública:

• Sem verificação de e-mail e sem limite por IP. Endpoint anônimo que cria bancos.
• Síncrono. Ver flx-onboarding.
• A guarda de slug impede o retry. A checagem de route_signup.py:53 é feita antes de provisionar, então um provisionamento interrompido deixa o slug ocupado e a pessoa presa. O provisioning_log já sabe quais passos completaram — falta consultá-lo aqui.

Lacunas

Rastreadas na fase-1-onboarding.