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

# Comandos do Bot

> Controle o ZeroPath a partir do seu pull request — faça triagem de descobertas, atribua tickets, gere patches e reescaneie, tudo mencionando o bot em um comentário

<h2 id="how-it-works">
  Como Funciona
</h2>

Mencione o bot do ZeroPath em um comentário de pull request ou merge request para enviar um comando. O bot interpreta o comentário, publica uma confirmação, executa a ação e então **atualiza o mesmo comentário no lugar** com o resultado. Isso mantém a conversa do seu PR limpa — há uma resposta do bot por comando, não uma cadeia de respostas.

<Steps>
  <Step title="Mencione o bot">
    Comece o seu comentário com `@ZeroPath` ou `@zeropath-ai` (aliases públicos), ou
    `@<your-bot-username>` (o nome de usuário exato configurado para o seu GitHub App ou
    integração do GitLab). Nomes de usuário de bot específicos de ambiente só correspondem àquela
    integração exata.
  </Step>

  <Step title="Digite um comando">
    Use um dos comandos estruturados abaixo, ou faça uma pergunta em linguagem natural. Alvos como `issue 2` são comparados com os problemas que o ZeroPath reportou neste PR.
  </Step>

  <Step title="Leia a resposta">
    O bot publica imediatamente um comentário "Thinking..." ou "Acknowledged" e então edita esse comentário no lugar quando a ação é concluída. Ações de longa duração como `retriage` transmitem um resumo estruturado de volta ao terminar.
  </Step>
</Steps>

<Info>
  Os comandos do bot são suportados no **GitHub** e no **GitLab**. O **Bitbucket** e o
  **Azure DevOps** suportam escaneamento de PRs, mas ainda não comandos do bot.
</Info>

<Note>
  Um `@ZeroPath` sozinho, sem comando, faz o bot responder com uma dica: `I'm here.
      Try: @ZeroPath fp issue 2 because …`
</Note>

<h2 id="command-reference">
  Referência de Comandos
</h2>

