Prompt para diagnosticar e resolver o comportamento do Enter enviando mensagens em vez de nova linha

Contexto: um aplicativo de mensagens atualmente envia a mensagem quando o usuário pressiona Enter, em vez de inserir uma nova linha, o que gera frustração e impacto potencial na OCD do usuário descrito no relato (ex.: Wth, this is so annoying. Why did they have to mess around with the Enter button. I need it to make a new line but I find mid paragraph that the message is sent and I have to stop the generation and ask my question again. It messes with my ocd so bad😭😭😭). Este prompt é destinado a gerar soluções abrangentes para diagnosticar, projetar e testar melhorias de UX/front-end relacionadas ao comportamento da tecla Enter, incluindo a possibilidade de alterar o comportamento ou tornar isso configurável pelo usuário.

Instruções para a IA que irá responder ao prompt:
1) Identificar causas prováveis (técnicas e de UX) que levam ao envio da mensagem ao pressionar Enter, incluindo tratamento de eventos keydown/keypress/keyup, diferenças entre plataformas (web vs mobile), componentes de área de texto (textarea) vs inputs, e configuração atual do atalho.
2) Propor estratégias de UX aceitáveis, incluindo opções: a) manter Enter para nova linha e usar Shift+Enter para envio; b) permitir configuração por usuário com fallback para comportamento atual; c) oferecer atalhos configuráveis por plataforma; d) garantir consistência entre web e mobile; e) considerar mensagens de ajuda e confirmações para evitar envios acidentais.
3) Fornecer um conjunto de soluções de código de exemplo (preferencialmente JavaScript/React) para detectar Enter e Shift+Enter, impedir envio não desejado, e implementar as opções de configuração (por exemplo, controller de comportamento via estado de configuração, props ou contexto). Incluir também caminhos para implementação em puro HTML/JS e em frameworks populares.
4) Apresentar um plano de testes abrangente com cenários realistas (com e sem Shift+Enter, com configuração ativada/desativada, em diferentes navegadores, em mobile), incluindo critérios de sucesso/aceitação e testes de acessibilidade.
5) Instrumentação de acessibilidade: ARIA, feedback de foco, descrições de comportamento (por exemplo, anúncios de “nova linha” vs “envio”), e compatibilidade com leitores de tela.
6) Sugerir mensagens de ajuda na UI (tooltip, helper text, toasts) para esclarecer o comportamento atual e como mudar.
7) Definir critérios de aceitação e métricas (redução de envios acidentais, melhoria de satisfação do usuário, consistência entre plataformas).
8) Incluir diretrizes de design para manter a consistência visual e de comportamento, com notas sobre internacionalização e tolerância a limitações de acessibilidade.
9) Entregar a saída de forma estruturada com seções claras para facilitar a automação e o consumo por equipes de produto, UX e desenvolvedores.

Formato de saída recomendado (estrutura clara):
- causas_provaveis
- ux_recomendacoes
- codigo_exemplos
- plano_de_testes
- mensagens_para_usuario
- acessibilidade
- configuracoes_disponiveis
- criterios_de_aceitacao
- notas_de_design

Observação: mantenha um tom empático e foque em soluções que reduzam fricção para usuários com OCD, evitando envios acidentais e proporcionando opções de recuperação e configuração.