diff --git a/services/wolf.sh b/services/wolf.sh
index 3a37a0f..0564a97 100644
--- a/services/wolf.sh
+++ b/services/wolf.sh
@@ -4038,10 +4038,26 @@ cd $WOLF_DIR && ./manage.sh controllers
 \`\`\`
 Picks your paired Moonlight client (auto-selected if there's only one),
 then asks how many controllers to configure and what type to force each
-one to (\`AUTO\` / \`XBOX\` / \`PS\` / \`NINTENDO\`) — e.g. controller 1 =
-Xbox, controller 2 = PlayStation. This calls Wolf's own REST API
-(\`controllers_override\`, per Wolf's own docs' "Override the default
-joypad mapping" section) rather than hand-editing \`config.toml\`.
+one to. There are only **3 concrete types** (confirmed against Wolf's own
+virtual-pad source, \`inputtino\`) — not one per real controller brand:
+- \`XBOX\` → an **Xbox One** controller specifically (not Series/360)
+- \`PS\` → a **PlayStation 5 DualSense** specifically (no separate PS4 option)
+- \`NINTENDO\` → a **Switch Pro Controller**
+- \`AUTO\` → auto-detects from whatever the physical controller reports
+  (this is what causes the collision in the first place — e.g. every
+  8BitDo pad set to "Switch mode" reports as Nintendo, so AUTO gives all
+  of them the identical GUID)
+
+e.g. controller 1 = \`NINTENDO\` (matches an 8BitDo pad's native Switch
+mode), controller 2 = \`XBOX\`, controller 3 = \`PS\`. This calls Wolf's own
+REST API (\`controllers_override\`, per Wolf's own docs' "Override the
+default joypad mapping" section) rather than hand-editing \`config.toml\`.
+
+Forcing a non-matching type doesn't break any buttons — Moonlight still
+translates your controller's actual button presses onto whichever virtual
+pad type you pick — it just means that controller's on-screen button
+prompts (e.g. "press ✕") won't visually match what's printed on the
+physical pad. Purely cosmetic.
 
 **Reconnect (or fully restart) the Moonlight stream afterward** — this
 applies when Wolf creates each controller's virtual pad for a *new*
@@ -4052,6 +4068,30 @@ If \`./manage.sh controllers\` says the API socket isn't up yet, re-run
 mount this command needs) and then \`docker compose up -d\` to recreate the
 Wolf container.
 
+### 4 controllers (Cemu / Wii U games)
+Wii U hardware itself tops out at 4 local players, and everything upstream
+supports at least that many: Cemu's own Input Settings allows up to 8
+controller slots (confirmed against Cemu's own wiki — well above what any
+Wii U game actually uses), and Wolf's wire protocol tracks controller
+slots via a bitmask with no hardcoded 4-controller limit (confirmed
+against its own \`control/input_handler.cpp\` source) — the practical
+ceiling is whatever your Moonlight *client* supports (commonly 4 on
+PC/iOS).
+
+The catch: with only 3 concrete forced types (above), controller 4 can't
+get its own guaranteed-unique GUID — it has to reuse \`XBOX\`, \`PS\`, or
+\`NINTENDO\` and land back in the same ambiguous-GUID situation with
+whichever one it matches.
+
+**Workaround for the 4th controller: bind it in Cemu one at a time.**
+Disconnect (or just don't touch) every controller except the one you're
+currently binding, then use Cemu's own "press a button to detect" step
+for that slot. With only one Wolf virtual pad actually emitting input at
+that moment, there's nothing for Cemu's picker to confuse it with,
+regardless of which type it's sharing a GUID with. This is a reasoned
+workaround, not one confirmed working live — if it doesn't pan out,
+that's useful to know.
+
 ## EA games (Battlefront II 2017, etc.)
 EA titles require GE-Proton and the EA App to be installed inside the Wine
 prefix. The EA App handles authentication — without it, the game launches