ilibras-widget 1.4.0 → 1.5.2

package/CHANGELOG.md

@@ -4,6 +4,94 @@ Todas as mudanças notáveis neste projeto serão documentadas neste arquivo.
 
 ---
 
+## [1.5.2] - 2026-09-18
+
+### 🗂️ Uma aba, não duas
+
+Ao criar o atendimento, o widget abria a aba nova **e** trocava a página da aba
+atual. A pessoa terminava com duas.
+
+A causa estava no plano B para pop-up bloqueado:
+
+```js
+const aba = window.open(destino, '_blank', 'noopener');
+if (!aba) window.location.assign(destino);
+```
+
+A especificação manda `window.open` devolver `null` sempre que `noopener` está
+presente — **mesmo quando a aba abre**. O teste lia esse `null` como pop-up
+bloqueado, e a segunda linha disparava sempre.
+
+Agora a chamada vai sem a feature e a proteção é feita na mão
+(`aba.opener = null`), o que dá o mesmo isolamento e preserva o retorno — que é
+justamente o que distingue aba aberta de aba barrada. O plano B continua de pé
+para quando o pop-up é realmente bloqueado: melhor trocar de página do que
+sumir com um atendimento já criado.
+
+---
+
+## [1.5.1] - 2026-09-18
+
+### 🎨 O tema do site não pinta mais o widget
+
+Todas as regras de estilo passaram a ser escopadas por
+`#ilibras-widget-container`.
+
+O widget usava seletores de uma classe só — `.ilibras-widget-submit` tem
+especificidade (0,1,0) e perde para qualquer tema que estilize botões com dois
+níveis. Um `.elementor-kit-275 button` é (0,1,1) e vencia.
+
+O estrago aparecia num site real: botões verdes, cantos arredondados em 30px e
+o "X" de fechar virado pílula — dentro de um widget cuja promessa é justamente
+se bastar no site dos outros. O botão principal escapava por acidente, porque o
+gradiente dele pintava por cima da cor do tema; o de agendar, sem gradiente,
+ficava verde.
+
+Com o prefixo, as regras vão a (1,1,0): ganham de qualquer seletor de tema
+**sem recorrer a `!important`**, e continuam perdendo para o `!important` que o
+README ensina o cliente a usar quando quer customizar de propósito. Quem
+customiza sem `!important` precisa passar a usá-lo.
+
+Problema antigo, anterior à v1.5.0 — só ficou visível quando o segundo botão
+entrou no formulário.
+
+---
+
+## [1.5.0] - 2026-09-18
+
+### 🙋 O formulário pede só o nome
+
+CPF e telefone saíram. Para chamar um intérprete não é preciso identificar a
+pessoa, e cada campo a mais era uma barreira a quem só queria ser atendido — em
+especial um CPF digitado errado, que reprovava o envio inteiro.
+
+Sai junto o que existia só para eles: a validação de CPF, a lista de DDDs, as
+máscaras dos dois campos. O widget ficou 4,5 KB menor.
+
+O que continua: nome (com sobrenome), a caixa de consentimento, a armadilha
+anti-robô e a marca de tempo de abertura.
+
+### 📲 Aviso por SMS mora no iLibras, não aqui
+
+Quem agenda um horário e quer ser avisado por SMS informa o celular **na tela
+de agendamento do iLibras**, e o número vale só para aquele atendimento. Era o
+motivo que restava para o widget pedir telefone de todo mundo — inclusive de
+quem nem ia agendar.
+
+### 🔁 Compatibilidade
+
+A API continua aceitando `cpf` e `telefone`, então **widget antigo instalado em
+site de cliente segue funcionando** sem ser atualizado.
+
+Esta é uma versão **minor** de propósito, e não major: quem seguiu o README e
+fixou `@1` recebe a mudança automaticamente, que é o ponto. A API pública do
+pacote (configuração e métodos) não mudou em nada.
+
+**Requer o iLibras com CPF e telefone opcionais.** Contra uma versão anterior do
+servidor, o cadastro sem CPF seria recusado com erro de validação.
+
+---
+
 ## [1.4.0] - 2026-09-16
 
 ### 📦 O widget virou pacote npm

package/README.md

