Ordliste

Kjernentiteter

Agent: En KI-arbeider med identitet, rolle, skills og en adapter. Tilhører nøyaktig ett arbeidsområde. Den viktigste aktøren i systemet.

Adapter: Kjøreren som utfører en agenttur. To leveres: Control Center (innebygd) — den prosessinterne kjernen som snakker med modellleverandørene — og Claude Code via claude -p. Cursor, Codex, Anthropic, OpenAI og resten er leverandører på den innebygde adapteren, ikke separate CLI-er. Se Administrer adaptere og modeller.

Arbeidsområde: Den øverste isolasjonsleietakeren. Grupperer agenter, repoer, områder, saker, minne og pipelines. Isolasjonen er strukturell, ikke konvensjonell: hvert arbeidsområde har sin egen SQLite-fil (<dataDir>/<workspaceId>/workspace.db), så en lesing på tvers av arbeidsområder kompilerer ikke. Hver rute i appen har prefikset /workspaces/:workspaceId — se rutekartet.

Kodevert: En kodevert — GitHub, GitLab eller Bitbucket Cloud. Kodeverten er en egenskap ved hvert repo, lest fra fjernkilden origin ved registrering, og den velger repoets API-adapter og legitimasjon. Ett arbeidsområde kan ha repoer hos alle tre; flater som samler inn (innboksen, PR-køen) spør alle representerte kodeverter, slår resultatene sammen og isolerer feil, slik at en utilgjengelig kodevert aldri tømmer de andre. Kodeverter er forskjellige i hva de støtter — se egenskapstabellen i Koble til en kodevert.

Repo: Et Git-repositorium registrert i ett arbeidsområde. Knyttet til arbeidsområdet — samme utsjekking registrert i to arbeidsområder er to uavhengige rader med to id-er; identiteten til et repo på tvers av arbeidsområder går på filsystemsti, aldri på id. Registrering krever et Git-arbeidstre der fjernkilden origin peker på en støttet kodevert. Hvert repo har denne kodeverten (github / gitlab / bitbucket), som velger API-adapteren og legitimasjonen som brukes for det.

Isolert repo: Et arbeidsområdeavgrenset worktree av et registrert repo. Copy-on-write via rift der denne native-en leveres; git worktree på Windows. Klargjort per område — hver samtale i det området deler én utsjekking — så agenter endrer aldri kilden.

Område: En arbeidsområdeavgrenset samarbeidsbeholder med menneskelige og agentiske deltakere, en lagret Mode, klargjøringsstatus og en SpaceKind (topic / agentPeer / system / pr / slack) som avgjør hvordan den seksjoneres, dempes, merkes og ryddes. Den eier de isolerte worktreene samtalene deler (copy-on-write via rift; git worktree på Windows).

Samtale: Én meldingsstrøm inne i et område, med egen id, historikk og kontekst for agentkjøringen. Samtaler i et område er likestilte — det finnes ingen primær- eller «hoved»-strøm. Hver åpnes som en fane i editoren; ulest-tilstanden til et område samler dem alle.

Tråd: En samtale der anchorMessageId er satt: forankret til én melding i en søstersamtale i samme område, med en fersk agentkontekst sådd av den forankringsmeldingen. Ett nivå dypt — tråder forankres aldri i tråder.

Sak: Aggregatet for arbeidsenheten. Leverandørnøytralt: local som standard, med synkroniseringsadaptere for Linear, GitHub Issues, Jira Cloud og ClickUp — selv om ingen flate i appen oppretter en synkroniseringstilkobling. Støtter hierarki, lenker og delegering. Tildeling til en agent registrerer eierskap og sender ikke ut noe; tildeling til et team er unntaket (TeamRoutingService sender ut lederen).

Pipeline: En DAG-basert arbeidsflyt som kjeder sammen steg (agentutsending, skript, betingelser). Definert av maler; kjørt som kjøringer.

Verdiobjekter

AgentRole: Oppramset rolle (CEO, coder, reviewer, QA, designer, security, devops, PM, general). Bestemmer persona, minnetilgang og hierarki.

