Назначение: Требования. Продукт: ShariX Open.

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

Темы: Заказы → Назначение · Сервис → Настройка · API → Контракты.

Навигация: Доменная модель → Подбор исполнителя.

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

Сервис должен найти предложение исполнителя, соответствующее обязательным условиям конкретного заказа и доступное к требуемому времени. Среди допустимых предложений учитываются согласованные предпочтения и приоритеты. Найденный кандидат, отправленное приглашение, согласие человека и подтверждённое назначение — разные результаты.

Ресурс и труд не заменяют друг друга: наличие автомобиля не подтверждает готовность водителя; свободное время человека не подтверждает пригодность инструмента. Сначала определяется, что именно требуется для исполнения, затем способ проверки этих условий.

Срез исходников от 31.10.2026:

• dbsynce/lib/order_matching.py отбирает активные предложения услуги, ограничивает компанию при соответствующем заказе, исключает обнаруженные конфликты, вызывает проверки пригодности и доступности.
• Кандидаты сортируются через provider_matching_priority. Дубли предложений одного XMPP JID устраняются перед ограничением партии.
• services/provider_availability.py различает online, offline и gap; ожидание gap связано с отметкой обновления доступности. В коде есть разные ветви планового и ASAP-заказа.
• PENDING-обработчик использует партии кандидатов и раунды. Его кэш, курсор и повторные проверки имеют ограничения, описанные в текущем сценарии PENDING.

Этот набор не является доказательством корректного полного подбора: необходимо отдельно подтвердить полноту ограничений, смысл предпочтений, актуальность сведений, резервирование и конкурентные ответы. Географическое расстояние само по себе не подтверждает достижимое время прибытия. Получение партии не резервирует кандидатов. Стабильная сортировка не доказывает справедливость правила или согласие участника.

1. Зафиксировать проверяемую редакцию заказа: условия, время, участников и требования.
2. Сформировать кандидатов в разрешённой области услуги и компании.
3. Отделить отклонение по обязательному условию от отсутствия сведений. Неизвестность сохранять как причину дополнительной проверки.
4. Проверить совместную доступность человека и ресурса на весь необходимый интервал, включая подготовку и перемещение там, где они нужны.
5. Применить подтверждённое правило предпочтений и ранжирования к допустимым кандидатам.
6. Отправить предложение с понятными условиями, сроком ответа и связью с данной попыткой подбора. Факт отправки не считать согласием.
7. При согласии повторно проверить актуальность заказа и возможность назначения; подтвердить назначение канонической операцией с защитой от конфликта.
8. Освободить проигравшие или просроченные резервы, завершить соответствующие ожидания и сообщить участникам подтверждённый результат.

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

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

Если нужен внешний источник ранжирования, использовать явный публичный контракт: применимость, версия, срок ответа, причины недоступности и допустимость локального продолжения. Внутренние алгоритмы закрытых модулей не входят в эту публичную страницу. Ни недоступность источника, ни пустой ответ не должны молча расширять условия заказа.

Для дальнейшего проектирования требуется определить:

• идентификаторы заказа, его редакции и попытки подбора;
• момент и источник проверки доступности;
• причины исключения или дополнительной проверки кандидата;
• применённую версию правил и объяснимые факторы ранжирования;
• приглашение, срок ответа, ответ и результат попытки назначения;
• владельца и время действия резерва, если он вводится;
• основание ручного решения и ответственного.

Это перечень требуемых сведений, а не объявление существующих полей API. В журналах не хранить лишние контакты, секреты и переписку; доступ к причинам и подробностям ограничивать ролью.

• Предпочитаемый исполнитель не проходит обязательное условие: его не назначают в обход ограничения; вариант продолжения объяснён.
• Кандидат свободен сейчас, но не может быть готов к сроку: текущая доступность не превращается в обещание прибытия.
• Два заказа претендуют на одну неделимую мощность: не возникает двойного подтверждённого назначения.
• Клиент изменил существенные условия во время ожидания: старое согласие обрабатывается по явному правилу редакций.
• Кандидат не ответил, отказался, ответил поздно или повторно: предусмотрен один согласованный исход без вечного резерва.
• Процесс перезапущен или ответ сети потерян: состояние сверяется; прежние приглашения и назначения не дублируются без основания.
• Кандидатов нет: клиенту не показывают ложное подтверждение; определены дальнейшее действие и ответственный.

Проверять данные, алгоритм и реальные взаимодействия отдельно. Для общих модулей соблюдать процесс разработки, передачу изменений ответственным и конкурентные операции. Алгоритм обработчика должен оставаться согласованным с канонической Blockly-моделью и сгенерированным Python.

Нельзя объявлять задачу завершённой по наличию функции matching или зелёному тесту одного фильтра. Передать матрицу требований и подтверждений, состав изменённых контрактов, проверки конфликтов/ожиданий и точные ограничения. Неподтверждённые части назвать явно. Эта страница задаёт ориентир дальнейшей разработки, а не разрешение самостоятельно внедрить его.