app-autotest/DOCS/sonnet-architecture-review-v1.0.89.md

Запрос к Claude (Sonnet): архитектурный аудит app-autotest v1.0.89

Цель: получить анализ текущей архитектуры и рекомендации по развитию проекта. Дата: 27.07.2026 Версия: 1.0.89

---

1. О проекте

Что делает

Flask-приложение для ручного тестирования операций облачной платформы Nubes:

• CREATE — создать инстанс сервиса с параметрами
• MODIFY — изменить параметры существующего инстанса
• DELETE / SUSPEND / RESUME / REDEPLOY — управление инстансом

Как работает сейчас

• Один HTML-файл (index.html) с ванильным JS — без фреймворков, без SPA
• Бэкенд: Flask + gunicorn (несколько воркеров)
• Все данные — из REST API Nubes (никакого локального кеша, кроме краткосрочного трекера)
• Трекер инстансов: JSON-файлы в /tmp/ под fcntl.flock
• Автоопределение стенда (dev/test) по JWT-токену

Текущая файловая структура

app-autotest/
├── site/
│   ├── app.py                    ← Flask(__name__), blueprints, /health
│   ├── api/
│   │   └── http_client.py        ← HttpClient, автостенд
│   ├── operations/
│   │   ├── get_params.py         ← слияние state.params + шаблон
│   │   ├── get_services.py       ← API-обёртки
│   │   ├── get_instances.py      ← пагинация
│   │   └── tracker.py            ← /tmp/instances-{clientId}-{stand}.json
│   ├── routes/
│   │   ├── main.py               ← GET/POST /, /api/operations/<svc_id>
│   │   ├── api.py                ← [LEGACY] раннер тестов
│   │   └── api_test.py           ← /api/test, /api/params, /api/log
│   ├── templates/
│   │   └── index.html            ← весь UI (~400 строк)
│   └── static/
│       └── style.css
├── DOCS/
│   ├── ARCHITECTURE.md           ← актуальная архитектура
│   ├── ARCHITECTURE.legacy.md    ← старая версия
│   ├── HISTORY.md                ← история версий
│   └── ...                       ← 12+ legacy-документов
└── secrets/                      ← токены (не в git)

Ключевые детали реализации

• Multi-worker safety: все общие данные в /tmp/ под fcntl.flock
• CREATE vs non-CREATE: раздельные потоки в бэкенде и фронтенде
• Текущие значения параметров: GET /instances/{uid} → state.params + GET /instanceOperations/default/{opId} → слияние
• Логирование: /tmp/app-autotest.log + /api/log + скрытая UI-панель
• Валидация: HTML-escape + JSON-валидация map-полей (onblur + pre-submit)

---

2. Что нужно проанализировать

A. Decoupling и модульность

Сейчас всё в одном HTML и одном api_test.py (300+ строк). Нужны рекомендации:

• Как разбить index.html на компоненты/модули?
• Как разбить api_test.py на независимые модули по операциям?
• Стоит ли переходить на микро-фронтенд (HTMX, Alpine.js, что-то ещё) или оставить ванильный JS?
• Как организовать роутинг если добавится больше страниц?

B. Хранение данных тестов

Сейчас никакие результаты тестов не сохраняются. Нужно:

• Где и как хранить историю запусков (каждый запуск = запись)?
• Какие данные сохранять: параметры, длительность, статус, этапы, ошибки?
• Формат хранения: SQLite? JSON-файлы? Внешняя БД?
• Как привязать к конкретному инстансу и пользователю?
• Нужна ли страница истории/отчётов?

C. Оптимизация для развития

• Что мешает добавить второй сервис (сейчас только Болванка, svcId=1)?
• Как сделать конфигурацию сервисов (какие сервисы показывать, какие операции)?
• Нужен ли config.yaml или всё из API?
• Как масштабировать на множество пользователей (изоляция данных)?

D. Улучшения архитектуры

• Сейчас _client() определяется в двух местах (main.py и api_test.py) — как унифицировать?
• Стоит ли вынести общие хелперы (_client_id, _stand, _token_info) в отдельный модуль?
• Нужен ли middleware для токена (вместо ручного извлечения в каждом роуте)?
• Как улучшить обработку ошибок (сейчас много try/except с голым str(e))?

E. Безопасность

• Токен передаётся в cookie и форме — достаточно ли этого?
• Нужна ли CSRF-защита для POST-запросов?
• Логи могут содержать чувствительные данные?

---

3. Ожидаемый формат ответа

1. Общая оценка

• Что сделано хорошо
• Что требует внимания
• Критические проблемы (если есть)

2. Decoupling — план

• Пошаговый план разбиения на модули
• Рекомендации по фронтенду (ванильный JS / HTMX / Alpine / SPA)
• Рекомендации по бэкенду (структура модулей)

3. Хранение данных тестов — план

• Схема данных (какие поля, какие таблицы/файлы)
• Технология (SQLite / PostgreSQL / JSON-файлы)
• API для чтения/записи
• UI для просмотра истории

4. Оптимизация — конкретные шаги

• Приоритизированный список улучшений
• Что можно сделать быстро, что требует переписывания

5. Риски и ограничения

• Что может пойти не так при предлагаемых изменениях
• Ограничения платформы (gunicorn, /tmp/, DDoS-Guard)

---

4. Файлы для изучения

Код (в порядке важности):

1. site/routes/api_test.py — основной модуль операций
2. site/templates/index.html — весь фронтенд
3. site/routes/main.py — главная страница и API операций
4. site/api/http_client.py — HTTP-клиент и автостенд
5. site/operations/get_params.py — слияние параметров
6. site/operations/tracker.py — файловый трекер
7. site/app.py — точка входа
8. site/operations/get_services.py + get_instances.py — API-обёртки

Документация:

1. DOCS/ARCHITECTURE.md — актуальная архитектура
2. DOCS/HISTORY.md — история версий
3. DOCS/terraform-operations-full-logic.md — логика API из Terraform-провайдера

Данные (HAR-файлы):

1. development/dummycreate.har — полный flow CREATE
2. development/dummymodify.har — полный flow MODIFY