Projetos com código-fonte exportado precisam de um teste de portabilidade

Exportar o código-fonte prova que você recebeu arquivos. Não prova que o projeto consegue compilar, iniciar, autenticar usuários, ler dados de produção ou ser implantado depois que o criador original de aplicações de IA desaparecer. Trate a portabilidade como um teste de aceitação, não como uma caixa marcada em um contrato comercial.

Já assumi aplicações geradas o suficiente para desconfiar de um repositório limpo à primeira vista. As falhas caras costumam se esconder fora do código evidente da aplicação: uma solicitação em execução para um serviço do fornecedor, um callback de autenticação registrado no tenant de outra pessoa, uma política de banco de dados que nunca entrou no controle de versão ou uma configuração de implantação que existe apenas em um painel gerenciado. Um projeto só é portável quando sua equipe consegue reproduzir seu funcionamento a partir da exportação e de serviços externos documentados, usando contas sob seu controle.

Projetos com código-fonte exportado ainda podem depender do criador

Um projeto com código-fonte exportado só funciona de modo independente se cada dependência necessária em tempo de compilação e execução estiver disponível, documentada, puder ser transferida e tiver licença para uso fora do criador. Essa definição é mais rigorosa do que «o repositório compila». Ela cobre o caminho de uma máquina vazia até uma versão de produção funcional, incluindo identidade, dados, tarefas agendadas, segredos, regras de rede e recuperação.

Três afirmações diferentes costumam se misturar. Acesso ao código-fonte significa que você pode inspecionar arquivos. Independência de compilação significa que você pode produzir artefatos sem chamar o criador. Independência em execução significa que esses artefatos continuam atendendo solicitações reais sem o criador. Um fornecedor pode cumprir a primeira afirmação e falhar nas outras duas.

A distinção tem uma consequência direta no contrato. Se o contrato promete «exportação de código-fonte», você pode receber um diretório React, um manifesto de pacotes e um README, mas ainda precisar de um SDK proprietário ou gateway hospedado. Peça um resultado operacional: um engenheiro autorizado deve conseguir compilar e executar a versão aceita em um ambiente limpo, usando contas pertencentes ao cliente.

Defina o limite antes de testar. Serviços gerenciados não são automaticamente uma falha de portabilidade. A maioria das aplicações relevantes depende de uma nuvem, processador de pagamentos, provedor de e-mail ou serviço de identidade. A questão é se você escolheu essas dependências conscientemente e se pode movê-las ou substituí-las sob seu próprio contrato. Um serviço oculto do fornecedor que não pode ser contratado separadamente é diferente de um banco de dados PostgreSQL documentado em sua conta na nuvem.

Crie um registro de dependências com quatro campos para cada componente externo: proprietário, finalidade, caminho de substituição e comportamento em caso de falha. «Proprietário» significa o titular legal da conta, não a pessoa que sabe a senha. O «caminho de substituição» pode ser um procedimento de migração, uma interface que você consegue reimplementar ou uma decisão explícita de manter o serviço. O «comportamento em caso de falha» registra o que os usuários veem quando ele está indisponível. Se o vendedor não consegue preencher esses campos, a exportação não foi explicada bem o bastante para precificar seu risco.

O melhor primeiro teste é banal: desconecte o acesso à conta do criador e tente usar a aplicação. Revogue os tokens em uma cópia de teste, bloqueie seus domínios conhecidos no limite da rede e observe o que falha. Não comece lendo todos os arquivos. Evidências em execução encontram dependências que a revisão de código não percebe, incluindo configurações injetadas e chamadas feitas por pacotes compilados.

Rastreie a aplicação enquanto fluxos reais são executados

Callbacks em execução se revelam quando você observa DNS, conexões de saída, solicitações do navegador e tarefas em segundo plano durante fluxos representativos. Uma página inicial que carrega prova pouco. Teste login, recuperação de senha, upload de arquivos, pesquisa, transições de cobrança, entrega de e-mails, tarefas agendadas, ações administrativas e qualquer recurso baseado em IA que o produto realmente venda.

