У TriCodeBot и TriCode2 давно появился свой рабочий диалект. В новостях, статусах, rollout-заметках и операторских апдейтах постоянно мелькают слова вроде run, rollout, runtime-state, DeployPrep, quality gate, service token или confirmable card. Для команды это уже почти разговорный язык, но для читателя снаружи такой поток легко превращается в кашу из знакомых и полузнакомых слов.

Эта страница нужна ровно для обратного эффекта: не добавить ещё один слой жаргона, а разложить все ключевые термины по полкам и зафиксировать, что именно они значат в нашем контексте. Ниже не словарь “вообще по индустрии”, а именно практический глоссарий того, как эти слова реально используются в новостях, статусах и рабочих объяснениях TriCodeBot.

Как читать этот глоссарий

У каждого термина здесь есть три слоя:

  • прямой смысл — что это такое технически;
  • операторский смысл — почему этот термин важен в статусе, новости или rollout-отчёте;
  • типичная ошибка чтения — где люди чаще всего делают неверный вывод.

Это важно, потому что один и тот же термин может звучать спокойно, а интерпретироваться драматично. Например, RUNNING ещё не всегда значит, что heavy-работа реально исполняется прямо сейчас, а dev ещё не значит “сломано” или “ненастоящее”.

Базовые роли и участники

SysAdmin

SysAdmin — это человек, который отвечает за инфраструктурную сторону среды: доступность runtime, deployment, секреты, сетевой маршрут, ingress, контейнеры, namespace, readiness и прочие слои, до которых обычный пользователь не дотрагивается.

В новостях термин нужен, когда проблема не в продуктовой логике, а в среде исполнения. Если пишется, что нужен SysAdmin, это обычно означает: баг нельзя закрыть одной правкой интерфейса или текста; нужен доступ к контуру, env, secret, deployment или сетевому пути.

Типичная ошибка чтения: считать, что SysAdmin всегда “чинит сервер”. На практике он часто не чинит код, а восстанавливает условия, в которых код вообще может работать предсказуемо.

Operator / оператор

Operator — это человек, который управляет системой в рабочем режиме: публикует новости, переключает proxy-mode, смотрит audit, следит за queue и понимает разницу между user-facing и infra-facing состояниями.

Когда новость называется operator update или operator briefing, это значит, что текст ориентирован не на маркетинг, а на управляемость и понимание operational состояния.

Admin

Admin — это пользователь с административными правами в контуре TriCodeBot. Админ может работать через Mini App, admin API, service token или Telegram-команды, если путь разрешён policy.

Типичная ошибка: путать admin как роль продукта и SysAdmin как роль инфраструктуры. Админ может уметь публиковать и переключать системные функции, но не обязан иметь доступ к k3s или секретам.

User-facing и operator-facing

User-facing означает, что текст написан для обычного читателя или пользователя продукта. Operator-facing — для человека, который интерпретирует состояние системы и принимает operational решения.

Если в задаче явно просят user-facing текст, это сигнал не тащить в публикацию внутренние детали уровня env, secret, SQL и внутреннего кода ошибок.

DevOps, Architect, Tester

DevOps в нашем контексте — всё, что связано с окружением, runtime, deploy и release discipline. Architect — роль, которая формулирует решения, направления или подтверждает структуру изменений. Tester — этап или роль, где проверяется поведение, а не только собираемость системы.

Когда в статусах пишут, что проект “дошёл до TESTER”, это сигнал, что pipeline реально двигается по продуктовой цепочке, а не завис ещё на самом раннем системном этапе.

Термины исполнения и жизненного цикла работы

Project

Project — это сущность верхнего уровня: рабочий контейнер смысла, внутри которого могут жить настройки, runs, история, роли, статусы и продуктовая цель. Проект может быть активным даже тогда, когда у него сейчас нет живого run.

Active project

Active project — проект, который выбран как текущий рабочий контур пользователя или оператора. Это не обещание, что там прямо сейчас исполняется код; это скорее отметка “именно в этот проект сейчас смотрят и его используют как основной”.

Run

Run — один конкретный запуск рабочего процесса. Это не проект целиком, а отдельная попытка прохождения pipeline, task loop или product flow. У проекта может быть много run-историй, и каждая имеет свой статус.

В новостях слово run встречается постоянно, потому что это самая удобная единица реального прогресса: не абстрактная “работа”, а конкретный исполнявшийся цикл.

Типичная ошибка: читать run как “вообще всё состояние проекта”. На деле run — это эпизод, а проект — контейнер эпизодов.

Task loop

