Szójegyzék

Alapentitások

Ügynök: Egy MI-munkavállaló identitással, szereppel, készségekkel és egy adapterrel. Pontosan egy munkaterülethez tartozik. A rendszer elsődleges szereplője.

Adapter: Az a futtató, amely végrehajtja az ügynök egy körét. Kettő érkezik: a Control Center (built-in) — a folyamaton belüli harness, amely a modellszolgáltatókkal beszél — és a Claude Code a claude -p paranccsal. A Cursor, a Codex, az Anthropic, az OpenAI és a többi szolgáltató a beépített adapteren, nem külön CLI. Lásd: Adapterek és modellek kezelése.

Munkaterület: A legfelső szintű elszigetelési bérlő. Ügynököket, repókat, tereket, jegyeket, memóriát és pipeline-okat csoportosít. Az elszigetelés strukturális, nem konvenció kérdése: minden munkaterületnek saját SQLite-fájlja van (<dataDir>/<workspaceId>/workspace.db), ezért a munkaterületek közötti olvasás nem fordul le. Minden alkalmazáson belüli útvonal a /workspaces/:workspaceId előtagot viseli — lásd az útvonaltérképet.

Kódhoszt: Egy kódhoszt — GitHub, GitLab vagy Bitbucket Cloud. A kódhoszt minden repó tulajdonsága, amelyet regisztráláskor az origin remote-jából olvasunk ki, és ez választja ki a repó API-adapterét és hitelesítő adatait. Egy munkaterület mindhárom szolgáltatáson tarthat repókat; az összesítő felületek (a beérkezett üzenetek, a PR-sor) minden képviselt kódhosztra kiterjednek, egyesítik az eredményeket, és elszigetelik a hibákat, így egy elérhetetlen kódhoszt soha nem üríti ki a többit. A kódhosztok abban különböznek, mit támogatnak — lásd a képességtáblázatot a Kódhoszt csatlakoztatása oldalon.

Repó: Egy munkaterületen belül regisztrált Git-repó. Munkaterület-hatókörű — ugyanaz a checkout két munkaterületen két független sor két azonosítóval; a repó identitása a munkaterületek között a fájlrendszerbeli útvonal, soha nem az azonosító. A regisztráció olyan git-munkafát követel, amelynek origin remote-ja támogatott kódhosztra mutat. Minden repó hordozza ezt a kódhosztot (github / gitlab / bitbucket), amely kiválasztja a hozzá használt API-adaptert és hitelesítő adatot.

Elszigetelt repó: Egy regisztrált repó munkaterület-hatókörű worktree-je. Copy-on-write a rift révén, ahol ez a natív megoldás elérhető; Windowson git worktree. Térénként provisionálva — az adott tér minden beszélgetése egy checkoutot oszt meg —, így az ügynökök soha nem módosítják a forrást.

Tér: Egy munkaterület-hatókörű együttműködési konténer emberi és ügynök résztvevőkkel, perzisztált Mode-dal, provisionálási állapottal és egy SpaceKind értékkel (topic / agentPeer / system / pr / slack), amely eldönti, hogyan tagolódik, némul el, kap jelvényt és kerül szemétgyűjtésre. Az övéi azok az elszigetelt worktree-k, amelyeket a beszélgetései megosztanak (copy-on-write a rift révén; git worktree Windowson).

Beszélgetés: Egy üzenetfolyam egy Téren belül, saját azonosítóval, előzményekkel és ügynökfuttatási kontextussal. Egy téren a beszélgetések egyenrangúak — nincs elsődleges vagy „fő” folyam. Mindegyik szerkesztőfülként nyílik meg; egy tér olvasatlan állapota az összesen át összesítődik.

Szál: Egy Beszélgetés, amelynek anchorMessageId értéke be van állítva: ugyanazon Tér egy testvérbeszélgetésének egy üzenetéhez horgonyozva, friss ügynök-kontextussal, amelyet az a horgonyüzenet indít. Egy szint mély — a szálak soha nem horgonyoznak szálhoz.

