autotest/DOCS/sonnet-review-prompt.md

Запрос к Соннету: анализ плана истории тестов

Что анализировать

Файл: DOCS/test-results-history-plan.md — полный план реализации истории/результатов тестов.

Что НЕ трогать

⚠️ Только анализ, никаких изменений кода. Мы сами будем реализовывать.

Файлы для контекста (если нужно понять как устроено приложение)

Файл	Зачем
app-autotest/site/app.py	Точка входа, структура Flask, версия
app-autotest/site/routes/api_test.py	API тестов: /api/test, /api/test/status/<opUid>, /api/operations/<svcId>
app-autotest/site/routes/main.py	Главная страница, /api/operations/<svcId>
app-autotest/site/operations/tracker.py	Трекер инстансов (/tmp/instances.json)
app-autotest/site/operations/get_instances.py	Пагинированный запрос инстансов
app-autotest/site/api/http_client.py	HTTP-клиент облака
app-autotest/site/templates/index.html	Весь UI в одном файле
DOCS/api-operation-stages.md	Как работают stages в API
DOCS/terraform-operations-full-logic.md	Полная логика операций из Terraform

Вопросы

1. SQLite в /tmp/ — на поде k8s это надёжно для тестовой истории? Или лучше PostgreSQL-сервис Nubes? Учтти что при редеплое /tmp/ НЕ затирается (в отличие от site/).

2. Схема БД — три таблицы (test_runs, test_stages, test_params) — нормально? Что-то упущено?

3. stageMsg — стоит ли хранить большие JSON-строки с логами Jenkins? Они могут быть по несколько килобайт.

4. API эндпоинты — GET /api/results, GET /api/results/<id>, DELETE /api/results/<id>, GET /api/results/stats — достаточный набор?

5. UI — текущий UI на серверном рендеринге Jinja2 + ванильный JS. Для истории тестов с фильтрами и раскрытием деталей — оставить такой же подход или переходить на что-то другое?

6. Экспорт — JSON потоком или файлом?

7. Что ещё важного мы упустили? — как человек который видит картину целиком.