Acesso ao banco PostgreSQL para construtores de apps com IA

Um construtor de apps com IA pode se conectar a um banco PostgreSQL existente sem ser proprietário do esquema, mas isso só funciona se esse limite existir de fato no PostgreSQL. Um prompt dizendo «não altere a produção» não é um controle. Uma função separada, padrões de transação, revisão explícita de migrações e verificações de esquema são controles.

O modelo seguro divide o trabalho no banco em três frentes. A descoberta lê metadados e amostras de dados permitidos. A aplicação lê e grava apenas nas tabelas e operações de que precisa. A alteração de esquema passa por uma identidade de migração separada, depois que uma pessoa aprova o SQL exato. Já vi equipes juntar essas frentes em uma única credencial conveniente de proprietário e depois descobrir que um agente tratou um nome de coluna plausível como permissão para redesenhar uma tabela em uso. A conveniência durou uma tarde, a limpeza levou muito mais tempo.

A descoberta deve ser somente leitura por construção

Uma conexão de descoberta precisa de acesso suficiente para entender o esquema permitido, não para melhorá-lo. Crie uma função de login que não possa criar bancos ou funções, não possa ignorar a segurança em nível de linha e não possa herdar privilégios inesperados de um grupo amplo. O PostgreSQL já cria novas funções sem esses poderes, mas declarações explícitas tornam a intenção revisável.

CREATE ROLE app_discovery
  LOGIN
  NOSUPERUSER
  NOCREATEDB
  NOCREATEROLE
  NOINHERIT
  NOBYPASSRLS
  CONNECTION LIMIT 3
  PASSWORD 'replace-through-secret-manager';

ALTER ROLE app_discovery SET default_transaction_read_only = on;
GRANT CONNECT ON DATABASE customer_portal TO app_discovery;
GRANT USAGE ON SCHEMA app TO app_discovery;
GRANT SELECT ON ALL TABLES IN SCHEMA app TO app_discovery;

default_transaction_read_only bloqueia gravações comuns em sessões que mantêm o padrão. É uma proteção extra, não a base da segurança. A ausência de INSERT, UPDATE, DELETE, TRUNCATE, CREATE e propriedade é o que mantém a função limitada se um cliente alterar sua configuração de transação. Não conceda à função participação em um grupo proprietário da aplicação e não a torne proprietária de um esquema.

As permissões existentes merecem inspeção antes de o construtor se conectar. A consulta a seguir produz uma linha por privilégio de tabela, para que um revisor detecte qualquer coisa além de SELECT:

SELECT table_schema, table_name, privilege_type
FROM information_schema.role_table_grants
WHERE grantee = 'app_discovery'
ORDER BY table_schema, table_name, privilege_type;

Um resultado saudável tem formato como app | invoices | SELECT. Um resultado vazio pode indicar que a descoberta não enxerga uma tabela necessária; uma linha terminando em UPDATE indica que a função tem poder demais. Verifique também os privilégios de esquema com has_schema_privilege e os privilégios de banco com has_database_privilege, pois permissões de tabela não mostram se a função pode criar objetos em outro lugar.

Não use um snapshot de produção como desculpa para compartilhar uma credencial de proprietário. Uma cópia ainda pode conter dados de clientes, e um agente com propriedade pode alterá-la tanto que comparações posteriores deixam de servir. Dê à descoberta uma identidade dedicada em cada ambiente.

A inspeção do catálogo deve ficar dentro de uma lista permitida

O construtor deve descobrir somente esquemas aprovados e registrar o que o PostgreSQL realmente informa. information_schema oferece visões portáveis de tabelas, colunas, restrições e privilégios. pg_catalog expõe detalhes do PostgreSQL, como índices, tipos, expressões geradas e segurança em nível de linha. Ambos são fontes melhores que a memória de uma LLM sobre uma tabela típica de clientes.

Comece com uma lista permitida, como app e reporting. Rejeite pg_catalog, information_schema, esquemas temporários, esquemas de extensões e todo esquema de locatário que não esteja na lista como destino da aplicação. A consulta deve filtrar nos níveis de banco, função e SQL. Uma lista permitida somente no prompt pode desaparecer em uma conversa posterior.

SELECT
  c.table_schema,
  c.table_name,
  c.ordinal_position,
  c.column_name,
  c.data_type,
  c.is_nullable,
  c.column_default
