🧭 Plano de Melhoria: Acesso, Leitura e Sequência Didática Teoria ⇄ Prática

Foco: experiência do aluno navegando o portal — não conteúdo, não infraestrutura de build. Os relatórios em RELATORIO_AUDITORIA_40_CURSOS já certificam completude de conteúdo (100% dos 800 capítulos com tópico/slide/quiz/exemplo/exercício). Este plano ataca um problema diferente: o aluno consegue seguir um fio condutor fluido da teoria até a prática real, sem se perder ou precisar adivinhar o próximo passo?

1. Diagnóstico (evidências coletadas em 2026-09-05)

1.1 Não existe navegação Anterior/Próximo entre capítulos

Ao final de um tópico o aluno só encontra uma tabela de recursos irmãos (slides/quiz/exemplos/exercícios) e, às vezes, um link ⬅️ Voltar ao Sumário do Módulo. Não há ➡️ Próximo Capítulo em nenhum dos dois formatos de rodapé encontrados (mod_02/topicos/05...md vs mod_02/topicos/19...md já divergem entre si). Isso confirma e formaliza a pendência registrada em [[project_proximos_passos_faltando_todo]] — o aluno termina um capítulo e precisa voltar ao índice do módulo para descobrir manualmente qual é o próximo.

1.2 Rodapé de navegação é inconsistente até dentro do mesmo módulo

Dois formatos convivem em mod_02_logica_e_algoritmos/topicos/:

Não é um padrão único aplicado por template — cada arquivo foi escrito manualmente, então a experiência de navegação varia por capítulo/módulo.

1.3 Breadcrumbs (trilha “você está aqui”) estão desligados globalmente

_config.yml tem breadcrumbs: false com um TODO explícito:

“o tema reconstrói o crumb intermediário relativo à raiz do site (…) gerando link quebrado. TODO Fase 2/3: portar o breadcrumb customizado do Cayman.”

Ou seja, o aluno nunca vê “Mod 02 › Bloco 2 › Capítulo 06” no topo da página — só o menu lateral, que é longo (ver 1.4).

1.4 Menu lateral é uma árvore única e plana de 1721 linhas

_data/navigation.yml lista todos os capítulos de todos os cursos em uma única lista main, sem escopo por curso atual. Já foram feitos fixes pontuais de colapso automático por URL e de mobile ([[project_mm_theme_migration_fixes_2026-09-01]]), mas a causa raiz — um índice gigante único em vez de um índice por curso — permanece.

1.5 A ponte Teoria → Projeto real é unidirecional e rasa

Cada módulo tem uma pasta projetos/ própria (mod_02_logica_e_algoritmos/projetos/index.md, etc.) que linka para fora, para o catálogo proj_aplicacoes_full_stack/projetos/ (158-164 projetos reais). Isso existe em todos os 14 módulos regulares (2 a 11 links cada). Porém:

Resultado prático: o catálogo de 164 projetos (proj_aplicacoes_full_stack/projetos_status.md) é navegável, mas desconectado da trilha de capítulos — parece um universo à parte em vez do próximo passo natural depois da teoria.

1.6 O que já funciona bem (não mexer)

2. Diagrama: fluxo atual vs. fluxo proposto

flowchart TB
    subgraph Atual["🔴 Fluxo Atual"]
        direction LR
        T1[Tópico N] -->|"link lateral"| S1[Slide/Quiz/Exemplo/Exercício]
        T1 -.->|"sem link direto"| T2["Tópico N+1<br/>(aluno precisa voltar ao índice)"]
        T1 -.->|"link genérico, se existir"| P1["projetos/index.md do módulo"]
        P1 -->|"link"| CAT["Catálogo de 164 projetos"]
        CAT -.->|"❌ nenhum link de volta"| T1
    end

    subgraph Proposto["🟢 Fluxo Proposto"]
        direction LR
        U1[Tópico N] -->|"lateral"| V1[Slide/Quiz/Exemplo/Exercício]
        U1 -->|"➡️ próximo capítulo"| U2[Tópico N+1]
        U1 -->|"🎯 projeto aplicado"| PR["Projeto específico no catálogo"]
        PR -->|"📚 pré-requisito"| U1
        U1 -.->|"breadcrumb"| BC["Módulo › Bloco › Capítulo"]
    end

