Monitor task for tracking unnumbered legacy tasks.
Documents standard for new tasks and archive threshold.
Next available task number: #101
Chronicler #69
Per Gemini consultation:
- Separate Projects for different work contexts
- Master Documents in Project Knowledge
- Micro-session workflow to prevent context bloat
- Dev Project: MVC, Arbiter, Trinity Console docs
- Ops Project: Handoffs, infrastructure, tasks
- Marketing Project: Brand, FOMO, social platforms
Ready for implementation next session (browser work only).
Chronicler #66 - The Indexer
Per Gemini consultation on model switching:
- Added future expansion section for Chronicler Orchestration Layer
- Middleware routing (Haiku/4.5/4.6 based on query type)
- Compressed state management (not raw history)
- RAG for historical context queries
- Prompt caching at API level
Saved consultation: docs/consultations/2026-04-07-model-switching.md
Long-term solution integrated into Codex roadmap.
Short-term: exploring Claude Projects optimization.
Chronicler #66 - The Indexer
- Bot command to auto-create category + 4 channels per server
- Includes delete command for server retirement
- QoL improvement for Holly
- Updated backlog with new task (MEDIUM priority)
Chronicler #66
Task #92 (Desktop MCP):
- Added Buffer MCP server config for Claude Desktop
- Example prompts for social media management
- Added Buffer API Key to Vaultwarden storage list
- Cross-referenced Task #48 and #97
Task #48 (n8n Rebuild):
- Created task folder with README
- Buffer MCP Client node configuration
- Automation workflow ideas (subscriber posts, server alerts, etc.)
- Priority workflows to build
Buffer MCP covers Bluesky, X, TikTok via single API.
Facebook/Instagram still require Meta Business Suite.
Chronicler #65
WHAT THIS IS:
Trinity Console feature to manage staggered restart schedules
for all 21 Minecraft servers across TX1 and NC1 nodes.
FEATURES:
- Visual timeline showing restart sequence
- Configurable base time + interval per node
- Drag-and-drop sort order for boot priority
- One-click sync to Pterodactyl API
- Audit system to detect/remove conflicting schedules
- Rate-limited API calls (200ms delay)
- Full audit trail logging
DATABASE TABLES:
- global_restart_config (node settings)
- server_restart_schedules (per-server state)
- sync_logs (audit trail)
DEFAULT PATTERN:
- TX1: 04:00 UTC, 5-min intervals
- NC1: 04:30 UTC, 5-min intervals
CONSULTATION:
Full architecture session with Gemini AI (April 5, 2026)
IMPLEMENTATION:
Complete code provided - ready for next Chronicler
Signed-off-by: Claude (Chronicler #60) <claude@firefrostgaming.com>
Problem: Servers without -TX/-NC in name don't appear in Trinity Console
Root cause: Grouping logic filters by name substring, not node ID
Affected: 6 of Holly's new servers not showing
Fix requires:
1. Update discovery.js to include nodeId from API
2. Update servers.js to group by node ID instead of name
Waiting for: Michael to get home (needs MobaXterm + node IDs from Panel)
Sign-off: Claude (Chronicler #60)
Email: claude@firefrostgaming.com
KEY STORED:
- Converted PuTTY → OpenSSH format
- Saved in Vaultwarden as Secure Note
- All 6 servers documented with usernames
WORKFLOW CLARIFIED:
- Claude cannot access Vaultwarden directly
- Michael retrieves key and uploads to session
- Takes ~30 seconds
Signed-off-by: claude@firefrostgaming.com
ARCHIVED:
- Holly Builder Rank Setup — Holly is now Trinity partner, not staff
- Staff Onboarding Holly — same reason
UPDATED:
- Discord Role Auto-Assignment marked as 'may already work'
- Arbiter 3.0 has Stripe webhooks configured
- Cannot test until first real subscriber
- Reduced High Priority from 16-21 hrs to 12-16 hrs
- Critical path reduced to ~5-7 hours
Signed-off-by: claude@firefrostgaming.com
Decap CMS now has:
- Fixed logo on login screen
- Tasks collection at TOP of sidebar
- Full Firefrost branding (Fire/Frost/Arcane colors)
Signed-off-by: claude@firefrostgaming.com
Task #89: Staff Portal Consolidation
- Vision: firefrostgaming.com/admin becomes central hub
- Move Decap to /cms, Trinity Console to /admin
- One URL for all staff tools
- Estimated: 3-4 hours post-launch
Task #90: Add Tasks Collection to Decap CMS
- BLOCKERS.md at TOP of collections list
- Fire orange (#FF6B35) standout styling
- Meg/Holly can manage tasks without Git
- Estimated: 1-2 hours post-launch
Signed-off-by: claude@firefrostgaming.com
WHAT WAS DONE:
Added comprehensive Gemini AI architectural review to Task #87 with critical edge cases, code blocks, and implementation guidance
GEMINI REVIEW STATUS: ✅ ARCHITECTURE APPROVED
Review Date: March 30, 2026
Session: Continuation of Arbiter 2.0 development consultation
Outcome: Validated with 2 critical edge cases identified and solutions provided
EXECUTIVE SUMMARY FROM GEMINI:
"This is a brilliant enhancement. The 'We Don't Kick People Out' policy is incredibly community-forward and will build massive loyalty. Arbiter 2.1 is exactly the right scope for this."
CRITICAL ISSUES IDENTIFIED & RESOLVED:
1. STRIPE SMART RETRIES CONFLICT:
Problem: Stripe retries payments on Days 1,3,5,7 - Arbiter downgrades Day 3, Stripe charges Day 5
Result: User stuck on Awakened while PAYING for monthly tier
Solution: Listen for payment.succeeded webhook to re-upgrade if late payment clears
2. DOUBLE BUY EDGE CASE:
Problem: User in grace period buys NEW subscription instead of updating card
Result: Database tracks two active monthly subscriptions
Solution: UPSERT using email as unique key (code provided)
ARCHITECTURE QUESTIONS ANSWERED (8 of 8):
Q1: Is 3-day grace period sound?
A1: ✅ Yes, with payment.succeeded handler for Stripe retry compatibility
Q2: Database design (permanent_tier + monthly_tier)?
A2: ✅ Clean and effective, helper function provided for highest tier resolution
Q3: Should cleanup be daily 4 AM or more frequent?
A3: ✅ 4 AM perfect - batches writes, aligns with backups, avoids peak hours
Q4: Is chargeback handling appropriate?
A4: ✅ Immediate permanent ban validated, no concerns
Q5: Edge cases missing?
A5: ⚠️ YES - Stripe smart retries + Double Buy (both solved)
Q6: Security concerns with auto-downgrade to Awakened?
A6: ✅ No exploit possible (gaming system costs more than $1)
Q7: Better approach to one-time vs recurring?
A7: ✅ Two-column approach simplest and most sustainable
Q8: Should grace periods be configurable?
A8: Not addressed (implies hardcoded acceptable for v1)
ADDITIONAL CRITICAL QUESTION - PAYMENTER VS STRIPE WEBHOOKS:
Gemini's Strong Recommendation:
- ❌ DO NOT build polling system (fragile, wasteful, high maintenance)
- ✅ Listen to Stripe webhooks directly if Paymenter lacks granular events
- Event-driven architecture only (lightweight, sustainable)
Decision Tree:
1. Research Paymenter webhook events (BLOCKING)
2. If granular (payment_failed, succeeded, cancelled, chargeback) → use Paymenter
3. If generic (just "subscription.updated") → add /webhook/stripe endpoint
CODE BLOCKS PROVIDED (5 READY TO IMPLEMENT):
1. Database schema updates (4 new columns):
- permanent_tier TEXT DEFAULT 'awakened'
- monthly_tier TEXT DEFAULT NULL
- grace_period_start DATETIME DEFAULT NULL
- is_banned INTEGER DEFAULT 0
2. Tier resolver helper function:
- Hierarchy array (awakened → sovereign)
- getHighestTier(permanent, monthly) function
- Returns highest tier for Discord sync
3. Webhook handler skeleton:
- Ban check before processing
- payment_failed → start grace period
- payment_succeeded → clear grace period
- subscription_cancelled → handle cancellation
4. 4 AM grace period sweeper job:
- Finds users past 3-day grace
- Removes monthly_tier
- Updates Discord to permanent_tier
- Sends Day 3 email
5. UPSERT for double buy protection:
- ON CONFLICT(email) DO UPDATE
- Prevents duplicate subscription tracking
- Clears grace_period_start on new subscription
PAYMENTER RESEARCH REQUIREMENTS (BLOCKING):
Must verify these webhook events exist in Paymenter:
1. invoice.payment_failed (triggers Day 0)
2. invoice.payment_succeeded (critical for Stripe retry fix)
3. subscription.cancelled (user voluntarily cancels)
4. chargeback.created or dispute.created (immediate ban)
Research procedure documented:
1. Log into Paymenter admin
2. Find webhook settings
3. Check documentation
4. Test payment failure
5. Decide: Paymenter webhooks vs Stripe webhooks
If Stripe webhooks needed:
- Add /webhook/stripe endpoint
- Configure Stripe dashboard
- Get signing secret
- Implement signature verification
EMAIL COMMUNICATION STRATEGY:
Critical guidance from Gemini:
"Turn a billing failure into a positive community moment!"
Day 3 email must say:
"Your payment failed, but because you are part of the Firefrost family, we've secured your spot in the Awakened tier permanently so you don't lose access to the community."
Email tone requirements:
- Day 0: Factual, helpful
- Day 1: Friendly reminder
- Day 2: Urgent but kind
- Day 3: POSITIVE FRAMING (secured your spot permanently)
IMPLEMENTATION PRIORITY ORDER:
Phase 1: Database & Core Logic
1. Add 4 database columns
2. Build tier resolver helper
3. Implement UPSERT logic
Phase 2: Paymenter Research (BLOCKING)
4. Research webhook events
5. Decide Paymenter vs Stripe
6. Test payment failure
Phase 3: Webhook Handlers
7. Add ban check to all handlers
8. Implement payment_failed handler
9. Implement payment_succeeded handler (critical)
10. Implement subscription_cancelled handler
11. Implement chargeback handler
Phase 4: Cleanup & Email
12. Build 4 AM sweeper job
13. Create 4 email templates
14. Implement email sending
Phase 5: Testing
15. Unit test handlers
16. Integration test grace flow
17. Test Stripe retry scenario (critical)
18. Test double buy scenario
19. Test chargeback ban
SUCCESS CRITERIA UPDATED:
Added 3 new requirements based on Gemini review:
- Late payment (Stripe retry) clears grace and re-upgrades ✅
- UPSERT prevents double subscription tracking ✅
- Banned users cannot re-activate via webhooks ✅
OPEN QUESTIONS FOR IMPLEMENTATION:
1. Paymenter webhook events - what does it send?
2. Paymenter vs Stripe - which webhook source?
3. Email service - using Mailcow SMTP from 2.0?
4. Discord role IDs - exact IDs for all tiers?
5. Test environment - Paymenter test mode available?
GEMINI'S FINAL GUIDANCE:
"Take your time digging into the Paymenter logs. Just update the Arbiter 2.1 doc with what you find, and ping me whenever you are ready to start snapping the code together! 🔥❄️💙"
WHY THIS MATTERS:
Gemini caught a CRITICAL production bug before we wrote a single line of code:
- Stripe smart retries would have caused users to pay for monthly tier while stuck on Awakened
- Would have been nightmare to debug in production
- Fixed with payment.succeeded webhook handler
Architecture validated by same AI that built Arbiter 2.0 foundation. Ready to implement after Paymenter webhook research.
NEXT STEPS:
1. Research Paymenter webhooks when home (BLOCKING)
2. Decide Paymenter vs Stripe webhook source
3. Build Phase 1 (database + helpers)
4. Build Phase 3 (webhook handlers)
5. Build Phase 4 (cleanup + email)
6. Test thoroughly (especially Stripe retry scenario)
7. Deploy before soft launch
FILE: docs/tasks/arbiter-2-1-cancellation-flow/README.md
CHANGES: Added 15,000+ words of Gemini architectural review
STATUS: Architecture validated, ready for implementation
Signed-off-by: The Versionist (Chronicler #49) <claude@firefrostgaming.com>
WHAT WAS DONE:
Created comprehensive enhancement plan for Arbiter 2.1 adding subscription cancellation, grace periods, and offboarding automation
CRITICAL SOFT LAUNCH BLOCKER:
We have subscription onboarding (Arbiter 2.0) but NO unsubscribe process.
Cannot launch without defining what happens when someone cancels.
POLICY DECISIONS MADE (March 30, 2026):
1. Discord Role Removal: At end of billing period (user gets what they paid for)
2. Whitelist Grace: 30 days after cancellation (goodwill, might come back)
3. Payment Failure Grace: 7 days with email reminders (industry standard)
4. Chargeback: Immediate removal + flag account (fraud protection)
THIS IS AN ENHANCEMENT, NOT A REWRITE:
- Arbiter 2.0 foundation is solid (2,000 lines)
- Arbiter 2.1 adds ~1,000 lines of new code
- Preserves all existing functionality
- Adds new webhook event handlers
- Adds grace period system
- Adds automated cleanup job
ARCHITECTURE COMPONENTS:
1. DATABASE ENHANCEMENT (2 new tables):
- subscriptions: Track lifecycle and status
- grace_periods: Automated cleanup tracking
- Indexes for performance
2. NEW WEBHOOK HANDLERS (4 functions):
- handleSubscriptionCancelled() - 30-day whitelist grace
- handlePaymentFailed() - 7-day grace with reminders
- handleChargeback() - immediate removal
- handleSubscriptionExpired() - cleanup
3. SCHEDULED CLEANUP JOB (new file):
- Runs daily at 4 AM
- Removes Discord roles (billing period ended)
- Removes whitelists (30-day grace expired)
- Sends payment failure reminders (Day 3, Day 6)
- Converts expired payment failures to cancellations
4. EMAIL TEMPLATES (5 new files):
- subscription_cancelled.html
- payment_failed.html
- payment_failure_reminder_day3.html
- payment_failure_final_warning.html
- access_removed_payment_failure.html
5. WHITELIST MANAGER INTEGRATION:
- New service: whitelistService.js
- API call to remove from all servers
- Requires Whitelist Manager API endpoint
GRACE PERIOD FLOWS:
NORMAL CANCELLATION:
1. User cancels → Paymenter webhook
2. Arbiter updates database (status = cancelled)
3. Discord role stays until billing period ends
4. Whitelist stays 30 days after billing end
5. Cleanup job removes role at billing end
6. Cleanup job removes whitelist after 30 days
7. Emails sent at each step
PAYMENT FAILURE:
1. Payment fails → Paymenter webhook
2. Arbiter creates 7-day grace period
3. Email sent immediately ("update payment")
4. Day 3: Reminder email (4 days left)
5. Day 6: Final warning (24 hours)
6. Day 7: Convert to cancellation
7. Follow normal cancellation flow
CHARGEBACK:
1. Chargeback filed → Paymenter webhook
2. IMMEDIATE Discord role removal
3. IMMEDIATE whitelist removal
4. Account flagged (manual review required)
5. Email sent (account suspended)
6. Discord alert to Michael/Meg
TESTING REQUIREMENTS:
- Unit test each handler in isolation
- Integration test full cancellation flow
- Edge case testing (race conditions, API failures)
- Test with real Paymenter subscription
DEPLOYMENT STRATEGY:
Phase 1: Arbiter 2.0 deployment (validate onboarding)
Phase 2: Arbiter 2.1 development (this task)
Phase 3: Staging test (full flow validation)
Phase 4: Production deployment (careful monitoring)
DEPENDENCIES:
- Arbiter 2.0 deployed and validated
- Paymenter webhook event research (verify what events exist)
- Whitelist Manager API endpoint (/api/bulk-remove)
BLOCKS:
- Soft launch (must have cancellation before launching)
RELATED TASKS:
- Task #83: Paymenter → Pterodactyl integration
- Task #7: Whitelist Manager (needs API enhancement)
- Task #86: Whitelist Manager compatibility fix
- Task #2: LuckPerms rank system
GEMINI REVIEW REQUESTED:
Architecture consultation needed before implementation:
1. Grace period architecture sound?
2. Database tables properly designed?
3. Separate cleanup job vs integrated handlers?
4. Chargeback handling appropriate?
5. Edge cases missing?
6. Security concerns?
7. Better Whitelist Manager integration approach?
8. Should grace periods be configurable?
WHY THIS MATTERS:
Cannot soft launch without offboarding flow. Industry standard requires:
- Clear cancellation process
- Grace periods for payment failures
- Fair billing (access through paid period)
- Fraud protection (chargeback handling)
This completes the subscription lifecycle: onboard → maintain → offboard.
FILE: docs/tasks/arbiter-2-1-cancellation-flow/README.md (28,000+ words)
NEXT STEPS:
1. Run by Gemini for architecture review
2. Incorporate feedback
3. Research Paymenter webhook events
4. Build Arbiter 2.1 enhancement
5. Test thoroughly
6. Deploy before soft launch
Signed-off-by: The Versionist (Chronicler #49) <claude@firefrostgaming.com>
WHAT WAS DONE:
Created comprehensive task documentation for fixing Whitelist Manager after Panel v1.12.1 API breaking changes
PROBLEM IDENTIFIED:
- Whitelist Manager built against Panel v1.11.x API (February 2026)
- Panel upgraded to v1.12.1 on March 13, 2026
- API response format changed between versions
- All servers showing "UNKNOWN" status
- Server grouping broken (wrong counts, unknown servers)
- Status detection completely broken
ROOT CAUSE:
Python code still parsing old v1.11.x API format. Panel v1.12.1 changed:
- feature_limits → limits
- whitelist → whitelist_enabled
- Possible: environment variable structure
- Possible: nested object changes
IMPACT:
- ❌ Status detection broken (all servers show UNKNOWN)
- ❌ Server grouping broken (TX1 wrong count, unknown group appeared)
- ✅ Core functions likely still work (add/remove player)
- ✅ Workaround exists (use Panel console)
TASK DETAILS:
- Time estimate: 1-2 hours
- Priority: Tier 3 (workaround exists)
- Status: TO DO - BROKEN (needs fix when home)
FIX PROCEDURE DOCUMENTED:
1. SSH to Billing VPS (38.68.14.188)
2. Check service logs for API errors
3. Test Pterodactyl API manually to see new format
4. Update Python code to parse v1.12.1 format
5. Add fallback support for v1.11.x (backward compatibility)
6. Test with live servers
7. Restart service
8. Verify all servers show correct status
CODE CHANGES NEEDED (EXAMPLE):
Before: server['attributes']['feature_limits']['whitelist']
After: server['attributes']['limits']['whitelist_enabled']
Plus: Add .get() safety, fallback to old format, better error handling
CRITICAL REMINDER ADDED:
**ALWAYS check Whitelist Manager after Panel or Wings updates!**
Pterodactyl API can change between minor versions. After ANY Panel/Wings update:
1. Visit whitelist.firefrostgaming.com
2. Verify server statuses (not all UNKNOWN)
3. Check server grouping (correct counts)
4. Test add/remove player
5. If broken → Task #86 fix procedure
PREVENTION DOCUMENTATION:
- Post-update checklist created
- Version compatibility matrix started
- Health check endpoint design
- API versioning notes
- Best practices for defensive coding
WORKAROUND UNTIL FIXED:
Use Pterodactyl Panel console directly:
1. panel.firefrostgaming.com
2. Select server → Console tab
3. Commands: whitelist add/remove <username>
FUTURE ENHANCEMENTS:
- Panel version detection
- API format auto-detection
- /health endpoint for monitoring
- Better error messages
- Retry logic for failed API calls
WHY THIS MATTERS:
Whitelist Manager saves 96.7% time (15 min → 30 sec). That value is lost while broken. Fix is probably trivial (2-5 lines of code) but critical for operational efficiency.
This also establishes pattern: Any Panel/Wings update can break integrations. Must test ALL custom tools after updates.
FILES CREATED:
- docs/tasks/whitelist-manager-v1-12-compatibility/README.md (10,500+ words)
FILES MODIFIED:
- docs/core/tasks.md (added Task #86)
RELATED TASKS:
- Task #7: Whitelist Manager (original deployment)
- Task #47: Whitelist Manager Refinements (Mayview grouping)
- Task #3: Pterodactyl Panel Update v1.12.1 (what broke it)
Signed-off-by: The Versionist (Chronicler #49) <claude@firefrostgaming.com>
WHAT WAS DONE:
- Added ftbessentials.delhome permission to Awakened group
- This gives all subscribers ability to delete their homes using /delhome
WHY:
Everyone needs access to delete homes they've set. Without this
permission, players can set homes but can't remove them when needed.
Permission inherits automatically to all higher tiers.
FILES MODIFIED:
- docs/tasks/rank-system-deployment/rank-structure.md (1 line added)
COMMAND TO RUN:
/lp group awakened permission set ftbessentials.delhome true
Signed-off-by: Claude (Chronicler #49) <claude@firefrostgaming.com>
The top subscription tier is Sovereign, not Founder.
This has been corrected multiple times across sessions — fixing at source.
FILES UPDATED:
- docs/core/tasks.md
- docs/core/project-scope.md
- docs/tasks/rank-system-deployment/rank-structure.md
- docs/tasks/paymenter-pterodactyl-integration/README.md
- docs/archive/2026-02-09-consolidation/luckperms-structure.md
- docs/planning/subscription-tiers.md
- docs/planning/awakened-gateway.md
- docs/guides/subscription-automation-guide.md
- docs/guides/holly-discord-roles-setup.md
- docs/guides/holly-wanderer-permissions-setup.md
- docs/systems/arbiter-discord-role-mappings.md
- docs/branding/trinity-leadership-artwork.md
NOTE: References to 'founders' meaning Michael/Meg/Holly as company
founders were intentionally preserved. Only tier name updated.
Signed-off-by: claude@firefrostgaming.com
WHAT WAS DONE:
- Built browser dashboard (dashboard.html) showing installed vs latest version
for all Pterodactyl game servers
- Built PHP proxy (proxy.php + config.php) for Billing VPS deployment
- Created isolated Nginx server block (version-proxy.conf)
- Created full deployment guide (DEPLOYMENT-GUIDE.md)
ARCHITECTURE:
- PHP proxy at /var/www/version-proxy on Billing VPS (38.68.14.188)
- Isolated from Paymenter/Laravel routing — separate directory + port
- API keys (Pterodactyl ptlc_, CurseForge) live server-side only
- FTB packs: fully automatic via .manifest.json + FTB public API
- CurseForge packs: reads manifest.json, needs CF Project ID + API key
- config.php blocked from direct web access via Nginx
PENDING AT DEPLOYMENT:
- Verify port 8080 is free (ss -tlnp) before enabling Nginx block
- Fill real API keys into config.php on server
- Enter CurseForge Project IDs for CF packs (saved in localStorage)
COLLABORATION:
- PHP proxy architecture designed by Gemini (consultation session 2026-03-29)
- Dashboard HTML and detection logic by Chronicler #47
- Gemini identified Laravel routing conflict and content-type gotcha
WHY:
- Interim solution before full Blueprint extension (post-launch)
- Hands-off modpack update monitoring for staff
- Zero manual checking required after initial CF Project ID setup
Signed-off-by: claude@firefrostgaming.com
WHAT WAS DONE:
- Created docs/tasks/rank-system-deployment/rank-structure.md (canonical rank reference)
- Filled the missing file referenced in rank-system-deployment/README.md
CHANGES FROM v1.0 (luckperms-structure.md in archive):
- Removed Fire/Frost text from in-game prefixes (color carries the path)
- Removed emojis from prefixes (not supported in Minecraft chat)
- Added Admin rank: [Admin] #A855F7 (Trinity purple)
- Added Mod rank: [Mod] #9E9E9E (staff gray)
- Added full LuckPerms /lp command list for Holly to implement
- Added Trinity member assignment commands (frostystyle, gingerfury, unicorn20089)
- Added hex color format notes for chat plugin compatibility
WHY:
- Holly requested colors and a full permissions list to implement the rank system
- Existing archive doc had emoji/Fire/Frost prefix design that was revised
- rank-structure.md was referenced in README but never created
Signed-off-by: claude@firefrostgaming.com
Created task documentation for removing Plane from TX1 Dallas server.
Context:
- Plane v2.4.2 was successfully deployed with 5 projects, labels, members
- Gitea↔Plane sync via n8n had webhook loop issues (crash)
- Team switched to Gitea's built-in Kanban project boards
- Plane adds unnecessary complexity for minimal benefit
Task deliverables:
- Stop/remove Plane Docker containers on TX1
- Remove Nginx config for tasks.firefrostgaming.com
- Delete /opt/plane/ directory and volumes
- Remove or repurpose DNS record
- Archive n8n Plane workflows
- Update infrastructure-manifest.md
Documentation includes:
- Complete decommissioning steps with commands
- Verification checklist
- Context on why Plane didn't fit workflow
- What replaces it (Gitea Projects)
Priority: Tier 5 (Infrastructure Cleanup)
Time estimate: 30 minutes
Added to docs/core/tasks.md as Task #82
Created docs/tasks/plane-decommissioning/README.md
Session: March 26, 2026
Chronicler: #41
- Ghost CMS migrated from Casper to Source v1.5.2
- Created custom-home.hbs template for homepage rendering (Gemini solution)
- Fixed navbar styling: dark theme, logo left, links center, actions right
- Resolved Sign in button issue (translation helper + custom class fix)
- Social media setup guide completed (separate commit)
- Session handoff updated with complete migration documentation
- Task documentation for ghost-theme-migration completed
Migration eliminates CSS specificity battles and provides clean foundation
for future customization. Gemini consultations were critical for:
1. Custom template approach (custom-home.hbs)
2. Sign in button diagnosis ({{t}} helper failure)
All work tested and verified on production Ghost instance.
Active theme: source-theme-ready
Homepage: https://firefrostgaming.com
Next priorities: Homepage content sections + Paymenter configuration
COMPLETED: Cockpit web terminal deployed to all Firefrost servers
Deployment summary:
- Command Center (63.143.34.217:9090) - NEW
- Ghost VPS (64.50.188.14:9090) - Pre-existing
- Billing VPS (38.68.14.188:9090) - NEW
- Panel VPS (45.94.168.138:9090) - NEW
- TX1 Dallas (38.68.14.26:9090) - NEW
- NC1 Charlotte (216.239.104.130:9090) - NEW
All servers accessible via browser with root / Butter2018!!
(Ghost VPS uses architect / Butter2018!!)
Security improvements:
- Enabled UFW firewall on NC1 Charlotte (was unprotected)
- Proper game server port rules (25565-25580, 5520-5521)
- Wings SFTP port (2022) secured
Files created:
- docs/reference/cockpit-quick-reference.md - Complete access guide
- docs/tasks/nc1-security-monitoring/README.md - NC1 temp/firewall monitoring
Files updated:
- docs/tasks/cockpit-deployment/README.md - Marked COMPLETE
Result: Michael can now manage entire infrastructure from Chromebook
without SSH client dependency. Critical for Claude session workflow
(port 22 blocked in Claude sessions).
Actual deployment time: ~1.5 hours (including NC1 firewall setup)
Signed-off-by: The Chronicler <claude@firefrostgaming.com>
Complete deployment plan for installing Cockpit web terminal on all 5 remaining servers (Command Center, Billing VPS, Panel VPS, TX1, NC1). Ghost VPS already has Cockpit operational.
Files created:
- docs/tasks/cockpit-deployment/README.md - Task overview
- docs/tasks/cockpit-deployment/deployment-plan.md - Technical strategy
- docs/tasks/cockpit-deployment/installation-commands.md - Copy/paste micro-blocks
Why: Enable full server management from Chromebook without SSH dependency. Claude sessions block port 22, but Cockpit (port 9090) works perfectly.
Estimated time: ~1 hour for all 5 servers (~10 min each)
Signed-off-by: The Chronicler <claude@firefrostgaming.com>
Session 36 spent 2+ hours fighting Casper CSS specificity issues.
Even html body .class element !important gets overridden.
Gemini recommends migrating to Source theme (official, minimal, dev-friendly).
Task includes complete migration plan with rollback strategy.
Created permanent Discord invite and configured clean redirect.
Deliverables:
- Permanent invite: https://discord.gg/hDHvKfqhKs
- Branded redirect: firefrostgaming.com/discord
- Ghost redirects.json configured and tested
Users can now use firefrostgaming.com/discord for all marketing.
Next: Update homepage CTA button to use /discord
Completed: March 21, 2026
By: Michael + The Chronicler #36
Time: 15 minutes
Previous AI generation attempts failed - skins had incorrect UV mapping.
Created complete commission brief and artist hiring guide.
Ready to send to Fiverr/professional Minecraft skin artist.
Materials prepared:
- Complete commission brief with specs for all 3 characters
- Trinity reference image for artist
- Minecraft template reference
- Where to hire guide (Fiverr recommended)
Budget: $25-40 for all 3 skins
Timeline: 3-5 days
Blocks: Tasks #62-64 (skin uploads)
Created by: The Chronicler #36
The skins generated in previous session don't follow correct Minecraft
UV template format. They're character illustrations instead of proper
skin templates and won't work when uploaded to minecraft.net.
Created comprehensive fix documentation and Gemini prompt for regeneration.
Related: Tasks #61-64 (Trinity Minecraft skins)
Created by: The Chronicler #36
Created comprehensive guide for storing Firefrost SSH key in Vaultwarden.
Task #14: Store Firefrost SSH Key in Vaultwarden
Priority: TIER 0 - FOUNDATIONAL (unblocks all troubleshooting)
Time: 30 minutes
Key Details:
- File: Firefrost_key.ppk (PuTTY format, ssh-rsa, version 3)
- Uploaded by Michael on March 20, 2026
- Used by ALL 6 Firefrost servers (same key everywhere)
- Two formats needed: PuTTY (.ppk) for Windows, OpenSSH for Linux/macOS
Servers Using This Key:
1. Ghost VPS (64.50.188.14) - architect user
2. Billing VPS (38.68.14.188) - root
3. Panel VPS (45.94.168.138) - root
4. Command Center (63.143.34.217) - root
5. TX1 Dallas (38.68.14.26) - root
6. NC1 Charlotte (216.239.104.130) - root
Documentation Includes:
- Step-by-step PuTTY → OpenSSH conversion
- Vaultwarden storage procedure
- Organization setup for Meg (team sharing)
- Usage instructions for future Chroniclers
- Security considerations (DO/DON'T lists)
- File permissions requirements (chmod 600)
- Test connection procedure
- Verification checklist
Why This Matters:
- Unblocks ALL server troubleshooting (Ghost, Paymenter, everything)
- Future Chroniclers can SSH without asking Michael each time
- Enables real-time debugging during sessions
- Foundation for operational efficiency
- Secure team credential sharing
Security:
- Private key NOT committed to Git (security best practice)
- KEY-LOCATION.md documents WHERE key is stored (Vaultwarden)
- Instructions for secure retrieval and usage
Impact: FOUNDATIONAL - Makes all future server work 10x easier
Files:
- docs/tasks/vaultwarden-ssh-setup/README.md (complete guide)
- docs/tasks/vaultwarden-ssh-setup/KEY-LOCATION.md (reference only)
Next Chronicler: Execute Task #14 FIRST in Priority 0 (before skins)
For children not yet born. 💙🔥❄️
Created by: The Guide (Chronicler #35)
Create task for giving Claude (The Chronicler) Gitea API + SSH access to all servers.
Task #65: Grant Claude Full Infrastructure Access
Priority: HIGH
Time: 30-45 minutes
WHY:
- Claude currently creates issue TEMPLATES (not real issues)
- Claude must ask Michael to run every server command
- No autonomous incident response
- Significant time waste per session (45-100 min)
AFTER THIS TASK:
- Claude creates Gitea issues directly via API
- Claude SSHs to all 6 servers for diagnostics/fixes
- Autonomous incident response
- Reduced manual overhead for Michael
ACCESS NEEDED:
1. Gitea API Token
- Scopes: write:issue, write:repository, write:user, write:admin
- Enables: Create issues, manage users, repos, permissions
2. SSH Keys (ED25519)
- Deploy to all 6 servers (Command Center, Ghost, Billing, Panel, TX1, NC1)
- Store in Vaultwarden (encrypted)
- Enables: Service diagnostics, log reading, restarts, deployments
IMPLEMENTATION:
- Generate SSH key pair (ed25519)
- Deploy public key to ~/.ssh/authorized_keys on all servers
- Store private key in Vaultwarden
- Generate Gitea API token with admin scopes
- Update session start prompts with token
- Test SSH + API access
SECURITY:
- Private key NEVER in Git
- Encrypted in Vaultwarden
- API token ephemeral (session prompts only)
- Can revoke instantly if needed
- Full audit trail (Git commits, SSH logs, API logs)
BLOCKED BY:
- Task #6 (Vaultwarden SSH key storage - still pending)
ENABLES:
- Autonomous operations
- Direct server troubleshooting
- Programmatic issue management
- Incident response without human intervention
Time saved: 45-100 minutes per session
Over 35 Chroniclers = hundreds of hours saved
For children not yet born. 💙🔥❄️
Created by: The Guide (Chronicler #35)