FROM information_schema.columns AS c
WHERE c.table_schema IN ('app', 'reporting')
ORDER BY c.table_schema, c.table_name, c.ordinal_position;

Armazene o resultado como um snapshot do esquema, com horário de obtenção e identificador do banco. O snapshot comprova o que o gerador viu. Ele não é uma verdade permanente. O PostgreSQL pode mudar entre a descoberta e a geração de código, então compare uma impressão digital atual antes da implantação. Uma impressão digital prática pode gerar um hash de descrições ordenadas de tabelas, colunas, tipos, nulidade, padrões, restrições e índices. Se a impressão diferir, pare e redescubra, em vez de supor qual mudança é inofensiva.

Amostragem de linhas é uma decisão de permissão separada. Metadados de colunas raramente contêm dados pessoais, enquanto amostras de linhas muitas vezes contêm. Prefira não amostrar linhas para gerar código. Se exemplos forem necessários, exponha uma visão que remova ou masque segredos e identificadores diretos, e conceda SELECT apenas nessa visão. LIMIT 10 não torna uma consulta sensível segura, apenas reduz o vazamento.

O caminho de pesquisa merece o mesmo tratamento. Defina-o para o esquema aprovado mais pg_catalog, qualifique os nomes de tabela gerados e nunca dependa do objeto que o PostgreSQL resolver primeiro. Um invasor ou uma migração descuidada pode criar um objeto com o mesmo nome em um esquema gravável. Nomes qualificados, como app.orders, removem essa ambiguidade.

A função de execução deve corresponder às ações reais do usuário

Descoberta e execução são trabalhos diferentes. A aplicação em execução pode precisar inserir um pedido, atualizar um rascunho ou chamar uma função cuidadosamente projetada, mas isso não justifica acesso amplo de gravação por todo o esquema descoberto. Monte uma matriz de permissões a partir das ações do usuário e traduza cada ação na menor permissão PostgreSQL possível.

Por exemplo, quem visualiza faturas pode precisar de SELECT em app.invoices e app.invoice_lines, enquanto um recurso de notas precisa de SELECT e INSERT em app.invoice_notes. Provavelmente não precisa de DELETE em faturas, acesso a registros de redefinição de senha ou criação de esquema. Conceda uso de sequências somente quando uma inserção realmente depender daquela sequência. O PostgreSQL trata sequências como objetos separados, o que surpreende geradores testados com uma conta proprietária.

Visões e funções podem reduzir ainda mais a superfície. Uma visão pode expor colunas aprovadas e ocultar campos internos. Uma função SECURITY DEFINER pode realizar uma operação controlada que permissões comuns não conseguem expressar, mas precisa de um search_path fixo, validação rigorosa de entradas e um proprietário sem poderes desnecessários. Trate essa função como código privilegiado, não como atalho para contornar o modelo de permissões.

A segurança em nível de linha cria um limite de dados dentro de uma tabela compartilhada. Ela não substitui permissões de tabela. O PostgreSQL primeiro verifica se a função pode executar a operação e depois aplica políticas de linha quando estão ativadas e são aplicáveis. Teste com a função exata de execução, pois proprietários de tabela e funções com BYPASSRLS podem escapar das políticas. Um teste com o proprietário de migração quase nada prova sobre o que um usuário final pode ver.

Mantenha segredos fora de prompts, código-fonte gerado, pacotes do navegador, logs de compilação e capturas de tela. Guarde a credencial de execução no armazenamento de segredos do ambiente de hospedagem e injete-a apenas no processo do servidor. Aplicações móveis e de navegador não conseguem manter uma senha PostgreSQL secreta, então devem chamar uma API de servidor, não se conectar diretamente. Faça a rotação das credenciais de descoberta, execução e migração de forma independente. Um vazamento em uma frente não deve abrir as outras duas.

O poder de migração pertence a um caminho de aprovação separado

Um construtor de apps pode propor migrações, mas não deve executá-las com sua sessão de descoberta ou execução. Dê ao trabalho de migração uma função separada ou deixe um sistema de implantação estabelecido assumir essa função em um único trabalho aprovado. Mantenha a credencial indisponível em sessões normais de conversa e prévia.