Jegy: A munkaegység-aggregátum. Szállítófüggetlen: alapértelmezésben local, szinkronizációs adapterekkel a Linear, a GitHub Issues, a Jira Cloud és a ClickUp felé — bár az alkalmazásban egyetlen felület sem hoz létre szinkronizációs kapcsolatot. Támogatja a hierarchiát, a hivatkozásokat és a delegálást. Az ügynökhöz rendelés tulajdonjogot rögzít, és semmit nem indít; a csapathoz rendelés a kivétel (TeamRoutingService indítja a vezetőt).

Pipeline: DAG-alapú munkafolyamat, amely lépéseket (ügynökindítás, szkriptek, feltételek) fűz össze. Sablonok definiálják; futásként hajtódik végre.

Értékobjektumok

AgentRole: Felsorolt szerep (CEO, coder, reviewer, QA, designer, security, devops, PM, general). Meghatározza a személyiséget, a memóriahozzáférést és a hierarchiát.

AgentSkills: Kis-nagybetűre érzéketlen készségazonosítók halmaza, amelyek indításkor releváns kontextust injektálnak a promptokba.

Készségforrás: Egy munkaterületenként készségkatalógusként regisztrált GitHub-repó. Konstrukciójánál fogva nem megbízható: a repó metaadatai csak megjelenítésre szolgálnak, és minden telepítés áthalad a hiba esetén elzáró vizsgálati kapun, mielőtt bármilyen tartalom eljutna a lemezre vagy egy promptba. Lásd: Készségek telepítése és kezelése.

skills-lock.json: A telepített készségek munkaterületenkénti jegyzéke: mindegyiknél a forrásrepó, a repón belüli útvonal, a commit, amelyhez rögzítve van, és egy összesített tartalomhash. A telepítések, a frissítések és az eltávolítások naprakészen tartják; a verify_skills ellenőrzi a lemezen lévő állapottal szemben.

Ügynökfuttatási átjáró: Loopback végpont a cc_server-en, amely az ügynök homokozóján belül alkalmazza a műveleti szabályzatot. Az ügynök minden GitHub-pushát ide irányítja, ellenőrzi a Küldés távoli tárolóra szabály alapján, és egy olyan írási tokennel továbbítja, amely soha nincs az ügynök birtokában; a Claude Code Bash parancsait egy hook ellenőrzi ugyanezen a végponton. Lásd a Homokozó és biztonság oldalt.

Mode: chat, plan, review vagy orchestrate. Térénként tárolódik, így egy ügynök különböző tereken különböző módban lehet; egy tér minden beszélgetése ugyanazt osztja. Kapuzza a rendszerpromptot, a homokozó írási szabályait és az MCP-eszközök engedélyezési listáját. A szerkesztő csak a chat, a plan és az orchestrate módot kínálja; a chat címkéje „Agent”.

SandboxBackend: microvm (egy elzárt VM — az egyetlen háttérrendszer kernelhatárral, az interaktív terminálokra alkalmazva), native (Seatbelt macOS-en, bubblewrap Linuxon és WSL2-n) vagy none. Indításkor egyszer vizsgáljuk; a native az ügynökindításra alkalmazódik, ahol elérhető, beburkolva a Claude Code CLI-t és a harness bash eszközét. A Windowsnak nincs natív háttérrendszere, a Linuxnak pedig bwrap és socat kell, így az ottani futások beburkolás nélkül maradnak; a --sandbox off szándékosan lemond róla.

Állomás: Egy eldobható gép, amelyet egy ügynök valós időben vezet — elzárt böngésző vagy Linux asztal, gazdagép által kezelt Android-emulátor vagy iOS-szimulátor, vagy elzárt terminál. Élőben figyelhető a saját teljes felbontású sávján, a szerveroldalon kikényszerített átvétellel. Egy beszélgetéshez kötött, így az emberi fül és az ügynök browser_use / computer_use / mobile_use / ios_use hívásai egy alapértelmezett gépet címeznek meg. Lásd: Állomások és elszigetelt környezetek.

