diff --git a/docs/planning/dynamic-servers-page-implementation.md b/docs/planning/dynamic-servers-page-implementation.md
new file mode 100644
index 0000000..538ca30
--- /dev/null
+++ b/docs/planning/dynamic-servers-page-implementation.md
@@ -0,0 +1,588 @@
+# Dynamic Servers Page Implementation Plan
+
+**Created:** April 3, 2026  
+**Status:** Ready for Implementation  
+**Target Launch:** April 15, 2026 (12 days)  
+**Architecture:** Cloudflare Workers + Pterodactyl Client API
+
+---
+
+## Executive Summary
+
+**The Problem:**
+The Servers page is currently static HTML. Every time we add/remove/modify a Minecraft server, we must manually edit website code and redeploy. This is unsustainable for a hosting company.
+
+**The Solution:**
+Cloudflare Workers acting as a serverless proxy between the website and Pterodactyl Panel. The Worker fetches live server status from Pterodactyl's Client API, caches at the edge for 60 seconds, and serves JSON to the frontend. Zero manual updates required.
+
+**Why This Architecture:**
+- ✅ **Serverless:** No VPS to maintain (critical for RV travel!)
+- ✅ **Secure:** API keys hidden in Worker environment variables
+- ✅ **Fast:** Edge caching protects Pterodactyl from traffic spikes
+- ✅ **Free:** Cloudflare Workers free tier covers our needs
+- ✅ **RV-Ready:** Fully decoupled, graceful degradation if panel goes down
+
+---
+
+## Architecture Overview
+
+```
+User Browser
+    ↓
+firefrostgaming.com/servers (11ty static page)
+    ↓ (JavaScript fetch)
+Cloudflare Worker (https://servers-api.YOUR-WORKER.workers.dev)
+    ↓ (Server-side API call, API key hidden)
+Pterodactyl Client API (/api/client/servers)
+    ↓ (Returns server list + live status)
+Worker (caches for 60 seconds at edge)
+    ↓
+JSON response → Browser renders
+```
+
+**Key Insight from Gemini:**
+If 1,000 users hit the site simultaneously, the FIRST user triggers the Worker → Pterodactyl API call (400ms). The remaining 999 users get cached data from Cloudflare's edge in ~10ms. Pterodactyl only gets hit once per minute regardless of traffic!
+
+---
+
+## Critical Pterodactyl API Distinction
+
+### Two APIs, Two Purposes
+
+**Application API (Admin) - `ptla_` prefix:**
+- Used for administrative tasks
+- Lists ALL servers regardless of owner
+- **Cannot provide real-time player counts or live stats**
+- Good for: Trinity Panel monitoring, server creation/deletion
+
+**Client API (User-Facing) - `ptlc_` prefix:**
+- Used for end-user access
+- Only shows servers the user has access to
+- **Provides `/resources` endpoint with live stats**
+- Good for: Website status display, player counts
+
+**We need the Client API for the website!**
+
+---
+
+## Implementation Plan (12 Days)
+
+### Phase 1: Pterodactyl Setup (April 3-4)
+
+**Task 1.1: Check Existing API Key Type**
+```bash
+# Look at Trinity Panel API key
+# If it starts with ptla_ = Application API (wrong for this!)
+# If it starts with ptlc_ = Client API (perfect!)
+```
+
+**Task 1.2: Create Service Account**
+1. Log into Pterodactyl Admin panel (https://panel.firefrostgaming.com)
+2. Go to **Users** → Create new user:
+   - Username: `website-api`
+   - Email: `website-api@firefrostgaming.com`
+   - Password: (generate secure password)
+3. For EACH Minecraft server we want public:
+   - Go to **Servers** in Admin panel
+   - Click the server
+   - Go to **Subusers** tab
+   - Add `website-api@firefrostgaming.com`
+   - Grant ONLY these permissions:
+     * ✅ View Server
+     * ✅ View Server Statistics
+     * ❌ Everything else (no control permissions!)
+4. Log out of Admin account
+5. Log in as `website-api@firefrostgaming.com`
+6. Go to Account Settings → **API Credentials**
+7. Create new Client API key
+8. **SAVE THIS KEY!** It starts with `ptlc_`
+
+**Task 1.3: Standardize Server Descriptions**
+Update ALL Minecraft server descriptions in Pterodactyl to follow this format:
+```
+All The Mods 10 | v1.0.9
+Stoneblock 3 | v1.2.4
+Project Architect 2 | v2.0.1
+Society | v1.1.0
+Mythcraft | v2.3.1
+All The Mons | v1.0.5
+```
+
+**Format:** `Modpack Name | v[Version]`
+
+**Why pipe-delimited:**
+- Clean, readable in Pterodactyl UI
+- Easy JavaScript parsing: `const [name, version] = desc.split(' | ');`
+- No special characters that break JSON
+
+---
+
+### Phase 2: Local Development (April 4-6)
+
+**Task 2.1: Install Wrangler CLI**
+```bash
+npm install -g wrangler
+```
+
+**Task 2.2: Create Worker Project**
+```bash
+mkdir cloudflare-workers
+cd cloudflare-workers
+mkdir servers-api
+cd servers-api
+wrangler init
+```
+
+**Task 2.3: Create .dev.vars (Local Secrets)**
+Create file: `.dev.vars` in worker directory:
+```env
+PANEL_URL="https://panel.firefrostgaming.com"
+CLIENT_API_KEY="ptlc_YOUR_ACTUAL_KEY_HERE"
+```
+
+**IMPORTANT:** Add `.dev.vars` to `.gitignore` - NEVER commit secrets!
+
+**Task 2.4: Write Worker Code**
+See `cloudflare-worker-code.js` in this directory for complete code.
+
+Key features:
+- Fetches from Pterodactyl Client API `/api/client` endpoint
+- Gets live server list
+- For each server, fetches `/resources` endpoint for status
+- Returns JSON with server name, status, players, description
+- Handles CORS for firefrostgaming.com
+- Edge caching: 60 seconds
+- Graceful error handling if panel is down
+
+**Task 2.5: Test Locally**
+```bash
+wrangler dev
+# Worker runs at http://localhost:8787
+# Open browser, test endpoint
+# Verify JSON structure matches expectations
+```
+
+**Test cases:**
+- ✅ All servers listed
+- ✅ Online/Offline status correct
+- ✅ Player counts (if available)
+- ✅ Modpack names parsed correctly
+- ✅ CORS headers present
+- ✅ Error handling works (simulate panel down)
+
+---
+
+### Phase 3: Deploy to Production (April 7-9)
+
+**Task 3.1: Deploy Worker**
+```bash
+wrangler deploy
+```
+
+**Output will be:** `https://servers-api.YOUR-WORKER.workers.dev`
+
+**Task 3.2: Configure Production Secrets**
+```bash
+wrangler secret put PANEL_URL
+# Enter: https://panel.firefrostgaming.com
+
+wrangler secret put CLIENT_API_KEY
+# Paste the ptlc_ key
+```
+
+**Task 3.3: Test Production Worker**
+```bash
+curl https://servers-api.YOUR-WORKER.workers.dev
+# Should return JSON with all servers
+```
+
+**Task 3.4: Update Cloudflare Worker Settings**
+- Go to Cloudflare Dashboard → Workers
+- Click `servers-api`
+- Settings → Triggers → Add custom domain (optional): `api.firefrostgaming.com`
+- Verify CORS settings
+
+---
+
+### Phase 4: Frontend Integration (April 9-11)
+
+**Task 4.1: Update servers.njk**
+See `servers-page-frontend.html` in this directory for complete code.
+
+Key features:
+- Static HTML container
+- JavaScript fetches from Worker on page load
+- Renders server cards dynamically
+- "Pulse" animation for online status (Frost cyan)
+- Offline status in Fire orange
+- Player count display (if available)
+- Error handling with friendly message
+- Auto-refresh every 60 seconds
+
+**Task 4.2: Add Easy Wins**
+1. **Copy IP Button:**
+```javascript
+<button onclick="navigator.clipboard.writeText('atm10.firefrostgaming.com')">
+  Copy Server IP
+</button>
+```
+
+2. **Auto-Refresh:**
+```javascript
+setInterval(() => {
+  fetch(WORKER_URL).then(/* update UI */);
+}, 60000); // Every 60 seconds
+```
+
+**Task 4.3: Test on Preview**
+1. Commit changes to git
+2. Push to Gitea (auto-deploys to GitHub → Cloudflare Pages)
+3. Wait 60-90 seconds
+4. Test `https://firefrost-website.pages.dev/servers`
+5. Verify on multiple devices:
+   - Desktop (Firefox, Chrome)
+   - Mobile (Michael's phone, Meg's phone)
+   - Tablet
+
+**Test checklist:**
+- ✅ All servers display
+- ✅ Status indicators correct (green pulse = online, red = offline)
+- ✅ Player counts showing (if Pterodactyl provides them)
+- ✅ Copy IP buttons work
+- ✅ Auto-refresh updates without page reload
+- ✅ Mobile responsive (no horizontal scroll!)
+- ✅ Error message displays if Worker fails
+- ✅ Loading state shows during fetch
+
+---
+
+### Phase 5: Monitoring Setup (April 11-12)
+
+**Task 5.1: Uptime Kuma Monitoring**
+1. Log into Uptime Kuma (Command Center)
+2. Add new monitor:
+   - Name: "Servers API Worker"
+   - Type: HTTP(s)
+   - URL: `https://servers-api.YOUR-WORKER.workers.dev`
+   - Interval: 120 seconds (2 minutes)
+   - Retries: 3
+3. Set up Discord notification:
+   - Webhook URL: (Trinity Discord channel)
+   - Alert on: Down, Error, Recovery
+
+**Task 5.2: Worker Error Webhook (Optional)**
+Add Discord webhook to Worker error handler:
+```javascript
+catch (error) {
+  // Alert Discord that Worker failed
+  fetch('https://discord.com/api/webhooks/YOUR_WEBHOOK', {
+    method: 'POST',
+    headers: { 'Content-Type': 'application/json' },
+    body: JSON.stringify({
+      content: '🚨 Servers API Worker failed to reach Pterodactyl Panel!'
+    })
+  });
+  
+  // Return graceful error to users
+  return new Response(JSON.stringify({
+    error: "Servers temporarily unreachable",
+    servers: []
+  }), { status: 500 });
+}
+```
+
+**Task 5.3: Cloudflare Analytics**
+1. Go to Cloudflare Dashboard → Workers → servers-api
+2. View Analytics tab
+3. Monitor:
+   - Request count
+   - Error rate
+   - CPU time usage
+   - P95 response time
+
+**Target metrics:**
+- Error rate: <1%
+- Response time: <500ms
+- CPU time: <5ms (network time doesn't count)
+
+---
+
+### Phase 6: DNS Cutover (April 14)
+
+**CRITICAL: Do NOT attempt DNS cutover until Servers page tested thoroughly on preview!**
+
+**Pre-Flight Checklist:**
+- ✅ Cloudflare Worker deployed and tested
+- ✅ servers.njk updated and tested on preview
+- ✅ All 7 pages working on firefrost-website.pages.dev
+- ✅ Mobile responsive verified
+- ✅ Uptime Kuma monitoring active
+- ✅ Discord alerts tested
+- ✅ Michael + Meg + Holly have reviewed site
+- ✅ Paymenter subscription links verified
+- ✅ /discord redirect working
+
+**DNS Cutover Steps:**
+1. Log into Cloudflare Dashboard
+2. Go to Workers & Pages → firefrost-website
+3. Settings → Domains → Add custom domain
+4. Enter: `firefrostgaming.com`
+5. Cloudflare provisions SSL certificate (1-5 minutes)
+6. Wait for edge network propagation (5-15 minutes)
+7. Test: Visit `https://firefrostgaming.com`
+8. Verify all pages load correctly
+9. Check Servers page specifically
+
+**Expected "routing weirdness" (Gemini's warning):**
+- First 5-15 minutes: Some users may see old Ghost site, some see new 11ty site
+- After 15 minutes: All users see new site
+- This is normal edge network propagation
+
+**Rollback Plan (if needed):**
+1. Remove custom domain from Cloudflare Pages
+2. Old Ghost site becomes active again
+3. Debug issue
+4. Try cutover again when ready
+
+---
+
+## Player Count Nuance (Important!)
+
+**From Gemini:**
+> The Client API does return a `players` integer under `attributes.resources.players`. However, Pterodactyl's Wings daemon gets this number by passively querying the Minecraft server. For heavily modded servers (like ATM10), the server query port sometimes hangs or reports 0 even when players are online.
+
+**Strategy:**
+1. **MVP (Launch):** Show player counts IF Pterodactyl provides them
+2. **Monitor:** Watch for false zeros (server shows "0 players" but you know people are online)
+3. **If unreliable:** Remove player count display post-launch
+4. **DO NOT:** Try to build custom RCON/Query proxy 12 days before launch
+
+**Keep it simple:** Online/Offline status is the MVP. Player counts are a nice-to-have.
+
+---
+
+## Server Naming Convention (Enforced Standard)
+
+**Format:** `Modpack Name | v[Version]`
+
+**Examples:**
+```
+All The Mods 10 | v1.0.9
+Stoneblock 3 | v1.2.4
+Project Architect 2 | v2.0.1
+Society | v1.1.0
+Mythcraft | v2.3.1
+All The Mons | v1.0.5
+```
+
+**JavaScript parsing:**
+```javascript
+const description = "All The Mods 10 | v1.0.9";
+const [modpackName, version] = description.split(' | ');
+// modpackName = "All The Mods 10"
+// version = "v1.0.9"
+```
+
+**Where to store:** Pterodactyl Server Description field (visible in Client API)
+
+**Maintenance:** When adding new servers, Michael MUST follow this format for automatic website updates!
+
+---
+
+## Caching Strategy
+
+**Cache-Control Header:**
+```javascript
+'Cache-Control': 'public, s-maxage=60, max-age=60'
+```
+
+**What this means:**
+- `public`: Anyone can cache this
+- `s-maxage=60`: Cloudflare Edge caches for 60 seconds
+- `max-age=60`: User's browser caches for 60 seconds
+
+**Traffic pattern example:**
+```
+Time 00:00 - User A visits → Worker executes → Pterodactyl queried → Result cached
+Time 00:15 - User B visits → Cloudflare Edge returns cached data (no Worker execution!)
+Time 00:30 - User C visits → Cloudflare Edge returns cached data (no Worker execution!)
+Time 00:45 - User D visits → Cloudflare Edge returns cached data (no Worker execution!)
+Time 01:01 - User E visits → Cache expired → Worker executes → Pterodactyl queried → New cache
+```
+
+**Result:** Pterodactyl only gets hit ONCE per minute, regardless of website traffic!
+
+**Why 60 seconds is acceptable:**
+Minecraft server status doesn't change rapidly. If a server goes down, users will see the old "Online" status for up to 60 seconds max. This is totally fine for this use case.
+
+---
+
+## Future Enhancements (Post-Launch)
+
+### ✅ Easy Wins (Add These!)
+1. **Copy IP Button** - One line of JavaScript
+2. **Auto-Refresh** - `setInterval` every 60 seconds
+3. **Status Pulse Animation** - CSS keyframe already provided
+
+### ⚠️ Possible But Complex
+1. **Modpack logos** - Would need image hosting, careful sizing
+2. **Server tags** - Requires Pterodactyl custom fields
+3. **"Last seen online"** - Requires tracking state changes
+
+### ❌ Architectural Nightmares (Skip!)
+1. **Historical uptime tracking** - Needs database (kills static site)
+2. **Live console output** - Security risk + WebSocket complexity
+3. **Custom RCON integration** - Over-engineering for MVP
+
+**Philosophy:** Ship the MVP. Add features iteratively after launch based on actual user feedback.
+
+---
+
+## Security Considerations
+
+### API Key Protection
+- ✅ Client API key stored in Cloudflare Worker environment variables
+- ✅ Never exposed to browser
+- ✅ `.dev.vars` file in `.gitignore`
+- ✅ Service Account has minimal permissions (read-only)
+
+### CORS Configuration
+- ✅ Only allows `https://firefrostgaming.com` origin
+- ✅ Rejects requests from other domains
+- ✅ Handles OPTIONS preflight requests
+
+### Rate Limiting
+- ✅ Edge caching prevents API abuse
+- ✅ Pterodactyl only hit once per minute max
+- ✅ No user can DOS the panel through the website
+
+### Error Disclosure
+- ✅ Generic error messages to users ("Servers temporarily unreachable")
+- ❌ Never expose API endpoints or keys in error messages
+- ✅ Detailed errors logged to Cloudflare Analytics only
+
+---
+
+## RV Travel Considerations
+
+**Why this architecture works for remote operation:**
+
+1. **Zero VPS dependencies:** Worker is serverless, no SSH needed
+2. **Automatic recovery:** If panel goes down temporarily, Worker error handling keeps site usable
+3. **Push notifications:** Discord webhooks alert Michael/Meg immediately
+4. **Edge monitoring:** Uptime Kuma on Command Center watches Worker health
+5. **Simple troubleshooting:** Only 3 moving parts (Worker, Pterodactyl, Frontend)
+
+**Troubleshooting from the road:**
+- Panel down? Uptime Kuma + Discord alert
+- Worker failing? Cloudflare Dashboard shows errors
+- Website broken? Cloudflare Pages deployment logs
+- All accessible via phone/tablet over cellular!
+
+---
+
+## Timeline & Milestones
+
+**April 3 (Today):**
+- ✅ Check existing API key type
+- ✅ Create Service Account in Pterodactyl
+- ✅ Standardize server descriptions
+
+**April 4-6 (Weekend):**
+- ✅ Install Wrangler CLI
+- ✅ Build Worker locally
+- ✅ Test with real Pterodactyl API
+
+**April 7-9:**
+- ✅ Deploy Worker to production
+- ✅ Configure secrets
+- ✅ Test Worker endpoint
+
+**April 9-11:**
+- ✅ Update servers.njk frontend
+- ✅ Add Copy IP + Auto-refresh features
+- ✅ Test on preview extensively
+
+**April 11-12:**
+- ✅ Set up Uptime Kuma monitoring
+- ✅ Configure Discord alerts
+- ✅ Final QA testing
+
+**April 14:**
+- ✅ Pre-flight checklist verification
+- ✅ DNS cutover to firefrostgaming.com
+- 🎉 **SOFT LAUNCH!**
+
+**April 15:**
+- Buffer day for unexpected issues
+- Monitor analytics closely
+- Celebrate! 🔥⚡❄️
+
+---
+
+## Success Metrics (Post-Launch)
+
+**Week 1 (April 15-21):**
+- Worker uptime: >99%
+- Page load time: <2 seconds
+- Error rate: <1%
+- Zero manual server list updates needed
+
+**Month 1 (April-May):**
+- Player count accuracy verified
+- Auto-refresh working smoothly
+- Mobile traffic analytics reviewed
+- User feedback collected (Discord)
+
+**Long-term:**
+- Add/remove servers without touching website code
+- Update modpack versions by changing Pterodactyl description only
+- Infrastructure "just works" from anywhere in the USA
+
+---
+
+## Contacts & Resources
+
+**Gemini AI Consultation:**
+- Session 1: Initial architecture recommendation (Cloudflare Workers)
+- Session 2: Implementation details and Q&A
+- Both consultations saved in `docs/planning/gemini-servers-consultation/`
+
+**Cloudflare Resources:**
+- Workers Dashboard: https://dash.cloudflare.com/workers
+- Wrangler Docs: https://developers.cloudflare.com/workers/wrangler/
+- Workers Examples: https://workers.cloudflare.com/examples
+
+**Pterodactyl Resources:**
+- API Documentation: https://dashflo.net/docs/api/pterodactyl/v1/
+- Client API Endpoints: /api/client, /api/client/servers/{id}/resources
+- Panel URL: https://panel.firefrostgaming.com
+
+**Team:**
+- Michael "Frostystyle" - Technical implementation
+- Claude (Chronicler #56) - Documentation and pair programming
+- Gemini AI - Architectural guidance and code review
+- Butter No Nutters - CEO approval (royal seal granted! 😺👑)
+
+---
+
+## Conclusion
+
+This implementation transforms the Servers page from a static, manually-maintained list into a **living, self-updating system** that reflects reality automatically. When we add a new Minecraft server, we:
+
+1. Create it in Pterodactyl
+2. Add Service Account as subuser
+3. Set description to `Modpack Name | vX.Y.Z`
+4. **DONE!** Website updates automatically within 60 seconds.
+
+Zero code changes. Zero deployments. Zero manual updates.
+
+**That's the vision:** Build it once, run it forever.
+
+**Fire + Frost + Foundation = Where Love Builds Legacy** 💙
+
+---
+
+**Document Status:** Complete and ready for implementation  
+**Last Updated:** April 3, 2026  
+**Next Review:** April 15, 2026 (post-launch retrospective)
diff --git a/docs/planning/gemini-servers-consultation/01-initial-consultation.md b/docs/planning/gemini-servers-consultation/01-initial-consultation.md
new file mode 100644
index 0000000..83ca0c3
--- /dev/null
+++ b/docs/planning/gemini-servers-consultation/01-initial-consultation.md
@@ -0,0 +1,463 @@
+# Gemini Consultation: Dynamic Servers Page with Pterodactyl API Integration
+
+Hey Gemini! 👋
+
+We're in the home stretch of the Firefrost Gaming website migration and could really use your architectural wisdom on a technical challenge. This is literally the **last piece before DNS cutover** from Ghost CMS to our new 11ty static site on Cloudflare Pages!
+
+## Context: Where We Are Right Now
+
+We just completed a **massive website migration** in record time:
+
+**What We've Built:**
+- Migrated from Ghost CMS to 11ty static site generator
+- All 7 pages complete: Homepage, Subscribe, About, Contact, Privacy, Terms, Servers
+- Deployed to Cloudflare Pages at `firefrost-website.pages.dev`
+- Auto-deploy chain: Gitea → GitHub mirror → Cloudflare Pages (~60-90 seconds)
+- Fire/Frost/Arcane branding throughout with Simple Icons for social media
+- Trinity artwork, Six Consultants (animals!), complete subscription tier system
+
+**Pages Status:**
+- ✅ Homepage - Fire/Frost background, origin story, community stats
+- ✅ Subscribe - All 6 tiers (Awakened $1 → Sovereign $50) with Paymenter integration
+- ✅ About - Trinity founders + Six animal consultants (Butter, Oscar, Jack, Skye, Jasmine, Noir)
+- ✅ Contact - Discord/Email/Social with official brand icons, `/discord` redirect page
+- ✅ Privacy - Effective April 1, 2026, GDPR/COPPA compliant
+- ✅ Terms - Effective April 1, 2026, "We Don't Kick People Out" philosophy
+- ❓ **Servers - THE PROBLEM WE NEED TO SOLVE**
+
+**DNS Cutover Plan:**
+Once Servers page is done, we point `firefrostgaming.com` to Cloudflare Pages and GO LIVE!
+
+---
+
+## The Problem: Static Servers Page vs Dynamic Reality
+
+**Current Situation:**
+The `servers.njk` page is **static** - it's hardcoded HTML that lists our Minecraft servers. Every time we:
+- Add a new server
+- Remove a server
+- Change a server name/description
+- Update modpack versions
+
+...we have to **manually edit the website code** and redeploy. This is unsustainable for a hosting company!
+
+**What We Need:**
+A **dynamic Servers page** that:
+1. **Auto-discovers** what Minecraft servers are actually running
+2. **Shows real-time status** (up/down with visual indicators)
+3. **Updates automatically** when servers are added/removed
+4. **Requires zero manual code changes** when infrastructure changes
+
+---
+
+## Our Infrastructure (The Good News!)
+
+**We Already Have Everything We Need:**
+
+### Pterodactyl Panel (Panel VPS: 45.94.168.138)
+- **Version:** v1.12.1 with Blueprint extension framework
+- **Manages:** 13+ active Minecraft servers across two dedicated machines
+- **API Available:** Yes! Full Pterodactyl API with endpoints for:
+  - List all servers
+  - Get server status (running/stopped/starting)
+  - Get server details (name, description, resource usage)
+  - Get player counts (if we want to show "5/100 players online")
+
+### Server Fleet
+- **TX1 Dallas** (38.68.14.26, 251GB RAM) - Pterodactyl Wings, ~7 servers
+- **NC1 Charlotte** (216.239.104.130, 251GB RAM) - Pterodactyl Wings, ~6 servers
+- **Command Center** (63.143.34.217, Dallas) - Could host backend proxy if needed
+
+### Tech Stack
+- **Frontend:** 11ty static site → Cloudflare Pages
+- **No backend currently** (static site!)
+- **Git workflow:** Gitea (primary) → GitHub (mirror) → Cloudflare (auto-deploy)
+
+---
+
+## The Challenge: Static Site + Dynamic Data
+
+Here's the architectural tension:
+
+**11ty + Cloudflare Pages = Static Site**
+- No server-side processing at runtime
+- Just HTML/CSS/JS served from CDN edge
+- Super fast, but how do we get dynamic data?
+
+**Pterodactyl API = Dynamic Data Source**
+- Has all the server info we need
+- Requires API authentication
+- Real-time status updates
+
+**How do we bridge this gap?**
+
+---
+
+## Options We've Discussed (Need Your Guidance!)
+
+### **Option 1: Client-Side API Fetch (Simplest)**
+
+**How it works:**
+1. Servers page loads static HTML
+2. JavaScript runs in browser
+3. Fetches directly from Pterodactyl API
+4. Renders server list dynamically
+
+**Example Code:**
+```javascript
+// On page load
+fetch('https://panel.firefrostgaming.com/api/application/servers', {
+  headers: {
+    'Authorization': 'Bearer API_KEY_HERE',
+    'Accept': 'application/json'
+  }
+})
+.then(res => res.json())
+.then(data => {
+  // Filter for Minecraft servers only
+  // Render with status indicators
+  // Show player counts
+});
+```
+
+**Pros:**
+- Simple! Just add JavaScript to the page
+- No new infrastructure needed
+- Real-time updates on every page load
+
+**Cons:**
+- **API key exposed in browser** (anyone can see it in DevTools!)
+- **CORS issues** (Pterodactyl API needs to allow firefrostgaming.com origin)
+- **Security risk** (API key in client-side code = bad practice)
+
+**Questions for You:**
+- Is there a way to make this secure without exposing the API key?
+- Could we use read-only API scope to limit damage?
+- What's the CORS configuration process for Pterodactyl?
+
+---
+
+### **Option 2: Backend Proxy Service (More Secure)**
+
+**How it works:**
+1. Build small Node.js/Python service on Command Center
+2. Service fetches from Pterodactyl API server-side (API key stays secret!)
+3. Exposes public JSON endpoint: `https://api.firefrostgaming.com/servers`
+4. Website JavaScript fetches from OUR endpoint (no API key needed)
+5. Can add caching, rate limiting, filtering
+
+**Example Architecture:**
+```
+Browser → https://firefrostgaming.com/servers
+  ↓ (JavaScript fetch)
+https://api.firefrostgaming.com/servers (our proxy)
+  ↓ (server-side, API key hidden)
+Pterodactyl API → returns server data
+  ↓ (proxy filters/formats)
+JSON response → browser renders
+```
+
+**Proxy Could Provide:**
+```json
+{
+  "servers": [
+    {
+      "name": "ATM10 - All The Mods 10",
+      "status": "running",
+      "players": "5/100",
+      "modpack": "All The Mods 10",
+      "version": "1.0.9",
+      "uptime": "99.8%",
+      "color": "#4ecdc4"
+    }
+  ]
+}
+```
+
+**Pros:**
+- **Secure!** API key never exposed to browser
+- Can cache results (faster page loads, less API strain)
+- Can transform data (add custom fields, filter sensitive info)
+- Rate limiting to prevent abuse
+- Could aggregate from multiple sources later
+
+**Cons:**
+- New infrastructure to maintain (Node.js app, systemd service)
+- Need to configure Nginx reverse proxy
+- More moving parts
+- Still need CORS headers (but on OUR endpoint we control)
+
+**Questions for You:**
+- What's the lightest-weight way to build this proxy?
+- Should we use Express.js, Fastify, or something even simpler?
+- Caching strategy: Redis, in-memory, or file-based?
+- Where should it live: Command Center, Ghost VPS, or new VPS?
+
+---
+
+### **Option 3: Build-Time Generation (Static + Cron)**
+
+**How it works:**
+1. Cron job runs daily on Command Center
+2. Fetches from Pterodactyl API
+3. Generates `servers.json` file
+4. Commits to git repo
+5. Cloudflare Pages auto-rebuilds site
+
+**Pros:**
+- No runtime API calls (fast page loads!)
+- API key stays server-side
+- Simple architecture
+
+**Cons:**
+- **Not real-time** (could be 24 hours out of date!)
+- No live up/down status indicators
+- Defeats the whole purpose if we want "real-time" updates
+
+**Our Take:**
+This doesn't solve the core problem - we want LIVE status, not yesterday's status.
+
+---
+
+## What We're Leaning Toward (But Need Your Input!)
+
+**Michael and I discussed this and we think Option 2 (Backend Proxy) is the winner, but we want your thoughts on:**
+
+### 1. **Architecture Questions**
+- Is a backend proxy overkill for this? Or exactly right?
+- Could we use Cloudflare Workers instead of a traditional backend? (They run at the edge!)
+- What's the simplest tech stack for the proxy?
+
+### 2. **Security Questions**
+- How do we properly secure the Pterodactyl API key?
+- Read-only API scope sufficient, or need more restrictions?
+- CORS configuration best practices?
+- Rate limiting to prevent abuse of our public endpoint?
+
+### 3. **Performance Questions**
+- How often should we cache server status? (30 seconds? 5 minutes?)
+- Redis vs in-memory vs no caching?
+- What happens if Pterodactyl API is slow/down? (Fallback strategy?)
+
+### 4. **Maintainability Questions**
+- Should this proxy live in the same git repo as the website, or separate?
+- Monitoring/alerting if proxy goes down?
+- How do we handle Pterodactyl API version changes?
+
+---
+
+## Alternative Idea: Cloudflare Workers? 🤔
+
+**Just thought of this:**
+Could we use **Cloudflare Workers** as the proxy? They:
+- Run at Cloudflare's edge (same infrastructure as our site!)
+- Can make fetch requests to Pterodactyl API
+- Can cache responses
+- Serverless (no VPS to maintain!)
+- Billed on requests (probably free tier for our traffic)
+
+**Would this work?**
+```javascript
+// Cloudflare Worker
+export default {
+  async fetch(request) {
+    // Fetch from Pterodactyl API
+    const response = await fetch('https://panel.firefrostgaming.com/api/...', {
+      headers: { 'Authorization': 'Bearer SECRET_KEY' }
+    });
+    
+    // Cache for 60 seconds
+    const data = await response.json();
+    
+    // Return to frontend
+    return new Response(JSON.stringify(data), {
+      headers: {
+        'Content-Type': 'application/json',
+        'Access-Control-Allow-Origin': 'https://firefrostgaming.com',
+        'Cache-Control': 'max-age=60'
+      }
+    });
+  }
+}
+```
+
+**Pros:**
+- No new VPS infrastructure!
+- Runs at Cloudflare edge (fast!)
+- Secrets stored in Worker environment vars (secure!)
+- Automatic scaling
+- Free tier likely covers our needs
+
+**Cons:**
+- Cloudflare Workers have 10ms CPU time limit (is that enough?)
+- Learning curve if we haven't used Workers before
+- Debugging might be trickier than traditional backend
+
+**What do you think about this approach?**
+
+---
+
+## Specific Technical Questions We Need Help With
+
+### 1. **Pterodactyl API Details**
+We haven't fully explored the Pterodactyl API yet. Can you help us understand:
+- What endpoints do we need? (`/api/application/servers` for list?)
+- How do we filter for ONLY Minecraft servers (not other game types)?
+- Can we get real-time player counts? Or just online/offline status?
+- Rate limits on the API?
+- API key scopes (read-only vs full access)?
+
+### 2. **Frontend Implementation**
+Once we have the data endpoint, how should the frontend look?
+
+**Current Static Servers Page Structure:**
+```html
+<!-- Grid of server cards -->
+<div class="server-card">
+  <h3>ATM10 - All The Mods 10</h3>
+  <p>Modpack: All The Mods 10 v1.0.9</p>
+  <p>Server IP: atm10.firefrostgaming.com</p>
+  <span class="status-badge">Online</span>
+</div>
+```
+
+**Should we:**
+- Keep the same visual design, just populate dynamically?
+- Add new features like player count badges?
+- Live "pulse" animation on status indicators?
+- "Last updated: 30 seconds ago" timestamp?
+
+### 3. **Error Handling**
+What happens when:
+- Pterodactyl API is down?
+- API returns error?
+- Network timeout?
+
+**Should we:**
+- Show cached "last known good" data with warning?
+- Show error message to users?
+- Fall back to static list?
+
+### 4. **RV Travel Consideration (IMPORTANT!)**
+Michael and Meg's long-term vision: **Run Firefrost Gaming from an RV while traveling the USA.**
+
+This means:
+- Infrastructure must be REMOTE MANAGEABLE
+- Can't rely on being physically near servers
+- Monitoring and auto-recovery essential
+
+**Does this change your recommendation?**
+- Need robust error handling?
+- Monitoring/alerting more important?
+- Simpler = better for remote troubleshooting?
+
+---
+
+## Our Constraints & Requirements
+
+### **Must Haves:**
+1. **Zero manual updates** when servers change
+2. **Real-time status indicators** (green = up, red = down)
+3. **Secure** (no API key exposure)
+4. **Fast** (page loads in <2 seconds)
+5. **Minecraft servers only** (filter out any non-Minecraft)
+6. **Mobile responsive** (works on phone)
+
+### **Nice to Haves:**
+1. Player count display ("5/100 players online")
+2. Uptime percentage
+3. Server version/modpack info
+4. Smooth animations/transitions
+5. Auto-refresh without page reload
+
+### **Constraints:**
+1. **No database** (static site, keep it simple)
+2. **Minimal new infrastructure** (prefer leveraging existing or Cloudflare)
+3. **Maintainable by one person remotely** (RV travel!)
+4. **Budget-conscious** (avoid expensive cloud services)
+
+---
+
+## What We Need From You, Gemini
+
+**Your Mission (If You Choose to Accept It!):**
+
+1. **Recommend the best architecture** (Client-side? Proxy? Cloudflare Workers? Something else?)
+2. **Provide implementation steps** (what do we build, where does it live, how does it work?)
+3. **Security best practices** (how to handle API keys, CORS, rate limiting)
+4. **Code examples** (if you can provide starter code, even better!)
+5. **Gotchas to watch for** (what will bite us if we're not careful?)
+
+**Bonus Points For:**
+- Cloudflare Workers example code (if that's the recommendation)
+- Pterodactyl API documentation links/tips
+- Caching strategy recommendations
+- Monitoring/alerting suggestions
+
+---
+
+## Timeline & Next Steps
+
+**Where We Are:**
+- Website migration 95% complete
+- Only Servers page needs this dynamic solution
+- DNS cutover waiting on this completion
+
+**Target:**
+- Soft launch April 15, 2026 (12 days away!)
+- Need to start implementing ASAP
+
+**After Your Guidance:**
+1. Michael reviews your recommendation
+2. We implement the solution (Claude + Michael pair programming)
+3. Test thoroughly
+4. DNS cutover to make firefrostgaming.com LIVE!
+5. 🎉 Celebrate! 🎉
+
+---
+
+## Why This Matters
+
+This isn't just a technical problem - it's about **building infrastructure that outlives us.**
+
+Michael's vision: "For children not yet born."
+
+A static servers page that requires manual updates every time infrastructure changes? That's fragile. That doesn't scale. That doesn't honor the vision.
+
+A dynamic, self-updating system that **just works** no matter what servers are running? That's the foundation we need.
+
+**Help us build something legendary, Gemini.** 🔥⚡❄️
+
+---
+
+## Current Tech Stack Summary (For Reference)
+
+**Infrastructure:**
+- Pterodactyl Panel v1.12.1 (45.94.168.138)
+- TX1 Dallas dedicated (38.68.14.26, 251GB RAM, Pterodactyl Wings)
+- NC1 Charlotte dedicated (216.239.104.130, 251GB RAM, Pterodactyl Wings)
+- Command Center VPS (63.143.34.217, Gitea, Uptime Kuma, automation)
+- Ghost VPS (64.50.188.14, Ghost CMS being phased out, Wiki.js, Nextcloud)
+
+**Website:**
+- 11ty static site generator
+- Hosted on Cloudflare Pages
+- Auto-deploy: Gitea → GitHub → Cloudflare Pages
+- Fire/Frost/Arcane branding (#FF6B35, #4ECDC4, #A855F7)
+
+**Minecraft Servers:**
+- 13+ active servers across TX1 Dallas and NC1 Charlotte
+- Mix of popular modpacks (ATM series, Stoneblock, custom packs)
+- All managed via Pterodactyl Panel
+
+---
+
+## Thank You!
+
+We're so close to launch, Gemini! Your architectural wisdom here will make or break our ability to ship on time.
+
+Looking forward to your thoughts, recommendations, and any code examples you can share!
+
+Fire + Frost + Foundation = Where Love Builds Legacy 💙
+
+— Michael "Frostystyle" (The Wizard) & Claude (Chronicler #56)
diff --git a/docs/planning/gemini-servers-consultation/02-followup-questions.md b/docs/planning/gemini-servers-consultation/02-followup-questions.md
new file mode 100644
index 0000000..4cd2bd5
--- /dev/null
+++ b/docs/planning/gemini-servers-consultation/02-followup-questions.md
@@ -0,0 +1,252 @@
+# Follow-Up: Cloudflare Workers Implementation Questions
+
+Hey Gemini! 🙏
+
+**THANK YOU!** That architectural blueprint is *exactly* what we needed. You absolutely nailed it - Cloudflare Workers with the Service Account pattern is the perfect solution. The way you broke down the Pterodactyl API gotcha (Application vs Client API) saved us from what would have been hours of frustrating debugging. Seriously, that "Aha!" confirmation and the complete code examples are gold.
+
+We're ready to implement this before our April 15 soft launch, but we have a few technical clarification questions before we dive in. Your guidance has been spot-on so far, so we want to make sure we get the implementation details right!
+
+---
+
+## Question 1: Existing API Key - Which Type Do We Have?
+
+**Context:**
+You mentioned Pterodactyl has two different APIs (Application API vs Client API). We already have an API key that our Trinity Panel monitoring system uses to check server status.
+
+**Our Question:**
+How do we determine if our existing API key is an Application API key or a Client API key? Is there a way to check this in the Pterodactyl panel, or can we tell from the key format itself?
+
+**Follow-up:**
+If it turns out to be the wrong type (Application API instead of Client API), can you walk us through the exact steps to:
+1. Create the "Service Account" dummy user in Pterodactyl
+2. Add it as a subuser to only our Minecraft servers
+3. Generate the Client API key for that account
+
+We want to make sure we're using the right API from the start!
+
+---
+
+## Question 2: Player Count - Does Client API Actually Provide This?
+
+**Context:**
+In your Worker code example, you reference:
+```javascript
+players: isRunning ? stats.attributes?.resources?.players ? `${stats.attributes.resources.players} Online` : '0 Online' : '-'
+```
+
+**Our Question:**
+Does Pterodactyl's Client API `/resources` endpoint **actually** return real-time player counts for Minecraft servers? Or does it only return CPU/RAM/network stats?
+
+**Why we're asking:**
+We've seen some documentation suggesting that Pterodactyl doesn't natively track Minecraft player counts - that you'd need to query the Minecraft server directly via RCON or the Query protocol. We want to understand:
+
+1. **If Pterodactyl DOES provide player counts:** Awesome! We're good to go with your code.
+2. **If Pterodactyl DOESN'T provide player counts:** Should we:
+   - Remove player count display from the initial version?
+   - Add a separate query to each Minecraft server (via Query protocol on port 25565)?
+   - Or is there another way to get this data through Pterodactyl?
+
+Real-time player counts would be amazing for the website ("5/100 players online"), but we don't want to overcomplicate the initial implementation if it requires additional infrastructure.
+
+---
+
+## Question 3: Modpack/Version Naming Convention
+
+**Context:**
+You mentioned we can parse modpack and version info from `server.attributes.description` if we enforce a naming convention.
+
+**Our Current Situation:**
+Right now, our Pterodactyl server descriptions are probably inconsistent - some might say "ATM10", others might have longer descriptions, etc.
+
+**Our Question:**
+Can you recommend a **specific naming convention** we should standardize on? Something that's:
+- Easy to parse with JavaScript regex or string splitting
+- Human-readable in the Pterodactyl panel
+- Includes the key info we want to display (modpack name, version)
+
+**Example options we're considering:**
+- `"ATM10 v1.0.9 - All The Mods 10"` (modpack code, version, full name)
+- `"[ATM10][1.0.9] All The Mods 10"` (bracketed metadata)
+- `"All The Mods 10 | v1.0.9 | Minecraft 1.21.1"` (pipe-delimited)
+
+What format would you recommend that's both robust for parsing and easy for Michael to maintain when adding new servers?
+
+**Bonus question:**
+Should we store this in the description field, or does Pterodactyl have a better place for custom metadata (like tags or custom fields)?
+
+---
+
+## Question 4: Testing Cloudflare Workers Locally
+
+**Context:**
+We want to test the Worker code thoroughly before deploying to production and pointing our live website at it.
+
+**Our Question:**
+What's the best way to test this Cloudflare Worker during development? Specifically:
+
+1. **Wrangler CLI:** Should we install Wrangler and use `wrangler dev` to test locally?
+2. **Environment variables:** How do we simulate the `env.PANEL_URL` and `env.CLIENT_API_KEY` during local testing?
+3. **Testing CORS:** How can we verify that CORS headers work correctly before going live?
+4. **Mocking the API:** Is there a way to mock Pterodactyl API responses for faster testing, or should we just test against our real panel?
+
+**What we want to avoid:**
+Deploying a broken Worker to production and having our Servers page fail on launch day. We'd rather catch issues in development!
+
+**Michael's testing style:**
+He's very thorough and likes to test edge cases:
+- What if the panel is slow to respond?
+- What if a server is in "starting" state (not running, not stopped)?
+- What if the API returns malformed JSON?
+
+Any guidance on testing strategies would be super helpful!
+
+---
+
+## Question 5: Monitoring & Observability
+
+**Context:**
+This Cloudflare Worker will be **critical infrastructure** - if it goes down, our Servers page breaks. Given that Michael and Meg will be running Firefrost Gaming from an RV, they need to know immediately if something breaks.
+
+**Our Questions:**
+
+### Built-in Cloudflare Monitoring
+1. Does Cloudflare provide built-in monitoring/analytics for Workers?
+2. Can we see metrics like:
+   - Request count
+   - Error rate
+   - Response time
+   - CPU time usage
+
+### External Monitoring
+3. Should we set up **Uptime Kuma** (which we already run on Command Center) to ping the Worker endpoint every minute?
+4. If Uptime Kuma detects the Worker is down/erroring, it can alert via Discord - is this a good pattern?
+
+### Error Alerting
+5. Can Cloudflare Workers send error logs somewhere? (Sentry, Discord webhook, email?)
+6. If the Worker hits an error (panel down, API key expired, rate limit), how do we get notified **before** users complain?
+
+**RV Context (Important!):**
+When they're on the road with spotty cellular internet, they need to trust that:
+- The Worker will keep working even if they lose connection
+- They'll get alerted if something breaks
+- Error messages are clear enough to troubleshoot remotely
+
+What's your recommended monitoring setup for this architecture?
+
+---
+
+## Question 6: Deployment & DNS Cutover Sequence
+
+**Context:**
+Right now we're at `firefrost-website.pages.dev` (Cloudflare Pages preview). Once we implement the dynamic Servers page, we'll do the DNS cutover to point `firefrostgaming.com` to Cloudflare Pages.
+
+**Our Question:**
+What's the correct **sequence** for deploying this?
+
+**Option A: Worker First, Then DNS**
+1. Deploy Cloudflare Worker
+2. Update `servers.njk` to point to Worker
+3. Test on `firefrost-website.pages.dev`
+4. Once confirmed working → DNS cutover
+
+**Option B: Everything Together**
+1. Deploy Worker + update frontend code simultaneously
+2. Do DNS cutover immediately
+3. Hope it works 😅
+
+**Option C: Staged Rollout**
+1. Deploy Worker
+2. Keep static server list as fallback
+3. Add JavaScript that tries Worker first, falls back to static if it fails
+4. After a few days of monitoring → remove fallback
+
+Which approach would you recommend for a smooth launch?
+
+---
+
+## Question 7: Performance & Caching Clarification
+
+**Context:**
+You mentioned `Cache-Control: max-age=60` in the Worker response headers, which caches at the edge for 60 seconds.
+
+**Our Questions:**
+
+1. **Edge vs Browser Caching:**
+   - Does `max-age=60` cache at Cloudflare's edge, or in the user's browser, or both?
+   - Should we add separate `s-maxage` for edge-only caching?
+
+2. **Cache Busting:**
+   - If a server goes offline, will users have to wait up to 60 seconds to see the status change?
+   - Is this acceptable, or should we use a shorter cache time (like 30 seconds)?
+
+3. **Rate Limiting:**
+   - With edge caching, you said the panel only gets hit once per minute even with 1,000 simultaneous visitors
+   - Does this mean Cloudflare automatically rate-limits requests to the Worker?
+   - Or is the Worker still called 1,000 times, but it returns cached data?
+
+**What we want to understand:**
+The difference between "Cloudflare intercepts the request and returns cached data" vs "Worker runs but returns cached Pterodactyl data"
+
+---
+
+## Bonus Question: Future Enhancements
+
+**Context:**
+Once we get the basic version working (server list with online/offline status), we're thinking about future enhancements:
+
+1. **Auto-refresh:** JavaScript that automatically re-fetches every 60 seconds without page reload
+2. **Historical uptime:** Track uptime percentage over time (would need a database though)
+3. **Server join buttons:** "Join Server" button that copies IP to clipboard
+4. **Live console output:** Show last 10 lines of server console (probably too complex?)
+
+**Question:**
+Of these ideas, which ones are:
+- ✅ **Easy wins** we should add soon
+- ⚠️ **Possible but not worth the complexity**
+- ❌ **Architectural nightmares** we should avoid
+
+We don't want feature creep to delay the April 15 launch, but we'd love your take on what's worth building vs what's over-engineering!
+
+---
+
+## Timeline Check
+
+**Where we are:**
+- April 3, 2026 (today)
+- 12 days until soft launch (April 15)
+
+**Realistic implementation estimate:**
+- Day 1-2: Set up Service Account, test API endpoints
+- Day 3-4: Build and test Cloudflare Worker
+- Day 5-6: Integrate frontend, test thoroughly
+- Day 7-8: Deploy to preview, monitor for issues
+- Day 9-10: DNS cutover, go live
+- Day 11-12: Buffer for unexpected issues
+
+**Does this timeline seem reasonable?** Or are we being overly optimistic?
+
+---
+
+## Thank You (Again!)
+
+Seriously, Gemini - this has been incredibly helpful. Your architectural guidance here is exactly the kind of expertise we needed. The way you:
+
+1. **Validated our instincts** (Cloudflare Workers over VPS proxy)
+2. **Caught the gotcha** (Application vs Client API)
+3. **Provided working code** (not just theory!)
+4. **Considered RV constraints** (graceful degradation, minimal infrastructure)
+5. **Thought about edge cases** (error handling, caching strategy)
+
+...has given us total confidence in this approach.
+
+Once we get this implemented and launch on April 15, the Firefrost Gaming website will be a **living, breathing system** that updates itself automatically. No more manual code edits when servers change. Just pure, automated infrastructure magic.
+
+That's the vision: **Build it once, run it forever.**
+
+Looking forward to your answers on these implementation details so we can start building!
+
+Fire + Frost + Foundation = Where Love Builds Legacy 💙
+
+— Michael "Frostystyle" (The Wizard) & Claude (Chronicler #56)
+
+P.S. - The Six Consultants (Butter, Oscar, Jack, Skye, Jasmine, and Noir) send their regards. Butter says this architecture has his royal approval. 😺👑
diff --git a/docs/planning/gemini-servers-consultation/03-gemini-initial-response.md b/docs/planning/gemini-servers-consultation/03-gemini-initial-response.md
new file mode 100644
index 0000000..660b9e0
--- /dev/null
+++ b/docs/planning/gemini-servers-consultation/03-gemini-initial-response.md
@@ -0,0 +1,203 @@
+# Gemini Response: Initial Architecture Recommendation
+
+**Date:** April 3, 2026  
+**Topic:** Dynamic Servers Page Architecture  
+**Consultant:** Gemini AI
+
+---
+
+Michael, Claude, and the rest of the Trinity—first of all, congratulations on that 45-minute migration. That is the definition of executing with precision. 
+
+To answer your core question immediately: **Your "Aha!" moment was completely right. Cloudflare Workers is the undisputed champion for this architecture.** Option 2 (VPS Proxy) introduces unnecessary infrastructure debt. As a team planning to run operations from an RV over cellular networks, every piece of server infrastructure you add is another potential point of failure you have to troubleshoot from the road. 
+
+A Cloudflare Worker is serverless, requires zero maintenance, hides your API keys, runs on the same edge network as your website, and will cost you absolutely nothing on the free tier. 
+
+Here is your complete architectural blueprint for making the Servers page dynamic before your April 15 soft launch.
+
+---
+
+### 🚨 The Pterodactyl API "Gotcha" (Crucial Architecture Insight)
+
+Before we write code, we need to address how Pterodactyl's API actually works, because it trips up a lot of developers.
+
+Pterodactyl has **two** APIs:
+1. **Application API (Admin):** Good for getting server names, IDs, and allocation details. **Bad** because it *cannot* give you real-time player counts or live CPU/RAM usage.
+2. **Client API (User-Facing):** This is the one you need. It provides the `/resources` endpoint, which returns `current_state` (running/offline) and real-time player counts.
+
+**The Strategy: The "Service Account" Pattern**
+To use the Client API securely without exposing admin privileges:
+1. Create a dummy user in your Pterodactyl panel (e.g., `api-service@...`).
+2. Add this user as a **Subuser** to *only* the Minecraft servers you want public on the website. Give it strictly "Read" permissions (View Server, View Stats).
+3. Generate a **Client API Key** for this dummy account. 
+*Note: I will use generic URLs in the examples below to keep your specific infrastructure secure.*
+
+---
+
+### 🛠️ Step 1: The Cloudflare Worker Proxy
+
+Cloudflare Workers give you 10ms of *CPU time* on the free tier, but network requests (waiting for the API) don't count toward that limit. You can easily fetch the data and aggregate it.
+
+Create a new Worker in your Cloudflare dashboard and use this code:
+
+```javascript
+export default {
+  async fetch(request, env) {
+    // 1. Handle CORS preflight requests
+    if (request.method === 'OPTIONS') {
+      return new Response(null, {
+        headers: {
+          'Access-Control-Allow-Origin': 'https://your-website-domain.com', // Update this!
+          'Access-Control-Allow-Methods': 'GET, OPTIONS',
+          'Access-Control-Allow-Headers': 'Content-Type, Authorization'
+        }
+      });
+    }
+
+    // Set these in Cloudflare Worker Environment Variables!
+    const PANEL_URL = env.PANEL_URL; // e.g., https://panel.example.com
+    const API_KEY = env.CLIENT_API_KEY;
+
+    try {
+      // 2. Fetch the list of servers the Service Account has access to
+      const listResponse = await fetch(`${PANEL_URL}/api/client`, {
+        headers: {
+          'Authorization': `Bearer ${API_KEY}`,
+          'Accept': 'application/json'
+        }
+      });
+      
+      const listData = await listResponse.json();
+      
+      if (!listData.data) throw new Error("Failed to fetch server list");
+
+      // 3. Fetch live stats for ALL servers concurrently
+      const serverPromises = listData.data.map(async (server) => {
+        const id = server.attributes.identifier;
+        
+        // Fetch live resources (players, status)
+        const statsResponse = await fetch(`${PANEL_URL}/api/client/servers/${id}/resources`, {
+           headers: {
+            'Authorization': `Bearer ${API_KEY}`,
+            'Accept': 'application/json'
+          }
+        });
+        
+        const stats = await statsResponse.json();
+        const isRunning = stats.attributes?.current_state === 'running';
+
+        return {
+          id: id,
+          name: server.attributes.name,
+          node: server.attributes.node,
+          status: isRunning ? 'Online' : 'Offline',
+          players: isRunning ? stats.attributes?.resources?.uptime ? `${stats.attributes.resources.players} Online` : '0 Online' : '-',
+          // You can parse modpack/version from the server description if you enforce a naming convention!
+          description: server.attributes.description
+        };
+      });
+
+      const finalServers = await Promise.all(serverPromises);
+
+      // 4. Return the aggregated data with Edge Caching
+      return new Response(JSON.stringify({ servers: finalServers }), {
+        headers: {
+          'Content-Type': 'application/json',
+          'Access-Control-Allow-Origin': 'https://your-website-domain.com', // Update this!
+          'Cache-Control': 'max-age=60' // CRITICAL: Caches at the Edge for 60 seconds
+        }
+      });
+
+    } catch (error) {
+      // RV-Resiliency: If the panel is down, fail gracefully.
+      return new Response(JSON.stringify({ error: "Servers temporarily unreachable", servers: [] }), {
+        status: 500,
+        headers: { 'Access-Control-Allow-Origin': '*' }
+      });
+    }
+  }
+}
+```
+
+**Why this is bulletproof:**
+* **`Cache-Control: max-age=60`**: Even if 1,000 people load your Servers page at the exact same second, Cloudflare intercepts it. Your panel only gets hit *once per minute*. It completely protects your infrastructure from traffic spikes.
+* **Security:** The `CLIENT_API_KEY` lives securely in Cloudflare's environment variables. The browser never sees it.
+
+---
+
+### 🖥️ Step 2: The 11ty Frontend Integration
+
+On your `servers.njk` page, you'll leave a static HTML container and use vanilla JavaScript to populate it. 
+
+Keep your visual design, but add a pulsing dot for the online status.
+
+```html
+<div class="ffg-container">
+  <h2>Live Infrastructure</h2>
+  <div id="server-grid" class="grid-layout">
+    <p class="loading-text">Establishing connection to the grid...</p>
+  </div>
+</div>
+
+<script>
+  document.addEventListener("DOMContentLoaded", () => {
+    const grid = document.getElementById('server-grid');
+    // Replace with your actual Cloudflare Worker URL
+    const WORKER_URL = 'https://servers-api.your-worker.workers.dev'; 
+
+    fetch(WORKER_URL)
+      .then(res => res.json())
+      .then(data => {
+        if (data.error || !data.servers.length) {
+          grid.innerHTML = `<p class="error-text">Navigation systems offline. Our engineers are investigating.</p>`;
+          return;
+        }
+
+        grid.innerHTML = data.servers.map(server => `
+          <div class="server-card">
+            <h3>${server.name}</h3>
+            <p class="desc">${server.description || 'Standard Minecraft Deployment'}</p>
+            <div class="status-row">
+              <span class="status-badge ${server.status.toLowerCase()}">
+                ${server.status === 'Online' ? '<span class="pulse-dot"></span>' : ''} ${server.status}
+              </span>
+              <span class="player-count">${server.players}</span>
+            </div>
+          </div>
+        `).join('');
+      })
+      .catch(err => {
+        grid.innerHTML = `<p class="error-text">Unable to establish telemetry with the fleet.</p>`;
+      });
+  });
+</script>
+
+<style>
+  /* Quick CSS for the "Pulse" animation you wanted */
+  .pulse-dot {
+    display: inline-block;
+    width: 8px;
+    height: 8px;
+    background-color: #4ecdc4; /* Frost brand color */
+    border-radius: 50%;
+    margin-right: 6px;
+    animation: pulse 2s infinite;
+  }
+  
+  @keyframes pulse {
+    0% { box-shadow: 0 0 0 0 rgba(78, 205, 196, 0.7); }
+    70% { box-shadow: 0 0 0 6px rgba(78, 205, 196, 0); }
+    100% { box-shadow: 0 0 0 0 rgba(78, 205, 196, 0); }
+  }
+  
+  .status-badge.offline { color: #FF6B35; /* Fire brand color */ }
+</style>
+```
+
+---
+
+### 🗺️ The RV Reality Check
+This architecture perfectly supports the travel vision.
+* If a server crashes, the Worker automatically detects it on the next 60-second polling cycle and updates the website to "Offline" without you lifting a finger.
+* If the *entire* panel goes offline, the `catch` block in the frontend JS elegantly displays an error message. The rest of your website remains lightning fast and perfectly usable because it is hosted on Cloudflare's edge, entirely decoupled from your backend infrastructure. 
+
+You have 12 days. Set up the Service Account in Pterodactyl, drop the Worker code into Cloudflare, point your frontend at it, and you are ready for the DNS cutover.
diff --git a/docs/planning/gemini-servers-consultation/04-gemini-followup-response.md b/docs/planning/gemini-servers-consultation/04-gemini-followup-response.md
new file mode 100644
index 0000000..e837d4a
--- /dev/null
+++ b/docs/planning/gemini-servers-consultation/04-gemini-followup-response.md
@@ -0,0 +1,84 @@
+# Gemini Response: Implementation Details & Q&A
+
+**Date:** April 3, 2026  
+**Topic:** Technical Clarifications for Dynamic Servers Page  
+**Consultant:** Gemini AI
+
+---
+
+Hey Michael and Claude! Please pass my gratitude on to His Royal Highness Butter—I am honored to have the feline seal of approval on the architecture. 😺👑
+
+You have a solid 12-day timeline, and your approach of systematically testing before the cutover is exactly how the Wizard should operate. Let's knock out these technical clarifications so you can start writing code.
+
+### Question 1: Existing API Key - Which Type Do We Have?
+You can tell instantly by the prefix of the key:
+* **Application API Keys (Admin)** always start with `ptla_`
+* **Client API Keys (User)** always start with `ptlc_`
+
+If your Trinity Panel is checking overall node health or listing *all* servers on the system regardless of owner, it's likely an Application key (`ptla_`). 
+
+**How to set up the Service Account (Client API):**
+1.  Log into Pterodactyl Panel as an Admin. Go to the Admin control panel (gear icon).
+2.  Go to **Users** -> Create a new user (e.g., `website-api`, `api@yourdomain.com`).
+3.  Go to the **Servers** list in the Admin panel. For each Minecraft server you want public, add the `website-api` user as a **Subuser**.
+4.  Grant this Subuser *only* the `View Server` and `View Server Statistics` permissions.
+5.  Log *out* of your Admin account, and log *in* as `website-api`.
+6.  Go to Account Settings (top right) -> **API Credentials**. Create a new key. This will be your `ptlc_` key for the Cloudflare Worker.
+
+### Question 2: Player Count - Does Client API Actually Provide This?
+**The Nuance:** The Client API *does* return a `players` integer under `attributes.resources.players`. However, Pterodactyl's Wings daemon gets this number by passively querying the Minecraft server. 
+* **The Gotcha:** For heavily modded servers (like ATM10), the server query port sometimes hangs or reports `0` even when players are online.
+* **The Strategy:** Pull the `players` attribute from the API first. If it works reliably for your modpacks, amazing! If you notice it frequently reports `0` when you know people are playing, drop it from the UI for the MVP. Do **not** try to build a custom RCON/Query proxy 12 days before launch. Keep it simple: Online/Offline is the MVP.
+
+### Question 3: Modpack/Version Naming Convention
+Use the pipe-delimited format. It is the cleanest for parsing and looks great in the UI.
+**Recommendation:** `Modpack Name | v[Version]` (e.g., `All The Mods 10 | v1.0.9`)
+
+**Why this wins:**
+* It's natively readable in the Pterodactyl server list for Michael.
+* In JavaScript, you just do: `const [name, version] = server.description.split(' | ');`
+* Yes, store this entirely in the **Description** field of the server. The Client API returns the `description` string natively, so no custom Pterodactyl egg modifications are needed.
+
+### Question 4: Testing Cloudflare Workers Locally
+You absolutely want to test locally.
+1.  **Wrangler CLI:** Install it (`npm install -g wrangler`). Use `wrangler dev` to run the worker locally at `http://localhost:8787`.
+2.  **Environment Variables:** Create a file named `.dev.vars` in your Worker's root directory. Add your secrets:
+    ```env
+    PANEL_URL="https://your-panel-url.com"
+    CLIENT_API_KEY="ptlc_YOUR_SECRET_KEY"
+    ```
+    *Wrangler automatically loads this file for local testing but ignores it for production deployments.*
+3.  **Mocking vs Live:** Test against the live panel. You want to see exactly how Pterodactyl formats the JSON and how fast it responds. 
+
+### Question 5: Monitoring & Observability (The RV Setup)
+Since you are relying on cellular internet from the road, you need a push-notification setup, not a pull-dashboard setup.
+
+1.  **Cloudflare Analytics:** The dashboard gives you requests, CPU time, and error rates natively.
+2.  **Uptime Kuma:** Point Uptime Kuma at your Worker URL (e.g., `https://servers-api.your-worker.workers.dev`). Set it to ping every 2 minutes. If the Worker fails, Kuma alerts Discord.
+3.  **Worker Discord Webhook (Pro Move):** Inside your Cloudflare Worker's `catch (error)` block, execute a quick `fetch()` to a private Discord Webhook url. If the Worker fails to reach Pterodactyl, it will literally text your Discord server: *"Hey, the website proxy just failed to reach the panel."*
+
+### Question 6: Deployment & DNS Cutover Sequence
+**Option A: Worker First, Then DNS** is the only way to fly.
+1.  Deploy the Worker.
+2.  Update `servers.njk` to fetch from the production Worker URL.
+3.  Push to Git. Wait 60 seconds.
+4.  Test furiously on `firefrost-website.pages.dev` (your phone, Meg's phone, desktop).
+5.  When you are 100% satisfied, flip the DNS for `firefrostgaming.com`. 
+
+### Question 7: Performance & Caching Clarification
+Let's clarify `Cache-Control`:
+Change the header in the Worker to: `'Cache-Control': 'public, s-maxage=60, max-age=60'`
+* `s-maxage=60`: Tells the Cloudflare **Edge** to cache it for 60 seconds.
+* `max-age=60`: Tells the user's **Browser** to cache it for 60 seconds.
+
+**How Rate Limiting Works Here:**
+If 1,000 users hit your site simultaneously, the *first* user triggers the Worker. The Worker hits the Pterodactyl API, takes maybe 400ms, and returns the data to Cloudflare's Edge.
+For the next 59 seconds, the remaining 999 users hit Cloudflare's Edge, and Cloudflare hands them the cached JSON in ~10ms. **The Worker does not execute, and Pterodactyl is not queried again.** 60 seconds is perfectly acceptable for Minecraft server status. 
+
+### Bonus: Future Enhancements
+* ✅ **Easy Win:** **Server join buttons (Copy IP).** Very simple clipboard JavaScript. Add it for launch if you have an extra hour!
+* ✅ **Easy Win:** **Auto-refresh.** A simple `setInterval` in your frontend JS to re-fetch the Worker URL every 60 seconds.
+* ❌ **Architectural Nightmare:** **Historical uptime.** Requires a database (Supabase/Postgres) to log ping results over time. Kills the pure static-site dream. Rely on Uptime Kuma internally for this instead.
+* ❌ **Architectural Nightmare:** **Live console output.** Exposing console output to a public website is a massive security risk (IP addresses, chat logs, auth tokens can leak), and piping WebSockets through a serverless worker is notoriously difficult.
+
+Your timeline is highly realistic. Get that Service Account created today, mock up the `.dev.vars` this weekend, and you'll be coasting into April 15. Let's get building! 🔥❄️⚡