Files
autotest/DOCS/sonnet-review-prompt.md
T

40 lines
2.7 KiB
Markdown

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