Référence du manifeste

Toutes les clés de beeuni.yaml v2, avec leurs valeurs par défaut, leurs limites et leurs règles de validation.

Le manifeste est le fichier que la plateforme considère comme faisant autorité pour un projet. Cette page répertorie chaque clé beeuni.yaml (v2), son type, sa valeur par défaut et la façon dont la plateforme la valide. Pour une version en langage courant, consultez Votre projet.

Deux surfaces de configuration

Un projet Beeuni comporte deux surfaces de configuration aux responsabilités strictement distinctes.

• Configuration Beeuni — beeuni.yaml à la racine du dépôt définit l’environnement du projet, les agents, les outils, les connecteurs et les déclencheurs. Les modèles de sandbox peuvent référencer un Dockerfile personnalisé.
• Configuration de l’agent — les fichiers d’agent, les compétences et les fichiers du harnais. Le harnais de l’agent la lit, dans la sandbox comme en local.

Les projets créés avant 2026-09 conservent leurs agents et compétences dans .beeuni/opencode/ et leur mémoire dans .beeuni/memory/. Beeuni lit les deux structures.

Le lien entre ces deux parties est le fichier .md de l’agent. Une clé du manifeste agents.<name> régit le fichier désigné par agents.<name>.file, ou agents/<name>.md si file est omis. Tous les champs comportementaux figurent uniquement dans le frontmatter et le corps de ce fichier .md, jamais dans beeuni.yaml :

• invite système
• model, mode
• temperature, top_p
• steps, permission

Le bloc agents: du manifeste définit uniquement la gouvernance : quels agents peuvent être lancés et à quoi chacun peut accéder. Le validateur l’impose. Il rejette tout bloc d’agent v2 contenant un champ comportemental et affiche une erreur indiquant le fichier .md de l’agent concerné.

Emplacement et versions

Tout dépôt dont la racine contient un manifeste valide est un projet Beeuni. beeuni.yaml (v2, YAML uniquement) est le format actuel pour les nouveaux projets, créés par le flux Web « Create project » et par beeuni init. beeuni.toml (v1) fonctionne toujours pour les projets existants, mais la plateforme n’y accepte aucune nouvelle fonctionnalité v2. Consultez TOML hérité pour le schéma v1 et les étapes de migration de v1 vers v2.

beeuni_version: 2 exige le format YAML : un fichier .toml qui déclare beeuni_version: 2 échoue à la validation. Tout manifeste déclarant une version supérieure à 2 est rejeté, afin que la plateforme n’interprète jamais silencieusement un champ futur de travers. Les clés de premier niveau inconnues sont ignorées ; vous pouvez donc y ajouter vos propres métadonnées.

validateManifest() est le contrôle unique utilisé par beeuni ship, la vérification de fusion des demandes de modification et beeuni validate. Les mêmes règles s’appliquent partout ; tout ce qui est fusionné dans main est donc structurellement valide. Le schéma est public et généré à partir du même paquet :

• beeuni.v2.schema.json
• beeuni.v1.schema.json
• beeuni.schema.json (effectue la sélection selon beeuni_version)

Pointez un beeuni.yaml vers le schéma v2 pour valider dans l’éditeur, ou récupérez-le depuis la CLI :

# yaml-language-server: $schema=https://beeuni.ai/schema/beeuni.v2.schema.json
beeuni_version: 2

beeuni schema --version 2

Exemple complet

beeuni_version: 2
default_agent: beeuni

project:
  name: my-project
  description: What this project is.

env:
  required: [DATABASE_URL]
  optional: [STRIPE_API_KEY, WEBHOOK_SLACK_SECRET]

sandbox:
  templates:
    - slug: ml
      name: ML Development
      dockerfile: Dockerfile.ml
      cpu: 4
      memory: 16

opencode:
  config_dir: harnesses/opencode

agents:
  beeuni:
    file: agents/beeuni.md
    connectors: all
    secrets: all
    beeuni_permissions: all
    skills: all

  release-bot:
    file: agents/release-bot.md
    sandbox: ml
    connectors: [github]
    beeuni_permissions: [project.gitops.push]
    secrets: [GITHUB_AGENT_TOKEN]

