O registro de entidades e o portão A

Sexta-feira na Vinco Instalações, cena inventada para a didática deste curso: 23 entidades desenhadas, 61 chaves estrangeiras traçadas, kickoff de desenvolvimento marcado para segunda e três linhas do registro ainda sem dono de escrita. Este capítulo mostra o portão que segura o código até a última linha marcar locked, e a errata que o próprio artigo publica no resumo.

O portão A tem uma única pergunta, e ela cabe em uma frase do paper da Boom Automations, publicado em 17 de agosto de 2026: "No code gets written until every row reads locked." Row é linha de um registro de entidades, e locked é o estado de uma linha cujo caminho de escrita está decidido, escrito e aceito por quem opera.

A tentação de Rita é óbvia: as três linhas pendentes parecem detalhe de configuração, o resto está fechado, e cada semana parada custa dinheiro visível. A conta que ela tem na mão vem do mapa do passo 01, com 58 horas por semana de trabalho manual cronometrado.

Liberar o começo do código com essas três linhas em rascunho produz um estrago maior que o de um atraso: o desenvolvedor precisa de uma decisão para escrever a primeira tela de documentos, então ele decide. Sem registro, a decisão dele mora dentro do código, e ninguém do lado do negócio vai revisar aquilo. Em quatro semanas o campo de medição existe em dois lugares porque duas telas diferentes gravam nele, e a Vinco reconstrói dentro do sistema novo exatamente o problema que estava saindo das planilhas.

Provavelmente você já viveu a versão frustrada disso. Todo projeto de sistema começa com alguma planilha chamada "estrutura de dados", "dicionário" ou "levantamento". Ela nasce em uma reunião animada, recebe uma cor por status, e morre no dia em que o time começa a programar. O motivo é que a planilha não tinha poder de bloqueio. Ela registrava intenção, e intenção perde de prazo toda vez.

O ponto exato em que a sua experiência prévia quebra é este: a planilha antiga tinha coluna de campo, tipo e obrigatoriedade. Ela descia ao nível do atributo e subia pouco ao nível da responsabilidade. O registro de entidades faz o contrário. Ele quase não fala de tipo de dado. Ele responde, por tabela, quem grava, de onde o histórico vem e se aquilo está decidido. É um documento de governança escrito na forma de tabela, não um esboço de banco.

O paper da Boom Automations chama esse artefato de registro de entidades e o publica na Fig. 05, com uma linha por tabela e cinco colunas: TABLE, FOREIGN KEYS, WRITE PATH, MIGRATES FROM e STATUS. As três primeiras colunas descrevem o sistema em regime. As duas últimas existem só durante a construção, e é justamente esse par que transforma o desenho em portão: MIGRATES FROM diz de onde o dado vem do mundo velho, e STATUS diz se aquela linha já pode ser construída.

O exemplo publicado tem cinco linhas, tamanho de demonstração, e nele a forma importa mais que o conteúdo: cada célula é curta e nenhuma delas é opinião.

A linha que ensina mais nesse exemplo é a de faturas. Em quatro das cinco linhas o WRITE PATH é system, ou seja, o sistema operacional novo é a fonte da verdade daquele substantivo. Em invoices o autor escreve outra coisa: "accounting, one-way sync". A contabilidade continua sendo o livro-razão, o sistema novo lê aquele dado e nunca grava de volta, e o registro documenta isso na cara, em uma célula de quatro palavras.

Essa célula é a aplicação da segunda das quatro regras do paper, um caminho de escrita por entidade, no caso mais difícil dela. É fácil manter um caminho único quando o caminho é o seu próprio sistema. A prova de fogo é a entidade que mora em uma ferramenta do balde manter, com peso regulatório e com um contador do outro lado. A tentação é deixar a fatura ser editável nos dois lugares "só para ajustar", e o preço disso o autor escreve sem meias palavras: no momento em que o dado mora em dois lugares, os dois discordam, e no momento em que discordam, o time para de confiar no sistema.

Vale nomear onde esse portão fica na esteira, porque a posição é o argumento. A ordem canônica do corpo do artigo e da Fig. 02 do paper coloca o portão A depois do passo 03, que é o schema, e antes do passo 04, que é consolidar. Isso significa que o portão barra duas coisas ao mesmo tempo: barra código e barra migração. Nada entra no sistema novo, nem uma linha de tela nem um registro histórico, enquanto o registro de entidades tiver rascunho.

Agora a parte deste capítulo que não estava no plano de ninguém, e que é a razão de ele existir separado. O artigo termina com um parágrafo chamado "Where to start this week", um resumo executivo de quatro frases para quem leu de raspão. Esse resumo diz, na ordem: "Map first. Consolidate second. Data model third. Build fourth." Leia de novo com o registro na mão. O resumo manda consolidar em segundo lugar e deixar o modelo de dados em terceiro, quer dizer, manda migrar departamento antes de existir schema, o que apaga o portão A do mapa.

