Глосарій

Основні сутності

Агент: ШІ-працівник з ідентичністю, роллю, навичками та адаптером. Належить рівно до одного робочого простору. Головний актор системи.

Адаптер: Виконавець, який провадить хід агента. Постачаються два: Control Center (вбудований) — внутрішньопроцесний harness, що спілкується з постачальниками моделей — і Claude Code через claude -p. Cursor, Codex, Anthropic, OpenAI та решта — це постачальники на вбудованому адаптері, а не окремі CLI. Див. Керувати адаптерами та моделями.

Робочий простір: Найвищий ізоляційний тенант. Групує агентів, репозиторії, простори, тікети, пам’ять і конвеєри. Ізоляція структурна, а не конвенційна: кожен робочий простір має власний файл SQLite (<dataDir>/<workspaceId>/workspace.db), тож читання крізь робочі простори не компілюється. Кожен маршрут у застосунку має префікс /workspaces/:workspaceId — див. карту маршрутів.

Хост коду: Хостинг коду — GitHub, GitLab або Bitbucket Cloud. Хост коду — властивість кожного репозиторію, яку зчитують з його remote origin під час реєстрації, і він вибирає API-адаптер та облікові дані цього репозиторію. Один робочий простір може містити репозиторії на всіх трьох; агрегувальні поверхні (вхідні, черга PR) розгалужуються на кожен представлений хост коду, зливають результати та ізолюють збої, тож недосяжний хост коду ніколи не спорожнює решту. Хости коду різняться тим, що підтримують — див. таблицю можливостей у Підключити хост коду.

Репозиторій: Git-репозиторій, зареєстрований у робочому просторі. Прив’язаний до робочого простору — той самий checkout, зареєстрований у двох робочих просторах, — це два незалежні рядки з двома ідентифікаторами; ідентичність репозиторію між робочими просторами визначається шляхом у файловій системі, ніколи не ідентифікатором. Реєстрація вимагає git work tree, чий remote origin указує на підтримуваний хост коду. Кожен репозиторій несе цей хост коду (github / gitlab / bitbucket), який вибирає API-адаптер і облікові дані для нього.

Ізольований репозиторій: Прив’язаний до робочого простору worktree зареєстрованого репозиторію. Copy-on-write через rift там, де цей native постачається; git worktree на Windows. Розгортається на кожен простір — кожна розмова в цьому просторі поділяє один checkout, — тож агенти ніколи не змінюють джерело.

Простір: Прив’язаний до робочого простору контейнер співпраці з людськими та агентними учасниками, збереженим Mode, статусом розгортання та SpaceKind (topic / agentPeer / system / pr / slack), який визначає, як його розділяють на секції, приглушують, позначають бейджем і прибирають. Він володіє ізольованими worktree, які поділяють його розмови (copy-on-write через rift; git worktree на Windows).

Розмова: Один потік повідомлень у просторі, з власним ідентифікатором, історією та контекстом запуску агента. Розмови в просторі рівноправні — немає первинного чи «головного» потоку. Кожна відкривається як вкладка редактора; стан непрочитаного в просторі агрегує їх усі.

Гілка: Розмова, у якої задано anchorMessageId: прив’язана до одного повідомлення сусідньої розмови в тому самому просторі, з новим контекстом агента, засіяним цим повідомленням-якорем. Лише один рівень — гілки ніколи не прив’язуються до гілок.

Тікет: Агрегат одиниці роботи. Незалежний від постачальника: типово local, з адаптерами синхронізації для Linear, GitHub Issues, Jira Cloud і ClickUp — хоч жодна поверхня в застосунку не створює з’єднання синхронізації. Підтримує ієрархію, зв’язки та делегування. Призначення агенту фіксує відповідальність і нічого не запускає; призначення команді — виняток (TeamRoutingService запускає лідера).

Конвеєр: Робочий процес на основі DAG, що зчіплює кроки (запуск агента, скрипти, умови). Визначається шаблонами; виконується як запуски.

Об’єкти-значення

