265 lines
8.3 KiB
Markdown
265 lines
8.3 KiB
Markdown
# FIREFROST GAMING - TASKS & PROGRESS TRACKER
|
|
|
|
**Last Updated:** February 9, 2026
|
|
**Current Focus:** Phase 0.5 - Management Services Deployment
|
|
|
|
---
|
|
|
|
## 📊 PHASE 0.5 PROGRESS: 60% COMPLETE (3/5 Services)
|
|
|
|
### ✅ Completed Services
|
|
|
|
**Service 1/5: Gitea** (git.firefrostgaming.com)
|
|
- Status: DEPLOYED Feb 8, 2026
|
|
- IP: 74.63.218.202
|
|
- Purpose: Git repository for all infrastructure
|
|
- SSL: Active (Let's Encrypt)
|
|
- GitHub Mirror: Configured (auto-sync)
|
|
|
|
**Service 2/5: Uptime Kuma** (uptime.firefrostgaming.com)
|
|
- Status: DEPLOYED Feb 9, 2026
|
|
- IP: 74.63.218.203
|
|
- Purpose: Infrastructure monitoring
|
|
- SSL: Active (Let's Encrypt)
|
|
- Discord: Integrated (#network-status)
|
|
|
|
**Service 3/5: MkDocs** (docs.firefrostgaming.com)
|
|
- Status: DEPLOYED Feb 9, 2026
|
|
- IP: 74.63.218.204
|
|
- Purpose: PUBLIC documentation (Git-native)
|
|
- SSL: Active (Let's Encrypt)
|
|
- Theme: Material with search enabled
|
|
|
|
### ⏳ Pending Services
|
|
|
|
**Service 4/5: Wiki.js** (subscribers.firefrostgaming.com + staff.firefrostgaming.com)
|
|
- Status: NEXT - Ready to deploy
|
|
- IP: 74.63.218.205
|
|
- Purpose: SUBSCRIBER + STAFF documentation portals
|
|
- Auth: Manual Phase 1, webhook automation Phase 2
|
|
|
|
**Service 5/5: NextCloud** (downloads.firefrostgaming.com)
|
|
- Status: PLANNED
|
|
- IP: 74.63.218.206
|
|
- Purpose: World downloads for subscribers
|
|
- Retention: 30-day (90-day for Ascendant+)
|
|
|
|
---
|
|
|
|
## 🔧 TROUBLESHOOTING TASKS
|
|
|
|
### GitHub Mirror Access Issue
|
|
**Priority:** Medium
|
|
**Status:** ✅ RESOLVED
|
|
**Created:** Feb 9, 2026 1:15 PM CST
|
|
**Resolved:** Feb 9, 2026 1:35 PM CST
|
|
|
|
**Root Cause:**
|
|
Claude's security model requires at least ONE URL from a repository to be "user-provided" before accessing other files in that repo.
|
|
|
|
**Solution:** Repository Unlock Method
|
|
1. User pastes ONE raw GitHub URL from the repository
|
|
2. This "unlocks" the entire repository for Claude
|
|
3. Claude can now fetch ANY file from that repo automatically
|
|
4. No more URL pasting needed for that repository!
|
|
|
|
**Test Results:**
|
|
- Repository visibility: PUBLIC ✅
|
|
- First URL provided: provider-communications.md ✅
|
|
- Subsequent files accessible without pasting: session-handoff.md ✅, TASKS.md ✅
|
|
- Repository fully unlocked: ALL 28+ docs accessible ✅
|
|
|
|
**Actual Workflow (Even Better Than Expected):**
|
|
1. Michael pastes ONE raw GitHub URL from the repo (one-time unlock)
|
|
2. Claude can now read ANY file from that repo automatically
|
|
3. Zero additional URL pasting needed
|
|
|
|
**Benefits:**
|
|
- ONE paste unlocks entire repository (28+ files)
|
|
- Saves Michael's hands (no bash commands needed)
|
|
- Fast documentation access
|
|
- Works perfectly with automation system
|
|
|
|
**Repository Unlocked:**
|
|
- https://github.com/Frostystyle/firefrost-operations-manual (FULL ACCESS)
|
|
|
|
---
|
|
|
|
## 📋 INFRASTRUCTURE TASKS
|
|
|
|
### TX1 ↔ NC1 Communication Issue
|
|
**Priority:** Medium
|
|
**Status:** TICKET SENT TO BREEZEHOST
|
|
**Created:** Feb 9, 2026 1:10 PM CST
|
|
|
|
**Issue:**
|
|
TX1 Dallas and NC1 Charlotte cannot communicate directly. Dallas gateway returns "Destination Net Unreachable" immediately. Charlotte can route toward Dallas but packets timeout after 9 hops.
|
|
|
|
**Diagnostic Results:**
|
|
- TX1 → NC1: Complete failure at gateway (38.68.14.25 !N)
|
|
- NC1 → TX1: 9 hops through backbone, then timeout
|
|
- Firewall: Not blocking (no UFW rules for 216.239.x)
|
|
- Conclusion: Datacenter-level routing isolation
|
|
|
|
**Ticket Sent:**
|
|
Asked Breezehost if this is:
|
|
1. Known limitation between Dallas/Charlotte datacenters
|
|
2. Solvable with inter-DC routing configuration
|
|
3. Acceptable to implement VPN tunnel (WireGuard/OpenVPN) if needed
|
|
|
|
**Waiting On:** Breezehost response (Jon/Ryan/Brandon)
|
|
|
|
**Business Impact (If No Solution):**
|
|
- Cannot implement BungeeCord/Velocity proxy
|
|
- Cannot use centralized database architecture
|
|
- Cannot do direct server-to-server backups
|
|
- Must design around datacenter isolation
|
|
|
|
---
|
|
|
|
## 🚀 AUTOMATION SYSTEM
|
|
|
|
### Firefrost Automation Framework
|
|
**Status:** ✅ FULLY OPERATIONAL
|
|
**Deployed:** Feb 9, 2026
|
|
**Efficiency Gain:** 95% reduction in manual operations
|
|
|
|
**Key Benefits:**
|
|
- Michael pastes ONE command to queue tasks
|
|
- Daemon executes automatically (10s polling)
|
|
- Results auto-commit to Git
|
|
- Claude reads results from GitHub mirror
|
|
- Perfect for marathon sessions with hand limitations
|
|
|
|
**Usage:**
|
|
- Start daemon: `nohup bash automation/automation-daemon.sh > /dev/null 2>&1 &`
|
|
- Queue tasks: `cat > automation/queue/task-name.sh << 'EOF' ... EOF`
|
|
- Read results: https://raw.githubusercontent.com/.../automation/results/
|
|
|
|
---
|
|
|
|
## 📝 DOCUMENTATION UPDATES NEEDED
|
|
|
|
### After This Session
|
|
- [ ] Update FIREFROST-PROJECT-SCOPE-V2.md (GitHub unlock solution)
|
|
- [ ] Update workflow-guide.md (New documentation access method)
|
|
- [ ] Re-upload updated project files to Claude Project
|
|
|
|
---
|
|
|
|
## 🎯 NEXT PRIORITY: WIKI.JS DEPLOYMENT
|
|
|
|
**Target:** Complete Services 4-5 today (Feb 9, 2026)
|
|
**Method:** Use automation system (one paste per service)
|
|
**Goal:** Reach 100% Phase 0.5 completion
|
|
|
|
---
|
|
|
|
**END OF TASKS.md**
|
|
|
|
---
|
|
|
|
## 🎨 FUTURE ENHANCEMENTS
|
|
|
|
### Landing Pages for Subscriber & Staff Portals
|
|
**Priority:** Medium
|
|
**Status:** PLANNED
|
|
**Created:** Feb 9, 2026 1:45 PM CST
|
|
|
|
**Goal:**
|
|
Create landing pages for staff.firefrostgaming.com and subscribers.firefrostgaming.com root domains that serve as entry points to multiple tools/services.
|
|
|
|
**Current State (Phase 1):**
|
|
- Root domains auto-redirect to /codex (Wiki.js)
|
|
- Users go straight to documentation
|
|
- Simple, functional, gets us operational
|
|
|
|
**Future State (Phase 2):**
|
|
- Custom landing pages at root (`/`)
|
|
- Links to multiple services:
|
|
- 📖 The Codex (Wiki.js documentation)
|
|
- 🔧 Tools (future staff tools)
|
|
- 📊 Dashboard (future analytics/status)
|
|
- 📥 Downloads (NextCloud for subscribers)
|
|
- Secure access control (authenticate at landing page level)
|
|
|
|
**Design Considerations:**
|
|
- Fire/Frost visual identity (match Design Bible)
|
|
- Role-based content (subscribers see different options than staff)
|
|
- Mobile-responsive
|
|
- Fast load times
|
|
- SSO/authentication strategy (Phase 2 webhook automation)
|
|
|
|
**Security Requirements:**
|
|
- Authentication BEFORE accessing any services
|
|
- Session management
|
|
- Secure token handling
|
|
- Rate limiting on login attempts
|
|
|
|
**Technologies to Explore:**
|
|
- Static HTML + Tailwind CSS (simple, fast)
|
|
- Next.js (if we want dynamic content)
|
|
- Authentik or Authelia (SSO/authentication layer)
|
|
- Integration with Paymenter subscriber validation
|
|
|
|
**Next Steps:**
|
|
1. Complete Wiki.js deployment (Service 4)
|
|
2. Complete NextCloud deployment (Service 5)
|
|
3. Reach 100% Phase 0.5 completion
|
|
4. THEN discuss landing page architecture in dedicated session
|
|
|
|
**Discussion Topics for Future Session:**
|
|
- Authentication strategy (Phase 1 manual vs Phase 2 webhooks)
|
|
- Visual design (Frost vs Fire styling for each portal)
|
|
- Navigation structure (what tools/links appear on each portal)
|
|
- Mobile vs desktop experience
|
|
- Onboarding flow for new subscribers
|
|
|
|
---
|
|
|
|
|
|
### Configure Wiki.js Git Sync with Gitea
|
|
**Priority:** High
|
|
**Status:** PENDING - Deploy Wiki.js first
|
|
**Created:** Feb 9, 2026 2:00 PM CST
|
|
|
|
**Goal:**
|
|
Set up two-way Git synchronization between Wiki.js and Gitea for markdown-based documentation workflow.
|
|
|
|
**Prerequisites:**
|
|
- ✅ Wiki.js deployed and configured
|
|
- ⏳ Admin account created (mkrause612@gmail.com / Butter2018!!)
|
|
- ⏳ Initial setup wizard completed
|
|
|
|
**Implementation Steps:**
|
|
1. Create new Gitea repository: `firefrost-codex`
|
|
2. Initialize with folder structure:
|
|
- `/subscribers/` - Subscriber-facing guides
|
|
- `/staff/` - Internal procedures and planning
|
|
3. Configure Wiki.js Git sync:
|
|
- Repository URL: https://git.firefrostgaming.com/firefrost-gaming/firefrost-codex.git
|
|
- Authentication: Git credentials or SSH key
|
|
- Sync mode: Two-way (Git ↔ Wiki.js)
|
|
- Sync interval: Every 5 minutes or manual trigger
|
|
4. Test workflow:
|
|
- Create page in Wiki.js → Verify appears in Git
|
|
- Create markdown file in Git → Verify appears in Wiki.js
|
|
5. Set up path-based permissions:
|
|
- Subscribers group: Read-only access to /subscribers/
|
|
- Staff group: Full access to /staff/
|
|
- Admin group: Full access everywhere
|
|
|
|
**Benefits:**
|
|
- Write in markdown (terminal/editor) OR web UI (Meg's preference)
|
|
- All content version controlled in Git
|
|
- Automatic sync both directions
|
|
- Perfect for Fire + Frost workflow (technical precision + creative editing)
|
|
|
|
**Next Steps:**
|
|
1. Wait for Wiki.js deployment to complete
|
|
2. Complete web setup wizard
|
|
3. Execute this configuration task
|
|
|
|
---
|
|
|