Verklarende woordenlijst
Kernentiteiten
Sectie getiteld “Kernentiteiten”Agent: Een AI-medewerker met een identiteit, rol, skills en een adapter. Hoort bij precies één werkruimte. De primaire actor in het systeem.
Adapter: De runner die een agentturn uitvoert. Er worden twee meegeleverd: Control Center (built-in) — de harness in het proces die met modelaanbieders praat — en Claude Code via claude -p. Cursor, Codex, Anthropic, OpenAI en de rest zijn aanbieders op de ingebouwde adapter, geen aparte CLI’s. Zie Adapters en modellen beheren.
Werkruimte: De isolatietennant op het hoogste niveau. Bundelt agenten, repo’s, ruimtes, tickets, geheugen en pipelines. Isolatie is structureel, niet louter conventie: elke werkruimte heeft zijn eigen SQLite-bestand (<dataDir>/<workspaceId>/workspace.db), dus een leesactie over werkruimtes heen compileert niet. Elke route in de app begint met /workspaces/:workspaceId — zie de routekaart.
Forge: Een codehost — GitHub, GitLab of Bitbucket Cloud. De forge is een eigenschap van elke repo, bij registratie uitgelezen uit zijn origin-remote, en die bepaalt de API-adapter en inloggegevens van die repo. Eén werkruimte kan repo’s op alle drie huisvesten; oppervlaktes die samenvoegen (het postvak, de PR-wachtrij) waaieren uit over elke vertegenwoordigde forge en voegen de resultaten samen, waarbij fouten geïsoleerd blijven zodat een onbereikbare forge de andere nooit leegmaakt. Forges verschillen in wat ze ondersteunen — zie de mogelijkhedentabel in Een codehost verbinden.
Repo: Een Git-repository die in één werkruimte is geregistreerd. Werkruimtegebonden — dezelfde checkout die in twee werkruimtes is geregistreerd, zijn twee onafhankelijke rijen met twee id’s; de identiteit van een repo over werkruimtes heen loopt via het bestandssysteempad, nooit via het id. Registratie vereist een git-worktree waarvan de origin-remote naar een ondersteunde forge wijst. Elke repo draagt die forge (github / gitlab / bitbucket), die de gebruikte API-adapter en inloggegevens kiest.
Geïsoleerde repo: Een werkruimtegebonden worktree van een geregistreerde repo. Copy-on-write via rift waar die native wordt meegeleverd; git worktree op Windows. Per ruimte ingericht — elk gesprek in die ruimte deelt één checkout — zodat agenten de bron nooit wijzigen.
Ruimte: Een werkruimtegebonden samenwerkingscontainer met menselijke deelnemers en agentdeelnemers, een opgeslagen Mode, een inrichtingsstatus en een SpaceKind (topic / agentPeer / system / pr / slack) die bepaalt hoe de ruimte wordt ingedeeld, gedempt, van een badge voorzien en opgeruimd. De ruimte bezit de geïsoleerde worktrees die haar gesprekken delen (copy-on-write via rift; git worktree op Windows).
Gesprek: Eén berichtenstroom in een ruimte, met een eigen id, geschiedenis en context voor agentruns. Gesprekken in een ruimte staan op gelijke voet — er is geen primaire of “hoofd”-stroom. Elk opent als een tabblad in de editor; de ongelezenstatus van een ruimte telt ze allemaal op.
Thread: Een gesprek waarvan anchorMessageId is gezet: verankerd aan één bericht van een zustergesprek in dezelfde ruimte, met een verse agentcontext die door dat ankerbericht wordt gevuld. Eén niveau diep — threads verankeren nooit aan threads.
Ticket: Het aggregaat van de werkseenheid. Leverancierneutraal: standaard local, met sync-adapters voor Linear, GitHub Issues, Jira Cloud en ClickUp — al maakt geen enkele oppervlakte in de app een sync-verbinding aan. Ondersteunt hiërarchie, koppelingen en delegatie. Toewijzing aan een agent legt het eigenaarschap vast en start niets; toewijzing aan een team is de uitzondering (TeamRoutingService start de leider).
Pipeline: Een workflow op basis van een DAG die stappen aan elkaar rijgt (agentdispatch, scripts, voorwaarden). Gedefinieerd door sjablonen; uitgevoerd als runs.
Waardeobjecten
Sectie getiteld “Waardeobjecten”AgentRole: Opgesomde rol (CEO, coder, reviewer, QA, designer, security, devops, PM, general). Bepaalt persona, geheugentoegang en hiërarchie.
AgentSkills: Hoofdletterongevoelige set van skill-id’s die op het moment van dispatch relevante context in prompts injecteert.
Skillbron: Een GitHub-repository die per werkruimte als skillcatalogus is geregistreerd. Wantrouwig van opzet: de metadata van de repository is alleen ter weergave en elke installatie passeert de fail-closed scanpoort voordat er inhoud op schijf of in een prompt belandt. Zie Skills installeren en beheren.
skills-lock.json: Het manifest per werkruimte van geïnstalleerde skills: voor elk ervan de bronrepository, het pad in de repo, de commit waaraan het is vastgezet en een samengevatte contenthash. Installaties, updates en de-installaties houden het actueel; verify_skills controleert het tegen de schijf.
Agentrun-gateway: Een loopback-eindpunt op cc_server dat het actiebeleid binnen de sandbox van een agent toepast. Elke GitHub-push van een agent wordt erheen geleid, getoetst aan de regel Naar een remote pushen en doorgestuurd met een schrijftoken dat de agent nooit in handen heeft; de Bash-opdrachten van Claude Code worden via een hook op hetzelfde eindpunt gecontroleerd. Zie Sandbox en beveiliging.
Modus: chat, plan, review of orchestrate. Per ruimte opgeslagen, dus één agent kan in verschillende ruimtes in verschillende modi staan; elk gesprek in een ruimte deelt de modus. Bepaalt de systeemprompt, de schrijfregels van de sandbox en de allowlist met MCP-tools. De composer biedt alleen chat, plan en orchestrate; chat heeft het label “Agent”.
SandboxBackend: microvm (een afgesloten VM — de enige backend met een kernelgrens, toegepast op interactieve terminals), native (Seatbelt op macOS, bubblewrap op Linux en WSL2) of none. Wordt één keer bij het opstarten geprobeerd; native wordt toegepast op agentdispatch wanneer die beschikbaar is, en omhult de Claude Code CLI en de bash-tool van de harness. Windows heeft geen native backend en Linux vereist bwrap plus socat, dus runs daar worden niet omhuld; --sandbox off kiest daar bewust voor om het uit te zetten.
Rig: Een wegwerpmachine die een agent in realtime aanstuurt — een afgesloten browser of Linux-desktop, een door de host beheerde Android-emulator of iOS Simulator, of een afgesloten terminal. Live bekeken via een eigen baan op volledige resolutie, met overname die server-side wordt afgedwongen. Gebonden aan een gesprek, zodat het menselijke tabblad en de aanroepen browser_use / computer_use / mobile_use / ios_use van de agent één standaardmachine aanspreken. Zie Rigs en omhullingen.
Omhulling: De sterkere grens van een VM-ondersteunde rig — een kernelgrens, een wegwerp-overlayschijf, een netwerkpoort die standaard weigert en een credential broker. Android- en iOS-rigs zijn wegwerpbaar maar gebruiken door de host beheerd netwerk en claimen deze grens niet. Elke rig aansturen gebruikt de beveiligingsklasse enclosureControl.
RunCost: Token- en kostenoverzicht (invoertokens, uitvoertokens, geschatte kosten in centen) voor één agentrun.
WakeReason: Waarom een agent is gedispatcht. Zes waarden: gebruikersbericht, tickettoewijzing, hersteldispatch na een fout, kindticket afgerond, geplande vervolghartslag en pipelinestap.
Poorten
Sectie getiteld “Poorten”SandboxPort: Beheert de levenscyclus van de sandbox (probe, launch, events, exec, destroy).
CredentialBrokerPort: Geeft begrensde inloggegevens uit voor het starten van een sandbox — alleen leesrechten voor de omgeving van een agent, schrijfrechten alleen voor het pushpad op de server — en trekt ze bij het opruimen weer in.
GitRepoInspectorPort: Haalt metadata (owner, repo, branch) op uit een lokaal Git-repopad.
EmbeddingPort: Produceert tekstembeddings met eenheidsnorm voor semantisch zoeken.
NotificationPort: Toont native desktopmeldingen en respecteert de filtering op categorie en route.
TicketProviderPort: Leverancierneutrale grens naar een ticketingbackend (create, get, list, update, transition, assign).
PipelineEnginePort: Start een pipelinerun vanuit een sjabloon en ontkoppelt zo de aanroepers van de concrete engine.
Domeinservices
Sectie getiteld “Domeinservices”AgentDispatchService: Start agentruns: richt geïsoleerde repo’s in, bouwt prompts, maakt runlogs aan en levert live gebeurtenisstromen terug.
TicketWorkflowService: Pure-domeinengine voor de ticketlevenscyclus met een mutatieknelpunt onder optimistische gelijktijdigheid en handhaving van werkruimte-isolatie. De overgangsgraaf die het afdwingt, bindt alleen agenten en automatisering; door de gebruiker gestuurde UI-wijzigingen geven force: true mee en omzeilen hem. Er is geen ticketdispatcher voor een agent als toegewezene — AgentDispatchService bezit de dispatch, en een ticket aan een agent toewijzen start geen run. Een ticket aan een team toewijzen is de uitzondering (TeamRoutingService start de leider).
PipelineEngine: Orkestreert de uitvoering van runs: start runs, plant stappen, slaat de toestand op, behandelt routers/joins/continue-on-fail en hervat lopende runs na een herstart.
PipelineTriggerDispatcher: Abonneert zich op domeingebeurtenissen en start automatisch passende pipelineruns voor ingeschakelde triggers.
MemoryAccessPolicy: Bepaalt en handhaaft de geheugenrechten van agentrollen op domeinen.
HarnessCostCalculator: Waardeert het tokenverbruik van de ingebouwde harness tot een RunCost op basis van de catalogus models.dev. Dispatch schrijft dat overzicht naar de runlog.
BudgetEnforcementService: Berekent de maandelijkse uitgaven per agent en een blokkade vóór dispatch (checkInvocationBlock). Die blokkade wordt alleen geraadpleegd door de herstel-reconcilers (OrphanRunReaper, StrandedTicketReconciler), nooit door een gewone dispatch door een gebruiker of agent.
BudgetGovernanceService: Evalueert de maandelijkse uitgaven per agent na elke run — een zachte drempel legt een waarschuwingsincident vast; uitputting legt een hard incident vast en zet de levenscyclus van de agent op paused.
Gebeurtenissen
Sectie getiteld “Gebeurtenissen”DomainEventBus: In-process broadcast- publish/subscribe-bus voor communicatie tussen features. Gebeurtenissen zijn getypeerd; abonnees lezen on<T>()-streams.
DomainEvent: Basisinterface. Elke gebeurtenis heeft occurredAt. Belangrijkste categorieën: workspace/agent, PR/review, berichten, ticketing, pipeline, vergaderingen/agenda, identiteit, rigs, observeerbaarheid.
Vergaderingen en agenda
Sectie getiteld “Vergaderingen en agenda”Vergadering: Een lokaal opgenomen, getranscribeerde vergaderingssessie. Legt microfoon- en systeemaudio vast, transcribeert op het toestel met een kiesbaar ASR-model (standaard Parakeet TDT v3; Parakeet TDT v2, Whisper large-v3-turbo en Whisper base.en zijn alternatieven), scheidt de sprekers en vat samen in notities, actiepunten en beslissingen. Het gekozen ASR-model wordt bij het opstarten geforceerd geïnstalleerd en opnamefuncties lichten op na één herstart. Werkruimtegebonden; blijft op de machine.
MeetingSegment: Eén getranscribeerd audiovenster, met sprekerstag (me/them), een diarisatielabel en offsets in milliseconden.
MeetingActionItem / MeetingDecision: Gestructureerde uitvoer die de samenvattingspipeline extraheert en als losse rijen opslaat. Actiepunten kunnen naar een ticket verwijzen.
CalendarEvent: Een gesynchroniseerde vermelding uit Google Calendar, gebonden aan een werkruimte en een verbonden account. Verschilt van een vergadering: een item is een geplande verplichting; een vergadering is een opgenomen sessie. Een-op-een gekoppeld via een MeetingCalendarLink.
CalendarAccount: Een verbonden Google-account, per werkruimte en e-mailadres. OAuth-refreshtokens worden server-side opgeslagen als google_*-sleutels in <dataDir>/secrets.json en bereiken nooit een client; de device-codeflow rondt af op de server. Een authExpiredAt-markering stuurt de banner om opnieuw te verbinden.
Architectuurbegrippen
Sectie getiteld “Architectuurbegrippen”Clean Architecture: Afhankelijkheidsregel: Presentation → Application/Providers → Domain ← Infrastructure. Het domein heeft nul infrastructuur-imports.
Poorten en adapters: Het domein definieert abstracte interfaces (poorten); de infrastructuur levert concrete implementaties (adapters). De compositieroot verbindt ze.
Gedeelde kernel: Entiteiten, waardeobjecten, poorten en services uit core/domain/ die door 3 of meer features worden gedeeld.
Feature-first: De code is georganiseerd naar bedrijfsdomein (agenten, pipelines, berichten) in plaats van naar technische laag.
Multiplayer, identiteit en snelheid
Sectie getiteld “Multiplayer, identiteit en snelheid”Principal: Een verzegelde waarde die mensen en agenten verenigt als de ene actorabstractie — UserPrincipal(userId) of AgentPrincipal(agentId). Elk bericht, ticket, elke review, elk plan en elke runlog wordt via een principal toegeschreven.
Gebruiker: Een menselijke identiteit, opgeslagen in global.db en dus globaal over werkruimtes heen. De principal die een werkruimte aanmaakt, wordt de eigenaar — vastgelegd op Workspace.ownerUserId met in dezelfde handeling een lidmaatschapsrij met de rol owner. Anderen sluiten aan via een uitnodiging of SSO.
WorkspaceMember / WorkspaceRole: Een lidmaatschapsrij die een gebruiker aan een werkruimte bindt met een rol (owner / admin / member / viewer / guest). Lidmaatschap — niet een koppelingssleutel — is de toegangsgrens. Toegiften per repo zorgen dat lidmaatschap niet boven de forge uitstijgt.
ParticipantPresence: Tijdelijke aanwezigheid voor een principal (status, verblijfplaats, cursor, typen, de live status en lopende kosten van een agent). Wordt nooit opgeslagen; draait via de server; vóór het uitwaaieren gefilterd op repotoegang.
Volgmodus: Klik op een avatar om diens viewport te volgen tot je zelf iets doet, en maak je daarna los. Werkt voor mensen en voor agenten (“kijk hoe een agent werkt”).
Autonomieknop: Een bediening per ruimte per agent — propose-only / act-with-approval / act-freely — geïmplementeerd als een benoemd profiel boven de opslag met actiebeveiligingen.
ActionClass: Een gesloten set van 13 effectklassen (fileDelete, gitPush, prCreate, networkEgress, processSpawn, enclosureControl, …). Elke muteerbare tool verklaart zijn klassen; de beveiligingsengine bepaalt per bereik allow / prompt / deny (ruimte > agent > werkruimte > modus-preset > ingebouwde standaard).
WriteLedger / Idempotentiesleutel: Elke mutatie draagt een door de client gegenereerde idempotentiesleutel (UUIDv7, per logische actie). Het werkruimtegebonden ledger ontdubbelt voordat de handler draait; een herhaling levert het byte-identieke oorspronkelijke resultaat op. Maakt opnieuw verbinden en meerdere clients veilig van opzet.
Postvak: Een wachtrij over alle pijlers met een strikte regel — een item verschijnt alleen als het iets blokkeert (een agent, een merge, een sync) of de operator expliciet vraagt.
Plan Studio: Het interactieve planningsvlak — bewerkbare plannen als getypeerde DAG, met kosten, tijd en risico per stap en gedeeltelijke goedkeuring.
Review-compute: Server-side PR-review-compute (uit de graaf afgeleide cohorten, getypeerde diagrammen, visuele diffs, API-contractdiffs, poorten over meerdere assen), geserveerd via review_studio.* en meegenomen in het tabblad Review.
Reviewruimte: De ene dragende ruimte van een PR (modus review, soort pr), idempotent aangemaakt en via een ReviewSpaceAssociation aan de PR gekoppeld. Elke reviewer legt er bevindingen in vast, en dat is wat ze vergelijkbaar maakt; haar geïsoleerde worktree heeft de PR op zijn head uitgecheckt.
Reviewnode: De gestructureerde eenheid van een AI-reviewbevinding: soort (bug, suggestion, recommendation, question, ticket), prioriteit P0–P3, een triage-drietal van categorie/ernst/inspanning, een anker op bestand en regel, een optionele voorgestelde oplossing en een betrouwbaarheidsscore. Vastgelegd met add_review_node; het oordeel wordt uit nodes berekend, niet uit proza.
Consensus-ready: De status van een reviewnode die alleen wordt bereikt wanneer een peer-reviewer een bevinding bevestigt — een agent kan zijn eigen bevinding niet bevestigen. De knop Publiceren naar GitHub in het tabblad Review verstuurt elke resterende open bevinding (selection: all_open); de MCP-tool publish_review_to_github richt zich nog steeds standaard alleen op door peers bevestigde bevindingen.
Reviewniveau: Beleid van de werkruimte (light, balanced, thorough) dat bepaalt welke reviewers uitwaaieren (alleen engineer; +qa+architect; +security+perf) en waar bevindingen onder de drempel verschijnen. Verwijdert nooit een bevinding.
Reviewas: Een van vijf scorebanen per review: correctness, security en testGap uit de bevindingen van reviewers; visual en apiContract deterministisch. Assen met een poort worden in het oordeel meegenomen en kunnen het alleen strenger maken — een poort die partial of unavailable is, houdt het oordeel tegen in plaats van het goed te keuren.
Review-oordeel: ship, hold of block. Elke P0-bevinding met een betrouwbaarheid >= 0,7 blokkeert; elk ander P0 of elk P1 houdt tegen; anders ship. Een as met een poort die faalt, dwingt block af en kan niet door bevindingen worden overstemd.
Fleet en evals
Sectie getiteld “Fleet en evals”cc_worker: Een headless uitvoerderbinary in puur Dart voor de fleet. Koppelt zich aan een cc_server, meldt de mogelijkheden van zijn host, haalt geleasde jobs op, voert ze uit en streamt procesgebeurtenissen terug. Houdt geen duurzame toestand vast — één gezaghebbende server, N domme ledematen.
JobSpec: De getypeerde spec voor alles wat uitvoerbaar is (agentrun, pipelinestap, code-index, golden-render, benchmark, evalbatch).
Eval-suite: Een werkruimtegebonden definitie van een evaluatie (prompt, doelagent en modus, beoordelaars). Bij het aanmaken van een werkruimte worden vijf starters gezaaid; Observeerbaarheid → Kwaliteit toont ze.
Deployment en clients
Sectie getiteld “Deployment en clients”Thin-clientarchitectuur: Geen enkele client opent de database; een headless cc_server-proces bezit de gegevens en serveert ze via WebSocket RPC. Elke client (desktop, web, telefoon) is een renderer over die ene RPC-verbinding.
cc_server: De headless serverbinary (puur Dart, zonder Flutter-engine). Bezit de Drift/SQLite-database, serveert repo-RPC via WebSocket en draait de achtergrondservices (pipelines, MCP, reconcilers).
ServerConnectionMode: Hoe de desktop zijn server bereikt — local (start een cc_server op deze machine, de standaard) of remote (kies er elders een). De webclient is altijd remote.
RemoteRpcClient: De transportonafhankelijke JSON-RPC-client die elke thin client gebruikt om met zijn server te praten — via WSS, loopback of de bemiddelde relay.
Werkruimte per aanroep: De server is staatloos — er is geen werkruimtebinding per sessie, dus meerdere clients op één server delen nooit een “huidige werkruimte”. Elke werkruimtegebonden repo/call en sub/subscribe moet workspace_id in zijn argumenten meedragen; een ontbrekend of niet-geregistreerd id wordt geweigerd voordat er een database opengaat. Toegang wordt daarna bepaald door werkruimtelidmaatschap en -rol, niet door de sessie.
cc_remote: De thin client voor de telefoon — een Flutter-web-PWA die de fleet op afstand bestuurt via de bemiddelde relay, met een toolbeleid dat standaard weigert.
cc_signaling_server: Een staatloze WebSocket-relaybroker die uitnodigingsgebonden ruimtes host — een domme relay die alleen end-to-end verzegelde frames doorstuurt, geen appgegevens vasthoudt en de koppelings-PSK nooit ziet.