@agent-native/core 0.87.0 → 0.90.1

package/docs/content/locales/de-DE/agent-native-toolkit.mdx

@@ -0,0 +1,103 @@
+---
+title: "Toolkit"
+description: "Reusable app-building primitives that sit between @agent-native/core and template apps."
+---
+
+# Toolkit
+
+`@agent-native/core` owns the foundational runtime: actions, app state, auth,
+SQL, server plugins, agent chat, sharing access checks, and collaboration
+transport. `@agent-native/toolkit` owns reusable app-building pieces that sit on
+top of that runtime: UI primitives, app-local adapters, shell helpers, sharing
+badges, and collaboration UI.
+
+Apps should compose those pieces through local adapters. That keeps app UI easy
+to customize without copying Toolkit implementation code.
+
+<WireframeBlock id="doc-block-toolkit-layering">
+  <Screen
+    surface="desktop"
+    html={
+      "<div style='min-height:520px;box-sizing:border-box;padding:48px 36px;display:flex;align-items:center;justify-content:center'><div style='width:min(900px,100%);display:grid;grid-template-columns:1fr;gap:18px'><div class='wf-card' style='padding:22px 24px'><div style='display:flex;align-items:center;justify-content:space-between;gap:16px'><div><strong>App</strong><p class='wf-muted' style='margin:6px 0 0'>Domain routes, actions, local UI adapters, product-specific views</p></div><span class='wf-pill'>@/components/ui/button</span></div></div><div class='wf-card' style='padding:22px 24px;border-color:hsl(var(--primary))'><div style='display:flex;align-items:center;justify-content:space-between;gap:16px'><div><strong>Toolkit</strong><p class='wf-muted' style='margin:6px 0 0'>Reusable primitives, collab UI, sharing UI, app shell hooks</p></div><span class='wf-pill'>ToolkitProvider</span></div><div style='display:grid;grid-template-columns:repeat(4,minmax(0,1fr));gap:10px;margin-top:16px'><span class='wf-pill'>UI</span><span class='wf-pill'>Collab UI</span><span class='wf-pill'>Sharing UI</span><span class='wf-pill'>Shell</span></div></div><div class='wf-card' style='padding:22px 24px'><div style='display:flex;align-items:center;justify-content:space-between;gap:16px'><div><strong>Core</strong><p class='wf-muted' style='margin:6px 0 0'>Actions, SQL, auth, sharing runtime, Yjs transport, app state</p></div><span class='wf-pill'>@agent-native/core</span></div></div></div></div>"
+    }
+  />
+</WireframeBlock>
+
+## What Ships Today {#what-ships-today}
+
+- **UI primitives**: shadcn-style components under
+  `@agent-native/toolkit/ui/*`.
+- **App adapters**: template-local wrappers such as
+  `@/components/ui/button` that re-export Toolkit primitives until an app wants
+  to customize them.
+- **ToolkitProvider**: an override layer that lets reusable Toolkit UI use an
+  app's local primitives, starting with `Button`.
+- **Collaboration UI**: presence avatars, live cursors, remote selection rings,
+  recent edit highlights, and agent presence chips under
+  `@agent-native/toolkit/collab-ui`.
+- **Sharing UI**: the reusable `VisibilityBadge` under
+  `@agent-native/toolkit/sharing`.
+- **Shell and hooks**: app-shell header actions plus shared hooks such as
+  `useIsMobile` and `useToast`.
+
+## Compatibility {#compatibility}
+
+Existing imports from `@agent-native/core/client` keep working. Core now exposes
+thin re-export shims for Toolkit-owned visual pieces while keeping runtime
+behavior in core.
+
+Those core shims are temporary migration support, not the long-term dependency
+direction. The next major can remove them; after that, reusable app-building
+packages should import Toolkit directly, and behaviorful Toolkit kits may compose
+core runtime APIs as peer/runtime dependencies instead of pushing more UI back
+into core.
+
+Extract future behaviorful kits one at a time before broadening the split.
+Sharing is the first candidate to validate that model because it exercises
+access checks, action-backed data, and share-link UI together.
+
+That means this keeps working:
+
+```tsx
+import { PresenceBar, VisibilityBadge } from "@agent-native/core/client";
+```
+
+New reusable app code should prefer Toolkit or app-local adapters:
+
+```tsx
+import { PresenceBar } from "@agent-native/toolkit/collab-ui";
+import { Button } from "@/components/ui/button";
+```
+
+## Boundary {#boundary}
+
+Move code into Toolkit when it is reusable app-building UI or a pure UI contract.
+Keep code in core when it owns access control, SQL, actions, request context,
+Yjs transport, auth, or other runtime guarantees.
+
+Good Toolkit candidates:
+
+- Components that render the same interaction across apps.
+- Display-only helpers and structural prop types.
+- Base components that receive data and callbacks from an app or core wrapper.
+- App-shell hooks and adapters that do not own domain data.
+
+Keep app-local:
+
+- Domain-specific workflows.
+- Resource-specific mutations and routes.
+- Custom visual systems an app intentionally owns.
+
+Keep core-owned:
+
+- Sharing actions and access checks.
+- Collaboration storage, awareness transport, and Yjs document sync.
+- Auth, sessions, app state, SQL, and server plugins.
+
+## Pages {#pages}
+
+- [UI Primitives](/docs/toolkit-ui)
+- [App Adapters](/docs/toolkit-app-adapters)
+- [Collaboration UI](/docs/toolkit-collaboration-ui)
+- [Sharing UI](/docs/toolkit-sharing-ui)
+- [Shell & Hooks](/docs/toolkit-shell-hooks)

package/docs/content/locales/de-DE/cloneable-saas.mdx

@@ -1,19 +1,19 @@
 ---
-title: "Vorlagen"
+title: "Apps"
 description: "Forken Sie ein funktionierendes SaaS-Produkt und machen Sie es zu Ihrem – Agent inklusive."
 ---
 
-# Vorlagen
+# Apps
 
-Möchten Sie Ihr eigenes KI-gestütztes Analysetool liefern? Mail-Client? Formularersteller? Wählen Sie eine Vorlage und Sie haben in wenigen Minuten ein funktionierendes SaaS – Agent, Datenbank, Authentifizierung und Bereitstellungspipeline sind bereits verkabelt.
+Möchten Sie Ihr eigenes KI-gestütztes Analysetool liefern? Mail-Client? Formularersteller? Wählen Sie eine Beispiel-App und Sie haben in wenigen Minuten ein funktionierendes SaaS – Agent, Datenbank, Authentifizierung und Bereitstellungspipeline sind bereits verkabelt.
 
