Merge pull request #502 from fsolla/plans/plan-issue-12

plan(B182/B183): PWA iOS — zoom preso no viewport + auto-zoom de inputs (planos de intenção)

docs/plans/pwa-ios-autozoom-input-foco.md

@@ -0,0 +1,73 @@
+# PWA iOS: foco na omnibox de filtros aplica auto-zoom que não volta
+
+Status: planejado (blocked — plano aguardando merge em main)
+Atualizado em: 2026-08-09
+Issue: #501
+Priority: P1
+Model: composer-2.5
+Model-local: deepseek-v4-flash-high
+Impeccable: A — N/A (bug fix; restaura o comportamento esperado, sem redesenho)
+Canvas UI: N/A — sem UI nova
+Appetite: ~0,5–1 dia eng
+Responsável: —
+
+## Intenção
+
+No PWA `/campanha` no iPhone: ao tocar na omnibox de filtros (ex. lista de Municípios), o Safari aproxima a tela no input; ao terminar de digitar, a tela fica nessa perspectiva aproximada, com as laterais do app cortadas — o usuário precisa perceber e desfazer o zoom na mão.
+
+Causa conhecida e documentada: o Safari iOS aplica auto-zoom em qualquer input com font-size renderizado menor que 16px ao focar, e no PWA standalone nem sempre restaura a escala ao fechar o teclado. A omnibox das listas usa `text-sm` (14px) — abaixo do limiar. O mesmo vale para outros inputs do app (login, formulários, wizard), que podem reproduzir o mesmo comportamento.
+
+## Persona e fluxo
+
+- **Persona / contexto:** staff da campanha (coordinator/advisor) no campo, filtrando listas (`/campanha/municipios`, `/campanha/apoiadores`, `/campanha/liderancas`, etc.) no iPhone.
+- **Job principal:** filtrar e seguir trabalhando, sem o app "desarrumar" a tela.
+- **Fluxo desejado:** toca na omnibox → teclado abre → digita e escolhe filtro → teclado fecha → tela exatamente como estava, na mesma escala.
+- **Anti-goals de produto:** não é redesenho da omnibox; não é "subir o texto para 16px no desktop".
+
+## Objetivo e aceite
+
+- Tocar na omnibox (e em qualquer input do PWA: login, filtros, formulários, wizard) não provoca zoom automático no iPhone.
+- Após fechar o teclado, a página permanece na escala original — sem corte de laterais, sem "desfazer zoom" manual.
+- No desktop e em telas maiores, a aparência dos inputs continua como hoje (a fonte maior vale só onde o trigger do iOS existe).
+- Nenhuma mudança de layout/visual além do tamanho de fonte dos campos no mobile, quando necessária.
+
+## Dados (intenção)
+
+- **Vou apresentar dados?** Não — bug de interação; verificação visual no aparelho.
+- **Decisões desbloqueadas:** nenhuma para o produto.
+
+## Direção no codebase (hipótese)
+
+- **Áreas prováveis:** `CampaignListOmnibox` (`src/components/campaign/shared/CampaignListOmnibox.tsx` — input `text-sm`; chassis compartilhado por todas as listas: `MunicipalityFilters`, `SupporterFilters`, `LeadershipFilters`, `TerritoryFilters`, `StateDeputyFilters`, `OrganizationFilters`, `CampaignUpdatesFilters`, `ActivityFilters`…); demais inputs dos formulários de `/campanha` (login, wizard de liderança, modais de criação) — o trigger é o mesmo, então o fix provavelmente é uma regra única para inputs do PWA no touch/mobile, não um ajuste campo a campo.
+- **Precedente a olhar:** fixos externos documentados (West-Wind, t3code PR #1652, BookStack #5935) — padrão `16px no mobile, tamanho original no desktop` (`sm:` override) ou regra global de inputs.
+- **Risco de acoplamento:** a omnibox é usada por ~8 listas com o mesmo chassis — mudança no componente compartilhado cobre todas de uma vez; não duplicar o fix por lista.
+
+## Dependências
+
+- Nenhuma dura. Suave: reduz a frequência do B182 (zoom preso) ao eliminar o trigger — podem ser executados em qualquer ordem.
+
+## Fora de escopo
+
+- Redesenho da omnibox ou das listas.
+- Corrigir o estado "zoom preso" em si quando ele vier de outras fontes (isso é o B182).
+- Inputs do site público (fora do PWA `/campanha`), salvo se reproduzirem e for trivial.
+
+## Rabbit holes de produto
+
+- **Caçar todos os inputs do app um a um.** O trigger é sistêmico (regra do iOS por font-size), então fix pontual por componente vira whack-a-mole. **Corte neste item:** regra única para inputs do PWA no mobile + verificação amostral (omnibox, login, um formulário), não inventário exaustivo.
+- **Virar debate de acessibilidade de zoom global.** `maximum-scale=1` global resolve mas degrada; aqui a regra de 16px é suficiente e não bloqueia nada. **Corte:** sem política de escala global neste item (se precisar, vive no B182 como fallback).
+
+## Questões em aberto (produto)
+
+- ~~Aplicar 16px em todos os inputs ou só na omnibox?~~ **Decidido no gate (2026-08-09): todos de uma vez** — regra única para inputs do PWA no mobile/PWA (inclui `contenteditable`/select), cobrindo omnibox, login, formulários e wizard com o mesmo trigger.
+- **O texto dos campos ficar maior no iPhone é aceitável?** **Opções:** A) sim, 16px é padrão de leitura em mobile; B) compensar visualmente com layout. **Recomendação:** A — 16px é o tamanho de input padrão no iOS; mudança perceptível mas coerente. _(assumido — validar com produto)_
+
+## Referências
+
+- GitHub Issue #501
+- Pesquisa externa (reaproveitável pelo executor):
+  - West-Wind (2023) — "Preventing iOS Textbox Auto Zooming": limiar 16px + `maximum-scale` seletivo como fallback
+  - t3code PR #1652 — padrão `text-base` no mobile com `sm:` override para desktop
+  - BookStack #5935 — zoom preso no PWA iOS ao editar texto; lista de workarounds
+  - dev.to (cederhook, 2026-07) — contexto do viewport standalone preso pós-teclado (parente do B182)
+- Código: `src/components/campaign/shared/CampaignListOmnibox.tsx` (input `text-sm`, linha ~225), formulários em `src/app/(campaign)/campanha/(app)/…` e `src/components/campaign/<domínio>/…`

