architect/prospective/process-operations.md

type: standard
aspect: process
title: "Процесс: операции платформы"
knowledge_level: У1
version: 1.0.0
date: 2026-04-10
status: active
sources:
- architect/standards/process/process-protocol.md
- architect/standards/process/process-role-management.md
- architect/standards/process/workflow-roles.md
- architect/standards/process/process-task-queue.md
- architect/standards/process/process-decision-making.md
- architect/standards/process/process-change-impact-analysis.md
- architect/standards/process/process-model-delegation.md
- architect/standards/process/process-credentials.md
- architect/standards/process/process-ssh-connection.md
- architect/standards/process/process-session-hooks.md
- architect/standards/process/process-backup.md
- architect/standards/process/process-log-archiving.md
- architect/standards/process/process-database-management.md
- architect/standards/process/process-resource-check.md

Процесс: операции платформы

Версия: 1.0.0
Дата: 2026-04-10

Операционные процессы платформы: протоколы взаимодействия, роли, очередь задач, принятие решений, инфраструктурные операции.

1. ПРОТОКОЛ ВЗАИМОДЕЙСТВИЯ

11 правил по приоритету

ПРАВИЛО 1: ПОДТВЕРЖДЕНИЕ ПЕРЕД ИЗМЕНЕНИЕМ (критический)

Никаких изменений без явного подтверждения оператора.

Требует подтверждения: создание, изменение, удаление файлов; команды с побочными эффектами; выбор из вариантов.

Не требует: чтение файлов, поиск, анализ, ответы на вопросы.

Формат:

ПЛАН:
* Файл: [путь]
* Действие: создать / изменить / удалить
* Что: [описание изменений]

Выполнить?

ПРАВИЛО 2: НЕ ВЫДУМЫВАТЬ (критический)

Если не знаешь — скажи. Не выдавай гипотезу за факт.

Уровень Значение Когда
ФАКТ 100% Прочитал в файле, проверил командой
ВЫСОКАЯ 80-95% Логический вывод из фактов
СРЕДНЯЯ 50-80% Аналогия, типичное поведение
НИЗКАЯ <50% Предположение, гипотеза

При неуверенности:

ГИПОТЕЗА:
1. [высокая] [вариант] — [почему]
2. [средняя] [вариант] — [почему]
3. [низкая] [вариант] — [почему]

Проверить: [способ]

ПРАВИЛО 3: ОДИН ОТВЕТ — ОДНО РЕШЕНИЕ (высокий)

Показал план, ждёшь подтверждения. Получил подтверждение, выполняешь. Выполнил, показываешь результат.

ПРАВИЛО 4: КОНТЕКСТ ПЕРВИЧЕН (высокий)

Сначала ГДЕ, КТО, КОГДА — потом ЧТО и ПОЧЕМУ. При неоднозначном термине — уточнять.

ПРАВИЛО 5: ОТЧЁТ ПОСЛЕ ДЕЙСТВИЯ (высокий)

ВЫПОЛНЕНО:
* Создано: [файлы]
* Изменено: [файл:строки]

ОТКАТ:
git checkout HEAD -- [файлы]

ПРАВИЛО 6: КРАТКОСТЬ (средний)

Максимум 40-50 строк за раз. Больше — разбить на части.

ПРАВИЛО 7: СТРУКТУРА ОТВЕТА (средний)

Списки и таблицы вместо абзацев. Код-блоки для технических данных. Запрещено: длинные абзацы, эмоции, вводные слова, извинения.

ПРАВИЛО 8: АЛЬТЕРНАТИВЫ С РЕКОМЕНДАЦИЕЙ (средний)

ВАРИАНТЫ:
1. [рекомендую] — [описание] — [почему]
2. [альтернатива] — [описание]
3. [не рекомендую] — [описание] — [почему]

Выбор? (1/2/3)

ПРАВИЛО 9: ФОРМЫ ПОДТВЕРЖДЕНИЯ (средний)

да, ок, +, 1 = подтверждение. 2, 3 = выбор варианта. Молчание = ждать. "наверное" = уточнить.

ПРАВИЛО 10: ПЕРЕКЛЮЧЕНИЕ КОНТЕКСТА (средний)

Вверх (файл → модуль → проект) — автоматически. Вниз (проект → модуль → файл) — с подтверждением.

ПРАВИЛО 11: ССЫЛКА НА РЕЗУЛЬТАТ (средний)

После создания/обновления документа — дать веб-ссылку:

http://91.218.142.168:8899/view/{путь относительно workspace}

Цикл взаимодействия

