RE:CORE — как устроена наша разработка

0Кому этот документ

Если тебе приходится гуглить слова вроде «git merge» или «docker compose» — ты по адресу. Этот документ специально написан так, чтобы каждый термин объяснялся простым языком прямо в тексте. Ничего специально не пропускаем.

1Основы за 10 минут

Если ты никогда не работал с кодом — прочти этот раздел. Без него дальше будет непонятно.

1.1 Git — «машина времени для файлов»

Git — программа, которая запоминает каждое изменение в проекте. Если что-то сломалось, ты возвращаешься к предыдущей версии за 2 секунды.

1.2 CI/CD — «робот-проверяльщик»

CI/CD (Continuous Integration / Continuous Deployment) — автоматический робот, который просыпается каждый раз, когда ты что-то запушил. Он:

1. Берёт твой код
2. Собирает из него программу (билдит)
3. Запускает тесты (проверяет что ничего не сломано)
4. Если всё ок — отправляет результат на сервер / в магазин приложений / в панель
5. Если плохо — пишет тебе «всё, дальше не пущу, смотри ошибку»

У нас CI называется GitLab CI. Он настроен в файле .gitlab-ci.yml в корне каждого репо. Тебе редактировать его обычно не надо — Никита уже всё настроил.

1.3 Pipeline, Job, Stage, Artifact

Это термины которые ты увидишь в логах и в GitLab-интерфейсе.

1.4 Docker — «виртуалка для программы»

Docker упаковывает программу вместе со всем, что ей нужно для работы (Node.js, Python, библиотеки, env-переменные) в один контейнер. Получается коробка которую можно запустить где угодно и она будет работать одинаково — на ноуте разработчика, на сервере, в CI.

1.5 Manifest — «паспорт программы»

Каждая наша сборка отдаёт JSON-файл со своей «биографией»: какая версия, какой коммит, какие endpoint-ы она открывает, какая версия базы данных нужна. Это и есть manifest.

{
  "version": "1.2.3",
  "channel": "stable",
  "gitCommit": "abc1234",
  "builtAt": "2026-04-22T10:00:00Z",
  "compatibility": {
    "dbSchemaVersion": 42,
    "breakingChanges": false,
    "minPanelVersion": "1.0.0"
  },
  "endpoints": {
    "health":   "/health",
    "manifest": "/api/manifest"
  },
  "required": {
    "env":   ["DATABASE_URL", "JWT_KEY"],
    "ports": [5000]
  },
  "migrations": ["001_InitialCreate.sql", "002_AddUsers.sql"]
}

1.6 Merge Request (MR) — «заявка на слияние веток»

Когда ты закончил работу в своей ветке, ты хочешь её содержимое влить в test или main. Для этого в GitLab создаётся Merge Request (в GitHub это называется Pull Request, но суть та же).

• MR — это страница в GitLab где видны все твои изменения построчно
• Там же проходит CI — если упал, кнопка «merge» неактивна
• Другой член команды делает code review — читает диффы и оставляет комментарии
• Когда все довольны — нажимается кнопка «Merge», и твой код попадает в целевую ветку

1.7 Зачем всё это

Потому что мы работаем в команде и с нейросетями. Нейросеть может что-то сломать в тихаря: починить одно, сломать другое. Без CI мы этого не заметим до жалобы клуба. С CI — машина проверит за нас: код не попадёт в прод, пока не пройдёт все проверки.

2Глоссарий терминов

Если встретишь в тексте или в логах непонятное слово — ищи тут.

Api (API)

Программный интерфейс. У нас чаще всего — HTTP endpoint на бэке, к которому стучатся мобилки, админка и клиенты. Пример: POST /api/auth/login.

Artifact (артефакт)

Файл, который один CI-job передаёт следующему. Обычно лежит 30 дней в GitLab и его можно скачать.

Backend / Frontend

Backend — программа на сервере (API, обработка данных). Frontend — то что пользователь видит (сайт, мобилка, десктоп).

Branch (ветка)

