Um projeto não está preservado apenas porque ainda existe uma imagem dele. Também não está preservado porque o código aparece em algum disco antigo. Para que um trabalho continue verificável, quatro camadas precisam sobreviver juntas: fonte, executável, evidência e contexto.
Essa diferença ficou concreta ao revisitar projetos antigos do portfólio. Em Bolsa Formação, o site governamental que disponibilizava os módulos WebGL já não mantém o link. O acervo atual preserva frames e um reel, mas ainda não contém a tela de Settings que demonstrava recursos importantes de acessibilidade, nem confirma a recuperação do repositório e de uma build executável. O trabalho existiu; parte da prova deixou de estar imediatamente acessível.
O mesmo padrão aparece de outras formas em Radgear, cuja documentação atual preserva o protótipo e declara a build final como ausente, e em After the 7 Day, que ainda possui um rastro público no LinkedIn, mas precisa ter repositório, build e mídia localizados e catalogados. Esses registros são pistas, não substitutos para o artefato.
Resonance oferece o contraponto. A página da Global Game Jam preserva a primeira build, os arquivos-fonte, a equipe e a premissa original. O case atual também documenta como aquele protótipo evoluiu até uma campanha lançada. Mesmo esse cenário não elimina o risco de depender de um serviço externo, mas mostra quanto uma baseline histórica muda a qualidade da reconstrução.
Um link público é distribuição, não arquivo
WebGL torna esse problema especialmente visível. Um jogo pode depender do domínio que o hospeda, de políticas de segurança do navegador, de uma API remota, de certificados, de headers e de um serviço que a equipe não controla. Quando o site sai do ar, a URL deixa de provar que o produto funcionava.
Posts, páginas de eventos, lojas e portais institucionais continuam valiosos como evidência externa. Eles registram data, contexto e recepção. Porém, nenhum deles deve ser o único ponto de recuperação. Hospedagem pública e preservação técnica cumprem funções diferentes.
O mesmo vale para Git. Um repositório sem um commit estável, versão do motor, dependências e instruções de execução pode preservar texto, mas não necessariamente o comportamento. Uma pasta local com alterações não rastreadas também não é uma entrega recuperável. A história precisa chegar a um estado identificável.
As quatro camadas mínimas
1. Fonte reproduzível
O repositório precisa conter o código autorizado, manifests de dependência, versão do motor, configurações necessárias e instruções curtas de build. O estado preservado deve estar commitado e identificado por tag, release ou hash. Segredos e materiais privados permanecem fora do Git, acompanhados por uma descrição segura do que precisa ser reconfigurado.
2. Executável conhecido
Cada marco relevante precisa de pelo menos uma build que já tenha sido executada e verificada: binário desktop, pacote mobile ou export WebGL completo. A build deve registrar plataforma, versão, data, commit de origem e checksum. “Compilava na época” não oferece o mesmo nível de recuperação que um artefato conhecido.
3. Evidência navegável
Screenshots isolados raramente explicam um sistema. Recursos como alto contraste, navegação por foco, aumento de fonte ou narração precisam de capturas do estado inicial, da configuração e do efeito aplicado. Fluxos importantes pedem vídeo curto, sequência de frames ou roteiro de reprodução. A evidência deve mostrar o comportamento sem depender da memória de quem o implementou.
4. Contexto e proveniência
Um manifesto conecta projeto, versão, commit, build, mídia, autoria, autorização e links externos. Também distingue o que está preservado, o que foi apenas documentado e o que ainda precisa ser recuperado. Sem essa camada, arquivos sobrevivem, mas perdem significado.
A fila de recuperação também é documentação
O estado atual pode ser descrito sem esconder as lacunas:
| Projeto | Evidência disponível | Pendência de recuperação |
|---|---|---|
| Bolsa Formação | Frames e reel dos dois módulos WebGL | Repositório, build executável e tela de Settings com os modos de acessibilidade |
| Radgear | Frames do protótipo e direção posterior | Build final ausente e seu estado de fonte correspondente |
| After the 7 Day | Registro externo indicado no LinkedIn | Repositório, executável e pacote local de evidências |
| Resonance — Global Game Jam | Página da jam com build inicial, fonte, equipe e conceito; case da evolução posterior | Espelhar localmente o que for autorizado para reduzir dependência do serviço externo |
Essa tabela não diminui o trabalho. Ela evita que uma lembrança seja promovida a prova e transforma a busca futura em uma tarefa delimitada.
“Concluído” precisa incluir preservação
Para projetos futuros, o fechamento técnico não deveria terminar no deploy. Uma entrega só entra no arquivo quando:
- o estado relevante está commitado e identificável;
- existe uma build executável associada ao commit;
- os fluxos principais possuem evidência legível;
- dependências, plataforma e instruções de execução estão registradas;
- autoria, autorização e material sensível foram classificados;
- links externos foram catalogados como referências, não como cópia única;
- a recuperação foi testada fora da máquina em que o projeto nasceu.
O aprendizado não é guardar tudo indiscriminadamente. É preservar um conjunto pequeno e suficiente para responder, anos depois: o que era, o que fazia, como rodava, qual versão foi entregue e que evidência sustenta essa afirmação?
Quando essas respostas dependem apenas de memória, a dívida já existe. Catalogar fonte, executável e evidência no momento da entrega custa pouco; reconstruir o mesmo contexto depois que repositórios, máquinas e sites desapareceram custa muito mais — e às vezes não é possível.