Execute a aplicação em uma nova rede de teste que registre o tráfego de saída. Dê a ela apenas os destinos listados no registro de dependências. Comece com uma política de bloqueio para tráfego não listado, se seu ambiente permitir. Cada solicitação bloqueada vira uma pergunta: ela é necessária, telemetria opcional, uma verificação de atualização ou uma chamada não documentada ao plano de controle?

As ferramentas de desenvolvimento do navegador importam porque algumas dependências nunca passam pelo seu servidor. Inspecione o painel Rede depois de limpar o armazenamento e usar uma nova sessão. Veja os hosts das solicitações, solicitações de preflight que falharam, conexões WebSocket, scripts carregados e redirecionamentos. Um frontend pode chamar diretamente uma API do criador mesmo quando o repositório do servidor parece autossuficiente. Service workers também podem preservar comportamentos antigos, então cancele seu registro antes de repetir o teste.

Em uma árvore de código Unix ou semelhante, esta busca oferece um primeiro inventário útil:

grep -R -n -E 'https?:|wss?:|fetch[(]|axios|WebSocket|grpc|callback|webhook' .

Espere uma saída no formato path/to/file:line:matching text. Analise lockfiles gerados separadamente do código da aplicação, pois um domínio nos metadados de um pacote não prova uma chamada em execução. Da mesma forma, uma busca limpa não comprova independência: variáveis de ambiente podem montar hosts, aliases DNS podem escondê-los e dependências binárias podem fazer suas próprias solicitações.

Pesquise termos do fornecedor, importações de SDK e prefixos de variáveis de ambiente em passagens separadas. Depois, inspecione os lockfiles para ver se os pacotes são resolvidos de um registro público ou de um registro privado do fornecedor. O êxito por causa do cache pode enganar nesse ponto. Exclua os caches de pacotes da linguagem no ambiente isolado de teste e recompile somente com as credenciais documentadas do registro.

Rastreie o comportamento em segundo plano por tempo suficiente para atravessar o limite de um agendador. Um processo web pode parecer saudável enquanto consumidores de fila falham, relatórios agendados param e tentativas de novo envio de webhooks se acumulam. Acione tarefas manualmente quando esperar o agendamento normal atrasaria o teste. Registre o destino, o método da solicitação, o tipo de autenticação, a classe de resposta, a regra de tentativa e a consequência visível para o usuário em cada integração de saída.

Não aceite «esse callback é só telemetria» sem testar sua falha. Bloqueie-o e repita o fluxo. A telemetria opcional deve expirar rapidamente ou falhar sem alterar a operação do usuário. Já vi chamadas de registro dentro de uma transação de solicitação transformarem uma interrupção inofensiva de análise em uma gravação que falha. O rótulo não determina o risco, o caminho do código determina.

SDKs proprietários precisam de uma rota de remoção ou licenciamento

Um SDK proprietário é aceitável apenas quando você consegue obtê-lo, compilar com ele, executá-lo legalmente e substituí-lo em um prazo que a empresa tolera. Ter o código-fonte de seu wrapper na exportação não concede direitos sobre o SDK, protocolo, endpoint hospedado ou modelo por trás dele.

Faça o inventário de dependências a partir dos manifestos e das importações do código. Em JavaScript, inspecione package.json e seu lockfile. Em Go, inspecione go.mod e as somas de verificação. Em Flutter, inspecione pubspec.yaml e seu lockfile. Anote pacotes buscados em repositórios Git, registros privados, caminhos locais ou arquivos. Esses são lugares comuns para esconder componentes pertencentes ao criador.

Para cada pacote questionável, responda quatro perguntas concretas:

