AssetGuy

assetguy library lê o banco configurado. assetguy sync atualiza esses dados; assetguy search consulta o catálogo público da Fab; assetguy download busca os arquivos. Essa separação explicita o custo de cada ação. assetguy add exige os arquivos no cache e, quando faltam, indica o comando de download em vez de transferir gigabytes silenciosamente.

URLs de thumbnails chegam nos metadados, mas baixar as imagens é opcional: o terminal não as desenha e uma biblioteca grande pode conter gigabytes de imagens. A interface começa pela CLI para estabilizar o comportamento antes que uma GUI dependa dele.

O catálogo pode ficar desatualizado entre sincronizações. Aceitei essa troca para que uma consulta tenha custo previsível e não dependa da disponibilidade do marketplace. Metadados ausentes continuam visíveis: uma listagem vazia não prova que não existam assets compatíveis.

A biblioteca possuída, detalhes públicos, busca pública e CDN da Fab têm requisitos de autenticação diferentes. Um cliente HTTP autenticado genérico levaria premissas erradas de uma rota para outra. O contrato de provider descreve operações como assets possuídos, detalhes de listing, autenticação e entrega.

Papéis e capacidades separados permitem explicar pelo nome uma operação sem suporte. Fab é o provider implementado hoje. A fronteira do download é um DownloadPlan: o provider converte o manifesto em plano; busca de chunks e montagem de arquivos usam esse plano sem depender dos tipos da API da Epic.

Essa fronteira permite testar o workflow sem depender dos detalhes HTTP e concentrar mudanças da API da Fab na implementação do provider. Ela ainda não comprova suporte a outra loja: um segundo provider terá de satisfazer esses contratos com seus próprios casos reais.

SQLite é o padrão sem configuração; PostgreSQL já está implementado. O backend escolhido guarda catálogo, curadoria e estado de download/instalação. Quatro papéis estreitam o acesso de cada chamador: AssetStore, CatalogWriteStore, CurationStore e DownloadStore. Um download não precisa poder reescrever regras de categorias.

Os contratos de storage usam chamadas síncronas, acompanhando o driver bloqueante do SQLite; operações de provider e rede são assíncronas. SQL específico fica atrás de uma fronteira de dialeto. A escolha do backend é configuração persistente; conexão inválida falha explicitamente em vez de abrir outra biblioteca. Trocar de banco não migra os dados existentes.

Escolhi SQLite como padrão para que o uso individual não exija administrar um servidor. PostgreSQL atende à necessidade de um catálogo comum, com o custo de conexão, credenciais e operação do banco. Compartilhar metadados e caminhos não torna os arquivos disponíveis em outras máquinas; isso exige o cache compartilhado ainda não implementado.

Categorias próprias expressam regras de correspondência em vez de um conjunto congelado de tags. Novos assets sincronizados podem entrar automaticamente na mesma organização. Versão de engine, formato, categoria da loja e estado de cache são filtros separados porque respondem perguntas diferentes.

Versões Unreal são comparadas por componentes: UE4.1 não pode significar também UE4.10. Metadados de engine e formato permanecem separados; um formato Unity não implica que a Fab forneça suas versões. Metadados ausentes e cobertura parcial da busca são informados, evitando interpretar resultado vazio como conhecimento completo do marketplace.

O sync primeiro busca a lista possuída, cuja paginação por cursor é sequencial. Depois enriquece cada asset com detalhes usando workers paralelos limitados. O orçamento de requisições controla a pressão sobre a API; não é apresentado como porcentagem da velocidade da conexão.

A lista possuída usa a sessão da conta, enquanto detalhes públicos usam um cliente anônimo. A distinção vem do comportamento observado da API. Um listing público removido ainda pode ser possuído e baixável; um tamanho ausente é desconhecido, não zero. Inspecionar o manifesto é uma operação separada para descobrir tamanhos Unreal.

Downloads buscam chunks em paralelo, mas montam arquivos com um writer ordenado, calculando SHA1 enquanto os bytes são escritos. Arquivos completos e verificados compõem o estado de retomada; a identidade do manifesto impede misturar builds diferentes. Os arquivos saem do diretório parcial somente após concluir o trabalho.

Chunks usados por vários arquivos têm um cache limitado em memória. Como o plano conhece a ordem de escrita, a remoção descarta o chunk cujo próximo uso está mais distante. Isso troca uma eventual nova busca por um teto previsível de memória, sem guardar o asset inteiro duas vezes no disco.

O writer ordenado simplifica a verificação e a retomada, mas pode esperar um chunk atrasado enquanto outros já chegaram. O limite de cache pode exigir buscar um chunk novamente. A escolha prioriza integridade e memória previsível em vez de maximizar paralelismo a qualquer custo.

Content packs entram em Content do projeto; projetos completos podem ser copiados como projetos; plugins de engine seguem os caminhos do manifesto. Dry run permite inspecionar a ação, e colisões exigem force explícito. Cópias são preparadas no volume de destino; staging de engine fica fora da pasta que o scanner de plugins lê.

Instalar plugins exige a raiz exata de uma engine registrada. Os arquivos vêm antes dos registros do launcher; a instalação mantém manifesto, item, lista de instalados e registros EOSH. Backups e leitura de conferência protegem a atualização da lista. O launcher precisa estar fechado porque pode reescrever os registros a partir do estado em memória.

Uma instalação de conteúdo num projeto e uma instalação de plugin na engine afetam estruturas diferentes. Mantê-las como comandos separados torna o destino e o efeito explícitos. A integração com os registros do launcher é a parte mais sensível: copiar a pasta sozinha não basta para que a ferramenta da Epic reconheça a instalação e sua remoção.

A configuração fica no perfil roaming; credenciais OAuth, cache e arquivos de auditoria ficam no perfil local. O login ocorre no navegador e retorna um código de autorização, ocultado na auditoria pela identidade do comando. Senhas de banco são fornecidas separadamente da URL de conexão armazenada.

O estado do launcher é somente leitura durante consulta e sincronização. install, uninstall e repair são as exceções explícitas que escrevem seus registros. A auditoria mensal local registra operações; doctor expõe problemas de integridade e estado sem exigir que um desenvolvedor invente consultas de diagnóstico.