1.1 O método científico aplicado a bugs

 1. REPRODUZIR   ── consigo fazer o bug acontecer de forma consistente?
                    (passos exatos, dados exatos, ambiente exato)
 2. ISOLAR       ── qual a MENOR parte do sistema que ainda exibe o bug?
                    (remover metade de cada vez — bisseção)
 3. HIPÓTESE     ── "acho que é X porque Y". Uma afirmação FALSIFICÁVEL.
 4. TESTAR       ── um experimento que confirma OU refuta a hipótese.
                    (não vários ao mesmo tempo)
 5. ── confirmou? conserte, e escreva um TESTE que reproduz (não repete)
    ── refutou?   volte ao passo 3 com o que aprendeu

1.2 Reprodução mínima

Um bug que só acontece "às vezes, na produção, com esse cliente" é quase impossível de corrigir. O trabalho é reduzi-lo a uma reprodução mínima e determinística: o menor código/estado/passos que ainda falha. Benefícios: você entende a causa no processo de reduzir; fica trivial de testar a correção; e vira um caso de teste. Ferramentas: codesandbox/stackblitz para front, um script isolado para back, um curl para uma API.

1.3 console.log vs o debugger

console.log tem lugar (Módulo 2 mostra como usá-lo bem), mas se a sua ferramenta principal é adicionar console.log, recarregar e ler — você está deixando 80% do poder do DevTools na mesa.

1.4 Outras técnicas que economizam horas

• Rubber duck: explicar o problema em voz alta (para um colega, ou um pato de borracha) força você a articular as premissas — e a errada aparece.
• git bisect (Módulo 9): "funcionava na semana passada" → o git acha o commit exato que quebrou, por busca binária.
• Ler a mensagem de erro inteira — o stack trace, a linha, o "caused by". A maioria diz exatamente o que é.
• Reverter para um estado bom conhecido e reaplicar em pedaços.
• Verificar as premissas: o arquivo que você editou é o que está rodando? o cache? a versão certa? a branch certa? o ambiente certo?

2.1 Abrir e navegar

• F12 ou Ctrl/Cmd+Shift+I; Ctrl/Cmd+Shift+C abre já no modo "inspecionar elemento" (clique num elemento da página).
• Ctrl/Cmd+Shift+P — o Command Menu: digite qualquer coisa ("screenshot", "coverage", "disable cache", "show rulers") — é o atalho para tudo.
• Docking: painel embaixo, à direita, ou janela separada (útil em telas pequenas ou depurando o próprio layout).
• Funciona igual em Chrome, Edge e (com nomes um pouco diferentes) Firefox. Este material usa a nomenclatura do Chrome/Edge; a lógica transfere.

2.2 Elements: DOM e CSS ao vivo

• Editar o DOM: duplo-clique num texto/atributo para editar; Enter confirma; botão direito → "Edit as HTML" para blocos; arrastar para reordenar; Delete remove. Tudo ao vivo, sem recarregar (perde-se no reload).
• Styles: cada regra CSS que se aplica, na ordem de cascata; riscadas = sobrescritas; ao lado, o arquivo:linha de origem (clicável). Marque/desmarque propriedades, edite valores (setas ↑↓ incrementam; Shift+seta = ±10). O bloco element.style { } no topo é o estilo inline que você adicionou.
• Computed: o valor final resolvido de cada propriedade, e — expandindo — de qual regra ele veio. É onde você descobre "por que esse texto está vermelho".
• Box model (aba Computed ou o diagrama): content / padding / border / margin com os valores; passe o mouse para ver realçado na página.
• Estados forçados (:hov): forçar :hover, :focus, :active, :focus-within para estilizar/depurar estados sem precisar segurar o mouse.
• Especificidade: a ordem das regras no painel já reflete a cascata; a regra que vence está no topo, sem riscos. Se a sua regra está riscada, outra é mais específica (ou vem depois, ou tem !important).
• Layout / Flexbox / Grid: badges flex/grid ao lado do elemento no DOM; clicar sobrepõe as linhas do grid/flex na página. A aba Layout lista todos os grids/flex da página.
• Event Listeners (aba ao lado de Styles): todos os handlers ligados ao elemento (e aos ancestrais), com o arquivo:linha — ótimo para "o que roda quando eu clico aqui?".

2.3 O Console como REPL

