2026-07-31 — Сессия (v1.1.57 → ...)

Контекст

Обсуждение архитектуры: унификация ручного и сценарного режимов, гибкие ссылки на инстансы, новый UI редактора сценариев.

Agent consultations

Промпт для Opus

Составлен DOCS/opus-architecture-prompt.md — полное описание проекта, дублирование CREATE-флоу, ограничение instance_map, вопросы по архитектуре.

Ответ Opus — 19 уточняющих вопросов

A. Единый executor (operations/executor.py)

Граница ответственности: executor делает всё до /run, поллинг — снаружи?
Обработка ошибок: исключения с типом или dict {ok, error, failed_step}?
Трекер: вызывать tracker_add внутри executor для create? Нужны ли сценарные инстансы в трекере?
_finish_op: остаётся в api_test.py или выносим в общий модуль поллинга?

B. Гибкие ссылки на инстансы 5. Приоритет резолвинга: instance_uid > instance_ref > (для create — новый) 6. Где хранить output→uid: в памяти (instance_map) или в scenario_runs.instance_bindings? 7. Валидация _validate_steps: проверять ссылки на output, уникальность, обязательность 8. Обратная совместимость: поддерживать старый формат (service_id) или мигрировать?

C. Схема БД 9. Формат в steps JSONB без изменений схемы? (подтверждено) 10. Использовать существующую колонку scenario_runs.instance_bindings?

D. UI редактора 11. Модал vs inline — рекомендация: модал на весь экран 12. Переиспользовать renderParamRow из operations.js в общем модуле? 13. Pre-fill параметров: авто или по кнопке? 14. Формат параметров: символические имена в БД (как сейчас) или иное?

E. Оптимизация 15. Вынести _find_uid/_uid_from_location в общий utils 16. Механизм восстановления зависших scenario_runs? 17. Ограничение lock_check: только один RUNNING сценарий — осознанное? 18. _op_results в памяти → мигрировать в БД/Redis? 19. Приоритет: бэкенд или UI редактора в первую очередь?

Ключевые решения (отвечено DeepSeek)

A. Executor:

A1. Граница: до /run включительно, без поллинга. Возвращает {instance_uid, op_uid, display_name}
A2. Ошибки: dict {ok, error, failed_step}, не исключения
A3. Трекер: да, tracker_add внутри executor для всех create
A4. _finish_op: оставить в api_test.py, цикл поллинга → operations/poll.py

B. Ссылки:

B5. Приоритет: instance_uid > instance_ref > новый create
B6. Хранение: память + scenario_runs.instance_bindings
B7. Валидация: проверять ссылки, уникальность, обязательность
B8. Совместимость: оба формата, без миграции, fallback на service_id

C. БД:

C9. Без изменений схемы
C10. Использовать instance_bindings

D. UI:

D11. Модал на весь экран
D12. Общий модуль params-render.js
D13. Авто pre-fill, все параметры с defaults
D14. Символические имена в БД

E. Оптимизация:

E15. _find_uid → api/utils.py
E16. Startup check: TIMEOUT для зависших >1ч
E17. lock_check оставить
E18. _op_results не в scope
E19. Порядок: executor → формат → api_test/scenario → UI

4.2 KiB Raw Blame History