Indicateurs de fonctionnalité

Activez une surface Beeuni pour un projet et découvrez ce que chaque indicateur contrôle.

Un indicateur de fonctionnalité active une fonctionnalité Beeuni pour un projet. N’importe quelle fonctionnalité peut être proposée derrière un indicateur — expérimentale, bêta ou entièrement stable. « Expérimental » est un badge de stabilité associé à un indicateur, et non le nom du système.

Les indicateurs sont propres à chaque projet. Activer un indicateur dans un projet ne change rien dans un autre projet ni pour les autres comptes.

Activer un indicateur

1. Ouvrez Settings → Feature flags. L’onglet répertorie tous les indicateurs pris en charge par la plateforme.
2. Consultez la ligne : le nom de l’indicateur, son badge de stabilité, une phrase de description et son origine — Default on, Default off ou Overridden for this project.
3. Utilisez le commutateur. La modification s’applique immédiatement au projet actuel.

Vous devez disposer de l’autorisation project.settings.write pour le projet. Pour tout autre appelant, la route renvoie 403.

Depuis la CLI

Les mêmes commutateurs sont accessibles aux scripts et aux agents via beeuni projects features :

beeuni projects features                # every flag: key, state, origin
beeuni projects features enable reminders
beeuni projects features disable reminders
beeuni projects features reset reminders  # drop the override; follow the platform default
beeuni projects features --json          # the full catalog as JSON

Ajoutez --project <id> pour agir sur un projet autre que celui associé ou défini par défaut. Un indicateur que la plateforme déclare indisponible reste désactivé, quels que soient les paramètres du projet ; la CLI l’affiche sous la forme n/a / unavailable.

Badges de stabilité

Le badge décrit le niveau de garantie, pas le commutateur. Un indicateur stable doit tout de même être activé explicitement : apps est stable et reste désactivé par défaut.

Application d’un indicateur

Chaque indicateur déclare un mode d’application.

Un rejet routes est identique partout :

{
  "error": "Apps is not enabled for this project. Contact Beeuni to enable it.",
  "code": "feature_disabled",
  "feature": "apps"
}

La chaîne error désigne la liste des indicateurs, et non un onglet en particulier. Cette liste correspond à l’onglet Experimental de Settings.

Testez code, jamais le texte du message. Le SDK exporte isFeatureDisabledError(error) et featureDisabledKey(error) à cette fin.

Tous les indicateurs

Ordre du registre — le même que celui affiché dans Settings → Feature flags.

Apps sont activés par projet par Beeuni. Contactez Beeuni pour demander l’accès. Settings affiche ensuite Managed by Beeuni.

Fonctionnalités contrôlées par chaque indicateur

• marketplace — parcourir et installer des compétences depuis les registres de la communauté et des fournisseurs.
• connectors_api_discover — parcourir les interfaces API directes, MCP, GraphQL, CLI et Postman, à côté des applications OAuth gérées. Voir Connecteurs.
• agentmail_email — attribuer des connexions de boîte de réception AgentMail afin que les e-mails entrants démarrent et poursuivent des sessions.
• llm_gateway — faire passer le projet par la passerelle LLM Beeuni gérée. Voir Modèles.
• meta_agent — ajouter un agent coordinateur géré par la plateforme qui lance et gère des sessions spécialisées.
• apps — déployer des sites statiques, des bundles, des Dockerfiles et des images OCI vers des URL serverless stables. Voir Applications.
• monitors — exécuter des observateurs 24 h/24 et 7 j/7 depuis votre dépôt, qui déclenchent des événements dans les sessions. Voir Déclencheurs.
• reminders — des rappels planifiés qui relancent une session, une fois ou de façon répétée. Désactivée, la route des rappels répond feature_disabled et les rappels existants ne se déclenchent pas. Voir Rappels.
• warm_sessions — maintenir un sandbox démarré tant qu’un projet est ouvert, afin qu’une nouvelle session démarre sans démarrage à froid.
• secrets_egress — appliquer le contrôle réseau à un secret : le sandbox conserve un identifiant, et Beeuni ne substitue la vraie valeur que pour les requêtes vers des hôtes approuvés. Voir Secrets.
• pi_harness — exécuter les sessions de ce projet sur le harnais d’agent pi, dans le sandbox de session habituel (BEEUNI_HARNESS=pi). Activée : chaque nouvelle session ou session redémarrée lance pi, quelles que soient les indications du manifeste. Désactivée : le manifeste décide — runtime: pi lance toujours pi, toute autre valeur lance le moteur d’agent par défaut. pi appelle les modèles uniquement par l’intermédiaire de la passerelle LLM : si llm_gateway est désactivée, chaque session lance le moteur d’agent par défaut, quelles que soient la valeur de ce paramètre ou les indications du manifeste. Même structure de dépôt, mêmes agents et compétences dans les deux cas ; une session en cours conserve son harnais jusqu’à son redémarrage ou sa reprise. Les sous-agents fonctionnent sur pi : l’agent délègue avec l’outil task à general, à explore (en lecture seule) ou à tout agent du projet avec mode: subagent dans son .md, et la transcription affiche les étapes de chaque sous-agent à leur place. Les sessions pi chargent également les packages pi.dev : voir harnesses:. pi ne prend pas en charge toutes les fonctionnalités de session d’le moteur d’agent par défaut : voir le tableau comparatif dans Harnais.

