Como uma auditoria de remediação sustenta um orçamento confiável

Um orçamento de reparo confiável nasce de evidências, não de um passeio pela interface. Um projeto herdado pode parecer bem acabado enquanto a redefinição de senha revela quais contas existem, a verificação de administrador roda apenas no navegador e o banco de dados aceita registros que o produto nunca conseguirá usar. Um serviço de remediação que calcula o preço com base em capturas de tela ou em uma ligação curta está precificando a incerteza. O comprador acabará pagando por ela em alterações de escopo, falhas não detectadas ou ambos.

A auditoria deve responder a duas perguntas distintas: o que está quebrado e o que o serviço realmente controla o suficiente para reparar? Essa diferença importa em projetos criados com Lovable, Bolt, v0, Cursor ou Replit, pois o código visível pode ser apenas uma parte do sistema. Configurações de autenticação, políticas do banco, variáveis de ambiente, contas de implantação, DNS, entrega de e-mail, regras de armazenamento e painéis de terceiros podem estar em outros lugares. Um orçamento bem feito mapeia todo o sistema em operação, registra as evidências e declara quais dúvidas permanecem.

O comprador deve conseguir ligar cada tarefa orçada a uma verificação que falhou ou a uma lacuna de propriedade documentada. Essa rastreabilidade muda a conversa comercial. Ela impede que uma refatoração cosmética passe à frente de dados expostos e dá às duas partes uma definição comum de trabalho concluído. Quando o serviço não puder mostrar a verificação que falhou, deve classificar o trabalho como melhoria preventiva ou descoberta, em vez de apresentar uma suposição como defeito.

O orçamento começa pelo acesso, não pelas estimativas

O serviço precisa de acesso de leitura a todo componente capaz de mudar o comportamento antes de definir um escopo fechado. Só o repositório raramente basta. A primeira etapa da auditoria deve criar um registro de ativos e propriedade que vincule cada componente em execução a uma conta, um proprietário e um ambiente de implantação.

O registro deve abranger o repositório e seu histórico, o projeto de hospedagem, os domínios de produção e homologação, o banco de dados, o provedor de autenticação, o armazenamento de arquivos, as funções sem servidor, os trabalhos em segundo plano, o serviço de e-mail, o provedor de pagamentos, as análises, o monitoramento de erros e qualquer automação que implante ou modifique dados. Para cada ativo, registre quem é o dono, quem pode administrá-lo, como o acesso pode ser transferido e se a produção depende de uma conta pessoal.

É nesse ponto que muitos compradores descobrem que não são donos do produto pelo qual pagaram. A agência pode controlar o repositório. Um ex-prestador pode ser dono da equipe de hospedagem. O fundador pode ter acesso ao banco, mas não possuir códigos de recuperação. Um orçamento não pode pressupor em silêncio que essas lacunas se resolverão sozinhas.

Peça ao serviço um registro de acesso com o estado de cada ativo. Um exemplo útil registraria o repositório como propriedade da organização compradora, com leitura confirmada pela tela de membros. Registraria o banco de produção com proprietário desconhecido, sem acesso para auditoria e tendo apenas um nome de conexão como evidência. Mostraria o projeto de hospedagem na conta de um prestador, com acesso de visualização e transferência pendente, enquanto a administração do domínio e do DNS já pertence ao comprador.

A falta de acesso ao banco nesse exemplo não é uma observação administrativa pequena. Ela impede verificar políticas, restrições, migrações, backups e a forma dos dados reais. O orçamento deve marcar o trabalho relacionado como condicional ou excluí-lo até que o acesso seja fornecido. Um serviço que informa o mesmo valor fechado antes e depois de ver esse registro não precificou o projeto real.

A autenticação precisa ser testada como um sistema

O auditor deve acompanhar cada caminho de identidade desde o navegador até os dados que ele autoriza. Ver uma tela de login funcionar prova apenas que um caminho ideal trocou credenciais por uma sessão. Isso não diz nada sobre recuperação de senha, verificação de e-mail, expiração da sessão, mudanças de função, exclusão da conta ou acesso entre organizações.

