Item-режим — задача выдачи + Проверка выдачи + шкафчик

В item-режиме staff физически достаёт предметы из сундука гильдии, пакует их в личный шкафчик каждого участника и подтверждает доставку в AO Master. Эта страница проводит поток пакера сквозным образом: превращение одобренных ригир в задачу выдачи, использование Список выдачи, чтобы знать, что доставать, Проверка выдачи для сверки с chest log и вкладки Recipients для пометки каждого участника доставленным.

Альтернатива — платить silver из Банк silver вместо паковки предметов — см. Silver-режим — выплата. Upstream-шаг одобрения — см. Staff — проверка + одобрение. Оба режима с одного взгляда — см. Обзор процесса ригир.

Права

Поток пакера использует три права, все в Edit Role → Permissions:

Действие	Надпись права	Где используется
Создать задачу выдачи (из пакетного действия #Проверка запросов)	Approve Regear Requests	То же право, что и для одобрения. Кнопка "Create Cut-off Task" на вкладке Approved гейтится этим.
Взять неназначенную задачу (кнопка Take Task)	Claim Cut-off Tasks	Узкое право, чтобы у гильдий мог быть staff только-пакер, не способный одобрять.
Редактировать / отменять / переименовывать любую задачу независимо от автора	Supervise Cut-off Tasks	Опционально. Без этого staff может только освободить или завершить задачи, которые он лично взял.
Перераспределять шкафчики между участниками	Manage Lockers	См. Шкафчики.

Гейт по режиму

Канал #Задачи выдачи появляется в боковой панели только когда гильдия в payout mode = Item delivery (Настройки → Regear Policy → Silver Regear). В любом из silver-режимов одобренные ригир оплачиваются действием Payout на #Проверка запросов — см. Silver-режим — выплата. Исторические задачи, созданные до смены режима, остаются читаемыми для аудита; блокируется только создание свежих.

От Approved → задача выдачи

Pipeline начинается на #Проверка запросов. После того как staff нажал Approve на запросе, он уходит с вкладки Pending и попадает на вкладку Approved — это очередь работы, ждущая паковки.

Чтобы превратить одобренные запросы в задачу:

1. Открой #Проверка запросов → вкладка Approved.
2. Отметь строки, которые хочешь упаковать вместе. Большинство гильдий пакетирует по дневному окну (например, все одобренные за последние 24ч), но можно также по вар-роли, по участнику или как удобно.
3. Нажми Create Cut-off Task в панели пакетных действий.
4. (Опционально) Введи имя задачи. Если пусто, система автоматически назовёт Cut-off DD/MM HH:MM от времени создания.

Задача создаётся неназначенной — её может взять любой с Claim Cut-off Tasks. Выбранные запросы покидают вкладку Approved (чтобы другой staff не достал их повторно) и попадают в созданную задачу.

Защита на сервере

В задачу можно добавить только запросы со статусом Approved — pending, rejected и уже-в-другой-задаче запросы блокируются с понятной ошибкой. Это защищает от устаревших вкладок браузера и параллельных кликов "Create" по пересекающимся выборам.

Канал Задачи выдачи

Открой канал в КОМАНДА ригир → # Задачи выдачи.

Две вкладки сверху:

Вкладка	Что там
Active	Задачи минимум с одним недоставленным получателем. Активная вкладка — то, с чем работают пакеры.
Completed	Каждый получатель в задаче помечен как доставленный. Сохраняется для аудита; дальше делать ничего не нужно.

Каждая карточка задачи показывает:

• Имя задачи (переименовать inline можно при наличии Supervise Cut-off Tasks).
• Created by — staff, собравший задачу.
• Количество предметов + количество получателей — быстрый сигнал размера.
• Assignee — Unassigned (никто не работает) или @username (взято).
• Прогресс-бар — N / M Done получателей.

Кликни по карточке, чтобы открыть детальный drawer.

Список выдачи — что доставать из сундука

Детальный drawer открывается на вкладке Pick List. Это объединённый список каждого предмета, нужного каждому получателю, агрегированный по всем запросам задачи:

Каждая карточка показывает иконку предмета (с учётом тира), нужное количество (x1, x2, …), слот, в который идёт, и — если Арсенал включён — текущий запас в Арсенале (x0 при отсутствии запаса или выключенном Арсенале). Бейдж склада — это чек пакера «хватит ли мне на эту задачу?».

Ключ агрегации — (itemBaseName, totalTier). Двое получателей, нуждающихся в одном предмете на одном sum-tier (например, два T8 Knight Armor, независимо от того, T6+2, T7+1 или T8+0), сворачиваются в одну строку с x2. Разные sum-tier остаются отдельно (T7 Icicle Staff и T8 Icicle Staff — две карточки). См. Именование предметов + тиры про математику тира.

В шапке три кнопки:

Кнопка	Что делает
Take Task	Взять задачу — назначает её на тебя, чтобы другие пакеры видели, что над ней работают.
Release	Снять назначение (показано, когда задача у тебя). Освобождение оставляет задачу на месте; другой пакер может её взять.
Undo Task	Удалить задачу и отправить каждый связанный запрос обратно на вкладку Approved в #Проверка запросов. Полезно, когда задача создана по ошибке или её нужно пере-собрать. Запросы не теряют свой статус approved.

Сверка с chest log (Проверка выдачи)

Когда ты достал предметы из исходного сундука и положил их в целевой сундук «For Regear», кнопка Verify against chest log (вверху справа Pick List) открывает Проверка выдачи — вставь deposit log целевого сундука, и парсер скажет точно, что совпало, чего не хватает, чего лишнего и неожиданного.

Как использовать:

1. В Albion открой сундук, который использовал как назначение ригир, правый клик → Export log. Albion пишет TSV-файл (с табуляцией).
2. Открой файл, скопируй строки за временное окно паковки и вставь в textarea.
3. Нажми Compare. Проверка резолвит каждое имя предмета (любой из 14 языков Albion) и сравнивает со списком выдачи задачи по ключу (core item name, sum tier). Результаты попадают в три группы:
   • OK — нужно = получено. Предмет доставлен как ожидалось.
   • Missing — нужно > получено. Ещё нужно достать из исходного сундука.
   • Wrong / Extra — получено > 0, но не в списке выдачи. Вероятно, достал не тот предмет или не тот тир.

Раскрытие "Show sample log" разворачивает реальный EN-US пример, чтобы ты подтвердил, какой формат пишет Albion (парсер автоматически определяет локаль).

Полный дизайн — зачем существует tier-prefix-aware резолвер, как работает определение языка и какие ограничения — см. Pick Checker reference (internal design doc). Для повседневного использования пакером инструкций модала достаточно.

Recipients — кто что получит

Переключись на вкладку Recipients, чтобы увидеть разбивку по участникам.

Каждая строка получателя показывает:

• Имя персонажа + привязанный Discord (@username) + чипы вар-роли для запросов в этой задаче.
• Бейдж шкафчика (например, H3 — #01) — шкафчик, в который пакуешь. Шкафчик берётся из назначения на #Members → Locker или со страницы #Шкафчики гильдии. Пусто, если участнику ещё не назначен шкафчик — исправь на странице Шкафчики перед паковкой.
• Предметы к доставке — что именно этот участник должен получить из этой задачи. Сетка предметов использует ту же раскладку 3×4, что и оверлей подачи ригир, чтобы пакер быстро оценил, что «все слоты покрыты».

Порядок сортировки

Выпадающий список Sort by выбирает порядок отображения получателей. По умолчанию — Group > Locker — получатели сгруппированы по тому же физическому порядку сундуков + номеров шкафчиков, что и страница Шкафчики гильдии. Это значит, что паковка списка сверху вниз = обход сундуков гильдии в физическом порядке. Две альтернативы:

• War role — группировка по вар-роли (полезно, когда один пакер специализируется на DPS-ригир, а другой на support).
• Character A-Z — по алфавиту, без группировки.

Твой выбор запоминается per-user в браузере, так что возвращение на страницу подбирает место.

Пометка получателя доставленным

Когда упаковал всё в шкафчик участника, нажми Mark delivered на его строке (кнопка активна только после того, как ты Take-нул задачу). Это:

• Устанавливает per-request completedAt timestamp.
• Устанавливает запросу receivedAt timestamp, который переключает шаг Delivered на строке #Мои запросы участника.
• Обновляет строку #Мои запросы участника в реальном времени — бейдж переключается на Delivered в его браузере без обновления.

Если промахнулся, Undo на строке получателя откатывает — работает, пока родительская задача ещё не завершена.

Завершение задачи

Когда каждый получатель помечен доставленным, кнопка Deliver Items в футере drawer активируется. Нажатие:

1. Переключает статус каждого связанного запроса с approved на completed.
2. Отправляет каждому владельцу запроса постоянное inbox-уведомление («Your regear is ready — 1 request delivered in Cut-off 23/05 19:30»).
3. Задача переходит со вкладки Active на Completed.

Защитный гейт

Задачу нельзя завершить, пока остаётся хотя бы один непомеченный получатель. Если видишь "N recipient(s) not yet completed", прокрути вверх и найди недостающие галочки. Проверка race-safe — даже если коллега снимает галочку в момент твоего клика Deliver Items, побеждает только один из двух кликов, а второй видит ошибку.

Параллельные пакеры — что безопасно

Pipeline выдачи построен так, чтобы пережить параллельную работу нескольких staff:

• Создание задачи — если два пакера отметят пересекающиеся запросы + кликнут Create Cut-off Task одновременно, побеждает только один. Другой видит ошибку "already linked" и просто должен обновить + пере-выбрать.
• Взятие задачи — первый, кто нажмёт Take Task, побеждает; второй видит "Task was taken by another staff member."
• Освобождение требует, чтобы ты был назначенцем ИЛИ держал право Supervise Cut-off Tasks. Supervise существует для случая, когда пакер ушёл оффлайн в середине задачи и кому-то нужно подхватить.
• Пометка получателей доставленными также требует, чтобы ты был назначенцем ИЛИ супервайзером.

Почему "Claim" + "Take" сосуществуют

Право называется Claim Cut-off Tasks в редакторе Ролей — кнопка действия на задаче пишет Take Task. Различие намеренное: имя права читается как «разрешено ли этому staff вообще быть пакером?», тогда как кнопка читается как «я лично буду работать с этой задачей сейчас». Обе контролируют одно и то же действие.

Что видит участник

Как только получатель помечен доставленным, строка #Мои запросы участника получает зелёный бейдж Delivered и подсветку "📦 Items Ready". Если у него включены Уведомления, в дропдауне колокольчика появится inbox-запись вроде "Your regear is ready — 1 request delivered in Cut-off 23/05 19:30".

Сами предметы живут в назначенном шкафчике участника. Участник открывает этот шкафчик в игре и достаёт снаряжение — AO Master никогда не трогает инвентарь Albion напрямую; шкафчик — это реальный гильдейский сундук Albion, на который ты настроил права. Назначение шкафчика показано в панели #Мой профиль → Locker участника для справки.

Когда что-то идёт не так

Симптом	Причина	Решение
Кнопка Create Cut-off Task неактивна	В выборе есть non-approved запросы	Отфильтруй по вкладке Approved; сними остальное.
Ошибка "Already linked" на Create Cut-off Task	Другой staff только что вытащил пересекающийся запрос в задачу	Обнови вкладку Approved + пере-выбери.
Задача заблокирована / "Task was taken by another staff member"	Кто-то нажал Take первым	Обнови — его @username появится на карточке.
У получателя нет бейджа шкафчика	Этому участнику ещё не назначен шкафчик	Перейди в Шкафчики → назначь → вернись + упакуй.
Проверка выдачи говорит "Wrong item", но ты его упаковал	Вставленный лог включает другой предмет с тем же core_item_name + sumTier, что и в списке выдачи	Перепроверь имена предметов Albion — разные предметы могут сворачиваться на одном core-ключе в редких случаях.
Проверка выдачи показывает не тот язык	Заголовок TSV отсутствовал или обрезан до вставки	Вставь весь лог, включая первую строку, которую пишет Albion; парсер использует её для определения локали.

Связанное

• Staff — проверка + одобрение — upstream-шаг.
• Silver-режим — выплата — альтернативный путь доставки.
• Обзор процесса ригир — оба режима бок о бок.
• Шкафчики — назначить / отменить / сбросить привязки шкафчика.
• #Задачи выдачи — короткая справка по каналу.