DOCS+HISTORY: Opus architecture prompt, Q&A, implementation plan, session logs

DOCS/opus-questions-2026-07-31.md

@@ -0,0 +1,61 @@
+# Opus Questions + Answers — 2026-07-31
+
+## A. Единый executor (operations/executor.py)
+
+**A1. Граница executor: до /run включительно, без поллинга.**
+Executor делает все шаги: POST /instances → POST /instanceOperations → send_params_terraform → /run. Возвращает `{instance_uid, op_uid, display_name}`. Поллинг — забота вызывающего (api_test.py: async thread, scenario.py: sync while).
+
+**A2. Ошибки: dict `{ok, error, failed_step}`.**
+Не исключения. `failed_step` = "instances" | "instanceOperations" | "params" | "run". Оба вызывающих конвертируют в свой формат (jsonify / RuntimeError).
+
+**A3. Трекер: да, вызывать tracker_add внутри executor для всех create.**
+Сценарные инстансы — такие же реальные инстансы в облаке, должны быть в трекере. Единообразие.
+
+**A4. _finish_op: оставить в api_test.py.**
+Но вынести цикл поллинга в общий хелпер `poll_until_done(client, op_uid, timeout=1800)` в `operations/poll.py`, который используют и _finish_op (async), и run_scenario (sync).
+
+## B. Гибкие ссылки на инстансы
+
+**B5. Приоритет: да. instance_uid > instance_ref > новый create.**
+
+**B6. Хранение output→uid: и в памяти, и в БД.**
+В памяти — словарь для быстрого резолвинга во время выполнения. В БД — `scenario_runs.instance_bindings` обновляется после каждого create-шага. При падении воркера видно что создалось. Но runner не зависит от БД для резолвинга (только память).
+
+**B7. Валидация: да на всё.**
+`_validate_steps()` проверяет: (a) instance_ref ссылается на output из предыдущих шагов, (b) output уникален в пределах сценария, (c) для не-create шага обязателен один из instance_ref/instance_uid.
+
+**B8. Обратная совместимость: поддерживать оба формата, без миграции.**
+Если шаг без output/instance_ref/instance_uid → fallback на старый instance_map[service_id]. Seed dummy_test работает как есть. Новые сценарии используют новый формат.
+
+## C. Схема БД
+
+**C9. Да, без изменений схемы.** Только новые опциональные ключи в JSONB-объектах шагов.
+
+**C10. Да, использовать instance_bindings.** После create: `bindings[output_name] = instance_uid`. Сохранять в БД после каждого шага.
+
+## D. UI редактора сценариев
+
+**D11. Модальное окно на весь экран.** Параметры с dataDescriptor (map-fixed) — много вложенных полей, inline в scenario-body слишком тесно.
+
+**D12. Да, вынести рендер параметров в общий модуль.**
+`static/js/params-render.js`: `renderParamRow()`, `renderMapFixedRow()`, `collectParams()`. Используется и в operations.js, и в scenario-form.js.
+
+**D13. Pre-fill: авто при смене операции.** Показывать ВСЕ параметры с defaults, пользователь удаляет лишние или меняет значения. Кнопка «Сбросить на defaults».
+
+**D14. Символические имена в БД.** `{"durationMs": "5000"}` — человекочитаемо, стабильно. Резолвинг в numeric ID — в runtime.
+
+## E. Оптимизация
+
+**E15. Да, вынести в `api/utils.py`.** Обе реализации (_find_uid, _uid_from_location) унифицировать.
+
+**E16. Да, startup check.** При старте: `UPDATE scenario_runs SET status='TIMEOUT', error_log='worker restart' WHERE status='RUNNING' AND created_at < NOW() - INTERVAL '1 hour'`. Просто, без доп. инфраструктуры.
+
+**E17. Оставить lock_check.** Один сценарий за раз — безопасно. Можно ослабить позже.
+
+**E18. Не в scope.** fallback на API работает, потеря stages — minor. Отдельная задача.
+
+**E19. Порядок: бэкенд → UI.**
+1. `operations/executor.py` + `operations/poll.py` + `api/utils.py`
+2. Формат шагов (output/instance_ref) + валидация + резолвинг
+3. Минимальные правки api_test.py и scenario.py (вызов executor)
+4. UI редактор (модал + общий рендер параметров)