Comece com uma matriz de identidades e funções. Liste visitantes anônimos, usuários comuns, usuários convidados, usuários suspensos, administradores, equipe de suporte e processos de serviço. Depois, teste o que cada identidade pode ler e alterar. As verificações mais úteis atravessam uma fronteira: o usuário A solicita o registro do usuário B, um usuário suspenso reutiliza uma sessão antiga, um usuário comum chama diretamente um endpoint administrativo e um navegador desconectado repete uma solicitação que antes era válida.

O OWASP Application Security Verification Standard separa autenticação, gerenciamento de sessão e controle de acesso por um bom motivo. As equipes costumam misturar esses conceitos. A autenticação prova quem apresentou uma credencial. A autorização decide se essa identidade pode executar esta ação neste objeto. Uma sessão válida ainda pode fazer uma solicitação não autorizada, portanto uma proteção de rota no cliente ou um botão oculto não protege uma API.

Em uma aplicação web apoiada pelo Supabase, examine as concessões no banco e as políticas de Row Level Security em vez de confiar no comportamento da interface. A documentação do Supabase diz que as tabelas em esquemas expostos precisam de RLS, e seu guia de segurança da API explica que as concessões determinam quais funções podem alcançar um objeto, enquanto as políticas determinam quais linhas essas funções podem acessar. A auditoria deve enumerar tabelas, visualizações, funções e áreas de armazenamento e, em seguida, exercitar as políticas com pelo menos dois usuários de teste reais.

Uma matriz de testes compacta expõe lacunas melhor do que uma nota dizendo «a autenticação funciona». Ela deve tentar fazer o usuário A ler a linha privada do usuário B e guardar a solicitação e a resposta de recusa. Deve mudar role no corpo de uma solicitação e preservar tanto a rejeição do servidor quanto a linha inalterada. Também deve chamar uma API com uma sessão expirada, invocar uma função administrativa anonimamente e reutilizar o token de atualização de um usuário excluído. Cada resultado precisa de um horário e do registro relevante do provedor ou da aplicação.

O auditor também deve verificar listas de redirecionamentos permitidos, URLs de retorno OAuth, atributos de cookies, armazenamento de tokens, limites de frequência nos fluxos de recuperação e verificação e se as mensagens de erro revelam contas cadastradas. Se a autenticação estiver no código gerado do cliente enquanto gravações privilegiadas usam uma credencial de serviço, o orçamento deve incluir a mudança dessa fronteira de confiança para um componente controlado pelo servidor.

Cada segredo precisa de localização e decisão sobre rotação

O serviço deve inventariar credenciais na árvore atual, em todo o histórico do Git, nas configurações de compilação, nas variáveis da hospedagem, nos exemplos locais, nos registros e nos pacotes gerados. Procurar apenas nos arquivos mais recentes deixa de fora arquivos .env excluídos e chaves enviadas ao repositório três semanas atrás. Remover uma credencial da ramificação atual não faz com que ela volte a ser secreta.

O inventário precisa distinguir identificadores publicáveis de credenciais privilegiadas. Por exemplo, o Supabase documenta que chaves publicáveis são adequadas para componentes públicos quando a RLS protege os dados, enquanto chaves secretas e antigas chaves service_role pertencem apenas a componentes de servidor porque têm acesso elevado e podem ignorar a RLS. Tratar toda chave visível como vazamento cria ruído. Tratar todas como inofensivas cria incidentes.

O auditor pode começar com buscas reproduzíveis como estas:

git log -p -G '(api[_-]?key|secret|token|password)'
git grep -nE '(BEGIN (RSA|OPENSSH) PRIVATE KEY|service_role|sk_live_)'

O primeiro comando deve retornar os commits e patches correspondentes. O segundo retorna linhas da árvore atual sob controle de versão no formato caminho:linha:correspondência. Essas buscas não provam segurança, pois as credenciais podem usar formatos desconhecidos, estar em binários ou existir apenas no painel de uma plataforma. Ainda assim, elas criam evidências verificáveis e revelam se o orçamento inicial inclui a limpeza do histórico.

A documentação de proteção de envio do GitHub descreve como bloquear segredos reconhecidos antes que eles entrem em um repositório. Esse controle ajuda nos commits futuros, mas não gira uma credencial já exposta. Para cada descoberta, o relatório deve indicar o dono da credencial, o privilégio, os ambientes alcançados, o último uso conhecido, o método de rotação e se a rotação interromperá outro serviço. O escopo do reparo deve incluir a rotação e as mudanças de configuração dependentes, não apenas a exclusão da sequência.