-Die meisten „Vorlagen“ geben Ihnen ein leeres Gerüst und eine lange TODO-Liste. Agent-Native macht das anders. Bei jedem einzelnen handelt es sich um ein **komplettes Produkt auf SaaS-Niveau** – bereits am ersten Tag lauffähig, bereits lieferbar und ganz Ihnen überlassen, individuell anzupassen, zu branden und bereitzustellen. Betrachten Sie sie als klonbare SaaS, nicht als Starter-Kits: Sie forken ein fertiges Produkt und starren nicht auf die Standardversion.
+Die meisten Starter-Vorlagen geben Ihnen ein leeres Gerüst und eine lange TODO-Liste. Agent-Native macht das anders. Jede Beispiel-App ist ein **komplettes Produkt auf SaaS-Niveau** – bereits am ersten Tag lauffähig, bereits lieferbar und ganz Ihnen überlassen, individuell anzupassen, zu branden und bereitzustellen. Betrachten Sie sie als klonbare SaaS, nicht als Starter-Kits: Sie forken ein fertiges Produkt und starren nicht auf die Standardversion.
 
-## Vorlagen verfügbar {#catalog}
+## Beispiel-Apps {#catalog}
 
 Jede davon ist eine echte App, die Sie heute verwenden können, und die Startrampe für Ihre eigene Version davon.
 
-| Vorlage                                   | Was es ist                                                                                                                                                 |
+| App                                       | Was es ist                                                                                                                                                 |
 | ----------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------- |
 | [**Chat**](/docs/template-chat)           | Minimale Chat-First-App mit dauerhaften Threads, actions, Authentifizierung und einem sauberen Pfad zum benutzerdefinierten UI oder Ihrem eigenen Backend. |
 | [**Mail**](/docs/template-mail)           | Ein aus Agenten stammender Übermensch. Posteingang, Beschriftungen, KI-Selektion, Tastatureingabe, Entwürfe und Versendungen über den Agenten.             |
@@ -35,16 +35,16 @@ Sehen Sie sich den vollständigen Katalog unter [Apps](/apps) an oder springen S
 
 ## Was Sie im Lieferumfang enthalten {#what-you-get}
 
-Jede Vorlage wird mit den Teilen geliefert, deren Erstellung normalerweise Monate dauert:
+Jede Beispiel-App wird mit den Teilen geliefert, deren Erstellung normalerweise Monate dauert:
 
 - **Ein funktionierender Agent** – bereits mit der App verbunden, bereits in der Lage, actions auf Ihre Daten zu übertragen, bereits kontextbewusst darüber, was Sie gerade sehen. Informationen zur Funktionsweise finden Sie unter [Messaging the agent](/docs/messaging).
 - **Auth** – Anmeldung, Sitzungen, Organisationen, mandantenfähige Isolation. Bereits erledigt.
-- **Eine Datenbank** – für jede Vorlage stehen Schema, Abfragen und Migrationen bereit. Bringen Sie Ihre eigene SQL-Datenbank (Postgres, SQLite, Turso, D1) mit – das Framework passt sich an.
+- **Eine Datenbank** – für jede Beispiel-App stehen Schema, Abfragen und Migrationen bereit. Bringen Sie Ihre eigene SQL-Datenbank (Postgres, SQLite, Turso, D1) mit – das Framework passt sich an.
 - **Ein Echtzeit-UI** – der Bildschirm bleibt mit den Aktionen des Agenten synchronisiert. Klicken Sie im Chat auf „E-Mail entwerfen“. Der Entwurf erscheint sofort in Ihrem Posteingang.
 - **Bereitstellungsbereit** – Push an Netlify, Vercel, Cloudflare, AWS oder an einen anderen Ort, an dem Node ausgeführt wird. Keine Lieferantenbindung.
 - **Branding-Hooks** – Name, Farben, Logo und Text können einfach geändert werden.
 
-Dies ist keine theoretische Behauptung. Der Autor des Frameworks führt seinen tatsächlichen Posteingang auf der Mail-Vorlage, seinen tatsächlichen Kalender auf der Kalendervorlage und seine tatsächlichen Analysen auf der Analytics-Vorlage aus. Vorlagen sind tägliche Treibersoftware.
+Dies ist keine theoretische Behauptung. Der Autor des Frameworks führt seinen tatsächlichen Posteingang in der Mail-App, seinen tatsächlichen Kalender in der Calendar-App und seine tatsächlichen Analysen in der Analytics-App aus. Diese Apps sind Software für den täglichen Einsatz.
 
 ## Was Sie tun {#what-you-do}
 
@@ -56,7 +56,7 @@ Der Weg von „Ich möchte mein eigenes SaaS“ zu „Ich habe mein eigenes SaaS
 <div class="diagram-fork">
   <div class="diagram-card">
     <span class="diagram-pill">1</span><strong>Pick</strong
-    ><small class="diagram-muted">a complete template</small>
+    ><small class="diagram-muted">eine vollständige App</small>
   </div>
   <div class="diagram-arrow diagram-muted" aria-hidden="true">&rarr;</div>
   <div class="diagram-card">
@@ -98,8 +98,8 @@ Der Weg von „Ich möchte mein eigenes SaaS“ zu „Ich habe mein eigenes SaaS
 
 </Diagram>
 
-1. **Wählen Sie eine Vorlage.** Verwenden Sie die CLI-Auswahl oder durchsuchen Sie die Dokumente und wählen Sie eine aus, mit der Sie beginnen möchten.
-2. **Marken Sie es.** Ändern Sie den Namen, die Farben, das Logo und den Text. Die meisten Vorlagen stellen dies in einer einzigen Konfigurationsdatei bereit.
+1. **Wählen Sie eine Beispiel-App.** Verwenden Sie die CLI-Auswahl oder durchsuchen Sie die Dokumente und wählen Sie eine aus, mit der Sie beginnen möchten.
+2. **Marken Sie es.** Ändern Sie den Namen, die Farben, das Logo und den Text. Die meisten Beispiel-Apps stellen dies in einer einzigen Konfigurationsdatei bereit.
 3. **Passen Sie es an.** Bitten Sie den Agenten, die benötigte Spalte hinzuzufügen, die Posteingangsgruppen zu ändern, eine Verbindung zu Ihrem internen API herzustellen und eine neue Ansicht hinzuzufügen. Der Agent bearbeitet den Code; Sie überprüfen den Unterschied.
 4. **Versenden Sie es.** Führen Sie den Bereitstellungsbefehl aus. Sie haben jetzt Ihr eigenes Produktions-SaaS in Ihrer eigenen Domain.
 
@@ -159,7 +159,7 @@ Das Ergebnis: Flexibilität auf Claude-Codeebene für jeden Benutzer, mit normal
 
 ## Möchten Sie nicht forken? {#hosted}
 
