# ⚠️ LEGACY — НЕАКТУАЛЬНО. Исторический документ.

# Задание: архитектура приложения автотестов Nubes

## Контекст

Проект: автотесты операций сервисов облачной платформы Nubes.
Обсуждение с заказчиком: `/home/naeel/nubes/autotest/DOCS/dialogues.md`

### Что есть сейчас

1. **Flask-приложение** в `site/app.py` (задеплоено на Nubes как pythonk8s):
   - Токен-вход (cookie)
   - Показывает организацию пользователя
   - Список всех инстансов пользователя
   - Таблица сервисов с раскрытием операций (AJAX)
   - Дизайн Nubes (CSS custom properties, Lucide-иконки, карточки)

2. **API облака** (три стенда: dev/test/prod):
   - `GET /services` — список сервисов
   - `GET /services/{id}` — детали + операции
   - `GET /instanceOperations/default/{opId}` — параметры операции (valueList, dataDescriptor, isModifiable)
   - `GET /instances` — инстансы пользователя
   - `POST /instances` — создать инстанс
   - `POST /instanceOperations` — запустить операцию
   - Аутентификация: `Authorization: Bearer <TOKEN>`
   - Обязательный `User-Agent: Mozilla/5.0`

3. **YAML-конфигурации сервисов** в `/home/naeel/nubes/autotest/STANDS/` — полные описания всех сервисов и их параметров (по стендам).

### Что требуется (из диалога с заказчиком)

- Веб-интерфейс со списком сервисов-операций и статусами тестирования
- Конфигурирование тестов (НЕ кодировать)
- Возможность выбирать какие операции тестировать для каждого сервиса
- **Запуск прямо на платформе**
- Не все операции можно делать (например, организацию создавать нельзя)
- Для многих сервисов — удаление с передержкой (создать можно, удалить нельзя)
- Объекты создавать и удалять в специальной тестовой организации
- Пока со своим токеном, потом — токенами по стендам

## Вопросы для архитектурного решения

### 1. Модель данных / конфигурация тестов

Как хранить конфигурацию тестов? Нужна ли БД?

- Какие сущности: TestSuite (набор тестов), TestCase (один тест = сервис + операция), TestRun (прогон)?
- Как конфигурировать какие операции тестировать, а какие нет?
- Как задавать параметры для операций (значения полей)?
- Нужна ли привязка к конкретной организации (для isolate-тестов)?

### 2. Процесс тестирования (Pipeline)

Какая механика запуска и отслеживания:

- Пользователь выбирает сервисы/операции → нажимает «Запустить»
- Что происходит дальше? Последовательно? Параллельно?
- Как отслеживать статус каждой операции?
- Как обрабатывать долгие операции (удаление с передержкой)?
- Нужен ли откат (удалить созданное после теста)?

### 3. UI/UX

- Как должен выглядеть экран конфигурации тестов?
- Нужен ли конструктор pipeline (drag-and-drop операций)?
- Как показывать результаты: таблица? дерево? график?
- История прогонов?

### 4. Техническая архитектура

- Flask-бэкенд остаётся или что-то другое?
- Нужна ли очередь (Redis, RabbitMQ) для запуска тестов?
- Поллинг или WebSocket для статуса?
- Где хранить состояние: SQLite? PostgreSQL? Файлы?

### 5. Multi-stand

- Один инстанс приложения на все стенды или по одному на стенд?
- Как переключаться между dev/test/prod?
- Разные токены для разных стендов?

## Ограничения

- Приложение деплоится как pythonk8s на Nubes (Flask, gunicorn)
- Структура: `site/app.py` + модули в `site/`
- Импорты без префикса `site.` (папка `site/` — не пакет, конфликт со stdlib)
- `if __name__ == "__main__": app.run(host="0.0.0.0", port=5000)` — обязательно
- Минимум зависимостей (Flask, gunicorn, requests — уже есть)
- Дизайн Nubes (CSS custom properties, карточки, Lucide)

## Что НЕ нужно

- Авторизация пользователей (пока один технический токен)
- Мобильная версия
- Сложная админка
- CI/CD пайплайны