---
doc_id: REF-CK8S-0007
type: glossary
title: "kodex — глоссарий новой платформы"
status: active
owner_role: KM
created_at: 2026-04-21
updated_at: 2026-04-23
related_issues: [470, 488]
related_prs: []
approvals:
  required: ["Owner"]
  status: approved
  request_id: "owner-2026-04-21-refactoring-wave1"
  approved_by: "ai-da-stas"
  approved_at: 2026-04-21
---

# Глоссарий новой платформы

## Общие правила
- В документации и PR по умолчанию используются русские термины.
- Английский остаётся только там, где это имя поля, API, протокола, файла, внешнего объекта или точного технического идентификатора.
- Если для понятия есть короткий и точный русский эквивалент, он считается каноническим.

## Канонические термины

### Агент-менеджер
Центральный платформенный агент, который принимает запрос пользователя, выбирает flow, роль агента, запуск и следующий шаг.

Короткая форма:
- agent-manager

Уточнение:
- быстрые экземпляры agent-manager по умолчанию работают через платформенный MCP-сервер как основной интерфейс к данным и операциям платформы.

### Ролевой агент
Агент, работающий в рамках конкретной функции: аналитика, архитектура, разработка, тестирование, эксплуатация, управление знаниями и других ролей.

Короткая форма:
- ролевой агент

Уточнение:
- ролевой агент в slot работает в смешанном режиме: provider-native артефакты оформляет через `gh` или нативный API провайдера, а платформенные операции делает через платформенный MCP-сервер.

### Встроенная роль
Роль, которая поставляется вместе с платформой и поддерживается как часть канонического каталога ролей.

### Пользовательская роль
Роль, которую добавляет пользователь или команда платформы без изменения ядра доменной модели.

Такая роль:
- может быть привязана к проекту, репозиторию или flow;
- может запускаться как основной исполнитель или как дополнительная роль проверки и контроля;
- использует те же контракты промптов, приёмки и policy, что и встроенные роли.

### Организация
Отдельный контур владения платформы, внутри которого могут жить пользователи, группы, проекты, billing-правила и инфраструктурные ограничения.

### Группа пользователей
Логическое объединение пользователей для назначения прав, подписок и policy без прямой привязки каждого разрешения к одному пользователю.

### Package catalog
Общий каталог расширений платформы, который объединяет плагины и пакеты руководящей документации под одним пакетным контрактом.

### Package entry
Запись каталога пакетов, которая описывает вид пакета, источник, версию, верификацию, коммерческий статус и допустимые контуры использования.

### `Plugin package`
Исполняемое расширение платформы, которое публикуется как пакет и запускается в Kubernetes-контуре по своему manifest.

### `Guidance package`
Пакет руководящей документации, шаблонов и правил, который хранится в репозитории-источнике и импортируется в локальный рабочий контур.

### Профиль роли агента
Описание роли, которое задаёт:
- ключ роли;
- область действия;
- обязательный `work`-шаблон;
- необязательный `revise`-шаблон;
- режим исполнения;
- policy доступа к MCP, внешним аккаунтам и runtime;
- участие в flow и gate-контуре.

### Роль управления рисками
Встроенная профильная роль платформы, которая анализирует изменения и артефакты с точки зрения риска.

Такая роль:
- запускается как дополнительная контрольная роль, если flow или policy требуют risk-анализа;
- может рекомендовать повышение класса риска и запуск дополнительных ролей проверки;
- не должна понижать класс риска без явного человеческого решения.

### `work`-шаблон промпта
Канонический шаблон, по которому роль выполняет основную задачу.

### `revise`-шаблон промпта
Канонический шаблон, по которому роль устраняет замечания по уже существующему артефакту.

Этот шаблон необязателен: часть ролей может обходиться только `work`-шаблоном.

### Ссылка на шаблон промпта
Ссылка на версию шаблона промпта в БД платформы.

Важно:
- канонический текст шаблона хранится в БД;
- профиль роли ссылается на конкретную версию шаблона;
- при запуске агента платформа рендерит шаблон из БД, а не читает файл из репозитория.

