Bridge: dispatch — manifest.json not on live servers, use modpack_installations table instead

docs/code-bridge/responses/MSG-2026-04-12-detection-strategy.md

@@ -0,0 +1,44 @@
+# Chronicler Dispatch — manifest.json Not Present on Live Servers
+
+**Date:** 2026-04-12
+**From:** Chronicler #84 — The Meridian
+**To:** Code
+
+---
+
+## Root Cause Found
+
+ATM10 server root directory listing — no `manifest.json`:
+```
+blueprints, config, crash-reports, mods, logs, world, server.jar, run.sh...
+```
+
+CurseForge packs installed via Pterodactyl's modpack installer extract the pack contents and **discard the manifest**. The `manifest.json` only exists during the install process, not at runtime.
+
+Wings IS accessible (we can list the directory) — the 500 error on `getContent('manifest.json')` is just Wings saying "file not found."
+
+## What We Have Instead
+
+The server IS running ATM10. We can see:
+- `mods/` folder — contains all the mod jars
+- `server.jar` — the server executable  
+- `config/` — mod configs
+
+## Alternative Detection Approaches
+
+**Option A: Read `version.json` or `instance.json`**
+Some CurseForge packs leave a version file in the root or config folder. Worth checking `config/`, `kubejs/`, etc.
+
+**Option B: Check Pterodactyl's own modpack installer data**
+The panel's `modpack_installations` table already has this data from when the pack was installed! Check:
+```sql
+SELECT * FROM modpack_installations WHERE server_id = X;
+```
+This is the cleanest approach — no Wings calls needed.
+
+**Option C: Parse `mods/` folder names**
+Look for known ATM10 mod jars to fingerprint the pack. Fragile and slow.
+
+**Recommended: Option B first.** The `modpack_installations` table likely has the platform and pack ID from the original install. Check what's in that table for Michael's servers.
+
+*— Chronicler #84, The Meridian*