triggers:
  - slug: daily-digest
    type: cron
    agent: beeuni
    cron: '0 0 9 * * 1-5'
    timezone: America/Los_Angeles
    prompt: |
      Summarize yesterday's commits. Open a CR against main.

Clés de premier niveau

imports:

Répartissez un manifeste entre plusieurs fichiers YAML. Utilisez cette option lorsque beeuni.yaml dépasse une page : 30 déclencheurs avec des invites sur plusieurs lignes, un connecteur par équipe, un fichier par groupe d’agents.

# beeuni.yaml
beeuni_version: 2
default_agent: beeuni
imports:
  - triggers/                # a directory: every .yaml and .yml file below it
  - agents.yaml              # a single file
agents:
  beeuni:
    connectors: all

beeuni.yaml
agents.yaml
triggers/
  reports/
    weekly.yaml
    monthly.yaml
  dockets/
    freedom-forever.yaml

# triggers/reports/weekly.yaml
triggers:
  - slug: weekly-report
    name: Cross-Sector Weekly Report
    type: cron
    agent: galileo
    cron: "0 15 * * 0"
    prompt: |-
      Build the weekly report.

Le fichier racine et ses imports forment une configuration de projet. Un déclencheur dans un fichier peut désigner un agent déclaré dans un autre.

Règles

1. Un chemin est relatif à la racine du dépôt. .., les chemins absolus et les motifs glob sont refusés.
2. Un import de répertoire inclut tous les fichiers .yaml et .yml qu’il contient, quelle que soit leur profondeur, triés par chemin. Les autres fichiers sont ignorés.
3. Un fichier importé déclare triggers, connectors, agents, apps, tools et imports. Toutes les autres clés (beeuni_version, default_agent, runtime, project, env, opencode, sandbox, policy, policies) restent dans le fichier racine. Un fichier importé qui en définit une échoue à la validation.
4. Un fichier importé peut en importer d’autres. La limite est de 8 niveaux et de 200 fichiers. Une boucle constitue une erreur. Un fichier atteint plusieurs fois n’est fusionné qu’une seule fois.
5. Un nom, un fichier. Si un slug de déclencheur, un slug de connecteur, un nom d’agent, de app ou d’outil est déclaré dans deux fichiers, une erreur nommant les deux fichiers est signalée. Aucun remplacement n’est effectué silencieusement.
6. Les entrées sont fusionnées dans l’ordre : le fichier importateur d’abord, puis ses imports dans l’ordre indiqué.

Un import incorrect invalide l’ensemble du manifeste, tout comme une erreur de syntaxe YAML. beeuni validate, beeuni ship et la vérification de fusion de la demande de modification le signalent avant qu’il n’atteigne main :

imports: triggers "weekly-report" is declared in both triggers/a.yaml and triggers/b.yaml — one name, one file

Les modifications sont apportées au fichier qui déclare l’entrée. Lorsque le tableau de bord, l’API ou beeuni triggers enable|disable|rm modifie un déclencheur, un connecteur, un agent ou une app déclaré par un fichier importé, seul ce fichier est écrit. Le fichier racine n’est pas réécrit. Une nouvelle entrée est écrite dans le fichier racine. Déplacez-la manuellement dans un fichier importé si vous le souhaitez.

imports exige beeuni.yaml. Un manifeste beeuni.toml ignore cette clé.

tools:

Les outils attribués à une session, par nom. Une valeur peut prendre l’une de ces deux formes :

tools:
  web_search: beeuni:web_search
  image_search: beeuni:image_search
  scrape_webpage: beeuni:scrape_webpage
  memory: tools/memory.ts                # replaces the Beeuni memory tool
  lookup_order: tools/lookup_order.ts
  crm_note: integrations/crm/note.ts

harness standard et harness expérimental exécutent le même module. Le contrat du module, beeuni tools ls, beeuni tools eject et la migration depuis harnesses/opencode/tools/ sont décrits dans Outils.

Règle de sélection.