### Установочные фикстуры flow, ролей и шаблонов промптов
Seed-файлы в репозитории платформы, из которых при установке или обновлении загружаются встроенные flow, профили ролей и шаблоны промптов.

Типовое содержимое:
- файлы flow;
- профили ролей;
- `work`- и `revise`-шаблоны промптов;
- policy-файлы для первичной загрузки.

Фикстуры не являются runtime-источником истины. После загрузки каноническое состояние живёт в БД и редактируется через UI.

### Источник проектной документации
Описанный в `services.yaml` источник продуктовой, архитектурной, сервисной или эксплуатационной документации конкретного проекта.

Он отличается от `guidance package`: руководящий пакет задаёт общие правила для агентов, а источник проектной документации описывает сам проект или его сервисы.

### Граф проектной документации
Набор источников проектной документации и зависимостей между ними.

Пример:
- общая продуктовая документация проекта;
- документация сервиса `service-1`;
- документация сервисов `service-2` и `service-3`, от которых зависит задача в `service-1`.

### Состав workspace
Список локально доступных источников, которые runtime загружает агенту в slot.

В него могут входить:
- один или несколько кодовых репозиториев;
- проектная документация;
- пакеты руководящей документации;
- вспомогательные файлы среды.

### Набор изменений по нескольким репозиториям
Связанный результат одной задачи, который состоит из нескольких `PR/MR` в разных репозиториях.

Такой набор остаётся provider-native: платформа не создаёт внутренний заменитель `PR/MR`, а хранит связи, ожидания приёмки и операторскую проекцию.

### Пользовательский запрос
Запрос, который человек отправляет платформе через чат, голос, фронтенд-действие или внешний канал.

### Flow
Шаблон процесса выполнения работы. Определяет этапы, переходы, обязательные артефакты, `gate`, Human gate, follow-up действия и привязки ролей к этапам.

Русский синоним:
- поток выполнения

### Automation rule
Правило автоматического запуска, которое по cron или trigger-событию создаёт задачу или запускает flow в заданном контуре.

### Trigger binding
Привязка внешнего или внутреннего события к automation rule и целевому flow.

### Этап
Отдельный шаг flow, например `intake`, `design`, `dev` или `release`.

### Шаблон этапа flow
Конфигурация одного этапа внутри flow: тип задачи, артефакты, acceptance profile, runtime-политика, `gate`, Human gate, переходы и follow-up.

### Привязка роли к этапу (`stage role binding`)
Правило, которое связывает профиль роли с конкретным этапом flow и определяет режим участия этой роли.

Такая привязка задаёт:
- запускается ли роль автоматически или вручную;
- является ли роль исполнителем, ролью проверки, `gatekeeper` или вспомогательной ролью;
- обязателен ли её результат для перехода дальше.

### Gate
Точка проверки или остановки перед следующим переходом.

Русский синоним:
- контрольная точка

Термин `gate` пока сохраняется как технически привычный и короткий.

### Инициатива
Обычный `Issue` типа `initiative`, который описывает крупную цель или сквозной поток работы.

### Этапная задача
Обычный `Issue` рабочего типа, соответствующего конкретному этапу flow.

### Follow-up задача
Обычный `Issue`, который создаётся как следующий шаг по результату этапа, проверки, релиза, инцидента или уточнения.

### Рабочий тип задачи
Семантический тип `Issue`, по которому платформа понимает назначение задачи.

Примеры:
- `initiative`
- `intake`
- `dev`
- `qa`
- `release`

### Нативная сущность провайдера
Сущность внешней системы, которой реально управляет GitHub/GitLab:
- `Issue`
- `PR/MR`
- комментарий
- mention
- relationship

### Watermark
Машинно-проверяемый блок в `Issue/PR/MR/comment`, который показывает, что артефакт оформлен по платформенному контракту.

Watermark не скрывает смысл от человека и не заменяет обычный читаемый текст.

### Открытая инструкция
Человекочитаемый блок в `Issue/PR/MR`, который явно объясняет агенту или человеку:
- что требуется;
- в каком flow идёт работа;
- какой следующий ожидаемый артефакт;
- какие ограничения действуют.

