Consultation Round 2: egg variable not viable, asking for outside-the-box solutions

Egg variables confirmed absent from NeoForge and Forge eggs.
Cannot require manual admin intervention for BuiltByBit customers.
Asking Gemini to revise plan — wild ideas welcome.
Also added ignore toggle UX question.

docs/consultations/gemini-installer-version-detection-round2-2026-04-13.md

@@ -0,0 +1,100 @@
+# Gemini Consultation: Installer Version Detection — Round 2
+
+**Date:** April 13, 2026  
+**From:** Michael (The Wizard) + Claude (Chronicler #85)  
+**To:** Gemini (Architectural Partner)  
+**Re:** Follow-up on installer detection — egg variable approach is not viable
+
+---
+
+## Hey Gemini! 👋
+
+Thanks for the Round 1 breakdown — really helpful framing. We need to push back
+on the egg variable suggestion though, and we're hoping you can help us think
+outside the box on this one.
+
+---
+
+## The Egg Variable Problem
+
+We pulled the actual egg definitions for the two most common eggs on our panel
+(NeoForge and Forge Minecraft). Here's what the variables look like:
+
+**NeoForge egg variables:** `MC_VERSION`, `NEOFORGE_VERSION`  
+**Forge egg variables:** `SERVER_JARFILE`, `MC_VERSION`, `BUILD_TYPE`, `FORGE_VERSION`
+
+No `MODPACK_CURRENT_VERSION` anywhere. And here's the critical constraint:
+
+**We cannot expect server owners to manually add egg variables.** This is a
+BuiltByBit product that will be installed by hundreds of Pterodactyl admins of
+varying skill levels. Asking them to edit egg JSON, add custom variables, and
+maintain them across updates is a non-starter. Even our own servers don't have
+this variable set. It's not a realistic solution.
+
+---
+
+## What We Know Works
+
+The `manifest.json` path via Wings Files API is promising — you confirmed it
+works whether the server is running or stopped. We already have partial logic
+for this in the cron. This is probably the right direction.
+
+---
+
+## The Real Question
+
+Is there any way to **automatically inject** a version tracking mechanism into
+the server without manual admin intervention? Some ideas we're throwing out —
+wild is welcome:
+
+1. **Post-install hook via Blueprint** — Could we use Blueprint to inject a
+   script or file into the Pterodactyl installation process that writes a
+   version file (e.g. `.modpack-version`) to the server filesystem after
+   the modpack installs? Blueprint has hooks for panel events.
+
+2. **Wings Files API on first detection** — When we first detect a server via
+   `modpack_installations`, immediately read `manifest.json` via Wings to get
+   the installed version and store it. No egg variable needed, no manual steps.
+
+3. **Parse the installer log** — Pterodactyl keeps installation logs. Could we
+   read the install log via the API to extract which version was installed?
+
+4. **CurseForge/Modrinth file ID from manifest** — `manifest.json` contains
+   the exact CurseForge `projectID` and potentially the file ID of the installed
+   pack. If we can read that file ID, we can compare it directly to the latest
+   file ID from the API — no version string parsing needed at all.
+
+4. **Watch for modpack_installations changes** — If we detect a new or changed
+   row in `modpack_installations`, trigger an immediate manifest.json read to
+   capture the installed version at the moment of install.
+
+5. **Something else entirely** — What would YOU do if you had access to Wings
+   API, the panel database, and Blueprint hooks? No constraints, think wild.
+
+---
+
+## Constraints Summary
+
+- Cannot require manual admin intervention
+- Cannot require egg modifications
+- Must work for BuiltByBit customers on vanilla Pterodactyl installs
+- Wings Files API is available (confirmed working whether server running or not)
+- We have `current_file_id` and `latest_file_id` columns ready for file ID comparison
+- `manifest.json` exists on CurseForge modpack servers
+- April 15 soft launch is the deadline — pragmatic wins
+
+---
+
+## Also — One More Thing
+
+Regardless of the version detection solution, we need your guidance on the
+**ignore toggle behavior**. Right now clicking the ignore button makes the
+widget vanish entirely (`return null`). It should instead show a persistent
+"Not tracked" state with an option to re-enable tracking. What's the cleanest
+UX pattern for a toggle like this in a Pterodactyl panel widget context?
+
+---
+
+Thanks Gemini! Wild ideas welcome. 🔥❄️
+
+— Michael + Claude (Chronicler #85)