ЗАДАЧА → АНАЛИЗ → ПЛАН → ПОДТВЕРЖДЕНИЕ → ВЫПОЛНЕНИЕ → ОТЧЁТ

2. РОЛИ И ДЕЛЕГИРОВАНИЕ

Цепочка передачи задачи

Оператор (человек)
    ↓ ставит задачу
Архитектор — решение + ограничения + политики
    ↓
Проектор — план + контекстблоки (фильтрует по политикам)
    ↓
Кодирование — реализация блока
    ↓
Оператор (инфра) — деплой

Роли

Роль Делает НЕ делает
Архитектор Решения, политики, стандарты, паттерны Не пишет код, не управляет проектами
Проектор Декомпозиция, контекстблоки, фильтрация по политикам Не принимает архитектурных решений
Кодирование Реализация контекстблока автономно Не меняет архитектуру, не планирует
Оператор (инфра) Деплой, серверы, Docker Не пишет бизнес-логику

Управление ролями (экономия токенов)

Роль = файл *.ai.md = контекст = токены

ОПТИМУМ:     1 роль    = ~400-600 токенов
ДОПУСТИМО:   2 роли    = ~1000 токенов
МАКСИМУМ:    3 роли    = ~1500 токенов
ЗАПРЕЩЕНО:   >3 ролей

Правила:
- Загружать МИНИМУМ необходимых ролей
- При смене задачи — выгружать старую роль
- Не загружать ВСЕ роли "на всякий случай"

Делегирование моделей

Принцип: Рутину — дешёвым моделям, думать — дорогим.

Класс Тип задачи Модель Стоимость
A Поиск, форматирование, валидация Haiku 3 1x
B Анализ, explore, сравнение Haiku 3.5 3x
C Написание кода, рефакторинг, тесты Sonnet 12x
D Архитектура, планирование, решения Opus (сам) 20x

Алгоритм выбора:

1. Извлечь ключевые слова из задачи
2. Проверить триггеры:
   "найди", "grep", "список"           → Класс A → Haiku 3
   "explore", "как работает", "объясни" → Класс B → Haiku 3.5
   "напиши", "создай", "рефакторинг"   → Класс C → Sonnet
   "архитектура", "спроектируй"        → Класс D → Opus
3. По умолчанию → Класс B
4. Эскалация при неудаче (2 попытки → следующая модель)

Централизованный справочник: system/config/models.yaml — единственный источник правды. Модели не хардкодятся в программах.

3. ОЧЕРЕДЬ ЗАДАЧ

Принцип

ПЛАНИРОВЩИК (широкий контекст) → создаёт задачи → .queue/pending/
ИСПОЛНИТЕЛЬ (глубокий контекст) → берёт задачу → выполняет → .queue/done/

Хранение

/.queue/                            ← ПЛАТФОРМА (Архитектор)
├── inbox/ → backlog/ → active/ → done/

projects/{name}/.queue/             ← ПРОЕКТ (Проектор)
├── inbox/ → backlog/ → active/ → done/

Формат задачи

Имя файла: {YYYY-MM-DD}_{NNN}_{slug}.yaml

id: "2025-12-21_001"
type: "task"                    # ticket | task
created_by: "architect"
assigned_to: "coder"
importance: "high"              # critical | high | medium | low

title: "Краткое название"
description: |
  Подробное описание.

context:
  files:
    - path: "путь/к/файлу"
      reason: "Зачем читать"

action:
  type: "create"                # create | edit | delete | analyze
  target: "путь/к/целевому/файлу"
  instructions: |
    1. Первый шаг
    2. Второй шаг

expected:
  result: "Что должно получиться"
  validation: |
    - Критерий 1
    - Критерий 2

status: "inbox"                 # inbox | triaged | assigned | active | blocked | review | done

Жизненный цикл

inbox → triaged → assigned → active → review → done
                                 ↕
                              blocked
Переход Кто Когда
inbox → triaged Планировщик Разобрал, определил приоритет
triaged → assigned Планировщик Назначил исполнителя
assigned → active Исполнитель Взял в работу
active → review Исполнитель Готово, на проверку
review → done Планировщик Проверил, принял

Правила

Для планировщика: одна задача = одно действие; контекст полный; инструкции пошагово; критерии проверки.

Для исполнителя: прочитать контекст; следовать инструкциям; заполнить result; отклонить если не хватает информации.

4. ПРИНЯТИЕ РЕШЕНИЙ

Уровни риска

Уровень Что относится Действие
L0 Production, деньги >1000р, данные, необратимое Согласие + откат + двойная проверка
L1 Требования, утверждённый дизайн, scope, бюджет Согласие оператора
L2 Архитектура, план, технологии Показать план, ждать возражений
L3 Код, конфиги, реализация Делать + записать в журнал
L4 Отладка, эксперименты Делать