### Acceptance machine
Контур приёмки, который проверяет полноту оформления артефактов, обязательные поля и соблюдение policy.

### Session
Сессия агентной работы, которую можно продолжить позже без потери логики диалога и контекста.

Русский синоним:
- агентная сессия

### Run
Отдельный исполняемый запуск агента внутри сессии.

Русский синоним:
- запуск

### Platform job
Отдельная техническая операция платформы, которая выполняет build, mirror, deploy или иной системный шаг.

Русский синоним:
- платформенная job
- техническая job

Важно:
- `run` относится к работе агента;
- `job` относится к техническому выполнению среды и поставки.

### Регламентная job
Периодическая `platform job`, которая поддерживает жизненный цикл платформы и среды по retention или health-check policy.

### Slot
Изолированное runtime-окружение в Kubernetes под конкретную работу.

### Прогретый slot
Заранее подготовленный slot, который можно быстро занять под новую задачу.

### Сервер
Узел размещения платформы или управляемый внешний вычислительный узел, который входит в реестр платформы.

### Kubernetes-кластер
Управляемый платформой кластерный контур, на котором могут жить slots, плагины, проектные окружения и сама платформа.

### Placement policy
Правило выбора допустимого серверного или кластерного контура для организации, проекта, репозитория, пакета или workload.

### `code-only`
Режим работы агента, когда доступен только код и связанный инструментарий без полноценного разворота проектного окружения.

### `full-env`
Режим работы агента, когда поднимается полноценное окружение проекта в отдельном slot.

### Production-контур только для чтения
Режим работы роли, при котором агент подключается к production-контексту без права менять его состояние.

Такой режим допускается только для специально разрешённых ролей, например `qa`, мониторинга, проверки релиза или postdeploy-наблюдения.

### Зеркальные проекции и дозаполнение
Внутренний слой платформы, который сохраняет данные провайдера в удобной форме, добавляет недостающий платформенный контекст и не становится новым владельцем исходной сущности.

### Зеркальная проекция провайдера
Нормализованное зеркало provider-native объекта внутри платформы, которое помогает принимать решения и строить UI, но не становится новым владельцем исходной сущности.

### Provider constraint
Явное внешнее ограничение, которое влияет на работу платформы: лимит провайдера, квота, потеря авторизации, отказ по правам доступа или временная недоступность провайдера.

### Release policy
Платформенная политика ветвления и релизов, которая связывает provider-native ветки, стратегию выкладки, обязательные gates и релизные подтверждения.

### Release line
Платформенный координационный контур релизной поставки, который объединяет задачи, `PR/MR`, release branches, rollout decisions и postdeploy-сигналы.

### Billing account
Сущность коммерческого контура, которая связывает организацию или иной контур с правилами расчёта и платными ресурсами.

### Cost record
Нормализованная запись учёта затрат по runtime, использованию внешних провайдеров, использованию пакетов или другим платным операциям.

### Платформенный MCP-сервер
Тонкий платформенный контур инструментов, через который быстрые экземпляры agent-manager и slot-агенты получают актуальные данные платформы, выполняют платформенные операции, инициируют апрувы и вызывают разрешённые действия owner-сервисов.

Важно:
- платформенный MCP-сервер не становится владельцем доменных данных;
- он остаётся инструментальной поверхностью над owner-сервисами и policy-контуром.

### Контур внешних каналов
Расширяемая модель взаимодействия с пользователем вне фронтенда: уведомления, вопросы, ответы, запросы апрува, продолжение диалога.

### Командный центр
Главный домашний экран платформы, через который пользователь запускает работу, общается с agent-manager, видит центр внимания и переходит в рабочие пространства.

### Рабочее пространство задачи
Универсальный экран для любого `Issue` независимо от его рабочего типа: `initiative`, этапная задача, follow-up, `risk`, `incident`, `self-improve`.

### Рабочее пространство `PR/MR`
Универсальный экран изменения, который показывает review status, acceptance, risk, связанные `run/job` и ведёт в нативный review интерфейс провайдера.

