Feature-Flags

Aktivieren Sie eine Beeuni-Oberfläche für ein Projekt und sehen Sie, welche Funktionen jedes Flag steuert.

Ein Feature-Flag aktiviert eine Beeuni-Oberfläche für ein Projekt. Jede Oberfläche kann hinter einem Flag ausgeliefert werden — experimentell, Beta oder vollständig stabil. „Experimental“ ist ein Stabilitäts-Badge für ein Flag, nicht der Name des Systems.

Flags gelten pro Projekt. Wenn du ein Flag in einem Projekt aktivierst, ändert sich in keinem anderen Projekt etwas und auch nichts für andere Konten.

Ein Flag aktivieren

1. Öffne Settings → Feature flags. Der Tab listet alle Flags auf, die von der Plattform unterstützt werden.
2. Lies die Zeile: den Namen des Flags, sein Stabilitäts-Badge, eine einzeilige Beschreibung und seinen Ursprung — Default on, Default off oder Overridden for this project.
3. Verwende den Schalter. Die Änderung gilt sofort für das aktuelle Projekt.

Du benötigst die Berechtigung project.settings.write für das Projekt. Die Route antwortet 403 für alle anderen Aufrufenden.

Über die CLI

Dieselben Schalter sind über beeuni projects features auch für Skripte und Agents verfügbar:

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

Füge --project <id> hinzu, um ein anderes als das verknüpfte/standardmäßige Projekt anzusprechen. Ein von der Plattform als nicht verfügbar markiertes Flag bleibt deaktiviert, unabhängig von der Projektüberschreibung; die CLI gibt dies als n/a / unavailable aus.

Stabilitäts-Badges

Das Badge beschreibt den Vertrag, nicht den Schalter. Ein Flag mit dem Badge stable muss weiterhin ausdrücklich aktiviert werden: apps ist stabil und standardmäßig trotzdem deaktiviert.

So wird ein Flag durchgesetzt

Für jedes Flag ist ein Durchsetzungsmodus festgelegt.

Eine Zurückweisung mit routes ist überall identisch:

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

Die Zeichenfolge error benennt die Flag-Liste, nicht einen bestimmten Tab. Die Liste ist der Tab Experimental in den Einstellungen.

Verzweige anhand von code, niemals anhand des Nachrichtentextes. Das SDK exportiert isFeatureDisabledError(error) und featureDisabledKey(error) genau dafür.

Alle Flags

Reihenfolge im Register — dieselbe Reihenfolge wie unter Settings → Feature flags.

Apps werden von Beeuni pro Projekt aktiviert. Kontaktiere Beeuni für Zugang. Nach der Aktivierung zeigt Settings Managed by Beeuni.

Was die einzelnen Flags steuern

• marketplace — Skills aus Community- und Anbieterregistern durchsuchen und installieren.
• connectors_api_discover — Direkte APIs, MCP-, GraphQL-, CLI- und Postman-Oberflächen neben verwalteten OAuth-Apps durchsuchen. Siehe Connectors.
• agentmail_email — AgentMail-Postfachverbindungen zuweisen, damit eingehende E-Mails Sitzungen starten und fortsetzen.
• llm_gateway — Das Projekt über das verwaltete Beeuni-LLM-Gateway leiten. Siehe Models.
• meta_agent — Einen plattformverwalteten Koordinator-Agent hinzufügen, der spezialisierte Sitzungen startet und verwaltet.
• apps — Statische Websites, Bundles, Dockerfiles und OCI-Images unter stabilen serverlosen URLs bereitstellen. Siehe Apps.
• monitors — 24/7-Watcher aus deinem Repository ausführen, die Triggerereignisse an Sitzungen senden. Siehe Triggers.
• reminders — Geplante Check-ins, die eine Sitzung einmalig oder wiederholt erneut anstoßen. Bei deaktiviertem Flag antworten die Reminder-Routen mit feature_disabled und vorhandene Reminders werden nicht ausgelöst. Siehe Reminders.
• warm_sessions — Eine Sandbox eingeschaltet lassen, solange ein Projekt geöffnet ist, damit neue Sitzungen ohne Kaltstart beginnen.
• secrets_egress — Netzwerkdurchsetzung für ein Secret aktivieren: Die Sandbox hält einen Verweis, und Beeuni setzt den echten Wert nur bei Anfragen an zugelassene Hosts ein. Siehe Secrets.
• pi_harness — Die Sitzungen dieses Projekts mit dem Pi-Agent-Harness innerhalb der gewöhnlichen Sitzungs-Sandbox ausführen (BEEUNI_HARNESS=pi). Aktiviert: Jede neue oder neu gestartete Sitzung startet Pi, unabhängig vom Manifest. Deaktiviert: Das Manifest entscheidet — runtime: pi startet weiterhin Pi, alles andere startet die Standard-Agent-Laufzeit. Pi ruft Modelle nur über das LLM-Gateway auf: Wenn llm_gateway deaktiviert ist, startet jede Sitzung die Standard-Agent-Laufzeit, unabhängig von diesem Flag oder dem Manifest. Repository-Struktur, Agents und Skills bleiben gleich; eine laufende Sitzung behält ihr Harness, bis sie neu gestartet oder fortgesetzt wird. Subagents funktionieren mit Pi: Der Agent delegiert mit dem Tool task an general, explore (schreibgeschützt) oder jeden Projekt-Agent mit mode: subagent in seinem .md, und das Transkript zeigt die Schritte jedes Subagents direkt an der entsprechenden Stelle. Pi-Sitzungen laden außerdem Pi.dev-Pakete: siehe harnesses:. Pi bietet nicht alle Sitzungsfunktionen von die Standard-Agent-Laufzeit: siehe die Übersicht unter Harnesses.

