Amount. Screenshot. Next loss. One card, one approve, paid.

What that costs you

Members send a screenshot and a number to whichever officer is online. The officer squints at the shot, tries to remember whether this person already claimed for that fight, pays out of memory, and writes it in a spreadsheet only they update.

Three questions then have no answer. How much did that fight cost us? Did we already pay this person for this death? Why was mine denied? And when the officer who kept the spreadsheet stops playing, the record leaves with them.

The fix is not a better form. Discord modals cannot take files at all, so a claim can never be one submission — which is exactly why the flow every guild invents is a DM thread. Guild Butler keeps the thread and gives it structure: a claim is a real database row from the first button press, so a bot restart mid-claim loses nothing, and every decision lands somewhere both sides can point at afterwards.

Buttons appear only when they’ll work

While a line is still waiting on its screenshot, Add is hidden — two open lines at once is exactly what used to cross two deaths' evidence. And Submit only appears when the claim would actually go through, so a member never presses a button that then refuses them.

Cancel and the "Edit an item…" picker always survive, so nobody can be locked out by their own half-finished line.

The panel follows the member. If anything is posted under it, the bot deletes it and re-posts at the bottom of the thread instead of editing in place — because a panel three screens up is a panel nobody presses.

The screenshot guide link is shown here, at the moment the member is being asked for a shot, rather than in a pinned message at the top of a channel.

The shots, the amounts, the roster — one card

The author line names the drive and links back to the board, so a shared review space is not a wall of identical "Regear #N" posts. The colour tracks status — pending, approved, denied — because that is the more useful signal at a glance.

The roster chip sits inside the From field rather than getting a field of its own, so it reads as a fact about that person instead of pushing the card's real content down: nothing when they were confirmed, 🪑 when they were on the bench, ⚠️ when they were not on the roster at all.

The Thread link is there because a card can only carry ten attachments. Past that the card says "Showing the first 10 of N" and points at the thread, which holds every shot and the whole conversation.

✂️ Split a lumped claim

Members routinely submit one line with the summed amount for several deaths. Officers do not want to bounce that back, so Split replaces one line of amount X with N lines of the same kind, using whole parts that sum to exactly X.

N is 2 to 10, and a split is refused when the amount is smaller than N — every part must be at least 1 silver. With one splittable line the count modal opens immediately; with several you pick the line first.

Splitting is not a decision: the member is not pinged and their thread is untouched. The confirmation then offers ✅ Approve, because you split it in order to approve it.

Afterwards the statistics read N deaths for N deaths, while claims stays 1 and the payout is a single credit of the original total. Evidence is copied onto the first child only — duplicating the same screenshot onto ten children would spend the card's entire ten-attachment budget on one picture.

✍️ Request changes, and how the bot knows it was addressed

The reasons are fixed: Wrong amount, Need a clearer / another screenshot, Wrong type (death / OC), Duplicate, Something else (add a note). Then which line — skipped when the claim has one, with "Whole request" always available.

The claim goes back to the member, their thread reopens with the ask, and the flagged line carries a ⚠️ badge in their edit picker. Their per-line panel gives them ✏️ Amount, → Death/OC, 🔄 Replace shots and 🗑️ Remove.

Each ask records a snapshot of the line as it was, so the bot can tell whether it was actually addressed rather than merely touched. A single "need a clearer shot" auto-resubmits the moment the new screenshot lands; a multi-ask round waits for the explicit 🔁 Resubmit for review button. Resubmitting with something still unaddressed gets a soft "resubmit anyway?" — a warning, not a wall. A "what changed" summary is posted in the thread on resubmit.

Why the undo has its own reason code

Revoke does not edit or remove the original credit. It appends a negative row with its own reason, regear_undo, distinct from regear.

That distinction is not cosmetic. Reusing regear for the reversal made a revoked claim count as a second regear received while the silver netted to zero — so a payout that had been taken back still looked, on the leaderboard, like one that stuck. With a separate reason the counts net out as well as the silver.

The member is told in their thread, the thread is stamped ↩️, and the board tally, the drive's roll-up, the leaderboard and any linked raid card all step back down. Officers are also offered ↩️ Undo directly on the approval confirmation, so the fix for a misclick is one press away.

The credit itself is idempotent: the approval re-checks the claim's status inside its own transaction, so a double click pays once.

Why the gear bar is a snapshot

The raid was called at "T8.1 · Beef stew · Resistance potions". A raid edited after the fight must not change the standard a claim is judged against, so the requirements are frozen onto the drive when it opens — the same reasoning that freezes a raid's tax mode.

It is kept separate from Conditions on purpose. Conditions is your guild's regear policy; Required gear is a fact about one raid.

The caller can open it, not just staff

The 📸 Regear board button sits on the raid's officer console next to Settle, and returns as 📸 Open regear board on the settle and End-without-split confirmations — the moments an officer is already thinking about that raid's money. Same action, same guards; one click, no modal.

That button is open to the raid's own caller as well as regear staff. The person who just watched twenty people die holds the context and is racing the window in which members still have their death screenshots — and opening a board moves no silver. Approving a claim stays regear staff, so the money boundary does not move. A called-off raid is refused outright: a board for a fight nobody fought is not a vacancy.

What the fight cost, reported where it belongs

When a raid-linked drive closes, a summary lands in that raid's own officer thread: claims, distinct claimants, the 💀 / ⚡ split, total paid, the biggest single claim, the denied count and the top claimants. The raid card itself picks up a 📸 Regear: … · N claims line.

The gross − repair − regear net appears only when the raid has actually been settled — there is nothing to net against otherwise — and it carries its own disclaimer, because it must not be mistaken for settlement math. Regear is paid from member balances; no silver moves against the raid's split.

More than one drive on the same raid is legitimate — late claims after a close — and the summary says how many boards it is adding up, because otherwise the totals look wrong to anyone who only remembers opening one.