Inspecione também os pacotes do navegador e as chamadas de rede depois de uma compilação de produção. Uma variável exclusiva do servidor pode tornar-se pública por um prefixo de compilação incorreto, pela serialização nos dados da página ou por um cliente de API gerado. Se a auditoria não puder acessar o painel do provedor relevante, deve dizer «exposição não verificada» em vez de «não há segredos expostos».

A lógica de negócio precisa de exemplos com dinheiro e estado

O auditor deve reconstruir as regras do produto independentemente do código atual. Aplicações geradas frequentemente implementam as telas com fidelidade, mas distribuem as regras de negócio entre manipuladores de botões, gatilhos do banco, funções sem servidor e condicionais moldadas por prompts. Uma revisão linha a linha não consegue dizer se essas regras correspondem ao negócio, a menos que alguém escreva primeiro o comportamento esperado.

Escolha os fluxos que criam um estado irreversível ou com efeito financeiro: cadastro e convite, checkout, mudanças de assinatura, consumo de créditos, aprovações, reembolsos, exclusão de registros, exportações e exceções administrativas. Para cada fluxo, registre pré-condições, ator autorizado, transição de estado, efeitos colaterais, comportamento em novas tentativas e resultado da falha. Depois, compare esse modelo com o código e os dados reais.

Suponha que uma compra de créditos siga esta sequência:

1. O navegador cria um pedido pendente.
2. Um provedor de pagamentos envia um evento de conclusão assinado.
3. Uma função de servidor verifica a assinatura e marca o evento como processado.
4. Uma transação única no banco registra o pagamento e adiciona créditos.
5. Um evento repetido retorna sucesso sem adicionar créditos novamente.

Se a aplicação atual adiciona créditos depois de um redirecionamento do navegador, o usuário pode repetir a solicitação. Se o webhook atualiza o pedido antes dos créditos e a segunda gravação falha, o dinheiro e o direito adquirido divergem. Se novas tentativas adicionam créditos duas vezes, uma repetição normal do provedor vira um erro de saldo. A auditoria deve executar o mesmo evento duas vezes, interromper o fluxo entre as gravações quando for prático e preservar as linhas anteriores e posteriores.

Esse exercício deixa clara uma distinção que auditorias fracas não percebem: uma funcionalidade quebrada é um comportamento observável, enquanto uma invariante quebrada permite um estado impossível. Corrigir o botão pode restaurar o caminho ideal, mas deixar saldos duplicados, registros órfãos ou transições não autorizadas no banco. O orçamento deve incluir o reparo do código e a conciliação dos dados quando os registros reais já puderem violar a regra.

Os compradores devem fornecer exemplos em linguagem simples, inclusive as exceções desconfortáveis. Quem pode reverter uma aprovação? Um usuário pode pertencer a duas organizações? O que acontece com registros compartilhados quando o proprietário sai? O cancelamento entra em vigor agora ou após o período pago? Se ninguém souber responder, o serviço deve precificar uma decisão de descoberta, não disfarçar uma decisão de produto como engenharia.

A integridade do banco vai além de consultas que funcionam

O auditor deve comparar o modelo de dados pretendido, o histórico de migrações e o esquema real de produção. Aplicações podem parecer funcionais enquanto dependem de campos de proprietário que aceitam nulos, IDs externos duplicados, texto onde deveria haver um estado restrito, chaves estrangeiras ausentes ou horários gerados de modo incoerente por vários clientes.

Comece pela estrutura: tabelas, colunas, tipos, padrões, chaves primárias, chaves estrangeiras, restrições de unicidade, restrições de verificação, índices, visualizações, funções, gatilhos e políticas RLS. Confirme se as migrações conseguem criar o esquema atual a partir de um banco vazio. Em seguida, compare o estado das migrações com produção. Mudanças manuais no painel que nunca entraram no controle de versão fazem parte do escopo de remediação, porque a próxima implantação pode apagá-las ou contradizê-las.

Execute consultas de integridade direcionadas de acordo com o modelo de negócio. Para uma aplicação com várias organizações, um ponto de partida útil é:

select id from projects where organization_id is null;
select external_id, count(*) from payments group by external_id having count(*) > 1;
select m.id from memberships m
left join organizations o on o.id = m.organization_id
where o.id is null;
select status, count(*) from orders group by status order by status;