A aprovação deve cobrir o SQL exato, a identidade do banco de destino, a impressão digital do esquema usada para prepará-lo e o comportamento esperado de bloqueio ou reescrita. Aprovar uma frase em linguagem natural como «adicionar status do cliente» deixa margem demais. A mudança executável pode adicionar uma coluna de texto anulável, reconstruir uma tabela grande, inventar um enum ou atualizar todas as linhas existentes. São operações diferentes, com modos de falha diferentes.

Uso um pacote compacto de migração:

1. O motivo da mudança e a versão da aplicação que a exige.
2. O SQL exato de avanço e, quando for honesto, o SQL exato de reversão.
3. Objetos, privilégios e linhas que os comandos podem afetar.
4. Consultas de pré-verificação, resultados esperados e uma nova impressão digital do esquema.
5. Tempo limite de bloqueio, tempo limite de instrução, referência do backup ou snapshot e responsável pela liberação.

Um script de reversão nem sempre desfaz uma migração. Remover uma coluna recém-adicionada pode reverter a mudança de catálogo, mas também destrói dados gravados após a liberação. O DDL transacional do PostgreSQL ajuda em muitas operações de catálogo, mas uma transação não restaura efeitos externos ou dados que um comando posterior excluiu. Identifique claramente reversões destrutivas, em vez de tratar DOWN como uma palavra mágica.

Defina lock_timeout para que uma migração falhe em vez de esperar atrás de uma transação ocupada enquanto bloqueia novos trabalhos. Defina statement_timeout de acordo com a operação revisada. Execute novamente as consultas de pré-verificação dentro da janela de mudança. Se o tamanho da tabela, objetos conflitantes, contagem de nulos ou impressão digital do esquema diferirem das premissas aprovadas, interrompa. O agente deve retornar um relatório de incompatibilidade, não improvisar uma nova migração em produção.

Nunca aprove automaticamente uma migração porque os testes gerados passaram. Em geral, os testes rodam em um esquema pequeno e limpo e não detectam filas de bloqueio, nulos antigos, restrições incomuns, extensões e versões da aplicação ainda atendendo tráfego. A aprovação é o momento em que uma pessoa concilia a intenção gerada com o sistema ativo.

O pool de conexões muda o cálculo de segurança

Um pool reutiliza sessões de banco, portanto o estado da sessão pode sobreviver à solicitação que o criou. Se uma solicitação executa SET search_path, muda uma função, cria um objeto temporário ou desativa um tempo limite, o próximo usuário da conexão pode herdar o resultado. A aplicação deve evitar estado de sessão mutável ou redefini-lo de forma confiável quando uma conexão volta ao pool.

O pool de transações torna o limite mais rígido. Um cliente pode receber uma sessão de servidor diferente após cada transação, o que quebra premissas sobre instruções preparadas da sessão, tabelas temporárias, bloqueios consultivos e configurações no nível da sessão. Construtores costumam gerar código que funciona por conexão direta e falha atrás de um pool porque não modelaram essa diferença. Decida se o pool usa modo de sessão ou de transação e inclua esse modo na geração e nos testes.

Planeje as conexões antes da implantação. Comece pelas conexões permitidas pelo banco, reserve capacidade para administração, migrações, monitoramento e outros serviços e divida o restante entre as instâncias da aplicação. Se dez instâncias abrirem vinte conexões cada, o PostgreSQL verá duzentas sessões potenciais mesmo com pouco tráfego. Um pool pequeno e conservador com fila costuma ser mais seguro que multiplicar conexões até que o banco as recuse.

Use tempos limite no servidor como proteção: statement_timeout limita instruções longas, lock_timeout limita esperas por bloqueios e idle_in_transaction_session_timeout remove sessões que mantêm uma transação aberta sem fazer nada. Defina valores para cada função, em vez de confiar que cada cliente gerado se lembrará deles. Verifique-os com SHOW usando a função real e por meio do pool real.

As verificações de integridade devem ser baratas. SELECT 1 confirma uma ida e volta, mas não confirma que a aplicação alcança uma tabela aprovada ou que seu caminho de pesquisa está correto. Uma verificação de prontidão pode consultar uma visão pequena e estável com a função de execução. Mantenha migrações fora da inicialização da aplicação. Instâncias simultâneas disputando para alterar o esquema criam exatamente o acoplamento que este projeto procura remover.

Colunas inventadas devem falhar antes de uma consulta ser executada

