diff --git a/HISTORY/2026-07-31-session.md b/HISTORY/2026-07-31-session.md
index e5e47bb..c05d265 100644
--- a/HISTORY/2026-07-31-session.md
+++ b/HISTORY/2026-07-31-session.md
@@ -128,9 +128,14 @@
 - ✅ output/instance_ref с облачными инстансами
 - ✅ Кнопки CRUD крупнее, справка «📖 Как заполнять»
 
-**Фаза 5 — редактор параметров (план от Опус, НЕ РЕАЛИЗОВАНО):**
-- Заменить ручной key=value на автоподгрузку через params-render.js
-- Параметры в свёрнутом `<details>` внутри карточки шага
-- Хранение: символические имена в БД, обратный маппинг numeric→name при сохранении
-- Снапшот параметров перед ре-рендером (защита от потери правок)
-- 3 развилки решены: без ссылок на output в параметрах, всегда шаблон, полный сброс при смене операции
+### v1.2.16 — instance_meta JSONB
+После каждого прогона сохраняется полная информация об инстансе (GET /instances/{uid}).
+Все поля кроме instanceUid/displayName/svc/serviceId/explainedStatus.
+
+## Идеи на будущее (НЕ ДЕЛАТЬ, обдумать)
+
+**Context snapshot:** сохранять снапшот ВСЕХ инстансов пользователя на момент запуска
+(instanceUid, displayName, serviceId, svc, explainedStatus, specification).
+При анализе FAIL — видеть контекст: «было 3 running Болванки, возможно конфликт ресурсов».
+Хранить в `runs.context_snapshot JSONB` и `scenario_runs.context_snapshot JSONB`.
+Данные обезличенные, не гигабайты. Отложено до реальной необходимости.
diff --git a/TASKS/OpusAboutLLM.md b/TASKS/OpusAboutLLM.md
new file mode 100644
index 0000000..abbb82d
--- /dev/null
+++ b/TASKS/OpusAboutLLM.md
@@ -0,0 +1,33 @@
+есть облачный ЛЛМ 120В
+КРАТКО - где его можно использовать в данном проекте ? и как и зачем
+
+Список задач обновлен
+
+Кратко — где 120B-LLM реально полезна в autotest (по убыванию ценности):
+
+**1. Разбор упавших прогонов (лучшее применение).**
+Где: История/панель прогона, где есть `error_log` + `stages`.
+Как: отправить error_log + этапы → LLM возвращает «причина + что проверить».
+Зачем: тестировщик не читает сырые терраформ/API-логи вручную — экономит время на триаже.
+
+**2. Генерация сценариев из текста.**
+Где: редактор сценариев (`scenario-*.js`, `/api/scenario/definitions`).
+Как: «создай vDC → VM → удали» → LLM генерит `steps[]` JSON по схеме (service_id, operation, output/instance_ref).
+Зачем: собрать цепочку автотеста словами вместо ручного JSON.
+
+**3. Подсказка значений параметров.**
+Где: форма параметров (params-render.js / operations).
+Как: схема параметров (name, dataType, isRequired, valueList) → LLM предлагает разумные дефолты.
+Зачем: меньше проб-ошибок при заполнении обязательных полей.
+
+**4. Анализ трендов по истории.**
+Где: таблица `runs` / история.
+Как: агрегат прогонов → LLM: «операция X падает в 40% на стенде test, обычно на этапе Y».
+Зачем: находить флаки и системные проблемы, а не единичные падения.
+
+**5. Триаж HAR** (`development/*.har`).
+Как: HAR → LLM извлекает последовательность API-вызовов/параметры для нового сценария.
+Зачем: реверс реальных операций Nubes в автотест.
+
+Архитектурно: отдельный бэкенд-эндпоинт (напр. `/api/llm/analyze`), который дёргает облачный 120B; фронт вызывает по кнопке «Разобрать ошибку»/«Сгенерировать». **Ничего не меняю — это ответ; скажешь «делай», добавлю в план как отдельную фазу.**
+