---
doc_id: REF-CK8S-0022
type: deployment-sequencing
title: "kodex — первое развёртывание новой версии и gate перехода к wave 7"
status: active
owner_role: EM
created_at: 2026-04-25
updated_at: 2026-04-25
related_issues: [470, 488, 586]
related_prs: []
approvals:
  required: ["Owner"]
  status: approved
  request_id: "owner-2026-04-25-refactoring-wave6"
  approved_by: "ai-da-stas"
  approved_at: 2026-04-25
---

# Первое развёртывание новой версии и gate перехода к wave 7

## TL;DR
- Первый deploy новой версии платформы будет происходить не как миграция боевого legacy-контура, а как развёртывание на чистом сервере и чистом кластере.
- До начала серверных работ должна существовать минимально жизнеспособная новая вертикаль: доступ, проектный контур, GitHub provider path, `agent-manager`, хотя бы один flow, `code-only` slot, `full-env` slot и базовый операторский UI.
- После завершения wave 6 следующий обязательный шаг — backlog checkpoint, а не немедленный старт большого кода без ревизии задач и границ.
- Ранний deploy допускается только как управляемый bootstrap новой архитектуры, а не как случайная проверка отдельных сервисов без целостного рабочего контура.
- Креды нового сервера и кластера подключаются только в момент фактического начала deploy-итерации; wave 6 фиксирует порядок и критерии, но не требует сейчас выполнять инфраструктурные команды.

## 1. Что считается первым deploy новой версии
Под первым deploy новой версии в рамках этой программы понимается:
- установка новой платформы на новый чистый сервер;
- запуск нового production-контура без требования мигрировать пользовательские данные старой версии;
- проверка, что новая вертикаль реально поднимается, стартует и способна вести хотя бы один рабочий поток.

Это не считается:
- техническим smoke отдельных pod без готовой продуктовой вертикали;
- возвратом старого `control-plane` как временного production-core;
- "временно ручным" deploy без повторяемого bootstrap-сценария.

## 2. Минимальный вертикальный срез до старта серверной итерации
До момента, когда имеет смысл подключать новые креды сервера и кластера, новая версия должна иметь как минимум:
1. вход и базовый контур пользователей;
2. проекты, репозитории и базовые project rules;
3. GitHub provider path с webhook ingest, mentions и provider operations;
4. быстрый `agent-manager`, работающий через платформенный MCP-сервер;
5. хотя бы один рабочий flow;
6. один рабочий `code-only` slot;
7. один рабочий `full-env` slot;
8. базовый UI с командным центром, рабочими поверхностями и операторской видимостью `run/job/slot`;
9. базовый fleet-контур, позволяющий зарегистрировать основной сервер и основной кластер платформы как управляемые объекты.

Причина простая:
- если этого нет, ранний deploy проверяет не платформу, а набор разрозненных технических заготовок;
- это создаёт ложное ощущение прогресса и почти гарантирует переделку bootstrap-модели позже.

## 3. Каноническая последовательность первого развёртывания

### Фаза 0. Backlog checkpoint до кодовых волн
Сразу после wave 6 и до wave 7 должен быть выполнен backlog checkpoint:
- пересмотреть активные `Issue` и открытые PR;
- закрыть или перепривязать то, что относится к legacy-модели и не входит в новые волны;
- собрать первую очередь реализационных задач под waves 7-17;
- проверить, что порядок волн не нарушается ad-hoc задачами "сразу сделать runtime/UI/deploy".

Это отдельный обязательный gate. Без него кодовая реализация будет расползаться обратно в старую модель.

### Фаза 1. Реализационные волны до готовой к deploy вертикали
После backlog checkpoint выполняются кодовые волны до момента, когда появляется минимальный вертикальный срез, готовый к deploy.

Практически это означает:
- wave 7 и дальше не обязаны ждать полной реализации всех доменов;
- но deploy на новый сервер не начинается, пока не собран минимальный вертикальный срез из раздела 2.

### Фаза 2. Подготовка нового сервера и кластера
Когда вертикаль готова, начинается управляемая инфраструктурная итерация:
- подключаются новые креды в `bootstrap/host/config.env`;
- подготавливается серверный базовый слой;
- поднимается Kubernetes-контур;
- проверяется базовый слой сети и storage;
- проверяется доступ к registry и секретам.

Wave 6 специально не описывает здесь конкретные shell-команды как канонику, потому что это будет частью уже кодовой deploy-реализации.