// helpers que só existem no Console:
$0            // o elemento selecionado agora no painel Elements ($1 = o anterior, etc.)
$('.btn')      // = document.querySelector('.btn')   (só no Console, não é jQuery)
$$('li')       // = [...document.querySelectorAll('li')]  (array de verdade)
$x('//a[@href]') // consulta por XPath

inspect($0)             // abre o elemento/objeto no painel apropriado
getEventListeners($0)   // os listeners do elemento, como objeto
copy(objetoOuTexto)     // copia para o clipboard (ótimo p/ um JSON grande)
monitorEvents($0, 'click')   // loga cada evento; unmonitorEvents($0) para parar
monitor(minhaFn)              // loga cada chamada da função e seus argumentos
queryObjects(Promise)        // todas as instâncias vivas de um construtor

• Live Expressions (o "olho" 👁 na barra do Console): fixa uma expressão que é reavaliada continuamente no topo — ex.: document.activeElement, store.getState().user, performance.memory.usedJSHeapSize.
• Filtros: por nível (Error/Warning/Info/Verbose), por texto, por contexto (top vs iframe), e Console settings → "Preserve log" (mantém entre navegações), "Selected context only".
• Console + qualquer painel: Esc abre o "drawer" do Console sobreposto a qualquer aba (você pode ver o Elements e o Console juntos).

3.1 O painel Sources

• Árvore de arquivos: Page (o que a página carregou), e — se houver source maps — os arquivos originais (TS, JSX, Sass) em "Authored" vs o bundle em "Deployed".
• Ctrl/Cmd+P abre qualquer arquivo por nome; Ctrl/Cmd+Shift+F busca em todos os arquivos carregados (ótimo para achar onde uma string ou seletor é usado).
• À direita: Call Stack, Scope (Local / Closure / Global), Watch, Breakpoints, e os breakpoints especiais (DOM, XHR, Event Listener, Exceptions).

3.2 Os tipos de breakpoint

3.3 Controlar a execução

• Call Stack: clique em qualquer quadro para ver o escopo daquele nível (variáveis locais de quem chamou). "Restart frame" re-executa a função atual do começo.
• Scope: edite valores de variáveis ao vivo (duplo-clique) para testar "e se fosse outro valor?".
• Watch: adicione expressões (this.state, items.length) reavaliadas a cada passo.
• Console durante a pausa: tudo que você digita no Console roda no escopo do frame selecionado — chame funções, inspecione, teste correções.

3.4 Source maps

Seu código roda como um bundle minificado (app.a3f9.js), mas você escreveu TypeScript/JSX. O source map (.map) mapeia cada posição do bundle para o arquivo/linha/coluna original — o DevTools mostra e depura o seu código. Garanta que o build gera source maps (em dev sempre; em produção, considere hidden source maps enviados só ao Sentry). Se você vê código minificado no debugger, o source map não carregou (404, caminho errado, ou desligado).

3.5 Recursos que economizam tempo

• Blackboxing / "Ignore list": botão direito num arquivo (ou padrão em Settings) → "Add script to ignore list" — o step pula bibliotecas (React, lodash, polyfills) e o stack trace as esconde. Você depura só o seu código.
• Pretty print ({ } no rodapé): re-indenta um arquivo minificado quando não há source map.
• Snippets (Sources → Snippets): trechos de JS reutilizáveis que você roda em qualquer página com Ctrl/Cmd+Enter — ótimo para bookmarklets de debug, checagens de acessibilidade, etc.
• Local Overrides (Sources → Overrides → escolher uma pasta): o DevTools persiste suas edições de qualquer arquivo (CSS, JS, até respostas de rede) e as reaplica a cada reload — você testa uma correção num site que não é seu, ou itera CSS sem tocar no projeto. Também dá para sobrescrever headers de resposta.
• Workspaces (conectar uma pasta local): editar no DevTools salva no arquivo do disco — Elements/Sources viram um mini-editor sincronizado.

4.1 A tabela e o waterfall

• Colunas úteis (botão direito no cabeçalho para escolher): Status, Type, Initiator (quem disparou), Size (transferido vs descomprimido — "(disk cache)" / "(memory cache)"), Time, Priority, Waterfall.
• Waterfall: a barra de cada request no tempo. Passe o mouse para o breakdown: Queueing, Stalled, DNS, Initial connection / SSL, Request sent, Waiting (TTFB) (o servidor pensando), Content Download. TTFB alto = backend/rede; Download alto = payload grande ou rede lenta.
• Filtros: por tipo (Fetch/XHR, JS, CSS, Img, Doc, WS, Manifest…), por texto, e a barra de filtro avançada: status-code:500, domain:api.exemplo.com, larger-than:100k, method:POST, -domain:*.google.com (o - exclui), has-response-header:cache-control, mime-type:application/json.
• Preserve log: mantém as requests entre navegações (essencial para depurar login/redirect). Disable cache (só com o DevTools aberto): força buscar tudo da rede.

