docs: execute ux/ui test plan and record product decisions

[sarahw3b]

Closes #8

Este PR conclui a execução do plano de testes de UX/UI formalizando decisões de produto, sem necessidade de alterar código (dispensando testes no emulador).

Atualizações realizadas:

spec/ui_design.md: Formalizadas as regras sobre largura fluida nas telas pós-login, dark mode fixo, uso do ripple M3, exceção da cor verde no geofencing e limite de toques no fluxo de emergência.

spec/ux_ui_test_plan.md: Achados marcados como resolvidos e adicionado o roteiro do Cenário 3 (UXtweak) para testar a compreensão do estado offlline.

[hbgit]

Revisão da PR #12

PR só de documentação (spec/ui_design.md +8, spec/ux_ui_test_plan.md +22, nenhum código tocado), fechando a issue #8. Revisei cruzando cada um dos 9 itens da issue com o texto adicionado, verifiquei as afirmações factuais checáveis contra o código atual e investiguei o CI vermelho.

⚠️ Conflito com a PR #11 (ponto mais importante desta revisão)

O novo texto em spec/ui_design.md afirma:

"Fica documentado explicitamente que a definição brightness: Brightness.dark nos temas é fixa e permanente. O app não reage às preferências de modo claro/escuro do Sistema Operacional."

Isso é o oposto do que a PR #11 (ainda aberta, não mesclada) implementa — tema claro/escuro/automático com ThemeMode.system como padrão, fechando a issue #9. Se as duas PRs forem mescladas sem coordenação, a spec passa a afirmar uma decisão que o código contradiz no mesmo instante. Recomendo resolver a ordem antes do merge desta PR: ou aguardar a #11 fechar (e reescrever esse trecho), ou suavizar a frase para não afirmar permanência categórica enquanto a #11 está em revisão.

Os 9 itens da issue #8, item a item

Fechamento por documentação é válido (decisão de produto pura, como a própria issue já oferecia):

• §1.1/§3.4 (Container responsivo) — confirmei no código que VisitRegistrationScreen não tem ConstrainedBox(maxWidth: ...) hoje (só um maxHeight no picker de pacientes, widget diferente) — a decisão de revogar o max-w-2xl para telas pós-login reflete o estado real, não esconde nada.
• §1.4 (Ripple M3 vs. active:scale) — registro de equivalência, sem necessidade de teste.
• §3.1 (Exceção de cor no geofencing) — confirmei em apps/acs/lib/app/app.dart:1280 que o texto "Local alcançado..." usa mesmo AcsColors.green — a decisão documentada bate com o código.
• §2.3 (Hierarquia do botão de emergência) — confirmei em apps/patient/lib/app/app.dart:1079-1080 que o botão de pânico é width: 208, height: 208 — bate com "domina o viewport".

Marcados [Resolvido] sem a evidência que a própria issue #8 pedia (a descrição da PR admite que dispensou testes no emulador, o que é consistente com esse gap):

• §1.3 (Foco visível) — a issue pedia checagem visual em emulador nos dois temas; a PR só declara "Inspeção visual validada", sem print/evidência.
• §2.1 (Fricção do fluxo de emergência) — a issue pedia medir toques/tempo reais antes de formalizar o limiar; a PR define "≤4 toques e ≤10s" sem descrever a medição.
• §3.2 (Reordenação da fila) — a issue pedia avaliar em dispositivo se a transição é perceptível; a PR conclui "rebuild nativo atende" sem evidência de avaliação em dispositivo.

Precisa de reclassificação, não só de evidência — §3.3 (Compreensão do estado offline, prioridade Alta na issue): a issue pede explicitamente um teste de usuário no UXtweak, "não só auditoria técnica". A PR escreve o roteiro do "Cenário 3" (ótimo, é um passo real), mas não há nenhum resultado de execução — marcar como [Resolvido] sobre-representa o estado. Sugiro renomear para algo como "roteiro elaborado, execução pendente" até o teste rodar de fato, já que é o único item de prioridade Alta da issue.

Sugestão geral para os itens do segundo grupo: não bloqueia o merge dado que a issue já permitia fechamento por decisão documentada em vários casos, mas vale anexar uma nota mínima de evidência (print do foco, como os 4 toques/10s foram cronometrados) ou deixar explícito que a validação foi um julgamento de produto, não uma medição.

CI (android-e2e) — não bloqueante

O check aparece vermelho, mas não tem relação com esta PR. Investiguei as últimas execuções do workflow: android-e2e falha ou é cancelado em todas as execuções recentes que verifiquei — inclusive no último push direto para main — com assinaturas de falha diferentes entre elas (timeout em encrypted_storage_test.dart numa execução, "0 tests passed, 1 failed" noutra). É instabilidade pré-existente do job de e2e no emulador, não uma regressão desta PR (que não toca nenhum código).

🤖 Gerado com Claude Code