Organização

O cliente da plataforma. Uma organização = uma empresa = dois bancos próprios (ent-bancos).

⚠️ Existem duas tabelas chamadas organizations. Esta nota é sobre a do plano de controle. A outra vive dentro de cada app_<org>, tem só id/name/is_active, guarda uma linha (ela mesma) e é a que o mod-organizations usa por engano.

Campos (appstock_core.organizations)

Campo	Papel
id	UUID. O mesmo id é usado dentro do app_<org> — sem de-para.
slug	Único. Vira app_<slug> e sync_<slug>, e é o ?org= das rotas públicas. Padrão: ^[a-z][a-z0-9_]{1,30}$.
name	Nome da empresa.
status	ACTIVE por padrão. Só ACTIVE é resolvível — resolve_org_by_slug e resolve_default_org filtram por ele. É o gancho de suspensão que já existe e ninguém usa.
is_default	Marca a organização que atende rota pública sem ?org=. Hoje: appstock (demo).
branding	JSONB. Escrito nunca, lido nunca. É o gancho para identidade visual e domínio por organização.

Organizações hoje

Slug	Papel
appstock	Demo e padrão. Dados fictícios determinísticos — vitrine e dashboards vivos.
santonio	Cliente em implantação. Vazia, aguardando o sincronizador.

Ciclo de vida

Nasce no passo 1 do flx-onboarding e nunca é apagada por caminho suportado (rewipe_orgs.py existe para desenvolvimento). Não há suspensão, exclusão nem migração entre tiers pela interface.

Buracos conhecidos

• Sem console de operador. Listar, suspender, diagnosticar: só por SQL. Ver mod-organizations.
• status nunca é alterado por código. O mecanismo de suspender inadimplente já existe e está inerte.
• branding morto. O portal público de oferta e prévia sai com a marca AppStock para o cliente final de qualquer organização, e o endereço público é único para toda a instalação.
• Um usuário pertence a uma organização só. O ent-user-directory foi desenhado para suportar multi-org (bastariam mais linhas), mas nada consome isso.