diff --git a/docs/consultations/gemini-arbiter-discord-roles-round-2-2026-04-13.md b/docs/consultations/gemini-arbiter-discord-roles-round-2-2026-04-13.md
new file mode 100644
index 0000000..298d03e
--- /dev/null
+++ b/docs/consultations/gemini-arbiter-discord-roles-round-2-2026-04-13.md
@@ -0,0 +1,65 @@
+# Gemini Consultation: Arbiter Discord Role Automation — Round 2
+
+**Date:** April 13, 2026  
+**From:** Michael (The Wizard) + Claude (Chronicler #86)  
+**To:** Gemini (Architectural Partner)  
+**Re:** Follow-up on discord.js + Express startup, and step-by-step Carlbot migration plan
+
+---
+
+## Hey Gemini! 👋
+
+Round 1 was exactly what we needed — thank you. Ephemeral replies solving Holly's button state question was the key insight, and the Gateway requirement for welcome messages is good to know before Code starts building.
+
+We have two follow-up topics: your question about discord.js + Express startup structure, and a new question about how to migrate off Carlbot cleanly.
+
+---
+
+## What We Did Based on Your Feedback
+
+- Locked in: persistent embed, edit-in-place with 404 fallback
+- Locked in: ephemeral replies for per-user role confirmation
+- Locked in: discord.js Gateway client alongside Express for `GUILD_MEMBER_ADD`
+- Decision: **no Carlbot cutover before April 15 launch** — build in parallel, cut over post-launch
+- Next step: file a Code bridge request with a complete implementation spec, but we want your answers here first so the spec is complete
+
+---
+
+## Specific Questions
+
+### On Your Follow-up: discord.js + Express Startup Structure
+
+1. **Non-blocking initialization:** What's the recommended pattern for initializing a `discord.js` Client alongside an Express server without blocking? Should `client.login()` be called before or after `app.listen()`? Should we `await` the `client.ready` event before starting Express, or let them start concurrently and handle the case where a webhook fires before the Gateway is ready?
+
+2. **Single process vs. separate process:** Should the discord.js Gateway client live in the same Node.js process as Express, or would you recommend splitting them into separate processes (e.g., a `bot.js` alongside `index.js`) under PM2 or systemd? Arbiter currently runs as a single `arbiter-3` systemd service. What are the tradeoffs at our scale?
+
+3. **Shared state:** Both the Express webhook handlers (Pterodactyl `/createserver`) and the discord.js client will need to call Discord API methods (update the get-roles message, assign roles). What's the cleanest pattern for sharing the `discord.js` client instance between Express route handlers and the bot event listeners? A module-level singleton? Dependency injection?
+
+### On Migrating from Carlbot: Step-by-Step
+
+4. **Current Carlbot reaction roles → Arbiter button roles migration:** We currently have a `#get-roles` message managed by Carlbot with emoji reactions. When we're ready to cut over post-launch, what's the safest step-by-step migration sequence? Specifically: do we disable Carlbot's reaction role handling first, then swap the message, or post Arbiter's button message first and run both briefly in parallel? What are the risks of each approach?
+
+5. **Role data continuity:** Members who currently have server roles assigned via Carlbot reaction roles will keep those roles after migration (Discord roles persist regardless of which bot assigned them), correct? We just need to make sure Arbiter knows about existing role assignments so it can correctly toggle them. Is there anything Arbiter needs to do at cutover time to reconcile existing role state, or does it just read from Discord's API on demand?
+
+6. **Welcome message cutover:** Carlbot currently sends a welcome message on member join. When we switch to Arbiter's `guildMemberAdd` handler, is there a risk of double-welcome-messages during a brief overlap period, and how do we avoid it?
+
+---
+
+## Context That Might Help
+
+- Arbiter runs as a single `arbiter-3` systemd service on Command Center (Node 20.x)
+- We do not currently use PM2 — just systemd
+- The Pterodactyl webhook fires when a server is created/deleted and Arbiter already handles it in `src/routes/webhook.js`
+- Code (Claude Code) will be implementing this in `firefrost-services/services/arbiter-3.0/`
+- We want the Code bridge request to be complete enough that Code can build without ambiguity
+- Post-launch cutover is targeting sometime the week of April 20
+
+---
+
+Thanks again Gemini — your Round 1 answers saved us from building the wrong thing. Really appreciate the partnership. 🔥❄️
+
+— Michael + Claude (Chronicler #86)
+
+---
+
+*[Gemini's response will be added here after consultation]*