• Aucune clé tools, dans le fichier racine ou dans un fichier importé : les sessions disposent des cinq outils Beeuni. Tous les projets créés avant l’existence de cette liste les conservent.
• Une clé tools, même vide (tools: {} ou tools: avec toutes les lignes supprimées) : les sessions disposent uniquement des outils Beeuni qu’elle répertorie, sous la forme beeuni:<name> ou d’un chemin de module. Une clé tools dans un fichier importé est également prise en compte.

Supprimez une ligne beeuni:<name> pour retirer cet outil de tous les agents. Utilisez agents.<name>.tools pour limiter cela à un seul agent.

Erreurs.

• Un nom doit être en snake_case : ^[a-z][a-z0-9_]{0,63}$.

• Un nom d’outil du harnais (bash, read, write, edit, apply_patch, glob, grep, list, task, question, todowrite, webfetch, websearch, skill, lsp, invalid, execute, plan_exit, pty_*) constitue une erreur.

• Un chemin se termine par .ts, .js, .mts, .mjs, .cts ou .cjs. Il ne doit pas commencer par / ou -, ni contenir de segment . ou ...

• beeuni:<name> sous une autre clé constitue une erreur. Sous un nom d’outil Beeuni, par exemple web_search: beeuni:image_search :

  tools.web_search : doit être `beeuni:web_search` (l’outil Beeuni) ou un chemin relatif au dépôt vers un module .ts ou .js (par ex. `tools/web_search.ts`) qui le remplace.

• beeuni:<name> pour un nom qui n’est pas celui d’un outil Beeuni, par exemple web_serch: beeuni:web_serch :

  tools.web_serch : doit être un chemin relatif au dépôt vers un module .ts ou .js (par ex. `tools/web_serch.ts`). `beeuni:<name>` désigne un outil Beeuni sous son propre nom : `web_search: beeuni:web_search`, `image_search: beeuni:image_search`, `scrape_webpage: beeuni:scrape_webpage`, `memory: beeuni:memory`, `show: beeuni:show`.

• beeuni validate signale également un module déclaré qui n’existe pas. Une valeur beeuni: ne nécessite aucun fichier.

Avertissements. Un avertissement n’invalide jamais beeuni validate.

• Une clé tools qui ne répertorie aucun des cinq outils Beeuni :

  tools : les sessions de ce projet ne disposent d’aucun outil Beeuni (web_search, image_search, scrape_webpage, memory, show). Ajoutez `<name>: beeuni:<name>` pour en conserver un.

  Cela permet de détecter un projet qui ajoute son premier outil personnalisé et supprime les cinq outils par erreur.

• Le tools d’un agent qui nomme un outil Beeuni que le projet ne charge pas :

  agents.beeuni.tools : « show » est un outil Beeuni que ce projet ne charge pas : ajoutez `show: beeuni:show` sous la clé `tools` de premier niveau, ou supprimez-le ici.

project:

Métadonnées facultatives destinées aux personnes : name et description. La plateforme ne lit pas cette table — le nom affiché d’un projet provient de son propre enregistrement dans la base de données. Considérez-la comme de la documentation pour les personnes qui consultent le dépôt.

env:

Déclare les noms des variables d’environnement dont vos sessions ont besoin. Les valeurs se trouvent sur la page Variables d’environnement du tableau de bord, jamais directement dans le manifeste. La plateforme les déchiffre et les injecte en tant que variables d’environnement simples au démarrage de la session.

env:
  required: [DATABASE_URL]
  optional: [STRIPE_API_KEY]

Les noms des variables d’environnement doivent respecter ^[A-Z_][A-Z0-9_]*$. Secrets Manager limite les noms à 64 caractères : un nom plus long est analysé ici, mais ne peut jamais recevoir de valeur. Il en va de même pour les noms commençant par BEEUNI_. Limitez les noms à 64 caractères et évitez le préfixe BEEUNI_. Spécification complète : Secrets.

sandbox: et sandbox.templates

Une liste d’images de sandbox nommées et amorçables. Facultative — sans entrée, chaque session démarre avec l’image par défaut de la plateforme. Chaque modèle doit définir exactement l’un de ces éléments : dockerfile (relatif au dépôt) ou image (une référence Docker publique, épinglée à un tag ou à un digest).

