diff --git a/docs/consultations/gemini-installer-version-detection-2026-04-13.md b/docs/consultations/gemini-installer-version-detection-2026-04-13.md
new file mode 100644
index 0000000..ec9ad6e
--- /dev/null
+++ b/docs/consultations/gemini-installer-version-detection-2026-04-13.md
@@ -0,0 +1,114 @@
+# Gemini Consultation: Installer Detection — Current Version Not Being Read
+
+**Date:** April 13, 2026  
+**From:** Michael (The Wizard) + Claude (Chronicler #85)  
+**To:** Gemini (Architectural Partner)  
+**Re:** ModpackChecker `installer` detection method stores installer filename instead of actual installed version
+
+---
+
+## Hey Gemini! 👋
+
+We just deployed ModpackChecker v1.1.0 to the live panel and ran the cron against
+22 real servers. The ErrorBoundary and pipeline work great — thank you for that
+guidance. But we've hit a detection accuracy problem that needs your input before
+we go live April 15.
+
+---
+
+## The Situation
+
+ModpackChecker detects modpack versions using several methods. The primary one
+is `installer` — it reads from Pterodactyl's `modpack_installations` table, which
+tells us which modpack is installed on each server (provider + modpack_id).
+
+**The `modpack_installations` table schema:**
+```
+server_id  | provider    | modpack_id | finalized
+55         | curseforge  | 490660     | 0
+```
+
+No version column. It only tells us *what* is installed, not *which version*.
+
+**What the cron does with installer detection:**
+```php
+// Step 1: modpack_installations table
+$installation = DB::table('modpack_installations')
+    ->where('server_id', $server->id)
+    ->first();
+
+if ($installation && !empty($installation->provider) && !empty($installation->modpack_id)) {
+    $this->checkVersion($server, $installation->provider, 
+        (string) $installation->modpack_id, 'installer', null);  // ← null installed version
+    return;
+}
+```
+
+It passes `null` as the installed version. Then `checkVersion` falls through its
+detection chain:
+1. `$installedVersion` → null
+2. `MODPACK_CURRENT_VERSION` egg variable → not set on most servers
+3. Existing DB value → first run = empty, subsequent runs = whatever was stored before
+4. **Seeds with latest version from API** → stores the latest release name as current
+
+**Result from live panel cron run:**
+```
+DeceasedCraft:  current: DeceasedCraft_Beta_DH_Edition_5.10.16, latest: 5.10.16
+Stoneblock 4:   current: FTB StoneBlock 4 1.10.0, latest: 1.10.0
+ATM10:          current: All the Mods 10-6.6, latest: All the Mods 10-6.6
+```
+
+The `current_version` is the full installer filename/release title from the API,
+not what's actually installed. For DeceasedCraft specifically, we KNOW the server
+has 5.10.15 installed but the widget shows it as up to date at 5.10.16.
+
+---
+
+## What We're Trying to Do
+
+Get the `installer` detection method to accurately report what version is actually
+installed on each server, so the update status is trustworthy.
+
+---
+
+## Specific Questions
+
+1. Pterodactyl's `modpack_installations` table doesn't store version info. Is there
+   another Pterodactyl table or API endpoint that tells us which version of a
+   modpack is currently installed on a server?
+
+2. If Pterodactyl doesn't store the installed version anywhere, what's the most
+   reliable fallback? Options we've considered:
+   - Read `manifest.json` from the server filesystem via Pterodactyl's Files API
+   - Read `minecraftinstance.json` (CurseForge launcher format)
+   - Read `modpack.json` or similar
+   - Compare file IDs (we have `current_file_id` and `latest_file_id` columns)
+   - Ask the server admin to set `MODPACK_CURRENT_VERSION` egg variable
+
+3. We already have file ID comparison logic (`current_file_id` vs `latest_file_id`).
+   Could we use the file ID from `modpack_installations` (if Pterodactyl stores it
+   somewhere) to determine if the installed version matches the latest?
+
+4. For the April 15 soft launch, what's the most pragmatic approach — fix the
+   detection or show an honest "version unknown, update check required" state
+   rather than a potentially wrong status?
+
+---
+
+## Context That Might Help
+
+- Pterodactyl version: 1.12.2 with Blueprint beta
+- All 22 servers use the `installer` detection method (via modpack_installations table)
+- The manifest.json detection path exists in the cron but requires the server to
+  be running and accessible via Pterodactyl's Files API
+- We have `current_file_id` and `latest_file_id` columns — file ID comparison is
+  already implemented but `current_file_id` is null for most servers
+- The `finalized` column in `modpack_installations` is 0 for some servers (not sure
+  what this means in Pterodactyl's context)
+- April 15 is 48 hours away
+
+---
+
+Thanks Gemini! 🔥❄️
+
+— Michael + Claude (Chronicler #85)