# Sistema Atendimento

Versão 1.0.0 · padrão de produto demonstrativo · dados fictícios e estado em memória.

O showcase está em `src/partials/design-system/atendimento.html` e o comportamento em `tpSupport`, no adapter `src/js/components/design-system.js`. Ele demonstra a estrutura visual e comportamental de um atendimento sem presumir a API, canal ou regra operacional do produto final.

## Objetivo

Dar contexto suficiente para uma pessoa reconhecer a solicitação, responder com clareza, registrar uma nota interna, informar a próxima ação e recuperar uma falha sem prometer prazo ou conclusão não confirmados.

## Anatomia

| Região | Conteúdo | Regra |
| --- | --- | --- |
| Resumo | abertos, não lidos, fila e SLA | indicadores de exemplo; não são métricas reais |
| Filtros | busca, fila e ordenação | buscar pessoa, empresa, assunto e canal; não expor dados sensíveis |
| Inbox | avatar, nome, preview, canal, atualização, status e prioridade | item inteiro é um botão nativo; seleção anuncia o atendimento |
| Conversa | mensagens recebidas, enviadas, internas, sistema e erro | `role="log"`, `aria-live="polite"` e texto sempre visível |
| Composer | textarea, resposta rápida, anexo, nota interna, emoji e envio | nenhuma ação externa no demo; loading desabilita duplicidade |
| Contato | pessoa, empresa, telefone, e-mail, última atividade, responsável, tags e SLA | contexto não substitui autorização de acesso |
| Próxima ação | orientação curta e verificável | não inventar prazo, status financeiro ou conclusão |

## Estados

| Estado | Uso | Tratamento visual e textual |
| --- | --- | --- |
| Aberto | atendimento em trabalho | informação e próxima ação visíveis |
| Pendente | aguardando ação interna | aviso de pendência e responsável |
| Aguardando cliente | falta informação do contato | explicar o dado necessário; não culpar a pessoa |
| Resolvido | evidência de conclusão disponível | sucesso com registro do que foi concluído |
| Fechado | ciclo encerrado | leitura; reabertura exige regra de produto |
| Não lido | nova mensagem | ponto visual + texto/contagem; nunca apenas cor |
| SLA | janela operacional | só exibir com origem e definição aprovadas |
| Enviando | ação em andamento | spinner, `aria-busy` + `aria-disabled` (o foco permanece no botão) e bloqueio de duplicidade no handler |
| Enviado | registro local confirmado | confirmação limitada ao escopo real da ação |
| Falha | tentativa não confirmada | erro, causa conhecida quando possível e `Tentar novamente` |
| Nota interna | comunicação exclusiva da equipe | cor/label distintos; nunca apresentar como resposta externa |
| Vazio | filtros sem resultado | informar que a busca não encontrou itens e como limpar |

## Conteúdo

Escreva: “Recebemos sua solicitação. Vou verificar o contexto e retorno com a próxima ação confirmada.” Só use essa confirmação quando o recebimento estiver realmente confirmado no produto. Para falha: “Não foi possível confirmar o envio. Revise o contexto e tente novamente.” Evite “em até 24 horas”, “resolvido” ou qualquer compromisso sem fonte.

Identificadores e contatos do showcase usam `conv-*`, `DEMO-*` e `example.invalid`. Antes de conectar dados reais, definir controle de acesso, retenção, mascaramento, auditoria e política de anexos.

## Contrato técnico

`tpSupport` mantém `query`, `filter`, `sort`, `selectedId`, `message`, `fileName`, `internal`, `sending`, `notice`, `quickReplies` e `conversations`. Os métodos públicos do demo são `select`, `chooseQuickReply`, `addAttachment`, `toggleInternal`, `send`, `retry` e `setStatus`.

O partial usa `x-id` para vínculos de formulário e `x-text` para conteúdo dinâmico. Ao integrar uma API, substitua as funções locais por um adaptador do produto, mantendo a anatomia, os estados, os nomes acessíveis e os contratos de erro. Não adicione chamadas ao partial do Design System.

## Checklist de integração

- Confirmar canal, fonte do SLA, timezone, responsável e permissões.
- Definir paginação/virtualização para filas grandes.
- Persistir estado somente no produto autorizado; remover demos e `example.invalid`.
- Sanitizar texto e anexos; não usar `innerHTML` para conteúdo de contato.
- Mapear erro técnico para microcopy acionável e log interno seguro.
- Testar teclado, leitor de tela, 200% de zoom, 320 px, tema escuro e `prefers-reduced-motion`.
- Validar com Atendimento, Produto, Engenharia, Privacidade e QA antes de homologar.