幹部 — 審核與核准 / 拒絕 regear 申請

成員在 #Request Regear 提交 regear；所有提交都會落到這裡，#Review Requests，給幹部分流處理。這頁從頭到尾走過審核佇列。

權限

你需要 Approve Regear Requests 權限（在 Edit Role → Permissions 的 Regear 區塊）才能看到這個頻道並對申請執行動作。多數公會會把這個權限授予 Regear Staff / Regear Manager / Manager 的 role 預設。完整對應表請看 權限參考。

審核佇列

從側欄的 REGEAR TEAM 區塊開啟 #Review Requests。

頁首：

• 分頁 —— Pending / Approved / Rejected。Pending 是工作佇列；另外兩個是稽核視角。
• 工具列（在 Pending 分頁）：
  • Select all 勾選框 —— 多選批次動作用。
  • Type 篩選 —— All / Deaths / Overcharge。
  • War Role 篩選 —— 縮窄到特定 war role 的申請（當某個 role 在某場 CTA 占多數時很有用）。
  • Search —— 接受受害者名稱或 #event_id（以 # 為前綴的 9 位數 Albion event ID，例如 #475568182）。event ID 就是 Albion 死亡資訊和事件連結 URL 所用的那串數字，當成員在 Discord 傳給你擊殺連結問「這筆有進來嗎？」時，把末端數字複製起來，加上 # 前綴貼入，佇列就只顯示那一列。同樣的 #event_id 搜尋在 #截止任務 也有效，讓你從審核佇列一路追蹤到打包端。

佇列上每張卡片是一筆申請：

• 頂部 —— 成員名稱 + 角色 + war role 標章（截圖中的 Outcomers / FreezDawnera / Riderr）。
• 中段 —— 死亡事件連結（eventID）+ 一個 3×4 裝備格，列出損失的物品並標出每欄位的驗證結果：
  • 🟢 OK —— 此欄位符合 role loadout 所期待的階級。
  • 🟡 Under-tier —— 物品階級低於 role 要求。
  • 🔵 Over-tier —— 物品階級較高。
  • 🔴 Invalid —— 物品根本不在這個 role 的 loadout 裡。
• 底部 —— 動作按鈕加上中介資訊（UTC 死亡時間戳與聲望）。

每筆申請的三個動作

✅ Approve

核准申請。下一步依公會的 regear 模式 而定：

• 物品模式 —— 申請進入 approved 狀態；綠色按鈕標為 Create Cut-off Task（單筆或多筆）。按它把申請打包成 #Cut-off Tasks 裡的打包任務。詳見 物品模式 — 截止與 locker。
• Silver 模式 —— 申請進入 approved 狀態；綠色按鈕標為 Payout（單筆或多筆）。按下後把 silver 入帳到成員的 Silver 銀庫錢包。詳見 Silver 模式 — 從 Silver 銀庫撥款。

同樣是 Approve 動作，但 第二步按鈕會依公會設定不同。在核准與實際發放金錢／物品之間刻意保留一段空檔 —— 詳見下方 兩步驟生命週期。

❌ Reject

直接拒絕申請。會跳出輸入理由的視窗 —— 寫上理由（例如「Wrong war role — not assigned for this CTA」），確認。成員會在 #My Requests 看到拒絕與理由。

一旦拒絕，申請就 終結 —— 不會再回到佇列。如果成員有異議，可以重新提交一筆修正過的申請。

📁 Archive

把申請從 Pending 佇列移除而不核准也不拒絕 —— 移到 Archived 視圖。當成員重複提交、申請已經過期不再處理、或者你想隱藏但又不想做決定時使用。

驗證政策的擋條件

對 under-tier / over-tier / invalid 問題，驗證器做什麼由公會的 Regear Policy（Settings → Regear Policy）決定。三個政策欄位，每個可獨立設為：

• Auto-reject —— 申請在送出當下就被拒絕；永遠不會出現在這個佇列。
• Allow —— 申請會帶著問題標記送到幹部端，但 Submit 按鈕不會擋成員。
• Staff decision（預設）—— 申請會到佇列；幹部看到問題後逐筆決定。

如果你公會在 invalid 欄位用「Staff decision」，你會看到帶 🔴 標章的申請，但仍由你決定。每個欄位的資訊幫你在 Approve（放行）、Reject（拒絕）、或 Approve-with-override（例如核准時改成另一個確實對得上裝備的 war role）之間做選擇。

核准時換 war role

點申請卡片頂部的 war role 標章可以為這筆申請 更換 war role。這會用新 role 的 loadout 重跑驗證 —— 在以下情境很有用：

• 成員提交時點錯 war role。
• 損失的裝備其實對應到另一個 role 的 loadout（例如說好跑 Holy Healer 但實際跑 Lifecurse）。
• 你想套用不同的 silver 上限（在 War Role — Capped by actual 模式下，撥款時用的就是所選 role 的上限）。

切換動作會記錄在稽核紀錄裡，便於追溯。

多選批次動作

勾選 Select all 或每張卡片上的勾選框 → 工具列會出現批次的 Approve / Reject / Archive 按鈕。

• 批次 Approve —— 一次核准 N 筆申請。每筆仍照各自的模式邏輯處理 —— 物品模式會為每筆建立一個 cut-off 任務（不會合併）；silver 模式會逐筆撥款，但合在一個批次動作裡。
• 批次 Reject —— 跳出理由輸入；同一個理由套用到所有選取項。適用於明顯的違規（「全部沒通過 war role 檢查」）。
• 批次 Archive —— 把選取項全部移出 pending。不會跳出提示。

兩步驟生命週期

為什麼核准與發放是兩個分開的點擊：

• silver 是真的錢。 Approve = 「是的，這是有效的請求。」Payout = 「是的，把 silver 移過去。」Stripe / 發薪系統 / PayPal 都把這兩步分開。
• 反悔視窗。 如果在核准與撥款之間發現有誤，撥款前直接拒絕該列就好，不必再做沖銷分錄。
• 發薪日批次。 幹部可以累積一週的核准，在發薪日一次撥完 —— 單一稽核紀錄、單一 Discord 通知。
• 與模式無關的 pending。 待審申請不在乎公會目前是哪種模式。如果公會切換模式（物品 → silver），待審申請不需要遷移 —— 它們會在被核准時綁定到新模式。

物品模式裡，這個拆分更明顯：核准 → 申請等待 → 打包成 cut-off 任務 → 打包人員執行。Cut-off 任務才是實際交付動作 —— 核准只是放行。

成員看到什麼

當你對申請執行動作後，成員會在 #My Requests（他的個人追蹤頁）看到更新：

• Approved → 進度條推進到第 2/5 步。
• Rejected → 該列變紅並顯示你的理由。
• Archived → 該列從他的 Pending 視圖消失。

接著進度條會跟著 cut-off 任務 / Payout 流程繼續推進。完整成員側細節在 成員 — 提交 regear。

相關頁面

• Regear 流程總覽 —— 模式與分岔解析
• 成員 — 提交 regear —— 上游提交流程
• 物品模式 — 截止與 locker —— 物品模式核准後會發生什麼
• Silver 模式 — 從 Silver 銀庫撥款 —— silver 模式核准後會發生什麼
• Settings — Regear Policy —— 驗證政策與模式選擇
• Member Regear Report —— 逐成員稽核視角