Revisar novos envios para um catálogo de recursos técnicos

## Usar um único arquivo do catálogo como base e gerar dele o site e os dados Trate um único documento de catálogo legível por pessoas como a fonte oficial. Gere índices, conjuntos de dados estruturados e páginas estáticas a partir dessa fonte, em vez de editar artefatos derivados separadamente. Organize as entradas por categorias temáticas, não por títulos de linguagem de implementação. Registre o suporte a linguagens como etiquetas em linha para que um recurso possa declarar várias linguagens sem mudar sua categoria temática. Documente o fluxo de dados: 1. O documento do catálogo armazena as entradas selecionadas. 2. Um analisador valida as entradas, complementa metadados externos aprovados e grava um conjunto de dados estruturado. 3. Um gerador do site lê o conjunto de dados quando ele existe; caso contrário, analisa o catálogo diretamente para prévias locais. 4. A integração contínua executa o analisador e o gerador e depois publica somente o diretório gerado do site. Mantenha o comportamento do analisador, do gerador e da implantação alinhado a esse contrato. Não transforme uma página ou um conjunto de dados gerado em outra fonte oficial concorrente. ## Escrever cada entrada do catálogo no mesmo formato, com etiquetas de linguagem Defina uma única estrutura de entrada reconhecível pelo analisador e trate a pontuação como parte do contrato. Uma entrada típica contém um nome com link, uma ou mais etiquetas de linguagem em linha e uma descrição: ``- [Name](https://example.org) - `Language` - Description.`` Aplique estas regras: - novas entradas não comerciais devem conter ao menos uma etiqueta de linguagem seguida pelo separador obrigatório; - as descrições devem terminar com ponto antes de qualquer link opcional para o repositório de origem; - novos links devem usar `https://`; - recursos comerciais ou proprietários pertencem a uma categoria própria; - etiquetas de linguagem só podem ser omitidas em categorias comerciais ou explicitamente alheias a linguagens; - o guia de contribuição voltado às pessoas usuárias continua sendo a fonte oficial para quem envia entradas. Aceite várias etiquetas de linguagem sem alterar a estrutura ao redor. Permita um link opcional para o repositório depois da descrição completa. Mantenha válidos os links de pacotes específicos de um ecossistema quando seguirem a mesma gramática de entrada. Não flexibilize o padrão do analisador por causa de uma única entrada malformada. ## Revisar com rigor as entradas novas e apontar as antigas só como avisos Use o ambiente e os invólucros de tarefas documentados no repositório para validar, analisar e publicar. Respeite a versão exigida do ambiente de execução e instale as dependências pelo comando oficial. Use dois modos de validação: 1. A validação de mudanças verifica apenas as entradas adicionadas em relação à revisão-base escolhida. 2. A validação do catálogo completo verifica todas as entradas. Para entradas novas, trate duplicatas, links malformados e violações da política de URL como erros. Para o catálogo completo, relate problemas antigos equivalentes como avisos, salvo quando opções estritas forem escolhidas explicitamente. Não deixe que a dívida antiga tolerada reduza o critério de admissão de novas entradas. Execute o analisador somente quando as credenciais necessárias estiverem disponíveis. Permita que o gerador do site use um conjunto de dados estruturado existente ou a alternativa documentada de análise direta para prévias locais. ## Revisar só os envios indicados e procurar duplicatas Limite a revisão aos envios indicados pela pessoa usuária. Para operar solicitações de alteração, use o conector configurado do repositório, não um cliente de linha de comando sem relação. Antes de qualquer ação que modifique dados: 1. Inspecione os arquivos propostos e as diferenças. 2. Verifique a posição da categoria e o formato exato da entrada. 3. Procure duplicatas no catálogo que atua como fonte oficial. 4. Verifique a formatação segura das URLs. 5. Avalie com evidências a atividade atual do projeto e sua documentação. 6. Apresente as constatações antes de alterar o estado externo. Não revise envios adicionais apenas porque estejam abertos. Não deduza popularidade nem estado de manutenção somente pela descrição enviada. Diferencie a conformidade com o formato do catálogo da qualidade e da utilidade contínua do recurso. ## Perguntar antes de comentar ou mesclar uma solicitação de alteração Sempre pergunte à pessoa usuária antes de comentar, etiquetar, fechar ou mesclar uma solicitação de alteração. Aplique a etiqueta de revisão concluída somente depois que a pessoa usuária aprovar o comentário de revisão. Mescle somente após receber aprovação explícita para aquela mesclagem. Use as ferramentas conectadas do repositório para listar solicitações abertas; inspecionar detalhes, arquivos, comentários, etiquetas e diferenças; buscar o catálogo do ramo padrão para verificar duplicatas; e executar mudanças aprovadas. Nunca substitua o conector necessário por outra ferramenta externa quando ele não estiver disponível. Se o conector estiver ausente, informe que as operações do repositório estão bloqueadas e peça à pessoa usuária que o configure. Separe a coleta de evidências somente para leitura das alterações externas. Uma instrução para revisar não autoriza, por si só, comentários, etiquetas, fechamentos nem mesclagens. ## Manter a credencial de acesso em segredo e publicar o site só pelo processo automático Trate o enriquecimento de metadados externos como uma operação que exige credenciais. Não o execute sem a credencial de acesso necessária e nunca exponha essa credencial em comandos, relatórios, páginas geradas ou arquivos confirmados. Mantenha a publicação reproduzível: - analise o catálogo oficial e converta-o no conjunto de dados estruturado documentado; - permita que prévias locais usem somente a alternativa documentada; - gere a página estática a partir da entrada atual validada; - publique somente pelo fluxo configurado de integração contínua; - revise as mudanças geradas quando o comportamento do analisador ou do modelo mudar. Não afirme que a publicação foi bem-sucedida com base apenas em uma prévia local. Verifique separadamente o artefato gerado e o fluxo de publicação. ## Relatar o que foi revisado, separando erros novos de avisos antigos Relate os envios revisados, as constatações, o modo de validação e qualquer operação bloqueada. Informe se as verificações cobriram somente entradas novas ou todo o catálogo. Separe os avisos originados pelo conteúdo antigo dos erros introduzidos pela mudança atual. Antes de concluir, confirme: - o catálogo permaneceu como fonte oficial; - a gramática, a pontuação, as etiquetas, as categorias e as URLs seguras foram verificadas; - as duplicatas foram verificadas em relação ao ramo padrão atual; - as afirmações sobre atividade e documentação se basearam em evidências; - nenhum estado externo foi alterado sem aprovação; - artefatos gerados não foram confundidos com conteúdo-fonte oficial. Mantenha o relatório conciso o suficiente para apoiar uma decisão, mas inclua toda constatação capaz de mudar a admissão.