Glossar

Kernentitäten

Agent: Ein KI-Arbeiter mit Identität, Rolle, Skills und einem Adapter. Gehört zu genau einem Arbeitsbereich. Der zentrale Akteur im System.

Adapter: Der Runner, der einen Agenten-Turn ausführt. Zwei werden ausgeliefert: Control Center (built-in), der prozessinterne Harness, der mit den Modellanbietern spricht, und Claude Code über claude -p. Cursor, Codex, Anthropic, OpenAI und die übrigen sind Anbieter auf dem eingebauten Adapter, keine eigenen CLIs. Siehe Adapter und Modelle verwalten.

Arbeitsbereich: Der oberste Isolationsmandant. Fasst Agenten, Repos, Bereiche, Tickets, Gedächtnis und Pipelines zusammen. Die Isolation ist strukturell, nicht bloß Konvention: jeder Arbeitsbereich hat seine eigene SQLite-Datei (<dataDir>/<workspaceId>/workspace.db), deshalb kompiliert ein Lesen über Arbeitsbereiche hinweg nicht. Jede Route in der App beginnt mit /workspaces/:workspaceId. Siehe die Routenkarte.

Code-Host: Ein Code-Host, GitHub, GitLab oder Bitbucket Cloud. Der Code-Host ist eine Eigenschaft jedes Repos, beim Registrieren vom Remote origin gelesen, und er wählt den API-Adapter und die Zugangsdaten dieses Repos. Ein Arbeitsbereich kann Repos auf allen dreien halten; Oberflächen, die zusammenführen (der Posteingang, die PR-Warteschlange), fragen jeden vertretenen Code-Host ab, führen die Ergebnisse zusammen und isolieren Ausfälle, sodass ein unerreichbarer Code-Host die anderen nie leert. Code-Hosts unterscheiden sich darin, was sie können. Die Tabelle der Fähigkeiten steht in Einen Code-Host verbinden.

Repo: Ein Git-Repository, das in einem Arbeitsbereich registriert ist. An den Arbeitsbereich gebunden: derselbe Checkout in zwei Arbeitsbereichen sind zwei unabhängige Zeilen mit zwei IDs; die Identität eines Repos über Arbeitsbereiche hinweg ist der Dateisystempfad, nie die ID. Die Registrierung verlangt einen Git-Arbeitsbaum, dessen Remote origin auf einen unterstützten Code-Host zeigt. Jedes Repo trägt diesen Code-Host (github / gitlab / bitbucket), der den API-Adapter und die Zugangsdaten dafür wählt.

Isoliertes Repo: Ein arbeitsbereichsbezogener Worktree eines registrierten Repos. Copy-on-Write über rift, wo dieses Native ausgeliefert wird; git worktree unter Windows. Bereitgestellt je Bereich: jede Unterhaltung in diesem Bereich teilt einen Checkout, deshalb verändern Agenten die Quelle nie.

Bereich: Ein arbeitsbereichsbezogener Behälter für die Zusammenarbeit, mit menschlichen und Agenten-Teilnehmern, einem gespeicherten Mode, einem Bereitstellungsstatus und einem SpaceKind (topic / agentPeer / system / pr / slack), der entscheidet, wie er gruppiert, stummgeschaltet, mit einem Badge versehen und aufgeräumt wird. Ihm gehören die isolierten Worktrees, die seine Unterhaltungen teilen (Copy-on-Write über rift; git worktree unter Windows).

Unterhaltung: Ein Nachrichtenstrom in einem Bereich, mit eigener ID, eigenem Verlauf und eigenem Kontext der Agenten-Ausführung. Unterhaltungen in einem Bereich sind gleichrangig: es gibt keinen primären und keinen „Haupt“-Strom. Jede öffnet sich als Editor-Tab; der Ungelesen-Zustand eines Bereichs fasst alle zusammen.

Thread: Eine Unterhaltung, deren anchorMessageId gesetzt ist: verankert an einer Nachricht einer benachbarten Unterhaltung im selben Bereich, mit einem frischen Agentenkontext, den diese Ankernachricht setzt. Eine Ebene tief: Threads verankern sich nie an Threads.