AgentRole: Перелічувана роль (CEO, coder, reviewer, QA, designer, security, devops, PM, general). Визначає персону, доступ до пам’яті та ієрархію.

AgentSkills: Регістронезалежний набір ідентифікаторів навичок, який додає до промптів релевантний контекст під час запуску.

Джерело навичок: GitHub-репозиторій, зареєстрований на робочий простір як каталог навичок. Недовірене за побудовою: метадані репозиторію лише для показу, і кожне встановлення проходить fail-closed шлюз сканування, перш ніж будь-який вміст потрапить на диск чи в промпт. Див. Встановлювати й керувати навичками.

skills-lock.json: Маніфест установлених навичок на кожен робочий простір: для кожної — репозиторій-джерело, шлях у репозиторії, зафіксований коміт і зведений хеш вмісту. Встановлення, оновлення та видалення підтримують його в актуальному стані; verify_skills звіряє його з диском.

Шлюз запусків агентів: Loopback-ендпоінт у cc_server, який застосовує політику дій усередині пісочниці агента. Кожен push агента в GitHub спрямовується на нього, перевіряється за правилом Надіслати на віддалений репозиторій і передається з токеном запису, якого агент ніколи не має; команди Bash у Claude Code перевіряються через хук на тому самому ендпоінті. Див. Пісочниця та безпека.

Режим: chat, plan, review або orchestrate. Зберігається на простір, тож один агент може перебувати в різних режимах у різних просторах; усі розмови в просторі поділяють його. Обмежує системний промпт, правила запису пісочниці та список дозволених інструментів MCP. Композер пропонує лише chat, plan та orchestrate; chat позначено як «Агент».

SandboxBackend: microvm (ізольована ВМ — єдиний бекенд з межею ядра, застосовується до інтерактивних терміналів), native (Seatbelt на macOS, bubblewrap на Linux і WSL2) або none. Опитується один раз під час завантаження; native застосовується до запуску агента, коли доступний, загортаючи CLI Claude Code та інструмент bash harness. Windows не має нативного бекенда, а Linux потребує bwrap і socat, тож запуски там незагорнуті; --sandbox off свідомо відмовляється від нього.

Rig: Одноразова машина, якою агент керує в реальному часі — ізольований браузер або робочий стіл Linux, керований хостом емулятор Android чи симулятор iOS або ізольований термінал. Стежать у реальному часі через його власний канал повної роздільності, а перехоплення керування забезпечує сервер. Прив’язаний до розмови, тож вкладка людини й виклики агента browser_use / computer_use / mobile_use / ios_use звертаються до однієї типової машини. Див. Rigs та ізольовані середовища.

Ізольоване середовище: Сильніша межа rig на базі ВМ — межа ядра, одноразовий оверлейний диск, мережевий шлюз із забороною за замовчуванням і брокер облікових даних. Rig Android та iOS одноразові, але використовують мережу, керовану хостом, і не заявляють цієї межі. Керування будь-яким rig використовує клас обмежень enclosureControl.

RunCost: Облік токенів/вартості (вхідні токени, вихідні токени, оцінена вартість у центах) для одного запуску агента.

WakeReason: Чому агента запущено. Шість значень: повідомлення користувача, призначення тікета, повторний запуск після збою, завершення дочірнього тікета, запланований heartbeat-продовження та крок конвеєра.

Порти

SandboxPort: Керує життєвим циклом пісочниці (перевірка, запуск, події, exec, знищення).

CredentialBrokerPort: Карбує обмежені облікові дані для запуску пісочниці — лише читання для середовища агента, запис лише для серверного шляху push — і відкликає їх під час згортання.

GitRepoInspectorPort: Витягує метадані (owner, repo, branch) з локального шляху Git-репозиторію.

EmbeddingPort: Створює одиничні за нормою вектори текстових вбудовувань для семантичного пошуку.

NotificationPort: Показує нативні сповіщення робочого столу з дотриманням обмежень за категорією/маршрутом.