AgentSkills: Sett av skill-identifikatorer uten hensyn til store og små bokstaver, som sprøyter relevant kontekst inn i prompter ved utsendingstidspunktet.

Skill-kilde: Et GitHub-repositorium registrert per arbeidsområde som en skill-katalog. Uklarert av konstruksjon: metadataene til repositoriet er kun for visning, og hver installasjon passerer den feillukkede skanningsporten før noe innhold når disken eller en prompt. Se installer og administrer skills.

skills-lock.json: Manifestet per arbeidsområde over installerte skills: for hver av dem kilderepositoriet, repositoriestien, commiten den er festet til og en samlet innholdshash. Installasjoner, oppdateringer og avinstallasjoner holder det oppdatert; verify_skills sjekker det mot disken.

Agentkjøringsgateway: Et loopback-endepunkt på cc_server som bruker handlingspolicyen inne i en agents sandkasse. Hver GitHub-push en agent gjør, ledes dit, kontrolleres mot regelen Push til en remote og sendes videre med et skrivetoken agenten aldri har; Claude Codes Bash-kommandoer kontrolleres gjennom en hook på samme endepunkt. Se Sandkasse og sikkerhet.

Modus: chat, plan, review eller orchestrate. Lagret per område, så én agent kan være i forskjellige moduser i forskjellige områder; hver samtale i et område deler den. Styrer systemprompten, sandkassens skriveregler og tillatelseslisten for MCP-verktøy. Skrivefeltet tilbyr bare chat, plan og orchestrate; chat er merket «Agent».

SandboxBackend: microvm (en lukket VM — den ene backenden med en kjernegrense, brukt på interaktive terminaler), native (Seatbelt på macOS, bubblewrap på Linux og WSL2) eller none. Probres én gang ved oppstart; native brukes på agentutsending når den er tilgjengelig, og pakker inn Claude Code-CLI-en og kjerne-bash-verktøyet. Windows har ingen native-backend, og Linux trenger bwrap pluss socat, så kjøringer der er uinnpakkede; --sandbox off velger bort med vilje.

Stasjon: En kastbar maskin en agent styrer i sanntid — en lukket nettleser eller et Linux-skrivebord, en vertsstyrt Android-emulator eller iOS-simulator, eller en lukket terminal. Overvåkes direkte over sin egen bane i full oppløsning, med overtakelse håndhevet på serversiden. Knyttet til en samtale, slik at menneskefanen og agentens browser_use / computer_use / mobile_use / ios_use-kall adresserer én standardmaskin. Se Stasjoner og isolerte miljøer.

Isolert miljø: Den sterkere, VM-støttede stasjonsgrensen — en kjernegrense, en kastbar overlay-disk, en nettsluse som avviser som standard og en legitimasjonsmegler. Android- og iOS-stasjoner er kastbare, men bruker vertsstyrt nettverk og gjør ikke krav på denne grensen. Å styre en stasjon bruker tillatelsesklassen enclosureControl.

RunCost: Token- og kostnadsopptelling (inndata-tokener, utdata-tokener, estimert kostnad i cent) for én enkelt agentkjøring.

WakeReason: Hvorfor en agent ble sendt ut. Seks verdier: brukermelding, saktildeling, gjenopprettingsutsending etter en feil, fullført underordnet sak, planlagt oppfølgingsheartbeat og pipeline-steg.

Porter

SandboxPort: Håndterer livssyklusen til sandkassen (probe, launch, events, exec, destroy).

CredentialBrokerPort: Utsteder avgrensede legitimasjoner for oppstart av sandkassen — bare lesing for en agents miljø, skriving bare for push-stien på serveren — og tilbakekaller dem ved nedriving.

GitRepoInspectorPort: Henter ut metadata (eier, repo, gren) fra en lokal Git-repo-sti.

EmbeddingPort: Produserer tekstembeddingvektorer med enhetsnorm for semantisk søk.

NotificationPort: Viser innebygde skrivebordsvarsler og respekterer gating etter kategori og rute.