Ticket: Das Aggregat der Arbeitseinheit. Anbieterneutral: standardmäßig local, mit Sync-Adaptern für Linear, GitHub Issues, Jira Cloud und ClickUp, obwohl keine Oberfläche in der App eine Sync-Verbindung anlegt. Kann Hierarchie, Verknüpfungen und Delegation. Die Zuweisung an einen Agenten schreibt das Eigentum fest und stößt nichts an; die Zuweisung an ein Team ist die Ausnahme (TeamRoutingService startet den Leiter).

Pipeline: Ein Workflow auf einem DAG, der Schritte verkettet (Agenten-Ausführung, Skripte, Bedingungen). Vorlagen definieren ihn; ausgeführt wird er als Läufe.

Wertobjekte

AgentRole: Aufgezählte Rolle (CEO, coder, reviewer, QA, designer, security, devops, PM, general). Bestimmt Persona, Gedächtniszugriff und Hierarchie.

AgentSkills: Groß- und kleinschreibungsunabhängige Menge von Skill-Kennungen, die beim Start einer Ausführung passenden Kontext in die Prompts schreibt.

Skill-Quelle: Ein GitHub-Repository, das je Arbeitsbereich als Skill-Katalog registriert ist. Von Konstruktion an unvertrauenswürdig: die Metadaten des Repositorys dienen nur der Anzeige, und jede Installation durchläuft das im Fehlerfall geschlossene Scan-Tor, bevor irgendein Inhalt auf die Platte oder in einen Prompt gelangt. Siehe Skills installieren und verwalten.

skills-lock.json: Das Manifest der installierten Skills je Arbeitsbereich: je Skill das Quell-Repository, der Pfad im Repo, der Commit, an den er geheftet ist, und ein zusammengefasster Inhalts-Hash. Installationen, Aktualisierungen und Deinstallationen halten es aktuell; verify_skills prüft es gegen die Platte.

Gateway für Agentenläufe: Ein Loopback-Endpunkt auf cc_server, der die Aktionsrichtlinie in die Sandbox eines Agenten trägt. Jeder GitHub-Push eines Agenten wird dorthin umgeleitet, gegen die Regel Zu einem Remote pushen geprüft und mit einem Schreib-Token weitergeleitet, das der Agent nie besitzt; die Bash-Befehle von Claude Code werden über einen Hook am selben Endpunkt geprüft. Siehe Sandbox und Sicherheit.

Modus: chat, plan, review oder orchestrate. Gespeichert je Bereich, deshalb kann ein Agent in verschiedenen Bereichen in verschiedenen Modi sein; jede Unterhaltung eines Bereichs teilt ihn. Steuert den System-Prompt, die Schreibregeln der Sandbox und die Zulassungsliste der MCP-Tools. Der Composer bietet nur chat, plan und orchestrate; chat heißt „Agent“.

SandboxBackend: microvm (eine gekapselte VM, das einzige Backend mit Kernel-Grenze, für interaktive Terminals), native (Seatbelt unter macOS, bubblewrap unter Linux und WSL2) oder none. Einmal beim Start geprüft; native greift bei der Agenten-Ausführung, wenn es verfügbar ist, und umhüllt die CLI von Claude Code und das Harness-Tool bash. Windows hat kein natives Backend, und Linux braucht bwrap plus socat, deshalb laufen Läufe dort ohne Umhüllung; --sandbox off schaltet bewusst ab.

Rig: Eine Wegwerfmaschine, die ein Agent in Echtzeit steuert: ein gekapselter Browser oder Linux-Desktop, ein vom Host verwalteter Android-Emulator oder iOS-Simulator, oder ein gekapseltes Terminal. Live beobachtet über eine eigene Spur in voller Auflösung, mit serverseitig erzwungener Übernahme. An eine Unterhaltung gebunden, sodass der Tab des Menschen und die Aufrufe browser_use / computer_use / mobile_use / ios_use des Agenten eine Standardmaschine ansprechen. Siehe Rigs und Kapseln.