A saída esperada é um conjunto vazio para as três primeiras verificações e um conjunto revisado de valores permitidos para a última. Resultados não vazios não são apenas tarefas de limpeza. Eles mostram qual invariante o esquema deixou de impor e onde o código da aplicação ainda pode criar linhas incorretas.

Inspecione os caminhos de acesso aos dados em busca de injeção e atualizações amplas acidentais. Bibliotecas de cliente parametrizadas ajudam apenas onde os desenvolvedores as usam corretamente. SQL dinâmico dentro de funções, filtros construídos como texto, auxiliares de consulta bruta e ferramentas administrativas ainda precisam de revisão. Procure também atualizações ou exclusões sem condições de organização, funções criadas com privilégios elevados e visualizações que expõem colunas escondidas na interface principal.

A existência de um backup não basta. A auditoria deve identificar a retenção, a conta que controla as restaurações, o backup bem-sucedido mais recente e se alguém testou uma restauração em ambiente separado. Um orçamento para mudanças invasivas no esquema precisa de um plano de retorno e verificação dos dados. Sem isso, «reparar o banco de dados» significa experimentar na única cópia que importa.

As dependências revelam dívida de manutenção e risco de execução

O auditor deve provar que o projeto instala e compila a partir de um checkout limpo, com um arquivo de bloqueio registrado. Uma implantação funcional criada meses atrás não mostra que um novo engenheiro consegue reproduzi-la. Projetos gerados costumam acumular bibliotecas de interface sobrepostas, envoltórios abandonados, SDKs sem uso e versões fixadas para silenciar um erro de compilação.

Registre a versão do ambiente de execução, o gerenciador de pacotes, o estado do arquivo de bloqueio, o comando de instalação, o comando de compilação e os avisos resultantes. Execute a ferramenta de alertas do ecossistema, mas interprete sua saída. A documentação do npm diz que npm audit relata vulnerabilidades conhecidas nas dependências configuradas. Ele não encontra uma falha de autorização em código personalizado, e um alerta em um pacote usado apenas no desenvolvimento não tem a mesma exposição que código de servidor acessível.

Uma captura de evidências útil para um projeto JavaScript é:

node -v
npm -v
npm ci
npm run build
npm audit

O relatório deve preservar os códigos de saída, o primeiro erro que permite uma ação, o artefato produzido e a saída da auditoria. Não aceite um orçamento que transforma cada alerta em uma tarefa de atualização de pacote. O serviço deve rastrear se o código vulnerável é distribuído, identificar a versão compatível mais segura e apontar atualizações que forçam mudanças de API ou framework.

A revisão da arquitetura deve ficar ao lado da revisão de dependências porque ambas afetam a mesma estimativa. Mapeie pontos de entrada, funções de servidor, estado compartilhado, clientes de dados e regras de negócio duplicadas. Conte cópias geradas apenas quando a quantidade muda o trabalho. Um único componente de 900 linhas que controla roteamento, busca de dados, validação e estado de janelas pode precisar ser separado antes de uma correção segura. Dez componentes organizados não precisam automaticamente de refatoração.

A recomendação popular de «reescrever tudo direito» costuma estar errada. As equipes gostam de reescritas porque a estimativa parece simples e ninguém precisa entender um código desconfortável. Uma reescrita também descarta casos de borda que funcionam, conhecimento sobre migrações e comportamentos de produção dos quais os usuários já dependem. A auditoria deve recomendar uma reconstrução apenas quando a base atual impedir a verificação ou o reparo, e deve nomear esse bloqueio.

Os testes precisam proteger a fronteira reparada

A auditoria deve medir se os testes detectam as falhas que o orçamento promete corrigir. Um selo, uma contagem de testes ou um comando verde têm pouco significado se a suíte simula todas as fronteiras e nunca verifica autorização, persistência ou novas tentativas.

Primeiro, execute os comandos existentes a partir de um checkout limpo e registre o que passa, falha, trava ou exige variáveis de ambiente não documentadas. Classifique os testes pelo que cobrem: funções puras, componentes, manipuladores de API, políticas de banco e fluxos completos de usuário. Em seguida, conecte cada descoberta de alto risco a um teste que falharia antes do reparo e passaria depois dele.