Task loop — повторяющийся внутренний рабочий цикл исполнения задач: система берёт задачу, делает шаги, обновляет состояние, двигается дальше и снова возвращается к следующему циклу. Когда пишут, что “основной task loop жив”, это означает, что работа не просто стартовала, а продолжает повторяемое движение вперёд.

Runtime

Runtime — среда, в которой код реально исполняется. Это не репозиторий, не идея, не ветка и не UI. Runtime — это живой исполняемый слой: процесс, контейнер, pod, HTTP-сервер, polling bot, proxy-цепочка, всё, что делает систему настоящей.

В новостях фраза “runtime жив” обычно сильнее, чем “код поправили”: это значит, что изменения не только написаны, но и действительно работают в исполнении.

Runtime-state

Runtime-state — подвид статуса, который описывает не абстрактное состояние проекта, а фактическое состояние исполнения: реально работает, ждёт слот, stalled, idle, paused или ещё в каком-то промежуточном состоянии.

Это один из самых важных терминов, потому что без него статус RUNNING очень легко читать слишком оптимистично.

RUNNING

RUNNING означает, что run не завершён и считается активным. Но это ещё не всегда значит, что heavy-работа реально исполняется каждую секунду. Run может быть running и при этом ждать ресурсы, очередь, слот или внешнее действие.

Queued / queue / queue-ish

Queue — очередь на ресурс или на тяжёлое выполнение. Queued означает, что работа поставлена в ожидание. Queue-ish — неформальная формулировка, когда состояние похоже на очередь по поведению, даже если в чистой модели это не буквально отдельный queue-state.

Операторский смысл прост: задача не умерла, но и не едет в полную силу. Это важно для честных новостей, чтобы не выдавать ожидание слота за активное выполнение.

Slot / heavy slot

Slot — доступное место на исполнение. Heavy slot — дефицитный слот для ресурсоёмкой работы. Если run ждёт heavy slot, это не обязательно ошибка: иногда это просто честный признак ограниченного runtime capacity.

Stalled

Stalled — работа зависла или перестала продвигаться, хотя внешне может выглядеть ещё не упавшей. Это опаснее обычной queue-ситуации: в очереди движение ожидаемо, в stalled-состоянии движение обещалось, но не происходит.

Paused

Paused — выполнение поставлено на паузу. Это управляемое состояние, а не аварийное. Чаще всего оно означает: работу можно продолжить позже, контекст не потерян, но сейчас цикл остановлен сознательно.

Blocked

Blocked — есть препятствие, которое run сам не может обойти. Это может быть quality gate, missing credential, policy violation, внешний dependency gap или любой другой фактор, который не даёт двигаться дальше без внешнего изменения.

Failed

Failed — run завершился неуспешно. Важно отличать fail уровня продукта от fail уровня среды. Один говорит “сломана логика или шаг сценария”, другой — “контур исполнения не дал сценарию шанса нормально отработать”.

Completed

Completed — run завершён. Но и здесь нужен нюанс: completed не всегда значит “больше ничего не требуется”. Иногда продуктовая часть завершена, а deploy-contract, rollout handoff или post-check ещё остаются как отдельные шаги.

Canceled

Canceled — run остановлен намеренно. Это не fail и не pause. Обычно это означает: оператор или система решила не продолжать конкретный прогон вообще.

Materialization

Materialization — момент, когда абстрактные задачи, решения или планы превращаются в конкретные единицы работы. Если run остановился “до materialization”, это значит, что он не дошёл до стадии реального разворачивания задач в рабочие объекты.

Quality gate

Quality gate — контрольный барьер качества. Пока run его не проходит, дальше движение не считается безопасным или допустимым. В новостях термин нужен, чтобы показать: остановка произошла не из-за хаоса, а из-за намеренного контрольного механизма.

Релизы, rollout и доставляемые изменения

Deploy

Deploy — сама операция выкладки изменений в живой контур. Это действие “донести и запустить”, а не просто “написать код”.

Rollout

Rollout — процесс развёртывания новой версии в runtime. Слово особенно полезно, когда важно не только, что выкладка произошла, но и что она прошла управляемо: с проверками, с переходом на новую версию и без аварийного отката.

DeployPrep / deploy-prep

DeployPrep — подготовка к выкладке. Это ещё не сам deploy, а слой до него: собрать артефакты, выровнять env, подготовить rollout steps, smoke-check план, rollback snapshot и handoff. Если новость говорит про deploy-prep, значит релизная работа ещё не означает живой runtime change.

Deploy contract