A maioria das categorias aceita a mesma **sintaxe de alvo** (consulte [Alvos](#targets)) e muitas aceitam um sufixo opcional **`because <reason>`** (consulte [O Modificador `because`](#the-because-modifier) para saber quais comandos persistem o motivo).

<h3 id="triage-status">
  Status de Triagem
</h3>

Marque o veredito de corretude de uma descoberta. Esses comandos alteram o estado de triagem do problema e disparam uma notificação `vulnerability status changed` pelos seus canais configurados.

| Comando                              | Aliases                                               | O Que Faz                                                                            |
| ------------------------------------ | ----------------------------------------------------- | ------------------------------------------------------------------------------------ |
| `@ZeroPath fp <target>`              | `false-positive`, `falsepositive`                     | Marca o(s) problema(s) como **false positive**                                       |
| `@ZeroPath true-positive <target>`   | `true positive`                                       | Marca o(s) problema(s) como **true positive** (confirmado como real)                 |
| `@ZeroPath accepted-risk <target>`   | `acceptedrisk`, `accept-risk`, `acceptrisk`           | Marca o(s) problema(s) como **accepted risk** — real, mas a equipe escolhe aceitá-lo |
| `@ZeroPath non-exploitable <target>` | `nonexploitable`, `not-exploitable`, `notexploitable` | Marca o(s) problema(s) como **non-exploitable** no contexto desta base de código     |

<h3 id="workflow-status">
  Status de Fluxo de Trabalho
</h3>

Mova uma descoberta pelo fluxo de revisão da sua equipe. Esses comandos não alteram o veredito de corretude — use o Status de Triagem para isso.

| Comando                                    | Aliases                                | Status Resultante  |
| ------------------------------------------ | -------------------------------------- | ------------------ |
| `@ZeroPath in-progress <target>`           | `inprogress`, `status reviewing`       | **Reviewing**      |
| `@ZeroPath patching <target>`              | `patch`, `status patching`             | **Patching**       |
| `@ZeroPath closed <target>`                | `close`, `resolved`, `status resolved` | **Resolved**       |
| `@ZeroPath backlog <target>`               | `defer`, `deferred`, `status backlog`  | **Backlog**        |
| `@ZeroPath status pending_review <target>` | —                                      | **Pending Review** |

<h3 id="assignment">
  Atribuição
</h3>

Atribua o ticket do Jira ou do Linear vinculado a uma descoberta a um colega de equipe. Requer que a descoberta tenha um issue associado no Jira/Linear (consulte [Jira](/pt/integrations/jira) ou [Linear](/pt/integrations/linear)).

| Comando                                  | O Que Faz                                                             |
| ---------------------------------------- | --------------------------------------------------------------------- |
| `@ZeroPath assign <target> to <email>`   | Atribui o ticket vinculado ao usuário com aquele e-mail               |
| `@ZeroPath assign <target> to @<handle>` | Atribui o ticket vinculado ao usuário com aquele handle da plataforma |

Se um alvo não tiver ticket vinculado no Jira/Linear, o bot reporta `assignment isn't possible (no linked Jira/Linear ticket)` para aquele problema e continua com os demais.

<h3 id="auto-fix-patches">
  Patches de Correção Automática
</h3>

Acione o pipeline de geração de patches do ZeroPath para uma descoberta específica. Consulte [Auto-Fix](/pt/scanning/auto-fix) para o recurso completo.

| Comando                             | Aliases                            | O Que Faz                                          |
| ----------------------------------- | ---------------------------------- | -------------------------------------------------- |
| `@ZeroPath generate patch <target>` | `create patch`                     | Gera uma branch de correção para a descoberta alvo |
| `@ZeroPath approve patch <target>`  | `open pr`, `create pr`, `issue pr` | Abre o patch como um pull request para revisão     |

<h3 id="github-patch-pr-changes">
  Alterações em PRs de Patch no GitHub
</h3>

No GitHub, quando o ZeroPath abre um PR de patch de correção automática, os revisores podem solicitar
mudanças de código adicionais diretamente da conversa do PR. Comece um novo comentário no PR
com `@ZeroPath` ou `@zeropath-ai` e descreva a mudança que você quer.

```text PR comment theme={null}
@zeropath-ai Please add a regression test for empty usernames
@zeropath-ai Please rename the new helper to `sanitizeDisplayName`
@zeropath-ai Please remove the temporary debug log added by this patch
```

Para essas solicitações, o ZeroPath:

1. Verifica que o PR é um PR de patch do GitHub criado pelo ZeroPath.
2. Verifica que a branch head atual do PR é a mesma branch de patch que o ZeroPath
   criou.
3. Aplica apenas a mudança solicitada.
4. Faz commit da mudança na branch existente do PR.
5. Responde com um resumo e a referência do commit.

<Info>
  Mudanças diretas na branch de PRs de patch são atualmente exclusivas do GitHub. Os comandos do bot no GitLab
  continuam suportando triagem, atribuição, geração de patches, reescaneamentos, retriagem e
  perguntas em linguagem natural, mas não commits de acompanhamento diretos em uma branch de
  PR de patch existente.
</Info>

<Warning>
  O ZeroPath se recusa a fazer push quando a branch do PR não pode ser verificada como uma
  branch de patch criada pelo ZeroPath, a branch se moveu enquanto o bot estava trabalhando,
  o PR vem de um fork, ou a solicitação é insegura, ambígua, impossível ou
  faria mudanças não relacionadas.
</Warning>

<h3 id="scan-operations">
  Operações de Escaneamento
</h3>

| Comando                  | Aliases                              | O Que Faz                                                                                                            |
| ------------------------ | ------------------------------------ | -------------------------------------------------------------------------------------------------------------------- |
| `@ZeroPath rescan`       | `re-scan`, `rescan pr`, `scan again` | Executa novamente o escaneamento do PR. Se um escaneamento para o commit atual já existe, ele é pulado.              |
| `@ZeroPath rescan force` | `force rescan`, `force re-scan`      | Força um reescaneamento mesmo que exista um escaneamento para o commit atual, ignorando a verificação de duplicidade |

Quando o bot não consegue executar um reescaneamento, ele explica o motivo com uma destas mensagens: `A scan for the current commit already exists. Use \`rescan force\` to bypass the cache.`, `Cannot rescan a closed pull request.\`, ou um motivo específico do serviço.

<h3 id="re-triage-deeper-investigation">
  Re-Triagem (Investigação Mais Profunda)
</h3>

Execute novamente a validação por IA nas descobertas usando uma investigação mais minuciosa do que a do escaneamento de PR padrão. Quando a descrição do PR referencia vulnerabilidades por tag `ZP-ID` ou URL do dashboard (consulte [Verificação de Correção](/pt/scanning/fix-verification)), `retriage` executa a **verificação de correção** em vez disso.

| Comando                                         | Aliases                                        | O Que Faz                                                                        |
| ----------------------------------------------- | ---------------------------------------------- | -------------------------------------------------------------------------------- |
| `@ZeroPath retriage`                            | `re-triage`, `reinvestigate`, `re-investigate` | Reinvestiga **todos** os problemas deste PR                                      |
| `@ZeroPath retriage <target>`                   | (mesmos aliases)                               | Reinvestiga um problema específico ou uma lista                                  |
| `@ZeroPath retriage <target> because <context>` | (mesmos aliases)                               | O mesmo, mas passa `<context>` à IA como informação adicional para a reavaliação |

A resposta do retriage, publicada no lugar do comentário de confirmação, lista cada problema com um veredito (**Confirmed** ou **Disconfirmed**), uma avaliação de segurança e um link para o problema no dashboard do ZeroPath.

<h3 id="natural-language-questions">
  Perguntas em Linguagem Natural
</h3>

Qualquer coisa que não corresponda a um comando estruturado ou a uma solicitação de mudança em
PR de patch do GitHub é tratada como uma pergunta ao bot. **No GitHub**, o bot responde com
uma resposta gerada por IA no mesmo fio de comentários, publicando um placeholder `Thinking...`
e editando-o no lugar com a resposta completa quando estiver pronta.

```text PR comment theme={null}
@ZeroPath Is this finding exploitable given our input validation?
@ZeroPath Can you explain what this vulnerability means for our auth flow?
@ZeroPath What's the risk of merging with these open issues?
```

<Note>
  Mensagens em formato de pergunta (aquelas classificadas como perguntas pelo LLM) recebem uma
  resposta de IA em formato livre **tanto** no GitHub quanto no GitLab. As plataformas divergem apenas
  quando o classificador não consegue reconhecer a mensagem de forma alguma: o **GitLab** retorna uma
  resposta estática listando os exemplos de comandos suportados (`I couldn't understand
      that command. Examples: ...`), enquanto o **GitHub** recorre a uma resposta de Assistant em
  formato livre. Se você está no GitLab e o bot responde com a lista estática de
  comandos, reformule como uma pergunta clara ou use um dos comandos estruturados acima.
</Note>

<Warning>
  Comentários que parecem tentativas de prompt injection são bloqueados automaticamente.
  Se você receber uma mensagem de rejeição, reformule a pergunta como uma consulta direta
  sobre uma descoberta específica reportada.
</Warning>

<h2 id="targets">
  Alvos
</h2>

Um **alvo** especifica a qual(is) problema(s) o comando se aplica. O parser aceita:

| Forma                       | Exemplo                                  | Resolve Para                                                         |
| --------------------------- | ---------------------------------------- | -------------------------------------------------------------------- |
| Número de um único problema | `issue 2`                                | Problema #2 reportado neste PR                                       |
| Números de vários problemas | `issues 1, 2, 3`                         | Problemas #1, #2, #3                                                 |
| Todos os problemas deste PR | `all issues in this pr`                  | Todos os problemas que o ZeroPath reportou neste PR                  |
| URL do dashboard            | `https://zeropath.com/app/issues/<uuid>` | O problema naquela URL                                               |
| UUID do problema, sozinho   | `f47ac10b-58cc-4372-a567-0e02b2c3d479`   | O problema com aquele UUID                                           |
| Implícito (resposta inline) | *nenhum alvo informado*                  | O problema ligado ao fio de revisão inline sob o qual você respondeu |

A forma implícita é o caminho mais fácil: abra um comentário inline de descoberta, responda a ele com `@ZeroPath fp because not reachable from input`, e o bot aplica o comando àquela descoberta sem que você precise nomear um número de problema. Cada comentário inline de descoberta inclui um rodapé de dicas rápidas com exemplos de comandos de resposta, para que você veja a sintaxe sem sair do seu PR.

Um `retriage` sozinho, sem alvo, assume por padrão **todos os problemas deste PR**.

<Warning>
  Use vírgulas, não a palavra `and`, para separar vários números de problemas. O parser
  só reconhece listas separadas por vírgula — `issues 1 and 4` silenciosamente atinge apenas o
  problema #1, descartando `and 4`. Sempre escreva `issues 1, 4`.
</Warning>

<h2 id="the-because-modifier">
  O Modificador `because`
</h2>

Todo comando de triagem, de status de fluxo de trabalho e de retriagem aceita um sufixo opcional `because <reason>`. O texto após `because` é capturado pelo parser como o motivo do usuário para a ação.

```text PR comment theme={null}
@ZeroPath fp issue 2 because the user input here is already validated upstream
@ZeroPath accepted-risk issues 1, 4 because we'll address these in Q3
@ZeroPath retriage issue 3 because we added a content-type check on the endpoint
```

Como o motivo é usado depende do comando:

| Comando                                                                                                                     | O que acontece com `because <reason>`                                                                                                                                                                                               |
| --------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `fp`, `true-positive`, `accepted-risk`, `non-exploitable`                                                                   | Persistido no problema e incluído na notificação `vulnerability status changed`                                                                                                                                                     |
| Status de fluxo de trabalho (`in-progress`, `patching`, `closed`, `backlog`, `status …`)                                    | Persistido no problema e incluído na notificação `vulnerability status changed`                                                                                                                                                     |
| `retriage`                                                                                                                  | Passado à investigação de IA como contexto adicional                                                                                                                                                                                |
| `assign`                                                                                                                    | Interpretado, mas **atualmente não persistido** — incluído apenas por consistência de sintaxe de comando. Use um comentário no Jira/Linear se você precisar de uma trilha de auditoria do porquê de um ticket ter sido reatribuído. |
| `rescan`, `generate patch`, `approve patch`, pergunta em linguagem natural, solicitação de mudança em PR de patch do GitHub | Não aceito (nenhuma cláusula `because` é interpretada)                                                                                                                                                                              |

<h2 id="worked-examples">
  Exemplos Práticos
</h2>

<CodeGroup>
  ```text Triage one finding theme={null}
  @ZeroPath fp issue 2 because input is sanitized in middleware.ts
  ```

  ```text Bulk-resolve all issues theme={null}
  @ZeroPath resolved all issues in this pr because addressed in commit abc123
  ```

  ```text Assign to a teammate via Linear theme={null}
  @ZeroPath assign issue 3 to @alice
  ```

  ```text Generate then open a patch PR theme={null}
  @ZeroPath generate patch issue 2
  @ZeroPath approve patch issue 2
  ```

  ```text Request a follow-up change on a GitHub patch PR theme={null}
  @zeropath-ai Please add a regression test for empty usernames
  ```

  ```text Rescan after a config change theme={null}
  @ZeroPath rescan force
  ```

  ```text Retriage everything with extra context theme={null}
  @ZeroPath retriage because we updated the auth library to 4.2.0
  ```

  ```text Reply implicitly under an inline comment theme={null}
  @ZeroPath non-exploitable because this code path is dev-only
  ```
</CodeGroup>

<h2 id="permissions">
  Permissões
</h2>

Quando o controle de acesso está habilitado para a sua organização, o bot verifica que o usuário do GitHub ou do GitLab que publicou o comentário está vinculado a uma identidade do ZeroPath, e que o usuário vinculado tem a permissão de repositório adequada para a ação. As permissões abaixo usam os **nomes de exibição exatos da página de configurações de Teams**, para que um admin possa encontrar cada uma como uma checkbox na UI de permissões de equipe.

| Comando                                                                                  | Permissão Necessária       |
| ---------------------------------------------------------------------------------------- | -------------------------- |
| `fp` (falso positivo)                                                                    | **Mark as False Positive** |
| `true-positive`, `non-exploitable`                                                       | **Mark as True Positive**  |
| `accepted-risk`                                                                          | **Archive Issues**         |
| Status de fluxo de trabalho (`in-progress`, `patching`, `closed`, `backlog`, `status …`) | **Mark Issues as Open**    |
| `assign`                                                                                 | **Mark Issues as Open**    |
| `rescan`, `rescan force`                                                                 | **Mark Issues as Open**    |
| `retriage`                                                                               | **Mark Issues as Open**    |
| Pergunta em linguagem natural                                                            | **Mark Issues as Open**    |
| `generate patch`                                                                         | **Generate Patches**       |
| `approve patch`                                                                          | **Create Pull Requests**   |
| Solicitação de mudança em PR de patch do GitHub                                          | **Create Pull Requests**   |

<Note>
  Essas são permissões distintas. Um usuário com **Mark as False Positive** mas sem
  **Archive Issues** pode executar `fp`, mas terá `accepted-risk` negado, ainda que
  ambas sejam ações de "triagem" no uso casual. Da mesma forma, `non-exploitable`
  é controlado por **Mark as True Positive**, não por False Positive — ambos os comandos
  afirmam uma classificação de vulnerabilidade, então compartilham a permissão de
  True Positive.
</Note>

Se um usuário não tiver a permissão necessária, o bot responde com
`Permission denied (missing <PERMISSION_CONSTANT>).` Por exemplo,
`ISSUE_EDIT_OPEN` corresponde a **Mark Issues as Open**, `PATCH_CREATE` corresponde a
**Generate Patches** e `PATCH_ISSUE` corresponde a **Create Pull Requests**.

Se o autor do comentário não tiver uma identidade do ZeroPath vinculada no GitHub, o bot responde:

> I can't verify your ZeroPath identity for this organization. Your GitHub account isn't linked to a ZeroPath user yet.
>
> To link it, set your GitHub public email (Settings > Public profile) to match your ZeroPath account email, then comment again. The link is saved on our side, so you can switch the email back to private afterward. This should fix the issue most of the time.

No GitLab, o bot responde:

> I can't verify your ZeroPath identity for this organization (no linked ZeroPath user). Please contact your org admin to link your account.

Consulte [Equipes e Permissões](/pt/platform/teams) para saber como vincular usuários do VCS e configurar RBAC.

<h2 id="platform-support">
  Suporte de Plataformas
</h2>

| Plataforma                             | Comandos do Bot                                    |
| -------------------------------------- | -------------------------------------------------- |
| **GitHub** (Cloud e Enterprise Server) | Sim — suporte completo                             |
| **GitLab** (Cloud e Self-hosted)       | Sim — suporte completo                             |
| **Bitbucket** (Cloud e Data Center)    | Escaneamento de PRs sim, comandos do bot ainda não |
| **Azure DevOps**                       | Escaneamento de PRs sim, comandos do bot ainda não |

<h2 id="troubleshooting">
  Solução de Problemas
</h2>

**O bot responde "I couldn't understand that command."**
O parser não reconheceu nem uma palavra-chave explícita nem uma pergunta. Use um dos [exemplos práticos](#worked-examples) como modelo, ou cole uma URL do dashboard como alvo.

**O bot responde "No matching issues found for that target."**
O número de problema que você usou não corresponde a uma descoberta que o ZeroPath reportou neste PR. Verifique o comentário de resumo do PR para ver a lista de problemas reportados, ou use `all issues in this pr`.

**O bot responde "I can't verify your ZeroPath identity..."**
A sua conta no VCS não está vinculada a um usuário do ZeroPath. No GitHub, a correção mais rápida é definir o seu e-mail público do GitHub (Settings > Public profile) para corresponder ao e-mail da sua conta do ZeroPath e então comentar novamente — o ZeroPath vinculará automaticamente as contas via correlação de e-mail. Você pode voltar o e-mail para privado depois; o vínculo persiste. No GitLab, o fallback de correlação de e-mail ainda não está implementado, então entre em contato com o admin da sua organização para vincular as contas em Teams, ou execute a ação a partir do dashboard do ZeroPath.

**`assign` reporta "no linked Jira/Linear ticket"**
A descoberta alvo ainda não foi enviada ao Jira ou ao Linear. Configure a integração do [Jira](/pt/integrations/jira) ou do [Linear](/pt/integrations/linear) com auto-ticketing, ou crie o ticket a partir do dashboard primeiro.

**O bot rejeitou meu comentário como conteúdo de prompt injection**
Reformule como uma pergunta direta sobre uma descoberta específica reportada, sem instruções formatadas como comandos de bot embutidas nela.

**O bot se recusou a modificar um PR de patch do GitHub**
O bot só faz commits diretamente em branches de PR que o ZeroPath criou para PRs de
patch. Ele se recusa quando não consegue verificar a branch, o PR vem de um fork, a
branch se moveu enquanto a solicitação estava sendo preparada, ou a mudança solicitada é
insegura, ambígua, impossível, não relacionada ao patch ou não produz mudanças em
arquivos.

<Info>
  Consulte [Escaneamento de PRs](/pt/scanning/pr-scanning) para o recurso ao redor (status de
  verificação, comentários inline, comentários de resumo) e
  [Auto-Fix](/pt/scanning/auto-fix) para o que `generate patch` e `approve patch`
  realmente produzem.
</Info>