> For the complete documentation index, see [llms.txt](https://docs.ipcheck.ing/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.ipcheck.ing/developer/pt-br/contributing/reporting-issues.md).

# Relato de Problemas

Como abrir relatórios de bugs e solicitações de recursos úteis.

Todos os bugs e solicitações de recursos vão para [GitHub Issues](https://github.com/jason5ng32/MyIP/issues). O repositório vem com dois modelos — um relatório de bug e uma solicitação de recurso — e escolher o correto economiza uma ida e volta para todo mundo.

## Antes de abrir

{% hint style="info" %}
A maioria dos relatos sobre implantações auto-hospedadas acaba sendo problema de configuração, não bugs. Verifique estes primeiro.
{% endhint %}

1. **Pesquise issues existentes**, abertas e fechadas. Seu problema talvez já tenha sido relatado, respondido ou corrigido em `dev`.
2. **Leia o** [**FAQ**](/developer/pt-br/reference/faq.md)**.** Ela cobre os problemas comuns de implantação e configuração.
3. **Confirme sua configuração.** MaxMind é obrigatório — veja [Configuração da MaxMind](/developer/pt-br/getting-started/maxmind-setup.md). Vários recursos dependem de chaves de API opcionais; veja [Chaves de API opcionais](/developer/pt-br/configuration/optional-api-keys.md).
4. **Tente a versão mais recente.** O bug talvez já tenha desaparecido.

## Abrindo um relatório de bug

Use o **Relatório de bug** modelo. Ele é rotulado `bug` automaticamente. O modelo pede o seguinte.

### Ambiente

* Sistema operacional
* Navegador, se aplicável
* Versão do Node
* Versão do Vite
* Versão do Vue 3
* Versão do Docker, se aplicável
* Método de implantação — Vercel, Docker ou Node
* Variáveis de ambiente, **com todos os segredos removidos**
* Quaisquer outras versões de software relevantes

{% hint style="danger" %}
Nunca cole chaves de API, tokens ou credenciais do MaxMind em uma issue. Censure-os. Se você já tiver vazado um, revogue-o.
{% endhint %}

### Descrição e passos para reproduzir

Uma descrição clara do bug, seguida de passos numerados que o reproduzam. Os passos de reprodução são a parte individualmente mais útil de um relatório.

### Comportamento esperado vs. real

O que você esperava que acontecesse e o que realmente aconteceu. Capturas de tela ou uma gravação curta da tela ajudam em qualquer coisa visual.

### Logs do terminal e do console

O modelo destaca isso como importante, e é. Inclua ambos quando se aplicarem:

* **Logs do terminal** do backend — mensagens de erro e rastreamentos de pilha.
* **Logs do console do navegador** para qualquer coisa que falhe no frontend.

<details>

<summary>Obtendo mais detalhes do backend</summary>

O backend registra por meio de um `pino` logger compartilhado. Aumente o nível para capturar mais antes de reproduzir:

```bash
LOG_LEVEL=debug pnpm dev
```

Veja [Logs](/developer/pt-br/configuration/logging.md) para os outros ajustes, incluindo `LOG_FORMAT` e `LOG_HTTP`.

</details>

### Extras opcionais

* **Contexto adicional** — links para issues relacionadas, qualquer outra coisa relevante.
* **Possível solução** — se você já tiver uma ideia da correção, descreva-a. Se quiser implementá-la, diga isso e leia [Como Contribuir](/developer/pt-br/contributing/how-to-contribute.md) primeiro.

## Abrindo uma solicitação de recurso

Use o **Solicitação de recurso** modelo. Ele é rotulado `melhoria` automaticamente, e ela pede quatro coisas:

| Campo                                     | O que escrever                                               |
| ----------------------------------------- | ------------------------------------------------------------ |
| Está relacionado a um problema?           | A frustração por trás da solicitação, de forma concreta      |
| Descreva a solução que você gostaria      | O que deveria acontecer, do ponto de vista do usuário        |
| Descreva alternativas que você considerou | Outras abordagens, e por que elas são insuficientes          |
| Contexto adicional                        | Capturas de tela, mockups, links para referências anteriores |

Explique o benefício para o usuário, e não apenas a implementação. Uma solicitação que parte de um problema real é muito mais fácil de avaliar do que uma que parte de uma API proposta.

{% hint style="info" %}
Planeja criar o recurso você mesmo? Abra a issue mesmo assim e aguarde um mantenedor confirmar a direção antes de escrever código. Veja [Como Contribuir](/developer/pt-br/contributing/how-to-contribute.md).
{% endhint %}

## Problemas de segurança são diferentes

Não abra um relatório de bug normal para uma vulnerabilidade. Siga a [Política de Segurança](/developer/pt-br/contributing/security-policy.md) em vez disso.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.ipcheck.ing/developer/pt-br/contributing/reporting-issues.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.