Ordlista

Kärnentiteter

Agent: En AI-arbetare med identitet, roll, skills och en adapter. Tillhör exakt en arbetsyta. Systemets främsta aktör.

Adapter: Den körare som utför en agenttur. Två levereras: Control Center (inbyggd) – den inbyggda harnessen i processen som talar med modellleverantörer – och Claude Code via claude -p. Cursor, Codex, Anthropic, OpenAI och övriga är leverantörer på den inbyggda adaptern, inte separata CLI:n. Se Hantera adapters och modeller.

Arbetsyta: Den isolerande tenanten på toppnivå. Grupperar agenter, repos, ytor, ärenden, minne och pipelines. Isoleringen är strukturell, inte konventionell: varje arbetsyta har sin egen SQLite-fil (<dataDir>/<workspaceId>/workspace.db), så en läsning över arbetsytor kompilerar inte. Varje rutt i appen har prefixet /workspaces/:workspaceId – se routkartan.

Kodvärd: En kodvärd – GitHub, GitLab eller Bitbucket Cloud. Kodvärden är en egenskap hos varje repo, läst från dess origin-remote vid registreringen, och den väljer repots API-adapter och autentiseringsuppgift. En arbetsyta kan hålla repos hos alla tre; aggregerande ytor (inkorgen, PR-kön) frågar varje representerad kodvärd och slår samman resultaten, med isolerade fel så att en onåbar kodvärd aldrig tömmer de andra. Kodvärdar skiljer sig i vad de stöder – se kapacitetstabellen i Anslut en kodvärd.

Repo: Ett Git-repositorium registrerat i en arbetsyta. Arbetsyteavgränsat – samma utcheckning registrerad i två arbetsytor är två oberoende rader med två id:n; ett repos identitet över arbetsytor går på filsystemets sökväg, aldrig på id. Registreringen kräver ett git-arbetsträd vars origin-remote pekar på en kodvärd som stöds. Varje repo bär den kodvärden (github / gitlab / bitbucket), som väljer vilken API-adapter och autentiseringsuppgift som används för det.

Isolerat repo: Ett arbetsyteavgränsat worktree av ett registrerat repo. Copy-on-write via rift där den nativa varianten levereras; git worktree på Windows. Etableras per yta – varje samtal i den ytan delar en utcheckning – så agenter muterar aldrig källan.

Yta: En arbetsyteavgränsad samarbetsbehållare med mänskliga deltagare och agentdeltagare, ett sparat Mode, etableringsstatus och en SpaceKind (topic / agentPeer / system / pr / slack) som avgör hur den sektioneras, tystas, märks och städas bort. Den äger de isolerade worktrees som dess samtal delar (copy-on-write via rift; git worktree på Windows).

Samtal: En meddelandeström i en yta, med eget id, egen historik och egen kontext för agentkörningen. Samtal i en yta är jämbördiga – det finns ingen primär eller “huvudsaklig” ström. Vart och ett öppnas som en editorflik; en ytas olästa tillstånd aggregeras över alla.

Tråd: Ett samtal där anchorMessageId är satt: förankrat i ett meddelande i ett syskonsamtal i samma yta, med en färsk agentkontext som sås av det förankrade meddelandet. En nivå djupt – trådar förankras aldrig i trådar.

Ärende: Aggregatet för arbetsenheten. Leverantörsneutralt: local som standard, med synkadaptrar för Linear, GitHub Issues, Jira Cloud och ClickUp – även om ingen yta i appen skapar en synkanslutning. Stöder hierarki, länkar och delegering. Tilldelning till en agent registrerar ägande och startar ingenting; tilldelning till ett team är undantaget (TeamRoutingService startar ledaren).

Pipeline: Ett DAG-baserat arbetsflöde som kedjar samman steg (agentdispatch, skript, villkor). Definieras av mallar; körs som körningar.

Värdeobjekt

AgentRole: Uppräknad roll (CEO, coder, reviewer, QA, designer, security, devops, PM, general). Avgör persona, minnesåtkomst och hierarki.

