📱 Plano de Melhoria: Layout Responsivo das Páginas de Índice

Escopo: as ~40 páginas index.md de módulo/especialização/guia (não os capítulos individuais, que já passaram por trabalho de navegação nas sessões anteriores). Foco nas 3 telas pedidas: computador, tablet, celular.

1. Diagnóstico — o que já está bem resolvido (auditoria do CSS real, 2026-09-05)

Antes de propor mudanças, auditei assets/css/style.scss (1036 linhas) e o breakpoint do tema para não propor retrabalho. Resultado: a base já é sólida, melhor do que uma primeira impressão sugeriria.

Conclusão intermediária: os 3 elementos que eu esperava que fossem o maior risco (tabela larga, grid de cards, diagrama grande) já não quebram o layout em telas estreitas. O trabalho pendente é mais cirúrgico do que uma reforma geral.

2. O gap real: a faixa de tablet (768–1024px) nunca foi ajustada de propósito

O CSS custom tem apenas 2 media queries, ambas herdadas da migração do tema Cayman e cosméticas, não estruturais:

@media (max-width: 600px) { /* posição do toggle de dark mode, botão back-to-top */ }
@media (max-width: 768px) { /* opacidade do botão de copiar código */ }

Ou seja: celular (<600px) recebeu atenção real em várias sessões (toggle de sidebar, cabeçalho, TOC). Desktop (>1024px) é o alvo de design padrão do tema. Mas a faixa de tablet (600–1024px) — onde a sidebar da Minimal Mistakes muda de comportamento (deixa de ser fixa, mas a tela ainda é larga o bastante pra não ativar as adaptações pensadas pra celular) — nunca foi testada ou ajustada deliberadamente.

⚠️ Nota de transparência sobre a verificação visual

Tentei confirmar isso ao vivo redimensionando a janela do Chrome pra 3 tamanhos (1440×900 desktop, 820×1180 tablet, 390×844 celular) e comparando capturas de tela. A ferramenta de resize não alterou o viewport efetivo da página nesta sessão (as 3 capturas saíram idênticas), então não tenho confirmação visual real dos 3 tamanhos — a análise acima é baseada em auditoria do código-fonte CSS, não em teste visual ao vivo. Antes de implementar qualquer item deste plano, o próximo passo deveria ser abrir o DevTools do navegador (F12 → Toggle Device Toolbar) manualmente e testar de verdade, já que a ferramenta automatizada não serviu para isso desta vez.

3. Itens de investigação/ação recomendados (nenhum executado ainda)

4. Abordagem recomendada

1. Testar antes de codar. Usar o DevTools real (não a ferramenta de resize automatizada, que falhou nesta sessão) nos 3 tamanhos de referência: 390×844 (celular), 820×1180 (tablet retrato, iPad-like), 1440×900 (desktop). Screenshot de 2-3 páginas representativas: index.md raiz (hero + cards), um mod_*/index.md com tabela “Matriz Curricular” (ex.: mod_02), e proj_aplicacoes_full_stack/projetos_status.md (tabela mais complexa + filtros).
2. Só then decidir se algum item da tabela da Seção 3 é um bug real ou se — como já aconteceu com tabelas/cards/mermaid nesta auditoria — já está adequado e a suspeita não se confirma.
3. Corrigir cirurgicamente, um media query por vez, sempre no range $medium (768px) do próprio tema em vez de inventar breakpoints novos — para ficar consistente com o resto do CSS do tema.

5. Encerramento (2026-09-05) — nenhuma ação necessária

Tentei de novo o teste automatizado de viewport (resize_window + leitura de window.innerWidth via JS) numa sessão seguinte — mesma limitação: o innerWidth não muda, permanece no tamanho real da janela (1920px) independente do tamanho pedido. Não há, nesta ferramenta de automação de navegador, um mecanismo de emulação de dispositivo em nível de CDP (Emulation.setDeviceMetricsOverride) equivalente ao DevTools real — só JS de página, que não consegue sobrescrever innerWidth.

Na ausência de confirmação visual, fiz uma auditoria de código mais profunda dos 5 itens da Seção 3 antes de tocar em qualquer CSS:

• Item 2 (cabeçalho/hero) estava baseado numa premissa errada: a classe .page-header do assets/css/style.scss (com o padding: 3rem 1.5rem citado) é usada exclusivamente por _layouts/slide.html (chrome residual do tema Cayman, fora do escopo deste plano). A home e os index.md de módulo usam layout: default puro do Minimal Mistakes — só um <h1> estilizado pela tipografia própria do tema, já madura e responsiva, fora do alcance seguro do nosso CSS customizado.
• Item 1 (sidebar/TOC 768–1024px): comportamento nativo do tema, não do nosso CSS — sem evidência de bug real, arriscado sobrescrever às cegas.
• Item 3 (affordance de scroll em tabelas largas): já funciona (overflow-x: auto); item de polimento, não bug confirmado.
• Item 4 (.filter-btn em telas estreitas): o container já tem flex-wrap: wrap inline em projetos_status.md — nada quebrado.
• Item 5 (:hover em touch): navegadores já simulam hover-no-toque de forma aceitável — sem bug confirmado.

Decisão do usuário: encerrar o plano sem alterações de código. Nenhum dos 5 itens tinha um bug confirmado e seguro de corrigir dentro do CSS próprio, e a limitação de emulação de viewport impede confirmação visual real nesta ferramenta. Se um problema real de tablet aparecer no futuro, o caminho é reportar o sintoma específico visto num dispositivo/DevTools real, não reabrir esta auditoria especulativa.