# Как развивать webrtc-komaroff Проверенный исходник — `772de4a`, дата 16.09.2026. Ни одно предложение ниже не реализовано в приложении. [Архитектура]() описывает текущий код, [evidence ledger]() отделяет наблюдение от вывода. ## Оценка выбранного подхода Разделение медиасоединений, распознавания, модели и состояния разговора соответствует разным типам нагрузки. В пользу сохранения этих границ говорят разные жизненные циклы: peer connection живёт в Core, GPU принадлежит внешнему владельцу, диалог переживает запрос в Postgres. Слабее обоснован разрез между Agent и workflow: они вместе завершают один turn и передают полный runtime туда и обратно. Три workflow реализации полезны как экспериментальная площадка. Как постоянный продуктовый контур они требуют parity и увеличивают объём сопровождения. Пока не доказано, что два движка не имеют consumers, называть их мёртвым кодом преждевременно. Каталоги `src_*` корректны и к legacy-проблеме не относятся. ## Варианты по возрастанию вмешательства | Изменение | Проверяемый эффект | Цена и условие | |---|---|---| | [01. Карта: переиспользовать HTTP-соединения и убрать последовательное ожидание]() | 2 последовательных GET → параллельные запросы или один общий; session на время жизни приложения | Низкая | | [02. Сценарии: тратить модель на неоднозначность, а не на готовые координаты]() | 2 → 1 LLM call; 0 для явной команды UI | Низкая → средняя | | [03. Потоки и LLM: ограничить очередь до создания задач]() | Предел pending bytes/tasks; общая отмена и deadline | Средняя | | [04. Один turn: один результат, атомарная запись и безопасные реплики]() | Одна логическая фиксация turn при retries и replicas | Средняя | | [05. Сократить legacy через выбор одного workflow runtime]() | 3 → 1 поддерживаемый production runtime после проверки эквивалентности | Средняя | | [06. Выдать браузеру поток его сессии и восстанавливаемый результат]() | 0 чужих событий; восстановление terminal result | Средняя → высокая | | [07. Объединить Agent и выбранный workflow в один сервис диалога]() | Минус один request/reply boundary и один orchestration process | Высокая | | [08. Полная замена orchestration: сохранённые задания и возобновляемые шаги]() | Сохранность принятых jobs и recovery по crash matrix | Очень высокая; условный вариант | Номер отражает вмешательство, а не срочность. Сначала я бы закрыл **04** и **03**, поскольку они влияют на корректность при нагрузке и отказах. **01** можно сделать отдельно. Затем — **02**, корпус совместимости для **05** и решение по identity в **06**. **07** стоит проверить прототипом. **08** нужен только при доказанных требованиях к recovery. ## Общая база измерений До сравнения записать commit, модель и её параметры, dataset revision, cold/warm режим, replicas и limits. Использовать одинаковые текстовые/audio inputs; реальные персональные данные в fixtures не переносить. Для задержек фиксировать минимум p50/p95, размер выборки и долю ошибок. Нагрузку задавать ступенями, а не увеличивать replicas без ограничений. Разложить время turn на ingress, ожидание очереди, state read, routing, params, tool, LLM, commit и UI delivery. `trace_id` в JSON полезен для корреляции, но не подтверждает сквозную передачу W3C trace context. [OpenTelemetry traces]() описывает parent/child spans; здесь это основа плана измерений, не заявление о уже работающем trace. Нельзя обещать процент ускорения без baseline. Структурные результаты — количество calls, процессов и bounded capacity — проверяются отдельно от latency, качества ответа и стоимости. ## Актуальные внешние материалы Через Context7 16.09.2026 получены NATS queue groups/JetStream, aiohttp pooling, PostgreSQL transactions и LangGraph persistence/idempotency. Дополнительно сверены официальные страницы. [Запросы, версии и границы применимости]() сохранены рядом. Эти материалы обосновывают свойства механизмов; выбор новой границы сервиса остаётся инженерным предложением по этому репозиторию.