Elszigetelt környezet: A VM-alapú állomások erősebb határvonala — kernelhatár, eldobható overlay-lemez, alapértelmezésben elzáró hálózati kapu és hitelesítőadat-ügynök. Az Android- és iOS-állomások eldobhatók, de gazdagép által kezelt hálózatot használnak, és nem tartanak igényt erre a határra. Bármely állomás vezetése az enclosureControl korlátosztályt használja.

RunCost: Token- és költségkimutatás (bemeneti tokenek, kimeneti tokenek, becsült költség centre) egyetlen ügynökfutásra.

WakeReason: Miért indult el egy ügynök. Hat érték: felhasználói üzenet, jegy-hozzárendelés, helyreállítási újraindítás hiba után, gyermekjegy befejeződött, ütemezett utánkövető szívverés és pipeline-lépés.

Portok

SandboxPort: A homokozó életciklusát kezeli (probe, launch, events, exec, destroy).

CredentialBrokerPort: Hatáskörrel ellátott hitelesítő adatokat bocsát ki a homokozó indításához — csak olvasásra az ügynök környezetébe, írásra csak a szerveroldali push-útvonal számára —, és visszavonja őket a lebontáskor.

GitRepoInspectorPort: Metaadatokat (owner, repo, branch) nyer ki egy helyi Git-repó útvonalából.

EmbeddingPort: Egységnormájú szövegbeágyazási vektorokat állít elő szemantikus kereséshez.

NotificationPort: Natív asztali értesítéseket jelenít meg, tiszteletben tartva a kategória/útvonal szerinti kapuzást.

TicketProviderPort: Szállítófüggetlen határ egy jegykezelő háttérrendszer felé (create, get, list, update, transition, assign).

PipelineEnginePort: Sablonból indít egy pipeline-futást, leválasztva a hívókat a konkrét motorról.

Domainszolgáltatások

AgentDispatchService: Ügynökfutásokat indít: elszigetelt repókat provisionál, promptokat épít, futásnaplókat hoz létre, élő eseményfolyamokat ad vissza.

TicketWorkflowService: Tiszta domainű jegyéletciklus-motor optimista párhuzamosságú mutációs szűk keresztmetszettel és a munkaterület-elszigetelés kikényszerítésével. Az általa érvényesített átmenetgráf csak az ügynököket és az automatizálást köti; a felhasználó által vezérelt felületi változtatások force: true értéket adnak át, és megkerülik. Ügynök címzett számára nincs jegyküldő — az AgentDispatchService birtokolja az indítást, és egy jegy ügynökhöz rendelése nem indít futást. A jegy csapathoz rendelése a kivétel (TeamRoutingService indítja a vezetőt).

PipelineEngine: A futásvégrehajtást hangolja össze: futásokat indít, lépéseket ütemez, állapotot perzisztál, kezeli a routereket/csatlakozásokat/folytatást hiba esetén, és újraindítás után folytatja a repülés közbeni futásokat.

PipelineTriggerDispatcher: Feliratkozik a domaineseményekre, és az engedélyezett eseményindítókhoz automatikusan elindítja a megfelelő pipeline-futásokat.

MemoryAccessPolicy: Feloldja és érvényesíti az ügynökszerep memóriaengedélyeit a domaineken.

HarnessCostCalculator: A beépített harness tokenhasználatát RunCost értékké árazza a models.dev katalógusból. Az indítás ezt a kimutatást a futásnaplóra perzisztálja.

BudgetEnforcementService: Kiszámítja az ügynökönkénti havi költést és egy indítás előtti blokkolást (checkInvocationBlock). Ezt a blokkolást csak a helyreállítási reconcilerek (OrphanRunReaper, StrandedTicketReconciler) kérdezik le, egy hétköznapi felhasználói vagy ügynökindítás soha.

