Consultation: live panel deploy readiness — asking Gemini re: v1.1.0 frontend safety

Dev Panel validated: ErrorBoundary, zero-click, build pipeline.
Limitation: only fake test data, no real CurseForge calls tested.
Asking Gemini if sufficient to proceed to live panel 48hrs pre-launch.

docs/consultations/gemini-live-panel-deploy-readiness-2026-04-13.md

@@ -0,0 +1,78 @@
+# Gemini Consultation: Live Panel Deploy Readiness
+
+**Date:** April 13, 2026  
+**From:** Michael (The Wizard) + Claude (Chronicler #85)  
+**To:** Gemini (Architectural Partner)  
+**Re:** Is it safe to deploy ModpackChecker v1.1.0 to live panel after Dev Panel validation?
+
+---
+
+## Hey Gemini! 👋
+
+We've had quite the session. You may remember the production incident from last night where the v1.1.0 widget caused a silent React crash that wiped the entire server card. We emergency-reverted to v1.0.0 frontend, and you gave us the build pipeline hardening consultation that led to the ErrorBoundary implementation.
+
+We've now done the Dev Panel validation you recommended. Here's what we've confirmed and where we hit a wall.
+
+---
+
+## The Situation
+
+**What's deployed on Dev Panel (64.50.188.128):**
+- ModpackChecker v1.1.0 backend — fully deployed
+- ErrorBoundary wrapping the widget injection ✅
+- build.sh v1.1.0 with `set -e`, `set -u`, TS pre-flight, no PHP clobbering ✅
+- Widget loads on page open (zero-click) ✅
+- Display format correct: `ATM9 0.1.0 → 1.0.0 ↑` ✅
+- Card intact, no React crash ✅
+- Pre-commit PHP lint hook ✅
+- Missing `modpack_installations` migration added (with `IF NOT EXISTS` guard) ✅
+
+**The limitation we hit:**
+Dev Panel only has one test server with a fake/patched egg and hardcoded fake data. It doesn't have a real CurseForge API key configured, and the egg doesn't represent a real modpack installation. This means we couldn't test:
+- Real CurseForge API calls through the widget
+- Real version detection (manifest.json parsing, egg variable reading)
+- Real `update_available` vs `up_to_date` status transitions with live data
+
+**What live panel has:**
+- 22 real servers, all detected via the installer method
+- Real CurseForge API key configured
+- Real modpack installations with actual version data
+- v1.0.0 widget currently running (post-revert) — panel is stable
+
+---
+
+## What We're Trying to Do
+
+Deploy v1.1.0 frontend to live panel (45.94.168.138). Specifically:
+- Copy updated `wrapper.tsx` → compile → blueprint install
+- All the same steps we validated on Dev Panel
+
+The question is whether our Dev Panel validation is sufficient given the fake data limitation, or whether there's additional risk we should mitigate before touching live panel.
+
+---
+
+## Specific Questions
+
+1. Given that we validated the ErrorBoundary and build pipeline on Dev Panel but couldn't test with real modpack data — is that level of validation sufficient to proceed to live panel safely?
+
+2. The main risk from the original incident was an uncaught React crash wiping the server card. The ErrorBoundary specifically addresses that. Is there any remaining vector for a full card wipeout that we haven't addressed?
+
+3. We're about to deploy to a live panel 48 hours before our April 15 soft launch. Is there anything about this timing that changes your risk assessment?
+
+4. Is there a safer deployment sequence we should follow — for example, deploying to one server first rather than panel-wide?
+
+---
+
+## Context That Might Help
+
+- The v1.1.0 backend has been live on the panel for ~24 hours with no issues
+- The frontend revert to v1.0.0 was clean — panel has been stable since
+- Blueprint's `blueprint -install` is the canonical deploy path
+- We cannot do a partial/per-server frontend deploy — Blueprint compiles a single bundle for the whole panel
+- The Meridian's consultation doc is at `docs/consultations/gemini-build-pipeline-2026-04-13.md` if you want the full context from last night
+
+---
+
+Thanks Gemini! 🔥❄️
+
+— Michael + Claude (Chronicler #85)