4.2 Detalhes de uma request

Clique numa linha:

• Headers: URL, método, status, e todos os headers de request e response. "Payload" mostra o corpo enviado (form data ou JSON, já parseado). "Response" mostra o corpo recebido; "Preview" o renderiza (JSON como árvore, HTML, imagem).
• Timing: o breakdown detalhado daquela request.
• Cookies: os enviados e recebidos.
• Initiator: a stack de chamadas que originou a request (clicável até o seu código).

4.3 Ferramentas de reprodução e teste

4.4 Throttling

• Perfis prontos ("Slow 4G", "Fast 4G", "Offline") ou custom (latência, download, upload). Testar como o app se comporta em rede ruim — spinners, timeouts, retries, offline.
• Combine com CPU throttling (no painel Performance) para simular um celular modesto.

4.5 WebSockets, SSE e outros

• Filtro WS: clique numa conexão WebSocket → aba Messages mostra cada frame enviado/recebido, com direção e timestamp.
• Server-Sent Events aparecem como uma request que não "fecha"; a aba EventStream mostra os eventos.

5.1 As Core Web Vitals

No DevTools: o painel Performance mostra LCP/CLS numa gravação; a seção "Live Metrics" (Performance, versões recentes) mede LCP, CLS e INP enquanto você usa a página; a extensão Web Vitals mostra num overlay. Lembre: o número que o Google usa (CrUX) vem de usuários reais — o do seu laptop é só indicativo.

5.2 Gravar um profile

1. Painel Performance → escolher CPU throttling (4× ou 6× para simular celular) e Network throttling se o foco é carregamento.
2. Para carregamento: botão de reload (⟳) grava desde o início. Para uma interação: Record → fazer a ação → Stop. Mantenha curto (poucos segundos).

5.3 Ler o profile

• Trilha da CPU / Network no topo: visão geral; um bloco vermelho no canto de uma tarefa = long task (> 50 ms — bloqueia a resposta a interações).
• Frames / FPS: barras verdes = frames renderizados; buracos = travadas (jank).
• Main (thread principal): o flame chart — a pilha de chamadas ao longo do tempo. Largura = duração; um bloco largo no topo é onde o tempo foi gasto. Cores: amarelo = Scripting (JS), roxo = Rendering (Style/Layout), verde = Painting, cinza = System/idle.
• Bottom-Up / Call Tree / Event Log (embaixo): agregações — "Self Time" (tempo na própria função, sem filhas) vs "Total Time". Ordenar por Self Time acha a função que ela mesma queima CPU.
• Marcadores: DCL, L (Load), FP/FCP, LCP na régua; Layout Shift aparece na trilha Experience; clicar mostra o elemento que pulou.

5.4 Os problemas clássicos e o que procurar

6.1 Memory — vazamentos de JS

Um memory leak no front: objetos que deveriam ser coletados continuam referenciados, e a heap cresce sem parar (a aba fica lenta, trava, ou o navegador mata a página). Ferramentas do painel Memory:

6.2 Application — o estado do lado do cliente

• Storage: Local Storage, Session Storage, IndexedDB, Cookies — ver, editar e limpar cada entrada. "Clear site data" zera tudo (útil para testar o primeiro acesso).
• Service Workers: estado (activated/redundant), "Update on reload", "Bypass for network", "Unregister". Se "sua mudança não aparece", um service worker servindo do cache é o suspeito nº 1 — marque "Update on reload" ou "Bypass".
• Cache Storage: o que o service worker guardou; dá para deletar entradas.
• Manifest: o manifest.json do PWA, com validação e um botão "Add to homescreen".
• Background services: gravar Push, Notifications, Background Sync, Background Fetch para depurar.
• Frames: a árvore de iframes e os recursos de cada um.

6.3 Lighthouse

Aba Lighthouse: auditoria automatizada de Performance, Accessibility, Best Practices e SEO, com nota (0–100) e recomendações acionáveis ("elimine recursos que bloqueiam o render", "imagens sem dimensões", "contraste insuficiente"). Rode em modo incognito (extensões distorcem) e várias vezes (há variância). É um ponto de partida: a nota de Performance vem de uma simulação; use o painel Performance para o diagnóstico real, e o teste manual para acessibilidade (ver apostila de Acessibilidade & WCAG). Existe Lighthouse CI para gate no pipeline.