AgentSkills: Skiftlägesokänslig mängd skill-identifierare som injicerar relevant kontext i prompter vid dispatchtillfället.

Skillkälla: Ett GitHub-repositorium som registreras per arbetsyta som en skillkatalog. Opålitligt till sin konstruktion: repositoriets metadata är enbart för visning och varje installation passerar skanningsgrinden som faller stängt innan något innehåll når disk eller en prompt. Se installera och hantera skills.

skills-lock.json: Manifestet per arbetsyta över installerade skills: för var och en dess källrepositorium, sökvägen i repot, den commit den är fäst vid och en sammanräknad innehållshash. Installationer, uppdateringar och avinstallationer håller det aktuellt; verify_skills kontrollerar det mot disken.

Agentkörningsgateway: En loopback-slutpunkt på cc_server som tillämpar åtgärdspolicyn inuti en agents sandlåda. Varje GitHub-push som en agent gör leds dit, kontrolleras mot regeln Pusha till en remote och skickas vidare med en skrivtoken som agenten aldrig har; Claude Codes Bash-kommandon kontrolleras via en hook på samma slutpunkt. Se Sandlåda och säkerhet.

Mode: chat, plan, review eller orchestrate. Lagras per yta, så en agent kan vara i olika lägen i olika ytor; varje samtal i en yta delar det. Grindar systemprompten, sandlådans skrivregler och MCP-verktygens tillåtelselista. Composern erbjuder bara chat, plan och orchestrate; chat märks som “Agent”.

SandboxBackend: microvm (en avskild VM – den enda backend som har en kärngräns, tillämpad på interaktiva terminaler), native (Seatbelt på macOS, bubblewrap på Linux och WSL2) eller none. Sonderas en gång vid start; native tillämpas på agentdispatch när den finns tillgänglig och lindar in Claude Code-CLI:t och harnessens bash-verktyg. Windows har ingen native-backend och Linux behöver bwrap plus socat, så körningar där lindas inte in; --sandbox off väljer bort det medvetet.

Station: En tillfällig maskin som en agent kör i realtid – en avskild webbläsare eller ett Linux-skrivbord, en värdhanterad Android-emulator eller iOS Simulator, eller en avskild terminal. Bevakas live över sin egen kanal i full upplösning, med övertagande framtvingat på serversidan. Avgränsad till ett samtal så att människans flik och agentens anrop till browser_use / computer_use / mobile_use / ios_use adresserar en och samma standardmaskin. Se Stationer och avskilda miljöer.

Avskild miljö: Den starkare gränsen för VM-baserade stationer – en kärngräns, en tillfällig overlaydisk, en nätverksgrind som nekar som standard och en broker för autentiseringsuppgifter. Android- och iOS-stationer är tillfälliga men använder värdhanterat nätverk och gör inte anspråk på den här gränsen. Att styra en station använder åtgärdsklassen enclosureControl.

RunCost: Token- och kostnadsräkning (indata-tokens, utdata-tokens, uppskattad kostnad i cent) för en enskild agentkörning.

WakeReason: Varför en agent dispatchades. Sex värden: användarmeddelande, ärendetilldelning, återdispatch efter ett fel, underärende slutfört, schemalagt uppföljningshjärtslag och pipelinesteg.

Portar

SandboxPort: Hanterar sandlådans livscykel (probe, launch, events, exec, destroy).

CredentialBrokerPort: Präglar avgränsade autentiseringsuppgifter för sandlådestart – bara läsning för en agents miljö, skrivning bara för pushvägen på servern – och återkallar dem vid nedrivning.

GitRepoInspectorPort: Extraherar metadata (ägare, repo, gren) från en lokal Git-reposökväg.

EmbeddingPort: Producerar enhetsnormerade textinbäddningsvektorer för semantisk sökning.

NotificationPort: Visar nativa skrivbordsaviseringar och respekterar grindning per kategori/rutt.