sandbox:
  templates:
    - slug: ml
      name: ML Development
      dockerfile: Dockerfile.ml
      cpu: 4
      memory: 16
      disk: 50

Chaque valeur doit être un entier positif. Une valeur inférieure au minimum échoue à la validation et génère une erreur. Une valeur supérieure au maximum passe avec un avertissement, puis est ramenée à la limite à l’exécution. Les GPU ne sont pas pris en charge — déclarer gpu génère un avertissement, pas une erreur. Consultez Runtime pour savoir ce que la couche d’exécution ajoute à votre image.

sandbox.default

Définissez default sur sandbox pour faire d’un modèle le modèle par défaut de tout le projet. Toutes les sessions, tous les déclencheurs et tous les canaux le démarrent alors sans avoir à préciser de slug.

sandbox:
  default: dev
  templates:
    - slug: dev
      dockerfile: Dockerfile.dev

default doit désigner un modèle déclaré dans ce manifeste, ou la valeur réservée "default" pour l’image de la plateforme.

Un agent peut sélectionner son environnement avec agents.<name>.sandbox. La valeur doit désigner un modèle du manifeste ou du tableau de bord, ou "default".

agents:
  researcher:
    sandbox: ml

La résolution du modèle de session suit cet ordre :

1. sandbox_slug de session explicite.
2. sandbox de l’agent sélectionné.
3. sandbox.default du projet.
4. "default" de la plateforme.

Les déclencheurs cron, les déclencheurs webhook, les planifications et les canaux utilisent le modèle de l’agent sélectionné.

Une modification de spécification (cpu, memory, disk, container_runtime ou l’image elle-même) reconstruit l’instantané du projet. La nouvelle taille s’applique à la session suivante, pas à une session en cours.

opencode:

Emplacement du répertoire de configuration harness standard. Facultatif, avec une valeur par défaut.

opencode:
  config_dir: harnesses/opencode

Si config_dir n’est pas défini, Beeuni utilise le premier de harnesses/opencode et .beeuni/opencode qui contient un opencode.json ou un opencode.jsonc. Ce répertoire contient les fichiers lus uniquement par harness standard : opencode.jsonc, plugins/, tools/ et commands/. Les agents et les compétences se trouvent à la racine du dépôt, dans agents/ et skills/. opencode.jsonc reste le registre natif d’harness standard pour les plugins, les serveurs MCP, les fournisseurs et les autorisations — ne dupliquez pas ces paramètres dans le manifeste. Voir Agents.

harnesses:

Paramètres propres à chaque moteur. pi.config_dir pointe vers un répertoire de configuration natif de harness expérimental relatif au dépôt (par défaut : harnesses/pi, puis .beeuni/pi). Le répertoire est importé au démarrage de harness expérimental. pi.packages est distinct : il installe des paquets à partir de harnesses.pi.packages du manifeste, par agent. Il existe aujourd’hui une clé de paquet : pi.packages, les paquets harness expérimental chargés par chaque session harness expérimental de ce projet (runtime: pi ou l’indicateur pi_harness). Un paquet peut être n’importe quel élément de packages : extensions (outils, hooks, commandes), ainsi que les compétences et les prompts fournis avec un paquet.

runtime: pi
harnesses:
  pi:
    packages:
      - npm:pi-web-access@0.30.0            # pinned extension version
      - source: npm:pi-mcp-adapter@2.36.0
        extensions: ["extensions/*.ts"]     # load only these files of the package
        skills: []                          # load none of its skills
      - ./harnesses/pi/audit.ts             # an extension file in this repository

20 entrées maximum. Les sources Git sont refusées.

Par agent

Un agent peut ajouter ses propres paquets et en retirer de la liste de premier niveau, sous agents.<name>.harnesses :

harnesses:
  pi:
    packages: [npm:pi-web-access@0.30.0]            # every agent