Não tratamos isso como pegadinha de leitura. Tratamos como classe de defeito, e ela aparece em quase todo material de método: o corpo tem a ordem certa porque foi escrito devagar, o fecho tem a ordem cômoda porque foi escrito para caber. A ordem cômoda é sempre a que promete resultado mais cedo. Consolidar antes soa mais rápido, afinal mover gente para um sistema novo parece progresso, enquanto desenhar registro parece papelada.

O hábito que sai daqui vale além deste curso. Quando um documento de método traz uma esteira no corpo e uma recapitulação no fim, compare as duas antes de executar qualquer coisa, e execute a do corpo. O corpo carrega a justificativa de cada passo; o resumo carrega só a sequência. Se as duas divergem, a versão sem justificativa é a que está errada.

Voltemos à sexta-feira da Vinco, e resolvamos o caso do começo ao fim. Rita não tem cinco linhas para fechar, tem 23, porque o registro dela cobre as 23 entidades do passo 03. Vinte delas estão locked desde a quarta. As três pendentes são documentos, tarefas e medição, e cada uma pende por um motivo diferente, o que é típico: rascunho não é um problema só, é a fila dos problemas que o desenho empurrou para depois.

Repare no que o portão A comprou por dois dias de atraso. Comprou a decisão de escrita da medição de obra em documento, e a medição é o workflow mais caro do mapa da Vinco. Comprou também um efeito que só aparece na Parte 4 deste curso: como o paper exige que toda escrita de agente seja validada contra o schema antes de gravar, o registro fechado é o que dá ao agente de entrada de documentos um alvo estável. Registro em rascunho não é atraso de cronograma, é agente sem contrato.

Há um ganho menos óbvio nesse mesmo movimento, e ele é político. Quando Damião percorre a medição com Rita e a frase de escrita sai da boca dele, a decisão deixa de ser imposição de sistema e passa a ser combinado de operação. O paper insiste nesse ponto no passo 01, ao dizer que a versão do fundador e a versão do operador são geralmente dois processos diferentes, e o registro é onde essa diferença aparece por escrito antes de custar retrabalho.

A empresa que fecha o registro sem quem executa costuma descobrir a divergência na semana em paralelo, quando as duas ferramentas rodam juntas e os números não batem. Nessa altura, mudar caminho de escrita significa mexer em tela, em migração e em relatório ao mesmo tempo. No registro, a mesma mudança é uma célula.

O critério de pronto do portão A não é subjetivo, e ele cabe em uma lista verificável. Use a lista abaixo antes de marcar qualquer reunião de início de construção, e trate um item aberto como portão fechado. A régua do paper para o tamanho do artefato ajuda a calibrar: de 15 a 30 entidades no modelo, com 40 a 80 chaves estrangeiras, faixa que a Vinco cumpre com 23 entidades e 61 chaves.

Uma pergunta legítima é o que fazer com o registro depois do portão. Ele não vai para a gaveta. Na fase seguinte, quando um departamento por vez começa a migrar com backfill e semana em paralelo, o registro é a lista de conferência do que precisa chegar íntegro do lado novo. Entidade cuja origem não foi anotada é entidade cuja migração ninguém consegue verificar, e o portão B pede backfill verificado.

Depois, na Parte 4, o mesmo documento vira contrato de máquina. O paper exige que toda escrita de agente seja validada contra o schema antes de gravar e que toda escrita entre em log. Um agente que grava fatura em uma empresa cuja linha de faturas diz "accounting, one-way sync" está violando o registro, e a validação só consegue recusar isso porque a regra existe fora do código. O registro de entidades é a peça mais durável do projeto justamente porque não fala de ferramenta nenhuma, e o paper fecha nessa direção quando afirma que modelos e ferramentas se trocam, e que o mapa, o schema e os portões são a parte que fica.

A síntese retoma a sexta-feira da Vinco. Rita entrou naquele dia com um desenho elegante e um kickoff marcado, e o que faltava eram três decisões de responsabilidade que o desenho tinha empurrado para a fase em que decisão fica invisível dentro do código. O portão A custou dois dias e devolveu a medição de obra, o workflow de 9,5 horas por semana da empresa, com dono de escrita documentado.

Na segunda-feira, o movimento é um só e ele é executável em uma manhã. Abra o seu modelo de dados, escreva uma linha por tabela nas cinco colunas do registro, e marque locked apenas nas linhas cuja frase de escrita você consegue calcular na hora, sem perguntar a ninguém. O que sobrar em draft é a sua pauta da semana, com um dono e uma data por linha. O critério de pronto para liberar construção é literal, e vem do paper: nenhuma linha em rascunho.