3. Princípios norteadores

  1. Todo capítulo tem 3 saídas claras: aprofundar (slides/exemplos), praticar (exercícios/quiz) e avançar (próximo capítulo OU projeto aplicado quando for capítulo de fechamento de bloco).
  2. Nenhuma página é um beco sem saída. Se o aluno chegou lá por um link, deve conseguir sair por outro link relevante — nunca só “voltar”.
  3. Automatizar em vez de escrever à mão. A causa da inconsistência (1.2) é edição manual repetida 800+ vezes. A correção correta é um template/include único alimentado por dados, não reescrever arquivo por arquivo.
  4. Bidirecionalidade teoria↔prática. Se A linka para B, B deve linkar para A (capítulo → projeto, projeto → capítulo).
  5. Sem Ruby/Docker local funcional neste ambiente ([[project_ci_quebrado_link_rot_massivo_2026-09-01]]): toda mudança estrutural precisa ser validada via push + CI real do GitHub Actions, nunca só “parece certo no source”.

4. Plano de ação por fase

Status geral (atualizado 2026-09-05): Fase 1 100% concluída. Fase 2: 2.1/2.2 feito com escopo reduzido, 2.3 concluído, 2.4 descartado por decisão consciente. Fase 3: não iniciada, aguardando escopo do usuário. Ver seção 8 (Backlog Pendente).

Fase 1 — Quick wins de conteúdo (sem mexer em template/engine)

Baixo risco, alto impacto imediato, executável módulo a módulo.