Kapsel: Die stärkere Grenze eines Rigs auf einer VM: eine Kernel-Grenze, eine Wegwerf-Overlay-Platte, ein Netz-Tor, das standardmäßig verweigert, und ein Zugangsdaten-Broker. Android- und iOS-Rigs sind Wegwerfmaschinen, nutzen aber vom Host verwaltetes Netz und beanspruchen diese Grenze nicht. Jedes Rig zu steuern nutzt die Schutzregel-Klasse enclosureControl.

RunCost: Token- und Kostenaufstellung (Eingabe-Token, Ausgabe-Token, geschätzte Kosten in Cent) für einen einzelnen Agentenlauf.

WakeReason: Warum ein Agent gestartet wurde. Sechs Werte: Nutzernachricht, Ticketzuweisung, erneute Ausführung durch die Wiederherstellung nach einem Fehler, abgeschlossenes untergeordnetes Ticket, geplanter Folge-Heartbeat und Pipeline-Schritt.

Ports

SandboxPort: Steuert den Lebenszyklus der Sandbox (probe, launch, events, exec, destroy).

CredentialBrokerPort: Stellt begrenzte Zugangsdaten für den Start der Sandbox aus — nur Lesen für die Umgebung eines Agenten, Schreiben nur für den Push-Pfad auf dem Server — und widerruft sie beim Aufräumen.

GitRepoInspectorPort: Liest Metadaten (Owner, Repo, Branch) aus einem lokalen Git-Repo-Pfad.

EmbeddingPort: Erzeugt Text-Embedding-Vektoren mit Einheitsnorm für die semantische Suche.

NotificationPort: Zeigt native Desktop-Benachrichtigungen und beachtet die Sperre nach Kategorie und Route.

TicketProviderPort: Anbieterneutrale Grenze zu einem Ticket-Backend (create, get, list, update, transition, assign).

PipelineEnginePort: Startet einen Pipeline-Lauf aus einer Vorlage und entkoppelt die Aufrufer von der konkreten Engine.

Domänendienste

AgentDispatchService: Startet Agentenläufe: stellt isolierte Repos bereit, baut Prompts, legt Laufprotokolle an und liefert Live-Ereignisströme.

TicketWorkflowService: Reine Domänen-Engine für den Ticket-Lebenszyklus, mit einem Engpass für Mutationen unter optimistischer Nebenläufigkeit und mit Durchsetzung der Arbeitsbereichs-Isolation. Sein Übergangsgraph bindet nur Agenten und Automatisierung; Änderungen aus der Oberfläche, die ein Mensch anstößt, übergeben force: true und umgehen ihn. Einen Ticket-Dispatcher für einen Agenten als Empfänger gibt es nicht: AgentDispatchService besitzt die Ausführung, und ein Ticket einem Agenten zuzuweisen startet keinen Lauf. Ein Ticket einem Team zuzuweisen ist die Ausnahme (TeamRoutingService startet den Leiter).

PipelineEngine: Orchestriert die Ausführung eines Laufs: startet Läufe, plant Schritte, speichert den Zustand, behandelt Router, Joins und Continue-on-fail und nimmt laufende Läufe nach einem Neustart wieder auf.

PipelineTriggerDispatcher: Abonniert Domain-Ereignisse und startet für eingeschaltete Trigger passende Pipeline-Läufe von selbst.

MemoryAccessPolicy: Löst die Gedächtnisrechte der Agentenrolle auf Domänen auf und setzt sie durch.

HarnessCostCalculator: Bepreist den Tokenverbrauch des eingebauten Harness zu einem RunCost aus dem Katalog models.dev. Die Ausführung schreibt diese Aufstellung ins Laufprotokoll.

BudgetEnforcementService: Rechnet die monatlichen Ausgaben je Agent und eine Sperre vor der Ausführung (checkInvocationBlock). Diese Sperre fragen nur die Reconciler der Wiederherstellung ab (OrphanRunReaper, StrandedTicketReconciler), nie eine gewöhnliche Ausführung durch einen Menschen oder einen Agenten.