TicketProviderPort: Leverantörsagnostisk gräns mot en ärendebackend (create, get, list, update, transition, assign).

PipelineEnginePort: Startar en pipelinekörning från en mall och frikopplar anropare från den konkreta motorn.

Domäntjänster

AgentDispatchService: Startar agentkörningar: etablerar isolerade repos, bygger prompter, skapar körningsloggar och returnerar liveströmmar av händelser.

TicketWorkflowService: Ren domänmotor för ärendets livscykel med en flaskhals för mutationer under optimistisk samtidighet och upprätthållande av arbetsyteisolering. Dess övergångsgraf binder bara agenter och automatisering; användardrivna ändringar i gränssnittet skickar force: true och kringgår den. Det finns ingen ärendedispatchare för en tilldelad agent – AgentDispatchService äger dispatchen, och att tilldela ett ärende till en agent startar ingen körning. Att tilldela ett ärende till ett team är undantaget (TeamRoutingService startar ledaren).

PipelineEngine: Orkestrerar körningens utförande: startar körningar, schemalägger steg, bevarar tillstånd, hanterar routrar/joins/continue-on-fail och återupptar pågående körningar efter en omstart.

PipelineTriggerDispatcher: Prenumererar på domänhändelser och startar automatiskt matchande pipelinekörningar för aktiverade triggers.

MemoryAccessPolicy: Löser upp och upprätthåller agentrollens minnesbehörigheter på domäner.

HarnessCostCalculator: Prissätter den inbyggda harnessens tokenanvändning till en RunCost utifrån katalogen models.dev. Dispatchen skriver den räkningen till körningsloggen.

BudgetEnforcementService: Beräknar månadsutgiften per agent och en spärr före dispatch (checkInvocationBlock). Den spärren konsulteras bara av återhämtningens reconcilers (OrphanRunReaper, StrandedTicketReconciler), aldrig av en vanlig användar- eller agentdispatch.

BudgetGovernanceService: Utvärderar månadsutgiften per agent efter varje körning – en mjuk tröskel registrerar en varningsincident; uttömning registrerar en hård incident och ställer agentens livscykel till paused.

Händelser

DomainEventBus: Publicerings-/prenumerationsbuss i samma process för kommunikation mellan funktioner. Händelser är typade; prenumeranter konsumerar on<T>()-strömmar.

DomainEvent: Basgränssnitt. Varje händelse har occurredAt. Viktiga kategorier: arbetsyta/agent, PR/granskning, meddelanden, ärenden, pipeline, möten/kalender, identitet, stationer, observerbarhet.

Möten och kalender

Möte: En lokalt inspelad och transkriberad mötessession. Fångar mikrofon- och systemljud, transkriberar på enheten med en valbar ASR-modell (Parakeet TDT v3 som standard; Parakeet TDT v2, Whisper large-v3-turbo och Whisper base.en är alternativ), diariserar talare och sammanfattar till anteckningar, åtgärdspunkter och beslut. Den valda ASR-modellen tvångsinstalleras vid start och inspelningsfunktionerna tänds efter en omstart. Arbetsyteavgränsat; stannar på maskinen.

MeetingSegment: Ett transkriberat ljudfönster, talarmärkt (me/them) med en diariseringsetikett och millisekundsförskjutningar.

MeetingActionItem / MeetingDecision: Strukturerade utdata som sammanfattningspipelinen tar fram och lagrar som separata rader. Åtgärdspunkter kan länkas till ett ärende.

CalendarEvent: En synkad Google Calendar-post som hör till en arbetsyta och ett anslutet konto. Skild från ett möte: en händelse är ett schemalagt åtagande; ett möte är en inspelad session. Länkas ett-till-ett via en MeetingCalendarLink.

CalendarAccount: Ett anslutet Google-konto, per arbetsyta och e-postadress. OAuth-refresh-tokens lagras på serversidan som google_*-nycklar i <dataDir>/secrets.json och når aldrig en klient; device code-flödet slutförs på servern. En flagga authExpiredAt driver banderollen för återanslutning.

