Confiança explicada
Subir todo o conteúdo de dist/cpanel/ para public html, incluindo .htaccess, robots.txt, sitemap.xml, llms.txt, leitura-simples.html, pages/, assets, downloads, benchmarks, quality, examples e playbooks. Os diretórios técnicos entram para auditoria e reprodução, mas robots.txt e .htaccess os marcam como material não editorial.
Subir todo o conteúdo de dist/cpanel/ para public html, incluindo .htaccess, robots.txt, sitemap.xml, llms.txt, leitura-simples.html, pages/, assets, downloads, benchmarks, quality, examples e playbooks. Os diretórios técnicos entram para auditoria e reprodução, mas robots.txt e .htaccess os marcam como material não editorial.
Ela separa progresso real de promessa ainda não comprovada.
Leia os requisitos P0 primeiro, porque eles bloqueiam a conclusão.
Só trate como fechado o que tiver evidência verificável.
Artigo exclusivo · leitura guiada
Este artigo organiza critérios de confiança para publicação, separando o que já tem evidência do que ainda precisa de prova.
Depois da leitura, revise as pendências e priorize o que melhora a confiança do usuário iniciante.
Você entende Prontidão de publicação sem precisar começar pelo jargão. A ideia central é: Subir todo o conteúdo de dist/cpanel/ para public html, incluindo .htaccess, robots.txt, sitemap.xml, llms.txt, leitura-simples.html, pages/, assets, downloads, benchmarks, quality, examples e playbooks. Os diretórios técnicos entram para auditoria e reprodução, mas robots.txt e .htaccess os marcam como material não editorial.
Use a leitura como checklist antes de divulgar uma recomendação, especialmente quando ela depender de medição ou comparação.
Leia primeiro Prontidão de publicação, Artefatos de descoberta, Upload cPanel e Antes de publicar no domínio público. Quando aparecerem termos como benchmark, cPanel, HTML e LLM, use o glossário desta página antes de seguir.
Promessa sem evidência não deve virar chamada principal do portal. Procure a prova antes de repetir uma conclusão.
Data da auditoria: 2026-07-08
| Artefato | Status | Observação |
|---|---|---|
robots.txt | gerado | Permite indexação e aponta para sitemap absoluto. |
sitemap.xml | gerado | 54 URLs absolutas geradas a partir do pacote. |
llms.txt | gerado | Resumo honesto para leitores automáticos e humanos. |
feedback.md | gerado | Modelo público para receber ZIP multi-chip, correções e sugestões sem pedir dados sensíveis. |
publication-status.md | gerado | Artefato de status; só vira pronto quando domínio e feedback externos forem comprovados. |
publication-handoff.md | gerado | Checklist operacional para upload, bootstrap do alvo público, live-check e registro sem editar hashes manualmente. |
| base URL | configurável | IA_NO_MAC_SITE_URL=https://ia-no-mac.com.br/ no build, padrão provisório https://ia-no-mac.com.br/. |
| repositório do painel | configurável | IA_NO_MAC_HUB_GITHUB_URL=https://github.com/USUARIO/ia-no-mac-hub ativa o botão do Hub no GitHub. |
Subir todo o conteúdo de dist/cpanel/ para public_html, incluindo .htaccess, robots.txt, sitemap.xml, llms.txt, leitura-simples.html, pages/, assets, downloads, benchmarks, quality, examples e playbooks. Os diretórios técnicos entram para auditoria e reprodução, mas robots.txt e .htaccess os marcam como material não editorial. O diretório downloads/ não é opcional: o gate externo precisa encontrar o ZIP do hub, o manifesto e os links declarados na home do domínio publicado.
IA_NO_MAC_SITE_URL=https://SEU-DOMINIO.com.br/ make cpanel-check
PYTHONDONTWRITEBYTECODE=1 python3 scripts/validate_data.pyTroque SEU-DOMINIO.com.br pelo domínio registrado. A URL base afeta somente links absolutos do sitemap e do robots. Configure IA_NO_MAC_HUB_GITHUB_URL apenas depois que o repositório real do painel existir no GitHub; antes disso, o botão permanece pendente.
O pacote já inclui feedback.md, com textos prontos para submissão multi-chip, relato de erro e sugestão de modelo. Isso prepara o fluxo público, mas não comprova domínio publicado nem canal externo ativo. Canal externo ativo significa URL pública funcional: formulário com <form>, action HTTPS, campo de mensagem e envio, ou issue tracker GitHub/GitLab apontando para criação de issue. Página placeholder contendo a palavra "Feedback" não fecha o gate. Quando o domínio estiver no ar, rode o live-check e registre a evidência com scripts/register_publication_evidence.py; não preencha hashes manualmente em data/publication-status.json.
Status: prepared.
| Check | Passou | Observação |
|---|---|---|
| CHANGELOG e RELEASE | sim | - |
| Template público de feedback | sim | - |
| Domínio público em HTTPS | não | URL ausente |
| Canal externo de feedback | não | canal externo não configurado |
| Manifesto público do deploy | não | manifesto de deploy não verificado |
| Evidência estruturada | não | - |
Bloqueios: domínio público ainda não comprovado, canal externo de feedback ainda não comprovado, manifesto público de deploy ainda não comprovado, evidência estruturada de domínio, feedback, manifesto e prova pública ainda não registrada
Evidência, limite e decisão · leitura de especialista
Leia esta página com duas lentes ao mesmo tempo: valor prático para o usuário e força da evidência técnica. O objetivo não é decorar jargão, é saber o que pode virar recomendação pública e o que ainda precisa de teste.
Checklist técnico: Evidência, Ambiente, Baseline, Métrica, Repetição, Erro, Risco, Limites e Decisão precisam estar claros antes de transformar qualquer afirmação em recomendação.
Critério de prontidão deve distinguir bloqueador, pendência, melhoria desejável e evidência já aceita.
Declarar pronto porque a página existe, não porque a afirmação foi testada.
O que ainda impediria uma publicação responsável se um especialista externo revisasse hoje?