agents:
  researcher:
    harnesses:
      pi:
        packages: [npm:@juicesharp/rpiv-todo@2.11.0] # researcher only
  reviewer:
    harnesses:
      pi:
        exclude: [pi-web-access]                     # reviewer loads no web tools

• Les paquets d’un agent correspondent à la liste de premier niveau, moins son exclude, plus son propre packages.
• Pour un agent, une entrée qui concerne un paquet également répertorié au premier niveau remplace l’entrée de premier niveau (autre version ou autres filtres).
• exclude répertorie les noms de paquets (pi-web-access, @scope/name) ou les chemins ./ tels qu’ils sont indiqués dans la liste de premier niveau. Il ne prend jamais de version.
• Chaque liste de paquets distincte est construite une seule fois. Les agents qui partagent la même liste partagent la même compilation.
• Les paquets dépendent de l’agent avec lequel une session démarre. Un sous-agent démarré par un autre agent à l’aide de l’outil task utilise uniquement les outils d’espace de travail standard (bash, read, write, edit, glob, grep), pas ses propres paquets ni ceux de son agent parent ; les hooks d’extension du parent s’appliquent toujours à ses appels. Démarrez une session avec cet agent pour utiliser ses paquets.

Comment les paquets sont mis à disposition d’une session :

1. La fusion de la demande de modification qui édite cette liste construit les paquets une seule fois, pour la plateforme du bac à sable, avec les scripts d’installation désactivés. Chaque extension est précompilée dans un fichier minifié. La compilation conserve les autres fichiers du paquet, sauf le code déjà inclus dans ce fichier, les déclarations de types, les source maps, ainsi que les fichiers README et CHANGELOG à la racine. Les projets qui ont la même liste partagent la compilation.
2. Une nouvelle session ou une session redémarrée télécharge la compilation pendant le clonage de son dépôt, puis charge directement chaque extension. Une session n’exécute jamais npm install et ne compile jamais de paquet.
3. Un paquet qui ne peut pas être précompilé (par exemple, si son pi.extensions utilise des globs) fonctionne quand même : la session le charge depuis les paquets installés, ce qui prend plus de temps. Si le code d’un paquet lit l’un des fichiers exclus de la compilation, ajoutez un filtre extensions à son entrée : la session le chargera également depuis les paquets installés.
4. Une session qui démarre avant que la compilation soit disponible démarre sans les paquets du projet et lance la compilation ; la session suivante les aura.