1. Um novo agente de compilação controlado pelo cliente consegue baixar a versão exata?
2. A licença permite uso em produção depois que o contrato com o criador terminar?
3. O pacote chama um serviço que o cliente pode contratar diretamente?
4. A interface é pequena o bastante para ser substituída, e essa interface é testada?

Faça uma compilação a frio com credenciais criadas em uma organização controlada pelo cliente. Não copie todo o diretório de configuração de um desenvolvedor para a máquina de teste. Isso importa pacotes em cache, configurações implícitas de registro e tokens pessoais, o que invalida o exercício. Um procedimento correto de compilação começa com a versão documentada das ferramentas e declara cada credencial adicional individualmente.

Gere uma lista de materiais de software se as ferramentas oferecerem suporte, mas não confunda esse documento com um veredito de portabilidade. Uma SBOM lista componentes, mas raramente informa quem controla uma conta remota ou se um pacote se comunica com servidores externos. Use-a para comparar o que o repositório declara com o que o artefato compilado contém.

Quando um cliente proprietário fica atrás de um adaptador estreito, escreva agora um teste de contrato para o adaptador. Envie uma solicitação conhecida, valide a resposta normalizada e execute o mesmo teste com o endpoint de rede bloqueado. A falha deve ser explícita e limitada. Se chamadas proprietárias aparecem em componentes de visualização, manipuladores de rota e modelos de dados, precifique uma refatoração antes de assinar. O problema aumenta com a quantidade de pontos de chamada e o acoplamento semântico, não com o número de linhas do SDK.

As equipes muitas vezes recomendam substituir toda dependência proprietária antes da compra. Isso parece seguro, mas pode desperdiçar semanas em serviços que o comprador pretende manter. A regra melhor é remover dependências indisponíveis ou que não podem ser contratadas, isolar as que você aceita e atribuir custo de migração às demais. Portabilidade é ter controle sobre escolhas, não uma aplicação sem serviços externos.

A autenticação vai além da árvore de código-fonte

A autenticação só migra bem quando o cliente controla o tenant de identidade, os registros de redirecionamento, as chaves de assinatura, os identificadores de usuários, os modelos de e-mail e o processo de recuperação. O código da aplicação costuma registrar apenas uma parte desse sistema.

Comece desenhando o caminho de login com seus saltos reais. Um navegador chega à aplicação, a aplicação redireciona para um provedor de identidade, o provedor retorna a um callback registrado e o backend troca ou valida credenciais. Registre o proprietário e o local de configuração em cada salto. Se algum console só puder ser acessado pela organização do criador, exija transferência ou substituição antes da aceitação.

A autenticação gerenciada cria um problema de dados especialmente delicado. A tabela de usuários da aplicação pode armazenar um identificador específico do provedor, em vez de um endereço de e-mail ou de um ID interno durável. Exportar linhas não ajuda se um novo tenant de identidade emitir identificadores diferentes. Teste a correspondência de contas, o tratamento de duplicidades, usuários com senha, usuários de login social, inscrição em autenticação multifator, contas bloqueadas e usuários que mudaram de endereço de e-mail.

O OpenID Connect define a declaração sub como um identificador localmente único, nunca reatribuído dentro do escopo do emissor. O emissor importa. Tratar apenas sub como globalmente portável pode associar o registro errado da aplicação depois de uma mudança de tenant. Armazene e compare o emissor com o identificador e, então, crie um mapeamento explícito para a migração.

Seu teste precisa de pelo menos quatro contas: um usuário comum, um administrador, um usuário desabilitado e um usuário com um segundo fator de autenticação. Mova ou recrie a configuração de identidade em um tenant controlado pelo cliente, restaure uma cópia do banco de dados de teste e verifique tanto o login bem-sucedido quanto o acesso negado. Teste também logout, renovação de token, redefinição de senha, aceitação de convite e expiração de sessão. As equipes lembram do caminho feliz de login e descobrem a recuperação quebrada apenas depois da migração.