Arkitekturtermer

Clean Architecture: Beroenderegel: Presentation → Application/Providers → Domain ← Infrastructure. Domänen har noll infrastrukturimporter.

Portar och adaptrar: Domänen definierar abstrakta gränssnitt (portar); infrastrukturen tillhandahåller konkreta implementationer (adaptrar). Sammansättningsroten binder dem.

Delad kärna: Entiteter, värdeobjekt, portar och tjänster i core/domain/ som delas av 3+ funktioner.

Funktionsorienterad: Koden är organiserad efter affärsdomän (agenter, pipelines, meddelanden) i stället för efter tekniskt lager.

Multiplayer, identitet och hastighet

Principal: Ett förseglat värde som förenar människor och agenter i den enda aktörabstraktionen – UserPrincipal(userId) eller AgentPrincipal(agentId). Varje meddelande, ärende, granskning, plan och körningslogg tillskrivs genom en Principal.

Användare: En mänsklig identitet, lagrad i global.db och därför global över arbetsytor. Den principal som skapar en arbetsyta blir dess ägare – stämplad på Workspace.ownerUserId med en medlemsrad för ägarrollen i samma operation. Andra ansluter via inbjudan eller SSO.

WorkspaceMember / WorkspaceRole: En medlemsrad som binder en användare till en arbetsyta i en roll (owner / admin / member / viewer / guest). Medlemskapet – inte en parkopplingsnyckel – är åtkomstgränsen. Behörigheter per repo hindrar medlemskapet från att ge fler privilegier än kodvärden.

ParticipantPresence: Flyktig närvaro för en principal (status, locus, markör, skrivande, en agents livestatus och pågående kostnad). Sparas aldrig; hubbas av servern; filtreras på repo-behörighet före utskicket.

Följläge: Klicka på en avatar för att följa dess viewport tills du agerar, och koppla då loss. Fungerar för människor och för agenter (“se en agent arbeta”).

Autonomireglage: En kontroll per yta och per agent – propose-only / act-with-approval / act-freely – implementerad som en namngiven profil ovanpå lagret för åtgärdsräcken.

ActionClass: En sluten mängd av 13 effektklasser (fileDelete, gitPush, prCreate, networkEgress, processSpawn, enclosureControl, …). Varje muterande verktyg deklarerar sina klasser; räckesmotorn löser upp allow / prompt / deny per omfattning (space > agent > workspace > mode preset > built-in default).

WriteLedger / idempotensnyckel: Varje mutation bär en klientgenererad idempotensnyckel (UUIDv7, per logisk åtgärd). Liggaren, som är avgränsad till arbetsytan, tar bort dubbletter innan hanteraren körs; en repris returnerar det byte-identiska ursprungliga resultatet. Gör återanslutning och flera klienter säkra till sin konstruktion.

Inkorgen “Behöver mig”: En kö över alla pelare med en strikt regel – en post visas bara om den blockerar något (en agent, en sammanslagning, en synk) eller uttryckligen efterfrågar operatören.

Plan Studio: Den interaktiva planeringsytan – redigerbara typade DAG-planer med kostnad, tid och risk per steg, och partiellt godkännande.

Granskningsberäkning: Granskningsberäkning på serversidan för en PR (grafframtagna kohorter, typade diagram, visuella diffar, API-kontraktsdiffar, grindar över flera axlar) betjänad över review_studio.* och invävd i fliken Granskning.

Granskningsyta: Den enda bakomliggande ytan för en PR (läge review, typ pr), skapad idempotent och kopplad till PR:en via en ReviewSpaceAssociation. Varje granskare registrerar sina fynd i den, och det är det som gör dem jämförbara; dess isolerade worktree har PR:en utcheckad på sin head.

