<sharix-knowledge-meta>
{
    "id": "ShariXKnowledgeProviderSelectionTarget",
    "page": "sharixopen:knowledge:domain:provider_selection_target",
    "area": "open",
    "type": "requirement",
    "title": "Подбор исполнителя: требования к дальнейшей реализации",
    "status": "review",
    "schema_version": 1,
    "relations": {
        "related_to": [
            "ShariXKnowledgeServiceRequestPendingBPMN",
            "ShariXKnowledgeOpenKnowledgeDomainOrderconcurrency"
        ],
        "depends_on": [
            "ShariXKnowledgeOpenKnowledgeModulesBackenddbsynce"
        ],
        "verified_by": [
            "ShariXKnowledgeVerification"
        ]
    },
    "extensions": {
        "taxonomy": {
            "domain": "orders",
            "lifecycle": "not_applicable",
            "component": "dbsynce, handlers_backend, handlers_examples",
            "parents": [
                "ShariXKnowledgeOpenKnowledgeDomainStart"
            ],
            "terms": [
                "product_sharix_open",
                "audience_developer",
                "audience_integrator",
                "audience_reviewer",
                "audience_service_owner",
                "audience_ai",
                "material_requirement",
                "topic_orders_assignment",
                "topic_service_configuration",
                "topic_api_contracts"
            ]
        },
        "classification": {
            "schema": "sharix.knowledge.classification.v1",
            "products": [
                "sharix_open"
            ],
            "audiences": [
                "developer",
                "integrator",
                "reviewer",
                "service_owner",
                "ai"
            ],
            "material": "requirement",
            "topics": [
                "orders/assignment",
                "service/configuration",
                "api/contracts"
            ],
            "tag_terms": [
                "product_sharix_open",
                "audience_developer",
                "audience_integrator",
                "audience_reviewer",
                "audience_service_owner",
                "audience_ai",
                "material_requirement",
                "topic_orders_assignment",
                "topic_service_configuration",
                "topic_api_contracts"
            ],
            "registry_document": "ShariXKnowledgeClassification"
        },
        "source_evidence": [
            {
                "repository": "sharix-open-backend",
                "path": "lib/order_matching.py",
                "commit": "b70f6989f4c8616725b38f72fc15b8981a5dc47b",
                "sha256": "74d09c8d9a9970eceba0b7b2324a8beb0e9e315dbf72ac8139493fafbbd69a6d",
                "url": "https://git.sharix-app.org/ShariX_Open/sharix-open-backend/src/commit/b70f6989f4c8616725b38f72fc15b8981a5dc47b/lib/order_matching.py"
            },
            {
                "repository": "sharix-open-backend",
                "path": "services/provider_availability.py",
                "commit": "b70f6989f4c8616725b38f72fc15b8981a5dc47b",
                "sha256": "933d2a029ebbed4cb4e6b9154bb30a5798f445a0c8d9fe0d5fbd6ea3d1f485c5",
                "url": "https://git.sharix-app.org/ShariX_Open/sharix-open-backend/src/commit/b70f6989f4c8616725b38f72fc15b8981a5dc47b/services/provider_availability.py"
            },
            {
                "repository": "sharix-open-handlers-examples",
                "path": "handlers/open_service_request_pending.py",
                "commit": "76e0c693b628ed4a1fa34515a3f8abdff26149bb",
                "sha256": "8521aac05e4d6b39e7afe7e3fd23e01bf889efc28156f0fc24758bd4c47d1649",
                "url": "https://git.sharix-app.org/ShariX_Open/sharix-open-handlers-examples/src/commit/76e0c693b628ed4a1fa34515a3f8abdff26149bb/handlers/open_service_request_pending.py"
            }
        ],
        "editorial_review": {
            "date": "2026-10-31",
            "state": "future_design_guidance_not_implemented",
            "owner_direction": "Текущий подбор не завершён корректно; политика отмены — ориентир дальнейшей разработки",
            "runtime_checked": false
        }
    },
    "content_sha256": "e70f6a6cdec56209a867b4a012cb4df7cd1f07e90b9d764ee388dee37efb727c",
    "schema": 1
}
</sharix-knowledge-meta>
====== Подбор исполнителя: требования к дальнейшей реализации ======
~~NOCACHE~~

**Назначение:** [[sharixopen:knowledge:classification:materials#trebovanija|Требования]]. **Продукт:** [[sharixopen:knowledge:classification:products#sharix_open|ShariX Open]].

**Для кого:** [[sharixopen:knowledge:classification:audiences#razrabotchik|Разработчик]] · [[sharixopen:knowledge:classification:audiences#integrator|Интегратор]] · [[sharixopen:knowledge:classification:audiences#recenzent_i_prijomschik|Рецензент и приёмщик]] · [[sharixopen:knowledge:classification:audiences#vladelec_servisa|Владелец сервиса]] · [[sharixopen:knowledge:classification:audiences#nejroset|Нейросеть]].

**Темы:** [[sharixopen:knowledge:classification:topics#naznachenie|Заказы → Назначение]] · [[sharixopen:knowledge:classification:topics#nastrojka|Сервис → Настройка]] · [[sharixopen:knowledge:classification:topics#kontrakty|API → Контракты]].


**Навигация:** [[sharixopen:knowledge:domain:start|Доменная модель]] → Подбор исполнителя.

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

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

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

===== Что найдено в исходниках и чего это не доказывает =====
Срез исходников от 31.10.2026:
  * ''dbsynce/lib/order_matching.py'' отбирает активные предложения услуги, ограничивает компанию при соответствующем заказе, исключает обнаруженные конфликты, вызывает проверки пригодности и доступности.
  * Кандидаты сортируются через ''provider_matching_priority''. Дубли предложений одного XMPP JID устраняются перед ограничением партии.
  * ''services/provider_availability.py'' различает ''online'', ''offline'' и ''gap''; ожидание ''gap'' связано с отметкой обновления доступности. В коде есть разные ветви планового и ASAP-заказа.
  * PENDING-обработчик использует партии кандидатов и раунды. Его кэш, курсор и повторные проверки имеют ограничения, описанные в [[sharixopen:knowledge:scenarios:service_request_pending|текущем сценарии PENDING]].

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

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

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

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

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

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

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

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

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

Проверять данные, алгоритм и реальные взаимодействия отдельно. Для общих модулей соблюдать [[sharixopen:knowledge:development:practice|процесс разработки]], [[sharixopen:knowledge:development:shared_change_flow|передачу изменений ответственным]] и [[sharixopen:knowledge:domain:order_concurrency|конкурентные операции]]. Алгоритм обработчика должен оставаться согласованным с канонической Blockly-моделью и сгенерированным Python.

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

~~SHARIX_KNOWLEDGE_RELATED~~