Параллельная версия репозитория. У нас используются: test (самое свежее), beta (проверка), main (то что у клиентов), feature/* (твоё рабочее).

Build (сборка)

Процесс превращения исходного кода в запускаемую программу. Для Docker — docker build, для Android — сборка APK, для сайта — npm run build.

CI/CD

Continuous Integration / Continuous Deployment. Робот-автоматизатор проверок и выкладок.

Channel (канал)

Уровень «зрелости» версии. У нас три: test (экспериментальное), beta (проверяется 2-3 клубами), stable (идёт всем).

Commit (коммит)

Сохранение изменений в Git. Имеет уникальный id (SHA) и подпись.

Container (контейнер)

Запущенная программа внутри Docker. Изолирована от системы как песочница.

Dockerfile

Рецепт сборки Docker-образа.

Endpoint

Конкретный адрес у API. Пример: GET /health, POST /api/clubs/new.

Env (environment variable)

Переменная окружения — настройка программы, которую задают снаружи, а не хардкодят в коде. Нужна чтобы одна и та же программа на ноуте разработчика, в CI и в проде подключалась к разным БД/серверам/ключам без правки исходников.

Что там обычно лежит:

• DATABASE_URL — строка подключения к БД: postgres://user:password@host:5432/dbname
• JWT_SECRET, JWT_KEY — секретный ключ для подписи токенов авторизации
• REDIS_URL — адрес кэша
• TELEGRAM_BOT_TOKEN, GITLAB_TOKEN, OPENAI_API_KEY — токены внешних API
• APP_VERSION, APP_CHANNEL, APP_GIT_COMMIT — CI прокидывает сюда версию и SHA коммита, программа печатает их в /api/manifest
• NODE_ENV, ASPNETCORE_ENVIRONMENT — development / production, меняет логирование и оптимизации
• PORT — на каком порту слушать

Где хранятся: локально в файле .env (который никогда не коммитится в git — он в .gitignore). В проде — в docker-compose.yml через env_file, в CI — в Settings → CI/CD → Variables. Правило: если ты видишь токен или пароль в коде напрямую — это баг, переноси в env.

В коде читаются так: process.env.DATABASE_URL (Node.js), os.environ["DATABASE_URL"] (Python), Environment.GetEnvironmentVariable("DATABASE_URL") (.NET).

Health (health-check)

Специальный endpoint (обычно /health) который возвращает 200 OK если программа жива.

Image (Docker image)

Сохранённый образ программы в Docker. Из него создают контейнеры.

Job / Stage / Pipeline

Pipeline — один запуск CI целиком. Stage — этап внутри pipeline (build, validate, publish). Job — конкретная команда в этапе. Подробно: раздел 1.3.

Manifest

Паспорт версии в JSON: какая версия, какой коммит, какие endpoints открывает, какая схема БД нужна. Панель читает его перед применением. Подробно: раздел 1.5, рантайм-вариант: раздел 19.

Merge (слияние)

Объединение веток. «Merge ветки feature/X в test» = взять все коммиты из feature/X и применить к test.

Merge Request (MR)

Заявка на merge в GitLab. В GitHub это Pull Request (PR).

Migration (миграция БД)

Скрипт для изменения структуры базы данных (добавить колонку, таблицу). Применяется автоматически при деплое.

Pipeline

Один запуск CI (весь набор jobs). Зелёный = всё ок, красный = что-то упало.

Protected branch

Ветка которую нельзя случайно сломать. В main/beta нельзя пушить напрямую — только через MR.

Pull / Push

Pull = забрать свежее с сервера, push = отправить своё на сервер.

Registry

Хранилище Docker-образов. У нас пока локально на сервере; планируется GitLab Container Registry на reborndev.ru:5050.

Regression test

Тест который проверяет что старая починенная функциональность не сломалась снова. У нас хранятся в panel.recore.su.

Rollback (откат)

Возврат к предыдущей версии программы. Панель делает авто-rollback если новая версия падает 5 минут подряд.

Runner (GitLab runner)

Исполнитель CI-задач. Отдельный компьютер на котором крутится твой pipeline.

SHA (commit hash)

Уникальный id коммита. Длинный — 40 символов, короткий — 7. Пример: a1b2c3d.

SSH

Протокол удалённого доступа. ssh root@46.37.123.214 = «зайти в чужой компьютер через терминал».

Tag

Метка на коммите. У нас версии помечаются тегами: v1.2.3.

Webview

Встроенный браузер внутри нативного приложения. В десктоп-клиенте у Андрея так показывается веб-контент.

3Как общаться с AI-чатом

Главный инструмент вайбкодера — Claude Code (основной) или Codex CLI (для оркестратора). Оба работают в терминале в папке проекта: видят файлы, правят код, запускают команды, коммитят. От того насколько точно ты формулируешь задачу зависит качество результата.

3.1 Как дать AI контекст проекта

Первое что обеспечит хороший результат — правильный контекст. Три вещи которые надо сказать AI в начале сессии:

1. Путь к проекту — в какой папке ты работаешь.
2. Краткое описание — что это за продукт и кто с ним работает.
3. Текущая задача — что именно сейчас надо сделать.

Я работаю в проекте recore-team-assistant-new, репо лежит по пути
d:\2\REBORN_client\codexrebornhub.

Это CRM + AI-агент платформа для команды. Backend — Fastify
на TypeScript, frontend — Next.js. Я пишу код только через тебя,
я не программист.

Сейчас нужно: починить баг что на странице /projects не
открывается модалка «Новый проект» — нажимаю кнопку, ничего
не происходит.

Сначала изучи репо, потом предложи план, потом реализуй.

3.2 Хорошие принципы запросов

3.3 Режим планирования (Plan Mode) и суперсилы

Claude Code — не просто автодополнение. В нём есть режимы и встроенные «скиллы» (суперсилы), которые радикально меняют поведение AI. Пользуйся ими — это разница между «генерит первый попавшийся код» и «сначала думает, потом делает».

Plan Mode (режим планирования)

Нажми Shift+Tab дважды в Claude Code — попадёшь в Plan Mode. В этом режиме AI не трогает файлы, только исследует код и пишет пошаговый план. Ты читаешь план, одобряешь его кнопкой «Accept» — и только тогда он начинает править.

Суперсилы (superpowers)

У Claude Code есть набор встроенных «скиллов» — это заготовленные процедуры которые AI знает как выполнять идеально. Они активируются когда AI видит что задача подходит, либо когда ты напрямую просишь.

Полезные режимы и команды

• /clear — очистить контекст если AI «залип» или пошёл не туда
• /compact — сжать историю разговора, освободить контекст, не теряя сути
• /review — попросить ревью текущих изменений перед коммитом
• /fast — переключиться на Opus 4.6 с ускоренным выводом (меньше задержка, та же модель)
• /help — список всех команд
• Ctrl+C — прервать текущее действие (если AI начал делать не то)
• Shift+Tab (дважды) — в Plan Mode, (ещё раз) — обратно

4Примеры запросов к AI

Эти примеры можно копировать прямо в Claude Code или Codex CLI. Замени {переменные} на свои.

4.1 Старт работы над задачей

Склонируй https://reborndev.ru/git/recore/rebornapi-backend.git в папку
d:\2\REBORN_client\rebornapi-backend, создай новую ветку
feature/fix-login-button от ветки test, и покажи что внутри проекта.
Мне нужно понять структуру.

В проекте rebornapi-backend добавь endpoint POST /api/clubs/new,
который принимает JSON { "name": "строка", "city": "строка" },
валидирует что оба поля непустые и длиной от 2 до 120 символов,
и возвращает 201 с id созданного клуба или 400 с текстом ошибки.

Используй стиль который уже есть в других контроллерах проекта.
Не забудь обновить .recore-project.yml если добавляется endpoint.

Напиши регрессионный тест который проверяет что
POST /api/auth/login с body {"login":"admin","password":"test"}
возвращает 200 и в ответе есть поле "token".

Тест добавь в формате который панель RE:CORE принимает
через /api/regression-tests. Покажи итоговый JSON который
я могу вставить в панель руками.

4.2 Разбор ошибки

У меня упал pipeline в GitLab CI, job называется validate:rebornapi.
Вот последние строки лога (прикрепляю). Объясни простыми словами
что пошло не так, и предложи что сделать. Не правь код пока я не
одобрю план.

Один из регрессионных тестов упал: имя "Логин админа клуба работает".
Ошибка: ожидали 200, получили 500.

Изучи последние изменения в ветке test, найди что именно могло
сломать логин, покажи мне предполагаемую причину и план починки.

4.3 Локальная проверка

Установи gitlab-runner локально и покажи как запустить наш
.gitlab-ci.yml на моём ноуте. Я хочу проверить pipeline
не пушая пока в GitLab.

Сервер у меня Windows, WSL есть. Пиши команды по шагам, я буду
запускать и показывать вывод.

Я склонировал recore/rebornapi-backend. Помоги запустить проект
локально: что установить, какие env-переменные задать, какие порты
откроются. После запуска мы должны увидеть ответ 200 от /health.

У меня Windows 11, Docker Desktop установлен.

4.4 Создание MR

Сделай коммит всех текущих изменений с понятным сообщением,
запушь ветку в origin, и создай Merge Request в GitLab
(reborndev.ru/git) с целевой веткой test.

В описании MR напиши:
- что именно было сделано (bullet list)
- что нужно проверить ревьюверу
- ссылка на задачу (если есть номер — спроси у меня)

В конце дай мне ссылку на созданный MR.

4.5 Просьба объяснить код

Объясни мне файл src/routes/auth.ts простыми словами. Я не
программист. Для каждой функции — что она делает и когда вызывается.
Если что-то кажется странным или потенциально багованным — тоже
подсвети.

5Чего НЕ делать с AI

6Как читать ошибки CI

Когда в GitLab pipeline загорелся красным — не паникуй. Вот как смотреть что случилось.

6.1 Где смотреть

1. Открой https://reborndev.ru/git → свой репо → вкладка CI/CD → Pipelines
2. Найди красный pipeline (недавний, твоё имя в авторе)
3. Кликни на красный кружок — увидишь список jobs
4. Клик по красному job → откроется лог выполнения
5. В логе ищи строки со словами ERROR, FAILED, Error:

6.2 Типовые ошибки и что они значат

6.3 Как скормить ошибку AI

Не копируй весь лог — копируй последние 50-100 строк, там самое важное. В Claude Code просто скажи: «прочти лог последнего pipeline и объясни что не так».

Pipeline упал на этапе {build|validate|publish|regression}.
Последние 100 строк лога:

---
[сюда вставь лог]
---

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

7Первый день: общая подготовка

Это надо сделать всем, вне зависимости от роли. Дальше — индивидуальные инструкции по проектам.

7.1 Программы которые надо установить

7.2 Ссылки — сохрани в закладки

7.3 Настройка рабочего места — одним промптом

Не настраивай Git/GitLab руками — запусти Claude Code в папке где будут проекты, и вставь этот промпт. ИИ сам проверит что стоит, что не стоит, установит недостающее, поставит git config, подскажет где брать токен GitLab и склонирует первый репо.

Настрой мне рабочее место разработчика RE:CORE с нуля. Я вайбкодер,
я не программист — делай сам, не проси меня копировать команды.

МОИ ДАННЫЕ:
- Имя: {Моё Имя}
- GitLab email: {my@email.com}
- GitLab логин: {выданный Никитой}
- Рабочая папка: d:\2\REBORN_client  (Windows) или ~/recore (macOS/Linux)
- Моя роль: {мобилка / админка / бэкенд / CRM / биллинг / CCTV / техпанель / десктоп}

ЧТО ПРОВЕРИТЬ И ПОСТАВИТЬ (в этом порядке, пропускай если уже стоит):

1. Git — git --version
   Windows: winget install Git.Git --silent --accept-package-agreements --accept-source-agreements
   macOS: xcode-select --install
   Linux: sudo apt-get install -y git

2. Node.js 20 LTS — node --version
   Windows: winget install OpenJS.NodeJS.LTS --accept-source-agreements
   macOS: brew install node@20
   Linux: curl -fsSL https://deb.nodesource.com/setup_20.x | sudo bash && sudo apt install -y nodejs

3. Docker Desktop — docker --version
   Windows: winget install Docker.DockerDesktop
   macOS: brew install --cask docker
   Linux: curl -fsSL https://get.docker.com | sh

4. Claude Code — claude --version
   Если нет: npm install -g @anthropic-ai/claude-code

5. Codex CLI (для AI-оркестратора) — codex --version
   Если нет: npm install -g @openai/codex

6. Git config (если ещё не задан):
   git config --global user.name "{Моё Имя}"
   git config --global user.email "{my@email.com}"
   git config --global core.autocrlf true  # только Windows
   git config --global init.defaultBranch main

ЛОГИН В GITLAB:
7. Открой в браузере https://reborndev.ru/git, залогинься.
8. Настрой 2FA (Settings → Account → Enable 2FA) — обязательно.
9. Создай Personal Access Token: User Settings → Access Tokens
   scope: api, read_repository, write_repository.
   Скопируй токен (показывается только один раз).
10. Сохрани токен в gh-кеш чтобы git не спрашивал пароль:
    echo "https://{gitlab-login}:{token}@reborndev.ru" >> ~/.git-credentials
    git config --global credential.helper store

КЛОНИРУЙ МОИ РЕПО ПО МОЕЙ РОЛИ:
11. На основе поля «роль» выше выбери нужные репо из раздела
    «Первый день» документа https://reborndev.ru/info/ и склонируй.
    Для каждого: cd папка → git checkout test.

ПОСЛЕ УСТАНОВКИ:
12. Покажи мне список что установил, что уже стояло, что пропустил.
13. Проверь что в каждом склонированном репо git remote -v
    указывает на reborndev.ru/git.
14. В конце выведи единую короткую инструкцию «что делать дальше»
    (открой такой-то репо, прочитай CLAUDE.md, следующий шаг — прочитать
    раздел про твою роль в https://reborndev.ru/info/).

Если какой-то шаг требует моего ввода (пароль, 2FA код, токен) —
остановись и напиши чего тебе не хватает. Всё остальное делай сам.

7.4 Первый тестовый коммит

После настройки открой любой из склонированных репо, запусти Claude Code и попроси:

Создай новую ветку feature/{моё-имя}-hello от test, сделай
в README.md пометку «{Моё Имя} подключился {сегодняшняя дата}»,
закоммить, запушь в origin и создай MR в test через GitLab API
(reborndev.ru/git). В описании MR — одна строка «первый коммит
нового участника команды».

Через 2-3 минуты CI прогонится, MR появится на https://reborndev.ru/git → твой репо → Merge Requests. Никита увидит, одобрит, смерджит. Это подтверждение что связка ноут → git → GitLab → CI → панель работает у тебя end-to-end.

8Первый день — Гвоздев Дмитрий

8.1 Твои репозитории

• https://reborndev.ru/git/recore/rebornapi-backend.git — основной API
• https://reborndev.ru/git/recore/reborn-admin-frontend.git — админ-панель клуба

8.2 Пошаговая подготовка

8.3 Типичные задачи Димы

• Новый endpoint в API → ветка feature/api-{short-name} → MR в test
• Изменение схемы БД → обязательно миграция + бамп dbSchemaVersion в .recore-project.yml
• Баг в админке → ветка fix/admin-{short-name} → MR с регрессионным тестом
• Hotfix в проде → отдельный процесс: ветка hotfix/* → MR в main с меткой «hotfix» + два апрува

8.4 Что тебе важно помнить

9Первый день — Теплов Влад

9.1 Твои репозитории

• recore/mobile-client-android (PID=63) — Android (native Kotlin + Jetpack Compose, в папке native-android/)
• recore/mobile-client-ios (PID=64) — iOS (Swift)

Обе ветки test → beta → main уже настроены. main и beta protected (Maintainer-only merge), test доступен для пуша всем разработчикам репо.

9.2 Как собрать AAB через GitLab CI (рекомендуется)

Pipeline сам подписывает релизный AAB production-ключом (без debug-key). Триггерится на каждый push в test, beta, main.

git checkout test && git pull
git checkout -b feature/my-thing
# правки в native-android/
git push origin feature/my-thing

9.3 Как собрать AAB локально (если CI лежит или нужно отладить)

Понадобится JDK 17 + Android SDK (через Android Studio).

# 1. Клон репо
git clone https://reborndev.ru/git/recore/mobile-client-android.git
cd mobile-client-android

# 2. Переключись на нужную ветку
git checkout test  # или beta / main / feature/your-branch

# 3. Получи production keystore у Никиты (.jks файл) и пароли
#    Положи keystore в безопасное место, например ~/.keystores/recore-upload-key.jks

# 4. Экспортируй переменные окружения (под Linux/Mac)
export ANDROID_KEYSTORE=$HOME/.keystores/recore-upload-key.jks
export ANDROID_KEYSTORE_PASS='ПАРОЛЬ_KEYSTORE'
export ANDROID_KEY_ALIAS='reborngg-recore-upload'
export ANDROID_KEY_PASS='ПАРОЛЬ_КЛЮЧА'

# (Windows PowerShell)
# $env:ANDROID_KEYSTORE = "$HOME\.keystores
ecore-upload-key.jks"
# $env:ANDROID_KEYSTORE_PASS = 'ПАРОЛЬ'
# $env:ANDROID_KEY_ALIAS = 'reborngg-recore-upload'
# $env:ANDROID_KEY_PASS = 'ПАРОЛЬ'

# 5. Собрать AAB
cd native-android
./gradlew :app:bundleRelease

# 6. Файл будет здесь:
#    native-android/app/build/outputs/bundle/release/app-release.aab

9.4 Как залить AAB в Google Play

9.5 Как залить AAB в RuStore

./gradlew :app:assembleRelease
# Файл: native-android/app/build/outputs/apk/release/app-release.apk

9.6 Что важно знать

• Каждый push в test/beta/main → CI собирает signed AAB → артефакт лежит в pipeline 1 неделю
• versionCode в native-android/app/build.gradle.kts увеличивай вручную перед каждым релизом — Play не примет AAB с тем же versionCode что предыдущий
• На production-сборке ProGuard выключен (isMinifyEnabled = false). Если будут жалобы на размер AAB — включай R8/ProGuard, но тестируй прежде чем релизить
• iOS отдельный репо recore/mobile-client-ios — там нужен ApplicationVerifier через Apple Developer + сертификаты подписи. Подключение Codemagic для CI обсуждай с Никитой

10Первый день — Скоков Денис

10.1 Твой репозиторий

• recore/admin-mobile (PID=69) — Capacitor 6 monorepo: один репо собирает и Android (.aab), и iOS (.ipa) из общего React/TypeScript кода.

Структура репо:

admin-mobile/
├── src/                  ← React + TypeScript + Radix UI
├── android/              ← Capacitor-сгенерированный Android-проект (трогать редко)
├── ios/                  ← Capacitor iOS
├── ios-native/           ← переход на native iOS (в процессе)
├── public/               ← статика
├── scripts/              ← билд-скрипты
├── deploy-configs/       ← per-club appsettings
├── capacitor.config.ts   ← главный конфиг Capacitor
├── package.json
└── .gitlab-ci.yml        ← CI

Ветки test → beta → main уже настроены, main/beta protected (Maintainer-only).

10.2 Как собрать AAB локально (главный способ пока)

Понадобится: Node.js 20+, JDK 17, Android SDK через Android Studio.

# 1. Клон
git clone https://reborndev.ru/git/recore/admin-mobile.git
cd admin-mobile
git checkout test

# 2. Установить зависимости
npm install

# 3. Собрать Web (Vite билд React/TS в dist/)
npm run build

# 4. Синхронизировать собранный web в Android-проект
npx cap sync android

# 5. Получи у Никиты production keystore (.jks) и пароли.
#    Положи безопасно, например ~/.keystores/admin-mobile-key.jks
export ANDROID_KEYSTORE=$HOME/.keystores/admin-mobile-key.jks
export ANDROID_KEYSTORE_PASS='ПАРОЛЬ_KEYSTORE'
export ANDROID_KEY_ALIAS='alias-name'
export ANDROID_KEY_PASS='ПАРОЛЬ_КЛЮЧА'

# 6. Собрать AAB через Gradle
cd android
./gradlew :app:bundleRelease

# 7. Готовый файл:
#    android/app/build/outputs/bundle/release/app-release.aab

Если в android/app/build.gradle ещё нет signingConfigs.release читающий env-переменные — спроси Никиту, добавит по образцу mobile-client-android (см. раздел 9.3).

10.3 Как собрать IPA для iOS

Понадобится macOS, Xcode 15+, Apple Developer аккаунт.

# 1-3 как для Android (npm install, npm run build)
npx cap sync ios

# 4. Открыть в Xcode
npx cap open ios
# или: open ios/App/App.xcworkspace

# 5. В Xcode: Product → Archive → Distribute App → App Store Connect → Upload
# Подписи и provisioning profiles настраивает Никита через Apple Developer аккаунт

10.4 Как залить AAB в Google Play

10.5 Как залить APK в RuStore

cd android
./gradlew :app:assembleRelease
# Файл: android/app/build/outputs/apk/release/app-release.apk

10.6 Что важно знать

• Web-only HMR в разработке: npm run dev запускает Vite на http://localhost:5173 для быстрой итерации UI без пересборки нативного слоя
• Изменил web-код → нужен npx cap sync перед сборкой Android/iOS, иначе native-приложение увидит старую версию
• Изменил capacitor.config.ts или плагины (npm install @capacitor/...) → обязательно npx cap sync + проверка native-проектов
• versionCode в android/app/build.gradle увеличивай вручную перед каждым релизом — Play не примет AAB с тем же versionCode
• Push-уведомления: используется @capacitor/push-notifications. APNs-ключ для iOS лежит на panel-сервере (не в репо)
• SignalR: подключение к real-time через @microsoft/signalr — если падает, проверь сертификаты SSL для конкретного клуба
• Центральный логин: один админ → много клубов. Аутентификация через https://panel.recore.su/api/auth/admin, потом выбирается клуб из списка
• Не храни токены в коде. На Capacitor: @capacitor/preferences с шифрованием, либо нативные SharedPreferences/Keychain через bridge

11Первый день — Чернорай Влад

11.1 Твой репозиторий

11.2 Шаги подготовки

11.3 Особые требования к твоей зоне

12Первый день — Радаев Влад

12.1 Твои репозитории

• https://reborndev.ru/git/recore/cctv-analytics.git — видеоаналитика (Python, Docker)
• https://reborndev.ru/git/recore/recore-crm.git — CRM модуль заявок (часть большой CRM)

12.2 Пошаговая подготовка

12.3 Чек-поинты

• CCTV — тяжёлые модели, собирай в Docker с GPU-runtime где нужно (обсуди с Никитой)
• Заявки CRM — обязательно миграция БД + регрессионный тест на создание тикета
• Видеоаналитика имеет feature flags на клуб (не все клубы хотят распознавание лиц — комплаенс)

13Первый день — Корешов Артём

13.1 Твои репозитории

• https://reborndev.ru/git/recore/tech-panel.git — статический сайт для роутера клуба
• https://reborndev.ru/git/recore/truenas-config.git — Ansible playbook для TrueNAS

13.2 Пошаговая подготовка

13.3 Особенности зоны

• Роутеры клубов отрезаны от интернета — TechPanel заливается локально. Панель это учитывает и отдаёт zip-архив
• TrueNAS — playbook с auto-rollback: если что-то сломалось, откатывается за 5 минут на прошлый снапшот
• Для TechPanel нет E2E-тестов в обычном смысле (нет сервера), только visual-regression через Playwright screenshot compare

14Первый день — Названцев Андрей

14.1 Твой репозиторий

• https://reborndev.ru/git/recore/desktop-client.git

14.2 Пошаговая подготовка

14.3 Баг правой кнопки мыши (история)

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

Найди в коде место где инициализируется webview (Electron BrowserWindow
или WebView2 control). Отключи контекстное меню. Добавь unit-тест
который проверяет что right-click не вызывает menu.

Перед правкой — покажи план и текущее место в коде.

14.4 Специфика зоны

• Подпись .exe обязательна — иначе Windows SmartScreen блокирует запуск. CI переменные: WIN_PFX_BASE64, WIN_PFX_PASS
• Деплой на ПК клуба — через автообновление: клиент сам скачивает новую версию из панели
• Клиент всегда работает с API своего клуба (panel.recore.su/club/{id}/api), никогда не напрямую с облаком

14.5Первый день — Плужникова Катя

14.5.1 Твой репозиторий

• https://reborndev.ru/git/recore/investor-dashboard.git — отдельный repo, твой личный «песочник»
• Stack на твой выбор (обсуди с Никитой). Типичный — Next.js + Tailwind, или чистый статический сайт
• productType: static-site в манифесте

14.5.2 Шаги подготовки

14.5.3 Откуда брать данные

• Метрики из CRM — через API reborndev.ru/api/metrics/investor (Никита подготовит отдельный endpoint с агрегатами)
• Метрики клубов — через panel.recore.su/api/public-status (публичные статусы без персональных данных)
• Roadmap — можно вручную в коде или из CRM (обсуди с Никитой что проще)

15Инфраструктура

15.1 Главные адреса

15.2 Как устроены клубы

Одно API = экономия ресурсов. Отдельные БД = юридическая изоляция данных (каждый клуб — свой контур персональных данных).

15.5Справочник системы — общие endpoints и адреса

Совместная «база знаний»: куда ходят программы, какие endpoints у каждого сервиса, с чем совместимо. Если пишешь новый клиент (мобилку, десктоп, интеграцию) — сначала посмотри сюда, потом иди кодить. Эта таблица — единая правда на всю команду. Если у тебя другие адреса — значит таблица устарела, поправь.

15.5.1 Адреса — откуда что взять

15.5.2 Эндпоинты которые должны быть у каждого сервиса

Если пишешь новый бэкенд — добавь эти три endpoint сразу. Без них CI не пустит, а панель клубов не покажет версию.

15.5.3 Общие контракты данных

16Три канала релизов

16.1 Что такое «обкатка в beta 48 часов»

Версия, которая только-только опубликовалась в beta, не может прыгнуть в main. Нужно подождать — за 48 часов бета-клубы успеют обнаружить баги. Если что-то найдено — ты откатываешь, а не распространяешь дальше.

Это правило зашито в CI — job gate:check-beta. Обойти нельзя.

17Ветки и Merge Request

17.1 Структура веток

• main — protected — что сейчас у клиентов. Пушить напрямую нельзя.
• beta — protected — версии в обкатке. Пушить напрямую нельзя.
• test — свободная — самое свежее. Сюда сначала попадает весь код.
• feature/*, fix/*, hotfix/* — твои рабочие ветки. Живут пока не мерж, потом удаляются.

17.2 Формат имён веток

# Новая фича
feature/billing-hourly-rate
feature/add-club-dashboard

# Багфикс
fix/login-button-does-not-respond

# Срочный фикс в проде
hotfix/payment-double-charge

# Твой эксперимент / pet-project
experiment/try-new-ui-library

17.3 Формат коммитов

feat: добавил endpoint POST /api/clubs/new
fix: починил логин в админке клуба
chore: обновил зависимости
docs: дописал README для модуля biller
refactor: разбил auth.ts на части
test: добавил юнит-тесты для calculate-session-cost
[breaking] feat: изменил формат ответа /api/sessions

Префикс [breaking] обязателен если твой коммит ломает совместимость — например, удалил endpoint или поменял структуру JSON.

17.4 Жизненный цикл фичи

17.5GitLab — приёмы на каждый день

Практические трюки которые решают частые вопросы: «как прогнать CI но не мержить», «как не спамить код-ревьюерам пока сам не уверен», «как посмотреть что будет если смержим».

17.5.1 Прогнать проверки без пуша в main — Draft MR

Проблема: ты сделал изменения, хочешь убедиться что CI проходит и посмотреть «как эти правки сольются с main» — но пушать в main ещё рано, ревью не было, да и сам не уверен.

Решение — Draft Merge Request: MR у которого в названии префикс Draft: (или нажата галочка «Mark as draft»). Всё как у обычного MR — CI гоняется, ты видишь диффы, можешь смотреть conflicts, — но кнопка Merge отключена. Никакие случайные клики не вольют код.

17.5.2 Прогнать CI без create MR — Merge Results Pipeline

GitLab умеет запускать pipeline на временном слиянии твоей ветки с target branch (test/main) — это показывает, что будет после merge, а не что в твоей ветке сейчас.

Как включить: это настройка проекта (Settings → Merge requests → «Pipelines for merge results»). Никита включает её на ключевых репо. Тогда в каждом MR появляется дополнительный pipeline с тегом detached или merge request — это и есть прогон на «условном merge».

17.5.3 Merge train — очередь мержей

Проблема: Петя смержил свою фичу, через 2 минуты ты хочешь смержить свою. У тебя CI был зелёный, но он гнался против старого main, а теперь main изменился — и твой код уже ломается.

Решение — Merge train: ты жмёшь «Add to merge train» вместо «Merge». GitLab становит тебя в очередь: ждёт пока Петя смержится, перезапускает твой CI на обновлённом main, и только если снова зелёный — мержит. Если упал — не мержит и говорит «твой код конфликтует с недавними изменениями».

Когда нужен: если в проекте часто параллельные MR от нескольких человек (CRM, ReBornAPI). Для единоличных репо — не обязательно.

17.5.4 Pipeline против произвольной пары веток — /compare

Если хочется просто посмотреть «что будет если влить ветку X в ветку Y», не создавая MR — открой https://reborndev.ru/git/recore/{repo}/-/compare и задай from/to. Покажет дифф без создания MR и без запуска CI.

Покажи через GitLab API (reborndev.ru/git, проект {id}), что изменится
если смерджить ветку test в main. Нужен summary по файлам —
сколько строк добавилось/удалилось, какие файлы затронуты, есть ли
конфликты. Используй endpoint /repository/compare?from=main&to=test.

17.7Вкладки проекта в CRM

В разделе «Проекты» каждого проекта — 8 вкладок. Это витрина над GitLab для не-девов: Никита, менеджеры и ответственные видят состояние продукта на одном экране, не блуждая по репам. Ниже — что за каждой вкладкой стоит.

17.7.1 Что делает каждая вкладка

17.7.2 Форма «Новый проект»

Кнопка «Создать проект» в списке проектов открывает форму, которая за один запрос делает:

1. Создаёт GitLab-репо под reborndev.ru/git/recore/{path}
2. Пишет базовый .recore-project.yml (раздел 18)
3. Пишет .gitlab-ci.yml из шаблона по productType
4. Создаёт ветки test и beta
5. Ставит protected branches на main и beta (push=0, merge=Maintainers)
6. Добавляет owner-а как Maintainer
7. Регистрирует проект в CRM с человеческим именем

Поля формы: path, name (в GitLab), displayName (в CRM), description, category, platform, productType, owner, tags, qaChecklist. После создания — сразу можно клонировать и начинать работу.

17.8Автор коммита в CI — почему «Claude AI» и как вернуть своё имя

В пайплайнах иногда вместо твоего имени стоит «Claude», «AI Assistant» или пустое. Это не баг и не «ИИ украл авторство» — это про настройки git config, которые нейросеть задала себе. Объясню и дам фикс.

17.8.1 Кто кого подписывает

В каждом коммите два поля: Author (кто написал код) и Committer (кто применил коммит). Git берёт их из git config user.name и user.email. GitLab показывает в UI — Author. Пайплайн в поле CI_COMMIT_AUTHOR тоже использует Author.

17.8.2 Почему AI подписывается собой

• Claude Code при коммите иногда добавляет Co-Authored-By: Claude ... — это дополнительный «со-автор», основной остаётся твоим
• Но если ИИ запустил git config user.name "Claude" (например, в первичной настройке, когда пользователь ещё не задал свои данные) — все следующие коммиты пойдут от имени Claude
• В CI такое видно сразу: pipeline «triggered by Claude AI» вместо «triggered by vanch»

17.8.3 Починить — три команды

# 1. Проверь кто сейчас подписан
git config --global user.name
git config --global user.email

# 2. Если видишь "Claude", "AI Assistant" или что-то не твоё — переопредели
git config --global user.name "Моё Имя"
git config --global user.email "my@email.com"

# 3. Для текущего репо отдельно (если работают несколько репо с разными email):
git config user.name "Моё Имя"
git config user.email "my@email.com"

17.8.4 Что делать с уже запушенными коммитами

git rebase -i HEAD~N  # N = сколько коммитов поправить
# Для каждого замени "pick" на "edit", сохрани
# Для каждого остановка:
git commit --amend --author="Моё Имя <my@email.com>" --no-edit
git rebase --continue
git push --force-with-lease origin feature/my-branch

git rebase --exec 'git commit --amend --author="Моё Имя <my@email.com>" --no-edit' origin/test
git push --force-with-lease

18Файл .recore-project.yml

«Паспорт проекта» — один YAML-файл в корне репо, описывающий что это за продукт, кому он принадлежит, какие у него требования. Панель читает его каждый раз при релизе.

18.1 Минимальный пример

# .recore-project.yml — паспорт проекта
displayName: "ReBorn API"
description: "Бэкенд клубов (.NET 8)"
category: "club-service"
platform: "backend"
productType: "docker-image"
owner: "dima"

18.2 Все поля подробно

18.3 Примеры по типам продукта

Docker image (ReBornAPI)

displayName: "ReBorn API"
description: "Бэкенд-сервер каждого клуба (.NET 8)"
category: "club-service"
platform: "backend"
productType: "docker-image"
owner: "dima"
tags: ["api", "dotnet", "docker"]
compatibility:
  dbSchemaVersion: 42
  breakingChanges: false
  minPanelVersion: "1.0.0"
required:
  env: ["DATABASE_URL", "JWT_KEY", "REDIS_URL"]
  ports: [5000]
endpoints:
  health: "/health"
  manifest: "/api/manifest"
  auth: "/api/auth"
migrations:
  - "001_InitialCreate.sql"
  - "042_AddLoginField.sql"
qaChecklist:
  - "логин админа возвращает 200 и токен"
  - "клуб 42 открывается на /api/clubs/42"

Static site (TechPanel)

displayName: "Tech Panel"
description: "Техпанель для роутера клуба"
category: "club-static"
platform: "web"
productType: "static-site"
owner: "artem"
tags: ["static", "router"]
qaChecklist:
  - "главная страница открывается"
  - "мониторинг показывает статус всех ПК"

Mobile Android (клиентская мобилка)

displayName: "Reborn Client (Android)"
description: "Мобилка для клиентов клуба"
category: "mobile"
platform: "android"
productType: "mobile-android"
owner: "vladteplov"
tags: ["mobile", "android", "client"]
compatibility:
  minSupportedApiVersion: "2.1.0"
  targetReBornApiVersion: "2.5.0"
qaChecklist:
  - "логин по коду из SMS работает"
  - "бронь на завтра создаётся"
  - "оплата успешно проходит"

Desktop (Windows клиент)

displayName: "Reborn Desktop Client"
description: "Клиентское ПО для игровых ПК"
category: "desktop"
platform: "desktop"
productType: "win-installer"
owner: "nazvantsev"
tags: ["desktop", "windows", "webview"]
required:
  features: ["auto-update"]
qaChecklist:
  - "правый клик в webview НЕ открывает меню браузера"
  - "автообновление подхватывает новую версию"
  - "запуск игры работает"

Ansible config (TrueNAS)

displayName: "TrueNAS Config"
description: "Ansible playbook для файлового хранилища клубов"
category: "tool"
platform: "config"
productType: "ansible-config"
owner: "artem"
tags: ["ansible", "truenas", "infrastructure"]

18.4 uiContracts — защита UI от регрессий

uiContracts:
  - screen: "LoginScreen"
    url: "/login"
    mustHave:
      - "input[name=login]"
      - "input[name=password]"
      - "button[type=submit]"
    mustNotHave:
      - "text:error"   # не должно быть ошибки по дефолту
    interactions:
      - action: "input login=admin, password=test"
        expect: "redirect to /dashboard"

18.5 Что править руками, а что отдать AI

Сгенерируй .recore-project.yml для моего проекта.

Путь к репо: {путь}
Тип: {docker-image | static-site | mobile-android | ...}
Кто я: {owner}

Изучи структуру проекта, найди endpoint-ы, миграции, env-переменные.
Составь полный файл. Поле breakingChanges оставь false, если не уверен.
Поле qaChecklist — предложи 3-5 пунктов, а я добавлю ещё.

18.6 Когда и как обновлять .recore-project.yml

Это не файл «написал и забыл». Манифест обязан отражать реальное состояние проекта — иначе панель примет несовместимую версию и клуб сломается.

Триггеры — когда точно обновлять

Рабочий цикл — что идёт вместе в один MR

Я внёс изменения в ветку {branch}. Проанализируй diff (git diff
test..{branch}) и скажи что из .recore-project.yml нуждается
в обновлении. Предложи патч. Следуй таблице из
https://reborndev.ru/info/#project-yml раздел 18.6.

Особо внимательно посмотри: миграции, новые/изменённые endpoints,
новые env-переменные, breaking changes в API.

19manifest.json в рантайме

Помимо .recore-project.yml (который лежит в репо), твой работающий продукт должен отдавать свой manifest в рантайме на endpoint /api/manifest. Это то, что панель дёргает когда проверяет конкретный запущенный контейнер.

19.1 Пример ответа

{
  "version": "1.2.3",
  "channel": "stable",
  "gitCommit": "abc1234",
  "builtAt": "2026-04-22T10:00:00Z",
  "compatibility": { "dbSchemaVersion": 42, "breakingChanges": false },
  "endpoints": { "health": "/health", "manifest": "/api/manifest" }
}

19.2 Где брать значения

CI прокидывает их через build-args в Dockerfile, ты читаешь из env:

// .NET пример
app.MapGet("/api/manifest", () => new {
    version    = Environment.GetEnvironmentVariable("APP_VERSION"),
    channel    = Environment.GetEnvironmentVariable("APP_CHANNEL"),
    gitCommit  = Environment.GetEnvironmentVariable("APP_GIT_COMMIT"),
    builtAt    = Environment.GetEnvironmentVariable("APP_BUILT_AT"),
    compatibility = new { dbSchemaVersion = 42, breakingChanges = false },
    endpoints = new Dictionary<string,string> {
        { "health",   "/health" },
        { "manifest", "/api/manifest" }
    }
});

206 слоёв защиты от поломок

Чтобы нейросеть (или уставший человек) не сломал прод. Каждый слой ловит свой класс багов.

20.1 Слой 1: Protected branches

20.2 Слой 2: Manifest-валидация (CI)

20.3 Слой 3: Health + endpoints probe (CI)

20.4 Слой 4: Regression tests

20.5 Слой 5: E2E Playwright

20.6 Слой 6: QA чеклист + ручной review

20.7 Что если все 6 прошли, но всё равно упало

21Регрессионные тесты

Реестр коротких API-тестов, хранящийся в panel.recore.su. Прогоняются CI против каждой сборки.

21.1 Правило

21.2 Как добавить тест через UI

1. Открой https://panel.recore.su/regression-tests
2. Жми + Добавить
3. Заполни поля:
   • Имя: «Логин админа клуба работает»
   • HTTP метод + endpoint: POST /api/auth/login
   • Body: {"login":"admin","password":"test"}
   • Ожидаемый статус: 200
   • Ожидаемые поля: {"success": true}
   • Severity: critical / error / warning
   • isRequired: если включено — failed тест блокирует publish
4. Сохрани. С этого момента каждый новый pipeline прогоняет его.

21.3 Промпт для AI: сгенерировать тест

Я только что починил баг: при пустом пароле API возвращал 500
вместо 400 "invalid credentials".

Сформируй регрессионный тест для этого бага в формате который
принимает panel.recore.su. Я скопирую JSON в форму добавления.

Формат как в этом примере:
{
  "name": "...",
  "method": "POST",
  "endpoint": "...",
  "body": {...},
  "expectedStatus": 400,
  "expectedFields": {...},
  "severity": "critical",
  "isRequired": true
}

22E2E Playwright — тесты как пользователь

E2E = End-to-End. Тесты которые эмулируют реального человека в браузере. Отличаются от unit-тестов тем что проверяют всю цепочку: клик → API → ответ → отображение.

22.1 Что такое Playwright простыми словами

Это как робот который сидит за компьютером, открывает ваш сайт и пытается им пользоваться. Если не получилось (кнопка не нажалась, страница не загрузилась, текст не появился) — тест красный.

22.2 Пример простого теста

import { test, expect } from '@playwright/test';

test('админ может войти в панель', async ({ page }) => {
  // 1. Открываем логин
  await page.goto('https://panel.recore.su/club/42/admin/login');

  // 2. Вводим данные
  await page.fill('input[name=login]', 'admin');
  await page.fill('input[name=password]', 'test');

  // 3. Жмём "Войти"
  await page.click('button[type=submit]');

  // 4. Ждём что окажемся на дашборде
  await expect(page).toHaveURL(/\/admin\/dashboard/);

  // 5. Проверяем что видно приветствие
  await expect(page.locator('h1')).toContainText('Добро пожаловать');
});

22.3 Как написать свой тест через AI

Напиши E2E-тест на Playwright который проверяет сценарий:

1. Админ открывает https://panel.recore.su/club/42/admin/login
2. Вводит login=admin, password=test
3. Жмёт "Войти"
4. Должен попасть на /admin/dashboard
5. На дашборде должна быть кнопка "Новая бронь"
6. Клик по ней открывает модалку с заголовком "Новая бронь"
7. В модалке есть поле "Имя клиента" и кнопка "Сохранить"

Используй стиль и хелперы которые уже есть в моём репо
(посмотри существующие тесты в папке tests/).
Если хелпера на логин ещё нет — создай его в tests/helpers/auth.ts.

22.4 Как запустить локально

# Установить Playwright (один раз)
npm install -D @playwright/test
npx playwright install

# Запустить все тесты
npx playwright test

# Запустить один файл
npx playwright test tests/admin-login.spec.ts

# С браузером вживую (чтобы посмотреть глазами)
npx playwright test --headed

# Открыть HTML-отчёт после запуска
npx playwright show-report

23QA-чеклист

Ручные проверки которые делает человек перед promote в stable. Хранятся в .recore-project.yml в поле qaChecklist, отображаются в панели.

23.1 Пример хорошего пункта

23.2 Как добавить пункт в CRM

1. Открой репо, отредактируй .recore-project.yml:

   qaChecklist:
     - "логин админа: admin/test → /dashboard"
     - "бронь завтра на 2 часа создаётся"
     - "КАССА → Z-отчёт скачивается PDF"
     # <-- добавь новый пункт сюда

2. Закоммить + пуш
3. CI-job sync-metadata синхронизирует в панель автоматически
4. Проверь: https://panel.recore.su/products/{твой-ключ} — в блоке «QA Checklist» пункт появился

23.3 Промпт для AI: предложить чеклист

Посмотри мой продукт {название}, изучи его функционал
(основные страницы / endpoints / фичи) и предложи 10 пунктов
для qaChecklist в .recore-project.yml.

Каждый пункт — конкретное проверяемое действие с ожидаемым
результатом. Избегай абстракций вроде "всё работает".

24Частые проблемы

24.1 «CI красный, что делать»

24.2 «Не могу запушить в main»

Это не баг, это защита. В main пушить напрямую нельзя. Правильная последовательность:

# Создай ветку от test
git checkout test && git pull
git checkout -b feature/my-change

# Работай
git add . && git commit -m "feat: описание"
git push origin feature/my-change

# В GitLab UI создай MR в test. Через CI и review оно смержится.

24.3 «Мой MR не мержится — there is a conflict»

Это значит что между твоей веткой и целевой (test) кто-то уже изменил те же строки в том же файле. Нужно разрулить.

# У себя локально:
git checkout feature/my-change
git pull origin test     # или git merge origin/test
# Git отметит конфликты <<< >>> в файлах

# Проще всего — позови Claude Code:
# "у меня git merge conflict в файлах X, Y. Разреши их сохранив смысл
#  обеих версий, объясни каждое решение."

# После разрешения:
git add .
git commit -m "chore: resolve conflicts with test"
git push

24.4 «Новая версия не появилась в панели»

24.5 «Потерял работу локально после git reset»

Не всё потеряно. Git хранит все коммиты ещё 30+ дней, даже если они вроде бы удалены.

# Покажи все движения HEAD за последние дни
git reflog

# Увидишь список, например:
#  a1b2c3d HEAD@{0}: reset: moving to HEAD~3
#  e4f5g6h HEAD@{1}: commit: фикс логина
#  i7j8k9l HEAD@{2}: commit: добавил endpoint

# Возвращаемся на нужный коммит (берём SHA)
git checkout e4f5g6h

# Если хочешь вернуть как ветку
git checkout -b recovery-branch e4f5g6h

# Всё, работа вернулась

24.6 «Docker падает: "no space left on device"»

# Почисти старые образы и контейнеры
docker system prune -a -f --volumes

# Если мало помогло — рестарт Docker Desktop (Windows/Mac)
# На Linux: sudo systemctl restart docker

24.7 «Не могу склонировать репо — permission denied»

1. Убедись что ты залогинен в GitLab (открой https://reborndev.ru/git)
2. Создай Personal Access Token (Settings → Access Tokens → scope read_repository, write_repository)
3. Используй токен как пароль при клонировании:

   git clone https://username:TOKEN@reborndev.ru/git/recore/repo.git

25Шпаргалка команд

Минимум который реально пригодится. Распечатай или сохрани в закладки.

25.1 Git — базовые

25.2 Docker — базовые

25.3 curl — проверить API

25.4 Что чаще нужно Гвоздеву Дмитрию

25.5 Что чаще нужно Теплову Владу / Скокову Денису (мобильные)

25.6 Что чаще нужно Радаеву Владу / Корешову Артёму

25.7 Claude Code (всем)

26FAQ

27Обновление софта на ПК клубов (v9+)

После MR #28 (май 2026) появилась полноценная система управления версиями десктоп-клиента и rebornapi. Эта секция — для вайбкодеров: что делать, как работает, куда смотреть когда что-то идёт не так.

Главное в трёх абзацах

1. Каналы. Любая собранная версия попадает на канал, привязанный к git-ветке: test → beta → main (=stable). Production-клубы видят только stable. Promote из канала в канал — кнопка [Promote → beta] в панели, между beta и stable обязательны 48 часов обкатки.

2. Где решается какую версию ставить. Каждый ПК клуба периодически дёргает GET /api/clients/latest?clubSlug=…&pcId=… — сервер возвращает целевую версию по приоритету: (1) pin на ПК → (2) target на клуб → (3) последняя в канале клуба. Клиент ставит то что вернулось — даже если это даунгрейд.

3. Push «обновись сейчас». Кнопка [Перепроверить обновления] в карточке клуба публикует NATS-команду recore.cmd.<club>.<pc>.RecheckUpdates — десктоп-клиент v9.2.4+ сразу опрашивает /latest и обновляется. Без push'а — обновляется при следующем плановом poll'е.

Как делать обычные операции

Инструкция для CI продукта (если делаешь новый репозиторий)

Чтобы новый продукт публиковал версии в панель, в .gitlab-ci.yml подключи стандартный шаблон:

include:
  - project: 'root/recore-platform'
    file: '/ci-templates/standard-version-manifest.gitlab-ci.yml'
    ref: main

variables:
  PRODUCT_KEY: "my-product"
  ARTIFACT_TYPE: "docker-image"   # или win-installer, static-site, mobile-android, mobile-ios, ansible-config

stages:
  - build
  - publish

В job-е сборки положи в $CI_PROJECT_DIR/manifest.json type-specific блок (для docker-image — imageRegistryUrl, для win-installer — объект installer.{url,sha256,sizeBytes}). Шаблон сам добавит tag, channel, gitCommitSha, publishedAt и POST в панель. Нужны переменные окружения CI_PANEL_URL + CI_PANEL_TOKEN — берутся из Group-level CI/CD variables в GitLab.

Эндпоинты, которые ты можешь дёргать руками

Все mutating endpoints требуют JWT (получи через POST /api/auth/login).

Что лежит в БД (для дебага)

База reborn_platform на panel-сервере (176.114.85.85:5432 через docker exec):

• clubs — добавились release_channel, client_target_version_id, is_production.
• computers — отдельная таблица в platform-DB (синкается из клубных reborn_club_*.Computers). Поля: club_id, pc_number, client_version_override, last_reported_version, last_reported_at.
• client_versions — версии десктоп-клиента, выпущенные через CI. Колонка club_slug='*' — глобальная версия для всех клубов; конкретный slug — переопределение для одного клуба.
• api_versions — то же самое для rebornapi (docker-image).
• audit_log — все админские действия с версиями. Если кто-то жалуется «сама обновилась» — смотри сюда.

NATS subjects (полезно знать)

Тестовый листенер прямо на сервере:

docker logs recore-transport-nats --tail 50 | grep "RecheckUpdates"

Если что-то сломалось

Связанные документы

• Полный runbook в репозитории: recore-platform/docs/UPDATE-SYSTEM.md
• Спека дизайна: docs/superpowers/specs/2026-05-03-update-system-design.md
• Implementation plan: docs/superpowers/plans/2026-05-03-update-system-mr28.md
• MR #28 — recore-platform, добавил всё что выше
• MR #20 в recore/desktop-client — companion с RecheckUpdates handler в .NET клиенте