Granskningsnod: Den strukturerade enheten för ett AI-granskningsfynd: typ (bug, suggestion, recommendation, question, ticket), prioritet P0–P3, en triage-trippel av kategori/allvarlighetsgrad/insats, ett fil-och-rad-ankare, ett valfritt förslag på åtgärd och en konfidenspoäng. Registreras med add_review_node; utfallet beräknas ur noder, inte prosa.

Redo för konsensus: Den granskningsnodsstatus som bara nås när en kollegagranskare bekräftar ett fynd – en agent kan inte bekräfta sitt eget. Knappen Publicera till GitHub på fliken Granskning skickar varje kvarvarande öppet fynd (selection: all_open); MCP-verktyget publish_review_to_github använder fortfarande som standard bara kollegabekräftade fynd.

Granskningsnivå: Arbetsytepolicy (light, balanced, thorough) som styr vilka granskare som skickas ut (endast ingenjör; +qa+arkitekt; +säkerhet+prestanda) och var fynd under tröskeln visas. Tar aldrig bort ett fynd.

Granskningsaxel: En av fem bedömningsbanor per granskning: correctness, security och testGap hämtas ur granskarnas fynd; visual och apiContract är deterministiska. Grindade axlar vävs in i utfallet och kan bara göra det mer allvarligt – en partial- eller unavailable-grind håller kvar utfallet i stället för att passera det.

Granskningsutfall: ship, hold eller block. Varje P0-fynd med konfidens ≥ 0.7 blockerar; varje annat P0 eller något P1 håller; annars ship. En grindad axel som fallerar tvingar fram block och kan inte överröstas av fynd.

Flotta och utvärderingar

cc_worker: En headless-binär i ren Dart som kör flottan. Parkopplas med en cc_server, deklarerar sin värds förmågor, hämtar leasade jobb, utför dem och strömmar processhändelser tillbaka. Håller inget varaktigt tillstånd – en auktoritativ server, N dumma lemmar.

JobSpec: Den typade specifikationen för allt körbart (agentkörning, pipelinesteg, kodindex, golden-render, benchmark, eval-batch).

Eval-svit: En arbetsyteavgränsad utvärderingsdefinition (prompt, målagent och läge, bedömare). Fem startsviter sås in när en arbetsyta skapas; Observability → Kvalitet listar dem.

Driftsättning och klienter

Arkitektur med tunna klienter: Ingen klient öppnar databasen; en headless cc_server-process äger datan och betjänar den över WebSocket-RPC. Varje klient (skrivbord, webb, telefon) är en renderare över den enda RPC-anslutningen.

cc_server: Den headless serverbinären (ren Dart, ingen Flutter-motor). Äger Drift/SQLite-databasen, betjänar repo-RPC över WebSocket och kör bakgrundstjänsterna (pipelines, MCP, reconcilers).

ServerConnectionMode: Hur skrivbordet når sin server – local (startar en cc_server på den här maskinen, standard) eller remote (ringer upp en någon annanstans). Webbklienten är alltid remote.

RemoteRpcClient: Den transportagnostiska JSON-RPC-klient som varje tunn klient använder för att tala med sin server – över WSS, loopback eller den förmedlade relän.

Arbetsyteavgränsning per anrop: Servern är tillståndslös – det finns ingen arbetsytebindning per session, så flera klienter på en server delar aldrig en “aktuell arbetsyta”. Varje arbetsyteavgränsat repo/call och sub/subscribe måste bära workspace_id i sina args; ett saknat eller oregistrerat id avvisas innan någon databas öppnas. Åtkomsten grindas sedan av arbetsytemedlemskap och roll, inte av sessionen.

cc_remote: Telefonens tunna klient – en Flutter-webb-PWA som fjärrstyr flottan över den förmedlade relän, med en verktygspolicy som nekar som standard.

cc_signaling_server: En tillståndslös WebSocket-reläbroker som hostar inbjudningsgrindade rum – en dum relä som bara vidarebefordrar end-to-end-förseglade frames, håller inga appdata och aldrig ser parkopplings-PSK:n.