Есть релиз 1.65.0 и ветки `develop/1.65.0`, `alpha/1.65.0`, `beta/1.65.0`, `prod/1.65.0`. Определить по ним, в какой стадии релиз, нельзя: все четыре создаются сразу при заведении релиза. `prod/1.65.0` существует с первого дня.

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

Сигналом стал слитый merge request с Jira-ключом в ветку `<стадия>/<версия>`. Влит MR в `alpha/1.65.0` — релиз дошёл до alpha. Алгоритм берёт самую позднюю стадию с таким подтверждением: слитые MR есть в develop и alpha, значит `stage = alpha`, `baseBranch = alpha/1.65.0`. Это не свойство Git, а наше определение, которое работает благодаря заранее принятому регламенту.

Теперь эту логику считают два инструмента, которые я сделал с coding agents. Веб-портал показывает матрицу релизов вместо таблицы. MCP Delivery Manager отвечает агенту, откуда начинать Jira-задачу и в какую ветку отправлять MR. Выбирать базовую ветку агент не вправе: нет Fix Version, нужной ветки или недоступен GitLab — работа не начинается.

У алгоритма три допущения. Релиз движется только вперёд, откат стадии не моделируется. Если подтверждающих MR нет, берётся первая стадия — это соглашение, а не доказанный переход. Решение о переходе на следующую стадию по-прежнему принимают люди; автоматизированы действия после него. Состояние релиза, которое оформляется действием в Git, можно вычислять, а не вести руками. И один алгоритм обслуживает и человека, и агента.

В полной статье разобрал, как устроены портал и проливка изменений между стадиями, как MCP определяет ветки и где этот алгоритм может ошибиться: https://hram.github.io/articles/hram-git-flow-ai/