Золотое правило: При сомнении — уровень ВЫШЕ.

Модификаторы уровня

Повышающие (+1): утверждено оператором, деньги >1000р, внешние системы, необратимо, production.

Понижающие (-1): автооткат, dev/stage, делегировано, прототип.

ИТОГОВЫЙ_УРОВЕНЬ = БАЗОВЫЙ + ПОВЫШАЮЩИЕ - ПОНИЖАЮЩИЕ
(минимум L4, максимум L0, при сомнении округлять к L0)

Срочный режим

Срочный = потери > 500 руб/час ИЛИ блокер для команды.

Для срочного L1: если ущерб (потери x время ожидания) > 5000 руб — принять решение самостоятельно + немедленно уведомить оператора + записать в DECISIONS.md с пометкой "СРОЧНО".

Триггеры эскалации

Ситуация Действие
Задача > 2x оценки L3 → L2
> 5 файлов в разных местах L3 → L2
Конфликт с согласованным → L1
Застрял > 2 часов Эскалация выше

Каскадный анализ (для L3 и выше)

1. ПРЯМЫЕ ПОСЛЕДСТВИЯ — что меняю? файлы?
2. ЗАВИСИМЫЕ КОМПОНЕНТЫ — grep -r "имя_функции" .
3. ДОКУМЕНТЫ — какие описывают? утверждены ли?
4. ВНЕШНИЕ СИСТЕМЫ — затрагивает API/интеграции?
5. ИТОГОВЫЙ УРОВЕНЬ — MAX(всех затронутых) + модификаторы

Верификация (для L0-L2)

ХОРОШО (p=60%): что если всё по плану?
ПРОБЛЕМЫ (p=30%): что типично пойдёт не так? План Б?
ПЛОХО (p=10%): худший случай? Откат возможен?

Журналирование

Уровень Что Куда
L0 Полный лог + результат DECISIONS.md + системный лог
L1 Решение + обоснование DECISIONS.md
L2 Решение + обоснование DECISIONS.md
L3 Краткая запись log.md
L4 Только если > 15 мин debug/

5. IMPACT ANALYSIS ПРИ СМЕНЕ АДРЕСОВ

Правило

Перед сменой любого адреса — найти все места где он используется и обновить все разом.

Адрес = путь к файлу/папке, URL, порт, имя контейнера, IP, имя сервиса.

Алгоритм

# Шаг 1 — найти все упоминания
grep -r "{старый_путь}" /etc/systemd/system/
grep -r "{старый_путь}" /etc/nginx/
grep -r "{старый_путь}" /opt/claude-workspace/ \
  --include="*.yml" --include="*.yaml" \
  --include="*.sh" --include="*.env" \
  --include="*.conf" --include="*.md" \
  --exclude-dir=".git"

# Шаг 2 — составить список: файл → что менять
# Шаг 3 — обновить все файлы разом
# Шаг 4 — перенести (только после обновления ссылок)

# Шаг 5 — проверить
grep -r "{старый_путь}" /etc/systemd/system/ /etc/nginx/ /opt/claude-workspace/

Матрица: что где ссылается

Тип адреса Где искать
Путь к папке systemd, nginx, docker-compose, .env, скрипты
Порт сервиса nginx upstream, docker-compose, .env, CLAUDE.md
Имя Docker-контейнера docker-compose depends_on, .env, скрипты
URL сервиса nginx, .env, CLAUDE.md, документация
IP адрес nginx, .env, документация

6. CREDENTIALS

Системный администратор

Параметр Значение
Email admin@0kt.ru
Username admin
Роль Super Admin

Использовать для: все Docker-сервисы, все веб-приложения, все БД (admin user), все API-консоли.

Формат паролей

Шаблон: {Service}{Year}{Type}!

NocoDB2025Admin!
Drupal2025Admin!
Postgres2025Admin!

Требования: минимум 16 символов, заглавные + строчные, цифры, спецсимволы.

Процедура развёртывания

1. Создаёшь сервис
2. Admin email: admin@0kt.ru
3. Пароль: {Service}{Year}Admin!
4. Записываешь в реестр
5. Если есть secrets → отдельный файл (.env, gitignore)

Хранение секретов

7. SSH ПОДКЛЮЧЕНИЕ

Правило

ПЕРЕД ЛЮБЫМ SSH ПОДКЛЮЧЕНИЕМ:
1. Найти CONNECTION.md или .credentials.md проекта
2. Использовать только указанного SSH пользователя
3. НЕ перебирать варианты при ошибке

Как различать пользователей

