Fase 1 — Onboarding da organização

Objetivo. Uma empresa nova se cadastra, recebe seus bancos, entra no sistema e consegue ligar o ERP dela — sem ninguém de dentro rodar comando nenhum.

É a fatia mais a montante do produto: nada do resto importa se um cliente novo não consegue existir e receber dados. É também a fase que não depende de nenhuma outra — pode começar já.

O que já está de pé

O caminho feliz existe e é real. As duas organizações atuais nasceram dele.

Nota	Tipo	Status
Token do sincronizador	entidade	Parcial
Onboarding da organização	fluxo	Parcial
Primeira carga de dados	fluxo	Parcial
Resolução de tenant	fluxo	Parcial
Organizações (rotas)	modulo	Parcial
Provisionamento de organização	modulo	Parcial
Signup público	modulo	Parcial
Ingestão do sincronizador	modulo	Parcial
Entrar no sistema	tela	Parcial
Criar conta da empresa	tela	Parcial

Leitura recomendada nesta ordem: flx-onboarding → flx-resolucao-tenant → flx-primeira-carga. As decisões que sustentam tudo: adr-001-banco-por-org, adr-002-email-unico-global, adr-003-erp-nunca-ao-vivo.

Mapa visual: Canvas do onboarding (mapa visual — abra no Obsidian).

O que falta

Bloco A — Correções (dias, sem dependência)

Cada uma remove uma mentira de tela ou um beco sem saída. Nenhuma precisa de decisão.

• Alinhar a validação de senha do formulário (6) com a da API (8) tela-signup P
• Permitir retry de provisionamento incompleto: consultar provisioning_log em vez de barrar pelo slug mod-signup P
• Corrigir as 3 entidades do contrato que não têm app_id e respondem 422 mod-sync-ingest P
• Fazer o heartbeat gravar execução em app_sync_control mod-sync-ingest P
• Recuperação de senha (“esqueci minha senha”) tela-login P
• Consertar ou remover decommission_legacy.py — está quebrado e executa DROP DATABASE antes de estourar mod-provision P
• Checagem de slug disponível enquanto se digita tela-signup P
• Campo de organização no login, ou remover o parâmetro da API tela-login P
• Identificador da organização embutido nos links públicos (oferta e prévia abrem 404 fora da demo) flx-resolucao-tenant P

Bloco B — Destravar o cliente novo

Sem isto, quem se cadastra recebe uma organização que não tem como ser integrada.

• Emitir, listar e revogar o token do sincronizador (endpoint autenticado + tela) ent-sync-token M
• Ingestão das 19 tabelas de faturamento, notas fiscais, títulos e dimensões mod-sync-ingest M
• Cursores por entidade + marca d’água + reconciliação contra o ERP flx-primeira-carga M
• Painel real de sincronização, substituindo o mockup de /settings/sync/erp flx-primeira-carga G
• Página de Integração no portal: catálogo de entidades campo a campo, views do kit para copiar, documentação das APIs, token e estado das cargas G
• Neutralizar o contrato do espelho — tirar as chaves metadata->>'…__c' herdadas do CRM de origem, inclusive de dentro do sync_template.sql adr-003-erp-nunca-ao-vivo G

Bloco C — Plataforma

O que sustenta operar mais de um cliente sem susto.

• Migrations versionadas do appstock_core (hoje nasce por create_all) mod-provision P
• Validar a sessão gravada a cada request — hoje logout não invalida o token tela-login P
• Decidir o destino de modules/organizations: apagar, virar console do operador, ou virar console da organização mod-organizations M
• Fazer org_modules realmente gatear os módulos (hoje é gravado e nunca lido) mod-provision M
• Provisionamento assíncrono com tela de progresso flx-onboarding M
• Verificação de e-mail e limite de tentativas por IP no signup mod-signup M
• Rotina de aplicar migrations em todas as organizações (consequência direta de adr-001-banco-por-org) M
• Backup por organização, healthchecks no compose e observabilidade M
• Identidade visual e domínio por organização (a coluna branding existe e nunca é lida) ent-organizacao P

Decisões pendentes (suas)

1. modules/organizations — apagar ou repontar? Repontar para o core resolve mais lacunas de uma vez (destrava org_modules e dá visibilidade a provisionamento incompleto).
2. Signup público continua público? Se o modelo de venda é com implantação assistida, metade do Bloco C (verificação de e-mail, limite por IP, progresso) perde urgência e o CLI basta.
3. Qual o primeiro ERP do kit? O Bloco B fica muito mais concreto ancorado num alvo real — a implantação da santonio é o candidato natural.

Critério de aceite

Uma empresa nova, sem ninguém de dentro tocar em terminal:

1. Se cadastra e entra no sistema.
2. Encontra sozinha o token e a documentação de integração no portal.
3. Faz a primeira carga e vê na tela o que entrou, quando e o que falhou.
4. Abre um link público de oferta que funciona na organização dela.