diff --git a/DESIGN.md b/DESIGN.md
index 188d7f0..7406011 100644
--- a/DESIGN.md
+++ b/DESIGN.md
@@ -123,6 +123,23 @@ Spacing follows Tailwind's 4px scale. Existing frontend stacks use `gap-1`, `gap
 - **Motion**: control transition only.
 - **Layout**: wraps on narrow screens without horizontal overflow.
 
+### Transfer workflow surface
+
+- **Structure**: the account `AssignmentCard` owns current-assignment context and opens the
+  `RequestTransferDialog`; `/transfers` uses a `stack` of `Card` sections containing request,
+  approval, and escalated-resolution cards.
+- **Variants**: request cards, leader approval cards, and superuser resolution cards share the
+  neutral card surface; status meaning is carried by the existing `Badge` variants.
+- **States**: loading, empty, pending, approved, rejected, appealed, escalated, completed,
+  cancelled, denied, error, and success feedback.
+- **Accessibility**: every dialog has a visible title and description, every textarea has a label,
+  rejection requires a non-empty reason, and destructive actions remain keyboard reachable with
+  the existing focus ring.
+- **Motion**: use the existing shadcn dialog, button, and toast transitions only; no decorative
+  section animation. Async buttons expose their pending state and disable competing actions.
+- **Layout**: the transfer list is a single document scroll region inside the authenticated shell;
+  cards use an intrinsic one-column-to-two-column grid and remain readable at narrow widths.
+
 ## 6. Motion & Interaction
 
 ### Timing
diff --git a/TODO.md b/TODO.md
index 9d4400e..2b0ca25 100644
--- a/TODO.md
+++ b/TODO.md
@@ -4,10 +4,11 @@
 
 - [x] **Leadership evaluations and performance rating system** - Members of the unit should be able to rate the performance of their direct team leaders (full performance rating) and submit opinions on separate leaders (a more limited rating system for non-direct supervisors.) These ratings should appear anonymously on the leader's service record page. The ratings are divided by mission, so that they can accumulate over time to form a more accurate representation of the overall delta of a leader's performance over the course of multiple operations. These ratings appear as bars, red-to-green gradients, and percentage scores on the service record page. A small table showing the latest missions and the leader's overall rating are also visible below this bar. Additionally, leaders should be able to rate the performance of their subordinates. However, these ratings appear in a far more limited fashion on the subordinate's service record page. Instead of a breakdown with bars, percentages, latest missions, etc., they instead just get a text label indicating a summary of their performance from leadership. For example, if a subordinate is rated very highly by their leaders, their text label might say "OPERATOR PERFORMANCE LEVEL: EXCELLENT" in green text while a moderate review may say "OPERATOR PERFORMANCE LEVEL: MODERATE" in grey or blue text and a low rating might say "OPERATOR PERFORMANCE LEVEL: UNDER REVIEW" in red text. Preferably, there'd be at least 5 levels of performance instead of the 3 I used as examples.
 - [ ] **Ribbon overview and listing page** - There should be a page that lists all of the medals and ribbons that could be granted to a user (excluding commendations, which could arise on the fly and are not set in stone.) This would allow users to review the requirements for earning a specific medal or ribbon, and get to see the art of that award as well, if any.
-- [ ] **Assignment transfer request system** - Allow users to request transfers to new assignments (i.e. transfer from infantry to aviation, medical to infantry, medical to aviation, infantry to intel, logistics to infantry, etc., covering all cases). The leader of the user's current assignment and the leader of the user's requested assignment should be notified of the request via app and via bot, and should have the option to "approve" or "reject with reason" in either interface. If both leaders approve, the assignment is automatically transferred and updated everywhere. If one leader rejects it, the rejection reason is sent to the other leader and to the individual making the request, and the individual is given an option to appeal via the app or the bot. If they appeal, both leaders are bypassed and the request goes directly to me (or a superuser) who can then make the final call.
+- [ ] **Assignment transfer request system** - Allow users to request transfers to new assignments (i.e. transfer from infantry to aviation, medical to infantry, medical to aviation, infantry to intel, logistics to infantry, etc., covering all cases). The leader of the user's current assignment and the leader of the user's requested assignment should be notified of the request via app and via bot, and should have the option to "approve" or "reject with reason" in either interface. Approvals are only collected from assignments that actually have a leader: if the user's current assignment has no leader (e.g. it lost its leader), only the requested assignment's leader needs to approve — and vice versa if the requested assignment is leaderless. If neither assignment has a leader, skip the leaders entirely and send the request directly to me (or a superuser) for a final call. Once all required approvals are in, the assignment is automatically transferred and updated everywhere. If any required approval is rejected, the rejection reason is sent to the other leader (if one exists) and to the individual making the request, and the individual is given an option to appeal via the app or the bot — this applies even when only one approval was required. If they appeal, all remaining leaders are bypassed and the request goes directly to me (or a superuser) who can then make the final call.
 - [ ] **Scoped admin UI pages** - The admin UI is fantastic, but it needs to be scoped so that users can only see and interact with certain pages even if they have read permissions for any/all pages. For example, if a user has read permissions for the Users collection, they can't just see the admin page for it - they need something like "admin:users:manage" or something like that (based on whatever format fits our current system best.) So long as they have BOTH the read and manage permissions, they can see the admin page. Otherwise, it's just hidden from them entirely.
 - [ ] **Editable helpdesk tickets & user voting** - Having helpdesk tickets be editable by their authors after the fact would be very helpful. This would have to be auditable, of course. In addition, allow users to upvote specific tickets would help to prioritize desired features, pressing bugs, or other tickets wherein there is a shared desire for work from the userbase.
 - [ ] **"Community" navigation group** - A "Community" nav group in the sidebar with subpages like "Contacts (NPCs)", "Statistics", etc., would be really helpful for future updates wherein the players will have interactions with NPCs via the market, in general conversation, long-standing faction interactions, etc.
+- [ ] **Respawn tickets based on attendance** - I want to track respawn tickets as a "global variable" that is automatically incremented based on reported attendance for a mission compared against real attendance checked via the webapp<->Arma sync system. For every person who marks that they will attend and DOES attend, 1 respawn ticket is awarded. For every person who marks they MIGHT attend and DOES attend, 0.5 respawn tickets will be awarded. For every person who marks that they will NOT attend and does attend, 0.25 respawn tickets will be awarded. All respawn tickets are accumulated and applied to the next operation.
 
 ## Desirable Additions, Medium Priority