6.4 Coverage

Command Menu → "Show Coverage" → recarregar → mostra, por arquivo, quanto do CSS e JS foi realmente executado vs carregado. Barras vermelhas = código morto naquele carregamento — candidatos a code-splitting, lazy loading, ou remoção. Não é "cobertura de testes" — é "quanto do bundle a página usou".

6.5 Rendering

Command Menu → "Show Rendering". Ferramentas de diagnóstico visual:

• Paint flashing: pisca em verde as áreas repintadas — se a tela toda pisca a cada scroll, há um problema de paint.
• Layout Shift Regions: destaca em azul onde ocorre CLS.
• Frame Rendering Stats / FPS meter.
• Emular: prefers-color-scheme, prefers-reduced-motion, forced-colors, deficiências de visão (protanopia, embaçado), print media — testar acessibilidade e o modo de impressão sem mudar as configs do SO.
• Core Web Vitals overlay.

6.6 Outros painéis úteis

• Animations: captura e permite dar slow-motion, inspecionar e editar keyframes/timing de animações CSS e Web Animations — ótimo para acertar uma transição.
• CSS Overview: um relatório da página — todas as cores usadas, contrastes insuficientes, fontes, media queries, seletores não usados.
• Issues: avisos consolidados do navegador — cookies que vão quebrar (SameSite), mixed content, CSP, deprecações, problemas de acessibilidade detectáveis. Vale checar antes de cada release.
• Device Mode (ícone de celular): viewport responsivo, presets de dispositivo, devicePixelRatio, emulação de touch, e captura de screenshot (inclusive de página inteira: Command Menu → "Capture full size screenshot").
• Recorder: grava um fluxo de cliques/digitação e o reproduz; exporta para Puppeteer ou Playwright (ver apostila de Testing & Automação) e mede a performance do fluxo.
• Security: estado do TLS, certificado, mixed content.

7.1 O debugger do VS Code

O mesmo poder do DevTools (breakpoints, step, watch, call stack, debug console) dentro do editor, para backend, scripts, testes e — via extensões — frontend. Configura-se em .vscode/launch.json:

{
  "version": "0.2.0",
  "configurations": [
    {
      "name": "Debug API",
      "type": "node",
      "request": "launch",
      "program": "${workspaceFolder}/src/server.ts",
      "runtimeArgs": ["--import=tsx"],
      "envFile": "${workspaceFolder}/.env",
      "console": "integratedTerminal"
    },
    {
      "name": "Attach to :9229",
      "type": "node",
      "request": "attach",
      "port": 9229
    },
    {
      "name": "Debug current test",
      "type": "node",
      "request": "launch",
      "program": "${workspaceFolder}/node_modules/.bin/vitest",
      "args": ["run", "${relativeFile}"],
      "console": "integratedTerminal"
    }
  ]
}

• launch = o VS Code inicia o processo; attach = o processo já está rodando (com --inspect) e o VS Code se conecta.
• Breakpoints: clicar na gutter; condicionais e logpoints (botão direito) iguais ao DevTools; "Break on exceptions" (painel Breakpoints).
• Debug Console: avalia expressões no frame pausado, como o Console do browser.
• JavaScript Debug Terminal (Command Palette): qualquer node/npm/pnpm rodado nele já entra com o debugger anexado — sem launch.json.
• compounds: rodar backend + frontend juntos numa config só.

7.2 Node.js: --inspect

node --inspect app.js            # abre o inspector na porta 9229; conecte o VS Code ou o Chrome
node --inspect-brk app.js       # pausa na 1ª linha — para depurar o boot / imports
node --inspect=0.0.0.0:9229 app.js   # dentro de um container (exponha a porta; NUNCA em produção pública)

# com um runner:
node --inspect-brk ./node_modules/.bin/vitest run
NODE_OPTIONS='--inspect' npm start

• Chrome DevTools para Node: abra chrome://inspect → "Open dedicated DevTools for Node" → aparece o alvo; você tem Sources, Console, Memory (heap snapshots do servidor!) e Performance (CPU profile do servidor).
• CPU profile de produção sem parar: node --cpu-prof app.js gera um .cpuprofile que abre no painel Performance; ou node --heap-prof.
• Debug de testes: Jest/Vitest/Mocha rodam sob --inspect-brk; ou a config "Debug current test" acima.

