# beeuni.toml heredado

Estado del soporte y ruta de migración de beeuni.toml v1 a beeuni.yaml v2.

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

Questa pagina tratta il manifest v1 (`beeuni.toml`, `beeuni_version: 1`). Per il manifest attuale, consulta [Riferimento del manifest](/docs/it/project/manifest).

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

## Stato del supporto

Beeuni supporta ancora i manifest v1. La piattaforma risolve il manifest di un progetto in questo ordine: `beeuni.yaml`, poi `beeuni.yml`, quindi `beeuni.toml`. Lo starter attuale crea un `beeuni_version: 2` `beeuni.yaml`. Un progetto v1 continua a funzionare senza aggiornamenti forzati.

v1 accetta la sintassi TOML o YAML. La versione 2 accetta solo YAML. Un manifest v2 scritto in TOML non supera la convalida.

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

## Migrazione a v2

Crea `beeuni.yaml` nella radice del repository. Imposta `beeuni_version: 2`.
Converti `[[agents]]` in una mappa `agents:`, indicizzata per nome dell'agente.
Rinomina il campo `env` di ogni agente in `secrets`. Elenca ogni secret di cui l'agente ha bisogno: v2 non concede secret per impostazione predefinita.
Aggiungi `default_agent`, specificando l'agente eseguito per impostazione predefinita.
Elimina `[[channels]]`. Ricollega ogni canale dalla dashboard.
Se usi `[sandbox]` o `[[sandboxes]]`, sposta ogni definizione di immagine sotto `sandbox.templates`.
Esegui `beeuni validate` su `beeuni.yaml`. Correggi eventuali errori segnalati.
Elimina `beeuni.toml`.

Il comportamento dell'agente — prompt di sistema, `model`, `mode`, `temperature` e altro — non cambia mai posizione. È già presente nel frontmatter `.md` di ogni agente, sia in v1 sia in v2, sotto `.beeuni/opencode/agents/`. Consulta [Agenti](/docs/it/project/agents).

Verifica il risultato con `beeuni validate --file beeuni.yaml`. Recupera lo schema v2 completo con `beeuni schema --version 2`. Consulta il [Riferimento della CLI](/docs/it/cli) per entrambi i comandi.

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

## Differenze principali

| v1 (`beeuni_version: 1`) | v2 (`beeuni_version: 2`) | Modifica |
|---|---|---|
| `[[agents]]` (array) | `agents:` (mappa indicizzata per nome) | Converti ogni elemento dell'array in una voce della mappa. |
| `[[agents]].env` | `agents.<name>.secrets` | Rinominato. Il valore predefinito passa da `all` a `none` — consulta il riquadro qui sotto. |
| `[[agents]].model` | rimosso | Inutilizzato in v1 (analizzato, ma mai applicato). Il comportamento dell'agente proviene sempre dal frontmatter `.md` dell'agente. |
| `[[agents]].file` | `agents.<name>.file` | Inutilizzato in v1 (analizzato, ma mai applicato). In v2 indica `.md` dell'agente. |
| nessun `default_agent` | `default_agent` (obbligatorio) | Deve indicare un agente dichiarato e abilitato. |
| `[[channels]]` | rimosso | Il routing dei canali è gestito dalla dashboard. Un canale connesso appare come voce `connectors:` con `provider: channel`. |
| `[sandbox]` (singolare, con le chiavi delle immagini direttamente al suo interno) | `sandbox.templates` (elenco) | Sposta ogni immagine in una voce del template. |
| `[[sandboxes]]` | `sandbox.templates` | Rinominato. |

> **I secret sono nessuno per impostazione predefinita in v2**
>
> In v1, un agente senza il campo `env` riceve per impostazione predefinita ogni secret del progetto. In v2, un agente senza il campo `secrets` non riceve alcun secret. Durante la migrazione, elenca ogni secret di cui ha bisogno ciascun agente: un agente che perde un secret senza avviso può fallire durante un'attività.

Alcune azioni `beeuni_permissions` sono tollerate per compatibilità legacy in 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`): la piattaforma mostra un avviso, ma le consente. Le stesse azioni generano un errore bloccante in v2. Rimuovile dalla concessione `beeuni_permissions` di qualsiasi agente prima della migrazione.