> ## Documentation Index
> Fetch the complete documentation index at: https://docs.quanux.org/symphony/llms.txt
> Use this file to discover all available pages before exploring further.

# Изоляция горячего пути в QuanuX Symphony

> Узнайте, как Symphony удерживает qxctl и плоскость знаний вне путей живого исполнения с помощью дисциплины холодного и «замороженного» пути, дисциплины шин и Prima Parte.

Symphony отделяет административную работу от работы по выполнению, чтобы живая торговля, исследования и другие чувствительные к производительности пути оставались свободными от джиттера, задержек и скрытых зависимостей. qxctl и плоскость знаний относятся к администрированию холодного или «замороженного» пути. Они могут явно воздействовать на Node, на котором также выполняется живая работа, но не должны становиться постоянными зависимостями горячего пути.

## Дисциплина холодного и «замороженного» пути

qxctl и векторные движки — административные компоненты холодного или «замороженного» пути. Они не должны:

* Выполняться в одной линии с горячими или тёплыми путями выполнения
* Разделять блокировки с живыми рабочими нагрузками
* Создавать синхронные зависимости, добавляющие джиттер или задержку
* Становиться скрытыми наблюдателями, резидентными интерпретаторами или незапрошенными фоновыми менеджерами пакетов
* Постоянно присутствовать на Node, выполняющих рабочие нагрузки

Это правило распространяется на координатор сессий знаний, векторные движки и все операции, администрируемые через qxctl. Они формируют свидетельства, проверяют состояние и готовят планы, но не участвуют в пути живого выполнения.

## Дисциплина шин

Тяжёлые передачи данных, управление, исследования и выходной поток выполнения не обязаны использовать одну шину. Топология может использовать несколько шин или обходить шину для объявленного пути, особенно там, где общий трафик может вызвать джиттер. NATS JetStream, ZeroMQ и другие фабрики — это адаптеры и выбор пользователя. Наличие администрирования шин в qxctl не делает прохождение через шину обязательным.

Вы выбираете топологию шин, соответствующую вашим требованиям к задержке и пропускной способности. Symphony поддерживает такую конфигурацию, не навязывая единую общую фабрику.

## Prima Parte

**Prima Parte** — это утверждённая концепция фазы 3, а не существующий исполняемый файл. Это необязательный, предельно лёгкий локальный для Node свидетель состояния на C++, который явно вызывается qxctl после существенной операции. У него нет демона, слушателя, таймера, наблюдателя, цикла опроса или постоянного подключения к шине.

Его ограниченный долговременный словарь включает три термина:

* `current` — текущее наблюдаемое состояние
* `previous` — состояние до существенной операции
* `lastTransmitted` — состояние, отправленное удалённым Node после выполнения соответствующей команды (получение не подтверждено)

Prima Parte фиксирует только свой собственный Node, никогда не становится уменьшенной копией Maestro и завершает работу после выполнения своей ограниченной задачи. Это не рецептор Maestro фазы 1, и исполняемый файл пока не реализован.


## Related topics

- [Документация QuanuX Symphony](https://docs.quanux.org/symphony/ru/index.md)
- [Быстрый старт: знакомство с QuanuX Symphony](https://docs.quanux.org/symphony/ru/quickstart.md)
- [Доктрина платформы QuanuX Symphony](https://docs.quanux.org/symphony/ru/doctrine.md)
- [SACV: управление API-контрактами в QuanuX Symphony](https://docs.quanux.org/symphony/ru/skv/sacv.md)
- [Symphony Quantitative Vector: контракты фреймворка](https://docs.quanux.org/symphony/ru/vectors/sqv.md)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.