WHAT WAS PREPARED: Monorepo structure, database migrations, documentation, and deployment checklist ready for Gemini's complete Trinity Console code delivery. DIRECTORY STRUCTURE CREATED: - src/routes/admin/ (admin routes) - src/views/admin/ (EJS templates for all pages) - src/views/components/ (reusable EJS components) - src/public/css/ (Tailwind CSS) - src/public/js/ (htmx + utilities) DATABASE MIGRATION: - migrations/trinity-console.sql - New tables: player_history, admin_audit_log, banned_users - Enhanced subscriptions: MRR, grace period, referrals - Indexes for performance - Complete schema documentation PACKAGE.JSON UPDATES: - Added EJS ^3.1.9 for server-side templating - Updated description to include Trinity Console - Ready for htmx (will be added to public/js) DOCUMENTATION: - TRINITY-CONSOLE.md: Complete feature overview, tech stack, philosophy - DEPLOYMENT-CHECKLIST.md: Step-by-step deployment guide for tomorrow - Covers all 10 deployment steps from database migration to go-live - Includes rollback plan, success criteria, testing procedures GEMINI CONSULTATION: Comprehensive implementation request sent to Gemini asking for: - Complete code for ALL THREE PHASES - All Express routes (dashboard, players, servers, financials, etc.) - All EJS views and components - Database migration SQL (already created) - htmx integration for reactive UI - Tailwind CSS styling - Server-Sent Events for real-time updates - Complete deployment guide FEATURES REQUESTED: Phase 1: Player table, server matrix, force sync, stats dashboard Phase 2: Grace period tracking, ban list, role audit, alerts Phase 3: Revenue analytics, player history, audit log, skins, export tools ARCHITECTURE DECISIONS (from Gemini): - Stay in Arbiter 3.0 (don't build separate app) - Use htmx for SPA-like reactivity (NO build pipeline for RV) - Use EJS for server-side rendering - Use Tailwind CSS for styling - Use SSE for real-time updates - Server-side pagination (don't load 500+ players) - 60-second Panel API caching (prevent rate limits) - Low-bandwidth RV mode (text-only view) DEPLOYMENT TIMELINE: - Tonight: Receive Gemini's complete code - Tomorrow 8am: Deploy database migration - Tomorrow 9am: Deploy code + npm install - Tomorrow 10am-2pm: Feature testing - Tomorrow 6pm: Go live for Trinity SOFT LAUNCH IMPACT: Trinity Console is NOT a blocker for soft launch (April 15). Arbiter 3.0 already handles subscriptions, whitelists, and Discord roles. Trinity Console adds operational intelligence, admin tools, and analytics. Deploy early to battle-test before first real subscribers. PHILOSOPHY: "Fire + Frost + Foundation = Where Love Builds Legacy" Built to be maintainable from an RV, scalable to hundreds of subscribers, and designed to last decades. FILES ADDED: - TRINITY-CONSOLE.md (complete documentation) - DEPLOYMENT-CHECKLIST.md (deployment guide) - migrations/trinity-console.sql (database schema) - src/routes/admin/index.js (placeholder for Gemini's code) - package.json (added EJS dependency) NEXT STEPS: 1. Receive complete implementation from Gemini 2. Populate src/routes/admin/* with Gemini's code 3. Populate src/views/admin/* with Gemini's EJS templates 4. Add htmx.min.js to src/public/js/ 5. Deploy tomorrow morning Signed-off-by: The Golden Chronicler <claude@firefrostgaming.com>
🔥❄️ Firefrost Services
Monorepo for Firefrost Gaming backend services
This repository contains all custom Node.js services that power Firefrost Gaming's subscription automation, game server management, and community tools.
📋 Services
Active Services
- Arbiter — Discord bot for subscription automation and role management
- Whitelist Manager — Pterodactyl Panel integration for Minecraft whitelist automation
- Modpack Version Checker — Monitors modpack updates across game servers
Experimental
- Future — Experimental services and proof-of-concept tools
🏗️ Architecture
This monorepo uses npm workspaces for dependency management and service-prefixed Git tags for versioning.
Repository Structure
firefrost-services/
├── package.json # Root workspace configuration
├── services/ # Production services
│ ├── arbiter/
│ ├── whitelist-manager/
│ └── modpack-version-checker/
├── shared/ # Shared utilities (@firefrost/shared)
└── future/ # Experimental services
Versioning Strategy
Each service versions independently using Git tags:
- Arbiter releases:
arbiter-v2.1.0,arbiter-v2.2.0 - Whitelist Manager:
whitelist-v1.0.0,whitelist-v1.1.0 - Modpack Checker:
modpack-v1.0.0
This allows Service A to be at v2.1 while Service B is at v1.0.
🚀 Quick Start
Initial Setup
# Clone repository
git clone https://git.firefrostgaming.com/firefrost-gaming/firefrost-services.git
cd firefrost-services
# Install all dependencies (services + shared)
npm install
Deploying a Service
# Fetch latest tags
git fetch --all --tags
# Check out specific service version
git checkout arbiter-v2.1.0
# Install dependencies
npm install
# Create .env file (copy from .env.example)
cd services/arbiter
cp .env.example .env
# Edit .env with actual credentials
# Start service (systemd)
sudo systemctl enable arbiter
sudo systemctl start arbiter
Updating a Service
# Return to main branch
git checkout main
# Pull latest code
git pull origin main
# Check out new version
git checkout arbiter-v2.2.0
# Install any new dependencies
npm install
# Restart service
sudo systemctl restart arbiter
Rolling Back
# Check out previous version
git checkout arbiter-v2.1.0
# Restart service
sudo systemctl restart arbiter
📦 Shared Code
The @firefrost/shared package contains utilities used across multiple services:
- Database helpers
- Discord formatting utilities
- Pterodactyl API wrappers
- Logging infrastructure
Services import shared code like any npm package:
import { logger } from '@firefrost/shared';
🔐 Environment Variables
IMPORTANT: Never commit .env files to Git.
Each service has an .env.example file showing required variables. On the server:
- Copy
.env.exampleto.env - Fill in actual credentials
- Ensure
.envis in.gitignore(it is by default)
🛠️ Development
Adding a New Service
- Create directory:
services/my-new-service/ - Add
package.jsonwith service name - Develop service
- Create
.env.examplewith required variables - Add systemd service file to
deploy/directory - Document in service README
- Tag initial release:
git tag my-service-v1.0.0
Using Shared Code
// In your service
import { logger, formatDiscordEmbed } from '@firefrost/shared';
logger.info('Service started');
Running Tests (Future)
# Run all service tests
npm test
# Run specific service tests
npm test -- --workspace=services/arbiter
📋 systemd Configuration
Each service includes a systemd unit file in deploy/. Example for Arbiter:
[Unit]
Description=Arbiter Discord Bot
After=network.target
[Service]
Type=simple
User=arbiter
WorkingDirectory=/var/www/firefrost-services/services/arbiter
ExecStart=/usr/bin/node src/index.js
Restart=always
RestartSec=10
StandardOutput=journal
StandardError=journal
[Install]
WantedBy=multi-user.target
Copy to /etc/systemd/system/, then:
sudo systemctl daemon-reload
sudo systemctl enable arbiter
sudo systemctl start arbiter
🎯 Deployment Targets
Services run on different servers based on their purpose:
| Service | Server | Location |
|---|---|---|
| Arbiter | Command Center | Dallas, TX |
| Whitelist Manager | Panel VPS | TBD |
| Modpack Checker | TX1 Dallas | Dallas, TX |
Each server clones the entire repo but only runs its designated services.
📚 Documentation
- Architecture Decision: See
operations-manual/docs/reference/architecture-decisions/firefrost-services-monorepo-decision.md - Service-specific docs: Each service has its own README in
services/[service-name]/ - Shared package docs: See
shared/README.md
🤝 Contributing
This repository is maintained by:
- Michael "Frostystyle" Krause (The Wizard) — Technical lead
- Meg "GingerFury" (The Emissary) — Community manager
- Holly "unicorn20089" (The Catalyst) — Lead builder
- Claude (The Chronicler) — AI partner
Contribution Workflow
- Create feature branch from
main - Develop and test changes
- Update service version in package.json
- Create PR to
main - After merge, tag release:
[service]-v[version]
🏷️ Version History
See Git tags for complete version history.
📄 License
Proprietary — All rights reserved by Firefrost Gaming.
This codebase is private and not licensed for public use or distribution.
Fire + Frost + Foundation = Where Love Builds Legacy 💙🔥❄️
For children not yet born.