Тип Признак Пример
SSH Без суффикса lideravto, root, ubuntu
MySQL Суффикс _db, _cs, _wcs lideravto_wcs
Приложение Суффикс _app, _api app_user

Алгоритм

1. Найти инфру проекта → Glob: projects/org/{name}/**/CONNECTION.md
2. Прочитать → извлечь SSH credentials (НЕ MySQL!)
3. Подключиться → ssh USER@HOST
4. При ошибке "Permission denied" → СТОП, вернуться к шагу 1

Структура CONNECTION.md

## SSH доступ
| Параметр | Значение |
|----------|----------|
| Host | example.beget.tech |
| User | example |          ← SSH пользователь

## База данных
| Параметр | Значение |
|----------|----------|
| User | example_db |        ← MySQL пользователь (ДРУГОЙ!)

8. SESSION HOOKS

Правило

Любой скрипт, запускающий claude или claude --resume, обязан сначала выполнить cd /opt/claude-workspace.

# ПРАВИЛЬНО
WORKSPACE="/opt/claude-workspace"
cd "$WORKSPACE"
claude --resume "$session_id"

# НЕПРАВИЛЬНО — хук не сработает если CWD != workspace
claude --resume "$session_id"

Как работает цепочка

cd /opt/claude-workspace
  → claude --resume
    → ищет .claude/settings.json
      → запускает хуки SessionStart → session-setup.sh
        → session-setup.sh читает CLAUDE.md → additionalContext
          → Claude получает все инструкции

Диагностика если хук не работает

# 1. Проверить что hook существует
ls -la /opt/claude-workspace/.claude/hooks/session-setup.sh

# 2. Проверить регистрацию в settings.json
cat /opt/claude-workspace/.claude/settings.json | python3 -m json.tool | grep -A10 hooks

# 3. Запустить hook вручную
echo '{"source":"resume"}' | bash /opt/claude-workspace/.claude/hooks/session-setup.sh | head -5

# 4. Проверить CWD скрипта запуска
grep -n "cd.*workspace\|WORKSPACE" /usr/local/bin/session /usr/local/bin/start

9. БЭКАПЫ

Уровни бэкапов

УРОВЕНЬ 1: Локальные
├── Где: /var/backups/dev-pro/
├── Что: SSH keys, configs
└── Когда: Вс 03:00

УРОВЕНЬ 2: S3 Hub
├── Где: hub/_backup/
├── Что: Git bundle workspace
└── Когда: Вс 04:00

УРОВЕНЬ 3: Яндекс.Диск
├── Где: yandex:/backups/
├── Что: Копии локальных бэкапов
└── Когда: После локальных

УРОВЕНЬ 4: GitHub
├── Где: github.com/...
├── Что: Код (git push)
└── Когда: После commit

Cron (DEV-PRO)

# System backup (Вс 03:00)
0 3 * * 0 /opt/.../backup.sh

# Git bundle (Вс 04:00)
0 4 * * 0 /opt/.../git-backup-s3.sh

Восстановление

# Код из Git bundle
git clone hub/_backup/workspace-YYYY-MM-DD.bundle workspace-restored

# Конфиги из локального бэкапа
tar -xzf /var/backups/dev-pro/backup-YYYY-MM-DD.tar.gz -C /

Полное восстановление DEV-PRO

  1. Развернуть новый сервер
  2. Восстановить SSH keys
  3. Clone workspace из GitHub
  4. Настроить rclone для S3
  5. Восстановить конфиги из бэкапа

Проверка

Еженедельно: бэкапы создались, размер не 0, дата актуальна.
Ежемесячно: тестовое восстановление, retention (старые удалены).