@@ -4,7 +4,7 @@
 [![JavaScript](https://img.shields.io/badge/JavaScript-ES6+-yellow.svg)](https://developer.mozilla.org/en-US/docs/Web/JavaScript)
 [![CSS3](https://img.shields.io/badge/CSS-3-blue.svg)](https://developer.mozilla.org/en-US/docs/Web/CSS)
 
-Widget embarcável similar ao WhatsApp para captura de dados (Nome e CPF) com integração via API. Envia dados de forma segura via POST e redireciona para plataforma de atendimento. Ideal para integração em sites, sistemas e plataformas web.
+Widget de acessibilidade em Libras: um botão flutuante que leva a pessoa surda ao atendimento com intérprete — ao vivo ou agendado. Pede só o nome, envia por POST e redireciona para a plataforma. Ideal para sites, sistemas e plataformas web.
 
 ![iLibras Widget](https://via.placeholder.com/800x400/25D366/FFFFFF?text=iLibras+Widget)
 
@@ -13,9 +13,9 @@ Widget embarcável similar ao WhatsApp para captura de dados (Nome e CPF) com in
 - 🚀 **Fácil integração** - Apenas 2 linhas de código
 - 🎨 **Totalmente personalizável** - Cores, posição, textos e mais
 - 📱 **Responsivo** - Funciona perfeitamente em desktop e mobile
-- ✅ **Validação automática** - CPF validado antes do envio
+- 🙋 **Pede só o nome** - Nada de CPF ou telefone para ser atendido
+- 📅 **Ao vivo ou agendado** - Entrar na fila agora, ou marcar dia e hora
 - 🔒 **Envio seguro** - Dados enviados via POST para API
-- 🎭 **Máscaras de entrada** - Formatação automática de CPF
 - 🌐 **Universal** - Funciona em qualquer site ou sistema
 - ♿ **Acessível** - Suporte a leitores de tela e navegação por teclado
 - 🌙 **Tema escuro** - Adapta-se automaticamente às preferências do usuário
@@ -213,18 +213,21 @@ Os dados são enviados como **FormData** (similar a um formulário HTML tradicio
 
 ```
 nome: "João Silva"
-cpf: "12345678900"
-telefone: "11987654321"
+modo: "fila"
 token: "seu_token_de_autenticacao"
 ```
 
 | Campo | Descrição | Formato |
 |-------|-----------|------|
 | `nome` | Nome completo do usuário | String |
-| `cpf` | CPF sem formatação (apenas números) | String numérica (11 dígitos) |
-| `telefone` | Telefone sem formatação (apenas números) | String numérica (10-11 dígitos) |
+| `modo` | `fila` (atendimento agora) ou `agendamento` (escolher dia e hora) | String |
 | `token` | Token de autenticação fornecido pela equipe | String |
 
+> Até a v1.4.0 o widget também enviava `cpf` e `telefone`. A partir da v1.5.0
+> não envia mais: para chamar um intérprete não é preciso identificar a pessoa,
+> e cada campo a mais era uma barreira a quem só queria ser atendido. A API
+> continua aceitando os dois campos, para os widgets antigos ainda instalados.
+
 ### Resposta Esperada da API
 
 A API deve retornar um JSON com um link de redirecionamento:
@@ -428,18 +431,6 @@ Todos os dados são enviados via **método POST** (não via URL/GET), garantindo
 - Maior segurança no tráfego de informações sensíveis
 - Conformidade com boas práticas de desenvolvimento web
 
-### Validação de CPF
-
-O widget valida o CPF antes do envio usando o algoritmo de verificação de dígitos. CPFs inválidos são rejeitados automaticamente.
-
-```javascript
-// CPFs aceitos: números válidos com 11 dígitos
-// CPFs rejeitados: 
-// - Números com menos de 11 dígitos
-// - Sequências repetidas (111.111.111-11)
-// - Dígitos verificadores incorretos
-```
-
 ### Validação de Nome
 
 - Entre 3 e 120 caracteres
@@ -447,17 +438,14 @@ O widget valida o CPF antes do envio usando o algoritmo de verificação de díg
   pontuação de código são rejeitados
 - Exige nome e sobrenome
 
-### Validação de Telefone
-
-- DDD conferido contra a lista de códigos em uso no país
-- Celular com 9 dígitos precisa começar em 9; fixo com 8 dígitos, entre 2 e 5
-- Sequências repetidas (00000000000) são rejeitadas
-
 ### Sanitização de Dados
 
-- CPF e telefone: apenas dígitos
 - Nome: espaços das pontas removidos e sequências de espaço reduzidas a um
 
+> O telefone não é mais pedido aqui. Quem agenda um horário e quer aviso por
+> SMS informa o celular na própria tela de agendamento do iLibras, e ele vale
+> só para aquele atendimento.
+
 > **A validação do widget é conveniência, não barreira.** Ela roda no navegador
 > e qualquer pessoa a desliga pelo console. As mesmas regras valem no servidor,
 > e é lá que elas decidem — o widget as repete só para avisar cedo e em