LLMs inventam identificadores plausíveis. Se um prompt fala sobre o nome de exibição de um cliente, o código gerado pode tentar usar customers.display_name mesmo quando o banco armazena given_name e family_name. O banco rejeitará essa consulta, o que é melhor que ler silenciosamente o campo errado, mas um erro em produção continua sendo uma estratégia ruim para validar o esquema.

Gere um artefato de esquema tipado a partir do snapshot de catálogo aprovado e faça dele a única fonte para construir consultas. Uma tabela ou coluna ausente desse artefato deve causar um erro de geração. Não deixe o modelo corrigir o erro adicionando uma migração, a menos que a tarefa entre explicitamente na frente de migração. Um identificador ausente pode significar descoberta desatualizada, erro de escrita, ambiente errado ou um requisito real de produto. Cada caso exige uma resposta diferente.

As verificações estáticas devem analisar o SQL e resolver cada relação e coluna em relação ao snapshot. Depois, prepare instruções em um banco descartável ou em uma transação que não possa gravar. O analisador do PostgreSQL detecta colunas desconhecidas, referências ambíguas, erros de tipo de operador e muitas conversões ruins sem exigir dados de negócio válidos. Execute testes de integração com a função de execução para que permissões e políticas de linha participem.

O relatório de falha precisa trazer detalhes suficientes para uma pessoa decidir. Inclua a localização no SQL, o identificador não resolvido, identificadores válidos próximos, a impressão digital do snapshot e a identidade do banco de destino. Sugestões ajudam, mas substituição automática aproximada é perigosa. Trocar billing_address_id por shipping_address_id porque os nomes são parecidos pode produzir SQL válido com significado de negócio falso.

Para filtros e ordenações dinâmicos, mapeie nomes públicos da API para um conjunto fechado de expressões SQL qualificadas. Nunca cole em SQL um identificador fornecido pelo modelo, nem por meio de um parâmetro de valor. Parâmetros protegem valores, não nomes de tabela ou coluna. Se usuários puderem escolher um campo de ordenação, traduza created para uma expressão conhecida, como app.orders.created_at, e rejeite qualquer token desconhecido.

A deriva do esquema deve interromper uma liberação, não provocar uma reconciliação criativa. Gere novamente o snapshot, mostre as diferenças e repita os testes. Essa pausa pode parecer excessiva, mas custa menos que implantar código cuja compreensão do banco existe apenas no registro de uma conversa.

SQL destrutivo precisa de uma política de bloqueio e evidências

Um construtor deve classificar o SQL antes que alguém possa executá-lo. Bloqueie DROP, TRUNCATE, DELETE ou UPDATE amplos sem um predicado revisado, mudanças de propriedade, escalada de privilégios, mudanças em extensões e comandos voltados para fora dos esquemas aprovados. Trate ALTER TABLE como algo que exige revisão, não como algo automaticamente seguro. Uma mudança de tipo de coluna ou nova restrição não anulável pode examinar ou reescrever dados e manter bloqueios importantes.

Comparar texto sozinho é frágil, pois SQL tem comentários, identificadores entre aspas, funções e muitas formas de expressar efeitos colaterais. Analise as instruções com um analisador que conheça PostgreSQL, inspecione suas árvores sintáticas e também conte com a função do banco para negar ações proibidas. O classificador melhora a revisão; os privilégios impõem o limite. Nenhum dos dois deve carregar toda a responsabilidade.

Use um banco de staging restaurado de um snapshot recente e devidamente protegido quando uma migração depender de formatos reais de tabelas ou distribuições de dados. Aplique ali o pacote de migração exato, registre duração e observações de bloqueio, execute testes da aplicação com credenciais de execução e então descarte o ambiente. Não edite silenciosamente o SQL entre staging e produção. Qualquer edição cria um novo artefato que precisa de nova impressão digital e aprovação.

Os logs devem ligar uma proposta a uma execução sem registrar segredos ou linhas sensíveis. Registre quem aprovou o artefato de migração imutável, seu resumo criptográfico, a identidade de destino, o status de início e fim e detalhes de erros PostgreSQL. Preserve as diferenças geradas e os resultados da pré-verificação. Uma conversa com um agente traz contexto útil, mas não é um registro de auditoria, pois usuários podem bifurcar, tentar novamente e reformular instruções.

Snapshots e controles de rollback reduzem o tempo de recuperação, mas não tornam SQL destrutivo aceitável. Um snapshot pode restaurar todo um banco a um ponto anterior quando a necessidade real é uma única coluna removida, e a restauração pode descartar gravações legítimas feitas depois do snapshot. Teste a recuperação separadamente e documente quem pode acioná-la.

