> ## Documentation Index
> Fetch the complete documentation index at: https://docs.replit.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Transforme o feedback de clientes em melhorias funcionais

> Transforme o feedback de clientes em uma alteração pontual no repositório com o Replit, teste a melhoria em um preview de desenvolvimento e prepare um pull request para a revisão da equipe.

Os clientes sempre esquecem um campo obrigatório no seu formulário de cadastro. Em vez de parar em um ticket de suporte ou em um pedido de funcionalidade, trabalhe com o Replit para entender o comportamento atual, propor uma melhoria pontual e testá-la em um preview de desenvolvimento. Quando o resultado estiver pronto, prepare um pull request para sua equipe revisar.

O mesmo fluxo de trabalho pode ajudar com uma mensagem de erro pouco clara, um link de ajuda quebrado ou uma melhoria maior que precisa da sua especialização. Comece com um problema e uma forma clara de verificar se a alteração o resolve.

## Ideal para

* Especialistas de suporte que querem transformar um problema recorrente de clientes em uma correção proposta.
* Gerentes de produto que querem avaliar uma melhoria em relação à implementação existente.
* Designers e engenheiros que querem iterar em um fluxo de trabalho real antes de enviar alterações para revisão.

## Conectores

Você pode usar o GitLab em vez do GitHub. Um conector de suporte é opcional: você pode começar com um resumo higienizado do feedback ou indicar ao Replit uma fonte que você conectou e tenha autorização para ler.

## Antes de começar

Você precisa de acesso ao desenvolvimento baseado em repositório no seu workspace e de permissão para ler o repositório. Abrir um pull request também exige permissão para fazer push de uma branch ou usar o fluxo de fork aprovado da sua equipe.

Escolha um problema específico e identifique o repositório que implementa a experiência afetada. Remova informações pessoais de clientes dos exemplos. Use dados de teste e credenciais de desenvolvimento ao testar o app, não contas reais de clientes.

Para instruções de conexão, consulte [Conecte-se ao seu repositório](https://docs.replit.com/pt/build/code/connect-your-repository.md).

## Dê o prompt ao Replit

Clientes relatam que não conseguem saber qual campo obrigatório do cadastro
deixaram de preencher. Revise \[fonte do feedback ou resumo higienizado] e
inspecione o fluxo de cadastro em \[URL do repositório]. Explique o comportamento
atual e proponha uma melhoria pontual usando nossos componentes de formulário
existentes. Mantenha as regras de validação inalteradas. Peça que eu confirme a
abordagem antes de editar e depois mostre-me um preview de desenvolvimento e os
resultados dos testes relevantes. Não faça commit, push nem abra um pull request
até que eu peça.

## O que esperar

```mermaid theme={null}
flowchart LR
    A["Customer feedback"] --> B["Understand the existing code"]
    B --> C["Agree on a focused change"]
    C --> D["Preview and verify"]
    D --> E["Propose it for team review"]
```

**1. Entenda o problema**

O Replit lê o feedback que você fornece ou que autoriza que ele recupere e
depois examina a implementação relevante. Verifique se a explicação proposta
corresponde ao problema do cliente. Alguns relatos não provam que todos os
clientes são afetados, e o código-fonte sozinho não estabelece o comportamento
em produção.

**2. Combine a melhoria**

Decida o que deve mudar e o que deve permanecer igual. Neste exemplo, o
objetivo é deixar mais claros os erros de campos obrigatórios, não criar novos
requisitos de cadastro. Peça ao Replit que reutilize os componentes existentes
e mantenha separadas as alterações não relacionadas.

**3. Teste a alteração em um preview**

O Replit prepara uma configuração de desenvolvimento, faz a alteração combinada
e inicia o app quando a configuração permite. Abra o preview, envie o formulário
com um campo obrigatório vazio e depois corrija-o. Dê feedback específico sobre
a mensagem de erro, o layout e a interação.

Se a configuração exigir credenciais, insira credenciais de desenvolvimento
limitadas pelo fluxo seguro de secrets. Se você aprovar um serviço simulado
(mock), deixe essa limitação explícita em vez de tratá-lo como um teste da
integração real.

**4. Confira o resultado**

Peça ao Replit que execute as verificações relevantes e informe os testes
aprovados, reprovados e bloqueados. Inspecione o diff e confirme que o
comportamento de validação existente permanece intacto. Inclua a navegação por
teclado e o comportamento em telas estreitas quando relevante.

Capturas de tela podem ajudar a explicar uma alteração visual, mas não
substituem testes nem revisão.

**5. Prepare o pull request**

Quando estiver satisfeito com o resultado e entender suas limitações, peça:

Abra um pull request em rascunho para esta melhoria. Siga as diretrizes de
contribuição do repositório. Descreva o problema do cliente sem incluir
detalhes privados de clientes, explique a alteração e inclua os resultados
de testes relevantes e evidências visuais. Informe claramente tudo o que não
conseguimos verificar.

No GitLab, peça um merge request em rascunho. Sua equipe revisa a alteração
proposta pelo processo que já existe. Abrir o pedido não faz o merge nem o
deploy dele.

Você termina com uma contribuição pontual que conecta o problema do cliente a uma implementação e às evidências de verificação dela. Confirme que a alteração foi de fato lançada antes de dizer aos clientes que o problema foi corrigido.

## Adapte ao seu caso

Verifique se alguma issue ou pull request aberto já trata este feedback antes
de começarmos. Se tratar, resuma esse trabalho e sugira como posso contribuir
sem duplicá-lo.

O feedback é sobre um erro de digitação na confirmação do cadastro, não sobre
a lógica de cadastro. Corrija apenas esse texto, preserve o estilo existente e
mostre-me o resultado.

Esta melhoria precisa de uma regra de negócio confirmada pelo nosso especialista
de produto. Liste as decisões pendentes antes de implementar qualquer coisa.
Mantenha o comportamento confirmado separado das suposições.

## Solução de problemas

> **O feedback é vago demais para reproduzir**
>
> Peça a etapa afetada, o comportamento esperado e o comportamento observado.
> Use exemplos higienizados. Peça ao Replit que separe possíveis explicações das
> conclusões respaldadas pelo código e pelos testes de desenvolvimento.

> **O preview não consegue rodar**
>
> Peça ao Replit que inspecione as instruções de configuração do repositório e
> identifique as dependências, serviços ou permissões ausentes. Informe o
> bloqueio na passagem de trabalho em vez de afirmar que o comportamento foi
> testado.

> **A correção proposta está ficando grande demais**
>
> Volte ao problema original e peça a menor alteração útil. Separe redesigns
> mais amplos ou novos requisitos em trabalhos posteriores.

> **O revisor pede alterações**
>
> Peça ao Replit que avalie o feedback e atualize o pedido aberto existente
> quando apropriado. Verifique novamente o comportamento afetado após as
> correções. Se o pedido já passou por merge, trate o trabalho adicional como
> uma nova contribuição.

## Relacionados

> **[Analise o feedback de clientes](https://docs.replit.com/pt/use-cases/analyze-customer-feedback.md)**
>
> Identifique temas recorrentes antes de escolher uma melhoria para trabalhar.

> **[Programe com o Replit](https://docs.replit.com/pt/build/code/code-with-replit.md)**
>
> Entenda o desenvolvimento baseado em repositório e comece com sua equipe.