При этом способ входа в bootstrap первой версии фиксируется уже сейчас:
- стартовым входом служит один shell-скрипт под Debian/Ubuntu;
- он работает как пошаговый launcher и валидатор входных данных;
- на входе он спрашивает адрес сервера, пользователя, способ входа, ключ или пароль, а также проверяет базовую достижимость и корректность DNS/адреса;
- после авторизации он подготавливает сервер, ставит необходимые зависимости, Go и toolchains;
- затем устанавливает через `go install` серверный TUI-инсталлятор и запускает его уже на целевой машине;
- дальнейшая пошаговая настройка сервера, firewall, кластера, Vault, SSO и самой платформы идёт через этот TUI-инсталлятор, а не через бесконечный набор ручных shell-команд.

### Фаза 3. Platform infrastructure bootstrap
После подготовки хоста выполняется bootstrap базового слоя платформы:
- namespaces;
- PostgreSQL и owner-базы;
- secret bindings;
- базовые shared dependencies;
- readiness infrastructure для owner-сервисов.

### Фаза 4. Owner-services bootstrap
Дальше в cluster поднимаются:
1. owner-сервисы;
2. edge-контуры;
3. `web-console`;
4. seed bootstrap встроенных объектов.

Фактически эта фаза должна впервые дать работоспособный новый production-контур.

### Фаза 5. Первичная продуктовая проверка
После bootstrap новой версии выполняется обязательный вертикальный smoke:
- вход пользователя;
- открытие командного центра;
- создание или открытие проекта;
- provider connectivity;
- запуск хотя бы одного рабочего flow;
- прохождение хотя бы одного `code-only` и одного `full-env` сценария;
- видимость `run`, `job`, slot и operator inbox.

### Фаза 6. Gate перехода к дальнейшему расширению
Только после успешной первичной вертикальной проверки допускается:
- расширять deploy на дополнительные контуры;
- включать более сложные automation rules;
- подключать внешние package sources;
- углублять production governance и billing;
- считать новую платформу готовой к следующему рабочему этапу.

## 4. Что должно быть подготовлено до подключения серверных cred

### 4.1. Документация
К моменту старта первой server-итерации в канонике должны существовать:
- все документы waves 0-6;
- backlog checkpoint package после wave 6;
- актуальный порядок кодовых волн;
- актуальный deploy/runbook базовый слой для новой архитектуры.

### 4.2. Кодовая база
К этому моменту код должен уже содержать:
- минимальный вертикальный срез новой архитектуры;
- явный runtime/deploy path для новой версии;
- documented bootstrap-point для seed и owner-баз;
- operator-visible status path;
- отсутствие старых редакций сервисов в активном build/deploy graph.

### 4.3. Базовый GitHub/provider-контур
К этому моменту должна быть понятна и готова:
- модель machine accounts;
- provider permissions для новой вертикали;
- правила, какие операции делает долгоживущий slot-агент через `gh` или provider API, а какие идут через platform MCP.

## 5. Exit criteria wave 6
Wave 6 считается завершённой, если одновременно выполнены все условия:
1. runtime, deploy и bootstrap описаны отдельной каноникой;
2. последовательность первого deploy новой версии зафиксирована;
3. зафиксирован gate, что до deploy нужен минимальный вертикальный срез, а не набор независимых сервисов;
4. зафиксирован backlog checkpoint как обязательный шаг перед wave 7;
5. зафиксировано, что новые серверные креды подключаются только в момент deploy-итерации, а не заранее "на всякий случай".

Если хотя бы один из этих пунктов не выполнен, wave 6 нельзя считать закрытой.

## 6. Что именно должно попасть в backlog checkpoint
Backlog checkpoint после wave 6 должен дать на выходе:
- перечень legacy-задач, которые закрываются как неактуальные;
- перечень задач, которые перепривязываются к waves 7-17;
- первую кодовую очередь для wave 7;
- список документов из `docs/**`, которые уже считаются историческими reference для новых доменов;
- список PR и GitHub-артефактов, которые надо выровнять до начала новой кодовой очереди.

Backlog checkpoint не подменяется словами "потом разберёмся по ходу". Это отдельный управленческий результат.

## 7. Что нельзя делать после wave 6
После wave 6 нельзя:
- начинать код одновременно по нескольким несвязанным доменам без очереди волн;
- тащить в первую server-итерацию legacy deploy path как основу новой платформы;
- к моменту первого deploy оставлять старые редакции сервисов в активных `services/**` и в активном deploy-графе;
- подключать сервер и кластер только ради проверки отдельных старых сервисов;
- трактовать одноузловой старт как оправдание для single-cluster жёстких допущений в коде и БД;
- пропускать backlog checkpoint из-за спешки перейти к реализации.

## 8. Следующий шаг после принятия wave 6
Следующий обязательный шаг программы:
1. провести backlog checkpoint;
2. выровнять GitHub backlog и связанные PR/Issue;
3. открыть первую кодовую доменную волну — wave 7 `Access and accounts`.

Любой другой порядок считается отклонением от программы и требует отдельного согласования.