-Das musst du nicht. Jede Vorlage ist auch als gehostete App auf `agent-native.com` – `mail.agent-native.com`, `calendar.agent-native.com` usw. verfügbar. Nutzen Sie die gehostete Version kostenlos oder kostenpflichtig; Fork nur, wenn Sie etwas ändern möchten, das die gehostete Version nicht offenlegt.
+Das musst du nicht. Jede Beispiel-App ist auch als gehostete App auf `agent-native.com` – `mail.agent-native.com`, `calendar.agent-native.com` usw. verfügbar. Nutzen Sie die gehostete Version kostenlos oder kostenpflichtig; Fork nur, wenn Sie etwas ändern möchten, das die gehostete Version nicht offenlegt.
 
 ## Probieren Sie es mit einer Fertigkeit aus {#try-with-a-skill}
 
@@ -168,10 +168,10 @@ Nicht bereit für den Gerüstbau? Sie können einem Codierungsagenten, den Sie b
 ## Darauf aufbauen
 
 - [**Getting Started**](/docs/getting-started) – Erstellen Sie eine chat-first App, fügen Sie eine action hinzu, rendern Sie ein strukturiertes Ergebnis und wachsen Sie zu einer Seite
-- [**Messaging the agent**](/docs/messaging) – wie Benutzer (und Sie) mit dem Agenten kommunizieren, der mit jeder Vorlage geliefert wird
-- [**Multi-App Workspace**](/docs/multi-app-workspace) – Bündeln Sie mehrere Vorlagen in einem Arbeitsbereich, der Authentifizierung, Marke und Agent teilt
-- [**Dispatch**](/docs/template-dispatch) – die Vorlage für die Steuerungsebene des Arbeitsbereichs
-- [**Creating Templates**](/docs/creating-templates) – Erstellen und veröffentlichen Sie Ihre eigene Vorlage
+- [**Messaging the agent**](/docs/messaging) – wie Benutzer (und Sie) mit dem Agenten kommunizieren, der mit jeder App geliefert wird
+- [**Multi-App Workspace**](/docs/multi-app-workspace) – Bündeln Sie mehrere Apps in einem Arbeitsbereich, der Authentifizierung, Marke und Agent teilt
+- [**Dispatch**](/docs/template-dispatch) – die App für die Steuerungsebene des Arbeitsbereichs
+- [**Creating Templates**](/docs/creating-templates) – Erstellen und veröffentlichen Sie Ihre eigene App-Vorlage
 
 ### Für Entwickler {#dev-details}
 