Deploy contract — явный контракт на то, как изменение должно быть выкачено, проверено и кому передано. Это защита от хаоса “код есть, а дальше как-нибудь сами”.

Rollback snapshot

Rollback snapshot — заранее подготовленная точка возврата. Она нужна не потому, что команда ждёт катастрофу, а потому что хороший rollout заранее допускает безопасный путь назад.

Smoke-check / smoke test

Smoke-check — короткая проверка того, что базовые функции после rollout не умерли. Это не полный тестовый прогон, а минимальный набор сигналов “контур жив, критическая поверхность отвечает”.

Healthz и readyz

healthz — проверка общего факта, что процесс жив. readyz — проверка, что контур готов обслуживать реальную работу. Если healthz зелёный, а readyz нет, это типичная ситуация “процесс существует, но к нормальной работе ещё не готов”.

Recovery

Recovery — восстановление работоспособности после поломки или деградации. Важный нюанс: recovery не всегда равно полной нормализации. Иногда это “вернули рабочий доступ”, но ещё не “всё идеально и стабильно”.

Среды и ветки

dev

dev — рабочий контур разработки и проверки изменений. Это не мусорная среда и не инцидент по умолчанию. В нашем контексте dev часто является штатным местом, где живёт Telegram runtime для контролируемой выкладки и верификации.

production / prod

Production или prod — боевой контур, где изменения уже пользовательски значимы и где цена ошибки выше. Если в новости подчёркивают “это dev, не production”, это не бюрократия, а защита от ложных ожиданий.

main

main — основная ветка исходников. Фраза “в production выкатили main” означает источник изменений, но сама по себе не гарантирует, что все слои среды автоматически стали одинаковыми.

Интерфейсы и UI-термины

UI

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

Studio

Studio — основной рабочий интерфейс продукта. Когда пишут “Studio показывает runtime-state”, речь идёт не о маркетинговой витрине, а о рабочей панели, через которую человек реально читает и управляет состоянием.

Mini App

Mini App — Telegram-встраиваемый интерфейс, который даёт доступ к части рабочих функций без отдельного полного веб-интерфейса. В TriCodeBot это не игрушка, а полноценный control-plane слой для части админских и пользовательских сценариев.

Workspace

Workspace — отдельная рабочая секция внутри Mini App или связанного контекста. Это не обязательно файловая папка; чаще — логическая область: dashboard, users, news, audit, projects.

Modal

Modal — всплывающее окно для отдельного действия, подтверждения или редактирования. Если действие уходит в modal, это обычно знак, что оно требует отдельного фокуса и не должно случайно сработать на основном экране.

Confirm modal

Confirm modal — модалка с явным подтверждением опасного или важного действия: delete, publish, revoke, pause, cancel. Это страховка от “кликнул мимо и испортил состояние”.

Confirmable card

Confirmable card — неформальный термин для карточки или UI-блока, где опасное действие не срабатывает мгновенно, а сначала переводит пользователя в явное подтверждение. Идея та же, что у confirm modal, только мыслится через карточную структуру интерфейса.

Card / story card

Card — компактный визуальный блок с ограниченным смыслом. Story card — карточка, которая уже не просто перечисляет поля, а упаковывает короткую историю: headline, lead, snapshot, акцент, CTA.

Snapshot

Snapshot — компактный срез состояния на один момент времени. В Telegram это часто делается через <pre>-блок или визуально ограниченную табличку, чтобы читатель видел не расплывчатый абзац, а конкретную схему состояния.

CTA

CTA — call to action, то есть явный призыв к следующему действию. В наших новостях CTA важен не как рекламный трюк, а как переход из компактного канального анонса в полную canonical статью.

Teaser

Teaser — короткий анонс большой истории. Он не должен повторять всю статью; его задача — дать точный эмоционально-операционный вход в материал и привести в полный текст без потери смысла.

Контент и публикационные режимы

Canonical content

Canonical content — полная базовая статья, которую считаем основной версией новости. Именно на неё должны ссылаться короткие анонсы, если задача требует двухслойную схему публикации.

Public / channel / private visibility

Public — видимость для полной web-статьи. Channel — контент для канального слоя. Private — внутренний слой, который не должен читаться как открытая статья. Эти режимы важны, потому что один и тот же текст по-разному работает как web-story и как Telegram-анонс.

Broadcast

Broadcast — доставка новости авторизованным подписчикам как архивируемый subscriber-flow. Это не то же самое, что публикация в канал.

Channel

Channel publish — публикация в Telegram-канал. Здесь важны ширина пузыря, компактность, snapshot и выразимый CTA.

Promo

