Подбор исполнителя: требования к дальнейшей реализации

Назначение: Требования. Продукт: 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.

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

Обязательные решения до реализации

Вопрос	Что необходимо определить
Предмет выбора	Предложение исполнителя, связанный ресурс, компания и область услуги; отличать Provider от учётной записи человека.
Жёсткие ограничения	Требования заказа, полномочия, совместимость ресурса, место, временное окно и отсутствие недопустимых пересечений. У каждого ограничения — источник данных и проверка.
Предпочтение клиента	Это обязательный выбор конкретного человека или пожелание среди допустимых кандидатов? Можно ли предлагать альтернативу и какое согласие требуется?
Готовность	Когда получены сведения, до какого момента им можно доверять и какое подтверждение нужно при назначении? Неизвестное не считать свободным.
Время	Плановое/срочное обращение, длительность, подготовка, дорога, часовой пояс, интервалы занятости и запас. Не смешивать оценку прибытия с фактом готовности.
Ранжирование	Какие критерии действуют после обязательных проверок, кто устанавливает их приоритет и как объяснить результат без раскрытия чужих персональных данных?
Резервирование	Что именно и на какой срок удерживается; кто снимает резерв; что происходит при двух одновременных согласиях и истечении времени ответа?
Отказ и отсутствие ответа	Сроки, продолжение поиска, исчерпание кандидатов, передача ответственному и информация клиенту.

Целевой порядок обработки

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

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

Изменение заказа и внешние действия

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

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

Наблюдаемость и данные решения

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

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

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

Критерии приёмки будущего изменения

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

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

Требования к нейросети и передаче человеку

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

Содержание