### Центр внимания
Единая операторская поверхность, где собираются approvals, запросы обратной связи, блокировки, failed `run/job`, provider limits и другие actionable события.

### Sequence-first редактор flow
Канонический UX-режим настройки flow, где источником истины является упорядоченный список этапов и правил, а графическое представление остаётся только preview.

### Риск-класс
Класс изменения или действия, который определяет требуемый уровень проверок и обязательных человеческих контрольных точек.

### Human gate
Точка процесса, где решение обязан принять человек, а не acceptance machine.

### Профиль риска
Набор policy-правил, который задаёт минимальный risk class и обязательные gates для проекта, репозитория, сервиса, API, данных или типа операции.

### Release decision package
Структурированный evidence bundle, на основании которого принимается решение о релизе.

### Релизная контрольная точка
Human gate перед deploy `job`, на котором принимается решение, можно ли выпускать текущий release-кандидат.

Короткая форма:
- release gate

### Blocking signal
Сигнал, который запрещает переход к следующему шагу, переводит процесс в `hold` или требует rollback decision.

### Release safety-loop
Связанный контур `release -> postdeploy -> ops`, в котором релиз считается завершённым только после наблюдения, follow-up решений и закрытия блокирующих сигналов.

### Release-кандидат
Состояние поставки, в котором артефакты и evidence уже готовы к release gate, но deploy ещё не запущен.

### `hold`
Состояние управляемой остановки процесса до внешнего решения, окна, ресурса или снятия блокирующего сигнала.

### Решение об откате
Явное решение перевести процесс в rollback или recovery-сценарий вместо продолжения текущего перехода.

### Evidence
Набор подтверждений, что этап можно считать выполненным:
- артефакты;
- ссылки;
- результаты проверок;
- комментарии;
- runtime-диагностика.

### Хвост лога
Короткий фрагмент последних строк технического лога, который сохраняется в базе для быстрого показа в UI/API.

Полный лог при этом остаётся в Kubernetes-контуре или внешней системе логирования.

### Retention-политика
Правило хранения и очистки устаревших данных, временных сред, технических записей и других объектов жизненного цикла платформы.

### Уведомление
Настраиваемое сообщение о значимом событии платформы: ошибке, блокировке, завершении задачи, завершении `job`, необходимости действия человека или исчерпании лимитов.

### Acceptance profile
Набор правил, по которым acceptance machine проверяет конкретный тип артефакта, flow или этап.

### Дополнительная контрольная роль
Роль, которая запускается не как основной исполнитель этапа, а как параллельный контур проверки и контрольных точек после появления нужных артефактов.

### Машинно-проверяемый контракт артефакта
Сочетание открытых разделов, provider-native полей и watermark, которое acceptance machine может проверить без догадок.

### Owner approval
Обязательное решение владельца продукта по документу, high-risk переходу или релизному действию.

### Compact PR
PR, который закрывает один логический срез и реально поддаётся содержательному review.

### Prototype -> production conversion
Обязательный переход от быстрого прототипа к production-поставке через компактные PR и удаление временных решений.

## Термины, которые считаются нежелательными

### "Инициатива" как внутренняя платформенная сущность
Нежелательно.

Правильно:
- инициатива как `Issue` определённого типа

### "Артефакт" как всё подряд
Нежелательно использовать расплывчато.

Нужно уточнять:
- `Issue`
- `PR/MR`
- комментарий
- файл в репозитории
- evidence

### "Workflow" вместо любого процесса
Допустимо только там, где нужен именно термин `flow` или внешний технический термин.

По умолчанию лучше писать:
- flow
- поток выполнения
- шаблон потока

### "Дашборд" как центральная сущность продукта
Нежелательно как продуктовый термин верхнего уровня.

Новая каноника строится вокруг:
- agent-manager;
- задач;
- запусков;
- runtime;
- операционных представлений.

## Термины, которые будут детализированы позже
- точный словарь risk-классов;
- точный словарь stage-типов;
- названия UI-режимов во фронтенде;
- точные имена внешних interaction contracts и extension mechanism.