Quando uso o Koder.ai para um app que toca um banco já estabelecido, mantenho o trabalho no modo de planejamento até revisar o código exportado e o limite de banco proposto. Snapshots e rollback são controles de recuperação, não permissão para pular essa revisão. A mesma regra vale para qualquer construtor: a conveniência do produto deve ficar atrás da imposição feita pelo banco.

Mudanças de esquema devem tolerar versões mistas da aplicação

Uma migração só é segura quando a aplicação antiga e a nova podem funcionar durante a janela de liberação. A produção raramente muda de uma versão para outra em um único instante. Solicitações podem chegar a instâncias antigas enquanto novas começam, tarefas em fila podem carregar cargas antigas e um rollback pode recolocar o código de ontem contra o esquema de hoje. Um construtor que valida apenas o código final contra o esquema final ignora essa sobreposição.

Prefira primeiro mudanças aditivas. Adicione uma coluna anulável, uma tabela nova ou um índice sem remover o caminho antigo. Implante código que consiga ler as duas representações e gravar na nova quando apropriado. Preencha as linhas existentes com um trabalho revisado separadamente, acompanhe erros e atraso e então torne o novo campo a fonte principal. Remova a coluna ou restrição antiga em uma liberação posterior, depois que houver evidências de que nenhum código em execução a usa.

Essa sequência leva mais tempo que gerar uma única instrução ALTER TABLE, mas isola falhas. Se o novo código se comportar mal antes da remoção, o caminho antigo ainda existe. Se o preenchimento ficar para trás, ele pode pausar sem manter a liberação da aplicação refém. Se a implantação sofrer rollback, a aplicação antiga ainda reconhece o banco. A liberação extra custa menos que descobrir durante o rollback que o binário anterior consulta uma coluna que a migração já removeu.

Renomeações exigem cuidado especial porque o PostgreSQL muda o nome imediatamente. Um gerador pode propor renomear customer_ref para customer_id porque o novo nome parece melhor. Instâncias antigas falharão assim que a migração for confirmada. Adicione customer_id, mantenha os dois campos sincronizados no código da aplicação ou em um gatilho estritamente revisado, mova os leitores e remova customer_ref somente quando os gravadores antigos desaparecerem. A duplicação temporária é uma dívida visível com condição de remoção; uma renomeação imediata é acoplamento invisível da liberação.

Padrões e restrições não anuláveis também podem esconder trabalho. Antes de aprovar SET NOT NULL, conte os nulos existentes e prove que todo gravador ativo fornece um valor. Para tabelas grandes ou muito usadas, revise como a versão do PostgreSQL valida a restrição e quais bloqueios ela obtém. Um construtor deve informar essas condições prévias, não inferi-las de um esquema que não contém tráfego representativo.

Preenchimentos de dados não devem ocorrer dentro de uma transação de esquema sem limite. Atualize linhas em lotes medidos por meio de um trabalhador aprovado, registre o progresso com um cursor estável e torne as tentativas idempotentes. Uma tentativa é idempotente quando aplicá-la duas vezes produz o estado pretendido, não apenas quando o PostgreSQL aceita a segunda consulta. Para valores derivados, registre a versão da derivação se códigos futuros puderem calculá-los de forma diferente.

O pacote de liberação deve nomear quatro pontos de compatibilidade:

1. A versão mais antiga da aplicação autorizada a executar antes da migração.
2. O estado do esquema aceito por versões antigas e novas.
3. O sinal que permite a liberação de limpeza destrutiva.
4. O caminho de recuperação se o novo código sofrer rollback depois que os dados mudarem.

Consultas geradas devem evitar SELECT * durante essas transições. Adicionar uma coluna pode mudar o custo de leitura, a decodificação do resultado, o mapeamento posicional e a exposição de dados, mesmo que o SQL antigo ainda seja analisado. Liste colunas qualificadas explicitamente e gere decodificadores a partir do mesmo snapshot de esquema. Isso também faz a revisão do código mostrar exatamente quais dados cruzam o limite do banco.

Ferramentas de migração preparadas costumam rastrear uma versão aplicada em uma tabela, mas um número de versão sozinho não prova compatibilidade. Registre o resumo criptográfico do artefato SQL exato, pois dois arquivos com o mesmo nome amigável podem conter comandos diferentes. O executor deve recusar uma versão já registrada com resumo diferente. Também deve recusar uma migração posterior quando faltar um predecessor obrigatório.