Pesquise no repositório URIs de redirecionamento, IDs de cliente, nomes de emissor, domínios de cookie, valores de público e referências a chaves de assinatura. Mantenha segredos fora do repositório, mas registre seus nomes, proprietários, etapas de criação, etapas de rotação e formatos exigidos na documentação de implantação. Um arquivo de ambiente de exemplo deve identificar o contrato sem conter valores reais:

AUTH_ISSUER=
AUTH_CLIENT_ID=
AUTH_CLIENT_SECRET=
AUTH_CALLBACK_ORIGIN=
SESSION_SIGNING_KEY=

Não aceite um tenant compartilhado do criador como arranjo permanente só porque a migração pode acontecer «depois». Migrações de identidade afetam todos os usuários ativos e todas as premissas de autorização. Transfira o controle antes de assinar ou transforme a substituição em uma condição do acordo com custo e testes definidos.

A portabilidade do banco de dados inclui comportamento e operações

Um dump de banco de dados não basta quando esquemas, extensões, políticas por linha, gatilhos, armazenamento de objetos, filas, backups e regras de conexão vivem fora dele. Portabilidade de banco de dados significa que você consegue restaurar os dados e reproduzir o comportamento que os protege e altera.

Comece com uma instância PostgreSQL vazia, controlada pelo cliente, na versão principal documentada. Aplique as migrações do repositório em ordem. Se o projeto não tiver migrações e exigir a importação de um dump de esquema criado pelo fornecedor, registre isso como defeito. Um dump pode capturar o estado atual, mas não explica como a próxima versão altera esse estado com segurança.

Compare o esquema restaurado com a produção ou o ambiente de teste. Verifique tabelas, colunas, tipos, restrições, índices, sequências, visualizações, funções, gatilhos, extensões habilitadas, funções, permissões e políticas de segurança em nível de linha. Muitas ferramentas de migração omitem funções e configurações no nível do provedor. Uma aplicação pode passar em testes básicos de leitura enquanto tarefas administrativas falham porque a função restaurada não tem permissão para usar uma sequência ou função.

Em seguida, verifique o caminho dos dados com uma ida e volta controlada:

1. Crie um registro pelo fluxo público da aplicação.
2. Leia-o por meio de um segundo usuário autorizado quando o compartilhamento for esperado.
3. Confirme que um usuário não autorizado não consegue lê-lo nem alterá-lo.
4. Atualize-o e exclua-o pela aplicação.
5. Restaure o banco de dados em outra instância limpa e repita as leituras.

Essa sequência testa juntos o código da aplicação, a política de autorização, os valores gerados e a capacidade de recuperação. Contagens diretas de linhas em SQL não cobrem esses comportamentos.

Trate o armazenamento de objetos como parte do limite do banco de dados quando as linhas apontarem para arquivos enviados. Exporte buckets, metadados de objetos, regras de acesso, regras de ciclo de vida e configurações de geração de URL. Um banco de dados restaurado cheio de chaves de objetos não serve quando os arquivos subjacentes continuam em um bucket controlado pelo criador. O mesmo alerta vale para índices de pesquisa e armazenamentos vetoriais: decida se vai migrá-los ou reconstruí-los e comprove o procedimento de reconstrução.

Não meça sucesso ou fracasso com base em um único dump pequeno. Use uma cópia com tamanho semelhante ao ambiente de teste, que contenha textos longos, valores nulos, caracteres não ASCII, objetos grandes, datas e horas em torno de mudanças de horário de verão e relações representativas. Você não precisa inventar benchmarks. Precisa de evidências de que a transferência termina dentro da indisponibilidade permitida e de que a aplicação funciona depois dela.

Alegações de backup exigem uma restauração. Identifique quem agenda backups, onde as cópias ficam, quem pode descriptografá-las, como funciona a retenção e como você detecta uma falha de backup. Restaure um deles em uma conta isolada com instruções escritas. Se apenas o criador consegue apertar o botão de restauração, você tem um recurso de serviço, não um plano de recuperação independente.

