---
doc_id: GLO-CK8S-PLATFORM-0001
type: glossary
title: kodex — продуктовый глоссарий платформы
status: active
owner_role: KM
created_at: 2026-04-26
updated_at: 2026-05-07
related_issues: [599, 600, 601, 602, 655]
related_prs: []
approvals:
  required: ["Owner"]
  status: approved
  request_id: "owner-2026-04-26-platform-product-frame"
  approved_by: "ai-da-stas"
  approved_at: 2026-04-26
---

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

## Правила терминологии

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

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

| Термин | Значение |
|---|---|
| Agent-manager | Центральный быстрый агент платформы, который принимает запросы, выбирает flow, роли, запускает операции и общается с пользователем. |
| Ролевой агент | Агент, работающий в конкретной роли: разработка, проверка, `qa`, release-check, postdeploy-наблюдение, управление рисками и другие роли. |
| Owner | Человек, который утверждает документы, решения и high-risk переходы по policy, но не обязан быть reviewer каждого кода. |
| Acceptance machine | Контур машинной приёмки артефактов, обязательных полей, watermark, provider-native связей и policy. |
| Организация | Контур владения пользователями, группами, проектами, доступом, биллингом и допустимой инфраструктурой. |
| Группа пользователей | Логическая группа для назначения прав, подписок и policy. |
| Проект | Контейнер репозиториев, настроек, flow, внешних аккаунтов, runtime-ограничений и release policy. |
| Репозиторий | Управляемый источник кода, документации, конфигурации или пакета. |
| Provider-first модель | Подход, при котором рабочие артефакты остаются в GitHub/GitLab, а платформа добавляет оркестрацию и policy поверх них. |
| Нативная сущность провайдера | `Issue`, `PR/MR`, комментарий, mention, relationship, ветка, тег или review-состояние внешнего провайдера. |
| Зеркальная проекция | Локальная производная запись платформы по нативной сущности провайдера для быстрого UI, поиска, уведомлений, приёмки и защиты от лимитов провайдера. Не является отдельной задачей. |
| Платформенные метаданные | Данные, которыми владеет платформа: состояние приёмки, риск, policy decisions, связи с `run`, `job`, slot, сессией, уведомлениями и операторскими списками. |
| Webhook inbox | Надёжный входящий журнал сырых событий провайдера до их бизнес-обработки. Нужен для дедупликации, повторов и воспроизведения обработки. |
| Incremental reconciliation | Фоновая сверка с провайдером по cursor, времени обновления или другому доступному механизму без полного постоянного обхода всех данных. |
| `sync_cursor` | Состояние последней успешной сверки области синхронизации провайдера: репозитория, проекта, типа артефакта или другого контура. |
| `drift_status` | Признак уверенности платформы в актуальности проекции: например synced, stale, suspect или conflict. |
| Снимок лимитов провайдера | Снимок текущего состояния лимитов внешнего API, полученный до, после или во время agent-run. Для `gh` это приближённый учёт, а не полный аудит каждой операции. |
| Инициатива | `Issue` типа `initiative`, описывающий крупную цель или поток работ. |
| Этапная задача | `Issue` рабочего типа, соответствующего этапу flow. |
| Follow-up задача | `Issue`, созданный как следующий шаг процесса, проверки, релиза, инцидента или уточнения. |
| `Flow` | Шаблон процесса выполнения работы: этапы, переходы, роли, gates, артефакты и правила запуска. |
| Этап | Шаг flow: например `intake`, `vision`, `prd`, `arch`, `design`, `plan`, `dev`, `qa`, `release`, `postdeploy`, `ops`. |
| Профиль роли | Описание назначения роли, шаблонов, runtime, MCP-прав, внешних аккаунтов и допустимого участия в flow. |
| Привязка роли к этапу | Правило, которое определяет, как роль участвует в конкретном этапе flow. |
| `Work`-шаблон | Шаблон промпта для выполнения основной задачи роли. |
| `Revise`-шаблон | Шаблон промпта для устранения замечаний по уже созданному артефакту. |
| Установочная фикстура | Seed-файл в репозитории платформы для первичной загрузки встроенных flow, ролей и шаблонов промптов. |
| Human gate | Точка, где требуется явное решение человека. Термин сохраняется как устойчивый, вместо искусственного русского перевода. |
| Gate | Контрольная точка автоматической или человеческой проверки. |
| Watermark | Машинно-проверяемый блок в `Issue`, `PR/MR` или структурированном комментарии. |
| Открытая инструкция | Человекочитаемые разделы артефакта, объясняющие контекст, ожидания, ограничения и следующий шаг. |
| Агентная сессия | Логический контекст агентной работы, который можно продолжить. |
| `Run` | Один исполняемый запуск агента внутри сессии. |
| `Slot` | Изолированное Kubernetes-окружение под конкретную работу. |
| `Job` | Техническая операция платформы: зеркалирование зависимостей, сборка, публикация образа, deploy, cleanup или health-check. |
| Runtime | Контур среды исполнения: slots, platform jobs, workspace, plugins и проектные workloads. Agent `Run` принадлежит `agent-manager`. |
| Fleet | Контур серверов и Kubernetes-кластеров, которыми управляет платформа. |
| Placement policy | Правило выбора допустимого серверного или кластерного контура. |
| SSO-провайдер | Самостоятельно управляемый контур входа в платформу по OIDC/SAML с подключением внешних поставщиков идентичности. Базовый вариант первой версии — Keycloak. |
| Package catalog | Каталог установленных и доступных пакетов конкретной установки платформы. |
| Package entry | Запись каталога о пакете, версии, источнике, верификации, коммерческом статусе и допустимом применении. |
| Plugin package | Исполняемый пакет-расширение, запускаемый в Kubernetes-контуре установки платформы. |
| Guidance package | Пакет руководящей документации, шаблонов и правил для агентов. |
| Магазин пакетов | Отдельный пакет, который отдаёт каталог доступных пакетов; не является частью ядра платформы. |
| Проектная документация | Документация конкретного проекта или сервиса, хранящаяся в репозиториях проекта. |
| Источник проектной документации | Описание в `services.yaml`, где лежит документация и как агенту её подключать в workspace. |
| Состав workspace | Набор локально доступных источников, которые получает агент в slot. |
| Release policy | Политика ветвления, релизных gates, evidence и выкладки. |
| Release line | Координационный контур релиза, связывающий задачи, `PR/MR`, ветки, теги, `job` и решения. |
| Automation rule | Правило запуска flow или создания задачи по cron, trigger или внешнему сигналу. |
| Роль управления рисками | Встроенная контрольная роль, которая анализирует риск и может рекомендовать усиление контроля. |
| Cost record | Запись затрат по runtime, внешним провайдерам, пакетам или иной платной операции. |
| Invoice basis | Расчётный срез для выставления счёта организации или проекту. |

## Запрещённые подмены смысла

| Нельзя писать | Почему | Правильно |
|---|---|---|
| Инициатива как отдельная внутренняя рабочая сущность | Ломает provider-first модель и создаёт конкурирующий трекер задач | `Issue` типа `initiative` плюс зеркальная проекция и платформенные метаданные |
| Human gate как дословный перевод | Звучит неестественно и ухудшает точность | Human gate |
| Логи `job` в БД | Создаёт лишний объём и повторяет Kubernetes-логи | статус, причина ошибки, короткий хвост и ссылка |
| Документы проекта как внутренние карточки платформы | Источник истины должен быть в репозитории | проектная документация в репозиториях, описанная в `services.yaml` |
