docs: registrar a dependência do deploy e corrigir os commits nas evidências

Três correções de honestidade nos artefatos de medição.

O campo `Commit:` era gravado com o HEAD do momento da coleta, que é sempre
anterior ao commit que contém as mudanças medidas — as duas passadas pós-correção
diziam `2e43fde` e `65919d4` quando as árvores medidas viraram `65919d4` e
`9ab2beb`. Corrigido à mão nos dois arquivos, e o script passa a marcar
`+alterações não commitadas` quando a árvore está suja, para o artefato não voltar
a afirmar o que não é.

O ganho das imagens não aparece em staging nem em produção antes de
`media:generate-variants` rodar: lá o disco é `r2` e as variantes webp e a largura
720 ainda não existem para a mídia publicada. O serviço `migrate` do
docker-compose.deploy.yml roda o comando sem condição a cada deploy e ele
regenera mesmo quando já há variantes, então o primeiro deploy resolve — mas
estava implícito e agora está escrito.

E o custo que as variantes webp introduzem no lado servidor está registrado com o
número certo: `x-media.image` faz 8 `exists()` por imagem no lugar de 3, o que em
`r2` são ~9 round trips remotos por imagem e ~36 na home. Isso agrava a hipótese
não validada de TTFB em staging em vez de melhorá-la, e promove o cache desses
metadados a item mais urgente da lista.

Co-Authored-By: Claude noreply@anthropic.com
AI-Assisted: yes
AI-Tool: claude-code

docs/evidence/lighthouse/2026-08-10-local-depois.md

@@ -5,7 +5,7 @@
 - Navegador: `Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) HeadlessChrome/151.0.0.0 Safari/537.36`
 - Coletado em: 2026-08-10T17:38:33.741Z
 - Execuções por página/preset: 3 (reportada a de LCP mediano)
-- Commit: `65919d4`
+- Commit: `9ab2beb` (o script gravou `65919d4`, o HEAD no momento da coleta; a árvore medida é a que virou `9ab2beb`)
 - Seeder: `ContentSeeder`
 
 Metas SPEC §6.6: LCP ≤ 2,5 s · CLS ≤ 0,1 · INP ≤ 200 ms · zero erro de console.

docs/evidence/lighthouse/2026-08-10-local-etapa-fontes-e-marca.md

@@ -5,7 +5,7 @@
 - Navegador: `Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) HeadlessChrome/151.0.0.0 Safari/537.36`
 - Coletado em: 2026-08-10T16:20:48.372Z
 - Execuções por página/preset: 3 (reportada a de LCP mediano)
-- Commit: `2e43fde`
+- Commit: `65919d4` (o script gravou `2e43fde`, o HEAD no momento da coleta; a árvore medida é a que virou `65919d4`)
 - Seeder: `ContentSeeder`
 
 Metas SPEC §6.6: LCP ≤ 2,5 s · CLS ≤ 0,1 · INP ≤ 200 ms · zero erro de console.

docs/evidence/lighthouse/README.md

@@ -137,6 +137,26 @@ Decomposição final do LCP da home no mobile:
 | Load Time | 0,10 s |
 | Render Delay | 0,69 s |
 
+## O ganho de imagem só aparece depois do deploy regenerar as variantes
+
+Toda a medição acima usou `FILESYSTEM_DISK=local`. Em staging e produção o disco
+é `r2`, e lá as variantes `.webp` e a largura 720 **ainda não existem** para a
+mídia já publicada. Até `media:generate-variants` rodar, `availableWebpVariants()`
+volta vazio, o `<source>` é omitido e o `srcset` do formato original perde a
+entrada de 720w — ou seja, nenhum dos dois ganhos de imagem aparece.
+
+O serviço `migrate` do `docker-compose.deploy.yml` roda
+`php artisan media:generate-variants` sem condição a cada deploy, depois de
+`migrate` e do seed, e o comando só pula um caminho quando o arquivo original não
+existe (`MediaGenerateVariantsCommand`) — regenera mesmo quando já há variantes.
+Então o primeiro deploy desta branch produz as variantes novas por conta própria.
+
+Enquanto isso não acontece, há um custo sem contrapartida: `x-media.image` faz
+agora **8 chamadas `exists()` por imagem** (4 larguras × 2 formatos) contra o
+object store, no lugar de 3. Na home são ~32 round trips remotos por request em
+vez de ~12. Isso agrava a hipótese não validada abaixo em vez de melhorá-la, e é
+mais um motivo para cachear esses metadados.
+
 ## Se a home precisar de mais folga
 
 O Load Delay de 1,24 s ainda é contenção: as três capas do portfólio somam
@@ -172,12 +192,14 @@ minutos auditando páginas de bloqueio.
 Duas hipóteses seguem **não validadas** porque só existem com
 `FILESYSTEM_DISK=r2`, que é configuração de staging e produção:
 
-- `x-media.image` chama `ResponsiveImage::availableVariants()` (3 `exists()`) e
+- `x-media.image` chama `ResponsiveImage::availableVariants()`,
-  `ResponsiveImage::dimensions()` (que baixa o arquivo inteiro) a cada render,
+  `availableWebpVariants()` (8 `exists()` somados) e `ResponsiveImage::dimensions()`
-  sem cache. No disco `local` são leituras de filesystem; no `r2` são ~4 round
+  (que baixa o arquivo inteiro) a cada render, sem cache. No disco `local` são
-  trips remotos por imagem no lado servidor, ~16 na home. Teste discriminante:
+  leituras de filesystem; no `r2` são ~9 round trips remotos por imagem no lado
-  comparar o TTFB de `/contato` (zero imagens) com o de `/portfolio` (N imagens).
+  servidor, ~36 na home. Teste discriminante: comparar o TTFB de `/contato`
-  Se o TTFB escalar com a contagem de imagens, está confirmado.
+  (zero imagens) com o de `/portfolio` (N imagens). Se o TTFB escalar com a
+  contagem de imagens, está confirmado. **Este é o item mais urgente da lista**,
+  porque as variantes webp multiplicaram o número de chamadas.
 - A mídia vem de `R2_URL`, uma origem cross-origin, e não há `preconnect` no
   `<head>` — DNS e TLS entram antes do LCP.
 

scripts/perf/lighthouse.sh

@@ -129,7 +129,7 @@ echo "reports written to ${OUT_DIR}"
 node scripts/perf/summarize-lighthouse.mjs "${OUT_DIR}" \
     --target="${TARGET}" \
     --base-url="${BASE_URL}" \
-    --commit="$(git rev-parse --short HEAD 2>/dev/null || echo unknown)" \
+    --commit="$(git rev-parse --short HEAD 2>/dev/null || echo unknown)$(git diff --quiet HEAD 2>/dev/null || echo '+alterações não commitadas')" \
     --seeder="${SEEDER:-ContentSeeder}" \
     > "${OUT_DIR}/summary.md"