TicketProviderPort: Незалежна від постачальника межа до бекенда тікетів (створити, отримати, перелічити, оновити, змінити стан, призначити).

PipelineEnginePort: Запускає запуск конвеєра за шаблоном, розв’язуючи викликачів від конкретного рушія.

Доменні сервіси

AgentDispatchService: Запускає запуски агентів: створює ізольовані репозиторії, будує промпти, створює журнали запусків, повертає потоки подій у реальному часі.

TicketWorkflowService: Доменний рушій життєвого циклу тікетів з точкою контролю мутацій на основі оптимістичної конкурентності та забезпеченням ізоляції робочих просторів. Граф переходів, який він забезпечує, зв’язує лише агентів і автоматизацію; зміни з інтерфейсу, ініційовані користувачем, передають force: true й обходять його. Для призначення на агента немає диспетчера тікетів — запуском володіє AgentDispatchService, і призначення тікета агенту не запускає нічого. Призначення тікета команді — виняток (TeamRoutingService запускає лідера).

PipelineEngine: Оркеструє виконання запусків: запускає запуски, планує кроки, зберігає стан, обробляє роутери/з’єднання/continue-on-fail, відновлює незавершені запуски після перезапуску.

PipelineTriggerDispatcher: Підписується на доменні події та автоматично запускає відповідні запуски конвеєрів для увімкнених тригерів.

MemoryAccessPolicy: Розв’язує й забезпечує дозволи ролі агента на доступ до пам’яті в доменах.

HarnessCostCalculator: Оцінює використання токенів вбудованого harness у RunCost за каталогом models.dev. Запуск зберігає цей облік у журналі запуску.

BudgetEnforcementService: Обчислює місячні витрати на агента та блок перед запуском (checkInvocationBlock). Цей блок використовують лише відновлювальні реконсилятори (OrphanRunReaper, StrandedTicketReconciler), ніколи — звичайний запуск користувача чи агента.

BudgetGovernanceService: Оцінює місячні витрати на агента після кожного запуску — м’який поріг записує попереджувальний інцидент; вичерпання записує жорсткий інцидент і перемикає життєвий цикл агента на paused.

Події

DomainEventBus: Внутрішньопроцесна широкомовна шина публікації/підписки для міжфічевої взаємодії. Події типізовані; підписники споживають потоки on<T>().

DomainEvent: Базовий інтерфейс. Кожна подія має occurredAt. Ключові категорії: робочий простір/агент, PR/перевірка, повідомлення, тікети, конвеєр, зустрічі/календар, ідентичність, rig, спостережуваність.

Зустрічі та календар

Зустріч: Локально записана й транскрибована сесія зустрічі. Захоплює звук мікрофона й системи, транскрибує на пристрої вибраною моделлю ASR (типово Parakeet TDT v3; альтернативи — Parakeet TDT v2, Whisper large-v3-turbo і Whisper base.en), розділяє мовців і резюмує в нотатки, пункти дій і рішення. Вибрану модель ASR примусово встановлюють під час завантаження, а операції запису стають доступними після одного перезапуску. Прив’язана до робочого простору; залишається на машині.

MeetingSegment: Одне транскрибоване вікно аудіо, позначене мовцем (me/them), з міткою діаризації та зсувами в мілісекундах.

MeetingActionItem / MeetingDecision: Структуровані результати, витягнуті конвеєром резюмування та збережені як окремі рядки. Пункти дій можуть посилатися на тікет.

CalendarEvent: Синхронізований запис Google Calendar, прив’язаний до робочого простору й підключеного облікового запису. Відрізняється від зустрічі: подія — це заплановане зобов’язання; зустріч — записана сесія. Пов’язаний один-до-одного через MeetingCalendarLink.

CalendarAccount: Підключений обліковий запис Google, на кожен робочий простір та email. Токени оновлення OAuth зберігаються на сервері як ключі google_* у <dataDir>/secrets.json і ніколи не потрапляють до клієнта; потік device-code завершується на сервері. Прапорець authExpiredAt керує банером повторного підключення.

