# Запрос к 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