Documentação por visibilidade e comunidade

Público e privado

Público: Wiki é fonte oficial; README apresenta brevemente e liga Wiki, Discussions e painéis. Privado: locais e procedimentos existentes permanecem. Licenças, arquivos de comunidade, instruções das IAs, modelos, contratos e configuração necessários à execução continuam no código. Remover Markdown não remove contrato consumido pelo programa.

Ciclo de documentação

1. Conferir visibilidade real, Wiki habilitada, Home e acesso; em falha preservar os originais.
2. Inventariar funcionalidades reais, requisitos e testes; mapear páginas pelos identificadores lógicos.
3. Atualizar conteúdos afetados, capturar hashes das fontes após revisão e enviar proposta Git separada da Wiki.
4. Revisar diff de código e documentação no mesmo PR, registrando base e SHA da Wiki.
5. Validar conteúdo, matriz, links, imagens e navegação; publicar com comparação da base e push normal.
6. Confirmar HEAD publicado; somente então remover originais e corrigir consumidores.
7. CI e portão de produção bloqueiam ausência, cobertura incompleta e falha de publicação, inclusive Flash.

A matriz cobre funcionalidades/módulos por fontes reais e cenários existentes; existência de páginas não substitui revisão de seus fluxos. Hash novo não autoriza simplesmente repetir prosa antiga. Código documentado e Wiki possuem SHAs separados no manifesto e no PR.

Discussions, Projects e Social preview

A IA publica o primeiro post factual com marcador idempotente bigbang:discussions:welcome:v1. Atualizações não recriam boas-vindas. Painéis públicos exigem auditoria de conteúdo/campos e confirmação de leitura anônima; a mudança não concede escrita ao público nem reduz permissão do colaborador.

Social preview é preparado no design e conferido em criação/atualização: PNG/JPG/GIF, idealmente 1280×640, menos de 1 MB. O GitHub documenta upload pela interface Settings → General → Social preview. Este ambiente não oferece a interface autenticada para upload, por isso a imagem está preparada e a instalação personalizada fica pendente, sem bloquear a entrega funcional nem inventar conclusão.

Critérios e conteúdo obrigatório

Produto, planejamento, tecnologia, arquitetura, design, requisitos, fluxos funcionais, uso, referência técnica, segurança, operação e histórico possuem destino na Wiki. Conteúdo não aplicável deve ter motivo. O manifesto não deve aceitar ausência como N/A sem justificativa; funcionalidades planejadas não são registradas como entregues.

Bootstrap de validadores anteriores à Wiki

O código confiado da branch de destino julga o PR, e versões anteriores à 2.0.0 leem RNs locais e tabela STACK. Preserve somente esses contratos efetivamente consumidos, com motivo concreto e temporário em arquivos_funcionais, enquanto atualiza o framework da branch confiada. A Wiki já é a fonte oficial. Depois, remova entradas e exceções em outra tarefa/PR com CI e revisão independente; a migração não está concluída até removê-las. Não desligue portões nem modifique aceites.

Badges Markdown aninhados têm dois destinos: imagem e link externo do badge. O validador 2.0.1 confere ambos; páginas, imagens e âncoras internas ausentes impedem entrega. Links externos de outros sites exigem revisão factual separada.