Implementação de Collections

CollectionPath reconhece o primeiro segmento de Collection, extrai o nome e remove o segmento para o cálculo da rota. CollectionStructureValidator indexa configurações e páginas-mãe pelo nome, explicando por que a unicidade precisa ser global.

CollectionConfigLoader interpreta _collection.yaml, valida defaults sem exigir título, valida as configurações opcionais llms_full e mdx_source e resolve type por TypeExtensionRegistry. O registry percorre classes concretas de Core\Head\Social\OpenGraph, mantém as que implementam TypeExtension e compara o retorno estático de slug(). Nenhum mapa central de slugs é mantido.

CollectionDefaultsMerger converte a metadata tipada do item de volta para array, constrói um bloco social Git apenas para Article e usa array_merge na ordem Collection, Git, item. O resultado é validado e hidratado novamente.

Datas são obtidas por GitFileDates, que executa git log de forma síncrona. O provider solicita criação e modificação para o enriquecimento; ContentSummaryFactory solicita criação para a ordenação e usa filemtime() quando Git não responde.

aggregateCollectionItems() cria os resumos e ordena timestamps de forma decrescente. injectItemsIntoParents() adiciona todas as Collections irmãs relevantes às páginas-mãe e adiciona a própria Collection a cada item.

Cada summary MDX também recebe readingTime, calculado durante a construção da rota. Items Blade mantêm esse campo nulo, pois a engine não tenta interpretar templates executáveis como texto legível.

Além das rotas, a descoberta conserva os corpos Markdown já separados do front matter para llms_full e o raw completo — incluindo front matter — para Collections que habilitam mdx_source. O RouteCatalog armazena esses resultados durante o build; assim, os geradores não relêem arquivos nem repetem parsing de YAML. Essa retenção opt-in evita aumentar a memória de Collections comuns.