Staff — revisar + aprovar / rejeitar solicitações de regear

Membros enviam regears em #Solicitar Regear; tudo que enviam cai aqui em #Revisar Solicitações para a staff triar. Esta página percorre a fila de revisão de ponta a ponta.

Permissões

Você precisa da permissão Approve Regear Requests (na seção Regear em Editar Função → Permissões) para ver este canal e agir nas solicitações. A maioria das guildas dá isso para os presets Regear Staff / Regear Manager / Manager. Veja a Referência de permissões para a tabela completa.

A fila de revisão

Abra #Revisar Solicitações pela seção REGEAR TEAM da barra lateral.

Topo da página:

• Abas — Pending / Approved / Rejected. Pending é a fila de trabalho; as outras são visões de auditoria.
• Toolbar (na aba Pending):
  • Checkbox Select all — para ações em massa.
  • Filtro Type — All / Deaths / Overcharge.
  • Filtro War Role — afunila para uma war role específica (útil quando uma função domina em uma CTA).
  • Buscar — aceita um nome de vítima OU um #event_id (o ID do evento Albion de 9 dígitos com o prefixo #, ex.: #475568182). O ID do evento é o mesmo número que o feed de mortes do Albion e as URLs de link de evento usam — quando um membro te envia no Discord um link de abate perguntando "esse passou?" — copie o número no final, adicione #, cole, e a fila filtra para só aquela linha. A mesma busca por #event_id funciona em #Tarefas de Corte para você rastrear uma morte da fila de revisão até o lado do packer.

Cada card na fila é uma solicitação:

• Linha de cima — nome do membro + personagem + badge de war role (Outcomers / FreezDawnera / Riderr na screenshot).
• Meio — link do evento de morte (eventID) + um grid 3×4 de equipamentos mostrando os itens perdidos com badges de validação por slot:
  • 🟢 OK — slot bate com o loadout da função no tier esperado.
  • 🟡 Under-tier — item está em tier menor que o pedido.
  • 🔵 Over-tier — item está em tier maior.
  • 🔴 Invalid — item não está no loadout da função.
• Linha de baixo — botões de ação + metadados (timestamp UTC da morte + fame).

As três ações por solicitação

✅ Aprovar

Aprova a solicitação. O que acontece depois depende do modo de regear da guilda:

• Modo Item — a solicitação vai para approved; o botão verde se chama Create Cut-off Task (única + em lote). Clique para juntar a solicitação em uma tarefa de empacotamento em #Tarefas de Corte. Veja Modo Item — Corte + locker.
• Modo Silver — a solicitação vai para approved; o botão verde se chama Payout (única + em lote). Clique para creditar silver na carteira do Banco de Silver do membro. Veja Modo Silver — pagamento do Banco de Silver.

Mesma ação Aprovar, botão de segundo passo diferente conforme a configuração da guilda. De propósito há uma lacuna entre aprovar e o dinheiro/itens efetivamente se moverem — veja Ciclo de vida em dois passos abaixo.

❌ Rejeitar

Rejeita a solicitação. Um prompt de motivo abre — digite o motivo (ex.: "War role errada — não escalada para essa CTA"), confirme. O membro vê a rejeição + motivo em #Minhas Solicitações.

Uma vez rejeitada, a solicitação é terminal — não volta para a fila. Se o membro discorda, pode enviar uma nova solicitação com informação corrigida.

📁 Arquivar

Tira a solicitação da fila Pending sem aprovar nem rejeitar — manda para a visão Archived. Use quando um membro envia duplicata, uma solicitação antiga que não dá mais para agir, ou qualquer coisa que você queira esconder sem se comprometer com decisão.

Trava por política de validação

O que o validador faz com problemas under-tier / over-tier / inválido é decidido pela Regear Policy da guilda (Configurações → Regear Policy). Três slots de política, cada um setado independentemente para:

• Auto-reject — solicitação é rejeitada no envio; nunca chega nessa fila.
• Allow — solicitação flui para a staff com o problema marcado mas o botão Enviar nunca bloqueia o membro.
• Staff decision (padrão) — solicitação chega na fila; staff vê o problema + decide por solicitação.

Se sua guilda usa "Staff decision" para slots inválidos, espere ver solicitações com badges 🔴 que ainda são da sua conta. A info por slot ajuda a decidir entre Aprovar (perdoar), Rejeitar (recusar) ou Aprovar-com-override (ex.: escolher uma war role diferente na aprovação que dá match no gear).

Override de war role na aprovação

Clique no badge da war role no topo do card de uma solicitação para trocar a war role daquela solicitação específica. Isso re-roda a validação contra o loadout da nova função — útil quando:

• O membro clicou na war role errada na hora de enviar.
• O equipamento perdido na real mapeia para o loadout de outra função (ex.: um Holy Healer rodou Lifecurse).
• Você quer aplicar um silver cap diferente (em modo War Role — Capped by actual, o cap da função escolhida é o que vale no Payout).

O override é gravado no Registro de auditoria por transparência.

Ações em massa por multi-seleção

Marque o checkbox Select all (ou os checkboxes por card) → a toolbar revela botões Aprovar / Rejeitar / Arquivar em massa.

• Bulk Approve — aprova N solicitações em uma chamada. Cada solicitação ainda passa pela lógica por modo — modo item cria uma Tarefa de Corte por solicitação (sem bundling); modo silver credita N pagamentos um atrás do outro mas como uma ação em lote.
• Bulk Reject — abre um prompt de motivo; mesmo motivo aplicado a todas as selecionadas. Use para violações claras ("Todas falharam na checagem de war role").
• Bulk Archive — tira todas as selecionadas de pending. Sem prompt.

Ciclo de vida em dois passos

Por que aprovar e entregar são cliques separados:

• Silver é moeda de verdade. Aprovar = "sim, é uma reivindicação válida." Payout = "sim, move o silver." Stripe / folha de pagamento / PayPal separam todos.
• Janela de reversão. Se você notar um erro entre aprovar e pagar, rejeite a linha antes do dinheiro sair. Sem precisar de lançamentos de compensação.
• Lotear para o payday. A staff pode acumular uma semana de aprovados e pagar tudo num único Payday — uma única entrada no Registro de auditoria, uma única notificação no Discord.
• Pending agnóstico ao modo. Solicitações pendentes não ligam para qual modo a guilda está. Se sua guilda troca de modo (item → silver), as pendentes não precisam de migração — se comprometem com o novo modo quando aprovadas.

Para modo item o passo de bundling é ainda mais visível: aprovar → solicitação espera → juntar em uma Tarefa de Corte → packer faz o trabalho. A Tarefa de Corte é a entrega de fato — a aprovação é só o sinal verde.

O que os membros veem

Quando você age numa solicitação, o membro vê a atualização em #Minhas Solicitações (o tracker pessoal):

• Approved → a barra de progresso avança para o passo 2 de 5.
• Rejected → a linha fica vermelha com seu motivo.
• Archived → a linha some da visão Pending dele.

A barra de progresso então continua conforme a Tarefa de Corte / fluxo de Payout avança. Detalhe completo do lado do membro em Membros — enviar um regear.

Páginas relacionadas

• Visão geral da pipeline de regear — modos + bifurcação explicados
• Membros — enviar um regear — o fluxo de envio upstream
• Modo Item — Corte + locker — o que acontece depois de Aprovar em modo item
• Modo Silver — pagamento do Banco de Silver — o que acontece depois de Aprovar em modo silver
• Configurações — Regear Policy — política de validação + escolha de modo
• Regear de membro — a visão de auditoria por membro