Beeuni installe également un ensemble de paquets système dans chaque session harness expérimental. Une entrée de projet pour le même paquet remplace la version système. Un dépôt peut aussi contenir des extensions natives de harness expérimental dans .pi/extensions/*.ts ; harness expérimental les charge sans entrée de manifeste.

Les extensions s’exécutent sans interface de terminal : les outils, hooks et commandes fonctionnent ; les widgets réservés au terminal ne font rien.

triggers:

Liste des définitions cron, webhook et de surveillance. Chaque entrée déclenche une session qui exécute prompt comme premier message.

triggers:
  - slug: daily-digest
    type: cron
    cron: '0 0 9 * * 1-5'
    prompt: Summarize yesterday's commits.

Les déclencheurs Cron nécessitent exactement l’un de cron (une expression à 6 champs) ou run_at (un horodatage ISO-8601 ponctuel), ainsi que timezone, un nom IANA. Les déclencheurs Webhook nécessitent secret_env, le nom d’un secret qui utilise la livraison broker avec le consommateur connector. Les déclencheurs Monitor nécessitent run (une commande relative au dépôt) et mode (poll ou stream), et rejettent tous les champs Cron et Webhook. Pour la référence complète des champs, la configuration des identifiants, la création de modèles de charge utile, les points de terminaison et la stratégie de session, voir Déclencheurs.

connectors:

Une liste d’outils externes qu’un agent peut appeler. La définition se trouve dans git ; les identifiants se trouvent sur la plateforme, jamais dans le manifeste. Voir Connecteurs pour le modèle conceptuel.

connectors:
  - slug: gmail-read
    name: Gmail read only
    provider: pipedream
    app: gmail
    authorization_strategy: user
    policies:
      - match: search_email
        action: always_run

Champs spécifiques au fournisseur :

Les connecteurs channel nécessitent rarement une entrée rédigée à la main : la connexion d’un canal depuis le tableau de bord en crée une automatiquement. Voir Slack et canaux. Les slugs beeuni_slack, beeuni_teams, beeuni_email et computer sont réservés à la plateforme ; leur utilisation avec un autre fournisseur provoque une erreur de validation. Le connecteur computer est créé lorsque le premier membre connecte un ordinateur, car les identifiants des machines sont des identités du plan de contrôle du compte et ne doivent pas figurer dans le manifeste.

connectors.auth : facultatif, pour les fournisseurs autres que pipedream. type est bearer, basic, custom, api_key, oauth1, hmac, aws_sigv4, mtls ou none (par défaut). oauth1 est réservé aux fournisseurs openapi, postman et http. in est header (par défaut), query ou cookie. name est obligatoire lorsque type vaut custom ou api_key.

connectors.policies : une liste de paires {match, action}. match est un motif glob appliqué aux noms d’outils. action vaut always_run, require_approval ou block. Les politiques sont associées au connecteur. Toutes les connexions de ce connecteur utilisent les mêmes politiques.

policy.default_mode : une clé de premier niveau, distincte de connectors:, qui définit le mode d’approbation des connecteurs à l’échelle du projet. Elle accepte allow_all (par défaut ; tous les outils sans correspondance s’exécutent) ou risk (approbation requise pour les appels sans correspondance qui modifient ou détruisent des données). Définissez-la avec beeuni connectors policy set --default <risk|allow_all> — voir CLI.

Canaux

La v2 supprime channels: du schéma. Le routage des canaux vers les agents (Slack, Microsoft Teams, e-mail et voix actuellement) relève de l’état opérationnel en direct, et non d’une configuration déclarative. Vous le définissez depuis la page Channels du tableau de bord ou à l’aide de commandes de chat ; cette séparation permet aussi de garder les identifiants hors de git. La connexion d’un canal crée toujours une entrée connectors avec provider: channel que l’agent peut appeler. Voir Slack et canaux. La table [[channels]] de la v1 est présentée dans Ancien format TOML.

agents:

Une table de correspondance entre noms et blocs, indexée par nom d’agent. Cette table sert uniquement à la gouvernance : elle définit ce qu’un agent peut utiliser, jamais ce qu’il dit ou fait.

Ce bloc constitue la deuxième des deux liaisons : un principal obtient ses rôles de Beeuni, et un agent reçoit en plus les autorisations Beeuni déclarées ici. Une session ne peut faire que ce que les deux autorisent. Voir Un vocabulaire, deux liaisons.

default_agent: beeuni

agents:
  beeuni:
    file: agents/beeuni.md
    connectors: all
    secrets: all
    beeuni_permissions: all
    skills: all

  release-bot:
    file: agents/release-bot.md
    connectors: [github]
    connectors_required: [github]
    beeuni_permissions: [project.gitops.push]
    secrets: [GITHUB_AGENT_TOKEN]

La v2 applique le refus par défaut : si connectors, secrets, beeuni_permissions, skills ou apps est omis pour un agent déclaré, sa valeur devient none. Accordez explicitement à chaque agent toutes les autorisations dont il a besoin, comme le fait l’agent beeuni du modèle de démarrage ci-dessus. Un projet qui migre depuis la v1 doit réaccorder manuellement toutes les autorisations : dans la v1, env (secrets) prend la valeur all lorsqu’il est omis, soit l’inverse de la v2.

connectors_personal reste un alias d’entrée obsolète pour connectors_required. Les nouveaux manifestes doivent utiliser connectors_required. Le paramètre authorization_strategy du connecteur détermine si l’autorisation appartient au projet ou au membre.

Les autorisations beeuni_permissions proviennent d’un ensemble fixe d’autorisations limitées au projet (project.read, project.gitops.push, project.gitops.merge, project.gitops.ref.any, project.trigger.*, project.secret.*, project.connector.*, et plus encore). Les autorisations limitées au compte — member.*, billing.*, project.create — ne peuvent jamais être accordées à un agent. Exécutez beeuni validate --scopes depuis une session pour afficher la liste actuelle des autorisations pouvant être accordées.

Le fichier de l’agent

agents.<name>.file indique le .md de l’agent, relatif à la racine du dépôt.

agents:
  support:
    file: agents/support.md

• Le chemin doit se terminer par .md.
• Le chemin ne doit pas commencer par / ou -. Il ne doit contenir aucun segment . ou .., ni aucun segment vide.
• Chaque segment ne peut contenir que des lettres, des chiffres, _, -, . et des espaces.
• Si file est omis, Beeuni lit agents/<name>.md, puis .beeuni/opencode/agents/<name>.md. Lorsque opencode.config_dir est défini, le second chemin est <config_dir>/agents/<name>.md.
• Lorsque le tableau de bord enregistre un agent doté de .md, il écrit file avec ce chemin.
• L’API refuse toute requête qui modifie file (400, code invalid_config). Pour déplacer un agent, déplacez son .md et mettez à jour file dans beeuni.yaml au sein du même commit.

beeuni validate et la vérification de fusion de la demande de modification rejettent tout file invalide avec une erreur sur agents.<name>.file.

Quand les modifications de configuration prennent effet

• Une modification du manifeste, agents/, skills/ ou du répertoire de configuration harness standard ne s’applique qu’après la fusion d’une demande de modification dans main. Les sessions et les déclencheurs lisent la branche par défaut, et non les branches de session.
• Une modification du cron ou du webhook d’un déclencheur est prise en compte par le planificateur quelques secondes après la fusion.
• Une modification de l’image sandbox ou du matériel reconstruit l’instantané. La nouvelle spécification s’applique à la prochaine session, pas à la session en cours.
• Une modification de la valeur d’un secret dans le tableau de bord est prise en compte lors de la création du sandbox. Elle s’applique à la prochaine session, pas à une session en cours.

Règles de conversion aller-retour

Les modifications effectuées dans le tableau de bord correspondent à une opération de lecture-modification-écriture sur le fichier qui déclare l’entrée : beeuni.yaml, ou un fichier importé. Pour que les différences restent propres entre les modifications dans l’interface et celles effectuées pendant une session :

1. Gardez beeuni_version comme première clé.
2. Dans une entrée de déclencheur, ordonnez les champs ainsi : slug, name, type, agent, enabled, puis les champs propres au type, et enfin prompt.
3. Si vous ajoutez un déclencheur webhook avant que son secret soit défini, indiquez le nom du secret dans env.optional. Laissez le déclencheur enabled: false jusqu’à ce que la valeur soit renseignée.

Accès au dépôt

Définissez agents.<name>.repository_access sur false pour les agents qui n’ont pas besoin des fichiers source du projet. Ils peuvent tout de même créer des fichiers sandbox et utiliser les outils, secrets et connecteurs qui leur sont accordés. Définissez-le sur true pour les agents qui ont besoin du dépôt. Les autorisations Git restent distinctes. Modifiez ce paramètre dans l’éditeur d’agent, sous Workspace → Project repository access. Le paramètre s’applique aux nouvelles sessions. Les sessions existantes conservent la politique qui leur a été enregistrée, y compris après le remplacement du runtime.

agents:
  support:
    repository_access: false
  engineer:
    repository_access: true

Le champ obsolète workspace reste lisible : branch signifie true, et runtime signifie false. Les configurations read héritées continuent de rejeter la création de sessions tant que vous n’avez pas remplacé ce champ par une valeur booléenne explicite. Il n’existe pas de mode de dépôt en lecture seule. Les champs anciens et nouveaux en conflit sont rejetés. L’éditeur et le SDK envoient repository_access. Lorsque l’accès est désactivé, l’API stocke également workspace: runtime comme valeur miroir de compatibilité. Cela préserve la restriction pour les anciennes répliques de l’API pendant un déploiement ou un retour à une version précédente. Les lectures de l’API omettent cette valeur miroir. Les manifestes rédigés à la main qui utilisent uniquement repository_access nécessitent la version mise à jour de l’API.