cat hub/_backup/last-backup.txt
ls -lh hub/_backup/*.bundle
du -sh hub/_backup/

10. АРХИВИРОВАНИЕ ЛОГОВ

Принцип

Логи за неделю — АКТИВНЫЕ (в /var/log)
Логи старше недели — АРХИВ (в $INFRA/logs/archive/YYYY-MM/)

Расписание

# system/scheduler/schedule.yaml
archive_logs:
  command: "bash infra/scripts/archive-logs.sh"
  cron: "0 3 * * 0"    # воскресенье 03:00
  enabled: true

Что архивируется

НЕ архивируется: текущие логи без суффикса, логи моложе 7 дней.

Экстренная очистка (диск переполнен)

# Удалить старые rotated логи БЕЗ архивирования
find /var/log -name "*.gz" -mtime +7 -delete
journalctl --vacuum-size=100M

# Затем создать архив
bash infra/scripts/archive-logs.sh

Восстановление из архива

# Посмотреть без распаковки
zcat $INFRA/logs/archive/2026-02/syslog.1.gz | less

# Распаковать
gunzip $INFRA/logs/archive/2026-02/syslog.1.gz

11. УПРАВЛЕНИЕ БАЗАМИ ДАННЫХ

Принципы

  1. Одна база на сервис — не смешивать данные. Связи через API, НЕ через foreign keys между базами.

  2. Naming Convention:

Базы:    {service}_{env}       → platform_ui_prod, platform_ui_dev
Таблицы: {entity} (plural)     → users, tasks, chat_history
Колонки: {field_name}          → created_at, user_id, is_active
Индексы: idx_{table}_{column}  → idx_users_email
  1. Стандартные поля (каждая таблица):
id              SERIAL PRIMARY KEY
created_at      TIMESTAMP DEFAULT CURRENT_TIMESTAMP
updated_at      TIMESTAMP DEFAULT CURRENT_TIMESTAMP

Опционально: deleted_at (soft delete), created_by, updated_by.

Миграции

Файлы: migrations/NNN_description.sql (3 цифры, инкрементально).

Каждая миграция:
- Идемпотентная (можно запустить N раз)
- Имеет rollback (DOWN)
- Протестирована на dev

-- UP
CREATE TABLE IF NOT EXISTS users (
    id SERIAL PRIMARY KEY,
    email VARCHAR(255) NOT NULL UNIQUE,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

-- DOWN (закомментировано)
-- DROP TABLE IF EXISTS users;

Применение:

# Development
psql -U postgres -d platform_ui_dev -f migrations/001_initial_schema.sql

# Production (с бэкапом!)
pg_dump -U postgres platform_ui_prod > backup_before_001.sql
psql -U postgres -d platform_ui_prod -f migrations/001_initial_schema.sql

Доступ

-- Приложение (CRUD)
GRANT SELECT, INSERT, UPDATE, DELETE ON ALL TABLES TO platform_ui_app;

-- Read-only (мониторинг)
GRANT SELECT ON ALL TABLES TO platform_ui_ro;

-- Superuser (только миграции)
-- postgres

Бэкапы БД

# Перед критичными изменениями
pg_dump -U postgres platform_ui_prod > backup_before_migration_$(date +%Y%m%d_%H%M%S).sql

Автоматические: ежедневно 03:00 UTC, retention 7 дней, локация $INFRA/backups/databases/.

Security чеклист

12. ПРОВЕРКА РЕСУРСОВ

Когда проверять

Действие Проверка
Docker контейнер, деплой сайта Да
npm install, pip install Да
Импорт >100MB, бэкап БД Да
Запуск скрипта, редактирование Нет

Уровни состояния

ЗЕЛЁНЫЙ — можно развёртывать:

RAM Available > 500 MB, Swap Used < 50%, Диск Used < 80%, Диск Free > 5 GB

ЖЁЛТЫЙ — с осторожностью:

RAM 200-500 MB ИЛИ Swap 50-80% ИЛИ Диск 80-90% ИЛИ Диск Free 2-5 GB
→ Выполнить L0 очистку → повторить проверку → предложить L1 если не помогло

КРАСНЫЙ — стоп:

RAM < 200 MB ИЛИ Swap > 80% ИЛИ Диск > 90% ИЛИ Диск Free < 2 GB
→ L0 очистка → L1 с подтверждением → отказать если не помогло

Скрипт проверки

bash /opt/scripts/check_resources.sh
# GREEN → продолжай / YELLOW → cleanup / RED → СТОП

Уровни очистки

L0 — автоматическая (без вопросов):

apt-get clean                    # 100-500 MB
pip cache purge                  # 50-200 MB
journalctl --vacuum-time=3d      # 100-500 MB
rm -rf /tmp/*.log /tmp/*.tmp /tmp/pip-*   # 10-100 MB
docker system prune -f           # 500 MB-5 GB
find . -name "__pycache__" -exec rm -rf {} +

L1 — с подтверждением пользователя:

Что Риск
/tmp/* полностью Потеря temp файлов
snap ненужные Нужна переустановка
node_modules старше 30 дней npm install заново
venv старше 30 дней pip install заново
Docker volumes unused Потеря данных!

L2 — только вручную: логи приложений, активные Docker volumes, файлы проектов, бэкапы.

Типичные пожиратели места

Компонент Типичный размер
Docker images 500 MB - 10 GB
Docker volumes 100 MB - 50 GB
Snap пакеты 100 MB - 2 GB каждый
node_modules 200-500 MB каждый
venv 100-500 MB каждый
/tmp 0 - 10 GB
/var/log 100 MB - 5 GB

Версия: 1.0.0