samykabu/github-wiki-publish

Publicação no Wiki do GitHub

Publique o material solicitado no Wiki existente do repositório. Mantenha a geração de conteúdo separada da publicação: use as páginas, relatórios e ativos fornecidos, adaptando links e navegação conforme necessário. Siga as regras do projeto alvo sem importar convenções de outro projeto.

Estabeleça o destino e o escopo

• Resolva o host do GitHub, repositório, URL do Wiki, arquivos de origem e nomes de página pretendidos a partir do contexto da solicitação e do repositório. Pergunte apenas sobre opções não resolvidas que alterem materialmente a publicação.
• Diferencie preparação de publicação. Uma solicitação explícita para publicar autoriza a atualização nomeada do Wiki; não pergunte novamente pela mesma ação. Uma solicitação de rascunho ou avaliação por si só não autoriza um push.
• Descubra primeiro os recursos relevantes do conector. Se eles não conseguirem gerenciar conteúdo e ativos do Wiki adequadamente, use o repositório Git separado do Wiki. Explique a alternativa resumidamente. As APIs comuns de Conteúdo do repositório não tratam do repositório do Wiki.
• Verifique o acesso usando a conexão autenticada existente ou credenciais Git. Nunca incorpore credenciais em URLs, páginas ou evidências retidas. Um 404 não autenticado não prova que um Wiki privado está ausente.
• Se nenhum repositório Git do Wiki existir, verifique se o Wiki está desabilitado ou precisa que sua primeira página seja criada através do GitHub. Não habilite recursos do repositório nem altere o acesso como efeito colateral. Use uma criação autorizada da primeira página quando possível; caso contrário, relate o pré-requisito específico ausente.

Prepare uma atualização limitada

Para publicação via Git, leia o procedimento Git. Use um clone limpo temporário, descubra seu branch padrão real e leia as páginas de destino existentes, Home e barra lateral antes de escrever.

• Mapeie cada arquivo de origem para uma página ou ativo de destino. Preserve páginas não relacionadas, seções escritas manualmente e navegação. Um arquivo de origem ausente não é uma instrução de exclusão. Substitua uma página inteira apenas quando ela pertencer à atualização solicitada; use uma edição estreita para conteúdo compartilhado da Home/barra lateral. Mantenha links existentes e evite entradas de navegação duplicadas em execuções repetidas.
• Leia e escreva texto explicitamente como UTF-8. Copie ativos binários byte por byte. Não repare silenciosamente fatos de origem nem atualize um relatório a partir de um conjunto de dados diferente. Preserve sua data real, proveniência e limitações; use o gerador upstream apropriado apenas se a regeneração estiver no escopo.
• Reescreva links para o destino real do Wiki. Links relativos ao repositório podem quebrar após mover uma página. Copie ativos referenciados ou vincule a uma revisão acessível do repositório; não deixe caminhos locais, links de branch não publicado ou recursos externos inacessíveis.
• O Wiki mostra o nome do arquivo da página como seu título, portanto, uma página que começa com seu próprio H1 o exibe duas vezes. Remova esse H1 e nomeie a página com base nele, mantendo um H1 apenas quando ele diferir intencionalmente do nome da página (como Home); atualize a navegação para os nomes derivados. Home é servida em /wiki, então seus links relativos resolvem fora do Wiki: use URLs absolutas do Wiki para imagens, links de página e a barra lateral.
• Use imagens inline suportadas com texto alternativo significativo. Para um relatório HTML ou diagrama animado/interativo, forneça uma prévia estática útil e links para o artefato original quando o Wiki não puder renderizá-lo. Não descreva HTML baixável como um aplicativo servido dentro do Wiki. Siga ferramentas de diagrama específicas do projeto ao gerar novos gráficos que estiverem no escopo; nenhum gerador específico é exigido por esta skill.
• Verifique links locais e ativos, texto não ASCII representativo e os caminhos exatos alterados. Inspecione o diff final para exclusão não intencional, conteúdo sobrescrito, credenciais e detritos gerados. Mantenha clones temporários e evidências locais fora do repositório da aplicação, a menos que o usuário ou projeto exija fontes retidas lá.

Publique e verifique

Aplique a publicação apenas dentro da autorização existente do usuário. Uma atualização do Wiki não autoriza push de um branch da aplicação, alterar issues, implantar um site, agendar sincronização ou instalar CI.

• Faça commit apenas dos caminhos do Wiki pretendidos, depois busque e reconcilie alterações concorrentes conforme descrito no procedimento Git. Faça push normalmente para o branch padrão descoberto do Wiki. Nunca force-push para superar outro escritor.
• Em caso de rejeição, busque e inspecione uma vez. Integre edições compatíveis e verifique novamente o diff completo. Se o mesmo conflito se repetir, a intenção não puder ser resolvida ou o acesso falhar, pare as tentativas e retenha o clone recuperável com um bloqueador preciso. Não o exclua em caso de falha.
• Verifique o commit publicado contra o repositório remoto ativo. Uma árvore de trabalho limpa por si só não prova que commits locais foram enviados.
• Inspecione a página efetivamente servida através de um navegador autenticado quando disponível: texto da página, Unicode representativo, navegação, links, carregamento de imagens e legibilidade. Para gráficos, compare o resultado renderizado com os fatos de origem. Verifique uma imagem em tamanho real quando sua prévia inline obscurecer rótulos. Corrija defeitos observados dentro do escopo e verifique novamente o conteúdo afetado.
• Se a verificação renderizada autenticada não estiver disponível, relate a publicação e a verificação remota separadamente da verificação de navegador não executada. Não reivindique uma aprovação renderizada a partir de arquivos locais, uma resposta HTTP ou um push bem-sucedido.

Relate a URL da página, revisão publicada, alterações materiais, verificações realizadas e qualquer limitação não resolvida. Mantenha caminhos de recuperação quando o trabalho permanecer não publicado. Não adicione um novo gate de aprovação, esquema de conteúdo, ciclo de vida do projeto ou regime de teste.