Architecture pt BR

🇺🇸 English

O netwp é hexagonal (Ports & Adapters). O ponto do design é que a lógica de domínio nunca toca no sistema operacional diretamente, então ela continua rápida de testar e o mesmo código roda no Windows e no Linux.

As camadas

cmd/netwp         raiz de composição: dispatch da CLI + wiring dos adapters
internal/core     domínio puro: casos de uso + interfaces de porta (sem imports de SO/rede)
internal/adapter  adapters que tocam o SO/rede (arpscan, icmpping,
                  netinfo, oui, tcpprobe, namelookup, wifi, ...)
internal/tui      renderização no terminal: tabela do scan, monitor, dashboard

internal/core guarda os casos de uso (descoberta de dispositivos, classificação, diff de varredura, o doctor de conectividade, montagem do pacote Wake-on-LAN) e uma pequena interface de porta por capacidade (Scanner, Pinger, Prober, HostResolver, VendorLookup, ServiceScanner, e assim por diante). Não importa net, os/exec nem syscall, só tipos de dados simples. É isso que permite o domínio inteiro rodar contra fakes nos testes sem uma placa de rede real.

internal/adapter/* implementa essas portas contra o sistema de verdade. Cada adapter é um pacote pequeno; alguns são específicos de plataforma e escolhidos em tempo de compilação por build tags, nunca em runtime:

• arpscan no Windows usa SendARP; no Linux um socket AF_PACKET cru.
• icmpping no Windows usa IcmpSendEcho; nas outras plataformas a ferramenta ping.
• ifacestat, netinfo, wifi têm implementações por SO de forma parecida.

O core não sabe dizer com qual implementação está falando.

cmd/netwp é a raiz de composição: liga os adapters concretos aos casos de uso do core e faz o parsing dos argumentos da CLI. É deliberadamente fino.

internal/tui renderiza os tipos do core no terminal, tanto a tabela simples do scan quanto as views ao vivo em bubbletea/lipgloss (monitor, dashboard).

Como uma varredura flui

cmd monta um core.Discovery a partir dos adapters
  -> Discovery.Run: varredura ARP, depois enriquecimento por host em paralelo
       (hostname, fabricante, portas abertas, RTT/TTL por ICMP, serviços mDNS)
  -> Classifica cada host (serviços > portas > fabricante; um pin manual vence)
  -> internal/tui renderiza o resultado

As dependências apontam numa direção só: cmd e tui dependem de core; core não depende de ninguém. Os adapters dependem de core só pelas interfaces de porta e tipos de dados.

Por que dois renderizadores de tabela

O internal/tui tem dois jeitos de renderizar uma tabela de dispositivos de propósito. A saída simples do scan usa códigos ANSI crus, porque o lipgloss desabilita cor fora de um TTY real (o que tornaria as asserções de cor vazias no go test). As views ao vivo monitor/dashboard usam estilos lipgloss. Qualquer célula colorida nova precisa das duas variantes.

Persistência

Um estado pequeno vive como arquivos simples em <pasta-de-config-do-usuário>/netwp/, cada um atrás de um adapter de store minúsculo que compartilha um mapa JSON genérico chaveado por MAC (macstore): aliases.json, classoverride.json, watchlist.json, mais o cache lastscan.json e o log events.jsonl. Veja a Referência de Comandos.

Para a versão voltada ao contribuidor e as regras de fronteira de pacotes, veja o CONTRIBUTING.md.