TicketProviderPort: Leverandøruavhengig grense mot en saksbackend (create, get, list, update, transition, assign).

PipelineEnginePort: Starter en pipeline-kjøring fra en mal og frikobler kallere fra den konkrete motoren.

Domenetjenester

AgentDispatchService: Starter agentkjøringer: klargjør isolerte repoer, bygger prompter, oppretter kjøringslogger og returnerer levende hendelsesstrømmer.

TicketWorkflowService: Ren domenemotor for saksforløpet med et mutasjonsknutepunkt for optimistisk samtidighet og håndheving av arbeidsområdeisolasjon. Overgangsgrafen den håndhever binder bare agenter og automatisering; brukerdrevne endringer i grensesnittet sender force: true og omgår den. Det finnes ingen saksutsender for en agentmottaker — AgentDispatchService eier utsendingen, og å tildele en sak til en agent starter ingen kjøring. Å tildele en sak til et team er unntaket (TeamRoutingService sender ut lederen).

PipelineEngine: Orkestrerer kjøring: starter kjøringer, planlegger steg, lagrer tilstand, håndterer rutere/sammenføyninger/fortsett-ved-feil og gjenopptar kjøringer underveis etter omstart.

PipelineTriggerDispatcher: Abonnerer på domenehendelser og starter automatisk samsvarende pipeline-kjøringer for aktiverte utløsere.

MemoryAccessPolicy: Løser opp og håndhever minnetillatelser for agentroller på domener.

HarnessCostCalculator: Priser tokenbruken til den innebygde kjernen til en RunCost fra models.dev-katalogen. Utsendingen lagrer opptellingen på kjøringsloggen.

BudgetEnforcementService: Beregner månedsforbruk per agent og en blokkering før utsending (checkInvocationBlock). Denne blokkeringen konsulteres bare av gjenopprettingsavstemmerne (OrphanRunReaper, StrandedTicketReconciler), aldri av en vanlig bruker- eller agentutsending.

BudgetGovernanceService: Vurderer månedsforbruk per agent etter hver kjøring — en myk terskel registrerer en advarselshendelse; uttømming registrerer en hard hendelse og setter agentens livssyklus til paused.

Hendelser

DomainEventBus: Prosessintern kringkastingsbuss for publish/subscribe på tvers av funksjoner. Hendelser er typede; abonnenter konsumerer on<T>()-strømmer.

DomainEvent: Grensesnitt i bunnen. Hver hendelse har occurredAt. Viktige kategorier: arbeidsområde/agent, PR/gjennomgang, meldinger, saker, pipeline, møter/kalender, identitet, stasjoner, observerbarhet.

Møter og kalender

Møte: En lokalt tatt opp og transkribert møteøkt. Fanger opp mikrofon- og systemlyd, transkriberer på enheten med en valgbar ASR-modell (Parakeet TDT v3 som standard; Parakeet TDT v2, Whisper large-v3-turbo og Whisper base.en er alternativer), skiller talere og oppsummerer til notater, tiltak og beslutninger. Den valgte ASR-modellen tvangsinstalleres ved oppstart, og opptaksoperasjoner våkner etter én omstart. Knyttet til arbeidsområdet; blir på maskinen.

MeetingSegment: Ett transkribert vindu med lyd, talermerket (me/them) med en diariseringsetikett og millisekundforskyvninger.

MeetingActionItem / MeetingDecision: Strukturerte utdata hentet ut av oppsummeringspipelinen og lagret som egne rader. Tiltak kan lenkes til en sak.

CalendarEvent: En synkronisert Google Kalender-oppføring knyttet til et arbeidsområde og en tilkoblet konto. Forskjellig fra et Møte: en hendelse er en planlagt forpliktelse; et Møte er en tatt opp økt. Koblet én-til-én via en MeetingCalendarLink.

CalendarAccount: En tilkoblet Google-konto, per arbeidsområde og e-postadresse. OAuth-oppdateringstokener lagres på serversiden som google_*-nøkler i <dataDir>/secrets.json og når aldri en klient; enhetskodeflyten fullføres på serveren. Et authExpiredAt-flagg driver gjenoppkoblingsbanneret.