Para autenticação, use dois usuários e confirme a recusa de acesso cruzado. Para um evento de pagamento, repita o mesmo identificador e confirme apenas uma mudança no saldo. Para uma exclusão, confirme tanto a cascata pretendida quanto os registros que devem permanecer. Para uma migração, aplique-a em uma cópia semelhante à produção e execute as consultas de integridade. Esses testes produzem evidência de uma fronteira reparada, não apenas cobertura de código.

O orçamento deve declarar quais testes o serviço adicionará e onde eles serão executados. Também deve declarar o que continuará manual. Entrega de e-mail, configuração de contas de terceiros, comportamento de navegadores móveis e mudanças de DNS podem precisar de um roteiro de aceitação, em vez de um teste automatizado estável. Fingir que todo risco pertence a uma suíte de ponta a ponta infla o custo e produz testes frágeis.

Não use a porcentagem de cobertura como critério de aceitação, a menos que o serviço defina qual código conta e por que o limite importa. Uma suíte pequena em torno de identidade, dinheiro, ações destrutivas e separação entre organizações pode proteger uma remediação melhor do que centenas de testes de instantâneos.

A propriedade da implantação pode invalidar um reparo correto

O auditor deve acompanhar como um commit revisado se transforma na aplicação de produção e quem pode autorizar cada etapa. O código-fonte pode estar correto enquanto o site ativo aponta para outra ramificação, mantém variáveis antigas, executa uma função obsoleta ou é implantado por uma conta que o comprador não consegue acessar.

Registre a ramificação de produção, o comando de compilação, o diretório de saída, o ambiente de execução, os nomes das variáveis de ambiente, o gatilho de implantação, o mapeamento de domínio, o gerenciamento de TLS, a etapa de migração do banco e o método de retorno. Compare as configurações nos ambientes local, de prévia, de homologação e de produção. Os valores podem variar, mas sua finalidade e seu dono não devem ser um mistério.

Depois, faça uma verificação de procedência. Escolha um identificador de compilação inofensivo, coloque-o em um local de diagnóstico aprovado, implante pelo caminho documentado e confirme que a produção mostra o mesmo identificador. Isso detecta envios manuais, projetos paralelos e confusão de ramificações. Remova o identificador depois, se ele não tiver utilidade operacional.

A propriedade importa tanto quanto a configuração. O comprador deve controlar as contas da organização, o faturamento, os métodos de recuperação, os domínios e as credenciais de produção. O serviço de remediação pode precisar de administração temporária, mas a entrega deve deixar proprietários nomeados sob controle do comprador e remover colaboradores antigos. Senhas compartilhadas não são um plano de entrega.

A auditoria também precisa discutir indisponibilidade e retorno. Se uma migração do banco e uma versão da aplicação precisam entrar juntas, diga como a equipe impede que o código antigo leia incorretamente o novo esquema. Se o retorno não puder desfazer uma transformação de dados, use uma correção para a frente e um ponto de backup. Uma promessa genérica de «voltar se necessário» não cobre migrações destrutivas.

A FixMyMess oferece uma auditoria de código gratuita que cobre o diagnóstico antes de qualquer compromisso e pode fornecer essas evidências aos compradores que não conseguem inspecionar sozinhos um projeto gerado por IA. A entrega útil continua sendo a descoberta, sua prova, o reparo proposto e o proprietário necessário para concluí-lo.

Um orçamento defensável separa fatos de suposições

O orçamento final deve vincular preço e prazo a um registro de descobertas baseado em evidências. Cada linha precisa de um sintoma, uma causa raiz ou hipótese atual, o componente afetado, a gravidade, a ação de reparo, o método de verificação, a dependência e o estado do escopo. «Corrigir autenticação» não é um item de escopo. «Mover a atribuição de funções para o servidor, restringir atualizações de perfil e adicionar testes de política entre usuários» é.

Agrupe o trabalho em três categorias. Trabalho confirmado tem evidência e pode aceitar um preço fechado. Trabalho condicional tem um gatilho claro, como obter acesso ao banco ou encontrar linhas reais inválidas. Trabalho excluído fica fora do controle do serviço ou da decisão atual do comprador. Essa estrutura permite que o comprador compare orçamentos sem fingir que toda a incerteza desapareceu.

