v1.0.89: Sonnet review prompt — architecture audit request

2026-07-27 22:08:24 +04:00
parent 1cc3f6eb7e
commit 437aa7a1d1
1 changed files with 144 additions and 0 deletions
@@ -0,0 +1,144 @@
+# Запрос к 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