Promo — отдельный тип канальной публикации, чаще завязанный на onboarding, вход в бота или регистрационный сценарий. Это не просто ещё один channel-post, а более явно призывающий слой.

Slug

Slug — человекочитаемый хвост URL страницы. Если slug хороший, ссылку проще читать, обсуждать и узнавать визуально.

Интеграции, доступы и проверяемость

Admin API

Admin API — штатный HTTP-контур для операторских действий: создавать новости, публиковать, смотреть пользователей, менять policy, работать с proxy и токенами.

Service token

Service token — машинный ключ доступа к admin API. Он нужен не человеку глазами, а системе, автоматизации или аккуратному операционному скрипту.

Signed hook / webhook

Signed hook — подписанный входящий вызов, который системе можно доверять по HMAC-подписи, времени и nonce. Webhook — более общий термин для HTTP-вызова по событию. Подписанный hook — это webhook с явной криптографической дисциплиной.

InitData

Telegram initData — данные, которыми Mini App подтверждает, что пользователь действительно пришёл из Telegram-контекста. Это база для создания web-session без ручной логин-формы.

Web session

Web session — серверная сессия, которая позволяет пользователю или админу продолжать работу в Mini App и web-контуре без повторной авторизации на каждом шаге.

Login token

Login token — временный токен для входа в web/Mini App контур. Это отдельный механизм от service token: он для интерактивного пользователя, а не для машинной интеграции.

Link token

Link token — одноразовый токен, которым Telegram-аккаунт привязывают к внешней системе вроде tricode2. Если `/link <token>` не работает, это обычно не “сломался весь бот”, а поломка в очень конкретном binding-flow.

Binding

Binding — связь Telegram-пользователя с учётной записью или сущностью во внешней системе. Без binding Mini App или bot-facing API могут знать, кто вы в Telegram, но не понимать, какой вы пользователь в продукте.

Audit log

Audit log — журнал админских действий. Он нужен не для красоты, а чтобы потом можно было восстановить: кто, чем, когда и в каком контексте менял состояние.

Сетевой и инфраструктурный слой

Proxy

Proxy — промежуточный сетевой слой для маршрутизации трафика. В контексте TriCodeBot он особенно важен там, где прямой доступ к Telegram API нестабилен или требует контролируемого обхода.

VLESS

VLESS — транспортный протокол в прокси-контуре. Для пользовательской новости это почти никогда не главный герой, но для operator-facing диагностики это важный маркер того, через какой путь реально уходит Telegram-трафик.

Xray

Xray — runtime-компонент прокси-контура. Если в заметке упоминаются Xray и proxy state, речь почти всегда об operational транспортной дисциплине, а не о продуктовой функции для пользователя.

Landing

Landing — публичная входная витрина. Её важно не путать со Studio, Mini App или backend. В новостях про rollout часто отдельно подчёркивают, затронут landing или нет, потому что внешний фасад и рабочий контур — это разные слои.

Backend и frontend

Backend — серверная логика, API, хранение состояния и интеграции. Frontend — интерфейсная часть, через которую человек это видит. Очень многие новости становятся точнее, когда прямо говорят, в каком из этих слоёв изменение произошло на самом деле.

Практический перевод самых частых формул

  • “run жив” — исполнение не умерло, но это ещё не гарантия реального heavy-progress каждую секунду.
  • “rollout подтверждён smoke-check’ами” — базовая жизнеспособность после выкладки подтверждена, но это не равно полному тестовому покрытию.
  • “bot-side fixed” — именно бот перестал быть узким местом; следующая проблема может лежать уже в backend-side.
  • “queue” — ждёт ресурс, а не обязательно сломался.
  • “blocked” — без внешнего вмешательства дальше не поедет.
  • “dev-only” — изменение реально существует, но его нельзя выдавать за production-факт.
  • “canonical article + channel teaser” — большая статья считается источником правды, а Telegram ведёт в неё компактным входом.

Зачем вообще держать такой словарь

Потому что половина технического хаоса возникает не там, где система действительно сломана, а там, где одно и то же слово разные люди читают по-разному. Для одного RUNNING — это “всё хорошо”, для другого — “надо проверить runtime-state”. Для одного dev — “черновик”, для другого — “штатный боевой контур проверки”. Для одного rollout — “код смёржен”, для другого — “новая версия реально в runtime и прошла smoke”.

Этот глоссарий нужен как общий слой синхронизации. Чтобы когда TriCodeBot говорит своим рабочим диалектом, читатель понимал не только форму слова, но и фактический operational смысл, который за этим словом стоит.