autotest/DOCS/architecture-questions-for-sonnet.md

⚠️ 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 пайплайны