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

# Quickstart

> Configure o primeiro workspace, conecte um repositório e rode o primeiro review na Acrity.

Este guia mostra o caminho mínimo para começar a usar a Acrity em um workspace.

## Antes de começar

Você precisa de:

* Acesso ao Console da Acrity.
* Um usuário com permissão de Admin de workspace no workspace.
* Permissão para instalar ou autorizar o provedor de código usado pelo time.
* Pelo menos um repositório com pull requests ou merge requests ativos.
* Opcionalmente, acesso administrativo a uma ferramenta de gestão de trabalho como Jira, Linear ou ClickUp.

## Fluxo recomendado

```mermaid theme={null}
flowchart TD
  A[Select workspace] --> B[Connect provider]
  B --> C[Connect repositories]
  C --> D[Bootstrap ARCHITECTURE.md]
  D --> E[Adjust review policy]
  E --> F[Validate first PR/MR]
```

<Note>
  Aplicativos conectados, Credenciais, Conectores, Repositórios e Policy Engine exigem um Admin de workspace.
</Note>

<Steps>
  <Step title="Selecione seu workspace">
    Entre no Console e escolha o workspace no seletor superior.
  </Step>

  <Step title="Revise idioma e membros">
    No seletor de workspace e nas configurações do workspace, confirme o idioma padrão, os Admins de workspace e os usuários que precisam acompanhar reviews.
  </Step>

  <Step title="Conecte o provedor de código">
    Vá para `Console > Aplicativos conectados` quando puder usar OAuth ou um GitHub App. Use `Console > Credenciais` para credenciais manuais. Use `Console > Conectores` quando o VCS for privado, self-hosted ou estiver em uma rede restrita.
  </Step>

  <Step title="Conecte repositórios">
    Em `Console > Repositórios`, selecione `Conectar repositório`, escolha a origem de autenticação e confirme os repositórios que devem receber reviews.
  </Step>

  <Step title="Faça o bootstrap do ARCHITECTURE.md">
    Abra o repositório em `Console > Repositórios > Detalhe do repositório` e inicie o bootstrap do ARCHITECTURE.md. Isso dá aos reviews o contexto de projeto do qual eles dependem. Um repositório não fica pronto para reviews até ter um ARCHITECTURE.md com bootstrap concluído, então conclua esta etapa para cada repositório que você conectar.
  </Step>

  <Step title="Ajuste a política de review">
    Use `Console > Policy Engine` para regras do workspace e, quando necessário, ajuste configurações específicas em `Console > Repositórios > Detalhe do repositório`.
  </Step>

  <Step title="Valide o primeiro PR ou MR">
    Abra ou atualize um PR/MR no provedor de código e acompanhe o review no [dashboard Ops](/pt-BR/guides/ops-dashboard) — onde os reviews aparecem — e na saída do provedor. Use `Console > Audit Trail` apenas para detalhes técnicos de eventos e diagnóstico.
  </Step>
</Steps>

## Decisão rápida: qual tipo de conexão usar?

| Cenário                                                            | Use                    |
| ------------------------------------------------------------------ | ---------------------- |
| GitHub Cloud com instalação administrada                           | GitHub App conectado   |
| GitLab, Bitbucket, Azure DevOps, Jira, Linear ou ClickUp via OAuth | Aplicativos conectados |
| Token pessoal, token de projeto ou credencial técnica              | Credenciais            |
| VCS privado, VCS self-hosted ou sem acesso de entrada para a nuvem | Conectores             |

<Tip>
  Prefira Aplicativos conectados quando o provedor os suportar. Eles simplificam autorização, reautorização e descoberta de repositórios.
</Tip>

## Checklist de pronto para produção

* O workspace tem pelo menos dois Admins de workspace.
* Os repositórios importantes aparecem como prontos em `Console > Repositórios`, cada um com um ARCHITECTURE.md com bootstrap concluído.
* Os idiomas do workspace e dos repositórios estão corretos.
* A política de autores bloqueia contas que não devem gerar custo ou atividade de review.
* As API keys têm escopo mínimo, expiração e allowlist de IP quando aplicável.
* Os webhooks de saída usam HMAC quando o destino suporta verificação.
* Os Admins de workspace revisaram as páginas de segurança antes de configurar credenciais de produção.