# beeuni.toml legado

Status de suporte e caminho de migração do beeuni.toml v1 para o beeuni.yaml v2.

Canonical page: https://beeuni.ai/docs/pt/project/legacy-toml

Esta página aborda o manifesto v1 (`beeuni.toml`, `beeuni_version: 1`). Para o manifesto atual, consulte [Referência do manifesto](/docs/pt/project/manifest).

<a id="support-status"></a>

## Status de suporte

O Beeuni ainda oferece suporte a manifestos v1. A plataforma resolve o manifesto de um projeto nesta ordem: `beeuni.yaml`, depois `beeuni.yml` e, por fim, `beeuni.toml`. O starter atual cria um `beeuni_version: 2` `beeuni.yaml`. Um projeto v1 continua funcionando sem atualização obrigatória.

A v1 aceita sintaxe TOML ou YAML. A versão 2 aceita apenas YAML. Um manifesto v2 escrito em TOML falha na validação.

<a id="migrate-to-v2"></a>

## Migrar para v2

Crie `beeuni.yaml` na raiz do repositório. Defina `beeuni_version: 2`.
Converta `[[agents]]` em um mapa `agents:`, com as chaves correspondentes aos nomes dos agentes.
Renomeie o campo `env` de cada agente para `secrets`. Liste todos os segredos de que o agente precisa — a v2 não concede acesso a segredos por padrão.
Adicione `default_agent`, indicando o agente que será executado por padrão.
Exclua `[[channels]]`. Reconecte cada canal pelo painel.
Se você usa `[sandbox]` ou `[[sandboxes]]`, mova cada definição de imagem para `sandbox.templates`.
Execute `beeuni validate` em `beeuni.yaml`. Corrija os erros informados.
Exclua `beeuni.toml`.

O comportamento do agente — prompt do sistema, `model`, `mode`, `temperature` e muito mais — nunca é movido. Ele já fica no frontmatter `.md` de cada agente, em `.beeuni/opencode/agents/`, tanto na v1 quanto na v2. Consulte [Agentes](/docs/pt/project/agents).

Confira o resultado com `beeuni validate --file beeuni.yaml`. Busque o esquema v2 completo com `beeuni schema --version 2`. Consulte a [Referência da CLI](/docs/pt/cli) para ver os dois comandos.

<a id="key-differences"></a>

## Principais diferenças

| v1 (`beeuni_version: 1`) | v2 (`beeuni_version: 2`) | Alteração |
|---|---|---|
| `[[agents]]` (array) | `agents:` (mapa indexado pelo nome) | Converta cada item do array em uma entrada do mapa. |
| `[[agents]].env` | `agents.<name>.secrets` | Renomeado. O padrão muda de `all` para `none` — veja o aviso abaixo. |
| `[[agents]].model` | removido | Sem efeito na v1 (analisado, mas nunca aplicado). O comportamento do agente sempre vem do frontmatter `.md` do agente. |
| `[[agents]].file` | `agents.<name>.file` | Sem efeito na v1 (analisado, mas nunca aplicado). Na v2, indica o `.md` do agente. |
| sem `default_agent` | `default_agent` (obrigatório) | Deve indicar um agente declarado e habilitado. |
| `[[channels]]` | removido | O roteamento de canais é gerenciado pelo painel. Um canal conectado aparece como uma entrada `connectors:` com `provider: channel`. |
| `[sandbox]` (singular, com as chaves de imagem diretamente nele) | `sandbox.templates` (lista) | Mova cada imagem para uma entrada de template. |
| `[[sandboxes]]` | `sandbox.templates` | Renomeado. |

> **Na v2, nenhum segredo é concedido por padrão**
>
> Na v1, um agente sem o campo `env` recebe todos os segredos do projeto por padrão. Na v2, um agente sem o campo `secrets` não recebe nenhum. Ao migrar, liste todos os segredos de que cada agente precisa — um agente que perde um segredo sem aviso pode falhar no meio de uma tarefa.

Algumas ações `beeuni_permissions` são toleradas por compatibilidade legada na v1 (`project.session.exec`, `project.gateway.routing.edit`, `project.schedule.read`, `project.schedule.write`, `project.webhook.read`, `project.webhook.write`, `channel.read`, `channel.connect`, `channel.send`, `channel.disconnect`) — a plataforma emite um aviso, mas permite seu uso. As mesmas ações geram um erro bloqueante na v2. Remova-as da concessão `beeuni_permissions` de qualquer agente antes de migrar.