Um pipeline de CI ausente é conhecimento de produto ausente

Um repositório exportado sem integração contínua reproduzível obriga o comprador a redescobrir versões de ferramentas, ordem de compilação, testes, empacotamento de artefatos, momento das migrações de banco de dados e controles de lançamento. Esse conhecimento faz parte da entrega, mesmo quando o pipeline interno do vendedor não pode ser transferido literalmente.

Procure definições de pipeline, arquivos de compilação de contêineres, arquivos de versão de ferramentas, comandos de teste, regras de lint, comandos de migração e definições de infraestrutura. Depois, compare-os com um log de implantação real. A documentação costuma descrever uma compilação web simples enquanto a plataforma gerenciada gera silenciosamente configuração, injeta um componente de servidor, cria um pacote móvel ou executa migrações de banco de dados.

Reconstrua o pipeline mínimo em uma conta de CI controlada pelo cliente. Ele deve obter uma revisão fixada, instalar um conjunto declarado de ferramentas, buscar dependências, executar testes, produzir artefatos imutáveis e registrar a identidade do artefato. A implantação pode continuar manual durante o teste, mas o artefato que chega ao ambiente de teste deve ser o que o pipeline produziu.

Um log compacto de aceitação pode seguir este formato:

revision: 4f2c9ab
toolchain: declared versions loaded
dependencies: cold install passed
tests: unit and integration passed
artifacts: web, server, mobile
migrations: dry run passed
staging: health and workflow checks passed

Os valores serão diferentes, mas cada linha precisa ter saída de máquina ou um registro interno vinculado, não a lembrança de uma pessoa. Guarde o log com as evidências de aceitação.

Não exija a infraestrutura secreta de implantação do vendedor se não precisar dela. Exija instruções e configuração suficientes para reproduzir o resultado. Um pipeline portável pode usar um produto de CI diferente, desde que execute os mesmos estágios obrigatórios e não enfraqueça os controles de lançamento.

Aplicações móveis acrescentam ativos de assinatura, identificadores de pacote, contas de loja e credenciais de notificações push. É fácil ignorá-los porque uma compilação do código pode funcionar em um emulador sem eles. Verifique a propriedade do cliente sobre as contas de distribuição e documente a rotação de certificados. Em aplicações de servidor e web, inclua verificação de domínio, emissão de certificado TLS, alterações de DNS e invalidação de cache no exercício de lançamento.

O teste do pipeline termina com uma mudança, não com a recompilação do commit fornecido. Faça uma alteração visível e inofensiva, adicione uma migração de banco de dados que possa ser revertida, compile-a, implante-a no ambiente de teste, verifique-a e execute a reversão. Isso identifica artefatos gerados que foram incluídos uma vez, mas não podem ser gerados novamente.

Fixe os pacotes do sistema operacional usados na compilação, além do conjunto de ferramentas da linguagem. Módulos nativos podem compilar com bibliotecas que por acaso existem na imagem do criador. Um novo executor pode falhar antes do início dos testes da aplicação ou, pior, produzir um artefato com comportamento diferente. Registre nomes e versões de pacotes em uma definição de contêiner ou descrição de compilação equivalente legível por máquina.

Mantenha segredos fora dos logs de CI e, ao mesmo tempo, comprove que o pipeline consegue obtê-los de um cofre controlado pelo cliente. O teste deve criar uma credencial temporária do ambiente de teste, injetá-la pelo mecanismo documentado e rotacioná-la sem editar o código-fonte. Se um segredo precisa ser colado em um painel do fornecedor pela equipe de suporte, registre essa dependência em vez de escondê-la nas notas de configuração.

Premissas de hospedagem aparecem em uma implantação em ambiente limpo

