# ⚠️ LEGACY — НЕАКТУАЛЬНО. Исторический документ.

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

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

Файл: `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. **Что ещё важного мы упустили?** — как человек который видит картину целиком.