req-146: O pipeline de sincronização nunca remove — arquivo apagado no core sobrevive no destino

• Status do intake: backlog-v3.0

• Data: 2026-08-29 (movido para backlog em 2026-08-31 por decisão do operador)

• Origem: achado durante o BATCH-148, ao remover 64 arquivos não usados do DataTables

• Classificação: arquitetura de deploy, superfície exposta, segurança, baseline v3.0

• Batch candidato: Backlog Linha 3.0 (revisão total de pipelines e eliminação do Fomantic)

1. O que foi medido

Ao remover 64 dos 67 arquivos de gestor/assets/datatables/ no core e rodar os dois pipelines oficiais (manager:update-all e project:update-all [REDACTED]-local):

Os arquivos removidos continuavam respondendo HTTP 200 no runtime.

Nenhum dos comandos de sincronização (ManagerSyncFilesCommand, ProjectSyncCoreCommand, ProjectSyncFilesCommand) contém unlink, rmdir ou qualquer forma de poda. A sincronização é puramente aditiva: ela copia o que existe, e nunca remove o que deixou de existir.

2. Por que isso importa mais do que parece

O caso que revelou o problema era inofensivo — arquivos de tema de Bootstrap que ninguém usa. Mas o mecanismo não distingue:

1. Segurança: remover um arquivo do core PORQUE ele é vulnerável não o remove de lugar nenhum. Ele continua servido, com a mesma URL, em todos os ambientes já sincronizados. Quem auditasse o repositório concluiria que o arquivo foi eliminado.

2. Bibliotecas antigas convivendo com novas: a migração planejada do DataTables para a próxima major deixaria a versão 1.10.23 inteira viva ao lado da nova, servida e alcançável.

3. Auditoria mente: o inventário de dependências feito sobre o core não descreve o que está publicado.

A limpeza do espelho local, neste lote, foi feita à mão justamente porque o pipeline não sabe fazê-la — o que confirma a lacuna em vez de resolvê-la.

3. Por que não corrigi junto

Poda é destrutiva por natureza, e o destino contém coisas que o core não conhece.

Confirmado pelo Engenheiro Chefe (2026-08-29): estas pastas são do PROJETO, acabam vivendo dentro do gestor e não devem ser removidas — o sistema inclusive escreve em logs/ durante a operação.

• contents/files/ — mídia enviada pelo operador;

• contents/project/ — assets do projeto (inclusive as fontes geradas no BATCH-148);

• autenticacoes/ — .env por host;

• logs/ — escrito pelo sistema em runtime, portanto sempre "extra" em relação ao core.

Isso muda o desenho da solução: a poda não pode ser "remover tudo que não veio do core". Ela precisa de uma ALLOWLIST de diretórios que são espelho puro (assets/, modulos/, bibliotecas/, controladores/), e nunca uma lista de exceções — porque a lista de exceções só precisa estar incompleta uma vez para apagar dado de cliente.

4. Esboço de escopo

1. Poda restrita a diretórios que são espelho puro do core (assets/, modulos/, bibliotecas/, controladores/), com allowlist explícita — nunca por exclusão. Confirmado com o operador: contents/, autenticacoes/ e logs/ são do projeto e ficam permanentemente fora.

2. --dry-run como padrão: o comando relata o que removeria e só apaga com confirmação.

3. Relatório do que foi removido, para o deploy ficar auditável.

4. Respeitar a trava de local do environment.json, como css:rebuild e assets:fonts.

5. Teste garantindo que contents/, autenticacoes/ e logs/ nunca entrem na varredura.

5. Recomendação lateral (DataTables)

Quando a migração de major do DataTables acontecer, o caminho é registrá-lo em bibliotecas/assets-externos.php, como jQuery, CodeMirror e Fomantic. Hoje ele é vendorizado à mão, então a versão não tem dono declarado e a atualização é uma troca manual de arquivos. No registro, virar de major é mudar uma linha — e c2f assets:vendor baixa o resto.

O sistema usa exatamente três arquivos (datatables.min.js, datatables.min.css e 1.10.23/pt_br.json), o que torna a entrada no registro trivial.