docs: Add Gemini round 4 — full schema and pg-boss queue blueprint

docs/consultations/gemini-modpack-installer-followup-2026-04-15.md

@@ -196,3 +196,78 @@ Redis is a new infrastructure dependency for LuckPerms messaging service.
 Full consultation complete. Three rounds, all questions answered, provision.json validated.
 
 **Ready for:** Holly review → final spec → Code
+
+---
+
+## Gemini's Response — Round 4: PostgreSQL Schema + pg-boss Queue (April 15, 2026)
+
+**Summary:** Complete database schema and job queue blueprint. Ready for Code phase after Holly review.
+
+### Part 1: PostgreSQL Schema
+
+#### Updates to server_config
+```sql
+ALTER TABLE server_config
+ADD COLUMN modpack_provider VARCHAR(50),
+ADD COLUMN modpack_id VARCHAR(100),
+ADD COLUMN current_version_id VARCHAR(100),
+ADD COLUMN is_version_locked BOOLEAN DEFAULT FALSE,
+ADD COLUMN locked_version_id VARCHAR(100) DEFAULT NULL,
+ADD COLUMN lock_reason TEXT DEFAULT NULL,
+ADD COLUMN spawn_verified BOOLEAN DEFAULT FALSE,
+ADD COLUMN ram_allocation_mb INT NOT NULL DEFAULT 8192,
+ADD COLUMN ram_ceiling_mb INT NOT NULL DEFAULT 16384,
+ADD COLUMN hibernation_status VARCHAR(50) DEFAULT 'active';
+```
+
+#### New: install_history table
+```sql
+CREATE TABLE install_history (
+    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
+    server_id UUID REFERENCES server_config(id) ON DELETE CASCADE,
+    pterodactyl_server_id VARCHAR(100),
+    job_type VARCHAR(50) NOT NULL,
+    target_version_id VARCHAR(100) NOT NULL,
+    triggered_by VARCHAR(100) NOT NULL,
+    status VARCHAR(50) NOT NULL,
+    started_at TIMESTAMP WITH TIME ZONE DEFAULT NOW(),
+    completed_at TIMESTAMP WITH TIME ZONE,
+    duration_seconds INT,
+    mods_injected INT DEFAULT 0,
+    log_output JSONB DEFAULT '{}'
+);
+
+CREATE INDEX idx_install_history_recent_failures 
+ON install_history(server_id, status, started_at);
+```
+
+### Part 2: pg-boss Queue Architecture
+
+Three queues:
+- `modpack-installs` — concurrency 2 (heavy file I/O)
+- `maintenance-tasks` — concurrency 5 (ghost updates, hibernation)
+- `fast-sync` — concurrency 20 (LuckPerms pings, Discord alerts)
+
+### Worker Execution Flow
+1. Job picked up → install_history status = `running`
+2. Pre-flight: node RAM/disk check, Java version mapping → correct egg
+3. Pterodactyl server provisioned
+4. Download pack → scrub client mods against Firefrost Reject List
+5. Standard stack injection from NextCloud
+6. Inject provision.json + Holly-Bot mod
+7. Stream to Pterodactyl via SFTP/Wings
+8. Cloudflare DNS + Discord channels created
+9. Power on → spawn_verified = false (enters Holly's queue) → install_history = success → staff Discord ping
+
+### Gemini's Question
+> "Does this schema and queue architecture pass the smell test, or do we need to adjust how we're handling ghost_update staging in the DB?"
+
+**Answer:** It passes. ghost_update staging can live as a job_type in install_history ('ghost_update') with status tracking through the queue. No additional DB columns needed — the staging folder on disk is the state, the DB just tracks the job.
+
+---
+
+## FULL CONSULTATION COMPLETE ✅
+
+Four rounds. Architecture locked. Schema defined. Queue designed. provision.json validated.
+
+**Status:** Awaiting Holly review → Holly names the bot → Final spec → Code