Терміни архітектури

Clean Architecture: Правило залежностей: Presentation → Application/Providers → Domain ← Infrastructure. Домен не має жодного імпорту з інфраструктури.

Порти та адаптери: Домен визначає абстрактні інтерфейси (порти); інфраструктура надає конкретні реалізації (адаптери). Корінь композиції зв’язує їх.

Спільне ядро: Сутності, об’єкти-значення, порти й сервіси core/domain/, спільні для 3+ фіч.

Первинність фіч: Код організовано за бізнес-доменом (агенти, конвеєри, повідомлення), а не за технічним шаром.

Спільна робота, ідентичність і швидкість

Principal: Запечатане значення, що об’єднує людей і агентів в єдину абстракцію актора — UserPrincipal(userId) або AgentPrincipal(agentId). Кожне повідомлення, тікет, перевірка, план і журнал запуску атрибутуються через Principal.

Користувач: Людська ідентичність, збережена в global.db і тому глобальна для всіх робочих просторів. Принципал, який створює робочий простір, стає його власником — зафіксованим у Workspace.ownerUserId разом із рядком членства з роллю власника в тій самій операції. Інші приєднуються за запрошенням або через SSO.

WorkspaceMember / WorkspaceRole: Рядок членства, який прив’язує користувача до робочого простору з роллю (owner / admin / member / viewer / guest). Членство — а не ключ спарювання — є межею доступу. Дозволи на окремі репозиторії не дають членству перевершити хост коду.

ParticipantPresence: Ефемерна обізнаність про принципала (статус, місце, курсор, набір тексту, живий статус агента та поточна вартість). Ніколи не зберігається; розподіляється через сервер; фільтрується за дозволами репозиторію перед розсиланням.

Режим стеження: Натисніть на аватар, щоб їхати за його в’юпортом, доки не дієте самі, тоді відчепіться. Працює і для людей, і для агентів («дивіться, як працює агент»).

Регулятор автономності: Елемент керування на кожен простір і кожного агента — propose-only / act-with-approval / act-freely — реалізований як іменований профіль над сховищем обмежень дій.

ActionClass: Закрита множина з 13 класів ефектів (fileDelete, gitPush, prCreate, networkEgress, processSpawn, enclosureControl, …). Кожен інструмент, що змінює стан, оголошує свої класи; рушій обмежень розв’язує allow / prompt / deny для кожної області (простір > агент > робочий простір > пресет режиму > вбудоване типове).

WriteLedger / ключ ідемпотентності: Кожна мутація несе згенерований клієнтом ключ ідемпотентності (UUIDv7, на кожну логічну дію). Прив’язаний до робочого простору ledger прибирає дублікати, перш ніж виконатися обробник; повтор повертає байт-у-байт ідентичний оригінальний результат. Робить повторне підключення й роботу кількох клієнтів безпечними за побудовою.

Вхідні «Потрібен я»: Черга, що перетинає всі напрями, із суворим правилом — елемент з’являється лише якщо він блокує щось (агента, злиття, синхронізацію) або явно просить оператора.

Plan Studio: Інтерактивна поверхня планування — редаговані плани як типізований DAG, з вартістю, часом і ризиком на крок та частковим схваленням.

Обчислення перевірки: Серверне обчислення перевірки PR (когорти, виведені з графа, типізовані діаграми, візуальні diff, diff контрактів API, гейти за багатьма осями), яке віддається через review_studio.* і вкладається у вкладку Рев’ю.

Простір перевірки: Єдиний опорний простір PR (режим review, тип pr), створюваний ідемпотентно та пов’язаний із PR через ReviewSpaceAssociation. Кожен рецензент оформлює в ньому зауваження, і саме це робить їх порівнюваними; його ізольований worktree має PR, вилучений на його head.

Вузол перевірки: Структурована одиниця зауваження ШІ-перевірки: вид (bug, suggestion, recommendation, question, ticket), пріоритет P0–P3, трійка тріажу категорія/серйозність/зусилля, прив’язка до файлу й рядка, необов’язкова запропонована правка та оцінка впевненості. Оформлюється через add_review_node; вердикт обчислюють із вузлів, а не з тексту.