BudgetGovernanceService: Bewertet die monatlichen Ausgaben je Agent nach jedem Lauf: eine weiche Schwelle schreibt einen Warnvorfall; Erschöpfung schreibt einen harten Vorfall und setzt den Lebenszyklus des Agenten auf paused.

Ereignisse

DomainEventBus: Prozessinterner Broadcast-Bus nach Publish/Subscribe für die Kommunikation über Features hinweg. Ereignisse sind typisiert; Abonnenten lesen Ströme on<T>().

DomainEvent: Basisschnittstelle. Jedes Ereignis hat occurredAt. Zentrale Kategorien: Arbeitsbereich/Agent, PR/Review, Nachrichten, Tickets, Pipeline, Besprechungen/Kalender, Identität, Rigs, Observability.

Besprechungen und Kalender

Besprechung: Eine lokal aufgezeichnete, transkribierte Besprechung. Nimmt Mikrofon und Systemton auf, transkribiert auf dem Gerät mit einem wählbaren ASR-Modell (standardmäßig Parakeet TDT v3; Alternativen sind Parakeet TDT v2, Whisper large-v3-turbo und Whisper base.en), trennt Sprecher und fasst das in Notizen, Aufgaben und Entscheidungen zusammen. Das gewählte ASR-Modell wird beim Start zwangsinstalliert, und die Aufnahme-Funktionen leuchten nach einem Neustart auf. An den Arbeitsbereich gebunden; bleibt auf dem Rechner.

MeetingSegment: Ein transkribiertes Audiofenster, mit Sprecher-Markierung (me/them), einem Diarisierungs-Label und Offsets in Millisekunden.

MeetingActionItem / MeetingDecision: Strukturierte Ergebnisse, die die Zusammenfassungs-Pipeline zieht und als eigene Zeilen speichert. Aufgaben können auf ein Ticket verweisen.

CalendarEvent: Ein synchronisierter Google-Calendar-Eintrag, gebunden an einen Arbeitsbereich und ein verbundenes Konto. Etwas anderes als eine Besprechung: ein Termin ist eine geplante Verpflichtung, eine Besprechung ist eine aufgezeichnete Sitzung. Eins zu eins verknüpft über einen MeetingCalendarLink.

CalendarAccount: Ein verbundenes Google-Konto, je Arbeitsbereich und E-Mail. OAuth-Refresh-Tokens liegen serverseitig als Schlüssel google_* in <dataDir>/secrets.json und erreichen nie einen Client; der Device-Code-Ablauf schließt auf dem Server ab. Ein Flag authExpiredAt steuert das Banner Erneut verbinden.

Architekturbegriffe

Clean Architecture: Abhängigkeitsregel: Presentation → Application/Providers → Domain ← Infrastructure. Die Domäne importiert keine Infrastruktur.

Ports und Adapter: Die Domäne definiert abstrakte Schnittstellen (Ports); die Infrastruktur liefert konkrete Implementierungen (Adapter). Die Kompositionswurzel bindet sie.

Gemeinsamer Kern: Entitäten, Wertobjekte, Ports und Dienste unter core/domain/, geteilt über 3 oder mehr Features.

Nach Features: Der Code ist nach Fachdomäne geordnet (Agenten, Pipelines, Nachrichten), nicht nach technischer Schicht.

Multiplayer, Identität und Tempo

Prinzipal: Ein versiegelter Wert, der Menschen und Agenten zur einen Akteur-Abstraktion macht: UserPrincipal(userId) oder AgentPrincipal(agentId). Jede Nachricht, jedes Ticket, jedes Review, jeder Plan und jedes Laufprotokoll wird über einen Prinzipal zugeschrieben.

Benutzer: Eine menschliche Identität, gespeichert in global.db und deshalb global über alle Arbeitsbereiche. Der Prinzipal, der einen Arbeitsbereich anlegt, wird sein Eigentümer, in derselben Operation eingetragen auf Workspace.ownerUserId mit einer Mitgliedszeile der Rolle Eigentümer. Andere treten per Einladung oder SSO bei.