# Ação Onde Esforço Status
1.1 Unificar o rodapé de navegação de todos os tópicos no formato de 5 colunas (“🧭 Navegação Rápida”) já usado no Capítulo 19 do mod_02, adicionando uma linha ⬅️ Capítulo Anterior | ➡️ Próximo Capítulo Todos os topicos/NN_*.md dos 14 módulos + specs/extras Alto (mecânico, mas em massa — candidato a fork/script) ✅ Feito (PR #7)
1.2 Investigar e fechar a pendência [[project_proximos_passos_faltando_todo]]: confirmar quais módulos citados pelo usuário realmente carecem da seção e corrigir junto com 1.1 mod_02 e demais reportados Baixo (já é subconjunto de 1.1) ✅ Feito (PR #7)
1.3 Em cada proj_aplicacoes_full_stack/projetos/<slug>/index.md, adicionar seção “📚 Pré-requisitos Teóricos” com 1-3 links para o(s) capítulo(s) de módulo que ensinam os conceitos usados 166 arquivos de projeto Alto (mecânico + precisa mapeamento projeto→capítulo) ✅ Feito (PR #8), 164/164
1.4 Nos capítulos de “Projeto Integrador” (geralmente o Capítulo 20 de cada módulo) e nos projetos/index.md de módulo, trocar links genéricos por links nomeados por capítulo relevante (“Depois do Cap. 17 (Busca Binária), faça: …”) 14 projetos/index.md + capítulos finais Médio ✅ Feito (PR #9), 42 links

Fase 2 — Estrutural (template/dados)

Resolve a causa raiz da inconsistência; precisa de mais cuidado e validação via CI.

# Ação Onde Esforço Status
2.1 Criar _includes/chapter-nav.html que renderiza o rodapé padrão (5 recursos + anterior/próximo) a partir de front-matter (prev_url, next_url, module_index_url) ou de uma tabela _data/curriculo/<modulo>.yml _includes/, _data/ Médio-Alto ⚠️ NÃO feito — só removida a redundância cosmética deixada pela 1.1 (PR #11). O include unificado de verdade pros 40 cursos continua em aberto (ver seção 8)
2.2 Popular o front-matter/_data necessário para o include funcionar em todos os capítulos (script gerador, não manual) todos os módulos Alto ⚠️ NÃO feito (depende de 2.1)
2.3 Resolver o bug de breadcrumbs documentado no _config.yml (portar lógica cumulativa do Cayman para _includes/head/custom.html) e reativar breadcrumbs: true _config.yml, _includes/head/custom.html Médio ✅ Feito (PR #10), via _includes/breadcrumbs.html
2.4 Reestruturar _data/navigation.yml para nav escopada por curso (usar nav_scope/front-matter por seção do MM, ou dividir em múltiplos arquivos de nav carregados condicionalmente) em vez de uma lista main única de 1721 linhas _data/navigation.yml Alto (risco de regressão no menu — testar bastante) ❌ Descartado por decisão do usuário (2026-09-05) — exigiria trocar front-matter em 3.240 arquivos confirmados via grep, sem build local pra testar; dor do aluno já mitigada por CSS/JS. Ver seção 8

Fase 3 — Enriquecimento pedagógico

Depois que a canalização básica (Fases 1-2) está sólida.

# Ação Onde Esforço Status
3.1 Adicionar, dentro do próprio tópico teórico (não só no índice do módulo), uma caixa “🎯 Onde isso vira prática?” citando o projeto real específico que aplica aquele conceito tópicos de capítulos-chave Médio ⏸️ Não iniciado — usuário optou por não seguir em sequência automática (é escrita de conteúdo novo, não correção de estrutura). Achado relevante: quase todo Capítulo 20 já é um “Projeto Integrador” que constrói o projeto dentro do próprio capítulo, não aponta pra um projeto separado — muda a forma como 3.1 precisaria ser desenhado
3.2 Criar uma página de “Trilha Visual” por módulo (mermaid: Teoria → Exercício → Projeto → Próximo Módulo) complementando o index.md atual index.md de cada módulo Médio ⏸️ Não iniciado
3.3 Revisar proj_aplicacoes_full_stack/projetos_status.md/catálogo para agrupar/ordenar por trilha de aprendizado (não só por categoria técnica) — já ganhou uma limpeza de categorias Java Web/Desktop/Full Stack nesta sessão; próximo passo é ordenar por progressão didática dentro de cada trilha proj_aplicacoes_full_stack/projetos_status.md Baixo-Médio ⏸️ Não iniciado

5. Priorização sugerida (impacto × esforço)

quadrantChart
    title Impacto x Esforço
    x-axis "Baixo Esforço" --> "Alto Esforço"
    y-axis "Baixo Impacto" --> "Alto Impacto"
    quadrant-1 "Fazer primeiro"
    quadrant-2 "Planejar bem"
    quadrant-3 "Adiar"
    quadrant-4 "Delegar/automatizar"
    "1.2 Fechar pendência Próximos Passos": [0.15, 0.55]
    "1.1 Padronizar rodapé (todos capítulos)": [0.75, 0.85]
    "1.3 Pré-requisitos nos projetos": [0.7, 0.8]
    "1.4 Links nomeados por capítulo": [0.4, 0.6]
    "2.1 Include reusável de navegação": [0.55, 0.7]
    "2.3 Corrigir breadcrumbs": [0.45, 0.6]
    "2.4 Nav escopada por curso": [0.85, 0.65]
    "3.1 Caixa 'onde vira prática'": [0.5, 0.55]
    "3.2 Trilha visual por módulo": [0.5, 0.4]

Recomendação de ordem de execução: 1.2 → 1.1 → 1.3 → 2.3 → 2.1/2.2 → 1.4 → 3.x → 2.4 (a mais arriscada, por último e com mais testes).

6. Validação

Sem Ruby/Docker local confiável neste ambiente ([[feedback_verify_deploy_after_push]]):

  1. Alterações de conteúdo (Fase 1): validar com _scripts de checagem de links existentes + push para branch e checar gh run list / log da Action antes de declarar concluído.
  2. Alterações de template (Fase 2): testar em 1-2 módulos piloto primeiro (ex.: mod_02 e mod_11, que já tiveram auditoria recente), confirmar visualmente via claude-in-chrome no site publicado, só então propagar para os outros 38.
  3. Nunca declarar “corrigido” sem confirmar no build real da Action, dado o histórico de CI travado por bugs sutis de Liquid neste repositório.

7. Métricas de sucesso

Métrica Antes Meta Status 2026-09-05
Capítulos com link ➡️ Próximo Capítulo 0 confirmado (achado real: 11/40 cursos com 0%, não sitewide) 100% (800/800) ✅ 100% — 220 capítulos corrigidos, os outros 29 cursos já estavam OK
Projetos do catálogo com pré-requisito teórico linkado de volta 0/166 ≥ 90% ✅ 100% — 164/164
Formato de rodapé de navegação único no site 2+ variantes conhecidas 1 padrão via include ⚠️ Parcial — redundância removida, mas ainda não é 1 include único (2.1/2.2 não feito)
Breadcrumbs ativos Desligado Ligado, sem link quebrado ✅ Ligado, verificado em 5 tipos de página

8. Backlog Pendente (não concluído nesta rodada)

Item O que falta Por que não foi feito agora
2.1/2.2 — Include Liquid unificado Criar _includes/chapter-nav.html de verdade, alimentado por _data, e migrar os ~800 capítulos pra usar o include em vez de HTML hardcoded no corpo do arquivo Escopo reduzido pra só limpar a redundância criada na 1.1; o include reutilizável de verdade nunca foi construído
2.4 — Menu lateral escopado por curso Quebrar _data/navigation.yml (1721 linhas) em ~40 arquivos + trocar front-matter nav: "main" em 3.240 arquivos confirmados via grep Descartado por decisão do usuário: blast radius maior de todo o plano, sem build local pra testar, ganho é só performance/manutenção (a dor visível do aluno já foi mitigada antes por CSS/JS de auto-colapso)
3.1 — Caixa “Onde isso vira prática?” Escrever, dentro do próprio tópico teórico (não só no rodapé/índice), uma citação ao projeto real que aplica aquele conceito específico É escrita de conteúdo pedagógico novo em volume grande (até 40 cursos), não correção de estrutura — usuário preferiu não entrar nisso em sequência automática. Achado que muda o desenho do item: quase todo Capítulo 20 de cada curso já é um “Projeto Integrador” que constrói o projeto dentro do próprio capítulo (não aponta pra um projeto separado do catálogo)
3.2 — Trilha Visual por módulo Página/diagrama mermaid por módulo (Teoria → Exercício → Projeto → Próximo Módulo) complementando o index.md Mesma razão do 3.1 — não iniciado
3.3 — Reordenar catálogo por progressão didática Hoje proj_aplicacoes_full_stack/projetos_status.md ordena as linhas dentro de cada categoria alfabeticamente por slug, não por dificuldade/ordem de aprendizado Não iniciado, baixa prioridade relativa
Achado colateral (fora do escopo do plano) mod_13_devops_e_cloud/projetos/index.md ainda diz “Ver Todos os 123 Projetos” ✅ Corrigido na PR #14 (reorganização do catálogo)

9. Auditoria de Profundidade Teórica dos Capítulos (iniciada 2026-09-05)

Objetivo: este plano até aqui atacou navegação (o aluno acha o próximo passo?). Esta seção ataca uma pergunta diferente e mais fundamental: o conteúdo teórico que o aluno encontra ao chegar lá é real, ou é placeholder? Pedido explícito do usuário — gerar o relatório aqui para orientar uma rodada de melhoria de conteúdo mais tarde, sem corrigir agora.

Metodologia

Fork dedicado leu os 20 capítulos de teoria na íntegra (não só a introdução) e classificou cada um em ✅ Fundamentação sólida / ⚠️ Superficial / ❌ Placeholder-like, com evidência concreta por capítulo. Achados mais graves foram reconferidos manualmente (não apenas aceitos do relatório do fork) antes de entrar aqui.

9.1 Resultado — proj_aplicacoes_full_stack/topicos/ (piloto, 20 capítulos)

Cap Arquivo Verdict Evidência
01 arquitetura_full_stack_e_monorepo ❌ Placeholder Parágrafo genérico de abertura + “Pilares Fundamentais” que não citam monorepo/Turborepo
02 autenticacao_jwt_e_rbac ❌ Placeholder Mesmo parágrafo e mesmos 3 “Pilares Fundamentais” idênticos, palavra por palavra, ao Cap 01
03 design_patterns_mvc_e_clean_architecture ✅ Sólida Explica DIP, Use Cases, Adapters com exemplo concreto (CriarPedidoUseCase)
04 validacao_zod_e_pydantic ✅ Sólida Conceito “Type-First Schemas” + specifics reais (z.infer, field_validator)
05 stack_express_e_react ❌ Placeholder Boilerplate idêntico; front matter diz “Cap 03” (deveria ser Cap 05)
06 stack_nextjs_e_nestjs ❌ Placeholder Boilerplate idêntico; front matter diz “Cap 05” (deveria ser Cap 06)
07 persistencia_prisma_typeorm_drizzle ✅ Sólida Compara trade-offs reais (schema-first vs TS-first vs decorators)
08 websockets_e_socketio ✅ Sólida Sequence diagram + WS puro vs Socket.io (fallback, rooms, Redis adapter)
09 stack_springboot_e_angular ❌ Placeholder Boilerplate idêntico; front matter diz “Cap 04” (deveria ser Cap 09)
10 stack_fastapi_e_vue ✅ Sólida Specifics de Depends(), AsyncSession, Composition API
11 htmx_e_thymeleaf ✅ Sólida Trade-off real entre paradigma HOTW vs SPA
12 micro_frontends_federacao ✅ Sólida Module Federation, shared deps, padrões de comunicação
13 caching_redis ✅ Sólida Cache-Aside vs Write-Through, rate limiting
14 filas_bullmq_celery ✅ Sólida Sequence diagram, retries/backoff
15 docker_compose ✅ Sólida Multi-stage build explicado com números (1.5GB → 50MB)
16 playwright_e2e ✅ Sólida Pirâmide de testes, auto-wait, BrowserContext
17 deploy_e_hospedagem_cloud ❌ Placeholder grave Reconferido manualmente: o front matter do arquivo diz title: "Cap 06: Comunicação em Tempo Real com WebSockets..." e o corpo é sobre WebSockets/Prometheus — conteúdo inteiro é uma cópia do Cap 08, zero relação com deploy/Render/Neon/Vercel/AWS que o nome do arquivo promete
18 observabilidade_sentry ✅ Sólida 3 pilares de observabilidade, correlationId, source maps
19 projeto_integrador_tecloja ✅ Sólida Arquitetura de microsserviços concreta e coerente
20 projeto_integrador_saas ✅ Sólida RLS, resolução de tenant, Stripe billing

Resumo: 14/20 ✅, 0/20 ⚠️, 6/20 ❌ (Caps 01, 02, 05, 06, 09, 17). Boilerplate idêntico confirmado manualmente (comparação byte a byte do parágrafo de abertura e dos “Pilares Fundamentais” entre Caps 01 e 02). Os 3 erros de numeração no front matter (05→”Cap 03”, 06→”Cap 05”, 09→”Cap 04”, todos deslocados em -2) e a troca total de conteúdo do Cap 17 foram confirmados lendo o arquivo diretamente, não só aceitos do relatório automático.

Hipótese de causa: os 6 capítulos ❌ e os 14 ✅ têm perfil de escrita visivelmente diferente — os ✅ têm profundidade técnica específica por stack, os ❌ compartilham um template genérico. Consistente com terem sido gerados em lotes diferentes, um lote nunca tendo recebido o conteúdo real (e no caso do Cap 17, o conteúdo de outro capítulo foi colado no lugar por engano).

9.2 Resultado — mod_01 a mod_05 (rodada 2, 100 capítulos, 2026-09-05)

Continuação da auditoria pedida pelo usuário (“continuar auditoria nas demais subpastas topicos outros modulos”). Mesma metodologia: leitura integral dos 20 capítulos de cada curso, sem heurística automática.

Curso Resultado Observação
mod_01_fundamentos_da_computacao 20/20 ✅ Conteúdo formal específico por capítulo (provas de Big-O, autômatos com 5-tupla, propriedades ACID, teorema CAP, fórmula do A*), sem repetição de boilerplate
mod_02_logica_e_algoritmos 20/20 ✅ Caps 01-10 muito ricos (comparação VisualG/Portugol/C/Java/Python, thread evolutivo do exemplo “Retângulo” entre paradigmas); Caps 11-20 em formato mais enxuto (“🧭 Navegação Rápida”), mas o conteúdo teórico em si continua específico e correto — é só uma inconsistência de formato de rodapé, não um problema de fundamentação
mod_03_design_de_interfaces_ui_ux 20/20 ✅ Teoria de UX real e correta (Leis de Fitts/Hick, heurísticas de Nielsen, WCAG 2.2 com números de contraste certos, Atomic Design, HEART framework)
mod_04_html5_e_css3 20/20 ✅ Tecnicamente denso e preciso (especificidade CSS com cálculo correto, Core Web Vitals com limiares certos, Container Queries, Subgrid)
mod_05_javascript_fundamentos_e_dom 20/20 ✅ Igualmente preciso (Event Loop com ordem de execução correta, Prototype Chain, armadilha real do fetch não rejeitar em 404/500)

Resumo da rodada 2: 100/100 ✅, 0 ⚠️, 0 ❌. Nenhum boilerplate, nenhuma troca de conteúdo, nenhum erro de numeração de capítulo no front matter (verificado nos 5 cursos). Resultado bem mais limpo que o piloto — sugere que o piloto (proj_aplicacoes_full_stack) foi gerado em condições diferentes (lote/sessão específica) e não é representativo do padrão de qualidade do restante do site.

9.3 Resultado — mod_06 a mod_10 (rodada 3, 100 capítulos)

Curso Resultado Observação
mod_06_versionamento_com_git_e_github 🚨 0/20 ✅ — 20/20 ❌ Padrão diferente do piloto: não é o mesmo template de “Pilares Fundamentais”, é um esqueleto de 4 seções onde 3 nunca mudam — mesma tabela de comandos (git status/log/diff) e mesmos 4 bullets de “Melhores Práticas” em todos os 20 arquivos, incluindo capítulos sobre submodules/LFS/hooks sem nenhuma relação com esses comandos básicos. Confirmado via grep (git status aparece nos 20/20 arquivos)
mod_07_backend_e_apis 20/20 ✅ HTTP com tabela real de idempotência, handshake TLS em 3 passos, Docker multi-stage com números reais
mod_08_bancos_de_dados_sql_e_nosql 20/20 ✅ CTEs/Window Functions com distinção real vs GROUP BY, trade-off embedding vs referencing no MongoDB
mod_09_estruturas_de_dados 20/20 ✅ Confirma o achado já feito no piloto anterior desta sessão (Cap 10, Árvores AVL)
mod_10_paradigmas_e_padroes_de_projeto 20/20 ✅ Factory Method/Abstract Factory com intenção GoF e diagrama de classes real

Resumo da rodada 3: 80/100 ✅, 0 ⚠️, 20/100 ❌ (todos em mod_06).

9.4 Resultado — mod_11 a mod_14 (rodada 4, 80 capítulos)

80/80 ✅, zero placeholder, zero erro de numeração. Verificado com leitura completa de todos os 80 capítulos (não amostragem) — cada um cita fonte/framework correto e específico: mod_11 (Qualidade/Testes) cita Boehm, IEEE 1012, Gerard Meszaros, Dan North, Netflix (Chaos Engineering); mod_12 (Dev Seguro) tem STRIDE/DREAD, Saltzer&Schroeder, OWASP Top 10 e API Top 10 corretos; mod_13 (DevOps/Cloud) tem métricas DORA, arquitetura Kubernetes control-plane, Terraform state locking reais; mod_14 (Hardware/Compiladores) tem protocolo MESI, pipeline LLVM em 3 fases, fórmula de IPC. Nenhum dos 4 cursos tem qualquer capítulo ❌ ou ⚠️.

9.5 Resultado — os 7 guias extra_* (rodada 5, 140 capítulos)

Curso ✅ ⚠️ ❌ Capítulos ❌
extra_engenharia_de_software 16 0 4 01, 03, 06, 14
extra_guia_de_ferramentas 15 1 4 01, 05, 07, 10 (Cap 02 ⚠️ duplica o Cap 09)
extra_guia_de_linguagens_de_programacao 20 0 0 — melhor curso auditado no site inteiro, conteúdo autoral rico com cross-links reais entre linguagens
extra_guia_de_markdown 16 0 4 01, 03, 05, 13
extra_guia_de_modelagem_uml 16 0 4 01, 02, 06, 09
extra_guia_de_redes 14 0 6 01, 04, 05, 09, 13, 17
extra_inteligencia_artificial 10 0 10 01-06, 09, 13, 17, 20 (único curso onde até o Projeto Integrador final é placeholder)

Resumo da rodada 5: 107/140 ✅, 1/140 ⚠️, 32/140 ❌ (23%). Mesmo padrão do piloto (parágrafo + “Pilares Fundamentais” idênticos), sempre concentrado em 4-10 capítulos específicos por curso, nunca o curso inteiro (exceto o Cap 20 de IA).

9.6 Resultado — as 4 especializações spec_backend_com_* (rodada 6, 80 capítulos)

🚨 0/80 ✅ — 80/80 ❌ (100%). Golang/Gin, Java/Spring Boot, PHP/Laravel e Python/FastAPI têm os 20 capítulos idênticos entre si e entre os 4 cursos, mudando só o nome do tópico. Confirmado manualmente: mesmo diagrama mermaid genérico (Cliente→Gateway→Controller→Service→Repository→DB), mesma frase “O domínio de [Título] é crucial para arquiteturas backend modernas, seguras e de alto tráfego”, mesmos 3 “Principais Pilares” idênticos, e a seção “💻 Código de Demonstração Corporativo” não tem código nenhum — é um bloco text com só o comentário // Demonstração Técnica de [Título] ([LINGUAGEM])`. Cada arquivo tem exatamente 71 linhas nos 4 cursos. Pior que o piloto: lá pelo menos 70% dos capítulos eram reais; aqui é zero.

9.7 Resultado — frontend e mobile: Angular/React/Vue/Android/Flutter (rodada 7, 100 capítulos)

🚨 0/100 ✅ — 100/100 ❌ (100%). Mesma família de template do item 9.6, adaptada por domínio: variante “web” (Angular/React/Vue, frase “é fundamental para a criação de aplicações web modernas…”) e variante “mobile” (Android/Flutter, frase “é crucial para o desenvolvimento de aplicativos móveis modernos…”). Confirmado manualmente via grep da frase-gatilho (20/20 em spec_frontend_com_react). Os títulos de capítulo no front matter são bons e específicos (ex: “RxJS switchMap/debounceTime”, “Riverpod Providers/AsyncValue”) — o problema é 100% no corpo do texto, o planejamento curricular está certo. Inclui o Capítulo 20 (Projeto Integrador) de todos os 5 cursos.

9.8 Resultado — Segurança, C, C++, C#, Go (rodada 8, 100 capítulos)

Curso Resultado Observação
spec_seguranca_e_criptografia 🚨 0/20 ✅ — 20/20 ❌ Todos os 20 arquivos com exatamente 69 linhas, mesmo template; verificado em Cap 05 (AES) e Cap 10 (ECC) — zero ensino real de criptografia em ambos
spec_sistemas_com_cpp 🚨 0/20 ✅ — 20/20 ❌ Todos com exatamente 67 linhas; Cap 09 (Classes/RAII) tem comentário fake no lugar de código C++ real
spec_sistemas_com_csharp 🚨 0/20 ✅ — 20/20 ❌ Todos com exatamente 67 linhas; bug adicional confirmado: o template vazou a variável crua “CSHARP” (maiúscula, sem formatar) 3 vezes no Cap 06 (“Código Fonte CSHARP”, “linguagem CSHARP”) em vez de “C#” — prova cabal de que é conteúdo gerado por máquina, nunca revisado por humano
spec_sistemas_com_go ⚠️ 0/20 ✅ — 20/20 ⚠️ Categoria diferente das outras: os diagramas mermaid são reais e específicos por capítulo (verificado Cap 07 Strings/runas, Cap 10 Structs/embedding), mas a prosa é o mesmo parágrafo + 3 pilares genéricos sobre Go repetidos em todos os 20 — diagrama bom, texto raso
spec_sistemas_com_c ✅ Sólida (amostrado, não 100% exaustivo) Contagem de linhas varia organicamente (167-291, sem uniformidade suspeita); Cap 15 (Heap/Valgrind) e Cap 09 (Recursividade) lidos na íntegra, ambos com profundidade real

Resumo da rodada 8: 20/100 ✅ (só C), 20/100 ⚠️ (Go), 60/100 ❌ (Segurança+C+++C#).

9.9 Resultado — Java, Python, Rust, TypeScript “Sistemas” (rodada 9, 80 capítulos)

Curso Resultado Observação
spec_sistemas_com_java 20/20 ✅ Cada capítulo com conceito real + código Java compilável específico (ex: Cap 16 Virtual Threads/Project Loom com Executors.newVirtualThreadPerTaskExecutor() real)
spec_sistemas_com_python 20/20 ✅ Mesmo padrão de qualidade (ex: Cap 15 GIL/asyncio.TaskGroup real, Cap 10 typing.Protocol real)
spec_sistemas_com_rust 🚨 0/20 ✅ — 20/20 ❌ Mesmo template dos itens 9.6-9.8, adaptado pra Rust — até os conceitos mais centrais e difíceis (Ownership, Borrowing, Lifetimes, Unsafe/FFI) são boilerplate genérico sem uma linha de explicação real
spec_sistemas_com_typescript 🚨 0/20 ✅ — 20/20 ❌ Mesmo template exato do Rust, só trocando “RUST” por “TYPESCRIPT”

Resumo da rodada 9: 40/80 ✅ (Java+Python), 40/80 ❌ (Rust+TypeScript) — split perfeito dentro do mesmo lote de curadoria, mostrando que a causa é por curso/lote de geração, não por dificuldade do assunto.

9.10 🚨 Resultado consolidado — todos os 40 cursos, 800 capítulos

Auditoria completa. Tabela de contagem por curso e o total geral:

Bloco de cursos ✅ Sólida ⚠️ Superficial ❌ Placeholder % problema
proj_aplicacoes_full_stack (piloto) 14 0 6 30%
mod_01 – mod_05 100 0 0 0%
mod_06 0 0 20 100%
mod_07 – mod_14 (8 cursos) 160 0 0 0%
extra_* (7 guias) 107 1 32 23%
spec_backend_com_* (4) 0 0 80 100%
spec_frontend_* + Android + Flutter (5) 0 0 100 100%
spec_seguranca, cpp, csharp (3) 0 0 60 100%
spec_sistemas_com_go 0 20 0 100%¹
spec_sistemas_com_c 20 0 0 0%
spec_sistemas_com_java + python (2) 40 0 0 0%
spec_sistemas_com_rust + typescript (2) 0 0 40 100%
TOTAL (40 cursos, 800 capítulos) 441 21 338 42,25%

¹ Go conta como “problema” na % por ser ⚠️ (raso), não ❌.

Achado principal: quase 43% de todo o conteúdo teórico do site (338 de 800 capítulos) é boilerplate genérico ou placeholder, concentrado quase inteiramente nas especializações spec_* (14 de 18 cursos de especialização — 78% — são placeholder de 100% a 100%, com exceção de C, Java, Python “sistemas” e Go). Os 14 módulos regulares (mod_*) e os 7 guias extra_* estão, na maioria, genuinamente bons — a exceção é mod_06 (Git/GitHub), que é 100% placeholder com um padrão de template diferente dos demais.

Padrão claro por lote de geração, não por tema: dentro do mesmo assunto “sistemas” (rodada 9), Java e Python saíram 100% sólidos enquanto Rust e TypeScript saíram 100% placeholder — não é que Rust seja “mais difícil de gerar conteúdo”, é que aquele lote específico nunca recebeu o conteúdo real. Isso é consistente em todas as 9 rodadas: cursos inteiros saem 100% bons ou 100% (quase) ruins, quase nunca um meio-termo — sugere que a causa raiz é por sessão/lote de geração de conteúdo, e uma vez identificado que um curso está bom ou ruim, o padrão se mantém no curso inteiro (a única exceção parcial real é o piloto e os extra_*, que têm mistura dentro do mesmo curso).

Sinais mecânicos úteis para detectar isso automaticamente no futuro (achados ao longo da auditoria, não usados como único critério — sempre confirmados por leitura real):

9.12 Progresso de execução (atualizado 2026-09-05)

A ordem recomendada na Seção 9.11 foi aceita pelo usuário e está em execução:

Etapa Escopo Status PR
STEP 1 Bugs pontuais (numeração de capítulo, Cap 17 do piloto trocado, indice_geral.md desatualizado, extra_guia_de_ferramentas Cap 02 duplicado) ✅ Concluído e no ar #19
STEP 2 mod_06_versionamento_com_git_e_github (20 capítulos) ✅ Concluído e no ar #20
STEP 3 14 cursos spec_* 100% placeholder (280 capítulos) 🔄 4/14 concluídos (backend: Go/Gin, Java/Spring Boot, PHP/Laravel, Python/FastAPI — 80 capítulos) #23
STEP 4 Enriquecer prosa de spec_sistemas_com_go ⏳ Não iniciado —
STEP 5 32 capítulos parciais dos extra_* + resto do piloto ⏳ Não iniciado —

Achado que expandiu o escopo real do STEP 3: a auditoria original (Seção 9) só verificou topicos/ (teoria). Ao iniciar a correção, descobriu-se que exemplos/ (código) tinha exatamente o mesmo problema nos 4 cursos backend — o bloco de código inteiro era um único comentário repetindo o título do capítulo, sem código real algum. exercicios/, quizzes/ e slides/ desses mesmos cursos já eram genuinamente bons. Ainda não confirmado se os 10 cursos spec_* restantes têm o mesmo padrão em exemplos/ — verificar antes de escalar a correção.

Método usado (backend, 4 cursos): para cada capítulo, ler primeiro o exercicios/+quizzes/ já correto (fonte de verdade do escopo técnico real) e escrever topicos/+exemplos/ consistentes com esse escopo — evita inventar um escopo novo desconectado do que os exercícios já cobram.

9.11 Ação recomendada (não executada ainda — só relatório, por pedido do usuário)

Por ordem de severidade/impacto:

  1. Reescrever do zero os 14 cursos de especialização 100% placeholder (spec_backend_com_golang_e_gin, spec_backend_com_java_e_springboot, spec_backend_com_php_e_laravel, spec_backend_com_python_e_fastapi, spec_frontend_com_angular, spec_frontend_com_react, spec_frontend_com_vue, spec_mobile_nativo_android, spec_multiplataforma_com_flutter, spec_seguranca_e_criptografia, spec_sistemas_com_cpp, spec_sistemas_com_csharp, spec_sistemas_com_rust, spec_sistemas_com_typescript) — 280 capítulos, o maior bloco de trabalho.
  2. Corrigir mod_06_versionamento_com_git_e_github (20 capítulos) — é um módulo regular obrigatório, prioridade mais alta que as especializações eletivas.
  3. Enriquecer a prosa de spec_sistemas_com_go (20 capítulos) — os diagramas já são bons, só falta o texto de apoio.
  4. Completar os 32 capítulos parciais dos extra_* (listados na tabela 9.5) + os 6 do piloto proj_aplicacoes_full_stack.
  5. Corrigir os bugs pontuais já identificados: Cap 17 do piloto (conteúdo trocado, cópia do Cap 08), 3 erros de numeração de capítulo no piloto, 1 erro de numeração + 1 duplicação em extra_guia_de_ferramentas (Cap 02).
  6. Considerar investigar a causa raiz (qual sessão/prompt gerou os lotes ❌) antes de reescrever, já que o padrão “curso inteiro bom ou curso inteiro ruim” sugere um problema sistemático de processo, não apenas conteúdo faltante ad-hoc.
⬅️ Voltar ao Índice de Documentação 🗺️ Ver Roadmap Geral