@@ -181,10 +181,10 @@ Wenn Sie jetzt ein Gerüst erstellen, lautet der CLI-Befehl:
 npx @agent-native/core@latest create my-platform
 ```
 
-Sie erhalten eine Mehrfachauswahl-Auswahl. Wählen Sie eine App (eigenständig) oder mehrere (Arbeitsbereich – Apps teilen sich Authentifizierung, Marke, Agentenkonfiguration und Datenbank). Jede ausgewählte Vorlage wird mit jeder benötigten Datei in `apps/<name>/` eingebunden. Für eine Automation ohne Browser-UI anstelle einer Vorlage UI verwenden Sie `npx @agent-native/core@latest create my-agent --headless`.
+Sie erhalten eine Mehrfachauswahl-Auswahl. Wählen Sie eine App (eigenständig) oder mehrere (Arbeitsbereich – Apps teilen sich Authentifizierung, Marke, Agentenkonfiguration und Datenbank). Jede ausgewählte App wird mit jeder benötigten Datei in `apps/<name>/` eingebunden. Für eine Automation ohne Browser-UI anstelle einer App-UI verwenden Sie `npx @agent-native/core@latest create my-agent --headless`.
 
 Geben Sie `.env` (hauptsächlich `ANTHROPIC_API_KEY` und `DATABASE_URL`), `pnpm install`, `pnpm dev` ein und es funktioniert. Kein „TODO: Login implementieren“, keine Platzhalterrouten.
 
 Ziele bereitstellen: jeder Nitro-kompatible Host (Node, Cloudflare, Netlify, Vercel, Deno, Lambda, Bun) und jede Drizzle-kompatible SQL-Datenbank (SQLite, Postgres, Turso, D1, Supabase, Neon). Für Arbeitsbereiche erstellt `npx @agent-native/core@latest deploy` jede App auf einmal und versendet sie hinter einem einzigen Ursprung. Siehe [Deployment](/docs/deployment).
 
-Informationen zum Erstellen und Veröffentlichen Ihrer eigenen Vorlage finden Sie unter [Creating Templates](/docs/creating-templates).
+Informationen zum Erstellen und Veröffentlichen Ihrer eigenen App-Vorlage finden Sie unter [Creating Templates](/docs/creating-templates).

package/docs/content/locales/de-DE/components.mdx

@@ -25,7 +25,9 @@ Vermeiden Sie den Import von UI-Komponenten aus dem bloßen `@agent-native/core`
 `@agent-native/core/client` oder ein fokussierter `@agent-native/core/client/*`-Unterpfad
 daher wählen Bundler den browsersicheren Eintrag.
 
-Verwenden Sie `@agent-native/toolkit` für wiederverwendbare App-Bausteine, die nicht Teil des grundlegenden Laufzeitvertrags sind: shadcn-artige UI-Primitives, gemeinsame Hooks, einfache App-Shell-Helfer und weitere Template-Kompositionsmodule. Core behält während der Umstellung Kompatibilitäts-Reexports, aber neuer Template- und App-Code sollte Toolkit-Module direkt importieren:
+Verwenden Sie `@agent-native/toolkit` für wiederverwendbare App-Bausteine, die nicht Teil des grundlegenden Laufzeitvertrags sind: shadcn-artige UI-Primitives, gemeinsame Hooks, einfache App-Shell-Helfer und weitere Template-Kompositionsmodule. Core behält während der Umstellung Kompatibilitäts-Reexports.
+
+Wiederverwendbare Packages können Toolkit-Module direkt importieren:
 
 ```tsx
 import { Button } from "@agent-native/toolkit/ui/button";
@@ -34,6 +36,13 @@ import { useToast } from "@agent-native/toolkit/hooks/use-toast";
 import { useSetHeaderActions } from "@agent-native/toolkit/app-shell";
 ```
 
+Innerhalb von Template-Apps sollten app-lokale Adapter bevorzugt werden, damit Teams Primitives einmal ersetzen können und jede wiederverwendete Toolkit-Oberfläche die lokale Implementierung nutzt:
+
+```tsx
+import { Button } from "@/components/ui/button";
+import { useToast } from "@/hooks/use-toast";
+```
+
 <Diagram id="doc-block-6bst90" title="Lassen Sie eine Ebene nach unten fallen, nicht aus dem Framework heraus" summary={"Jede Ebene behält die gleiche Laufzeit bei – Aktionen, Thread-Status und SQL-backed-Synchronisierung – und gibt Ihnen gleichzeitig mehr Kontrolle über Chrome."}>
 
 ```html
@@ -443,7 +452,8 @@ function WorkspaceResources() {
 
 | Bereich            | APIs                                                   | Importpfad                                |
 | ------------------ | ------------------------------------------------------ | ----------------------------------------- |
-| Teilen             | `<ShareButton>`, `<ShareDialog>`, `<VisibilityBadge>`  | `@agent-native/core/client/sharing`       |
+| Teilen             | `<ShareButton>`, `<ShareDialog>`                       | `@agent-native/core/client/sharing`       |
+| Sharing UI         | `<VisibilityBadge>`                                    | `@agent-native/toolkit/sharing`           |
 | Benachrichtigungen | `<NotificationsBell>`                                  | `@agent-native/core/client/notifications` |
 | Fortschritt        | `<RunsTray>`, Fortschritts-Hooks und -Typen            | `@agent-native/core/client/progress`      |
 | Onboarding         | `useOnboarding()`, Onboarding-Panel-Haken              | `@agent-native/core/client/onboarding`    |

package/docs/content/locales/de-DE/data-programs.mdx

@@ -0,0 +1,329 @@
+---
+title: "Datenprogramme"
+description: "Gespeicherte, vom Agenten verfasste JS-Skripte, die Daten serverseitig abrufen, verknüpfen und aggregieren, in SQL zwischengespeichert und von Dashboard-Panels gerendert werden – der Live-Daten-Mittelweg zwischen einer einmaligen run-code-Abfrage und einer fest codierten Provider-Aktion."
+search: "data program emit rows schema providerFetch dashboard panel program source refresh TTL viewer-scoped cache save-data-program run-data-program"
+---
+
+# Datenprogramme
+
+Ein **Datenprogramm** ist ein benanntes, gespeichertes, vom Agenten verfasstes JS-Skript, das Daten abruft, verknüpft, filtert oder aggregiert – Provider-APIs über `providerFetch` / `providerFetchAll` / `providerSearchAll`, App-Daten über `appAction`, oder Resources-gestützte Workspace-Dateien – und genau einmal `emit(rows, schema)` mit dem Ergebnis aufruft. Das Ergebnis wird in SQL zwischengespeichert, und jede Chart-/Tabellenkomponente kann es rendern, aktualisiert nach einer von Ihnen gewählten Richtlinie statt bei jedem Seitenaufruf.
+
+Es ist automatisch überall verfügbar, wo [`run-code`](/docs/actions) verfügbar ist – es gibt nichts, das Sie pro App einbinden oder konfigurieren müssen. Wenn Ihre App run-code bereits aktiviert hat, sind `save-data-program`, `preview-data-program`, `run-data-program`, `list-data-programs`, `get-data-program` und `delete-data-program` bereits registrierte actions.
+
+<Diagram id="doc-block-dp-overview" title={"Von der Ad-hoc-Abfrage zum Live-Panel"} summary={"Ein run-code-Skript wird zu einem gespeicherten Programm, sobald es emit() aufruft; jedes Dashboard-Panel kann sich daran binden, und die Cache-/Aktualisierungsrichtlinie übernimmt von dort aus."}>
+
+```html
+<div class="dp-flow">
+  <div class="diagram-card" data-rough>
+    <span class="diagram-pill">run-code script</span
+    ><small class="diagram-muted">providerFetch, joins, aggregation</small>
+  </div>
+  <div class="diagram-arrow diagram-muted" aria-hidden="true">&rarr;</div>
+  <div class="diagram-panel">
+    <span class="diagram-pill accent">emit(rows, schema)</span
+    ><small class="diagram-muted"
+      >save-data-program dry-runs, then persists</small
+    >
+  </div>
+  <div class="diagram-arrow diagram-muted" aria-hidden="true">&rarr;</div>
+  <div class="diagram-box" data-rough>
+    data_program_runs<br /><small class="diagram-muted"
+      >cached per (program, params, viewer)</small
+    >
+  </div>
+  <div class="diagram-arrow diagram-muted" aria-hidden="true">&rarr;</div>
+  <div class="diagram-card">
+    <span class="diagram-pill">Dashboard-Panel</span
+    ><small class="diagram-muted"><code>source: "program"</code></small>
+  </div>
+</div>
+```
+
+```css
+.dp-flow {
+  display: flex;
+  align-items: center;
+  gap: 12px;
+  flex-wrap: wrap;
+}
+.dp-flow .diagram-card,
+.dp-flow .diagram-panel {
+  display: flex;
+  flex-direction: column;
+  gap: 6px;
+  padding: 14px 16px;
+  min-width: 180px;
+}
+.dp-flow .diagram-arrow {
+  font-size: 20px;
+  line-height: 1;
+}
+```
+
+</Diagram>
+
+## Warum es das gibt {#why}
+
+Ohne ein gespeichertes Datenprogramm endet „baue eine Live-Ansicht von X" meist an einem von zwei schlechten Orten:
+
+- **Eine fest codierte action pro Anbieter/Abfrageform.** Brüchig, und sie kann nicht jede benutzerdefinierte Eigenschaft jedes Kunden, einen anbieterübergreifenden Join oder einen willkürlichen Filter antizipieren, an den Sie nicht gedacht haben.
+- **Dieselbe Abruf-/Join-Logik bei jedem Seitenaufruf von Grund auf neu ausführen.** Langsam, und es verbraucht bei jedem Blick auf ein Diagramm erneut dasselbe Provider-API-Kontingent.
+
+Ein Datenprogramm ist der Mittelweg: Schreiben Sie die Abruf-/Join-/Aggregationslogik einmal als gewöhnlichen `run-code`, speichern Sie sie, und lassen Sie die Cache- und Aktualisierungsrichtlinie entscheiden, wie oft sie tatsächlich erneut ausgeführt werden muss.
+
+## Wann Sie eines verwenden sollten {#when-to-use-one}
+
+| Situation                                                                                                                                                                                                     | Greifen Sie zu                                                                                     |
+| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------- |
+| Ein Standard-Rollup hat bereits eine erstklassige action (ein vorgefertigter `hubspot-deals`-Filter, eine eingebaute Metrik)                                                                                  | Die vorhandene action — verpacken Sie sie nicht in ein Programm                                    |
+| Eine einmalige Chat-Frage, die Sie nie wieder ansehen werden                                                                                                                                                  | Einfaches `run-code` oder `provider-api-request` — beantworten Sie es direkt, speichern Sie nichts |
+| Eine Erweiterung benötigt ein kleines, interaktives Widget pro Benutzer mit eigener UI                                                                                                                        | [Erweiterungen](/docs/extensions) — ein Datenprogramm hat keine eigene UI                          |
+| Eine Kohorte benötigt einen willkürlichen Eigenschaftsfilter, eine IN-Suche über benutzerdefinierte Werte oder einen Join über zwei Provider hinweg, **und** jemand möchte es mit aktuellen Daten wiedersehen | Ein Datenprogramm                                                                                  |
+| Ein Dashboard-Panel soll dieses verknüpfte/aggregierte Ergebnis anzeigen und nach der Cache-Richtlinie aktualisieren                                                                                          | Ein Datenprogramm, gebunden an ein `"program"`-Panel                                               |
+
+Ein Vergleich mit den anderen run-code-förmigen Optionen:
+
+|                                                    | Einmaliges `run-code`     | Fest codierte Provider-action                                | Datenprogramm                                                    |
+| -------------------------------------------------- | ------------------------- | ------------------------------------------------------------ | ---------------------------------------------------------------- |
+| **Bleibt zwischen Aufrufen bestehen**              | Nein                      | N/A (es ist Quellcode)                                       | Ja — gespeicherte Zeile + Ergebnis-Cache                         |
+| **Ergebnis wird zwischengespeichert/aktualisiert** | Nein, läuft jedes Mal neu | Kein eingebautes Caching                                     | Ja — `refreshMode`/`refreshTtlMs`                                |
+| **Verarbeitet willkürliche Filter/Joins**          | Ja, aber danach verworfen | Nein — begrenzt auf das, was das Schema der action offenlegt | Ja — es ist immer noch gewöhnlicher Code                         |
+| **An ein Dashboard-Panel bindbar**                 | Nein                      | Nur wenn eine Panel-Quelle dafür gebaut wurde                | Ja — die generische `"program"`-Quelle                           |
+| **Erfordert ein Deployment**                       | Nein                      | Ja (neue action = Code-Änderung)                             | Nein — vom Agenten zur Laufzeit erstellt                         |
+| **Zur Lesezeit verwendete Credentials**            | Die des Aufrufers         | Die des Aufrufers                                            | **Die des Betrachters**, pro Lesevorgang aufgelöst (siehe unten) |
+
+## Autoren-Workflow {#authoring-workflow}
+
+1. **Zuerst im Chat prototypisieren.** Schreiben Sie die Abruf-/Join-/Aggregationslogik als normales `run-code`-Skript und bestätigen Sie, dass es die erwarteten Zeilen zurückgibt.
+2. **Ändern Sie es so, dass es genau einmal `emit(rows, schema?)` aufruft**, am Ende, statt das Ergebnis zurückzugeben oder auszugeben.
+3. **Speichern Sie es** mit `save-data-program`. Dies **führt einen Dry-Run des Codes mit `defaultParams` durch, bevor es gespeichert wird**, und lehnt das Speichern mit einem strukturierten Fehler ab, falls es fehlschlägt, sodass ein defektes Programm nie gespeichert wird. Bei Erfolg gibt es `{ programId, rowCount, columns, sampleRows }` zurück — betrachten Sie das als Beweis, dass das Programm die erwarteten Zeilen liefert, bevor Sie dem Benutzer sagen, dass es bereit ist.
+4. **Binden Sie ein Dashboard-Panel daran**, oder rufen Sie `run-data-program` direkt von Ihrem eigenen Lesepfad aus auf. Es gibt keine dashboard-spezifische Verkabelung, die in die Primitive selbst eingebaut ist — die `"program"`-Panel-Quelle der Analytics-Vorlage (unten) ist eine Anwendung davon, kein erforderliches Muster.
+5. **Iterieren Sie, ohne zu speichern**, über `preview-data-program({ code, params? })` — derselbe Dry-Run-Pfad, keine gespeicherte Zeile.
+
+### Ein realistisches Beispiel
+
+Angenommen, eine App möchte eine Live-Tabelle „aktuelle hochwertige Support-Tickets" aus einem Support-Provider, gefiltert nach einem Schwellenwert, der von keiner eingebauten action offengelegt wird:
+
+```ts
+// The program's stored `code` — ordinary run-code, with one emit() call.
+const minValue = Number(params.minValue || 5000);
+
+const tickets = await providerFetchAll("acme-support", "/v1/tickets", {
+  query: { status: "open" },
+  itemsPath: "data",
+  pagination: {
+    cursorParam: "cursor",
+    nextCursorPath: "next_cursor",
+    maxPages: 10,
+  },
+});
+
+const rows = (tickets.items || [])
+  .filter((t) => Number(t.contract_value || 0) >= minValue)
+  .map((t) => ({
+    ticket_id: t.id,
+    subject: t.subject,
+    account: t.account_name,
+    contract_value: Number(t.contract_value || 0),
+    opened_at: t.created_at,
+  }));
+
+emit(rows, [
+  { name: "ticket_id", type: "string" },
+  { name: "subject", type: "string" },
+  { name: "account", type: "string" },
+  { name: "contract_value", type: "number" },
+  { name: "opened_at", type: "string" },
+]);
+```
+
+Beim Speichern:
+
+```ts
+await appAction("save-data-program", {
+  name: "high-value-open-tickets",
+  title: "High-Value Open Tickets",
+  description:
+    "Open support tickets above a configurable contract-value threshold.",
+  code: "/* the script above */",
+  defaultParams: { minValue: 5000 },
+  refreshMode: "ttl",
+  refreshTtlMs: 300_000,
+});
+```
+
+Die Antwort enthält `{ programId, rowCount, columns, sampleRows }` — der Proof-of-Done des Dry-Runs. Von dort aus führt `run-data-program({ programId, params: { minValue: 10000 } })` es für einen anderen Schwellenwert erneut aus (oder liefert den Cache), und ein Dashboard-Panel kann sich auf dieselbe Weise an `programId` binden.
+
+## Die Sandbox-Oberfläche {#sandbox-surface}
+
+Ein Datenprogramm läuft durch genau dieselbe `executeSandboxCode`-Sandbox wie `run-code` — es gibt keinen neuen Sandboxing-, Credential-, SSRF- oder Kontingent-Code für diese Primitive. Es erhält dieselben Globals (`providerFetch`, `providerFetchAll`, `providerSearchAll`, `appAction`, `webFetch`, `workspace*`-Resources-Helfer) plus zwei Ergänzungen aus einer kleinen, vom Framework injizierten Präambel:
+
+- **`params`** — ein **eingefrorenes** globales Objekt, das die Parameter für diesen Lauf enthält (`defaultParams`, zusammengeführt mit dem, was an `run-data-program` oder den Panel-Deskriptor übergeben wurde). Lesen ist in Ordnung; Mutieren wirft einen Fehler.
+- **`emit(rows, schema?)`** — rufen Sie dies **genau einmal** auf, am Ende. Ein zweiter Aufruf wirft einen Fehler. `rows` muss ein Array von einfachen Objekten sein. `schema`, sofern angegeben, ist `{ name: string, type: string }[]`; wenn weggelassen, wird es aus den ersten 50 Zeilen abgeleitet (eine Spalte ist `"json"`, wenn Zeilen im Sample beim primitiven Typ nicht übereinstimmen, andernfalls `"number"` / `"string"` / `"boolean"`). `console.log` bleibt vollständig frei für Debugging — der Runner erfasst kombiniertes stdout/stderr und entfernt beim Parsen des Ergebnisses nur die Sentinel-Zeile, die `emit()` schreibt.
+
+Bei jedem Lauf durchgesetzte Obergrenzen (nicht pro Programm konfigurierbar):
+
+| Grenze                                                    | Wert                                                                                                                                                                                         |
+| --------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| Max. emittierte Zeilen                                    | 10.000 — Zeilen darüber hinaus werden verworfen, `truncated: true`                                                                                                                           |
+| Max. emittierte Ergebnisgröße                             | 4 MiB — Zeilen werden vom Ende entfernt, um zu passen; eine einzelne Zeile über der Obergrenze ist ein harter `result_too_large`-Fehler, da es nichts gibt, das sicher gekürzt werden könnte |
+| Max. aktive (nicht archivierte) Programme pro App         | 200 — archivieren Sie ungenutzte, um Platz zu schaffen                                                                                                                                       |
+| Minimales Aktualisierungs-TTL                             | 60.000 ms                                                                                                                                                                                    |
+| Aufbewahrte Laufzeilen pro (Programm, Params, Betrachter) | 5 neueste — ältere werden bei jedem Schreibvorgang automatisch bereinigt                                                                                                                     |
+
+Kürzung ist immer explizit (`truncated: true` im Ergebnis) — nie ein stiller Verlust.
+
+## Params und Dashboard-Panel-Bindung {#params-and-panel-binding}
+
+Programme deklarieren ein optionales `paramsSchema` (JSON Schema, das akzeptierte Params beschreibt) und `defaultParams`. Ein Dashboard übernimmt die `"program"`-Panel-Quelle, indem es einen kleinen JSON-Deskriptor im Abfragefeld des Panels statt einer Abfragezeichenfolge platziert:
+
+```json
+{ "programId": "dp_a1b2c3d4e5f6", "params": { "minValue": 10000 } }
+```
+
+Das Panel rendert durch genau dieselben Chart-/Tabellenkomponenten wie jede andere Panel-Quelle — es erhält immer nur `{ rows, schema }` zurück. Ein Panel an ein Programm zu binden bedeutet nur „welches gespeicherte Programm, mit welchen Param-Überschreibungen"; es gibt keinen anderswo duplizierten dashboard-spezifischen Ausführungspfad.
+
+## Aktualisierung, TTL und Caching-Semantik {#refresh-and-caching}
+
+Jedes `(programId, paramsHash)`-Paar hat seine eigene Laufhistorie in `data_program_runs`, und `paramsHash` bezieht **den Betrachter** ein, nicht nur die Params (siehe den Sicherheitsabschnitt für den Grund). Was bei jedem Lesevorgang passiert:
+
+| Situation                                                                                      | Verhalten                                                                                                                                                                                                                                |
+| ---------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| Frischer Cache (jünger als `refreshTtlMs`, oder `refreshMode: "manual"` mit vorherigem Erfolg) | Gibt sofort zwischengespeicherte Zeilen zurück, `cacheHit: true`                                                                                                                                                                         |
+| Cache ist älter als das TTL                                                                    | Führt synchron erneut aus — ein 25s-Budget für Panel-View-Lesevorgänge, 120s für Agent-/manuelle Aufrufe — und ersetzt den Cache bei Erfolg                                                                                              |
+| `refreshMode: "manual"`                                                                        | Aktualisiert nie automatisch; nur ein explizites `forceRefresh: true` (oder eine manuelle Aktualisierungs-UI-action) führt es erneut aus                                                                                                 |
+| Noch kein Cache                                                                                | Führt synchron aus wie ein normaler erster Abruf                                                                                                                                                                                         |
+| `background: true`-Programm, kein frischer Cache                                               | Liefert sofort den letzten guten Lauf mit `stale: true` und stellt eine dauerhafte Hintergrundausführung in die Warteschlange (10-Minuten-Budget); ein späterer Aufruf finalisiert das Ergebnis, sobald die Ausführung abgeschlossen ist |
+| Hintergrundprogramm läuft noch, kein vorheriger Erfolg                                         | `background_pending`-Fehler — zeigt einen expliziten Zustand „läuft noch" an, nie ein leeres Ergebnis                                                                                                                                    |
+| Ausführung schlägt fehl (Timeout, Sandbox-Fehler, falsche `emit()`-Form)                       | Ein strukturierter `{ code, message }`-Fehler; wenn ein vorheriger Erfolg existiert, wird er als `lastGoodRun` angehängt, sodass ein Panel veraltete Daten anzeigen kann, statt leer zu bleiben                                          |
+| Programm wurde archiviert (soft-deleted über `delete-data-program`)                            | Expliziter `archived`-Fehler — nie ein stilles leeres Panel                                                                                                                                                                              |
+
+Greifen Sie nur für Programme zu `background: true`, die routinemäßig das Vordergrund-Timeout überschreiten — große Multi-Provider-Joins, tiefe Paginierung. Alles andere sollte im Vordergrund bleiben: Es ist einfacher zu verstehen und liefert schneller frische Daten.
+
+### Warum der Cache pro Betrachter gescopet ist {#per-viewer-cache}
+
+`providerFetch` innerhalb eines Programms löst die Authentifizierung anhand des **eigenen Anfragekontexts des aufrufenden Betrachters** auf — nie des Programmautors. Das gilt unabhängig davon, ob der Aufruf vom Agenten, einem `run-data-program`-Aufruf oder einem von einem Teammitglied angesehenen Dashboard-Panel kommt. Zwei verschiedene Betrachter, die dasselbe Programm mit denselben Params ausführen, können legitim zwei unterschiedliche Ergebnisse erhalten: Einer hat einen konfigurierten HubSpot-Schlüssel und der andere nicht, oder die Provider-Berechtigungen auf Zeilenebene unterscheiden sich pro Person.
+
+Deshalb bezieht `hashDataProgramParams` die Identität des Aufrufers zusätzlich zu den kanonisierten Params in den Cache-Schlüssel ein. Das ist am wichtigsten für **geteilte Dashboards**: Wäre der Cache nur nach Params geschlüsselt, würde die erste Person, die ein Panel ansieht, still bestimmen, was jeder andere Betrachter sieht — einschließlich eines Betrachters ohne die Credentials, die dieses zwischengespeicherte Ergebnis erzeugt haben. Die Scopierung pro Betrachter bedeutet, dass ein Teammitglied ohne Credential seinen eigenen Auth-Fehler auf diesem Panel sieht, nicht die Daten einer anderen Person.
+
+## Sicherheitsmodell {#security}
+
+<Callout id="doc-block-dp-security" tone="success">
+
+**Rohe Provider-Tokens erreichen nie das Modell oder den Browser.** Das Einzige, was die Sandbox jemals verlässt, ist das `{ rows, schema }`, das ein `emit()`-Aufruf erzeugt — dieselbe Vertrauensgrenze wie bei jeder anderen run-code-Ausführung und jeder anderen Dashboard-Panel-Quelle.
+
+</Callout>
+
+- **Nur serverseitig.** Der Code eines Datenprogramms wird ausschließlich innerhalb von `executeSandboxCode` auf dem Server ausgeführt. Weder der gespeicherte Quellcode noch irgendein Credential, das er berührt, wird an den Browser oder das Modell gesendet — nur die emittierten Zeilen/Schema und kompakte Laufmetadaten (Zeilenanzahl, Spalten, Beispielzeilen) werden es.
+- **Credentials sind immer die des aufrufenden Betrachters, nie die des ursprünglichen Autors des Programms.** Siehe [Aktualisierung, TTL und Caching-Semantik](#per-viewer-cache) oben, warum dies auch den Cache-Schlüssel bestimmt.
+- **`allowPublic: false` ist eine feste Invariante, kein Standardwert.** Datenprogramme registrieren sich bei der Sharing-Registry auf dieselbe Weise wie [Erweiterungen](/docs/extensions#security), mit deaktivierter öffentlicher Freigabe. Ein öffentliches Programm würde jedem authentifizierten Benutzer erlauben, beliebigen gespeicherten Code unter seinem eigenen Token auszuführen — das Teilen eines Programms ist auf Ihre Organisation beschränkt und bedeutet immer nur „Teammitglieder können das zwischengespeicherte Ergebnis ansehen und erneute Läufe auslösen", nie „das allgemeine Internet kann dies ausführen."
+- **Mutierende und ausführende actions sind nicht tool-aufrufbar von der sandboxed Extension-/Iframe-Bridge aus.** `save-data-program`, `preview-data-program`, `run-data-program` und `delete-data-program` sind `toolCallable: false` — nur der Agent oder ein serverseitiger Lesepfad kann sie aufrufen, nie ein Extension-Iframe unter der Sitzung des Öffners. `list-data-programs` und `get-data-program` sind schreibgeschützt und über dieselben Sharing-Helfer wie jede andere ownable Ressource gescopet.
+- **Programme sind auf die App beschränkt, die sie erstellt hat.** Die Übergabe von `appId` an eine Suche bedeutet, dass ein in einer App erstelltes Programm in einer Shared-Database-Bereitstellung nicht vom Agent-Chat einer anderen App aus ausführbar ist, selbst für einen Aufrufer, der sonst Zugriff auf Zeilenebene (Owner/Org/Share) darauf hätte.
+- **Binden Sie sich nur an ein Programm oder sehen Sie es nur an, dem Sie vertrauen.** Da die Ausführung immer die eigenen Credentials des Betrachters verwendet, ist das Ansehen des Ergebnisses eines geteilten Programms genau wie das Öffnen der Erweiterung einer anderen Person — vertrauen Sie dem Code, nicht nur der Zugriffsberechtigung.
+
+## Das ausgearbeitete Risk-Meeting-Beispiel {#risk-meeting-example}
+
+Die Analytics-Vorlage liefert eine konkrete, lauffähige Fallstudie: Die `ensure-risk-meeting-dashboard`-action installiert idempotent zwei Datenprogramme plus ein Zwei-Panel-„Risk Meeting"-Dashboard und demonstriert drei Dinge, die eine fest codierte action nicht für jeden Kunden antizipieren kann.
+
+<FileTree
+  id="doc-block-dp-risk-meeting-files"
+  title={"Risk-Meeting-Installer"}
+  entries={[
+    {
+      path: "templates/analytics/actions/ensure-risk-meeting-dashboard.ts",
+      note: "idempotente action: aktualisiert beide Programme nach stabilem Namen, dann das Dashboard nach id",
+    },
+    {
+      path: "templates/analytics/seeds/data-programs/risk-meeting-cohort.js",
+      note: "gespeicherte Programm-Payload — reiner JS-Text, keine Build-Quelldatei",
+    },
+    {
+      path: "templates/analytics/seeds/data-programs/risk-meeting-pylon-early-warning.js",
+      note: "das ergänzende Frühwarnprogramm",
+    },
+  ]}
+/>
+
+**`risk-meeting-cohort.js`** — sucht nach einer konfigurierbaren Kohorte von CRM-Deals anhand einer willkürlichen `risk_status`-Eigenschaft (eine IN-Suche über benutzerdefinierte Werte, die eine vorgefertigte action nicht antizipieren kann), löst das Unternehmen jedes Deals über eine gebündelte Zuordnungssuche auf, löst die Domain jedes Unternehmens auf, ruft die Kontostimmung eines zweiten, nicht verwandten Providers ab und verknüpft die beiden nach Domain:
+
+```js
+// params: { riskStatuses?: string[], enterpriseOnly?: boolean }
+const riskStatuses = params.riskStatuses?.length
+  ? params.riskStatuses
+  : ["On the Radar", "Churn Risk", "Confirmed Churn", "No Save Attempted"];
+
+// 1. Arbitrary property IN-search — not expressible through a canned filter.
+const dealSearch = await providerFetchAll("crm-provider", "/deals/search", {
+  method: "POST",
+  body: {
+    filterGroups: [
+      {
+        filters: [
+          { propertyName: "risk_status", operator: "IN", values: riskStatuses },
+        ],
+      },
+    ],
+  },
+  itemsPath: "results",
+  pagination: {
+    cursorBodyPath: "after",
+    nextCursorPath: "paging.next.after",
+    maxPages: 20,
+  },
+});
+
+// 2-3. Batched deal -> company -> domain resolution (elided here; see the
+// real seed file for the full batching helper).
+
+// 4. A second, unrelated provider — zero bespoke glue action required.
+const accounts = await providerFetchAll("support-provider", "/accounts", {
+  itemsPath: "data",
+  pagination: {
+    cursorParam: "cursor",
+    nextCursorPath: "pagination.cursor",
+    maxPages: 20,
+  },
+});
+
+// 5. Join + emit.
+const rows = dealSearch.items.map((deal) => ({
+  deal_id: deal.id,
+  risk_status: deal.properties.risk_status,
+  arr: Number(deal.properties.total_contract_value || 0),
+  // ...domain lookup + sentiment join...
+}));
+
+emit(rows, [
+  { name: "deal_id", type: "string" },
+  { name: "risk_status", type: "string" },
+  { name: "arr", type: "number" },
+]);
+```
+
+**`risk-meeting-pylon-early-warning.js`** — die ergänzende Ansicht: Konten, die bereits durch Support-Stimmung als gefährdet markiert wurden und **noch nicht** in der obigen CRM-Kohorte aufgetaucht sind. Diese Lücke — Support-Signal, das dem CRM-Signal voraus ist — erfordert das Ausschließen der Kohorte eines Providers von der eines anderen, genau die Art von anbieterübergreifender Mengenlogik, die keine einzelne Anbieter-action ausdrücken kann.
+
+Beide Programme werden von `ensure-risk-meeting-dashboard` installiert und aktuell gehalten, welches:
+
+- Jedes Programm nach seinem stabilen `name` aktualisiert, sodass ein erneutes Ausführen des Installers dieselben Zeilen aktualisiert, statt sie zu duplizieren.
+- Keine CRM-/Support-Credentials zur Installationszeit benötigt — die Provider-Authentifizierung wird pro Betrachter erst aufgelöst, wenn ein Panel tatsächlich gerendert oder `run-data-program` aufgerufen wird, konsistent mit der obigen Cache-Scopierung pro Betrachter.
+- Ein Zwei-Panel-Dashboard erstellt, dessen Panels `source: "program"` verwenden, gebunden an die id jedes Programms.
+
+Siehe die `data-programs`-Skill für die vollständig kommentierte Quelle.
+
+## Wie andere Apps die Panel-Quelle übernehmen {#adopting-the-panel-source}
+
+Die `"program"`-Dashboard-Panel-Quelle ist eine Anwendung der Primitive, vollständig implementiert in der eigenen Panel-Abfrageschicht der Host-App — nichts Dashboard-spezifisches ist in `@agent-native/core/data-programs` selbst eingebaut. Die Implementierung der Analytics-Vorlage ist eine nützliche Referenz für die eigene Verkabelung:
+
+- Die `sql`-Spalte des Panels enthält einen kleinen JSON-Deskriptor — `{ programId, params? }` — statt einer Abfragezeichenfolge.
+- Das Rendern eines Panels ruft `runDataProgram` mit `triggeredBy: "panel_view"` und der Identität des aktuellen Betrachters auf, sodass der Cache pro Betrachter und die Credential-Auflösung automatisch gelten.
+- Bei Erfolg erhält das Panel `{ rows, schema }` — dieselbe Form, die jede andere Panel-Quelle zurückgibt, sodass es unverändert durch die vorhandenen Chart-/Tabellenkomponenten fließt.
+- Bei einem Fehler wird ein `lastGoodRun` einem defekten Panel vorgezogen, wann immer eines existiert; nur wenn kein vorheriger Erfolg existiert, zeigt das Panel einen strukturierten Fehler an (mit freundlicherer Formulierung für gängige Codes wie `access_denied`, `archived` und `background_pending`).
+
+Jede App kann dieselbe Anwendung für ihre eigenen Dashboards/Tabellen implementieren: Rufen Sie `run-data-program` auf (oder `runDataProgram` direkt, wenn Sie sich im selben Serverprozess befinden) von Ihrem eigenen Lesepfad aus, und übergeben Sie die zurückgegebenen `rows`/`schema` an Ihre eigenen Rendering-Komponenten.
+
+## Verwandte Dokumentation {#related}
+
+- [Erweiterungen](/docs/extensions) — die sandboxed Mini-App-Primitive, mit der Datenprogramme ein Sicherheitsmodell und Sharing-Modell teilen, aber mit einer eigenen UI.
+- [Actions](/docs/actions) — die `run-code`-Konventionen und Sandbox-Globals (`providerFetch`, `appAction`, usw.), auf denen Datenprogramme aufbauen.
+- [Sharing & Datenschutz](/docs/sharing) — das organisationsinterne, nie öffentliche Sharing-Modell, das Datenprogramme verwenden.
+- [Sicherheit](/docs/security) — die Credential-Handling- und Zugriffs-Scoping-Invarianten des Frameworks.

package/docs/content/locales/de-DE/deployment.mdx

@@ -384,24 +384,23 @@ Rotieren Sie sie, indem Sie die Umgebungsvariable auf jeder Instanz ersetzen und
 ## Production Agent Tools {#production-agent-tools}
 
 Produktionsagenten erhalten die registrierten actions der App sowie Framework-Tools von
-das Agenten-Chat-Plugin. Datenbankschreibvorgänge sind standardmäßig aktiviert, da Raw-DB
-Tools sind auf den authentifizierten Benutzer/die authentifizierte Organisation beschränkt, aber App-Besitzer können den Bereich einschränken
-Oberfläche, wenn eine Bereitstellung eigenwilliger sein sollte:
+das Agenten-Chat-Plugin. SQL-Inspektion ist standardmäßig aktiviert; Schreibvorgänge
+laufen über typisierte App-Actions, sofern die App nicht ausdrücklich rohe Schreibwerkzeuge aktiviert:
 
 ```ts
 // server/plugins/agent-chat.ts
 export default createAgentChatPlugin({
-  // Default: "write" (also true)
+  // Default: "read"
   databaseTools: "read", // "write" | "read" | "off"
   extensionTools: false,
 });
 ```
 
-- `databaseTools: "write"` – Standard. Register `db-schema`, `db-query`,
-  `db-exec` und `db-patch`. Schreibvorgänge sind auf den aktuellen Benutzer/die aktuelle Organisation und
-  Schemaänderungen werden blockiert.
-- `databaseTools: "read"` – registriert nur `db-schema` und `db-query`; Agenten
-  Daten mit SQL prüfen, für Schreibvorgänge muss jedoch die typisierte App-Actions verwendet werden.
+- `databaseTools: "read"` – Standard. Registriert nur `db-schema` und `db-query`;
+  Agenten prüfen Daten mit SQL, müssen für Schreibvorgänge aber typisierte App-Actions verwenden.
+- `databaseTools: "write"` oder `true` – registriert zusätzlich `db-exec` und
+  `db-patch` für bewusste rohe SQL-Wartung. Schreibvorgänge sind auf den
+  aktuellen Benutzer/die aktuelle Organisation beschränkt; Schemaänderungen werden blockiert.
 - `databaseTools: "off"` oder `false` – entfernt Rohdatenbank-Tools aus
   Agentenoberfläche, sodass die actions der App der einzige Datenzugriffspfad sind.
 - `extensionTools: false` – entfernt Framework-Erweiterungsverwaltung actions und