Não deixe cada instância da aplicação executar migrações na inicialização. Mesmo quando uma ferramenta de migração usa um bloqueio consultivo, a inicialização passa a depender de uma credencial privilegiada e da conclusão do trabalho de esquema antes de expirarem as verificações de integridade. Execute a migração em um único trabalho de liberação, aguarde seu resultado registrado e inicie instâncias de execução com uma identidade que não possa alterar o esquema. Se o sistema de liberação não consegue separar essas fases, corrija-o antes de conceder poderes de proprietário à aplicação.

Teste esta linha do tempo, não apenas o destino: código antigo no esquema antigo, código antigo no esquema expandido, código novo no esquema expandido e código com rollback após novas gravações. A limpeza recebe seu próprio teste depois. Essa matriz encontra mudanças sintaticamente válidas, mas operacionalmente impossíveis de reverter.

Comprove o limite com testes negativos

Um projeto de segurança fica incompleto até que as ações proibidas falhem em teste. Conecte-se como descoberta e tente uma inserção, uma criação de tabela e SET TRANSACTION READ WRITE. Conecte-se como execução e tente acessar uma tabela sem permissão, uma leitura entre locatários coberta pela segurança em nível de linha e uma mudança de esquema. O resultado esperado é um erro de permissão PostgreSQL, não uma promessa em um log de agente.

Execute também testes positivos. A descoberta ainda precisa ler cada entrada permitida do catálogo. A execução precisa realizar cada ação de usuário aprovada por meio do pool. A execução de migrações deve funcionar apenas pelo caminho de aprovação. Um limite que bloqueia o trabalho normal do produto incentivará alguém a substituí-lo por uma credencial de proprietário durante um incidente.

Mantenha um pequeno contrato de acesso junto ao código-fonte da aplicação. Ele deve nomear o banco, os esquemas permitidos, o escopo da descoberta, as operações de execução, o modo do pool, a política de tempos limite, os aprovadores de migração, o método de impressão digital do esquema e as instruções proibidas. Compare as permissões reais com esse contrato em verificações contínuas. A deriva de permissões PostgreSQL é deriva de configuração, mesmo quando ninguém alterou o código da aplicação.

Verifique novamente após mudanças de função, novas tabelas, bancos restaurados, atualizações do pool e mudanças de hospedagem. Privilégios padrão importam para objetos futuros: conceder SELECT ON ALL TABLES cobre as tabelas atuais, não as criadas depois. Decida se novos objetos devem ficar invisíveis até revisão ou ser incluídos por privilégios padrão configurados de forma restrita. Prefiro que fiquem invisíveis por padrão, pois uma permissão explícita coloca a nova tabela na conversa sobre acesso.

Inclua a revogação no plano de teste. Desative a credencial de descoberta e confirme que o tráfego de execução continua; desative a de execução e confirme que a ferramenta de migração não substitui silenciosamente pela identidade mais forte. Depois, faça a rotação de cada segredo enquanto há conexões ativas e observe se o pool aposenta sessões antigas dentro da janela prevista. Uma mudança de senha não encerra sessões já autenticadas, então os procedimentos de rotação precisam de uma reciclagem explícita do pool ou de uma política de encerramento de sessão do PostgreSQL.

Revise mensagens de falha para detectar divulgação acidental durante esses testes. Erros PostgreSQL podem incluir nomes de relações, trechos de SQL, nomes de restrições e valores fornecidos. Envie erros detalhados para logs restritos do servidor, retorne um erro público estável aos clientes e nunca alimente uma conversa com agente com todo o fluxo de erros de produção. O construtor precisa da localização da instrução e da resposta sanitizada do banco para corrigir código; não precisa de valores de clientes.

Um teste final detecta um número surpreendente de integrações inseguras: remova por completo a credencial de migração e execute a suíte de testes da aplicação. Se a inicialização normal, verificações de integridade, prévias ou tratamento de solicitações falharem, a propriedade do esquema vazou para o caminho de execução. Corrija esse acoplamento antes de conectar o construtor à produção. Um construtor de apps com IA pode trabalhar com um banco que não possui, mas o PostgreSQL precisa conseguir dizer não quando o código gerado esquece o acordo.