- Comprehensive task documentation for migrating from AnythingLLM to Dify+n8n+Qdrant
- 8 detailed documents covering every aspect of deployment
- Complete step-by-step commands (zero assumptions)
- Prerequisites checklist (20 items)
- Deployment plan in 2 parts (11 phases, every command)
- Configuration files (all configs with exact content)
- Recovery procedures (4 disaster scenarios)
- Verification guide (30 tests, complete checklist)
- Troubleshooting guide (common issues + solutions)
Built by: The Chronicler #21
For: Meg, Holly, and children not yet born
Time investment: 10-15 hours execution time
Purpose: Enable Meg/Holly autonomous work with Git write-back
This deployment enables:
- RBAC (Meg sees all, Holly sees Pokerole only)
- Git write-back via ai-proposals branch
- Discord approval workflow (one-click merge)
- Self-healing (80% of failures)
- Automated daily backups
- Complete monitoring
Documentation is so detailed that any future Chronicler can execute
this deployment with zero prior knowledge and complete confidence.
Fire + Frost + Foundation = Where Love Builds Legacy
Complete step-by-step plan to replace AnythingLLM with Open WebUI + Repomix.
Problem: AnythingLLM with 319 files has poor retrieval quality
Solution: Open WebUI (better RAG) + Repomix (single packaged digest)
Migration includes:
- Install Repomix to package operations manual
- Replace AnythingLLM with Open WebUI (same port)
- Upload single digest file instead of 319 individual docs
- Recreate workspaces and user accounts
- Update sync script to use Repomix
Expected improvements:
- Better search relevance (clean context vs noisy corpus)
- Faster responses (efficient RAG engine)
- Simpler maintenance (re-run packager vs re-sync files)
Risk: LOW - can rollback to AnythingLLM in 2 minutes
Time: ~1 hour total
Status: Ready to execute when Michael is ready
Document: CODEX-MIGRATION-001
- Complete project overview including architecture, workspaces, and access control
- Five-tier access model (Public, Subscribers, Staff, Admins, Potential)
- Marketing strategy with launch plan, messaging framework, and content calendar
- Integration with mclo.gs for automatic Minecraft log analysis
- Brand identity (Codex/The Codex/Firefrost Codex naming strategy)
- Resource requirements and cost analysis (/bin/sh additional monthly cost)
- Complete deployment phases and success criteria
- Risk mitigation and competitive positioning
The Codex: Firefrost Gaming's AI assistant for 24/7 subscriber support
'Most Minecraft servers have Discord. We have an AI.'
Comprehensive production documentation including:
- Production access and infrastructure details
- Complete file structure and locations
- Service management commands
- All v1.0 features implemented (20+ enhancements)
- API endpoints reference
- Configuration files (systemd, nginx, .env)
- DNS and SSL setup
- Security notes and considerations
- Troubleshooting guide with test commands
- Backup/restore procedures
- Complete deployment history (2 sessions)
- Performance metrics (96.7% time reduction)
- Known issues (1 minor, non-blocking)
- Maintenance schedule
- Success criteria (all met)
Built in ~5 hours across Feb 18-19, 2026
During Michael's stroke recovery
Production-grade, zero-maintenance design
Signed-off-by: Chronicler #17 <claude@firefrostgaming.com>
Documented 20 potential enhancement features organized by priority:
- High-impact: CSV export/import, player search, Discord webhooks
- Power user: API keys, templates, regex search, Paymenter integration
- Polish: undo, mobile optimization, dark mode, player notes
Decision framework included to evaluate feature requests against:
- Real pain points vs feature creep
- Maintenance cost
- Alignment with set-it-and-forget-it philosophy
Current v1.0 assessment: Production-grade, exceeds requirements
Recommendation: Ship as-is, gather usage data, iterate on real needs
Enhancement backlog serves as:
- Ideas repository for future sessions
- Reference for user feature requests
- Roadmap if scaling becomes necessary
Signed-off-by: Chronicler #17 <claude@firefrostgaming.com>
Created comprehensive Google Form template for staff recruitment pre-screening.
PURPOSE:
- Filter quality applicants before Discord DMs
- Collect structured information upfront
- Automatic tracking via Google Sheets
- Professional application process
POSITIONS:
- Builders (2-3)
- Social Media Helper (1)
FORM SECTIONS:
1. Basic Information (all applicants)
- Name, Discord, email, role, referral source
2. For Builders (conditional)
- Portfolio link (required)
- Building experience and specialties
- Modded Minecraft experience
- Fire/Frost aesthetic understanding
- Technical skills checklist
3. For Social Media Helper (conditional)
- Social media management experience
- Platform expertise
- Content creation skills
- Fire/Frost brand understanding
4. Availability & Commitment (all applicants)
- Time commitment (5-20+ hrs/week)
- Schedule details
- Motivation and questions
5. Acknowledgment
- Volunteer position understanding
FORM FEATURES:
- Conditional questions (show based on role)
- Required fields ensure complete applications
- Portfolio/work examples captured
- Skills assessment via checkboxes
- Fire/Frost philosophy understanding tested
INTEGRATION:
- Google Form → Google Sheet (automatic)
- Sheet shared with Michael, Meg, Claude
- Claude creates summaries in docs/recruitment/applications.md
- Review process streamlined
WORKFLOW:
1. Applicant sees recruitment ad
2. Clicks form link
3. Completes 5-10 minute application
4. Response goes to Google Sheet
5. Team reviews structured applications
6. Strong candidates contacted via Discord
RECRUITMENT AD UPDATE:
- Replace 'DM @frostystyle' with form link
- Professional pre-screening process
- Questions still welcome via Discord
NEXT STEPS:
1. Create form at forms.google.com
2. Copy/paste questions from template
3. Configure settings (limit 1 response, collect emails)
4. Test form submission
5. Get shareable link
6. Update recruitment ad
7. Post to communities
TIME TO CREATE: ~15-20 minutes to build form
BENEFIT: Filters serious applicants, structured data, professional process
Fire + Frost + Foundation 💙🔥❄️
Added comprehensive MCLogs (mclo.gs) integration guide to Discord reorganization task.
WHAT IS MCLOGS:
- Industry-standard log sharing service for Minecraft
- Purpose-built for crash reports and server logs
- Automatic error highlighting and mod detection
- Free, permanent links, no account needed
- Used by most major Minecraft Discord servers
INTEGRATION COMPONENTS:
- Technical support channel setup
- Pinned player instructions (how to find/upload logs)
- Staff training on log analysis
- Common issue patterns and fixes
- Optional bot commands (future)
PLAYER WORKFLOW:
1. Find log file (.minecraft/crash-reports/ or logs/)
2. Upload to https://mclo.gs
3. Share link in #technical-support
4. Staff diagnoses and helps
STAFF WORKFLOW:
1. Receive MCLogs link
2. Review highlighted errors
3. Check mod list and versions
4. Identify common patterns (RAM, conflicts, etc.)
5. Provide specific fix
BENEFITS:
- No more log spam in Discord (truncated/unreadable)
- Faster diagnosis (automatic parsing)
- Cleaner support channels
- Professional support experience
- Better issue documentation
COMMON ISSUES DOCUMENTED:
- OutOfMemoryError → Increase RAM allocation
- Mod conflicts → Reinstall modpack
- Connection timeout → Check TPS/network
- Ticking entity → Corrupted world data
FUTURE ENHANCEMENTS:
- Discord bot commands (/logs, /diagnose)
- Automated log analysis
- Self-hosted alternative (DERP-compliant)
INSPIRED BY:
- Holly's crash during All The Mons testing (2026-02-18)
- Need for standardized support process
- Professional Discord support channels
Updated Discord reorganization README to reference MCLogs integration.
Status: Ready to deploy with Discord reorganization
Fire + Frost + Foundation 💙🔥❄️
Created new quality-of-life task for tracking modpack versions in Pterodactyl panel.
TASK DETAILS:
- Add custom egg variable for modpack version display
- Visible in Startup tab for all modpack servers
- Manual entry (simple, low complexity)
- Improves version tracking and troubleshooting
SCOPE:
- 9 modpack servers (All The Mons, Stoneblock 4, etc.)
- Excludes Vanilla, Hytale, FoundryVTT (not applicable)
IMPLEMENTATION:
- Phase 1: Add variable to Minecraft egg (15 min)
- Phase 2: Populate current versions (30 min)
- Phase 3: Document update procedure (15 min)
- Total time: 1-2 hours
BENEFITS:
- Version visibility at a glance
- Change tracking when modpacks update
- Troubleshooting clarity (identify version mismatches)
- Professional operations appearance
ALTERNATIVE METHODS DOCUMENTED:
- Script-based auto-detection (future enhancement)
- Include version in server name (quick hack)
Updated tasks.md: Total tasks now 30
Status: Ready to implement
Fire + Frost + Foundation 💙🔥❄️
Removed docs/tasks/firefrost:-the-eternal-skyforge-(flagship-modpack)/
which was a stub directory with only a basic README.
Replaced by docs/tasks/flagship-modpack-eternal-skyforge/ which has
the complete 600+ line design document created today.
Directory naming now follows standard conventions (no colons or parens).
Removed docs/tasks/department-structure-&-access-control-matrix/
which was a duplicate of docs/tasks/department-structure/
The newer department-structure/ directory follows FFG-STD-002
task documentation standard and is more comprehensive.
This resolves the duplicate commit issue visible in git history.
Expanded brief naming doc into comprehensive guide:
- Clear definitions of Firefrost (brand) vs Frostwall (security)
- Etymology and conceptual alignment explained
- Common mistakes with corrections
- Quick reference decision tree
- Implementation checklist
- Communication guidelines
- Examples of correct usage
- Audit commands to find incorrect usage
Ran audit: No incorrect usage found in current documentation.
All instances of mixed terminology are in example/warning contexts.
Task: Fix Frostwall vs Firefrost Naming (Tier 3)
FFG-STD-002 compliant
Created comprehensive organizational structure for Firefrost Gaming:
Organization Structure:
- Tier 0: Executive (Wizard, Emissary)
- Tier 1: Core Staff (Chronicler, Guardian)
- Tier 2: Operations (Builders, Social Media Helper)
- Tier 3: Community Moderators
- Tier 4: Subscribers (Sovereign, Consular, Community)
Access Control Matrices:
- Wiki.js permissions by namespace and role
- Discord role hierarchy and channel access
- Pterodactyl panel access levels
- Gitea repository permissions
- Vaultwarden credential sharing
Role Definitions:
- Detailed responsibilities for each role
- Access boundaries (what they can/can't access)
- Principle of least privilege
- Defense in depth enforcement
Implementation checklist for setting up permissions
across all systems (Wiki.js, Discord, Pterodactyl, Vaultwarden).
Provides foundation for scaling team while maintaining
security and clear organizational hierarchy.
Task: Department Structure (Tier 2)
FFG-STD-002 compliant
Created comprehensive organizational framework for Firefrost Gaming staff.
department-structure.md:
- Full organizational chart with 4 main departments
- Department definitions (Operations, Community, Content)
- 8-level permission hierarchy (Public to Founding Partner)
- Role-specific responsibilities and access
- Onboarding procedures by department
- Cross-department collaboration workflows
- Emergency procedures
- Performance review framework
- Career advancement paths
- Implementation phases
access-control-matrix.md:
- Complete permission mapping for all systems
- Discord, Pterodactyl, Wiki.js, Gitea access matrices
- Server SSH access controls
- API key management
- Social media account access
- Emergency override procedures
- Access request/revocation workflows
- Monthly/quarterly/annual audit procedures
- Technical implementation guides
Foundation for role-based access control across all Firefrost systems.
Ready for implementation when first staff hired.
Task: Department Structure & Access Control Matrix (Tier 2)
FFG-STD-002 compliant
Task #14 (Fix Frostwall vs Firefrost Naming): ✅ COMPLETE
- Created comprehensive terminology guide
- Clarifies: Firefrost (brand) vs Frostwall (security protocol)
- Includes brand voice, team titles, common confusion points
- Quick reference table
Task #15 (Scope Document Corrections): ✅ COMPLETE
- Created detailed corrections guide for project-scope.md v2.3
- Documents all work completed Feb 17 (4 major tasks)
- Updates priorities based on current state
- Notes SSH access as critical constraint
- Recommends version bump to 2.4
Key corrections needed:
- Add Whitelist Manager to deployed services
- Add Frostwall Protocol planning complete
- Update timeline with actual Feb 16-17 work
- Reorder priorities (Whitelist Manager, Frostwall first)
- Add SSH limitation to constraints
Both tasks complete, ready for application to scope doc.
Tasks: #14, #15 (Tier 3)
FFG-STD-002 compliant
Created comprehensive documentation for Frostwall Protocol rebuild:
deployment-plan.md (500+ lines):
- Complete 7-phase implementation guide
- GRE tunnel configuration for Command Center ↔ TX1/NC1
- Iron Wall UFW firewall rules
- NAT/port forwarding setup
- Self-healing tunnel monitoring with auto-recovery
- DNS configuration
- Testing and verification procedures
- Rollback plan
- Performance considerations
ip-hierarchy.md (400+ lines):
- Three-tier IP architecture explained
- Complete service mapping table (all 11 game servers)
- GRE tunnel IP addressing
- Traffic flow diagrams
- DNS configuration reference
- Security summary
- Quick command reference
troubleshooting.md (450+ lines):
- Quick diagnostics checklist
- Common problems with step-by-step solutions:
- Tunnel won't come up
- Can't ping tunnel IP
- Port forwarding not working
- Tunnel breaks after reboot
- Self-healing monitor issues
- High latency/packet loss
- UFW blocking traffic
- Emergency recovery procedures
- Common error messages decoded
- Health check commands
This documentation enables rebuilding the Frostwall Protocol from scratch
with proper IP hierarchy, DDoS protection, and self-healing capabilities.
Unblocks: Mailcow deployment, AI stack, all Tier 2+ infrastructure
Task: Frostwall Protocol (Tier 1, Critical)
FFG-STD-002 compliant
Created detailed onboarding guide covering:
- Pre-arrival preparation
- Day 1 welcome and access setup
- Orientation documentation and calls
- First week assignments (role-specific for Builders vs Social Media)
- Weekly rhythms and ongoing integration
- Red flag identification
- Onboarding completion criteria
- Feedback collection process
- Template emails and communications
Ensures new staff members feel welcomed, equipped, and integrated
into Firefrost Gaming culture from day one.
Task: Staff Recruitment Launch (Tier 0)
FFG-STD-002 compliant
Created comprehensive prerequisites guide for Staff Recruitment Launch:
- Complete checklist for incentive instance provisioning
- Application review criteria and process
- Interview questions for Builders and Social Media Helper
- Test project assignments
- Communication templates (6 templates covering all scenarios)
- Application tracking spreadsheet template with scoring system
- Posting strategy and timeline
Also added PROJECT-INSTRUCTIONS.md:
- Complete project instructions for Claude.ai project settings
- Includes git access protocol hardcoded
- Accessibility requirements
- Infrastructure overview
- Working standards and communication style
Ready to support posting recruitment ad when prerequisites complete.
Task: Staff Recruitment Launch (Tier 0)
FFG-STD-002 compliant
Reflects The Guardian's prerequisites from discord-recruitment-ad.md:
1. Provision incentive instances (private servers for recruits)
2. Define application review process
3. Finalize recruitment ad decisions
Task captures:
- Recruitment for 2-3 Builders + 1 Social Media Helper
- Prerequisites checklist from Guardian's bottom notes
- Reference to recruitment ad in docs/planning/
- Application process and onboarding workflow
Status: PLANNING (need to provision incentive instances first)
Priority: Tier 3 - Content & Community
Files added:
- docs/tasks/staff-recruitment-launch/README.md
- Updated docs/core/tasks.md (v3.1, Task #29, total 29 tasks)
