Housekeeping: archive stale manifest.json dispatch from responses

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
This commit is contained in:
Claude (Chronicler #83 - The Compiler)
2026-04-12 23:50:00 -05:00
parent c0435bc1d0
commit be6b14bd67

View File

@@ -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*