Назначение: Справка по компоненту. Продукт: ShariX Open.

Для кого: Разработчик · Интегратор · Рецензент и приёмщик · Нейросеть.

Темы: Заказы → Исполнение · Архитектура → Владение моделями · API → Контракты.

Репозиторий sharix-open-webservice-running устанавливается как webservice_running. Здесь находятся локальные расширения и данные исполнения ShariX Open. Общая запись заказа остаётся в dbsynce. Эта страница описывает открытый модуль; устройство закрытого конструктора и внутренних модулей Platform относится к intrawiki.

Фактический экспорт — models/init.py. Timeline в интерфейсе не следует автоматически считать отдельной Django-моделью: services/order_execution.py получает ленту через services.timeline.get_stage_timeline.

В Orders хранятся общие условия и состояние заказа. Локальное расширение позволяет добавить предметные сведения без помещения каждого специального поля в общее ядро. Связь с заказом сохраняется; его участники, статус и цены не становятся независимой второй версией только потому, что отображаются в локальной карточке.

При изменении сначала называют факт: это новое условие общего заказа или локальная информация? Затем проверяют реальный импорт модели и её миграции. Нельзя выбрать таблицу только по похожему названию или подписи в интерфейсе.

Обе модели экспортируются через models/init.py. OrdersLocal не является псевдонимом OrdersLocalFullTemplate. Имя orders_local в БД тоже не доказывает, какой класс импортирует view.

apiviews/orders_local.py импортирует OrdersLocal. Однако OrdersLocalMVS.get_queryset строит select_related и filter по order_synced, тогда как у этой модели связь называется order. serializer/orders_local.py также использует order_synced.* и объявляет ту же модель OrdersLocal.

По проверенному коду endpoint нельзя считать исправно работающим. Требуются выбор целевой модели, согласование полей view/serializer с её миграциями и проверки чтения/обновления. Простая замена одного имени без проверки сохранённых данных не является подтверждённым исправлением.

Намерение защиты видно отдельно:

• view требует IsAuthenticated;
• разрешены методы GET/HEAD/OPTIONS/PUT/PATCH;
• видимые общие заказы отбираются через get_orders_queryset_for_user;
• serializer явно отклоняет переданные зеркальные поля, включая статус, клиента, исполнителя и цены;
• методы POST и DELETE этим view не разрешены.

Эти меры не исправляют отсутствующую связь и не доказывают успешность всего запроса.

До исправления не расширяют запись зеркальных полей ради обхода ошибки. Изменение общего состояния должно идти через владельца заказа, а не через локальный cache endpoint.

apps.py регистрирует order_execution_runtime_adapter в нейтральном порту backend. Вызов из backend приходит в services/order_execution.py. Инициализация требует связанного Ticket; при существующем OrderExecution возвращает его workspace и признак idempotent, не создавая тот же workspace заново. Этот локальный признак не означает идемпотентность POST создания самого заказа.

Если политика исполнения не настроена, результат инициализации содержит:

• configured=false;
• initialized=false;
• stage_count=0.

При настроенном исполнении сохраняется OrderExecution со снимком политики и создаются Stage в пределах её правил. Из этого не следует, что любой заказ всегда должен иметь одинаковые этапы.

Публичный runtime может читать допустимый результат настройки через интеграционную границу. Внутренние модели закрытого источника настройки на этой странице не описываются. Лицензия проверенного webservice_running — GNU GPL v3; лицензия подключаемого компонента проверяется отдельно.

1. Найти маршрут, view, импортированную модель и serializer. Проверить, какой ID ожидает операция: общего заказа или локальной записи.
2. Определить локальные поля и поля общего владельца. Для последних использовать каноническую операцию заказа.
3. Прочитать существующие данные и историю миграций до переименования связи или смены модели.
4. Для исполнения проверить настроенный runtime, созданный workspace, права на этап и видимость материалов.
5. На предназначенной для этого установке проверить допустимое действие, отказ с чужим заказом и отказ при попытке изменить зеркальное поле.

Отдельно оценивают:

• проверку импорта;
• работающий HTML-список;
• успешный API-запрос.

Это разные результаты. Если изменён общий модуль, публикацию и проверку другим продуктом передают его ответственному по порядку shared-изменений.

• Заказ, Ticket и PROCESS.
• Этапы исполнения.
• Материалы и версии.
• Обработчики и Blockly.

Проверены опубликованные исходники указанных commits. Это анализ кода, а не подтверждение версии, данных или выполненного запроса на сервере.

• sharix-open-backend: lib/order_permissions.py.
• sharix-open-backend: lib/integration_ports.py.
• sharix-open-webservice-running: LICENSE.
• sharix-open-webservice-running: models/__init__.py.
• sharix-open-webservice-running: models/webservice_running.py.
• sharix-open-webservice-running: models/local_examples.py.
• sharix-open-webservice-running: apiviews/orders_local.py.
• sharix-open-webservice-running: models/execution.py.
• sharix-open-webservice-running: models/execution_extensions.py.
• sharix-open-webservice-running: serializer/orders_local.py.
• sharix-open-webservice-running: services/order_execution.py.
• sharix-open-webservice-running: apps.py.