docs/plans/pwa-ios-zoom-preso-bordas-cortadas.md

@@ -0,0 +1,74 @@
+# PWA iOS: tela fica ampliada e com as bordas cortadas (zoom preso)
+
+Status: planejado (blocked — plano aguardando merge em main)
+Atualizado em: 2026-08-09
+Issue: #500
+Priority: P1
+Model: cursor-grok-4.5-medium
+Model-local: deepseek-v4-high
+Impeccable: A — N/A (bug fix; restaura o comportamento esperado, sem redesenho)
+Canvas UI: N/A — sem UI nova
+Appetite: ~0,5–1,5 dia eng (inclui diagnóstico no aparelho real)
+Responsável: —
+
+## Intenção
+
+O PWA `/campanha` instalado no iPhone apresenta a tela "comida" pelas bordas do aparelho: parece que a página inteira passa um pouco o limite da tela, e as bordas (topo/laterais) ficam cortadas. É comportamento específico do PWA em Safari/iOS — na aba do Safari não acontece.
+
+Pesquisa prévia confirma família de bugs conhecida do WebKit em PWA standalone: o visual viewport fica preso num scale > 1 (zoom "colado") — seja após usar um input com teclado (o teclado zooma e o restore não acontece), seja ao abrir/retomar o app de segundo plano. Sintomas relatados por outras aplicações são idênticos: "all edges clipped", "stays zoomed until the user pinches out". Há também regressões documentadas do iOS 26 com `position: fixed`/viewport após teclado.
+
+## Persona e fluxo
+
+- **Persona / contexto:** staff da campanha (coordinator/advisor) no campo, usando o PWA instalado no iPhone como ferramenta diária.
+- **Job principal:** abrir o app e enxergar a tela inteira, na escala certa, sem ter que "consertar" o zoom.
+- **Fluxo desejado:** abre o app (ou retoma de segundo plano) → tela ocupa exatamente a tela do aparelho, escala 100%, nenhuma borda cortada → usa por horas (lista, filtros, ficha) sem nunca precisar desfazer zoom manualmente.
+- **Anti-goals de produto:** bloquear zoom por pinça do usuário (acessibilidade); hack de tela cheia que esconda conteúdo; mudar o design do app.
+
+## Objetivo e aceite
+
+- Ao abrir ou retomar o PWA, a escala está em 100% e nenhuma borda está cortada (validar no aparelho real, não em emulador).
+- Após usar qualquer input + teclado e fechar o teclado, a tela volta sozinha à escala original (sem intervenção do usuário).
+- Zoom por pinça continua funcionando para o usuário (não é um "app que não dá zoom").
+- Nenhuma regressão no comportamento em aba do Safari nem no desktop.
+
+## Dados (intenção)
+
+- **Vou apresentar dados?** Não — bug de renderização/viewport, sem métrica nova.
+- **Decisões desbloqueadas:** nenhuma para o produto; verificação é visual no aparelho.
+
+## Direção no codebase (hipótese)
+
+- **Áreas prováveis:** config de viewport do `/campanha` (`src/app/(campaign)/layout.tsx` — hoje só `themeColor`, sem `viewport-fit` nem política de escala); shell do app `h-svh overflow-hidden` (`src/app/(campaign)/campanha/(app)/layout.tsx`); chrome fixo do PWA (`CampaignBottomNav`, `CampaignMobileTopBar` — que já usam `env(safe-area-inset-*)`, precedente de que a intenção de tela cheia existe); meta `apple-mobile-web-app-status-bar-style` (`statusBarStyle: 'default'` hoje).
+- **Precedente a olhar:** pesquisa externa citada em Referências — a família de bugs é a mesma relatada por Discourse, BookStack, Starbucks PWA etc.
+- **Risco de acoplamento:** o shell `h-svh`/`overflow-hidden` é a espinha de layout de todas as páginas `(app)` — qualquer mudança de altura/viewport precisa manter lista/quadro/agenda rolando dentro do painel, não a página inteira.
+
+## Dependências
+
+- Nenhuma dura. Suave: B183 (eliminar o trigger do auto-zoom de input reduz a frequência deste bug) — podem ser executados em qualquer ordem.
+
+## Fora de escopo
+
+- Reescrita do sistema de teclado/keyboard-inset próprio (polifill custom do teclado virtual) — se precisar, é outro item.
+- Redesenho do chrome do PWA (safe-area já está parcialmente tratada).
+- Bugs de terceiros não reproduzíveis no nosso app.
+
+## Rabbit holes de produto
+
+- **Caçar a família inteira de bugs WebKit.** A lista de bugs do standalone é longa e cada versão de iOS se comporta diferente. **Corte neste item:** corrigir o sintoma do nosso app (zoom preso / escala > 1) com o menor conjunto de medidas verificado no aparelho; sem polifill geral de viewport.
+- **Virar debate de acessibilidade.** Bloquear zoom globalmente resolveria fácil, mas degrada o usuário. **Corte:** se a política de escala for necessária, ela vale só para o modo standalone/PWA (ou via regra de fonte 16px), nunca para a aba.
+
+## Questões em aberto (produto)
+
+- ~~O corte é permanente ao launch ou só após input/resume?~~ **Decidido no gate (2026-08-09): desde o launch** — o corte de bordas está presente já ao abrir o app, independente de interação. Hipótese principal passa a ser zoom/escala preso do próprio standalone no launch/resume (não o trigger de teclado do B183); a verificação no aparelho deve medir a escala do visual viewport logo no primeiro launch (cold open) e comparar com um force-quit/rotação.
+- **Bloquear escala como último recurso?** **Opções:** A) nunca bloquear; B) `maximum-scale` seletivo só no standalone iOS, sem afetar aba/pinça (WCAG tradeoff conhecido); C) bloquear em tudo. **Recomendação:** A ou B, nunca C — prefere-se eliminar o trigger (16px, B183) e curar o estado preso; o bloqueio seletivo fica como fallback documentado se o bug persistir em iOS corrente. _(assumido — validar com produto)_
+
+## Referências
+
+- GitHub Issue #500
+- Pesquisa externa (já feita, reaproveitável pelo executor):
+  - WebKit bug 237961 — standalone + `viewport-fit: cover`: overscroll/`position: fixed`/`-webkit-fill-available` quebrados
+  - dev.to (cederhook, 2026-07) — PWA standalone iOS: viewport encolhe com o 1º teclado e não volta; heal via re-measure forçado
+  - west-wind (2023) — auto-zoom de input iOS e por que `maximum-scale` seletivo funciona no iOS sem matar a pinça
+  - Apple Developer Forums — iOS 26: `visualViewport.offsetTop` não reseta após teclado; fixed elements deslocados
+  - StackOverflow — `100dvh` no standalone não preenche a tela física (viewport unidades reportam menos o inset)
+- Reddit r/PWA — PWA standalone abre "zoomed" ao retomar de segundo plano (Starbucks PWA reproduz)