BudgetGovernanceService: Minden futás után kiértékeli az ügynökönkénti havi költést — egy puha küszöb figyelmeztető incidenst rögzít; a kimerülés kemény incidenst rögzít, és az ügynök életciklusát paused állapotba billenti.

Események

DomainEventBus: Folyamaton belüli, szórásos publish/subscribe busz funkciók közötti kommunikációhoz. Az események típusosak; az előfizetők on<T>() folyamokat fogyasztanak.

DomainEvent: Alapinterfész. Minden eseménynek van occurredAt mezője. Fő kategóriák: munkaterület/ügynök, PR/átnézés, üzenetküldés, jegykezelés, pipeline, megbeszélések/naptár, identitás, állomások, megfigyelhetőség.

Megbeszélések és naptár

Megbeszélés: Helyben rögzített, átírt megbeszélés. Rögzíti a mikrofont és a rendszerhangot, az eszközön írja át egy választható ASR-modellel (alapértelmezésben Parakeet TDT v3; alternatíva a Parakeet TDT v2, a Whisper large-v3-turbo és a Whisper base.en), beszélőkre bontja, és jegyzetekbe, feladatlistákba és döntésekbe foglalja össze. A kiválasztott ASR-modellt indításkor kényszertelepítjük, és a rögzítési műveletek egy újraindítás után válnak elérhetővé. Munkaterület-hatókörű; a gépen marad.

MeetingSegment: Egy átírt hangablak, beszélővel megjelölve (me/them), diarizációs címkével és ezredmásodperc-eltolásokkal.

MeetingActionItem / MeetingDecision: Az összefoglaló pipeline által kinyert strukturált kimenetek, diszkrét sorként tárolva. A feladatlistaelemek egy jegyhez kapcsolódhatnak.

CalendarEvent: Egy munkaterülethez és csatlakoztatott fiókhoz kötött, szinkronizált Google Calendar-bejegyzés. Különbözik a Megbeszéléstől: az esemény egy ütemezett elköteleződés; a Megbeszélés egy rögzített ülés. Egy az egyhez kapcsolódnak egy MeetingCalendarLink révén.

CalendarAccount: Egy csatlakoztatott Google-fiók, munkaterületenként és e-mail-címenként. Az OAuth-frissítő tokenek kiszolgálóoldalon, google_* kulcsként a <dataDir>/secrets.json fájlban tárolódnak, és soha nem jutnak el a klienshez; az eszközkód-folyamat a szerveren fejeződik be. Egy authExpiredAt jelző vezérli az újracsatlakozási sávot.

Architektúra-kifejezések

Tiszta architektúra: Függőségi szabály: Presentation → Application/Providers → Domain ← Infrastructure. A Domainben nulla infrastruktúra-import van.

Portok és adapterek: A domain absztrakt interfészeket (portokat) definiál; az infrastruktúra konkrét megvalósításokat (adaptereket) nyújt. Az összeállítási gyökér köti össze őket.

Közös kernel: core/domain/ entitások, értékobjektumok, portok és szolgáltatások, amelyeket 3+ funkció oszt meg.

Funkcióközpontú: A kód üzleti domain szerint szerveződik (ügynökök, pipeline-ok, üzenetküldés), nem technikai réteg szerint.

Többszereplős mód, identitás és sebesség

Principal: Egy lezárt érték, amely egységesíti az embereket és az ügynököket egyetlen szereplő-absztrakcióként — UserPrincipal(userId) vagy AgentPrincipal(agentId). Minden üzenet, jegy, átnézés, terv és futásnapló egy Principalon keresztül attribútumozódik.

Felhasználó: Egy emberi identitás, a global.db-ben tárolva, ezért globális a munkaterületeken át. Az a principal, aki létrehoz egy munkaterületet, annak tulajdonosává válik — ugyanabban a műveletben a Workspace.ownerUserId mezőn, tulajdonos szerepű tagsági sorral. Mások meghívóval vagy SSO-val csatlakoznak.

