# Feature-Flags

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

Canonical page: https://beeuni.ai/docs/de/feature-flags

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.

- [Apps](/docs/de/feature-flags/apps): Statische Websites, Bundles, Dockerfiles und OCI-Images unter stabilen URLs bereitstellen.

<a id="turn-a-flag-on"></a>

## 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.

<a id="from-the-cli"></a>

### Über die CLI

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

```bash
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.

> **Der Flag-Status befindet sich nicht in deinem Repository**
>
> Der Status der Flags pro Projekt wird in der Datenbank in der Projektzeile gespeichert. Er wird nie aus `beeuni.yaml` gelesen. Ein von dir aktiviertes Flag wird nicht mit einem Repository-Klon oder Fork übernommen.

<a id="stability-badges"></a>

## 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.

| Badge | Bedeutung |
|---|---|
| Experimental | Die Oberfläche und ihr Vertrag können sich noch ändern. |
| Beta | Die Oberfläche funktioniert und ihre Form nimmt Gestalt an. |
| Stable | Der Vertrag gilt. Das Flag muss weiterhin ausdrücklich aktiviert werden. |

<a id="how-a-flag-is-enforced"></a>

## So wird ein Flag durchgesetzt

Für jedes Flag ist ein Durchsetzungsmodus festgelegt.

| Modus | Verhalten des Servers, wenn das Flag deaktiviert ist |
|---|---|
| `routes` | Die HTTP-Oberfläche weist die Anfrage mit `403` zurück. |
| `behavioral` | Das Verhalten tritt nicht ein — kein Connector wird bereitgestellt, keine Umgebungsvariable eingefügt und kein Agent registriert. |
| `ui-only` | Der Server setzt das Flag bewusst nicht durch. Das Flag blendet nur die Client-Oberfläche aus. |

Eine Zurückweisung mit `routes` ist überall identisch:

```json
{
  "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.

<a id="every-flag"></a>

## 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**.

| Schlüssel | Name | Stabilität | Standard |
|---|---|---|---|
| `marketplace` | Marketplace | Beta | Aktiviert |
| `connectors_api_discover` | Connectors API Discover | Experimental | Deaktiviert |
| `agentmail_email` | AgentMail Email | Experimental | Deaktiviert |
| `llm_gateway` | LLM Gateway | Experimental | Aktiviert  |
| `meta_agent` | Meta Agent | Experimental | Deaktiviert |
| `apps` | Apps | Stable | Deaktiviert |
| `monitors` | Monitors | Experimental | Deaktiviert |
| `reminders` | Reminders | Beta | Deaktiviert |
| `warm_sessions` | Warm Sessions | Beta | Aktiviert |
| `secrets_egress` | Network-Enforced Secrets | Experimental | Aktiviert |
| `pi_harness` | Pi Harness  | Experimental | Deaktiviert |

<a id="what-each-flag-gates"></a>

### 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](/docs/de/connect/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](/docs/de/project/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](/docs/de/feature-flags/apps).
- **`monitors`** — 24/7-Watcher aus deinem Repository ausführen, die Triggerereignisse an Sitzungen senden. Siehe [Triggers](/docs/de/connect/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](/docs/de/connect/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](/docs/de/project/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:`](/docs/de/project/manifest#harnesses). Pi bietet nicht alle Sitzungsfunktionen von die Standard-Agent-Laufzeit: siehe die Übersicht unter [Harnesses](/docs/de/work/harnesses#what-each-harness-supports).

<a id="graduated-flags"></a>

### 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](/docs/de/project/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](/docs/de/connect/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](/docs/de/connect/teams).

<a id="side-effects-of-a-toggle"></a>

## Nebenwirkungen eines Schalters

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

| Flag | Wirkung nach dem Umschalten |
|---|---|
| `agentmail_email` | Beeuni führt die Bereitstellung des Channel-Connectors erneut aus, sodass der Connector entsprechend dem Flag erscheint oder verschwindet. |
| `llm_gateway` | Beeuni überträgt den neuen Anbietermodus an aktive Sandboxes. |

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.

<a id="read-and-set-a-flag-from-code"></a>

## Ein Flag im Code lesen und setzen

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

```tsx
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:

```ts
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:

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