WorkspaceMember / WorkspaceRole: Eine Mitgliedszeile, die einen Benutzer an einen Arbeitsbereich in einer Rolle bindet (owner / admin / member / viewer / guest: Eigentümer, Admin, Mitglied, Betrachter, Gast). Die Mitgliedschaft ist die Zugriffsgrenze, nicht der Kopplungsschlüssel. Freigaben je Repo halten die Mitgliedschaft innerhalb der Rechte des Code-Hosts.

ParticipantPresence: Flüchtiges Gewahrsein für einen Prinzipal (Status, Locus, Cursor, Tippen, Live-Status eines Agenten und laufende Kosten). Nie gespeichert; der Server sammelt es; vor dem Fan-out nach der Repo-Freigabe gefiltert.

Folgemodus: Klicke einen Avatar an und fahre seinen Viewport mit, bis du selbst handelst, dann löst du dich. Gilt für Menschen und für Agenten („einem Agenten bei der Arbeit zusehen“).

Autonomieregler: Ein Regler je Bereich und je Agent, Nur vorschlagen / Mit Genehmigung handeln / Frei handeln (propose-only / act-with-approval / act-freely), umgesetzt als benanntes Profil über dem Speicher der Aktions-Schutzregeln.

ActionClass: Eine geschlossene Menge von 13 Wirkungsklassen (fileDelete, gitPush, prCreate, networkEgress, processSpawn, enclosureControl, …). Jedes verändernde Werkzeug nennt seine Klassen; die Schutzregel-Engine löst allow / prompt / deny je Geltungsbereich auf (Bereich > Agent > Arbeitsbereich > Modus-Voreinstellung > eingebauter Standard).

WriteLedger / Idempotenzschlüssel: Jede Mutation trägt einen vom Client erzeugten Idempotenzschlüssel (UUIDv7, je logischer Aktion). Das arbeitsbereichsbezogene Ledger entfernt Dubletten, bevor der Handler läuft; eine Wiederholung liefert das bytegleiche ursprüngliche Ergebnis. Macht Wiederverbinden und mehrere Clients von Konstruktion an sicher.

Posteingang: Eine Warteschlange über alle Säulen mit einer strengen Regel: ein Eintrag erscheint nur, wenn er etwas blockiert (einen Agenten, einen Merge, eine Synchronisierung) oder dich ausdrücklich anfordert.

Plan Studio: Die interaktive Planungsfläche: bearbeitbare Pläne als typisierter DAG, mit Kosten, Zeit und Risiko je Schritt und teilweiser Freigabe.

Review-Compute: Serverseitiges Review-Compute für einen PR (aus dem Graphen abgeleitete Kohorten, typisierte Diagramme, visuelle Diffs, Diffs des API-Vertrags, Gates über mehrere Achsen), ausgeliefert über review_studio.* und in den Tab Review eingerechnet.

Review-Bereich: Der eine tragende Bereich eines PR (Modus review, Art pr), idempotent angelegt und über eine ReviewSpaceAssociation mit dem PR verknüpft. Jeder Reviewer legt Befunde darin ab, und genau das macht sie vergleichbar; sein isolierter Worktree hat den PR an seinem Head ausgecheckt.

Review-Knoten: Die strukturierte Einheit eines KI-Review-Befunds: Art (bug, suggestion, recommendation, question, ticket), Priorität P0–P3, ein Triage-Tripel aus Kategorie, Schwere und Aufwand, ein Anker auf Datei und Zeile, ein optionaler vorgeschlagener Fix und ein Konfidenzwert. Abgelegt mit add_review_node; das Verdikt wird aus Knoten gerechnet, nicht aus Prosa.

Consensus-ready: Der Status eines Review-Knotens, den nur die Bestätigung eines Peer-Reviewers erreicht. Ein Agent kann den eigenen Befund nicht bestätigen. Die Schaltfläche Auf GitHub veröffentlichen auf dem Tab Review sendet jeden verbleibenden offenen Befund (selection: all_open); das MCP-Tool publish_review_to_github bleibt standardmäßig bei nur von einem Peer bestätigten Befunden.

