Глоссарий

Основные сущности

Агент: ИИ-работник с идентичностью, ролью, навыками и адаптером. Принадлежит ровно одному рабочему пространству. Главный актор системы.

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

Рабочее пространство: Тенант изоляции верхнего уровня. Объединяет агентов, репозитории, пространства, тикеты, память и конвейеры. Изоляция структурна, а не условна: у каждого рабочего пространства собственный файл SQLite (<dataDir>/<workspaceId>/workspace.db), поэтому чтение между рабочими пространствами не компилируется. Каждый маршрут в приложении начинается с /workspaces/:workspaceId — см. карту маршрутов.

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

Репозиторий: Git-репозиторий, зарегистрированный внутри одного рабочего пространства. Привязан к рабочему пространству — одна и та же рабочая копия, зарегистрированная в двух рабочих пространствах, — это две независимые строки с двумя идентификаторами; идентичность репозитория между рабочими пространствами определяется путём в файловой системе, а не идентификатором. Регистрация требует рабочего дерева git, удалённый репозиторий origin которого указывает на поддерживаемый хост кода. Каждый репозиторий несёт свой хост кода (github / gitlab / bitbucket), который выбирает используемые для него API-адаптер и учётные данные.

Изолированный репозиторий: Worktree в границах рабочего пространства для зарегистрированного репозитория. Copy-on-write через rift там, где этот нативный компонент поставляется; git worktree в Windows. Создаётся для каждого пространства — каждый разговор в этом пространстве использует одну рабочую копию, — поэтому агенты никогда не изменяют исходный репозиторий.

Пространство: Контейнер совместной работы в границах рабочего пространства с людьми и агентами-участниками, сохраняемым 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 (заключённая VM — единственный бэкенд с границей ядра, применяемый к интерактивным терминалам), 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 на базе VM — граница ядра, одноразовый дисковый оверлей, сетевой шлюз, запрещающий по умолчанию, и брокер учётных данных. Rig для Android и iOS одноразовы, но используют управляемую хостом сеть и не заявляют эту границу. Управление любым rig использует класс ограничений enclosureControl.

RunCost: Учёт токенов и стоимости (входные токены, выходные токены, оценка стоимости в центах) для одного запуска агента.

WakeReason: Почему был запущен агент. Шесть значений: сообщение пользователя, назначение тикета, повторный запуск восстановления после сбоя, завершение дочернего тикета, запланированное контрольное напоминание и шаг конвейера.

Порты

SandboxPort: Управляет жизненным циклом песочницы (проверка, запуск, события, exec, уничтожение).

CredentialBrokerPort: Выпускает ограниченные учётные данные для запуска песочницы — только чтение для окружения агента, запись только для серверного пути push — и отзывает их при сворачивании.

GitRepoInspectorPort: Извлекает метаданные (владелец, репозиторий, ветка) из локального пути к 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, отдельно для каждого рабочего пространства и адреса электронной почты. Токены обновления 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, на логическое действие). Журнал в границах рабочего пространства устраняет дубликаты до запуска обработчика; повтор возвращает байт-в-байт исходный результат. Делает переподключение и работу нескольких клиентов безопасными по построению.

Входящие: Очередь по всем столпам со строгим правилом — элемент появляется, только если он блокирует что-то (агента, слияние, синхронизацию) или явно запрашивает оператора.

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; вердикт вычисляется по узлам, а не по прозе.

Consensus-ready: Статус узла проверки, достигаемый только когда коллега-ревьюер подтверждает замечание — агент не может подтвердить своё собственное. Кнопка Опубликовать на 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. Ось под шлюзом с результатом fail принудительно даёт block, и замечания не могут её переголосовать.

Флот и eval

cc_worker: Бинарник исполнителя флота на чистом Dart без графического интерфейса. Сопрягается с cc_server, объявляет возможности своего хоста, забирает арендованные задания, выполняет их и передаёт события процессов обратно. Не хранит постоянного состояния — один авторитетный сервер, N безмозглых конечностей.

JobSpec: Типизированная спецификация всего исполняемого (запуск агента, шаг конвейера, индекс кода, эталонный рендеринг, бенчмарк, пакет eval).

Eval-набор: Определение оценки в границах рабочего пространства (промпт, целевой агент и режим, грейдеры). При создании рабочего пространства создаются пять стартовых наборов; «Наблюдаемость → Качество» перечисляет их.

Развёртывание и клиенты

Архитектура тонкого клиента: Ни один клиент не открывает базу данных; процесс 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).