Uma implantação em ambiente limpo comprova a portabilidade quando uma equipe que não conhece o criador consegue lançar o sistema em um ambiente controlado pelo cliente, usando apenas a exportação, os serviços declarados e as instruções escritas. Execute-a antes da aceitação do contrato, com prazo definido e um registro de problemas.

Escolha um ambiente que corresponda ao modelo operacional pretendido. Migrar de uma plataforma gerenciada para máquinas virtuais sem gerenciamento cria trabalho não relacionado e pode fazer um projeto portável parecer quebrado. Corresponda às estruturas necessárias, como contêineres, PostgreSQL, armazenamento de objetos, tarefas agendadas, segredos e balanceamento de carga, mas não recrie mágica não documentada do fornecedor.

Inspecione a aplicação em busca de premissas sobre discos locais graváveis, portas fixas, sessões persistentes, cabeçalhos de proxy confiáveis, nomes de região, nomes de host injetados e variáveis de ambiente específicas da plataforma. O Twelve-Factor App recomenda armazenar a configuração no ambiente e tratar serviços de apoio como recursos conectados. Essas ideias continuam úteis, mas só variáveis de ambiente não documentam propriedade, formatos nem criação. Associe cada variável a um registro operacional.

As verificações de integridade merecem testes diretos. Um processo que retorna sucesso antes de terminar as migrações ou antes de conectar dependências necessárias pode entrar em um ciclo de reinicialização atrás de um orquestrador. Separe disponibilidade de prontidão quando o sistema de hospedagem oferecer suporte. Pare o banco de dados, o armazenamento de objetos e a fila, um por vez, e observe códigos de status, logs, comportamento de tentativas e recuperação quando o serviço voltar.

Confirme como a aplicação lida com várias instâncias. Sessões em memória, diretórios locais de upload e bloqueios de tarefas locais ao processo funcionam em uma instância gerenciada e falham depois da escala. Inicie duas instâncias, envie as solicitações do mesmo usuário pelas duas e execute trabalhadores de tarefas simultâneos. Verifique se as sessões persistem, os arquivos continuam disponíveis e uma tarefa agendada não é executada duas vezes, a menos que tenha sido projetada para ser idempotente.

Observe o encerramento tão cuidadosamente quanto a inicialização. Envie um sinal de término enquanto solicitações e tarefas em segundo plano estiverem ativas. O processo deve deixar de aceitar novo trabalho, concluir ou devolver com segurança as tarefas assumidas, fechar conexões e sair dentro do período de tolerância do host. Um criador gerenciado pode ter ocultado encerramentos abruptos com tempos limite longos ou novas tentativas que seu novo host não compartilha.

Logs e métricas também trazem premissas de hospedagem. Confirme que a aplicação grava eventos estruturados em um destino documentado, remove segredos e dados pessoais quando necessário e expõe informações suficientes para diagnosticar um fluxo que falhou. Um painel proprietário só é opcional quando a saída padrão ou outro destino controlado pelo cliente preserva as evidências necessárias.

Alegações sobre região e localização de dados exigem evidências de configuração. Registre onde a aplicação, o banco de dados, os backups, os logs e o armazenamento de objetos são executados, além de quais serviços externos recebem dados. Um seletor de região para o processo web não mantém os dados em um país se a autenticação ou a análise os envia para outro lugar. O contrato deve indicar quem aprova mudanças nesses locais.

O Koder.ai oferece exportação de código-fonte, implantação e hospedagem, domínios personalizados, snapshots e reversão. Se você avaliar um projeto exportado do Koder.ai quanto à operação independente, use o mesmo padrão de ambiente limpo: teste os componentes React, Go com PostgreSQL ou Flutter exportados no ambiente que pretende controlar e documente qualquer serviço que optar por manter.

Coloque as condições de aprovação e reprovação no contrato

O contrato deve definir portabilidade como comportamento observado, listar o ambiente de aceitação, atribuir responsabilidade pela correção e preservar tempo suficiente para corrigir falhas antes do pagamento final ou da dependência irreversível. Uma linguagem vaga sobre propriedade não salvará uma aplicação que ninguém mais consegue implantar.