Review-Stufe: Richtlinie des Arbeitsbereichs (light, balanced, thorough: Leicht, Ausgewogen, Gründlich), die einstellt, welche Reviewer losgeschickt werden (nur Engineer; +qa+architect; +security+perf) und wo Befunde unter der Schwelle erscheinen. Löscht nie einen Befund.

Review-Achse: Eine von fünf Wertungsspuren je Review: correctness, security und testGap aus den Befunden der Reviewer; visual und apiContract deterministisch. Gegatete Achsen gehen ins Verdikt ein und können es nur strenger machen. Ein Gate partial oder unavailable hält das Verdikt an, statt es durchzulassen.

Review-Verdikt: ship, hold oder block. Jeder Befund P0 mit einer Konfidenz ≥ 0,7 ergibt Block; jedes andere P0 oder jedes P1 ergibt Hold; sonst Ship. Eine gegatete Achse, die fehlschlägt, erzwingt Block und lässt sich von Befunden nicht überstimmen.

Fleet und Evals

cc_worker: Ein Headless-Binary in reinem Dart, das die Fleet ausführt. Koppelt sich an einen cc_server, meldet die Fähigkeiten seines Hosts, holt befristet zugewiesene Jobs ab, führt sie aus und streamt Prozessereignisse zurück. Hält keinen dauerhaften Zustand: ein maßgeblicher Server, N dumme Glieder.

JobSpec: Die typisierte Spezifikation für alles Ausführbare (Agentenlauf, Pipeline-Schritt, Code-Index, Golden-Render, Benchmark, Eval-Batch).

Eval-Suite: Eine an den Arbeitsbereich gebundene Definition einer Auswertung (Prompt, Zielagent und Modus, Grader). Fünf Starter werden beim Anlegen eines Arbeitsbereichs gesetzt; Observability → Qualität listet sie.

Bereitstellung und Clients

Thin-Client-Architektur: Kein Client öffnet die Datenbank; ein Headless-Prozess cc_server besitzt die Daten und liefert sie über WebSocket-RPC. Jeder Client (Desktop, Web, Telefon) zeichnet über diese eine RPC-Verbindung.

cc_server: Das Headless-Server-Binary (reines Dart, ohne Flutter-Engine). Besitzt die Drift/SQLite-Datenbank, liefert Repo-RPC über WebSocket und führt die Hintergrunddienste (Pipelines, MCP, Reconciler).

ServerConnectionMode: Wie der Desktop seinen Server erreicht: local (startet einen cc_server auf diesem Rechner, das ist die Vorgabe) oder remote (wählt einen anderswo an). Der Web-Client ist immer remote.

RemoteRpcClient: Der transportunabhängige JSON-RPC-Client, mit dem jeder Thin Client mit seinem Server spricht, über WSS, Loopback oder das vermittelte Relay.

Arbeitsbereich je Aufruf: Der Server ist zustandslos. Es gibt keine Bindung des Arbeitsbereichs an die Sitzung, deshalb teilen mehrere Clients auf einem Server nie einen „aktuellen Arbeitsbereich“. Jedes arbeitsbereichsbezogene repo/call und sub/subscribe muss workspace_id in seinen Argumenten tragen; eine fehlende oder nicht registrierte ID wird abgelehnt, bevor irgendeine Datenbank aufgeht. Der Zugriff hängt danach an Mitgliedschaft und Rolle im Arbeitsbereich, nicht an der Sitzung.

cc_remote: Der schlanke Client fürs Telefon, eine Flutter-Web-PWA, die die Fleet über das vermittelte Relay fernsteuert, mit einer Tool-Richtlinie, die standardmäßig verweigert.

cc_signaling_server: Ein zustandsloser WebSocket-Relay-Broker, der Räume hostet, die nur per Einladung offen sind. Ein dummes Relay, das nur Ende-zu-Ende versiegelte Frames weiterleitet, keine App-Daten hält und den Kopplungs-PSK nie sieht.