7.3 Outras stacks (o conceito transfere)

8.1 React DevTools

Extensão (Chrome/Firefox) que adiciona duas abas:

• Components: a árvore de componentes React (não o DOM). Selecione um → veja props, state, hooks (na ordem, com o valor de cada), e o componente que o renderizou ("rendered by"). Edite props/state ao vivo. O ícone de "target" seleciona pelo elemento na página. $r no Console = o componente selecionado.
• Profiler: Record → interagir → Stop. Mostra cada commit (render) como uma barra; o flamegraph mostra quais componentes renderizaram e quanto tempo levaram; o ranked chart ordena pelos mais caros. Clicar num componente mostra "Why did this render?" (props mudaram? hook? state? o pai renderizou?). É a ferramenta para caçar re-renders desnecessários.
• Settings: "Highlight updates when components render" — pisca na tela o que re-renderiza; se um clique num botão pisca a árvore inteira, há um problema de memoização / contexto mal fatiado.

8.2 Vue DevTools

Extensão + o overlay standalone (@vue/devtools). Inspetor de componentes (props, data, computed, setup state — editáveis), a timeline (eventos, mutações do Pinia/Vuex, performance de componentes), inspetor de rotas (Vue Router), e o inspetor do Pinia/Vuex (estado, getters, histórico de mutações, time-travel).

8.3 Estado: Redux / Zustand / etc.

• Redux DevTools (extensão + middleware): cada action disparada, o diff do estado que ela causou, o estado completo em qualquer ponto, time-travel (voltar e reproduzir), e "dispatch" manual de actions. É o padrão-ouro de depuração de estado.
• Zustand, Jotai, XState se conectam à mesma extensão Redux DevTools (via middleware/devtools).
• MobX tem seu próprio; Recoil/Signals idem.

8.4 Data-fetching e roteamento

• TanStack Query Devtools (<ReactQueryDevtools /> ou o painel embutido): cada query com seu status (fresh/stale/fetching/inactive), a chave, os dados em cache, o dataUpdatedAt, e botões para invalidar/refetch/resetar. Resolve "por que essa tela mostra dado velho?" na hora.
• TanStack Router / React Router: devtools que mostram a rota casada, os params, os loaders e o estado de navegação.
• Apollo Client Devtools (GraphQL): o cache normalizado, as queries ativas, e um "GraphiQL" embutido para rodar queries contra o mesmo endpoint (ver apostila de API Design).
• Angular DevTools: árvore de componentes, o injector tree (DI), e um profiler de change detection.

9.1 Clientes de API

9.2 Interceptar e modificar tráfego

Quando o "Copy as cURL" e o Network não bastam — depurar um app mobile, um SDK opaco, ou modificar respostas de forma sistemática:

• mitmproxy (open source, CLI + web UI): proxy HTTPS que intercepta, mostra e permite modificar requests/responses, escrever scripts em Python para reescrever tráfego, e gravar/reproduzir. O padrão para inspecionar o que um dispositivo/app realmente envia.
• Proxyman (macOS/iOS, ótima UX) / Charles Proxy (clássico, multiplataforma, pago): mesma ideia com interface gráfica — breakpoints de rede, map local/remote, throttling, SSL proxying.
• Uso típico: configurar o proxy no Wi-Fi do celular + instalar o certificado da ferramenta → ver e alterar todo o tráfego HTTPS do dispositivo.

9.3 Túneis: expor o localhost

• ngrok / cloudflared (Cloudflare Tunnel) / localtunnel: dão uma URL pública HTTPS que aponta para o seu localhost:3000. Para: testar webhooks (Stripe, GitHub, etc. — eles precisam de uma URL alcançável), mostrar um preview a alguém, testar em um dispositivo real, ou depurar OAuth callbacks. ngrok tem uma UI de inspeção das requests recebidas (parecida com o Network).

9.4 Análise de bundle

O que procurar: uma dependência gorda que dá para trocar (moment → date-fns/Temporal), um pacote inteiro importado para usar uma função (import _ from 'lodash' → import debounce from 'lodash-es/debounce'), duplicatas de uma lib em versões diferentes, polyfills desnecessários, e código que deveria ser lazy (ver Coverage, Módulo 6).

9.5 Monitoramento de erro no cliente

