02-modelo-dominio.md.django-simple-history.pgvector pra busca semântica (do APE-Especialista).Uma equipe expandida
para a tranquilidade regulatória.
Da estrutura dos dados à cadência de entrega. Em ordem: a intuição, a estrutura que emerge, e como cada peça do sistema responde a uma parte do que ficou no email.
"Meu propósito é criar uma empresa em parceria com uma pessoa experta em tecnologia que me permita oferecer soluções reais e confiáveis pra empresas que permitam crescer em escala."
"Além de um parceiro tecnológico, um experto em comunicação, em operações industriais, em finanças. Mas vamos pouco a pouco construindo essa visão."
"Este é o primeiro projeto que quero desenvolver juntos pra trazer uma solução real, pra um cliente real, que vai servir como base do nosso processo de aprendizado."
Este deck é a resposta a esse email. Tudo o que vem a seguir se justifica contra o que você desenhou — quando algo se descolar dali, é discutido, não silenciosamente assumido.
Preservadas como você escreveu. A estrutura interna do sistema cresceu em cima delas — mas no dia-a-dia operacional, ninguém precisa pensar em termos das quatro etapas. Elas são o contrato com o email, não o organograma de execução.
Quando o sistema estiver operando, esse 85 vira 15-25 — só Tier 1 (externalização) e amostras Tier 2 chegam à Paula. É o KPI de adoção da equipe expandida: se passar de 40/dia consistente, o sistema está sobrecarregando em vez de aliviar.
A planilha-mãe — colunas, linhas, status, datas, responsáveis — já é um modelo de dados. Falta tirar do XLSX e botar em banco que agrega, audita e versiona.
"Banco de dados é só coluna e linha."
Alê · Reunião 003
Não estamos reinventando o trabalho da Paula — estamos materializando o modelo mental dela em um banco que faz o que a planilha não faz: agregar (sem fórmulas frágeis), auditar (cada mudança rastreada), versionar (histórico nunca some), e deixar várias pessoas trabalharem ao mesmo tempo.
Escritório (MOA) └─ Cliente (TMG · futuros) └─ Filial (CNPJ · município · atividade) └─ Demanda (recursiva · polimórfica) └─ Sub-demanda (mesma entidade · recursão livre) └─ ... sem limite estrutural
Cada nível existe pra resolver uma pergunta operacional real: filial pra responder "em qual CNPJ está esta licença?"; Demanda pra responder "o que eu acompanho?"; sub-demanda pra responder "essa licença depende de qual outra?"
(Insight do Alê na Reunião 003 — preservado verbatim no modelo.)
Cada peça é um campo do banco. Cada Demanda no sistema preenche as cinco.
Tradução prática: quando a Paula precisa adicionar um novo órgão fiscalizador ou um novo tipo de licença, ela vai num painel de configuração e adiciona. Sem chamada pro programador, sem deploy, sem esperar.
Vocabulário herdado verbatim da Paula. "Renovação" substitui "Vencida" — escolha diplomática preservada (Paula evita assustar diretor TMG na apresentação). Sub-estado contextual entra como texto livre: "Renovação · Aguardando CLCB Sorriso".
"Se uma licença não está ativa mas tem 10 e-mails registrados, isso é o suficiente para a MOA."
Rafa, citando o critério da Paula · Reunião 003
Histórico é a coleção cronológica de uma Demanda; Andamento é o item individual — um evento atômico. Vocabulário herdado da Paula: "vou vir aqui em Andamentos e vou colocar..."
Cada e-mail, ligação, visita, protocolo vira um Andamento estruturado — tipo, autor (humano ou APE), data, payload.
Motor central que serializa toda mudança crítica. Auditoria automática. APE e humano usam o mesmo mecanismo.
agregado_id serializa por Demanda. Eventos da mesma Demanda em fila FIFO; Demandas diferentes em paralelo. Sem race conditions. Retry idempotente.
Andamento que registra um fato (e-mail recebido, ligação realizada) é criado automaticamente. A classificação enriquecida ou a próxima ação proposta vai pra Fila de Revisão.
Cliente vê o registro do fato em tempo real · humano valida a interpretação
Hoje a Paula mantém 4-5 arquivos manualmente — planilha de licenças, planilha de etapas, arquivo de resumo, gráficos mensais. No sistema, ela alimenta apenas a base. O resto sobe sozinho.
Em apresentação ao cliente: "você não vê só o que aconteceu — vê quem decidiu, quando, com base em quê, e quanto tempo levou pra acontecer."
Promoção Sombra → Operacional é manual, após métricas: ≥75% das sugestões teriam sido aprovadas + ≥50 sugestões + 0 incidentes graves. Daniela ou Paula apertam o botão. V1 inicia 100% com humanos operando — APE entra na Onda 5.
Cada verbo é uma view materializada no banco + uma tela específica. O Scanner (APE-Mapeador) não é a tela inicial — fica num botão "Adicionar cliente / Agregar demandas".
A informação do MOA é o ativo do MOA. O sistema é desenhado pra que perder informação — ou não saber o que aconteceu — seja tecnicamente improvável.
Implicação: a Onda 4 não trava por isso — construo na minha infra de testes. Mas antes da TMG entrar em produção, precisamos fechar essas quatro peças.
Após a Onda 7, o sistema está em produção operando todos os módulos. Não há "fase 2" planejada — evolução posterior é manutenção + melhoria contínua.
Revisão crítica na semana 6 da Onda 4: se foundation não vai fechar até a semana 8, corta feature — não estende prazo. Timebox rígido por onda.
A planilha vira banco.
O cliente passa a ver o dado vivo.
O operador opera num lugar só.
Os APEs entram como colegas internos.
Quatro entregas concretas · Projeto MOA
"Vamos pouco a pouco construindo essa visão" — sua frase, do email original. A cadência das sete ondas honra isso: sem prometer mais do que o cronograma comporta, sem entregar menos do que o cliente precisa.