Graduierte Flags

Ein graduiertes Feature ist für jedes Projekt aktiviert und hat keinen Schalter.

• Agents as principals ist Standardverhalten und hat keinen Schalter. Eine Agent-Sitzung agiert als der Agent selbst — mit seinen Beeuni-Berechtigungen innerhalb seiner Rollenobergrenze, unabhängig davon, wer sie ausführt. Siehe Agent permissions.
• Review Center wurde aus dem Flag-System herausgenommen. Die Review-Seite, der Eintrag Review in der Seitenleiste und der Eintrag in der Befehlspalette werden für jedes Projekt angezeigt; die Berechtigungen project.review.read und project.review.act gelten weiterhin. review_center ist kein Flag-Schlüssel mehr: PATCH /v1/projects/:id/features antwortet mit 400 Unknown feature flag, und beeuni projects features enable review_center prints that error and exits 1. Eine vor der Graduierung gespeicherte Überschreibung hat keine Wirkung.
• Computers wurde aus dem Flag-System herausgenommen. Jedes Mitglied kann über die Projektseitenleiste den eigenen Computer verbinden; die Einstellung TUNNEL_ENABLED der Plattform ist die einzige Schranke. agent_tunnel ist kein Flag-Schlüssel mehr: PATCH /v1/projects/:id/features antwortet mit 400 Unknown feature flag. Siehe Computers.
• Microsoft Teams wurde aus dem Flag-System herausgenommen. Jedes Projekt kann Teams über Connectors → Channels verbinden; ein Mandantenadministrator muss weiterhin einmalig seine Zustimmung geben oder das Projekt bringt seinen eigenen Bot mit. teams ist kein Flag-Schlüssel mehr: PATCH /v1/projects/:id/features antwortet mit 400 Unknown feature flag. Eine vor der Graduierung gespeicherte Überschreibung hat keine Wirkung. Siehe Microsoft Teams.

Nebenwirkungen eines Schalters

Einige Flags führen nach dem Commit der Änderung zu einer Angleichung des Plattformstatus.

Diese Effekte dienen der Statusangleichung und sind nicht Teil des Erfolgs des Umschaltens. Die API-Antwort wartet nicht darauf. Jeder Effekt wird einmal wiederholt; die dahinterliegenden Reconciler sind idempotent und werden bei ihren regelmäßigen Durchläufen erneut ausgeführt.

Ein Flag im Code lesen und setzen

Lies den effektiven Status pro Projekt über die Projektdetails oder den React-Hook:

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 ist nur dann true, wenn der Server exakt true zurückgegeben hat. Eine fehlende Projekt-ID, eine laufende Abfrage und ein Fehler ergeben alle false. Setze die Schranke standardmäßig auf „geschlossen“.

Setze die Projektüberschreibung mit dem 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 ruft PATCH /v1/projects/:id/features auf. feature ist einer von FEATURE_FLAG_KEYS, exportiert aus @beeuni/sdk und typisiert als FeatureFlagKey. Siehe SDK-Referenz.

Behandle ein deaktiviertes Feature anhand des Codes, nicht anhand der Nachricht:

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`);
  }
}