# TECHNICAL_REPORT.md ## 1. Resumo executivo O projeto `42net` consiste em um site de páginas públicas (landing pages) renderizadas no servidor via PHP, com layout compartilhado por includes (`includes/header.php`, `includes/nav.php`, `includes/footer.php`). A implementação atual não apresenta backend transacional (sem APIs, sem persistência em banco, sem rotas que processem entrada do usuário) e utiliza principalmente HTML/Tailwind, com pequenas interações JavaScript inline no navegador. ## 2. Stack tecnológica - Linguagens: PHP, HTML/CSS (via classes Tailwind), JavaScript vanilla inline - Estilização/UI: - Tailwind CSS via CDN (`https://cdn.tailwindcss.com`) - Font Awesome via CDN - Google Fonts (Inter) via CDN - HTML dinâmico/templating: composição por `include` em PHP - Integrações externas (links e ações): WhatsApp (wa.me/api.whatsapp.com), `mailto:`, cPanel (id.cpanel.net), Google Maps, registro.br, imagem externa do WordPress ## 3. Arquitetura do sistema - Estilo: monólito de templates (server-side rendered “static site” em PHP) - Estrutura modular: “modularidade” via *partials* de view (header/nav/footer) - Ausências relevantes: - Não há camada de domínio (model/services) - Não há camada de acesso a dados (repositories/DAO) - Não há endpoints REST/SOAP/GraphQL - Não há endpoints de autenticação, cadastro, envio de formulário ou persistência ## 4. Estrutura do projeto - Raiz: - `index.php` (Home) - `quemsomos.php` - `hospedagem.php` - `card.php` (Planos) - `email.php` - `tutorial.php` - `registro.php` - `wordpress.php` - `contato.php` (Contato/Conversão) - `span.php` (Política anti-spam) - `duvidas.php` - Includes compartilhados: - `includes/header.php` (head + carregamento Tailwind/Fonts + variáveis de metadados + canonical/OG/schema) - `includes/nav.php` (menu desktop/mobile + JS do menu) - `includes/footer.php` (rodapé + WhatsApp flutuante) - Observação de assets: - A pasta `assets/images/` está presente e contém imagens do site (logo, favicon, imagens da home e imagens de tutoriais). ## 5. Módulos principais 1. **Camada de layout (View/Layout)** - `includes/header.php`: metadados (usa `$pageTitle` e `$pageDescription`), canonical, OpenGraph/Twitter e schema básico (Organization) + dependências via CDN - `includes/nav.php`: navegação e script do menu mobile - `includes/footer.php`: rodapé e CTA WhatsApp flutuante (com `aria-label`) 2. **Páginas de conteúdo (View)** - `index.php`: landing com seções e script de scroll (opacidade de imagens) - `tutorial.php`: lista de tutoriais com expansão/collapse via JS inline - `card.php`: planos com CTAs (links externos para WhatsApp) - Páginas informativas/serviços: `quemsomos.php`, `hospedagem.php`, `email.php`, `registro.php`, `wordpress.php`, `span.php`, `duvidas.php`, `contato.php` 3. **Comportamento (Controller “leve” + Front JS)** - Não existe controller formal; o “controller” é feito pelas próprias páginas ao definir metadados e incluir o layout. - Interações são localizadas em: - `includes/nav.php` (toggle mobile menu) - `tutorial.php` (toggle de `.article-details`) - `index.php` (efeito no scroll do hero) ## 6. Fluxos de negócio Como não há persistência e nem endpoints transacionais, os fluxos representam navegação e engajamento: 1. **Navegação no site** - Usuário navega via links HTTP diretos para páginas PHP (ex.: `GET /card.php`, `GET /tutorial.php`) 2. **Interação de UI em tutoriais** - Usuário clica em botões `.toggle-article` -> JS alterna a classe `.hidden` em `.article-details` 3. **Contato/CTA via WhatsApp** - Usuário clica em “Assinar” (planos) -> abre URL externa `https://api.whatsapp.com/send?...` - Usuário também pode clicar no botão WhatsApp flutuante -> abre `https://wa.me/...` 4. **Contato/CTA via e-mail** - Usuário clica em `mailto:suporte@42net.com.br` -> abre o cliente de e-mail do usuário 5. **Redirecionamentos para serviços externos** - “Central do Cliente” (cPanel) e “Registro.br” via links externos 6. **Página de contato** - Usuário acessa `GET /contato.php` e escolhe canal (WhatsApp, e-mail ou Central do Cliente) ## 7. APIs e integrações ### APIs internas - Nenhuma identificada (não há REST/SOAP/GraphQL e não há processamento de requisições via `$_POST/$_GET`) ### Integrações externas (externas ao domínio do projeto) - Tailwind CSS (CDN) - Font Awesome (CDN) - Google Fonts (CDN) - WhatsApp: - `wa.me/5547996498116` - `api.whatsapp.com/send?...` - Links de negócio: - cPanel: `https://id.cpanel.net/get/login?...` - Registro.br: `https://registro.br` - Google Maps: link externo na home - Conteúdo externo: - WordPress logo via Wikimedia (em `wordpress.php`) ## 8. Banco de dados - Não identificado banco de dados no projeto. - Evidências: - Não há uso de `PDO/mysqli/mysql_*` - Não há queries SQL - Não há schemas, migrations ou configurações associadas ## 9. Infraestrutura e execução Execução típica em ambiente PHP com servidor web: - Apache/Nginx configurado para servir PHP - O navegador acessa diretamente arquivos na raiz (ex.: `/index.php`, `/tutorial.php`) - O layout é composto via includes do PHP: - `include __DIR__ . '/includes/header.php'` - `include __DIR__ . '/includes/nav.php'` - `include __DIR__ . '/includes/footer.php'` Observação: o projeto não contém arquivos de configuração local detectáveis (ex.: `composer.json`, `package.json`, `.htaccess`, `phpunit.xml`) que definam pipeline/build. ## 10. Riscos técnicos 1. **Ausência de arquitetura de backend** - Não há camada de domínio/persistência; se a intenção for evoluir para funcionalidades (cadastro, pagamentos, integrações, painel), será necessário criar uma base arquitetural do zero. 2. **Acoplamento de UI ao markup e scripts inline** - JS depende diretamente de IDs/classes específicas; mudanças no HTML podem quebrar interações sem detecção em build/test. 3. **Dependências via CDN** - Sem lockfile/local fallback, reprodutibilidade e controle de versões são menores (atualizações podem introduzir comportamento inesperado). 4. **Escalabilidade do código** - Conteúdo extenso (principalmente `tutorial.php`) dentro de páginas pode ficar difícil de manter e revisar. 5. **Ausência de testes** - Sem infraestrutura de testes unitários/integrados e sem validação automatizada de comportamento. 6. **Possível inconsistência de assets** - Risco mitigado: a pasta `assets/images/` está presente no repositório atual. Ainda assim, recomenda-se governança de assets (otimização de imagens, nomes semânticos e `alt` descritivos, especialmente em tutoriais). ## 11. Avaliação técnica (nota de 1 a 5) - **2/5** Justificativa: o projeto é tecnicamente simples e funcional como landing pages, mas carece de base arquitetural e práticas de engenharia (se evolução for necessária) como organização por camadas, controle de dependências, separação de scripts, testes e evidência de governança de assets/configuração. ## 12. Dúvidas em aberto 1. A pasta `assets/images/` está presente localmente; existe diferença entre ambiente local e produção (paths/URLs/caching)? 2. Existe algum backend “fora” deste diretório (ex.: rotas/serviços em outro projeto) que implemente autenticação/painel? 3. O projeto tem apenas páginas públicas (por enquanto) ou há expectativa futura de formulários/pagamentos/painel administrativo? 4. Há configurações server-side (ex.: `.htaccess`, rewrites, caching headers) que não foram detectadas aqui? 5. Existem páginas adicionais não detectadas na varredura (por nomes diferentes/execuções diferentes)? ## 13. Recomendações para evolução 1. **Base arquitetural para crescer** - Introduzir roteamento e separação entre: - controller (entrada HTTP), - view/templates, - serviços de domínio, - camada de persistência (repositories). 2. **Separar scripts inline** - Migrar JS inline para arquivos versionados (ex.: `public/js/...`) e referenciar no layout. - Reduzir acoplamento a seletores críticos (ou garantir convenções estáveis). 3. **Controlar dependências** - Adotar build simples (mesmo que mínimo) ou versionar assets front (Tailwind/FAC) para controlar versões. 4. **Gestão de assets** - Garantir que `assets/images/...` está presente e versionado (ou publicado via pipeline/CDN), evitando URLs quebradas. 5. **Testes e validação** - Criar pelo menos: - testes de regressão front (ex.: smoke), - checagens de build/linters para templates e JS. 6. **Tratamento de entrada futura** - Caso surjam formulários (lead/cadastro), implementar validação, rate limit, CSRF e logging.