A gravidade e a confiança na estimativa devem continuar separadas. Uma falha crítica de autorização pode ser fácil de reproduzir e barata de corrigir. Uma inconsistência de dados de gravidade média pode exigir dias de análise porque ninguém sabe quantas linhas ela afetou. Um rótulo descreve o impacto; o outro descreve quanto o serviço entende o trabalho. Misturá-los incentiva auditores a cobrar demais por descobertas dramáticas e de menos pelas nebulosas.

Cada descoberta deve ter uma referência de evidência que o comprador possa examinar. Para uma leitura entre organizações, ela pode ser uma solicitação e resposta com dados ocultos, as identidades dos usuários e a política que permitiu a ação. Para uma compilação com falha, preserve o commit do checkout limpo, a versão do ambiente, o comando, o código de saída e o primeiro erro relevante. Capturas ajudam com a configuração de painéis, mas exportações em texto são mais fáceis de comparar após o reparo. Oculte dados pessoais e valores de credenciais, mantendo contexto suficiente para reproduzir o resultado.

As estimativas também precisam de unidades compatíveis com o trabalho. Orce uma migração definida com sua verificação como um item. Orce uma limpeza repetida por uma faixa declarada de registros ou por uma reserva de tempo com ponto de aprovação. Não esconda coordenação, transferência de contas, backup de dados e monitoramento da publicação dentro da gestão do projeto. Essas tarefas consomem tempo real e às vezes exigem ação do comprador ou de um fornecedor anterior.

O cronograma deve mostrar etapas de liberação, não apenas uma data de início e uma de entrega. Uma sequência prática pode exigir acesso às contas antes da verificação de políticas, aprovação do comprador sobre regras de negócio discutidas antes do reparo da lógica, um ponto de backup antes da migração e testes de aceitação antes da publicação. Se uma etapa depender de terceiros, nomeie a dependência e explique qual trabalho pode continuar durante o bloqueio.

O texto de aceitação deve descrever resultados observáveis. Por exemplo, «um usuário comum recebe uma resposta de recusa ao solicitar a fatura de outra organização» pode ser testado. «A autorização é segura» não pode. «A aplicação instala a partir de um checkout limpo e a compilação de produção termina com sucesso no ambiente registrado» é melhor do que «o código é estável». O mesmo padrão vale para o reparo de dados: informe a consulta de integridade e o resultado vazio esperado.

Os compradores devem perguntar como o serviço lida com uma descoberta que muda depois do início do trabalho. Um processo razoável mostra a nova evidência, explica por que a auditoria original não poderia revelá-la, declara o efeito no preço e no prazo e aguarda aprovação, a menos que uma ação imediata evite danos. Isso protege os dois lados. Também expõe auditorias fracas, pois descobertas comuns que deveriam ter aparecido durante a inspeção não podem ser renomeadas como surpresas.

Por fim, o orçamento deve dizer o que o comprador recebe na entrega. No mínimo, espere o código reparado, migrações, inventário de configuração sem valores secretos, testes adicionados, registro de descobertas com estado de resolução, instruções de implantação, registro de propriedade e riscos residuais conhecidos. A revogação do acesso deve ser uma tarefa declarada. Uma aplicação reparada sem registro operacional simplesmente vira o próximo mistério herdado.

Peça estes anexos ao orçamento:

• O registro de ativos e propriedade, com as lacunas de acesso.
• O registro de descobertas, com provas e limites do reparo.
• O plano de testes e aceitação para cada mudança de alto risco.
• O plano de implantação, migração, retorno e entrega.
• As suposições, exclusões e taxas ou regras de aprovação para o trabalho condicional.

O serviço também deve identificar as decisões que pertencem ao comprador. Engenheiros podem mostrar que dois comportamentos de cancelamento entram em conflito; não podem escolher a política comercial sem autoridade. Coloque essa decisão no cronograma com um responsável e uma data para que ela não se torne um atraso invisível.

Rejeite estimativas que dependam de adjetivos. «Pequena limpeza», «pronto para produção» e «reforço de segurança padrão» não podem ser aceitos nem testados. Um bom orçamento permite que outro profissional competente examine as mesmas evidências e entenda por que o trabalho existe. Se o acesso continuar ausente, o número honesto é uma fase de descoberta limitada seguida de um escopo revisado. Precisão inventada antes da inspeção é teatro de vendas, e aplicações herdadas já contêm ficção suficiente.