Anexe uma matriz de aceitação em vez de depender de um parágrafo intitulado «código-fonte». Cada linha deve indicar uma capacidade, o procedimento de teste, o resultado esperado, a evidência, a parte responsável e a gravidade. Cubra compilação a frio, chamadas de rede em execução, transferência de identidade, restauração de banco de dados, armazenamento de arquivos, trabalho em segundo plano, CI, implantação limpa, monitoramento, restauração de backup, uma pequena alteração e reversão.

Use critérios de aprovação que terceiros possam observar. «Nenhuma dependência proprietária crítica» convida à discussão. «A aplicação no ambiente de teste conclui os fluxos A a F enquanto todas as credenciais controladas pelo criador estão revogadas e os domínios do criador estão bloqueados» pode ser testado. Defina as dependências permitidas pelo nome e pelo proprietário da conta para que a equipe não confunda um serviço gerenciado aprovado com uma falha.

Exija a entrega do código-fonte e dos materiais operacionais em uma revisão fixada: lockfiles, migrações, definições de compilação, configuração de infraestrutura quando disponível, catálogo de variáveis de ambiente, registro de dependências, exportação de dados, plano de migração de identidade, guias operacionais, avisos de licença e ativos de assinatura ou distribuição que pertençam ao cliente. Registre exclusões de modo explícito. O silêncio não deve significar aceitação.

Defina a gravidade pelo efeito nos negócios. A ausência de um evento opcional de análise não equivale a uma interrupção de login. Um esquema útil distingue bloqueadores que impedem a compilação ou fluxos essenciais, defeitos graves que removem uma capacidade importante ou um caminho de recuperação e defeitos menores com uma solução alternativa documentada. Vincule as datas de aceitação e correção a esses níveis sem inventar um cronograma universal.

Defina também os dados de teste e o operador. Vendedores às vezes demonstram portabilidade com um banco de dados vazio e uma conta de administrador que ignora a autorização comum. Exija usuários, funções, arquivos e tarefas em segundo plano representativos, com funcionários do cliente realizando o procedimento documentado. Mantenha os segredos sintéticos, mas preserve relações e casos extremos realistas.

Os custos fazem parte do pacote de evidências. Registre os serviços cobrados separadamente que são necessários para executar a versão exportada e qualquer plano mínimo, taxa de saída de dados ou assinatura de registro privado que o vendedor identificar. O teste não precisa prever todas as contas futuras. Ele precisa evitar que uma exportação supostamente independente revele um contrato inevitável com o fornecedor apenas depois da assinatura.

Inclua deveres de cooperação para serviços que não podem ser transferidos imediatamente. O vendedor pode precisar rotacionar chaves, aprovar uma exportação de identidade, mover um domínio ou fornecer um snapshot final dos dados. Indique a ação e a pessoa responsável. «Assistência razoável» é difícil de exigir quando a produção está fora do ar.

Preserve o direito de repetir os testes após a correção e depois da exportação final. Projetos gerados mudam rapidamente, e uma correção comprovada na revisão do mês passado não diz nada sobre novas dependências adicionadas ontem. Fixe o commit testado e os hashes dos artefatos no registro de aceitação.

Não deixe uma cláusula de escrow substituir esse trabalho. O escrow pode entregar arquivos depois de um evento desencadeador, mas arquivos sem instruções atuais de compilação, propriedade das credenciais e caminhos de recuperação testados podem chegar tarde demais para ajudar. A independência operacional deve existir enquanto as duas partes ainda podem cooperar.

Assine quando uma segunda equipe conseguir compilar, executar, alterar, implantar e recuperar a versão aceita sem ajuda privilegiada do criador original. Qualquer coisa menos que isso é posse do código-fonte com um projeto de migração não resolvido anexado, e o preço do contrato deve refletir esse trabalho.