Передача обращения исполнителю
Карточка CASE-01 находится в triaged: Ольга определила предмет и кандидата исполнителя, но Максим ещё не принял задачу. Передача обращения должна сохранять контекст и ответственность. В этом уроке подготовим HANDOFF-01, где предложение, принятие и возврат являются разными действиями. Результат — понятная карточка передачи, которую нельзя принять за отправленное уведомление.
Все участники и события синтетические. Папка lesson-13 архива серии содержит локальный пакет. Письма, сообщения и операции CRM не выполняются. Подписка R001 остаётся остановленной; работа с его учебным вопросом не возобновляет lesson_updates.
Контекст для исполнителя
Максиму нужны предмет, исходные условия, уже известные данные и ожидаемый результат. Карточка говорит: «Читатель не понимает, какое правило задаёт итоговый адрес после назначения пути». Известно различие исходника и URL, неизвестен конкретный сборщик. Ожидаемый вклад рецензента — определить необходимое уточнение и объяснить границы. Он не получает обязанность подключаться к чужому серверу или исправить весь проект.
Передача включает ссылку на BR-04 и обезличенный пересказ вопроса. Полная история подписки не нужна. Данные чувствительного характера отсутствуют. Если в рабочем обращении они присутствуют, пакет должен использовать минимальную пригодную часть и ограничить доступ. Наша учебная схема не реализует права CRM, поэтому нельзя считать открытый Markdown защищённым внутренним хранилищем.
| Поле | Значение модели | Причина |
|---|---|---|
| Предмет | Источник итогового пути | Локализовать работу |
| Известно | Путь назначен явно | Не повторять первый вопрос |
| Неизвестно | Правило среды | Не выдавать диагноз |
| Результат | Уточнение и граница ответа | Проверить завершение |
| Владелец до принятия | Ольга | Ответственность не потеряна |
Срок передаваемого шага обозначим как плановый: подготовить предметное уточнение в следующем доступном блоке рецензии. Это не обещание человеку реального времени ответа. Если нужен точный срок, он согласуется с календарём и ёмкостью. Кандидат может не иметь ресурса, поэтому назначение по имени без принятия не завершает передачу.
Предложение и принятие
У HANDOFF-01 исходная версия карточки 1. Ольга предлагает передачу Максиму с ожидаемым результатом и плановым окном. Пока статус offered, владельцем остаётся Ольга. В синтетической ветке Максим принимает актуальную версию, после чего CASE-01 становится assigned и получает владельца Максима. Это описание ожидаемого перехода, не реальный ответ человека.
Если Максим возвращает задачу, причина записывается: недостаточно предметных данных или нет доступного блока. Возврат не означает resolved. Ольга уточняет пакет либо пересматривает кандидата и срок. Такая модель предотвращает ситуацию, когда обращение исчезает между колонками, а каждый участник считает его переданным. Явный владелец сохраняется до принятого перехода.
Версия нужна для защиты смысла. Если после предложения Ольга добавила новую задачу, старое принятие не должно автоматически распространяться на другой объём. В модели исполнитель подтверждает конкретный пакет. При будущем программном хранении понадобится проверка актуальной версии и прав операции. Сейчас техническая реализация отсутствует, поэтому мы показываем условие, а не проверенный механизм конкурентного обновления.
Рассмотрим повтор принятия. Если версия и участник совпадают, смысл остаётся прежним: задача уже назначена. Нельзя создавать второе обращение или отправлять повторные уведомления по каждому дублирующему событию. В учебном документе у передачи есть устойчивый ID. Но техническая единственность уведомлений будет зависеть от будущего сервиса и отдельной модели, а не от наличия красивого номера.
Следующее действие после передачи
Максим готовит уточнение: «Какое правило среды выбирает итоговый путь и из какого состояния взята готовая страница?» Оно связано с неизвестными данными CASE-01. После редакционного согласования карточка может стать waiting_reader. Однако в этой главе сохраняем assigned: уточнение только подготовлено локально. Не отмечаем, что человек получил его, потому что внешнего ответа не было.
Уточнение должно быть достаточным, но небольшим. Просьба прислать весь репозиторий и доступ к хостингу выходит за цель. Для первого шага нужен инструмент, правило и наблюдение. Если данных всё ещё недостаточно, можно пояснить почему, вместо бесконечного запроса всех сведений. Предметная модель помогает удержать границу поддержки и не собирать лишнее.
Передача также показывает запрет смешения целей. Рецензент видит, что lesson_updates остановлена. Он может подготовить ответ по обращению в рамках отдельного процесса, но не добавлять контакт обратно в web-сегмент. Если полезный материал уже опубликован, ссылка в ответе должна объяснять конкретный вопрос. Она не превращает сервисное сообщение в новый рекламный выпуск автоматически.
Когда в будущем обращение решено, исполнитель передаёт результат с основанием, а редактор принимает завершение. Фраза «разобрался» без описания механизма недостаточна. Для CASE-01 результатом могло бы быть условие выбранного сборщика или объяснение происхождения старого состояния. Пока эти данные неизвестны, завершение не фиксируется. Это честная граница локального примера.
Журнал передачи
В artifact.md находятся предложение, ожидаемое принятие и подготовленное уточнение. У каждого шага есть сценарное происхождение. Поле notification_sent ложное; внешних ID нет. after.json добавляет HANDOFF-01 и ожидаемое assigned, сохраняя предыдущий triaged как историю. Это последовательность решений, а не миграция действующей базы.
Проверьте вариант, где карточка изменена до принятия. Максим принимает старую версию 1, а актуальная уже 2. Правильное ожидаемое решение — пересогласовать передачу, не считать новый объём принятым. Владелец остаётся определённым. Если система просто ставит имя без проверки, возможен спор о том, какую работу человек согласился выполнить.
Другой вариант: два исполнителя одновременно принимают предложение. Предметный процесс допускает одного текущего владельца и дополнительного рецензента с отдельной ролью. Будущая реализация должна сохранить это правило, но данная глава не содержит SQL, блокировок или выполненных проверок гонки. В документах достаточно назвать допустимый результат и недопустимое двойное владение.
Так HANDOFF-01 завершает передачу контекста, сохраняя цель обращения, неизвестные данные и ответственность. Следующая глава применит похожую явность к автоматическим сообщениям: событие, условия, повтор и остановка должны быть описаны до подключения планировщика или почтового сервиса.