Готовий до консенсусу: Статус вузла перевірки, якого досягають лише коли рівний рецензент підтверджує зауваження — агент не може підтвердити власне. Кнопка Опублікувати на GitHub на вкладці Рев’ю надсилає кожне відкрите зауваження, що залишилося (selection: all_open); інструмент MCP publish_review_to_github усе ще типово бере лише підтверджені рівними зауваження.

Рівень перевірки: Політика робочого простору (light, balanced, thorough), яка визначає, які рецензенти розгортаються (лише інженер; +qa+architect; +security+perf) і де показуються зауваження нижче порога. Ніколи не видаляє зауваження.

Вісь перевірки: Одна з п’яти смуг оцінювання на перевірку: correctness, security і testGap походять із зауважень рецензентів; visual і apiContract детерміновані. Осі під гейтом вкладаються у вердикт і можуть зробити його лише суворішим — гейт зі станом partial або unavailable утримує вердикт, а не пропускає його.

Вердикт перевірки: ship, hold або block. Будь-яке зауваження P0 з упевненістю ≥ 0.7 блокує; будь-яке інше P0 або будь-яке P1 утримує; інакше ship. Вісь під гейтом, що не пройшла, примусово дає block, і зауваження не можуть її переважити.

Флот і eval

cc_worker: Бінарник headless-виконавця флоту на чистому Dart. Спарюється з cc_server, оголошує можливості свого хоста, забирає орендовані завдання, виконує їх і транслює події процесу назад. Не має довготривалого стану — один авторитетний сервер, N німих кінцівок.

JobSpec: Типізована специфікація всього, що виконується (запуск агента, крок конвеєра, індексація коду, golden-render, бенчмарк, пакет eval).

Eval-набір: Визначення оцінювання, прив’язане до робочого простору (промпт, цільовий агент і режим, оцінювачі). П’ять стартових наборів засіваються під час створення робочого простору; Спостережуваність → Якість показує їх.

Розгортання та клієнти

Архітектура тонкого клієнта: Жоден клієнт не відкриває базу даних; headless-процес cc_server володіє даними й віддає їх через WebSocket RPC. Кожен клієнт (десктоп, веб, телефон) — рендерер поверх цього одного RPC-з’єднання.

cc_server: Бінарник headless-сервера (чистий Dart, без рушія Flutter). Володіє базою даних Drift/SQLite, віддає repo-RPC через WebSocket і запускає фонові сервіси (конвеєри, MCP, реконсилятори).

ServerConnectionMode: Як десктоп досягає свого сервера — local (запустити cc_server на цій машині, типово) або remote (під’єднатися до нього деінде). Вебклієнт завжди remote.

RemoteRpcClient: Незалежний від транспорту клієнт JSON-RPC, який кожен тонкий клієнт використовує для зв’язку зі своїм сервером — через WSS, loopback або брокерований ретранслятор.

Прив’язка до робочого простору на кожен виклик: Сервер безстановий — немає прив’язки робочого простору до сесії, тож кілька клієнтів на одному сервері ніколи не поділяють «поточний робочий простір». Кожен виклик repo/call і sub/subscribe у межах робочого простору має нести workspace_id у своїх аргументах; відсутній або незареєстрований ідентифікатор відхиляють, перш ніж відкриється будь-яка база даних. Далі доступ обмежує членство в робочому просторі та роль, а не сесія.

cc_remote: Телефонний тонкий клієнт — Flutter веб-PWA, який віддалено керує флотом через брокерований ретранслятор із політикою інструментів «заборонено за замовчуванням».

cc_signaling_server: Безстановий брокер-ретранслятор WebSocket, що розміщує кімнати з доступом за запрошенням — нерозумний ретранслятор, який пересилає лише кадри, запечатані наскрізним шифруванням, не зберігає даних застосунку й ніколи не бачить PSK спарювання.