Arkitekturtermer

Clean Architecture: Avhengighetsregel: Presentasjon → Applikasjon/Leverandører → Domene ← Infrastruktur. Domenet har null infrastrukturimporter.

Porter og adaptere: Domenet definerer abstrakte grensesnitt (porter); infrastrukturen leverer konkrete implementasjoner (adaptere). Komposisjonsroten binder dem sammen.

Delt kjerne: core/domain/-entiteter, verdiobjekter, porter og tjenester delt på tvers av 3+ funksjoner.

Funksjonsstruktur: Koden er organisert etter forretningsdomene (agenter, pipelines, meldinger) i stedet for etter teknisk lag.

Flerbruker, identitet og tempo

Principal: En forseglet verdi som samler mennesker og agenter i én aktørabstraksjon — UserPrincipal(userId) eller AgentPrincipal(agentId). Hver melding, sak, gjennomgang, plan og kjøringslogg tilskrives gjennom en Principal.

Bruker: En menneskelig identitet, lagret i global.db og dermed global på tvers av arbeidsområder. Principalen som oppretter et arbeidsområde, blir eieren av det — stemplet på Workspace.ownerUserId med en medlemsrad for eierrollen i samme operasjon. Andre blir med via invitasjon eller SSO.

WorkspaceMember / WorkspaceRole: En medlemsrad som binder en Bruker til et Arbeidsområde på en rolle (owner / admin / member / viewer / guest). Medlemskap — ikke en parkoblingsnøkkel — er tilgangsgrensen. Per-repo-tilganger hindrer medlemskapet i å gi mer privilegier enn kodeverten.

ParticipantPresence: Flyktig tilstedeværelse for en Principal (status, posisjon, markør, skriving, en agents levende status og løpende kostnad). Lagres aldri; samles på serveren; filtreres etter repo-tilgang før spredning.

Følg-modus: Klikk på en avatar for å ri på visningsfeltet dens til du handler, og koble deretter fra. Fungerer for mennesker og for agenter («se en agent arbeide»).

Autonomivriden: En kontroll per område og per agent — propose-only / act-with-approval / act-freely — implementert som en navngitt profil over lageret for handlingstillatelsesregler.

ActionClass: Et lukket sett med 13 effektklasser (fileDelete, gitPush, prCreate, networkEgress, processSpawn, enclosureControl, …). Hvert muterende verktøy erklærer klassene sine; tillatelsesmotoren løser opp allow / prompt / deny per omfang (område > agent > arbeidsområde > modusforvalg > innebygd standard).

WriteLedger / idempotensnøkkel: Hver mutasjon har en klientgenerert idempotensnøkkel (UUIDv7, per logisk handling). Den arbeidsområdeavgrensede loggen fjerner duplikater før behandleren kjører; en gjenavspilling returnerer det bytedentiske opprinnelige resultatet. Gjør gjenoppkobling og flere klienter trygt av konstruksjon.

«Trenger meg»-innboksen: En kø på tvers av søylene med en streng regel — et element vises bare hvis det blokkerer noe (en agent, en sammenslåing, en synkronisering) eller eksplisitt ber operatøren om noe.

Plan Studio: Planleggingsflaten — redigerbare planer som typet DAG, med kostnad, tid og risiko per steg, og delvis godkjenning.

Gjennomgangsberegning: Gjennomgangsberegning på serversiden for en PR (grafuledede kohorter, typede diagrammer, visuelle differ, API-kontraktsdiffer, porter over flere akser) servert over review_studio.* og innlemmet i fanen Gjennomgang.

Gjennomgangsområde: Det ene bakenforliggende området til en PR (modus review, type pr), opprettet idempotent og koblet til PR-en med en ReviewSpaceAssociation. Hver reviewer legger inn funn i det, og det er dette som gjør dem sammenlignbare; det isolerte worktreet har PR-en sjekket ut på head-en sin.

