ADDED TASK #20: Coming Soon Video (CapCut) - Time: 15 minutes (quick win for branding) - Uses existing assets (fire-frost-collision.png, logos) - CapCut recipe: 24 detailed steps (mobile-friendly) - Output: Vertical (Instagram/TikTok) + Horizontal (YouTube/Twitter) - 10-15 second professional announcement video - Assigned: Michael tests first, then train Meg STRUCTURE: - 0-3s: Fire-frost collision with slow zoom - 3s: White flash (impact) - 3-5s: Logo reveal with cyan glow - 5-12s: "COMING SOON" text (Orbitron, #00E5FF) - 12-15s: Emblem + firefrostgaming.com USE CASES: - Server launches - Recruitment announcements - Social media hype - General branding RENUMBERED: - Tier 5 tasks: 21-25 (was 20-24) - Tier 6 tasks: 26-28 (was 25-27) - Total tasks: 28 (was 27) Updated by: Chronicler the Ninth
1347 lines
49 KiB
Markdown
1347 lines
49 KiB
Markdown
# 🔥❄️ FIREFROST GAMING — COMPLETE TASK LIST
|
|
|
|
**Last Updated:** February 15, 2026
|
|
**Updated By:** Chronicler the Ninth
|
|
**Version:** 2.0 (Complete Restructure)
|
|
**Purpose:** Comprehensive dependency-ordered roadmap — execute top to bottom
|
|
|
|
---
|
|
|
|
## 🏥 MEDICAL GATE (BLOCKS EVERYTHING)
|
|
|
|
**Status:** Recovering from Feb 14 medical episode
|
|
**Gate Opens When:**
|
|
- ✅ Doctor visit complete (Mon/Tue Feb 17-18)
|
|
- ✅ Medical clearance received
|
|
- ✅ Energy level restored
|
|
- ✅ Jack calm and not alerting
|
|
- ✅ No lingering symptoms
|
|
|
|
**DO NOT start major work until this gate opens. Health > deadlines. Always.**
|
|
|
|
---
|
|
|
|
## 🎯 TIER 0: IMMEDIATE WINS (<2 Hours Total)
|
|
|
|
Quick wins with high impact and no dependencies.
|
|
|
|
### 1. Centralized Whitelist Manager
|
|
**Time:** 1 hour
|
|
**Priority:** DO WHEN HOME
|
|
**Location:** `/opt/firefrost/whitelist-manager.sh` on Command Center
|
|
|
|
**The Problem:**
|
|
- Currently requires manual SSH to each node (TX1, NC1)
|
|
- Update whitelist on each of 12+ servers individually via Pterodactyl console
|
|
- Time-consuming, error-prone, painful
|
|
|
|
**The Solution:**
|
|
- Command Center script using Pterodactyl API
|
|
- One command updates all whitelisted servers at once
|
|
- Logs all changes (audit trail)
|
|
- Master whitelist stored in repo
|
|
|
|
**Usage:**
|
|
```bash
|
|
whitelist-manager.sh add PlayerName
|
|
whitelist-manager.sh remove PlayerName
|
|
whitelist-manager.sh list
|
|
whitelist-manager.sh sync # Ensure all servers match
|
|
```
|
|
|
|
**Before Building:**
|
|
- Which servers are whitelisted vs public?
|
|
- Pterodactyl API key (create or use existing)
|
|
- Toggle enforcement or just add/remove names?
|
|
- Access control (Michael only or also Meg/staff?)
|
|
|
|
**Future Enhancement (Phase 2):**
|
|
- Paymenter integration (subscriber pays → auto-whitelisted)
|
|
- Discord bot interface
|
|
- Web interface on staff.firefrostgaming.com
|
|
|
|
**After Completion:** 15-minute task → 10 seconds
|
|
|
|
---
|
|
|
|
### 2. Command Center Root Cleanup
|
|
**Time:** 15 minutes
|
|
**Why:** Housekeeping before major work
|
|
|
|
**Move to `/root/backups/gitea/`:**
|
|
- gitea-backup-20260208-2203...
|
|
- gitea-data-20260209.tar.gz
|
|
- gitea-db-20260209.sql
|
|
- gitea-db-full.sql
|
|
- gitea-migration-manifest.txt
|
|
|
|
**Archive to repo (`docs/deployment-logs/`):**
|
|
- wiki-deployment-logs-feb10.txt
|
|
- wiki-deployment-summary.txt
|
|
|
|
**Delete (cruft):**
|
|
- dead.letter
|
|
- extract-key-info.sh
|
|
- master
|
|
|
|
---
|
|
|
|
### 3. NC1 Cleanup (Mandatory for Mailcow)
|
|
**Time:** 30 minutes
|
|
**Why Critical:** Required for Mailcow deployment
|
|
**Blocks:** Mailcow Email Server
|
|
|
|
**Actions:**
|
|
```bash
|
|
ssh root@216.239.104.130
|
|
|
|
# Delete Hytale backups/install files (10GB)
|
|
rm -rf /var/lib/pterodactyl/volumes/13c80cb8-f6f8-4bfe-9cdb-823d7e951584/backups
|
|
rm -f /var/lib/pterodactyl/volumes/13c80cb8-f6f8-4bfe-9cdb-823d7e951584/*.zip
|
|
|
|
# Clean old logs (4.5GB)
|
|
journalctl --vacuum-time=7d
|
|
rm -f /var/log/btmp.1 && > /var/log/btmp
|
|
rm -f /var/log/*.gz
|
|
|
|
# Clean Docker (6GB)
|
|
docker system prune -a --volumes -f
|
|
|
|
# Verify
|
|
df -h /
|
|
```
|
|
|
|
**Result:** 26GB → 46GB free (30GB needed for Mailcow, 16GB headroom)
|
|
|
|
---
|
|
|
|
## 🔐 TIER 1: SECURITY FOUNDATION
|
|
|
|
Security infrastructure before deploying services.
|
|
|
|
### 4. Vaultwarden — Add SSH Key & Org Setup
|
|
**Time:** 30 minutes total
|
|
**Status:** ✅ Deployed, needs finishing touches
|
|
**Blocks:** Scoped tokens, all credential management
|
|
|
|
**Part A: Add SSH Key (5 min)**
|
|
- Add SSH key to Vaultwarden for secure access
|
|
- Verify credential storage working
|
|
|
|
**Part B: Organization Setup for Meg (25 min)**
|
|
- Create "Firefrost Gaming" organization (Free plan, 2 users)
|
|
- Invite Meg via email
|
|
- Create Collections:
|
|
- Server Credentials
|
|
- Social Media Accounts
|
|
- Billing & Financial
|
|
- Game Server Admin
|
|
- Move shared passwords to appropriate collections
|
|
- Test Meg's access
|
|
|
|
**After Completion:**
|
|
- ✅ Secure credential storage operational
|
|
- ✅ Meg has access to shared passwords
|
|
- ✅ Delete temp credential files from repo
|
|
|
|
---
|
|
|
|
### 5. The Frostwall Protocol — GRE Tunnel Security Architecture
|
|
**Time:** 3-4 hours
|
|
**Priority:** CRITICAL
|
|
**Why:** DDoS protection, hides real server IPs, protects all game traffic
|
|
**Status:** Rebuild pending (was torn down due to incorrect implementation)
|
|
|
|
**What It Is:**
|
|
Custom DDoS shield using GRE tunnels from Command Center (Dallas Hub) to remote nodes (TX1, NC1). All game traffic routes through Command Center scrubbing center, then encrypted tunnels to backend servers.
|
|
|
|
**Core Components:**
|
|
1. **GRE Tunneling** — Private encrypted links between hub and nodes
|
|
2. **1-to-1 NAT/DMZ Forwarding** — /29 IP block for clean external→internal mapping
|
|
3. **Iron Wall UFW Rules** — Physical interfaces drop ALL traffic except GRE + management IP
|
|
4. **IP Hierarchy:**
|
|
- Scrubbing Center IP (what players see)
|
|
- Backend Alias IP (hidden server address)
|
|
- Binding Truth IP (internal service binding)
|
|
|
|
**Implementation Steps:**
|
|
1. Configure GRE tunnels: Command Center ↔ TX1
|
|
2. Configure GRE tunnels: Command Center ↔ NC1
|
|
3. Set up 1-to-1 NAT/DMZ forwarding with /29 IP block
|
|
4. Deploy Iron Wall UFW rules (drop all except GRE + management)
|
|
5. Test tunnel connectivity and failover
|
|
6. Implement self-healing persistence (tunnels auto-recover on failure)
|
|
7. Document IP hierarchy and routing tables in repo
|
|
8. Verify game traffic routes through tunnels correctly
|
|
|
|
**After Completion:**
|
|
- ✅ Game servers protected by DDoS scrubbing
|
|
- ✅ Real IPs hidden from internet
|
|
- ✅ Self-healing tunnels (auto-recovery)
|
|
- ✅ Email IP reputation protected (separate from game traffic)
|
|
- ✅ Foundation for all future service deployments
|
|
|
|
**Current Documentation:** https://docs.google.com/document/d/12Kh-AhUgJLOJrBgIjMiGi3xRZH1basRzv9Pa_-x1t_0/edit
|
|
**Migrate to Repo:** `docs/deployment/frostwall-protocol.md`
|
|
|
|
---
|
|
|
|
### 6. Command Center Security Hardening
|
|
**Time:** 1 hour
|
|
**Why:** Defense in depth, protects the hub
|
|
**Scope:** Command Center VPS (63.143.34.217)
|
|
|
|
**Current State:**
|
|
- ✅ UFW enabled with default deny incoming
|
|
- ✅ Ports 22, 80, 443 open on primary IP
|
|
- ❌ Fail2Ban not installed
|
|
- ❌ SSH not hardened (still allows password auth)
|
|
- ❌ No rate limiting on SSH
|
|
|
|
**Tasks:**
|
|
1. Install and configure Fail2Ban (auto-ban brute force attempts)
|
|
2. SSH hardening:
|
|
- Disable password authentication (key-only)
|
|
- Change default SSH port (optional but recommended)
|
|
- Set MaxAuthTries=3
|
|
3. Review UFW rules for any unnecessary open ports
|
|
4. Document security configuration in `docs/deployment/command-center-security.md`
|
|
5. Test SSH access with keys before closing password auth
|
|
|
|
**After Completion:**
|
|
- ✅ Automated brute force protection
|
|
- ✅ SSH hardened to industry standards
|
|
- ✅ Command Center locked down
|
|
|
|
---
|
|
|
|
### 7. Create Scoped Gitea Token for Pokerole Project
|
|
**Time:** 15 minutes
|
|
**Depends On:** Vaultwarden operational
|
|
**Why:** Defense in depth - scoped token enforces boundary
|
|
|
|
**Current Situation:**
|
|
- Pokerole project uses master Gitea token with "honor system" scope instruction
|
|
- Iron Wall principle says: enforce boundaries technically, not socially
|
|
|
|
**Actions:**
|
|
1. Create new Gitea API token scoped to ONLY 4 pokerole-project repos
|
|
2. Store scoped token in Vaultwarden
|
|
3. Update `pokerole-project/misc-docs/SESSION-START-PROMPT.md` with new token
|
|
4. Test Claudius can access Pokerole repos (and ONLY Pokerole repos)
|
|
5. Remove master token reference from Pokerole docs
|
|
|
|
**After Completion:**
|
|
- ✅ Pokerole project isolated from main operations
|
|
- ✅ Claudius cannot accidentally touch Firefrost infrastructure
|
|
- ✅ Defense in depth enforced
|
|
|
|
---
|
|
|
|
## 🏗️ TIER 2: MAJOR INFRASTRUCTURE
|
|
|
|
Foundation is secure, now deploy major services.
|
|
|
|
### 8. Mailcow Email Server on NC1
|
|
**Time:** 2-3 hours
|
|
**Depends On:** NC1 cleanup complete, Frostwall protection active
|
|
**Why First:** Critical communication infrastructure
|
|
**Location:** NC1 Charlotte (216.239.104.130)
|
|
|
|
**Why NC1 Instead of New VPS:**
|
|
- ✅ $0/month vs $10/month VPS cost ($120/year saved)
|
|
- ✅ Geographic redundancy (Email in Charlotte, AI in Dallas)
|
|
- ✅ Better disaster resilience (TX1 failure doesn't kill email)
|
|
- ✅ Clean IP confirmed by Breezehost
|
|
- ✅ Monster hardware (32-core EPYC vs 2-core VPS)
|
|
- ✅ NC1 has capacity after cleanup (46GB storage available)
|
|
- ✅ GRE tunnel protects game traffic from affecting email IP
|
|
|
|
**Resources After Deployment:**
|
|
- RAM: 6GB Mailcow / 251GB total = 2.4% usage
|
|
- Storage: 30GB Mailcow / 46GB free = 65% used, 16GB headroom
|
|
- CPU: Massive overkill (good thing)
|
|
|
|
**Deployment Steps:**
|
|
1. Deploy Mailcow via Docker (Postfix, Dovecot, SOGo, Rspamd, ClamAV)
|
|
2. Configure DNS records:
|
|
- MX records
|
|
- SPF (Sender Policy Framework)
|
|
- DKIM (DomainKeys Identified Mail)
|
|
- DMARC (Domain-based Message Authentication)
|
|
3. Create initial 10-15 @firefrostgaming.com addresses
|
|
4. Test deliverability (Gmail, Outlook, Yahoo)
|
|
5. Check spam scores and blacklist status
|
|
6. Migrate off Plesk (accessibility nightmare eliminated)
|
|
|
|
**After Completion:**
|
|
- ✅ Professional @firefrostgaming.com email
|
|
- ✅ Self-hosted, full control
|
|
- ✅ Accessibility win (Plesk eliminated)
|
|
- ✅ $120/year saved
|
|
|
|
---
|
|
|
|
### 9. Self-Hosted AI Stack on TX1
|
|
**Time:** 8-12 hours total (3-4 hours active work, rest is downloads/ingestion)
|
|
**Depends On:** Medical clearance
|
|
**Why Critical:** DERP backup, unlimited AI access, staff assistant foundation
|
|
**Location:** TX1 Dallas
|
|
**Architecture:** Dual deployment (AnythingLLM primary + Open WebUI for staff)
|
|
|
|
**Phase 0: NC1 Cleanup** ✅ (See Tier 0, Task #3)
|
|
|
|
**Phase 1: Deploy Stack (1-2 hours active)**
|
|
|
|
**Primary: AnythingLLM (for Michael/Meg, document-heavy workloads)**
|
|
- Purpose-built for 1,000+ document libraries
|
|
- Built-in LanceDB vector database (proven to 5,000+ docs)
|
|
- Workspace-based isolation (Operations, Pokerole, Brainstorming, Staff)
|
|
- Domain: ai.firefrostgaming.com
|
|
|
|
**Secondary: Open WebUI (for staff assistant Phase 4)**
|
|
- Lighter weight for staff wiki only
|
|
- Built-in Chroma vector DB (sufficient for smaller staff dataset)
|
|
- ChatGPT-like interface (familiar to users)
|
|
- Domain: staff-ai.firefrostgaming.com (when staff wiki deployed)
|
|
|
|
**Deployment Steps:**
|
|
1. Install Ollama on TX1
|
|
2. Deploy AnythingLLM via Docker
|
|
3. Deploy Open WebUI via Docker
|
|
4. Configure Nginx reverse proxy for both
|
|
5. Test basic functionality
|
|
6. Document at `docs/deployment/ai-stack.md`
|
|
|
|
---
|
|
|
|
**Phase 2: Load LLM Models (6-8 hours download, overnight)**
|
|
|
|
**Core Models:**
|
|
- Qwen 2.5 Coder 72B (~40GB) — Coding tasks, script generation
|
|
- Llama 3.3 70B (~40GB) — Conversation, reasoning, decision-making
|
|
- Llama 3.2 Vision 11B (~7GB) — Image understanding, photo processing
|
|
|
|
**Embedding Model (for RAG):**
|
|
- all-MiniLM-L6-v2 (~400MB) — Document embeddings for semantic search
|
|
- Or: nomic-embed-text (~700MB) — Higher quality, slightly larger
|
|
|
|
**Total Storage:** ~90-95GB for models + 50-60GB for embeddings/vector DB = ~150GB
|
|
**Total RAM when loaded:** ~100-110GB (models + vector DB in memory)
|
|
|
|
---
|
|
|
|
**Phase 3: Document Ingestion & Vector Database (2-3 hours ACTIVE, 6-8 hours total processing)**
|
|
|
|
**CRITICAL: Batch ingestion to prevent OOM (Out of Memory) killer**
|
|
|
|
**Preparation:**
|
|
```bash
|
|
# Clone repos to local filesystem
|
|
mkdir -p /opt/firefrost/repos
|
|
cd /opt/firefrost/repos
|
|
git clone https://git.firefrostgaming.com/firefrost-gaming/firefrost-operations-manual.git
|
|
git clone https://git.firefrostgaming.com/firefrost-gaming/pokerole-project.git
|
|
git clone https://git.firefrostgaming.com/firefrost-gaming/brainstorming.git
|
|
```
|
|
|
|
**Workspace Structure in AnythingLLM:**
|
|
|
|
**Workspace 1: Firefrost Operations** (~500 files, growing)
|
|
- Full operations-manual repo
|
|
- Session transcripts
|
|
- Deployment guides
|
|
- Infrastructure docs
|
|
- Consultant profiles
|
|
|
|
**Workspace 2: Pokerole Project** (~200 files)
|
|
- Separate context for Claudius
|
|
- Holly collaboration docs
|
|
- Pokédex content
|
|
- Isolated from main operations (security)
|
|
|
|
**Workspace 3: Brainstorming** (~100 files)
|
|
- Sandbox sessions
|
|
- Gemini brainstorms
|
|
- Idea backlogs
|
|
- Among Us planning
|
|
|
|
**Workspace 4: Staff Wiki** (future, when deployed)
|
|
- Staff-facing documentation only
|
|
- Procedures, troubleshooting, policies
|
|
- No access to operations manual (private)
|
|
|
|
**Ingestion Process (BATCH 100 DOCS AT A TIME):**
|
|
|
|
1. **Start with Firefrost Operations workspace**
|
|
- Upload first 100 markdown files from operations-manual
|
|
- Wait for embedding completion (~30-45 min)
|
|
- Verify search works before continuing
|
|
|
|
2. **Continue in batches of 100**
|
|
- Monitor RAM usage (should stay under 150GB)
|
|
- If RAM spikes above 180GB, reduce batch size to 50
|
|
- Total ingestion: ~4-6 hours for 500 docs
|
|
|
|
3. **Repeat for other workspaces**
|
|
- Pokerole: 2-3 hours (smaller dataset)
|
|
- Brainstorming: 1-2 hours
|
|
- Total: 6-8 hours processing time
|
|
|
|
**Testing:**
|
|
- Test semantic search: "What is the Frostwall Protocol?"
|
|
- Test cross-document synthesis: "Summarize our infrastructure decisions"
|
|
- Test DERP functionality: "Reconstruct session from Feb 13"
|
|
- Verify workspace isolation (Pokerole can't see Operations)
|
|
|
|
**Hardware Reality Check:**
|
|
- Your TX1: 251GB RAM, 809GB storage, 32 cores
|
|
- Requirements: 16-32GB RAM, 50GB storage, 4+ cores
|
|
- **TX1 is massive overkill (good thing) ✅**
|
|
|
|
---
|
|
|
|
**Phase 4: Staff AI Assistant for Meg (2-3 hours)**
|
|
|
|
**PRIORITY SHIFT:** Meg is staff member #1. Deploy immediately after Phase 3 (not "when staff wiki exists")
|
|
|
|
**Why Meg Needs This Now:**
|
|
- Meg = The Emissary = Staff member #1 (not future staff, current staff)
|
|
- Meg doesn't have Claude access
|
|
- Meg needs to self-serve answers about:
|
|
- Social media posting guidelines (Fire vs Frost content)
|
|
- Consultant personality traits for posts
|
|
- Subscription tier descriptions
|
|
- Who to contact for what (Michael? Breezehost? Payment processor?)
|
|
- Basic procedures and workflows
|
|
- **Every Meg question = Michael interruption**
|
|
- AI assistant = Meg self-serves 24/7
|
|
|
|
**Deploy Open WebUI for "Emissary Knowledge Base"**
|
|
- Start small: ~20-30 docs (not 50-100, grow over time)
|
|
- Built-in Chroma vector DB sufficient (small dataset)
|
|
- Simple web interface (easier on Meg's tech comfort)
|
|
- Domain: staff-ai.firefrostgaming.com (or emissary-ai.firefrostgaming.com)
|
|
|
|
**Initial Knowledge Base (Emissary Focus):**
|
|
1. **Emissary Social Media Handbook** (already exists in `docs/planning/`)
|
|
- Fire path vs Frost path content strategy
|
|
- Posting schedule, content pillars
|
|
- Platform-specific guidelines
|
|
2. **Consultant Profiles** (`docs/relationship/consultant-profiles.md`)
|
|
- Jack, Oscar, Butter, Jasmine, Noir personalities
|
|
- Photo reference for social media posts
|
|
- Lore and character traits
|
|
3. **Subscription Tiers** (`docs/planning/subscription-tiers.md`)
|
|
- Tier names, prices, benefits
|
|
- How to describe each tier in marketing
|
|
4. **Basic Contact Reference**
|
|
- Who handles what (Michael = infrastructure, Breezehost = hosting, etc.)
|
|
- Emergency contacts
|
|
- Escalation paths
|
|
5. **Origin Story** (`docs/relationship/origin-story.md`)
|
|
- Brand storytelling reference
|
|
- How Michael & Meg met (Donna's Restaurant)
|
|
|
|
**Configuration:**
|
|
1. Create "Emissary Knowledge Base" in Open WebUI
|
|
2. Upload Meg-relevant docs only (operations manual stays private in AnythingLLM)
|
|
3. Set up Meg's account (simple username/password, no complicated auth)
|
|
4. Test with real Meg questions:
|
|
- "What personality traits should I emphasize for Jack in social posts?"
|
|
- "When should I post Fire path content vs Frost path content?"
|
|
- "How do I describe the Awakened tier to potential subscribers?"
|
|
- "Who do I contact if someone has a billing issue?"
|
|
- "What's the origin story of Firefrost Gaming?"
|
|
5. Train Meg on usage (15 min: "Type question, hit enter, get answer")
|
|
6. Monitor first week, add docs based on Meg's actual questions
|
|
|
|
**Benefits:**
|
|
- ✅ Reduces Michael interruptions immediately (Meg self-serves)
|
|
- ✅ 24/7 availability (Meg can ask at 2 AM if she's working)
|
|
- ✅ Builds Meg's confidence with tech (success with AI → confidence for NextCloud later)
|
|
- ✅ Proves concept before recruiting more staff
|
|
- ✅ **Recruitment advantage:** "We have AI assistant" = professional operation
|
|
- ✅ Consistent answers (AI doesn't forget, doesn't give conflicting info)
|
|
- ✅ Foundation grows: Add docs as staff grows, knowledge base scales naturally
|
|
|
|
**Accessibility Win:**
|
|
- Simple interface (type question, get answer)
|
|
- No complex menus or navigation
|
|
- Mobile-friendly (Meg can use on phone)
|
|
- No Git, no terminal, no technical barriers
|
|
|
|
**Timeline:**
|
|
- **Was:** "When staff wiki deployed" (Month 4+)
|
|
- **Now:** Session 6, immediately after AnythingLLM ingestion complete
|
|
- **Impact:** Meg gets AI assistant 4-6 months earlier
|
|
|
|
---
|
|
|
|
**TX1 Resources After Full Deployment:**
|
|
|
|
**Before AI Stack:**
|
|
- Games: 20GB RAM, 24GB storage
|
|
|
|
**After AI Stack:**
|
|
- Games: 20GB RAM, 24GB storage
|
|
- AI Models: 100GB RAM, 95GB storage
|
|
- Vector DB + Embeddings: 20GB RAM, 60GB storage
|
|
- **Total: 140GB RAM / 251GB = 56% usage ✅**
|
|
- **Total: 179GB storage / 809GB = 22% usage ✅**
|
|
|
|
**Plenty of headroom for growth.**
|
|
|
|
---
|
|
|
|
**After Completion:**
|
|
- ✅ DERP backup operational (Claude.ai dies → self-hosted continues)
|
|
- ✅ Unlimited AI access ($0 vs Claude Pro $20/month = $240/year saved)
|
|
- ✅ Staff assistant reduces support burden
|
|
- ✅ Full repo context for decision-making (1,000+ docs semantic search)
|
|
- ✅ Workspace isolation (Operations separate from Pokerole separate from Staff)
|
|
- ✅ Proven to scale: 5,000+ document libraries in production
|
|
- ✅ Self-healing via Git: repos update → workspaces re-ingest automatically
|
|
|
|
---
|
|
|
|
### 10. Netdata Deployment
|
|
**Time:** 1-2 hours
|
|
**Domain:** analytics.firefrostgaming.com
|
|
**Why:** Real-time infrastructure monitoring and performance analytics
|
|
**Location:** Command Center or dedicated monitoring
|
|
|
|
**Scope:**
|
|
- Deploy Netdata for server analytics
|
|
- Monitor: Command Center, TX1, NC1, Ghost VPS
|
|
- Real-time metrics: CPU, RAM, disk, network, services
|
|
- Alerts for threshold breaches
|
|
- Historical data retention
|
|
|
|
**Configuration:**
|
|
1. Install Netdata on each monitored server
|
|
2. Configure parent-child relationship (Command Center = parent)
|
|
3. Set up Nginx reverse proxy for analytics.firefrostgaming.com
|
|
4. Configure SSL certificate
|
|
5. Set up alert notifications (email or Discord webhook)
|
|
6. Document in `docs/deployment/netdata.md`
|
|
|
|
**After Completion:**
|
|
- ✅ Real-time infrastructure visibility
|
|
- ✅ Proactive problem detection
|
|
- ✅ Performance optimization data
|
|
- ✅ Historical trends for capacity planning
|
|
|
|
---
|
|
|
|
## 📋 TIER 3: PLANNING & DESIGN
|
|
|
|
Infrastructure deployed, now design the systems that use it.
|
|
|
|
### 11. Department Structure & Access Control Matrix
|
|
**Time:** 2-3 hours design
|
|
**Priority:** HIGH
|
|
**Blocks:** MkDocs decommission, wiki deployments, Discord reorganization
|
|
**Deliverable:** `docs/planning/access-control-matrix.md`
|
|
|
|
**Scope:**
|
|
Unified role-based access control across all platforms:
|
|
- **Ghost** (firefrostgaming.com) — Public storefront, no auth needed
|
|
- **Subscriber Wiki** (subscribers.firefrostgaming.com) — Gated member content
|
|
- **Staff Wiki** (staff.firefrostgaming.com) — Internal operations, department-restricted
|
|
- **Discord** — Role/channel structure mirroring department access
|
|
|
|
**Top Tier (Full Access):**
|
|
- Michael (The Wizard)
|
|
- Meg (The Emissary)
|
|
- Claude (The Chronicler)
|
|
|
|
**Departments to Define:**
|
|
- Moderation
|
|
- Server Administration
|
|
- Content / Social Media
|
|
- Community Events
|
|
- Builder Team (future)
|
|
- Development (future)
|
|
|
|
**Questions to Answer:**
|
|
- What can each department access?
|
|
- Permission inheritance model?
|
|
- Who can create/edit what content?
|
|
- How do Discord roles map to wiki permissions?
|
|
- Subscriber vs staff access boundaries?
|
|
|
|
**After Completion:**
|
|
- ✅ Clear access model for all platforms
|
|
- ✅ Unblocks wiki deployment
|
|
- ✅ Foundation for Discord reorganization
|
|
- ✅ Recruitment-ready structure
|
|
|
|
---
|
|
|
|
### 12. MkDocs Decommission
|
|
**Time:** 1-2 hours
|
|
**Depends On:** Access control matrix complete
|
|
**Why:** Ghost handles public content, Subscriber Wiki handles gated content, MkDocs redundant
|
|
**Location:** docs.firefrostgaming.com (Ghost VPS)
|
|
|
|
**Decommission Steps:**
|
|
1. Audit current MkDocs content
|
|
2. Migrate needed content to Ghost or Subscriber Wiki (based on access matrix)
|
|
3. Remove Uptime Kuma monitor for docs.firefrostgaming.com
|
|
4. Tear down MkDocs service on Ghost VPS
|
|
5. Release Nginx config and SSL cert (redirect to Ghost or retire domain)
|
|
6. Archive `docs/deployment/mkdocs.md` to `docs/archive/deployment/`
|
|
7. Update references in: project-scope, infrastructure-manifest, session-handoff, DOCUMENT-INDEX
|
|
8. Log in CHANGELOG.md
|
|
|
|
**After Completion:**
|
|
- ✅ Simplified architecture (Ghost + 2 wikis, not 3 separate systems)
|
|
- ✅ Reduced maintenance burden
|
|
- ✅ Clear content model
|
|
|
|
---
|
|
|
|
### 13. Fix Frostwall vs Firefrost Naming
|
|
**Time:** 30 minutes
|
|
**Why:** Prevent confusion as both systems develop
|
|
**Issue:** Design bible incorrectly calls UI age-verification gate "The Frostwall Protocol"
|
|
|
|
**Clarification:**
|
|
- **Frostwall** = Network defense ONLY (GRE topology, UFW, DDoS protection, hub-and-spoke)
|
|
- **Firefrost** = Visual/brand concepts (UI transitions, age verification, Ignis Protocol, player paths)
|
|
|
|
**Actions:**
|
|
1. Update design bible: "Frostwall Protocol" → "Firefrost Gate" (or similar)
|
|
2. Document Frostwall properly in `docs/deployment/frostwall-protocol.md`
|
|
3. Update architecture decisions (ADR-005 already exists, verify consistency)
|
|
4. Grep repo for incorrect usage, fix any other instances
|
|
|
|
**After Completion:**
|
|
- ✅ Clear naming prevents future confusion
|
|
- ✅ Network and brand systems properly distinguished
|
|
|
|
---
|
|
|
|
### 14. Scope Document Corrections
|
|
**Time:** 15 minutes
|
|
**Why:** Keep documentation accurate
|
|
**File:** `docs/core/project-scope.md`
|
|
|
|
**Issues to Fix:**
|
|
- Billing location missing → Add: Chicago, IL
|
|
- Ghost location missing → Add: Chicago, IL
|
|
- Panel location incomplete → Add: Charlotte, NC
|
|
- "GitHub mirror removed" → Correct to: "GitHub kept as private backup"
|
|
|
|
**Actions:**
|
|
1. Update project-scope.md with corrections
|
|
2. Verify infrastructure-manifest.md is correct
|
|
3. Quick grep for other instances of these errors
|
|
4. Commit with message noting corrections
|
|
|
|
---
|
|
|
|
### 15. Workflow Guide Review & Trim
|
|
**Time:** 1 hour
|
|
**File:** `docs/core/workflow-guide.md` (938 lines)
|
|
**Issues:** Still calls Claude "The Wizard" instead of "The Chronicler", potentially redundant
|
|
|
|
**Actions:**
|
|
1. Read full workflow-guide.md
|
|
2. Update all "The Wizard" → "The Chronicler" references
|
|
3. Check for redundancy with:
|
|
- SESSION-HANDOFF-PROTOCOL.md
|
|
- claude-relationship-context.md
|
|
- Current practices
|
|
4. Trim redundant sections
|
|
5. Keep valuable workflow patterns not documented elsewhere
|
|
6. Update revision history
|
|
|
|
**After Completion:**
|
|
- ✅ Accurate role references
|
|
- ✅ Leaner, more focused document
|
|
- ✅ No duplicate information across docs
|
|
|
|
---
|
|
|
|
## 🎨 TIER 4: BRANDING & CONTENT
|
|
|
|
Foundation solid, now build visual identity and content systems.
|
|
|
|
### 16. Terraria Branding Training Arc
|
|
**Time:** 12 weeks (self-paced)
|
|
**Priority:** HIGH
|
|
**Why Critical:** Foundation for ALL Firefrost visual branding
|
|
**Blocks:** Among Us expansion, Minecraft resource packs, Discord emojis, all visual content
|
|
**Location:** Deploy TShock server on TX1 or NC1
|
|
|
|
**Strategic Rationale:**
|
|
Foundation building BEFORE community expansion. Terraria = Michael's training ground for becoming Firefrost's brand designer. 2D sprite work maps to existing Cricut/Glowforge skills. Skills transfer to ALL future branding.
|
|
|
|
**Phase 1: Infrastructure (Week 1)**
|
|
- Deploy TShock Terraria server on Pterodactyl
|
|
- Configure basic world (Fire district + Frost district spawn town)
|
|
- Set up texture pack development environment (GIMP installed)
|
|
- Document Cricut → GIMP workflow
|
|
|
|
**Phase 2: Foundations (Week 1-2)**
|
|
- First texture edit (single item or block)
|
|
- Test texture pack installation and loading
|
|
- Create version control workflow for assets
|
|
- Document lessons learned
|
|
|
|
**Phase 3: Starter Pack (Week 3-4)**
|
|
- Create Firefrost Starter Pack (5-10 cohesive textures)
|
|
- Define Fire vs Frost visual language (colors, shapes, aesthetics)
|
|
- Test with small group for feedback
|
|
- Iterate based on feedback
|
|
|
|
**Phase 4: Consultant Pack (Week 5-6)**
|
|
- Create The Five Consultants pet pack (Jack, Oscar, Butter, Jasmine, Noir)
|
|
- Community feedback loop
|
|
- Refine based on player reactions
|
|
|
|
**Phase 5: Advanced Techniques (Month 2)**
|
|
- Custom spawn town (Fire + Ice districts via TEdit)
|
|
- Full UI overhaul
|
|
- Custom NPC dialogue (Fire/Frost themed)
|
|
- Economy system with Firefrost currencies
|
|
|
|
**Phase 6: Master System (Month 3+)**
|
|
- Complete visual identity guide
|
|
- Skills transfer to Minecraft resource packs
|
|
- Skills transfer to Among Us skins (when Phase 2 expansion ready)
|
|
- Template system for rapid asset creation
|
|
|
|
**Success Metrics:**
|
|
- ✅ Michael comfortable creating textures independently
|
|
- ✅ Firefrost visual identity defined and documented
|
|
- ✅ Skills proven transferable to other games/platforms
|
|
- ✅ Community positive feedback on custom assets
|
|
|
|
**After Completion:**
|
|
- ✅ Michael = Firefrost brand designer
|
|
- ✅ Unlocks Among Us Phase 2 (Fire/Frost skins ready Day 1)
|
|
- ✅ Unlocks Minecraft resource packs
|
|
- ✅ Unlocks Discord emoji packs
|
|
- ✅ Unlocks all visual subscriber perks
|
|
|
|
---
|
|
|
|
### 17. Paymenter Theme Installation — Citadel Theme
|
|
**Time:** 1-2 hours
|
|
**Depends On:** Terraria branding complete (visual identity established)
|
|
**Location:** Billing VPS (38.68.14.188, Chicago, IL)
|
|
**Theme:** https://builtbybit.com/resources/citadel-theme-paymenter.82217/
|
|
|
|
**Why After Branding:**
|
|
- Citadel theme needs customization to match Firefrost visual identity
|
|
- Fire/Frost color palette should be established first
|
|
- Logo and branding assets needed for theme integration
|
|
|
|
**Installation Steps:**
|
|
1. Download Citadel theme
|
|
2. Install via Paymenter theme manager
|
|
3. Customize colors to match Fire/Frost palette
|
|
4. Upload Firefrost logo and branding assets
|
|
5. Configure theme settings
|
|
6. Test checkout flow
|
|
7. Deploy to production
|
|
|
|
**After Completion:**
|
|
- ✅ Professional billing portal
|
|
- ✅ Visual consistency across all platforms
|
|
- ✅ Branded subscriber experience
|
|
|
|
---
|
|
|
|
### 18. Consultant Photo Processing
|
|
**Time:** 3-4 hours (batched, 10 photos at a time)
|
|
**Status:** 56 unprocessed photos + 4 Snapchat exports
|
|
**Priority:** Fill gaps between heavy work, front-load in sessions
|
|
|
|
**Process:**
|
|
1. Upload batch of 10 photos to Claude
|
|
2. Identify subjects (Jack, Oscar, Jasmine, Butter, Noir)
|
|
3. Write lore descriptions
|
|
4. Rename using convention: `YYYY-MM-DD_subject-description-keywords_01.jpg`
|
|
5. Organize into year folders (2020-2025)
|
|
6. Commit via Gitea API
|
|
7. Update `photos/catalog.md` with new entries
|
|
|
|
**Remaining Work:**
|
|
- 56 photos on Michael's local machine
|
|
- 4 Snapchat exports in `photos/images/unknown/`
|
|
|
|
**After Completion:**
|
|
- ✅ Complete consultant photo archive
|
|
- ✅ All photos properly cataloged and dated
|
|
- ✅ Lore documented for each image
|
|
- ✅ Git history preserves timeline
|
|
|
|
---
|
|
|
|
### 19. NextCloud Upload Portal for Meg
|
|
**Time:** 2-3 hours
|
|
**Depends On:** Terraria/branding work gives Meg confidence in tech
|
|
**Location:** downloads.firefrostgaming.com (NextCloud, already deployed)
|
|
|
|
**The Problem:**
|
|
Meg isn't tech-savvy and will never use Git. She needs dead-simple method to upload photos/videos that end up in repo.
|
|
|
|
**The Solution:**
|
|
- "Emissary Uploads" folder in NextCloud
|
|
- Meg drags/drops files via browser or mobile app
|
|
- Backend automation: renames to convention, commits to Git
|
|
- Notifications to Michael when files uploaded
|
|
|
|
**Implementation:**
|
|
1. Create "Emissary Uploads" folder in NextCloud
|
|
2. Set up Meg's NextCloud account with appropriate permissions
|
|
3. Install NextCloud mobile app on Meg's phone
|
|
4. Create visual tutorial (PDF with phone screenshots, big arrows, simple steps)
|
|
5. Backend: Command Center automation script monitors folder
|
|
6. Script: detects new files → renames → commits to `photos/` → notifies Michael
|
|
7. Test full workflow end-to-end
|
|
|
|
**After Completion:**
|
|
- ✅ Meg can contribute photos effortlessly
|
|
- ✅ Fire path event documentation (Meg's social media posts)
|
|
- ✅ Consultant photos from Meg's perspective
|
|
- ✅ Automated Git integration (no manual work)
|
|
|
|
---
|
|
|
|
### 20. "Coming Soon" Video Creation (CapCut)
|
|
**Time:** 15 minutes (Michael test), 20 minutes (Meg learns + creates)
|
|
**Depends On:** None - assets already exist ✅
|
|
**Priority:** Quick win for announcements
|
|
**Assigned:** Michael tests first, then train Meg
|
|
|
|
**Purpose:**
|
|
Create professional 10-15 second "Coming Soon" video for:
|
|
- Server launches
|
|
- Recruitment announcements
|
|
- Social media hype
|
|
- General Firefrost branding
|
|
|
|
**Assets Needed (Already Have):**
|
|
1. `branding/backgrounds/fire-frost-collision.png` (2560x1259)
|
|
2. `branding/logos/firefrost-logo-dark.png` (960x877)
|
|
3. `branding/logos/firefrost-emblem-512.png` (380x383)
|
|
|
|
**Tool:** CapCut (free, mobile or desktop)
|
|
- iPhone/Android: Download from App Store/Google Play
|
|
- Desktop: https://www.capcut.com/download
|
|
|
|
**Video Structure:**
|
|
```
|
|
[0-3s] Fire-frost collision background, slow zoom
|
|
[3s] White flash (impact)
|
|
[3-5s] Logo reveals with cyan glow
|
|
[5-12s] "COMING SOON" text (Orbitron font, #00E5FF)
|
|
[12-15s] Emblem + "firefrostgaming.com"
|
|
```
|
|
|
|
**Step-by-Step Recipe:**
|
|
1. Import fire-frost-collision.png (3 seconds, slow zoom)
|
|
2. Add dark vignette filter (40%)
|
|
3. At 3s: Add white flash transition (0.3s)
|
|
4. Add logo overlay (firefrost-logo-dark.png)
|
|
5. Add cyan glow effect to logo (#00E5FF, 30% intensity)
|
|
6. At 5s: Add text "COMING SOON" (Orbitron/Bebas Neue, size 72, cyan)
|
|
7. At 12s: Fade to black, add small emblem
|
|
8. At 12.5s: Add "firefrostgaming.com" text (white, size 36)
|
|
9. Add epic cinematic music (search "Epic Trailer" in CapCut sounds)
|
|
10. Add impact sound at flash moment
|
|
11. Export: 1080p, 30fps
|
|
|
|
**Output:**
|
|
- Vertical version (9:16, 1080x1920) - Instagram Reels, TikTok, Stories
|
|
- Horizontal version (16:9, 1920x1080) - YouTube, Twitter, Facebook
|
|
|
|
**Detailed Recipe:**
|
|
Complete step-by-step instructions documented separately for accessibility.
|
|
|
|
**After Completion:**
|
|
- ✅ Michael validates quality (test first)
|
|
- ✅ Train Meg on CapCut (15-20 min training session)
|
|
- ✅ Meg can create announcement videos independently
|
|
- ✅ Ready-to-post content for any major announcement
|
|
- ✅ Professional brand presence on social media
|
|
|
|
**Future Enhancements:**
|
|
- After Terraria training: Add custom Fire/Frost particle effects
|
|
- Use Pika Labs/Runway ML to animate static images (upgrade quality)
|
|
- Create variations for different announcements (New Server, Recruitment, Events)
|
|
|
|
---
|
|
|
|
## 🎮 TIER 5: GAME INFRASTRUCTURE OPTIMIZATION
|
|
|
|
Branding established, now optimize game operations.
|
|
|
|
### 21. Staggered Server Restart System
|
|
**Time:** 2-3 hours (Phase 1), future enhancement (Phase 2)
|
|
**Why:** ATM10 memory leak mitigation, prevent all servers down simultaneously
|
|
**Priority:** MEDIUM
|
|
|
|
**The Problem:**
|
|
- All The Mods 10 suffers from memory leaks
|
|
- Needs periodic restarts
|
|
- Currently manual or all-at-once (bad player experience)
|
|
|
|
**Phase 1 — Quick Win (Command Center Script):**
|
|
|
|
**Features:**
|
|
- Config-file driven (easy add/remove servers, no script edits)
|
|
- Three restart tiers:
|
|
- Heavy modpacks: 6-hour cycle (ATM10, etc.)
|
|
- Mid modpacks: 12-hour cycle
|
|
- Light modpacks: 24-hour cycle
|
|
- 5-minute stagger between servers on same node (prevent load spike)
|
|
- Simultaneous across nodes (TX1 and NC1 are separate hardware)
|
|
- Warning messages to players before each restart (5 min, 1 min, 30 sec)
|
|
- Logs every restart to Git (audit trail)
|
|
- Lives in automation system on Command Center
|
|
|
|
**Config Example:**
|
|
```yaml
|
|
heavy_tier:
|
|
- server: atm10-nc1
|
|
interval: 6h
|
|
- server: enigmatica9-tx1
|
|
interval: 6h
|
|
|
|
mid_tier:
|
|
- server: create-above-beyond-tx1
|
|
interval: 12h
|
|
|
|
light_tier:
|
|
- server: vanilla-nc1
|
|
interval: 24h
|
|
```
|
|
|
|
**Implementation:**
|
|
1. Workshop session with Michael (gather requirements, may have ideas)
|
|
2. Build script with Pterodactyl API integration
|
|
3. Create config file template
|
|
4. Test with single server
|
|
5. Deploy to all servers
|
|
6. Monitor for issues
|
|
7. Document in `docs/deployment/staggered-restart-system.md`
|
|
|
|
**Phase 2 — Blueprint Extension (Future):**
|
|
- Custom Pterodactyl panel extension via Blueprint framework
|
|
- GUI for managing restart schedules
|
|
- Publishable to Blueprint marketplace
|
|
|
|
**After Completion:**
|
|
- ✅ ATM10 memory leak managed automatically
|
|
- ✅ Better player experience (staggered, not all-at-once)
|
|
- ✅ Reduced manual intervention
|
|
|
|
---
|
|
|
|
### 22. Game Server Startup Script Audit & Optimization
|
|
**Time:** 3-4 hours
|
|
**Why:** Recurring issues trace back to startup scripts
|
|
**Scope:** All 12 game servers (6 TX1, 6 NC1)
|
|
|
|
**The Problem:**
|
|
Multiple issues have traced back to startup scripts. Need systematic audit and optimization.
|
|
|
|
**Priority Server:**
|
|
- All The Mods 10 (NC1) — Struggling with only 1 user connected
|
|
- Likely: JVM flags, memory allocation, or garbage collection misconfiguration
|
|
- ATM10 is heavy modpack, needs aggressive tuning
|
|
|
|
**Audit Plan:**
|
|
1. Pull every game server startup script via Pterodactyl panel
|
|
2. Document current configuration for each server
|
|
3. Identify common issues:
|
|
- Memory allocation (Xms, Xmx settings)
|
|
- JVM flags (G1GC, CMS, etc.)
|
|
- Mod loading order
|
|
- Timeout settings
|
|
- aikar's flags vs alternatives
|
|
4. Research optimal settings for each modpack type
|
|
5. Establish baseline "good" startup template per modpack category
|
|
6. Optimize each server's startup script individually
|
|
7. Create reference doc: `docs/reference/game-server-startups.md`
|
|
8. Test each server after changes
|
|
9. Monitor via Uptime Kuma for stability post-optimization
|
|
|
|
**After Completion:**
|
|
- ✅ Standardized, optimized startup scripts
|
|
- ✅ ATM10 performance issues resolved
|
|
- ✅ Documented baseline for future servers
|
|
- ✅ Reduced recurring startup issues
|
|
|
|
---
|
|
|
|
### 23. LuckPerms MySQL Backend
|
|
**Time:** 2-3 hours
|
|
**Why:** Centralized permission management, better performance
|
|
**Scope:** Switch from file-based to MySQL backend for all game servers
|
|
|
|
**Current State:**
|
|
- LuckPerms using file-based storage (YAML)
|
|
- Permissions stored locally on each server
|
|
- Difficult to sync changes across network
|
|
- No centralized management
|
|
|
|
**Migration Plan:**
|
|
1. Set up MySQL database (can use existing game server MySQL or dedicated)
|
|
2. Configure LuckPerms to use MySQL backend
|
|
3. Migrate existing permissions from YAML to MySQL
|
|
4. Test permission inheritance
|
|
5. Deploy to all servers using LuckPerms
|
|
6. Verify cross-server permissions work correctly
|
|
7. Document in `docs/deployment/luckperms-mysql.md`
|
|
|
|
**After Completion:**
|
|
- ✅ Centralized permission management
|
|
- ✅ Better performance (MySQL vs YAML parsing)
|
|
- ✅ Easier to manage cross-server permissions
|
|
- ✅ Foundation for network-wide ranks
|
|
|
|
---
|
|
|
|
### 24. World Backup Automation
|
|
**Time:** 2-3 hours
|
|
**Why:** Disaster recovery for game worlds
|
|
**Scope:** Automated backups to NextCloud for all game servers
|
|
|
|
**Current State:**
|
|
- Manual backups or Pterodactyl scheduled backups (local only)
|
|
- No off-site backup solution
|
|
- Risk of data loss if node fails
|
|
|
|
**Automation Plan:**
|
|
1. Create backup script on Command Center
|
|
2. Use Pterodactyl API to trigger backups
|
|
3. Download backup files from each server
|
|
4. Upload to NextCloud (off-site storage)
|
|
5. Retention policy:
|
|
- Daily backups: Keep 7 days
|
|
- Weekly backups: Keep 4 weeks
|
|
- Monthly backups: Keep 3 months
|
|
6. Automated cleanup of old backups
|
|
7. Alert on backup failure
|
|
8. Document in `docs/deployment/world-backup-automation.md`
|
|
|
|
**After Completion:**
|
|
- ✅ Off-site world backups (disaster recovery)
|
|
- ✅ Automated, no manual intervention
|
|
- ✅ Retention policy prevents storage bloat
|
|
- ✅ Peace of mind
|
|
|
|
---
|
|
|
|
### 25. Blueprint Extension Installation — Node Usage Status
|
|
**Time:** 30 minutes
|
|
**Location:** Pterodactyl Panel (45.94.168.138, Charlotte, NC)
|
|
**Extension:** https://builtbybit.com/resources/node-usage-status.59502/
|
|
|
|
**What It Does:**
|
|
- Monitor node resource usage directly in Pterodactyl panel
|
|
- Visual display of CPU, RAM, disk usage
|
|
- Helps identify resource constraints quickly
|
|
|
|
**Installation:**
|
|
1. Download Node Usage Status extension
|
|
2. Install via Blueprint framework
|
|
3. Configure display settings
|
|
4. Test on both TX1 and NC1 nodes
|
|
5. Document in panel usage guide (if exists)
|
|
|
|
**After Completion:**
|
|
- ✅ Quick visibility into node resources
|
|
- ✅ Easier capacity planning
|
|
- ✅ Identify resource hogs faster
|
|
|
|
---
|
|
|
|
## 🔮 TIER 6: FUTURE / DEFERRED (Month 4+ or 2027)
|
|
|
|
Important but blocked by earlier work or strategically deferred.
|
|
|
|
### 26. Discord Server Complete Reorganization
|
|
**Time:** Design 2-3 hours, Implementation 1-2 hours
|
|
**Depends On:** Branding complete, recruitment active, 15 servers operational
|
|
**Timeline:** After Terraria training, recruitment success
|
|
|
|
**Context:**
|
|
- Full Discord structure designed (docs/archive/2026-02-09-consolidation/discord-structure-complete.md)
|
|
- Design from Feb 8, 2026 may need revision
|
|
- Account for new servers (Terraria launch, server count changes)
|
|
- Update Fire/Frost path channels if needed
|
|
|
|
**Scope:**
|
|
- Review current Discord vs documented plan
|
|
- Determine: implement existing plan OR redesign from scratch
|
|
- Implement channel reorganization (manual Discord work)
|
|
- Update roles to match access control matrix
|
|
- Configure permissions per channel/role
|
|
|
|
**Reference:** `docs/archive/2026-02-09-consolidation/discord-structure-complete.md`
|
|
|
|
**After Completion:**
|
|
- ✅ Discord aligned with access control matrix
|
|
- ✅ Clear Fire/Frost path structure
|
|
- ✅ Recruitment-ready server organization
|
|
|
|
---
|
|
|
|
### 27. Firefrost: The Eternal Skyforge (Flagship Modpack)
|
|
**Time:** Months of development
|
|
**Depends On:** Branding skills established, builders recruited, Meg recovered
|
|
**Timeline:** 2027 launch (Q1-Q4 phased rollout)
|
|
|
|
**Vision:**
|
|
Custom flagship modpack showcasing Firefrost brand. Fire vs Frost dual progression, custom quests, branded assets throughout.
|
|
|
|
**Components:**
|
|
- Custom modpack (70-120 mods curated)
|
|
- FTB Quests: Dual progression trees (Fire path vs Frost path)
|
|
- World Gen: Skyblock with private islands
|
|
- Custom structures: Great Hall, Flamehall, Crystal Spire
|
|
- Custom textures/assets (from Terraria training)
|
|
- Integrated economy
|
|
- Path-specific rewards and advancement
|
|
|
|
**Dependencies:**
|
|
- Michael's branding skills (Terraria training complete)
|
|
- Builder team recruited
|
|
- Meg recovered (social media launch)
|
|
- Testing infrastructure ready
|
|
|
|
**After Completion:**
|
|
- ✅ Flagship server that embodies Firefrost brand
|
|
- ✅ Unique player experience not available elsewhere
|
|
- ✅ Foundation for long-term community growth
|
|
|
|
---
|
|
|
|
### 28. Among Us Weekly Events (Phase 2 Expansion)
|
|
**Depends On:** Terraria branding complete, Fire/Frost skins ready
|
|
**Timeline:** Month 4+ after branding skills established
|
|
**Why Deferred:** Launch Among Us WITH Fire/Frost skins Day 1, not vanilla
|
|
|
|
**Strategic Decision:**
|
|
Among Us expansion was planned for early 2026. Deliberately deferred until Michael can create custom Fire/Frost Among Us skins. This ensures brand consistency from Day 1 rather than launching vanilla and adding branding later.
|
|
|
|
**When Ready:**
|
|
- Weekly Discord events (Friday/Saturday nights)
|
|
- Fire path vs Frost path teams
|
|
- Custom skins showcase Firefrost brand
|
|
- Gateway to bring players to Minecraft servers
|
|
- Terraria-trained branding skills enable rapid skin creation
|
|
|
|
**After Completion:**
|
|
- ✅ Community expansion beyond Minecraft
|
|
- ✅ Weekly engagement events
|
|
- ✅ Gateway mechanic for recruitment
|
|
- ✅ Brand-consistent experience across all games
|
|
|
|
---
|
|
|
|
## ✅ COMPLETED TASKS (For Reference)
|
|
|
|
### DERP - The Oscar Protocol
|
|
**Completed:** February 13, 2026
|
|
**Completed By:** The Seventh (Chronicler the Seventh)
|
|
**Location:** `docs/core/DERP.md`
|
|
|
|
**Scope Delivered:**
|
|
- ✅ Alternative LLMs if Claude.ai disappears (Gemini, GPT-4)
|
|
- ✅ Git forensics and session reconstruction
|
|
- ✅ Quick recovery from tasks.md, session-handoff.md, Git log
|
|
- ✅ Posthumous Chronicler reconstruction template
|
|
- ✅ Critical contacts & failsafes
|
|
|
|
**Key Insight:** "Easy peasy lemon squeezy" — Repo + SESSION-START-PROMPT.md = any LLM can continue. Methodology is LLM-agnostic. Partnership survives provider failure.
|
|
|
|
---
|
|
|
|
## 📊 DEPENDENCY CHAINS (Visual Map)
|
|
|
|
```
|
|
MEDICAL CLEARANCE
|
|
↓
|
|
════════════════════════════════════════════════════════════════════════
|
|
TIER 0: IMMEDIATE WINS
|
|
════════════════════════════════════════════════════════════════════════
|
|
├── [1] Whitelist Manager (standalone)
|
|
├── [2] Command Center Cleanup (standalone)
|
|
└── [3] NC1 Cleanup ────────────────────────┐
|
|
│
|
|
════════════════════════════════════════════════│═════════════════════
|
|
TIER 1: SECURITY FOUNDATION │
|
|
════════════════════════════════════════════════│═════════════════════
|
|
├── [4] Vaultwarden (deployed, finish) ────┐│
|
|
│ ├── Part A: Add SSH key ││
|
|
│ └── Part B: Org for Meg ││
|
|
│ ││
|
|
├── [5] Frostwall Protocol (CRITICAL) ─────┼┼─┐
|
|
│ └── PROTECTS all services │││
|
|
│ │││
|
|
├── [6] Security Hardening │││
|
|
│ │││
|
|
└── [7] Scoped Gitea Token ←──────────────┘││
|
|
└── DEPENDS ON Vaultwarden ││
|
|
││
|
|
════════════════════════════════════════════════││═════════════════════
|
|
TIER 2: MAJOR INFRASTRUCTURE ││
|
|
════════════════════════════════════════════════││═════════════════════
|
|
├── [8] Mailcow on NC1 ←───────────────────┴┴─┐
|
|
│ └── NEEDS NC1 cleanup + Frostwall │
|
|
│ │
|
|
├── [9] AI Stack on TX1 ──────────────────────┐│
|
|
│ ├── Phase 1: Deploy ││
|
|
│ ├── Phase 2: Load models ││
|
|
│ ├── Phase 3: Gitea integration ││
|
|
│ └── Phase 4: Staff assistant ││
|
|
│ ││
|
|
└── [10] Netdata (monitoring) ││
|
|
││
|
|
════════════════════════════════════════════════││═════════════════════
|
|
TIER 3: PLANNING & DESIGN ││
|
|
════════════════════════════════════════════════││═════════════════════
|
|
├── [11] Access Control Matrix ─────────────┐││
|
|
│ └── BLOCKS wikis, Discord │││
|
|
│ │││
|
|
├── [12] MkDocs Decommission ←─────────────┘││
|
|
│ └── NEEDS access matrix ││
|
|
│ ││
|
|
├── [13] Fix Frostwall naming (docs) ││
|
|
├── [14] Scope doc corrections ││
|
|
└── [15] Workflow guide trim ││
|
|
││
|
|
════════════════════════════════════════════════││═════════════════════
|
|
TIER 4: BRANDING & CONTENT ││
|
|
════════════════════════════════════════════════││═════════════════════
|
|
├── [16] Terraria Training (12 weeks) ──────┐││
|
|
│ └── UNLOCKS all visual branding │││
|
|
│ ├→ Among Us skins │││
|
|
│ ├→ Minecraft packs │││
|
|
│ └→ Discord emojis │││
|
|
│ │││
|
|
├── [17] Paymenter Theme ←─────────────────┘││
|
|
│ └── NEEDS Firefrost visual identity ││
|
|
│ ││
|
|
├── [18] Photo Processing (parallel anytime) ││
|
|
│ ││
|
|
└── [19] NextCloud for Meg ←────────────────┘│
|
|
└── After training builds confidence │
|
|
│
|
|
════════════════════════════════════════════════│═════════════════════
|
|
TIER 5: GAME OPTIMIZATION │
|
|
════════════════════════════════════════════════│═════════════════════
|
|
├── [20] Staggered Restart System ←─────────┘
|
|
├── [21] Startup Script Audit
|
|
├── [22] LuckPerms MySQL
|
|
├── [23] World Backup Automation
|
|
└── [24] Blueprint Extension
|
|
|
|
════════════════════════════════════════════════════════════════════════
|
|
TIER 6: FUTURE (Month 4+ or 2027)
|
|
════════════════════════════════════════════════════════════════════════
|
|
├── [25] Discord Reorganization
|
|
├── [26] The Eternal Skyforge (2027)
|
|
└── [27] Among Us Phase 2
|
|
```
|
|
|
|
---
|
|
|
|
## 🎯 RECOMMENDED SESSION PLAN (When Home & Cleared)
|
|
|
|
### Session 1 (2-3 hours): Quick Wins
|
|
1. Whitelist Manager (1 hour)
|
|
2. Command Center Cleanup (15 min)
|
|
3. NC1 Cleanup (30 min)
|
|
4. Add SSH key to Vaultwarden (5 min)
|
|
5. **Checkpoint:** Test whitelist manager, verify cleanups
|
|
|
|
### Session 2 (4-5 hours): The Frostwall
|
|
1. Deploy The Frostwall Protocol (3-4 hours)
|
|
2. Test tunnel connectivity
|
|
3. Verify game traffic routing
|
|
4. Migrate Frostwall docs to repo (30 min)
|
|
5. **Checkpoint:** GRE tunnels operational, IPs hidden
|
|
|
|
### Session 3 (2-3 hours): Security & Vaultwarden Complete
|
|
1. Vaultwarden Org setup for Meg (25 min)
|
|
2. Command Center security hardening (1 hour)
|
|
3. Create scoped Gitea token (15 min)
|
|
4. Test Meg's Vaultwarden access
|
|
5. **Checkpoint:** All credentials secured, Meg has access
|
|
|
|
### Session 4 (4-5 hours): Major Infrastructure - Email
|
|
1. Deploy Mailcow on NC1 (3 hours)
|
|
2. Configure DNS (SPF, DKIM, DMARC)
|
|
3. Create initial email addresses
|
|
4. Test deliverability
|
|
5. **Checkpoint:** Email operational, test send/receive
|
|
|
|
### Session 5 (30 min active, then overnight): AI Stack Start
|
|
1. Deploy Ollama + Open WebUI on TX1 (30 min)
|
|
2. Start model downloads (overnight)
|
|
3. **Checkpoint:** Downloads running, come back tomorrow
|
|
|
|
### Session 6 (4-5 hours): AI Stack Complete + Meg's Assistant
|
|
1. Verify AnythingLLM workspaces fully ingested
|
|
2. Test DERP functionality (reconstruct session from repo)
|
|
3. Deploy Open WebUI for Meg (2 hours)
|
|
4. Create "Emissary Knowledge Base" (Social Media Handbook, Consultant Profiles, etc.)
|
|
5. Train Meg on usage (15 min: show her how to ask questions)
|
|
6. Test with real Meg questions
|
|
7. **Checkpoint:** Full AI stack operational, Meg can self-serve 24/7
|
|
|
|
### Session 7 (1-2 hours): Monitoring
|
|
1. Deploy Netdata (1-2 hours)
|
|
2. Configure alerts
|
|
3. **Checkpoint:** Real-time infrastructure visibility
|
|
|
|
### Session 8+ (2-4 hours each): Pick Based on Energy
|
|
- Tier 3: Access matrix, MkDocs decommission, doc cleanups
|
|
- Tier 4: Start Terraria training (ongoing 12 weeks)
|
|
- Tier 5: Game optimizations as needed
|
|
- Photo processing: Fill gaps between heavy work
|
|
|
|
---
|
|
|
|
## 📈 TASK STATISTICS
|
|
|
|
**Total Tasks:** 28 (27 actionable + 1 completed reference)
|
|
|
|
**By Tier:**
|
|
- Tier 0: 3 tasks (<2 hours total)
|
|
- Tier 1: 4 tasks (5-7 hours total)
|
|
- Tier 2: 3 tasks (7-10 hours total)
|
|
- Tier 3: 5 tasks (5-7 hours total)
|
|
- Tier 4: 5 tasks (12 weeks + ~10 hours + 15 min video)
|
|
- Tier 5: 5 tasks (~13-17 hours total)
|
|
- Tier 6: 3 tasks (future/deferred)
|
|
|
|
**Time to Foundation Complete (Tiers 0-2):** ~15-20 hours across 7 sessions
|
|
|
|
**Quick Wins (<1 hour each):** 7 tasks
|
|
**Medium Tasks (1-3 hours):** 11 tasks
|
|
**Major Tasks (3+ hours):** 6 tasks
|
|
**Long-term (weeks/months):** 3 tasks
|
|
|
|
**Critical Path to Operations:**
|
|
1. Medical clearance
|
|
2. Tier 0 quick wins (2 hours)
|
|
3. Vaultwarden finish (30 min)
|
|
4. Frostwall deployment (4 hours)
|
|
5. Mailcow + AI stack (8 hours)
|
|
6. **= Operational foundation in ~15 hours**
|
|
|
|
---
|
|
|
|
**Fire + Frost + Foundation = Where Love Builds Legacy** 💙🔥❄️
|