):
a. initialize
b. maintenance
5. Health check, then snapshot is saved
```
As camadas são **aditivas**: comandos específicos do repo podem usar ferramentas instaladas pela org ou pelo blueprint da Enterprise. Níveis inferiores não podem sobrescrever o que um nível superior configurou. Builds normalmente levam de 5 a 15 minutos. Etapas individuais têm tempo limite de 1 hora.
### Como as sessões funcionam
Cada sessão inicia uma **cópia nova** do snapshot. Quando a sessão termina, todas as alterações são descartadas. No início da sessão:
1. O código mais recente é obtido do(s) repo(s) relevante(s).
2. Os comandos de `maintenance` (Enterprise, org e repo) são apresentados ao agente como contexto — **não são executados automaticamente**. O agente pode executá-los novamente se detectar que as dependências mudaram desde o último build.
3. As entradas de `knowledge` desse repo são carregadas no contexto do Devin.
**Knowledge é por repositório.** Se você tiver 5 repositórios configurados, o Devin verá apenas as entradas de Knowledge daquele em que estiver trabalhando.
### O que aciona um build
| Gatilho | Descrição |
| ----------------------------------- | ------------------------------------------------------------ |
| Salvar um blueprint | Criar, atualizar ou excluir um blueprint |
| Adicionar ou remover um repositório | Qualquer alteração na lista de repositórios |
| Adicionar um segredo ao repositório | Novos segredos exigem um rebuild para ficarem disponíveis |
| Gatilho manual | Clicar em **Build snapshot** na UI |
| Atualização periódica | Automática, aproximadamente a cada 24 horas |
| Sugestão do Devin | O Devin propõe uma alteração no blueprint durante uma sessão |
Apenas um build é executado por vez. Novos gatilhos cancelam qualquer build na fila e iniciam outro do zero.
### Status de builds
| Status | Significado |
| ------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Success** | Todas as etapas foram concluídas. O snapshot está pronto. |
| **Partial** | Algumas etapas no nível do repositório falharam, mas o snapshot é utilizável. Os repositórios que tiveram sucesso funcionam normalmente; os repositórios que falharam precisam ter seus blueprints corrigidos. |
| **Failed** | Falha crítica (a configuração da org ou do Enterprise falhou). O snapshot não é utilizável. |
| **Cancelled** | Foi substituído por um build mais recente ou cancelado manualmente. |
Um build **partial** ainda produz um snapshot funcional. Se um de cinco repositórios tiver um blueprint com problema, os outros quatro estarão totalmente funcionais.
**Build falhando?** Consulte [Solução de problemas de builds](#troubleshooting-builds) para um guia de depuração passo a passo.
## Gerenciando seu ambiente
### Estados dos repositórios
Os repositórios aparecem em três estados nas Configurações do ambiente:
| State | Meaning |
| -------------- | ---------------------------------------------------------------------------------------------------------- |
| **Configured** | Tem um blueprint com instruções de inicialização/manutenção/Knowledge. Totalmente configurado no snapshot. |
| **Included** | Clonado no snapshot, mas sem blueprint personalizado. Devin pode acessar o código. |
| **Available** | Conectado à org, mas não adicionado ao ambiente. Não clonado. |
**Included vs. configured:** Um repo "included" é clonado para que Devin possa acessar o código, mas não tem comandos de configuração personalizados. Um repo "configured" tem instruções explícitas de inicialização/manutenção/Knowledge.
### Segredos
Referencie os segredos com a sintaxe `$VARIABLE_NAME`. Adicione-os na aba **Segredos** no editor de blueprint.
```yaml theme={null}
maintenance:
- name: Configure private registry
run: npm config set //registry.npmjs.org/:_authToken $NPM_TOKEN
```
Os segredos estão disponíveis como variáveis de ambiente durante builds e sessões. Eles são removidos antes de o snapshot ser salvo, mas, se um comando gravar um valor secreto em um arquivo de configuração durante `initialize`, esse valor persistirá no snapshot. Coloque as etapas que gravam credenciais em `maintenance` para que sejam atualizadas durante builds periódicos.
Para ver detalhes sobre os escopos e o comportamento dos segredos, consulte a [Referência de blueprints](/pt-BR/onboard-devin/environment/blueprint-reference#environment-variables-and-secrets).
### Vários repositórios
Cada repo recebe seu próprio blueprint. Durante um build, todos os repositórios são configurados no mesmo snapshot, clonados em diretórios separados, com as dependências instaladas de forma independente.
Se dois repositórios instalarem versões diferentes de uma ferramenta global ou modificarem arquivos compartilhados (como `~/.bashrc`), o que for executado por último prevalece. Coloque as instalações de ferramentas compartilhadas no blueprint de nível da organização para evitar conflitos.
### GitHub Actions
Em vez de escrever scripts de shell para instalar ferramentas e runtimes, você pode referenciar GitHub Actions diretamente no blueprint. Devin baixa e executa a GitHub Action durante a build, da mesma forma que os runners de CI do GitHub executam as etapas da action.
```yaml theme={null}
initialize:
- name: Install Python 3.12
uses: github.com/actions/setup-python@v5
with:
python-version: "3.12"
```
Isso é especialmente útil para ações de configuração de linguagens, como `setup-python`, `setup-node` e `setup-go`, que fazem automaticamente o gerenciamento de versões e a configuração do PATH.
Para detalhes de sintaxe, exemplos e limitações, consulte [GitHub Actions em blueprints](/pt-BR/onboard-devin/environment/github-actions).
### Monorepos
Você pode executar comandos em subdiretórios usando subshells ou criar blueprints dedicados com escopo de workspace para packages individuais. Devin também oferece suporte a entradas no Knowledge por package, para que cada workspace tenha seus próprios comandos de lint, test e build.
Consulte [Workspaces e monorepos](/pt-BR/onboard-devin/environment/workspaces) para obter instruções de configuração e exemplos.
### Fixação e atualizações automáticas
Por padrão, o Devin usa o snapshot do build bem-sucedido mais recente. **Fixar** permite bloquear o uso de um snapshot de um build específico. Isso é útil quando um novo build introduz uma regressão ou quando você quer congelar o ambiente para um lote de sessões.
**Para fixar:** Acesse **Configurações > Ambiente > Snapshots**, encontre o build no histórico (deve ser `success` ou `partial`, com menos de 7 dias) e clique em **Pin**. Enquanto estiver fixado, as atualizações periódicas são puladas e a interface mostra **Auto-updates paused**.
**Para remover a fixação:** Clique em **Resume auto-updates**. O Devin muda para o build bem-sucedido mais recente.
### Blueprints versionados no Git
Você pode armazenar blueprints como arquivos `.devin/blueprint.yaml` diretamente no seu repositório. Após fazer merge das alterações, chame a API de sincronização (ou clique em Sync na UI) para atualizar o blueprint e, em seguida, acionar um build. Isso oferece o mesmo workflow de revisão de código que você usa para o código da aplicação, com a sincronização automatizada por meio de uma etapa de CI.
Consulte [Git-backed blueprints](/pt-BR/onboard-devin/environment/git-backed-blueprints) para obter instruções de configuração e mais detalhes.
## Solução de problemas em builds
### A etapa de inicialização falhou
**Causas comuns:** erro de digitação em um comando de shell, pacote indisponível, tempo limite de rede, referência incorreta a uma GitHub Action.
**Correção:** Verifique os logs de build para identificar o erro exato. Atualize `initialize` no seu blueprint e salve. Uma nova build é acionada automaticamente.
### Falha ao clonar o repo
**Causas comuns:** Devin não tem acesso ao repo, o repo foi renomeado/movido/excluído, problema temporário de rede.
**Correção:** Verifique o acesso ao repo nas configurações do seu provedor Git. Remova e adicione o repo novamente se ele tiver sido renomeado.
### Falha na etapa de manutenção
**Causas comuns:** conflito de dependências, biblioteca de sistema ausente, falta de espaço em disco, lock file fora de sincronização.
**Correção:** Verifique os logs do pacote/comando que falhou. Atualize `maintenance` ou `initialize` para instalar as dependências ausentes ou corrija o lock file no seu repositório.
### Tempo limite de build
Cada etapa tem um limite de tempo de 1 hora. Causas comuns: compilar grandes dependências nativas a partir do código-fonte (use binários pré-compilados), baixar artefatos grandes, comandos que ficam bloqueados aguardando entrada (todos os comandos devem ser executados sem interação).
### Refinando as correções
1. Verifique os logs da build para identificar a falha
2. Atualize o blueprint relevante
3. Salve (uma nova build é acionada automaticamente)
4. Monitore os logs da nova build
5. Repita até que a build seja concluída com sucesso
Você não precisa esperar uma build com falha terminar. Salvar uma nova configuração cancela qualquer build na fila e inicia uma nova do zero.
## Próximas etapas
Acelere os builds reconstruindo apenas os workspaces cujos blueprints foram alterados.
Use GitHub Actions para instalar linguagens, ferramentas e SDKs sem escrever scripts de shell.
Subshells, escopos de workspace e entradas de Knowledge para repositórios com vários pacotes.
Referência completa dos campos: tipos de etapa, variáveis de ambiente, segredos e anexos de arquivo.
Blueprints prontos para copiar e colar para Python, Node.js, Go, Java, Ruby, Rust e padrões avançados.
Armazene blueprints no seu repo como `.devin/blueprint.yaml` e sincronize pela API ou pela UI.
Guia passo a passo para migrar do assistente interativo para blueprints declarativos.
Gerenciamento de ambiente em toda a Enterprise: hierarquia de 3 níveis, segredos e configuração entre organizações.