• Sentry (o mais comum), Bugsnag, Rollbar, Datadog RUM, Highlight, LogRocket (grava a sessão): capturam os erros JS que acontecem nos usuários reais — stack trace (com source maps enviados no build), navegador/SO, os "breadcrumbs" (cliques, requests, navegação) que antecederam, e frequentemente uma repetição da sessão. É o que transforma "alguns usuários" (Módulo 1) em "este erro, neste componente, nestes navegadores, desde o deploy de terça". Cruza com a apostila de Observabilidade & SRE.
• Configure o upload de source maps no CI (e mantenha-os privados) para os stack traces virem legíveis.

9.6 git bisect — o debugger do histórico

git bisect start
git bisect bad                 # o commit atual está quebrado
git bisect good v2.3.0         # este era bom
# o git faz checkout no meio do caminho; você testa e diz:
git bisect good   / git bisect bad
# ... repete (busca binária) até:
# "abc123 is the first bad commit"
git bisect reset

# automático, se você tem um teste/script que retorna 0=bom, !=0=ruim:
git bisect run ./repro.sh

Em ~log₂(N) passos, o git aponta o commit exato que introduziu o bug — muitas vezes o diff já mostra a causa. Requer que cada commit compile/rode (mais um motivo para commits pequenos e verdes).

9.7 Depuração mobile

• iOS (Safari): no iPhone, Ajustes → Safari → Avançado → Inspetor da Web; no Mac, Safari → Desenvolvedor → [seu iPhone] → a aba. Você tem um Web Inspector completo (Elements/Console/Network/etc.) do Safari do dispositivo. Simulador do Xcode idem.
• Android (Chrome): ativar "Depuração USB" no telefone, conectar, abrir chrome://inspect no desktop → "inspect" na aba do dispositivo → DevTools remoto completo, inclusive screencast da tela.
• React Native: o menu de dev (agitar o device) → o debugger; nas versões modernas, React Native DevTools (baseado no Chrome DevTools) com Console, Sources, breakpoints e React DevTools integrados. Flipper (Meta) foi a plataforma de plugins padrão (rede, layout, bancos, logs) — hoje sendo substituída pelo novo DevTools nativo; ainda em muitos projetos.
• Flutter: o DevTools do Flutter/Dart — inspetor de widgets, timeline de performance, profiler de memória, o "repaint rainbow".

10.1 Onde isso conta

• Front-end: DevTools inteiro + React/Vue DevTools + análise de bundle e Web Vitals são competência de base, não diferencial — a ausência chama atenção.
• Full-stack / back-end: debugger do editor, Node --inspect, clientes de API, profiles de CPU/heap, git bisect.
• QA / SDET: Network, HAR, Recorder→Playwright, throttling, a11y no DevTools.
• Suporte / on-call: ler um HAR e um stack trace do Sentry, reproduzir com "Copy as cURL", interpretar um profile.
• Em entrevista técnica, "como você depuraria isto?" é uma pergunta recorrente — e a fluência com ferramentas aparece na resposta.

10.2 Roadmap de estudo (4–6 semanas)

10.3 Banco de perguntas de entrevista (com a resposta que aprova)

10.4 O que mostrar (portfólio)

1. Um writeup de investigação: "diagnostiquei um vazamento de memória / uma página lenta / uma request misteriosa" — com os passos, os prints do DevTools (heap comparison, flame chart, waterfall) e o raciocínio. Vale mais que "sei usar o DevTools".
2. Snippets de debug num gist: checagens úteis para colar no Console (contar listeners, achar elementos sem alt, medir render, dump de estado).
3. Um launch.json completo de um projeto real (launch + attach + debug de teste + compound), documentado.
4. Antes/depois de performance: um profile com uma long task, a correção, e o profile depois — com os números.
5. Um git bisect run resolvido, com o script de reprodução.

10.5 Fontes para continuar

• Chrome DevTools: a documentação oficial (developer.chrome.com/docs/devtools) — cada painel tem um guia; o "What's New in DevTools" a cada versão; o "Tips" (Command Menu → digitar); o canal do Chrome for Developers.
• Firefox: a MDN "Firefox DevTools User Docs".
• VS Code: a página "Debugging" da documentação; "Debugging recipes" para cada stack.
• Framework: a doc do React DevTools e o guia de "Profiler"; a do Vue DevTools; a do Redux DevTools; a da TanStack Query Devtools.
• Prática: "DevTools challenges" e o "DevTools Tips" de Umar Hansa; pegar um site lento conhecido e escrever a auditoria; plantar bugs num projeto de treino e caçá-los só com ferramentas.