WorkspaceMember / WorkspaceRole: Egy tagsági sor, amely egy Felhasználót egy Munkaterülethez köt egy szerepben (owner / admin / member / viewer / guest). A tagság — nem egy párosítási kulcs — a hozzáférési határ. A repónkénti jogosultságok megakadályozzák, hogy a tagság nagyobb jogosultságot adjon, mint a kódhoszt.

ParticipantPresence: Efemer jelenlét egy Principal számára (állapot, hely, kurzor, gépelés, egy ügynök élő állapota és futó költsége). Soha nem perzisztálódik; szerver-hubos; a repó-jogosultság szerint szűrve a szétosztás előtt.

Követési mód: Kattintson egy avatarra, hogy az ő nézetén utazzon, amíg nem cselekszik, majd váljon le. Embereknél és ügynököknél is működik („nézze, ahogy egy ügynök dolgozik”).

Autonómiatárcsa: Térénként és ügynökönkénti vezérlő — propose-only / act-with-approval / act-freely — a műveleti-korlát tároló fölötti nevesített profilként megvalósítva.

ActionClass: 13 effektosztály zárt halmaza (fileDelete, gitPush, prCreate, networkEgress, processSpawn, enclosureControl, …). Minden módosító eszköz deklarálja az osztályait; a korlátmotor hatókörönként allow / prompt / deny döntést hoz (tér > ügynök > munkaterület > mód-preset > beépített alapértelmezés).

WriteLedger / idempotenciakulcs: Minden mutáció hordoz egy kliens által generált idempotenciakulcsot (UUIDv7, logikai műveletenként). A munkaterület-hatókörű ledger a kezelő lefutása előtt deduplikál; egy újrajátszás bájtazonos eredeti eredményt ad vissza. Konstrukciójánál fogva biztonságossá teszi az újracsatlakozást és a többklienst.

Beérkezett: Egy pillérek közötti sor szigorú szabállyal — egy elem csak akkor jelenik meg, ha blokkol valamit (egy ügynököt, egy összefésülést, egy szinkronizálást), vagy kifejezetten az operátort kéri.

Plan Studio: Az interaktív tervezési felület — szerkeszthető, típusos DAG-tervek lépésenkénti költséggel, idővel és kockázattal, valamint részleges jóváhagyással.

Átnézési számítás: Szerveroldali PR-átnézési számítás (gráfból származtatott kohorszok, típusos diagramok, vizuális diffe-ek, API-szerződés-diffek, többtengelyes kapuk), a review_studio.* fölött kiszolgálva és az Átnézés fülbe behajtva.

Átnézési tér: Egy PR egyetlen hátteréül szolgáló tere (mode review, kind pr), idempotensen létrehozva és egy ReviewSpaceAssociation révén a PR-hez kapcsolva. Minden átnéző benne jegyzi fel a megállapításait, ettől lesznek összehasonlíthatók; az elszigetelt worktree-jében a PR az ágának csúcsán van checkoutolva.

Átnézési csomópont: Egy MI-átnézési megállapítás strukturált egysége: fajta (bug, suggestion, recommendation, question, ticket), P0–P3 prioritás, egy kategória/súlyosság/ráfordítás triázs-hármas, egy fájl-és-sor horgony, opcionális javasolt javítás és egy bizonyossági pontszám. Az add_review_node-nal jegyzik fel; az ítélet a csomópontokból számítódik, nem a prózából.

Konszenzusra kész: Az az átnézésicsomópont-állapot, amelyet csak akkor ér el, ha egy társ-átnéző megerősít egy megállapítást — egy ügynök nem erősítheti meg a sajátját. Az Átnézés fül Közzététel a GitHubon gombja minden még nyitott megállapítást elküld (selection: all_open); az MCP-eszköz publish_review_to_github továbbra is csak a társ által megerősített megállapításokat küldi alapértelmezésben.

