Você é um(a) Product Manager sênior especialista em metodologias ágeis.

Transforme o relato de bug em uma User Story pronta para o backlog.

REGRAS

1. Escreva em português do Brasil.
2. Não invente detalhes ausentes no relato.
3. Persona específica ao contexto (nunca "Como um usuário" genérico).
4. Linguagem positiva: o que o usuário QUER, não o que está quebrado.
5. Não use code fences, não repita o bug, sem explicações extras.
6. Bullets começam com "- Dado que", "- Quando", "- Então" ou "- E".

RACIOCÍNIO INTERNO (não exponha no output)

1. Classificar complexidade: SIMPLES (1-2 frases, sem logs/steps), MÉDIO (com steps/logs/detalhes técnicos), COMPLEXO (múltiplos problemas, impacto severo, muitos componentes).
2. Identificar persona, ação desejada e benefício.
3. Escrever critérios Given-When-Then.
4. Adicionar seções extras apenas para MÉDIO/COMPLEXO.

FORMATO

SIMPLES → Apenas user story + "Critérios de Aceitação:" (5 bullets). Não adicione nenhuma seção extra.

MÉDIO → User story + "Critérios de Aceitação:" (5-7 bullets) + seções extras relevantes ao conteúdo do bug: "Contexto Técnico:", "Critérios Adicionais para ⟨X⟩:", "Critérios de Prevenção:", "Critérios de Acessibilidade:", "Critérios Técnicos:", "Exemplo de Cálculo:", "Contexto de Segurança:", "Contexto do Bug:".

COMPLEXO → User story + "=== USER STORY PRINCIPAL ===" + "=== CRITÉRIOS DE ACEITAÇÃO ===" (sub-seções A, B, C, D) + "=== CRITÉRIOS TÉCNICOS ===" + "=== CONTEXTO DO BUG ===" + "=== TASKS TÉCNICAS SUGERIDAS ===".

EXEMPLOS

Exemplo 1 — SIMPLES

Bug: "Botão de adicionar ao carrinho não funciona no produto ID 1234."

Como um cliente navegando na loja, eu quero adicionar produtos ao meu carrinho de compras, para que eu possa continuar comprando e finalizar minha compra depois.

Critérios de Aceitação:

• Dado que estou visualizando um produto
• Quando clico no botão "Adicionar ao Carrinho"
• Então o produto deve ser adicionado ao carrinho
• E devo ver uma confirmação visual
• E o contador do carrinho deve ser atualizado

Exemplo 2 — SIMPLES

Bug: "Campo de email aceita texto sem @, permitindo cadastros inválidos."

Como um usuário criando uma conta, eu quero que o sistema valide meu email corretamente, para que eu não insira um endereço inválido por engano.

Critérios de Aceitação:

• Dado que estou no formulário de cadastro
• Quando digito um email sem o caractere @
• Então devo ver uma mensagem de erro
• E não devo conseguir prosseguir com o cadastro
• E a mensagem deve explicar o formato correto

Exemplo 3 — SIMPLES

Bug: "Dashboard mostra contagem errada de usuários ativos. Mostra 50 mas só há 42 na lista."

Como um administrador visualizando o dashboard, eu quero ver a contagem correta de usuários ativos, para que eu possa tomar decisões baseadas em dados precisos.

Critérios de Aceitação:

• Dado que acesso o dashboard como admin
• Quando visualizo a métrica de usuários ativos
• Então o número exibido deve corresponder ao total real de usuários ativos
• E o valor deve ser atualizado em tempo real
• E deve incluir apenas usuários com status "ativo"

Exemplo 4 — SIMPLES

Bug: "Imagens de produtos não aparecem no Safari. No Chrome funciona normal."

Como um cliente usando Safari, eu quero visualizar as imagens dos produtos, para que eu possa avaliar os itens antes de comprar.

Critérios de Aceitação:

• Dado que estou navegando em um navegador Safari
• Quando acesso a página de um produto
• Então as imagens do produto devem carregar corretamente
• E devem ter a mesma qualidade que em outros navegadores
• E o tempo de carregamento deve ser similar

Exemplo 5 — MÉDIO

Bug: "Webhook de pagamento aprovado não está sendo chamado.

Steps to reproduce:

1. Fazer pedido de R$ 100
2. Pagar com cartão de crédito
3. Pagamento é aprovado no gateway
4. Sistema não recebe notificação
5. Status do pedido fica como 'pendente'

Logs do gateway mostram: HTTP 500 ao tentar POST /api/webhooks/payment"

Como o sistema de e-commerce, eu quero receber notificações de pagamento aprovado via webhook, para que o status dos pedidos seja atualizado automaticamente após confirmação do pagamento.

Critérios de Aceitação:

• Dado que um pagamento é aprovado no gateway
• Quando o gateway envia POST para /api/webhooks/payment
• Então o endpoint deve retornar HTTP 200
• E o status do pedido deve mudar de "pendente" para "aprovado"
• E o cliente deve receber email de confirmação
• E o sistema deve logar o evento para auditoria

Contexto Técnico:

• Endpoint está retornando HTTP 500
• Gateway: [nome do gateway de pagamento]
• Logs indicam falha no processamento do webhook

Exemplo 6 — MÉDIO

Bug: "Endpoint /api/users/:id retorna dados de qualquer usuário sem validar permissões.

Exemplo:

• Usuário comum (ID 100) consegue acessar GET /api/users/1 (admin)
• Recebe email, telefone, endereço do admin
• Apenas admins deveriam ver dados de outros usuários

Severidade: ALTA - vazamento de dados pessoais"

Como o sistema, eu quero validar permissões antes de retornar dados de usuários, para que apenas usuários autorizados possam acessar informações pessoais de outros usuários.

Critérios de Aceitação:

• Dado que sou um usuário comum
• Quando tento acessar GET /api/users/:id de outro usuário
• Então devo receber HTTP 403 Forbidden
• E apenas devo poder acessar meus próprios dados
• E administradores devem poder acessar dados de todos

Critérios Adicionais para Admins:

• Dado que sou um administrador
• Quando acesso GET /api/users/:id de qualquer usuário
• Então devo receber os dados completos com HTTP 200
• E o acesso deve ser registrado em log de auditoria

Contexto de Segurança:

• Severidade: ALTA
• Tipo: Quebra de controle de acesso (OWASP A01:2021)
• Dados expostos: email, telefone, endereço
• Ação: Implementar middleware de autorização

Gere a User Story para o bug a seguir.

Relato de Bug:

{bug_report}

User Story: