PLATFORM_V2.md

Версия: 0.1.0 (концепция)
Дата: 2026-03-07
Статус: DESIGN

1. Зачем

Текущая архитектура — монолит: платформа, разработка и проекты на одном сервере в одном git-репо.

Проблемы:
- Платформенный код и проектный код перемешаны
- Нельзя дать доступ к одному проекту без доступа ко всему
- При масштабировании — узкое место в одном сервере
- Drupal/CS-Cart проекты тянут платформенный git за собой

Цель V2: разделить три зоны ответственности физически.

2. Три сервера

┌──────────────────────┐   деплой    ┌──────────────────────┐
│   ARCHITECT          │ ──────────► │   PLATFORM           │
│                      │             │                      │
│  Строим платформу    │             │  Разрабатываем       │
│  Стандарты, агенты,  │             │  проекты (на стеках  │
│  библиотека, шаблоны │             │  или ProCoder)       │
└──────────────────────┘             └──────────────────────┘
                                              │ деплой
                                              ▼
                                     ┌──────────────────────┐
                                     │   MANAGEMENT         │
                                     │                      │
                                     │  Проекты работают    │
                                     │  ProCoder-проекты    │
                                     │  живут здесь         │
                                     └──────────────────────┘

Architect сервер

Зона: создание и развитие платформы
Что живёт:
- architect/ — методология, стандарты, шаблоны
- system/ — агенты, планировщик, мониторинг
- library/ — библиотека компонентов
- @templates/ — шаблоны проектов
- solutions/ — готовые решения
- constructors/ — конструкторы

Git: собственный репозиторий платформы
Кто работает: Claude-архитектор, разработчики платформы
Результат: артефакты деплоятся на Platform сервер

Platform сервер (сервер разработки)

Зона: разработка конкретных проектов
Что живёт:
- Развёрнутая версия платформы (из Architect)
- Проекты в разработке ($PROJECTS_DEV/)
- Git-система для проектов (одна на всё или per-project)

Два режима работы:
1. На стеках — Drupal, CS-Cart, Python — код проекта в репо проекта
2. На ProCoder — проект на собственном кодере платформы

Git: отдельный git-сервер для проектов (возможно Gitea self-hosted)

Management сервер

Зона: эксплуатация готовых проектов
Что живёт:
- ProCoder-проекты в production ($PROCODER_HOME/)
- Каждый ProCoder-проект — свой запущенный инстанс

Стековые проекты (Drupal, CS-Cart и т.п.) — живут где угодно:
- На хостинге заказчика
- На отдельном VPS
- Не зависят от Management сервера

3. Git-топология

Сейчас (V1, монолит)

$WORKSPACE/          ← один git-репо на всё
├── architect/
├── system/
├── library/
├── projects/        ← проекты внутри
└── ...

Целевое (V2, три сервера)

Architect сервер:
  $ARCHITECT_HOME/   ← git-репо платформы
    ├── architect/
    ├── system/
    ├── library/
    ├── @templates/
    └── solutions/

Platform сервер:
  $PLATFORM_HOME/    ← развёрнутая платформа (из Architect git)
  $PROJECTS_DEV/     ← репозитории проектов в разработке
    ├── lideravto/   ← свой git-репо (или submodule)
    └── pirotehnika/ ← свой git-репо

Management сервер:
  $PROCODER_HOME/    ← ProCoder-проекты в production
    └── {project}/   ← каждый проект свой git-репо

Варианты git для проектов

Вариант	Описание	Когда
A. Per-project repo	Каждый проект — свой git	Drupal, CS-Cart (уже на стеке)
B. Shared projects repo	Один репо для всех проектов платформы	ProCoder-проекты
C. Mono + submodules	Платформенный репо + submodule для каждого стека	Переходный период

Рекомендация:
- Стековые проекты (Drupal, CS-Cart) → Вариант A (per-project)
- ProCoder-проекты → Вариант B (shared или per-project)

4. Переменные окружения

Текущие (V1)

WORKSPACE=/opt/claude-workspace   # монорепо, всё здесь
DATASPACE=/mnt/beget-s3           # S3 данные проектов

Новые (V2)

# Architect сервер
ARCHITECT_HOME=      # корень architect сервера
                     # пример: /opt/architect

# Platform сервер
PLATFORM_HOME=       # корень развёрнутой платформы
                     # пример: /opt/platform
PROJECTS_DEV=        # проекты в разработке
                     # пример: /opt/projects-dev

# Management сервер
MANAGEMENT_HOME=     # корень management сервера
                     # пример: /opt/management
PROCODER_HOME=       # ProCoder-проекты в production
                     # пример: /opt/procoder

# Git-серверы
GIT_PLATFORM_URL=    # git для платформы
                     # пример: git@git.architect.internal:platform
GIT_PROJECTS_URL=    # git для проектов
                     # пример: git@git.platform.internal:projects

Переходный период (один сервер, V1→V2)

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

# Сейчас (всё на одном сервере, переменные указывают на монорепо)
ARCHITECT_HOME=${WORKSPACE}
PLATFORM_HOME=${WORKSPACE}
PROJECTS_DEV=${WORKSPACE}/projects
PROCODER_HOME=${WORKSPACE}/projects

# После разделения — меняем только значения переменных
ARCHITECT_HOME=/opt/architect
PLATFORM_HOME=/opt/platform
PROJECTS_DEV=/opt/projects-dev
PROCODER_HOME=/opt/procoder

Файл: $WORKSPACE/system/platform-vars.sh — добавить новые переменные.

5. Карта компонентов: что куда переедет

6. Порядок перехода

Компонент	Сейчас	V2: Architect	V2: Platform	V2: Management
`architect/`	$WORKSPACE	✅	—	—
`system/`	$WORKSPACE	✅	деплой → ✅	—
`library/`	$WORKSPACE	✅	деплой → ✅	—
`@templates/`	$WORKSPACE	✅	деплой → ✅	—
`solutions/`	$WORKSPACE	✅	деплой → ✅	—
`constructors/`	$WORKSPACE	✅	деплой → ✅	—
`infra/`	$WORKSPACE	✅	—	—
`projects/` (стек)	$WORKSPACE	—	$PROJECTS_DEV	хостинг стека
`projects/` (procoder)	$WORKSPACE	—	$PROJECTS_DEV	$PROCODER_HOME

Фаза 0 (сейчас):
  → Добавить новые переменные в platform-vars.sh
  → Все новые доки писать без хардкода (только переменные)
  → Реестр изменений (раздел 7) — фиксировать что надо будет поменять

Фаза 1 (подготовка):
  → Вынести каждый IT-проект в свой git-репо
  → Настроить .gitignore под каждый стек
  → Проверить что всё работает через переменные

Фаза 2 (разделение Architect):
  → Поднять Architect сервер
  → Мигрировать architect/ system/ library/ туда
  → Настроить деплой платформы на Platform сервер

Фаза 3 (разделение Management):
  → Поднять Management сервер
  → Перенести ProCoder-проекты
  → Настроить git-деплой из Platform → Management

7. Реестр изменений при переходе

Сюда добавляется запись при создании/изменении любого документа платформы
который содержит пути, переменные или топологические допущения.

Документ	Что зависит от топологии	Что изменить при V2
`system/platform-vars.sh`	Определяет $WORKSPACE, $DATASPACE	Добавить новые переменные (раздел 4)
`infra/scripts/backup.sh`	Использует $WORKSPACE, $DATASPACE	Проверить что использует переменные, не хардкод
`infra/scripts/cleanup-*.sh`	Используют $WORKSPACE	Уже через переменные — ок
`architect/standards/PROJECT_STANDARD_IT.md`	Пути проектов $WORKSPACE/projects/	→ $PROJECTS_DEV/{org}/
`architect/standards/PROJECT_PROCESSES.md`	Пример пути `projects/org/lideravto/`	→ переменная $PROJECTS_DEV
`CLAUDE.md` (корневой)	$WORKSPACE = /opt/claude-workspace	Разделить на три секции по серверам
`@templates/`	Пути относительные — ок	Проверить ссылки на ../architect/

PLATFORM V2 — Переход на трёхсерверную архитектуру