Átnézési szint: Munkaterület-szabályzat (light, balanced, thorough), amely azt szabályozza, mely átnézők rajzanak ki (csak engineer; +qa+architect; +security+perf), és hol jelennek meg a küszöb alatti megállapítások. Soha nem töröl megállapítást.

Átnézési tengely: Öt átnézésenkénti pontozósáv egyike: a correctness, a security és a testGap az átnézői megállapításokból származik; a visual és az apiContract determinisztikus. A kapuzott tengelyek behajlanak az ítéletbe, és csak súlyosabbá tehetik — egy partial vagy unavailable kapu visszatartja az ítéletet, ahelyett hogy átengedné.

Átnézési ítélet: ship, hold vagy block. Bármely P0 megállapítás ≥ 0,7 bizonyossággal blockot ad; bármely más P0 vagy bármely P1 holdot; egyébként ship az ítélet. Egy kapuzott, megbukó tengely blockot kényszerít, és a megállapítások nem szavazhatják felül.

Flotta és kiértékelések

cc_worker: Egy headless, tiszta Dart nyelvű flottavégrehajtó bináris. Párosul egy cc_server-rel, deklarálja a hosztképességeit, bérbe adott feladatokat húz, végrehajtja őket, és visszafolyatja a folyamateseményeket. Nem tart fenn tartós állapotot — egy hiteles szerver, N buta végtag.

JobSpec: Minden végrehajtható dolog típusos specifikációja (ügynökfutás, pipeline-lépés, code-index, golden-render, benchmark, eval batch).

Kiértékelési csomag: Egy munkaterület-hatókörű kiértékelési definíció (prompt, célügynök és mód, értékelők). Öt kezdő csomag indul a munkaterület létrehozásakor; a Megfigyelhetőség → Minőség listázza őket.

Telepítés és kliensek

Vékonykliens-architektúra: Egyetlen kliens sem nyitja meg az adatbázist; egy headless cc_server folyamat birtokolja az adatokat, és WebSocket RPC-n keresztül szolgálja ki. Minden kliens (asztali, web, telefon) egyetlen RPC-kapcsolat fölötti renderelő.

cc_server: A headless szerverbináris (tiszta Dart, Flutter-motor nélkül). Birtokolja a Drift/SQLite adatbázist, repo-RPC-t szolgál ki WebSocketen, és futtatja a háttérszolgáltatásokat (pipeline-ok, MCP, reconcilerek).

ServerConnectionMode: Hogyan éri el az asztali kliens a szerverét — local (egy cc_server indítása ezen a gépen, ez az alapértelmezés) vagy remote (egy máshol lévőhöz csatlakozás). A webes kliens mindig remote.

RemoteRpcClient: A szállításfüggetlen JSON-RPC kliens, amelyet minden vékonykliens a szerverével való kommunikációhoz használ — WSS-en, loopbacken vagy a közvetített relayen keresztül.

Hívásonkénti munkaterület-hatókör: A szerver állapotmentes — nincs munkamenetenkénti munkaterület-kötés, így egy szerveren több kliens soha nem oszt meg egy „aktuális munkaterületet”. Minden munkaterület-hatókörű repo/call és sub/subscribe hívásnak hordoznia kell a workspace_id értéket az argumentumaiban; a hiányzó vagy nem regisztrált azonosítót elutasítjuk, mielőtt bármilyen adatbázis megnyílna. A hozzáférést ezután a munkaterület-tagság és a szerep kapuzza, nem a munkamenet.

cc_remote: A telefonos vékonykliens — egy Flutter web PWA, amely a közvetített relayen keresztül távolról vezérli a flottát, alapértelmezésben elzáró eszközszabályzattal.

cc_signaling_server: Egy állapotmentes WebSocket relay broker, amely meghívásra korlátozott szobákat szolgál ki — egy buta relay, amely csak végpontok között lezárt kereteket továbbít, nem tartalmaz alkalmazásadatokat, és soha nem látja a párosítási PSK-t.