Indicateurs généralisés

Une fonctionnalité généralisée est activée pour tous les projets et ne dispose d’aucun interrupteur.

• Agents en tant que principaux est le comportement standard et ne dispose d’aucun interrupteur. Une session d’agent agit en tant qu’agent lui-même — avec ses permissions Beeuni dans les limites de son rôle, quel que soit l’utilisateur qui la lance. Voir Permissions des agents.
• Centre de révision est sorti du système d’indicateurs. La page Review, la ligne Review de la barre latérale et la ligne de la palette de commandes s’affichent pour tous les projets ; les permissions project.review.read et project.review.act restent applicables. review_center n’est plus une clé d’indicateur : PATCH /v1/projects/:id/features répond 400 Unknown feature flag, et beeuni projects features enable review_center prints that error and exits 1. Une dérogation enregistrée avant la généralisation n’a aucun effet.
• Ordinateurs est sorti du système d’indicateurs. Chaque membre peut connecter son propre ordinateur depuis la barre latérale du projet ; le paramètre TUNNEL_ENABLED de la plateforme est le seul verrou. agent_tunnel n’est plus une clé d’indicateur : PATCH /v1/projects/:id/features répond 400 Unknown feature flag. Voir Ordinateurs.
• Microsoft Teams est sorti du système d’indicateurs. Chaque projet peut connecter Teams depuis Connectors → Channels ; un administrateur du tenant doit toujours donner son consentement une fois, ou le projet doit fournir son propre bot. teams n’est plus une clé d’indicateur : PATCH /v1/projects/:id/features répond 400 Unknown feature flag. Une dérogation enregistrée avant la généralisation n’a aucun effet. Voir Microsoft Teams.

Effets secondaires d’un changement

Certains indicateurs mettent l’état de la plateforme en convergence une fois l’écriture validée.

Ces effets sont des opérations de convergence, et non une partie de la réussite du changement. La réponse de l’API ne les attend pas. Chaque effet fait l’objet d’une nouvelle tentative, et les réconciliateurs qui les exécutent sont idempotents et se relancent lors de leurs vérifications périodiques.

Lire et définir un indicateur dans le code

Lisez l’état effectif par projet via les détails du projet ou le hook React :

import { useFeatureFlag } from '@beeuni/sdk/react';

function AppsNavItem({ projectId }: { projectId: string }) {
  const apps = useFeatureFlag(projectId, 'apps');
  if (!apps.enabled) return null;
  return <Link href={`/projects/${projectId}/apps`}>Apps</Link>;
}

enabled vaut true uniquement si le serveur a renvoyé exactement true. Un identifiant de projet manquant, une requête en cours ou une erreur donnent tous false. Appliquez une logique de refus par défaut.

Définissez la dérogation du projet avec le client :

const p = beeuni.project(projectId);

await p.updateFeatureFlag('apps', true);   // turn it on for this project
await p.updateFeatureFlag('apps', null);   // clear the override, inherit the default

updateFeatureFlag appelle PATCH /v1/projects/:id/features. feature est l’une des valeurs FEATURE_FLAG_KEYS, exportée depuis @beeuni/sdk et typée FeatureFlagKey. Voir la référence du SDK.

Gérez la désactivation d’une fonctionnalité dans le code, et non à partir d’un message :

import { featureDisabledKey, isFeatureDisabledError } from '@beeuni/sdk';

try {
  await beeuni.project(projectId).apps.list();
} catch (error) {
  if (isFeatureDisabledError(error)) {
    console.log(`${featureDisabledKey(error)} is off for this project`);
  }
}