Gjennomgangsknode: Den strukturerte enheten i et AI-gjennomgangsfunn: type (bug, suggestion, recommendation, question, ticket), prioritet P0–P3, en triage-trippel med kategori, alvorlighet og innsats, et anker for fil og linje, en valgfri foreslått retting og en konfidensverdi. Registreres med add_review_node; dommen beregnes fra noder, ikke fra prosa.

Consensus-ready: Statusen til en gjennomgangsknode som bare nås når en peer-reviewer bekrefter et funn — en agent kan ikke bekrefte sitt eget. Knappen Publiser til GitHub i fanen Gjennomgang sender hvert gjenstående åpne funn (selection: all_open); MCP-verktøyet publish_review_to_github bruker fortsatt bare peer-bekreftede funn som standard.

Gjennomgangsnivå: Arbeidsområdepolicy (light, balanced, thorough) som stiller inn hvilke reviewere som sendes ut (bare engineer; +qa+architect; +security+perf) og hvor funn under terskelen vises. Sletter aldri et funn.

Gjennomgangsakse: Én av fem vurderingsbaner per gjennomgang: correctness, security og testGap hentet fra reviewernes funn; visual og apiContract deterministiske. Gatede akser inngår i dommen og kan bare gjøre den strengere — en partial- eller unavailable-port holder dommen tilbake i stedet for å slippe den gjennom.

Gjennomgangsdommen: ship, hold eller block. Ethvert P0-funn med konfidens ≥ 0,7 blokkerer; ethvert annet P0 eller ethvert P1 holder; ellers ship. En gated akse som feiler, tvinger block og kan ikke overstemmes av funn.

Flåte og evals

cc_worker: En headless ren-Dart-binær for flåteutførelse. Kobler seg til en cc_server, erklærer vertsevnene sine, henter leide jobber, utfører dem og strømmer prosesshendelser tilbake. Har ingen varig tilstand — én autoritativ server, N dumme lemmer.

JobSpec: Den typede spesifikasjonen for alt som kan utføres (agentkjøring, pipeline-steg, kodeindeks, golden-render, benchmark, eval-batch).

Eval-suite: En arbeidsområdeavgrenset definisjon av en evaluering (prompt, målagent og modus, gradsgivere). Fem startsett legges inn når et arbeidsområde opprettes; Observabilitet → Kvalitet viser dem.

Drift og klienter

Tynnklientarkitektur: Ingen klient åpner databasen; en headless cc_server-prosess eier dataene og betjener dem over WebSocket-RPC. Hver klient (skrivebord, nett, telefon) er en gjengiver over den ene RPC-tilkoblingen.

cc_server: Den headless serverbinæren (ren-Dart, ingen Flutter-motor). Eier Drift/SQLite-databasen, betjener repo-RPC over WebSocket og kjører bakgrunnstjenestene (pipelines, MCP, avstemmere).

ServerConnectionMode: Hvordan skrivebordet når serveren sin — local (start en cc_server på denne maskinen, standarden) eller remote (koble til en annen et annet sted). Nettklienten er alltid remote.

RemoteRpcClient: Den transportuavhengige JSON-RPC-klienten som hver tynnklient bruker for å snakke med serveren sin — over WSS, loopback eller det formidlede reléet.

Arbeidsområdeavgrensning per kall: Serveren er tilstandsløs — det finnes ingen binding av arbeidsområde per økt, så flere klienter på én server deler aldri et «gjeldende arbeidsområde». Hvert arbeidsområdeavgrensede repo/call og sub/subscribe må ha workspace_id i argumentene sine; en manglende eller uregistrert id avvises før noen database åpnes. Tilgangen styres deretter av medlemskap og rolle i arbeidsområdet, ikke av økten.

cc_remote: Telefon-tynnklienten — en Flutter-nett-PWA som fjernstyrer flåten over det formidlede reléet med en verktøypolicy som avviser som standard.

cc_signaling_server: En tilstandsløs WebSocket-relémegler som er vert for invitasjonsgatede rom — et dumt relé som bare videresender ende-til-ende-forseglede rammer, ikke har appdata og aldri ser parkoblings-PSK-en.