diff --git a/docs/consultations/gemini-trinity-console-decision-2026-04-04.md b/docs/consultations/gemini-trinity-console-decision-2026-04-04.md
new file mode 100644
index 0000000..52b0090
--- /dev/null
+++ b/docs/consultations/gemini-trinity-console-decision-2026-04-04.md
@@ -0,0 +1,450 @@
+# Gemini Consultation: Trinity Console - Expansion vs Security Fixes Decision
+
+**Date:** April 4, 2026, 12:30 AM CST  
+**Consultation Type:** Critical Architectural Decision Review  
+**Participants:** Michael (The Wizard), Gemini (Architectural Partner), Claude (Chronicler #57)  
+**Context:** Soft launch in 11 days - should we fix security gaps now or build proper foundations first?
+
+---
+
+## 👋 HEY GEMINI - WE NEED YOUR STRATEGIC INSIGHT
+
+We're at a critical decision point and want your architectural perspective before we commit to a path.
+
+**The tension:** Security fixes now vs proper foundations first
+
+**Timeline pressure:** 11 days until soft launch (April 15, 2026)
+
+**The question:** Are we making a mistake by deferring security fixes? Or are we making a mistake by NOT building foundations first?
+
+Let us lay out the complete picture for you.
+
+---
+
+## 🎯 WHERE WE ARE RIGHT NOW
+
+### Soft Launch Status (April 4, 2026)
+
+**Target:** April 15, 2026 (11 days from now)  
+**Goal:** Successfully onboard and manage 10 paying subscribers  
+**Social campaign:** Started April 2, 2026
+
+**Blockers Complete (2 of 5):**
+1. ✅ **Website Migration** - firefrostgaming.com LIVE with real-time server status
+2. ✅ **Legal Pages** - Terms & Privacy sufficient for launch
+
+**Blockers Remaining (3 of 5):**
+3. ⏳ **Trinity Console Security Hardening** (4-5 hours) ← THE DECISION POINT
+4. ⏳ **Unsubscribe Flow UI** (2-3 hours) - Customer-facing, definitely needed
+5. ⏳ **End-to-End Workflow Test** (2-3 hours) - Definitely needed
+
+**Total remaining work:** 9-11 hours across 11 days
+
+**We have the time. The question is: what's the RIGHT work?**
+
+---
+
+## 🏗️ TRINITY CONSOLE - CURRENT STATE
+
+### What We Have (Deployed April 1, 2026)
+
+**Status:** ✅ 100% Functional - 7 modules operational
+
+**Architecture:**
+- Node.js + Express.js
+- PostgreSQL database
+- EJS templates + htmx + Tailwind CSS
+- Discord OAuth2 authentication
+- Trinity-only access (Michael, Meg, Holly)
+
+**7 Working Modules:**
+1. **Dashboard** - Stats overview (subscribers, MRR, server status)
+2. **Players** - Player/subscriber management, tier changes, staff status
+3. **Servers** - 12 game server monitoring, whitelist sync, toggle whitelist mode
+4. **Financials** - MRR, ARR, Fire vs Frost breakdown, tier performance
+5. **Grace Period** - Payment failure recovery, countdown timers, manual overrides
+6. **Audit Log** - Every admin action logged (who did what when)
+7. **Role Audit** - Discord role mismatch detection, bulk fixes
+
+**What it does:**
+- The Trinity manages all subscriber operations from web interface
+- Mobile-responsive (works on Meg's phone)
+- Real-time updates (htmx polling)
+- Integrates with Pterodactyl Panel, Discord API, PostgreSQL
+
+**URL:** https://discord-bot.firefrostgaming.com/admin
+
+**Current usage:** Works perfectly for development/testing. Ready for 10 subscribers.
+
+---
+
+## 🚨 THE 5 SECURITY GAPS (Current Blocker)
+
+### 1. CSRF Protection (30 min)
+**Problem:** No CSRF tokens on POST requests  
+**Risk:** Malicious site could trick admin into actions  
+**Mitigation:** Only 3 admins (Michael, Meg, Holly), all trusted  
+**Impact at 10 subscribers:** Very low (small attack surface)
+
+### 2. Database Transaction Safety (45 min)
+**Problem:** Multi-step operations not wrapped in BEGIN/COMMIT/ROLLBACK  
+**Risk:** Partial failures could corrupt data  
+**Example:** Tier change updates `subscriptions` table + audit log - if audit fails, subscriber still changed but no record  
+**Impact at 10 subscribers:** Low (can manually fix, low volume)
+
+### 3. Database Indexes (5 min)
+**Problem:** No indexes on `status`, `performed_at`, grace period fields  
+**Risk:** Slow queries at scale  
+**Impact at 10 subscribers:** None (queries will be instant)  
+**Impact at 500 subscribers:** Significant (slow admin pages)
+
+### 4. Ban Management UI (60 min)
+**Problem:** Can't view/manage chargeback bans via UI  
+**Current workaround:** Direct database access  
+**Impact at 10 subscribers:** Low (unlikely to have chargebacks in first 10)
+
+### 5. Email Integration (2-4 hours)
+**Problem:** Grace period recovery emails don't send automatically  
+**Current workaround:** Manual emails from Michael/Meg  
+**Impact at 10 subscribers:** Low (manageable manually)
+
+**Total time to fix:** 4-5 hours
+
+**Question for Gemini:** Are any of these ACTUALLY critical for 10 subscribers? Or can we defer safely?
+
+---
+
+## 🏗️ THE EXPANSION PLAN (April 2, 2026 Discussion)
+
+### What You Recommended (We Haven't Built Yet)
+
+**The Vision:** Complete operational platform for running Firefrost Gaming from RV
+
+**Phase 1: Foundations (9-13 hours)**
+
+**Foundation 1: Plugin/Module System** (4-6 hours)
+- Self-registering modules with `module.json` metadata
+- Drop folder → restart → works
+- Clean separation of concerns
+- Future-proof for third-party modules
+
+**Foundation 2: Role-Based Access Control** (3-4 hours)
+- Granular permissions (Owner, Moderator, Builder, Support)
+- Middleware: `requirePermission('tasks.edit')`
+- Navigation filtering by permission
+- Enable hiring staff without full admin access
+
+**Foundation 3: User Management UI** (2-3 hours)
+- Add users via Discord search
+- Assign roles
+- Suspend/reactivate
+- Activity audit trail
+
+**First Real Modules (Using New Foundations):**
+
+**Module 8: Tasks** (4-6 hours)
+- Team coordination for Michael, Meg, Holly
+- Assignments, status tracking, blockers
+- Mobile-first for Meg (primary phone user)
+- Replaces failed Git-based task tracking
+
+**Module 9: Infrastructure Dashboard** (2-4 hours)
+- Server inventory (TX1, NC1, VPS instances)
+- Service status tracking
+- Maintenance schedules
+- Health monitoring
+
+**Total Phase 1 Time:** 17-26 hours
+
+**Deferred to Post-Launch (Phase 2-3):**
+- Module 10: Operations Log (incidents, maintenance)
+- Module 11: Team Management (staff roster, availability)
+- Module 12: Support Tickets (post-launch)
+- Module 13: Community Dashboard (post-launch)
+
+---
+
+## 🤔 MICHAEL'S INSIGHT (The Decision Point)
+
+**Michael's thought:**
+
+> "If we're going to refactor Trinity Console to add plugin architecture + RBAC anyway, why fix security issues in the current architecture just to refactor it all in a few weeks? Why not build the foundations FIRST, then security gets built into the NEW architecture?"
+
+**The logic:**
+1. Current Trinity Console works fine for 10 subscribers
+2. Security fixes are "nice to have" at this scale, not critical
+3. Building foundations takes ~9-13 hours (similar to security fixes + unsubscribe + testing)
+4. Foundations unlock task management (Meg/Holly need this)
+5. Security fixes get done properly in new architecture (not retrofitted)
+6. Avoid doing work twice (fix now, then refactor later)
+
+**What we'd build instead:**
+- ✅ Plugin/Module System (4-6 hours)
+- ✅ RBAC Permissions (3-4 hours)
+- ✅ User Management UI (2-3 hours)
+- ✅ Tasks Module (4-6 hours) - Meg/Holly can finally manage work
+- ⏳ Unsubscribe UI (2-3 hours) - Still needed, customer-facing
+- ⏳ End-to-End Testing (2-3 hours) - Still needed
+
+**Security fixes:** Deferred to post-launch when we're refactoring anyway
+
+**Time investment:** ~17-26 hours vs ~9-11 hours (current blockers)
+
+**Trade-off:** Delay launch by 1 week BUT get proper foundations + task management operational team actually needs
+
+---
+
+## 🎯 THE CRITICAL QUESTIONS FOR YOU, GEMINI
+
+### Strategic Questions
+
+1. **Is this architectural debt we'll regret?**
+   - If we defer security fixes, will we create a security incident before we refactor?
+   - What's the actual risk level at 10 subscribers vs 100 vs 500?
+
+2. **Is Michael's logic sound?**
+   - Does it make sense to build foundations FIRST before security fixes?
+   - Or should we secure what we have, THEN expand?
+
+3. **What's the pragmatic path?**
+   - Launch April 15 with current Trinity Console (defer both fixes AND expansion)?
+   - Delay launch 1 week, build foundations + tasks properly?
+   - Fix security now, expand later (original plan)?
+   - Something else entirely?
+
+### Security-Specific Questions
+
+4. **CSRF at this scale:**
+   - Is CSRF protection actually critical with only 3 trusted admins?
+   - What attack vectors exist when Trinity Console is behind Discord OAuth?
+   - Can we launch without it for 10 subscribers?
+
+5. **Database transactions:**
+   - How likely are partial failures at low volume?
+   - Can we manually fix data corruption if it happens (first 10 subscribers)?
+   - Or is this a "you'll definitely corrupt data and regret it" situation?
+
+6. **Indexes:**
+   - At what subscriber count do missing indexes become painful?
+   - Can we add them later without downtime?
+   - Or should we add them now (5 minutes) regardless?
+
+7. **Ban management + Email:**
+   - Are these actually needed for soft launch?
+   - Or can we handle manually for first 10 subscribers?
+
+### Architectural Questions
+
+8. **Foundation timing:**
+   - Should foundations be built BEFORE any new features?
+   - Or is it okay to add Tasks module to current architecture and refactor later?
+
+9. **Refactoring difficulty:**
+   - How painful is it to migrate 7 existing modules to plugin architecture later?
+   - Is this a "do it right from the start" or "refactor when you need it" situation?
+
+10. **Plugin architecture necessity:**
+    - Do we NEED plugin system for 2-3 new modules?
+    - Or is this premature optimization?
+
+11. **RBAC necessity:**
+    - Do we NEED RBAC for 3-person team?
+    - When does this become critical (hiring first staff member)?
+
+### Timeline Questions
+
+12. **Launch timing:**
+    - Social campaign started April 2. Is delaying launch by 1 week acceptable?
+    - Or should we hit April 15 target no matter what?
+
+13. **Can we split the work?**
+    - Security fixes now (4-5 hours) → Launch April 15
+    - Foundations post-launch (build properly when we have real usage data)
+    - Or does this create more pain than doing it right from start?
+
+### Risk Assessment Questions
+
+14. **What's the biggest risk?**
+    - Security incident with 10 subscribers?
+    - Data corruption from missing transactions?
+    - Architectural debt from not building foundations?
+    - Missing April 15 launch window?
+    - Meg/Holly still can't manage tasks effectively?
+
+15. **What's the biggest regret?**
+    - In 6 months, what decision would we look back on and say "we should have done X"?
+
+16. **What happens if we're wrong?**
+    - If we defer security fixes and have an incident, what's the blast radius?
+    - If we delay launch and build foundations, what's the cost?
+
+---
+
+## 📊 COMPARISON TABLE
+
+| Approach | Time | Pros | Cons | Risk Level |
+|----------|------|------|------|------------|
+| **Option A: Security Fixes First** (Original Plan) | 9-11 hours | Hits April 15 launch, secures current system, lower immediate risk | Work gets redone during refactor, doesn't solve task management, Meg/Holly still blocked | Low security risk, high architectural debt |
+| **Option B: Foundations First** (Michael's Proposal) | 17-26 hours | Proper architecture, task management working, security built into new system, avoid rework | Delays launch 1 week, higher short-term security risk (10 subscribers) | Medium security risk (mitigated by small scale), low architectural debt |
+| **Option C: Launch As-Is** (Defer Everything) | 4-6 hours (just Unsubscribe + Testing) | Fastest to launch, validates market first, build based on real usage | Highest security risk, no task management, technical debt accumulates | Medium security risk, high operational friction (Meg/Holly blocked) |
+| **Option D: Hybrid** (Security fixes + Tasks only, defer full expansion) | 13-17 hours | Moderate timeline, basic security, task management working | Still refactoring later, partial solution, doesn't get full foundation benefits | Low security risk, medium architectural debt |
+
+---
+
+## 🌟 GEMINI - WHAT ARE WE NOT SEEING?
+
+**This is the most important question:**
+
+### The Blind Spots
+
+**Technical:**
+- Are we underestimating security risk at 10 subscribers?
+- Are we overestimating refactoring difficulty?
+- Is there a third option we're completely missing?
+
+**Operational:**
+- What breaks first with current architecture?
+- What do Meg and Holly ACTUALLY need to be effective?
+- Can we ship without task management for first month?
+
+**Strategic:**
+- Is April 15 launch date sacred or flexible?
+- Should we validate market before building more infrastructure?
+- Are we building when we should be testing?
+
+**RV Life Reality Check:**
+- What operational needs will we discover AFTER launch that we should build for NOW?
+- What breaks when you're managing 10 subscribers from a campground in Montana?
+
+### The Brutal Honesty Questions
+
+**Are we overthinking this?**
+- Should we just launch with what we have and build based on real needs?
+
+**Are we underthinking this?**
+- Is there a security disaster waiting to happen that we're downplaying?
+
+**What's the obvious answer we're missing?**
+- Sometimes the right path is so obvious you can't see it from inside the problem.
+
+**If you were running this business:**
+- What would YOU do?
+- What keeps YOU up at night about this decision?
+
+**What assumption are we making that's wrong?**
+- About security? About timelines? About what we need?
+
+---
+
+## 🎯 WHAT WE NEED FROM YOU
+
+**Your architectural perspective on:**
+
+1. **Security risk assessment** - Real risk at 10 subscribers vs our perception
+2. **Foundation timing** - Build now vs build later - which is less painful?
+3. **Pragmatic path** - Given 11 days and real constraints, what's the SMART move?
+4. **What we're missing** - Blind spots, risks, opportunities we don't see
+
+**Your honest opinion on:**
+
+1. Is Michael's logic sound or is he rationalizing technical debt?
+2. Are the security fixes actually critical or can we defer safely?
+3. Should we hit April 15 or delay for proper foundations?
+4. What would you do if this was your business?
+
+**Challenge our assumptions:**
+- If we're wrong, tell us WHY
+- If we're right, tell us what we're still missing
+- If there's a better path, SHOW US
+
+---
+
+## 🤝 OUR COMMITMENT
+
+**We will:**
+- Follow your architectural guidance (you haven't steered us wrong yet)
+- Make the pragmatic choice even if it's harder
+- Build for 10-year sustainability, not 10-day convenience
+
+**We won't:**
+- Rationalize technical debt if you say it's a bad idea
+- Skip security if you say it's critical
+- Rush to launch if foundations matter more
+
+**We trust you to tell us what we need to hear, not what we want to hear.**
+
+---
+
+## 📋 CONTEXT YOU MIGHT NEED
+
+**Team:**
+- 3 people (Michael, Meg, Holly)
+- All trusted, no external staff (yet)
+- Meg/Holly are non-technical
+- Michael has medical accommodations (structured workflow critical)
+
+**Scale:**
+- Soft launch: 10 subscribers
+- 6 months: ~50 subscribers
+- 18 months: ~500 subscribers (September 2027 target)
+- RV travel starts September 2027
+
+**Infrastructure:**
+- Command Center VPS (Trinity Console)
+- TX1 Dallas dedicated (game servers)
+- NC1 Charlotte dedicated (game servers)
+- Billing VPS (Paymenter, Mailcow)
+- Panel VPS (Pterodactyl)
+- Ghost VPS (website, wikis)
+
+**Budget:**
+- Bootstrapped (no external funding)
+- Revenue starts at launch
+- Can't afford security incidents (reputation = death)
+- Can't afford delays that miss market window
+
+**Previous Gemini guidance:**
+- You recommended unified architecture (Arbiter 3.0) ✅ Built
+- You validated Cloudflare Workers for website ✅ Deployed
+- You've consistently pushed us toward proper foundations
+- You've never steered us wrong
+
+---
+
+## 🔥 THE ASK
+
+**Gemini, be our architectural partner one more time.**
+
+Should we:
+1. Fix security now, expand later?
+2. Build foundations now, defer security?
+3. Launch as-is, build everything post-launch?
+4. Something else entirely?
+
+**Tell us what we're missing. Challenge our thinking. Show us the path.**
+
+We're 11 days from launch. This decision matters.
+
+What should we do?
+
+---
+
+**Fire + Frost + Foundation = Where Love Builds Legacy** 🔥❄️
+
+— Michael, Claude (Chronicler #57), and The Trinity
+
+---
+
+**P.S. - The Expansion Plan Documents:**
+
+For complete context, these documents contain the full expansion plan from April 2:
+- `docs/planning/gemini-consultations/trinity-console-expansion-2026-04-02.md` (856 lines)
+- `docs/planning/gemini-consultations/task-management-consultation-2026-04-01.md` (491 lines)
+
+**The Current Blocker:**
+- `BLOCKERS.md` (complete soft launch status)
+
+**Trinity Console Documentation:**
+- `docs/services/trinity-console.md` (641 lines)
+
+We can provide any additional context you need. Just ask.