Removed Powered by Ghost footer via direct theme edit.
Dark theme CSS injection documented.
Font injection documented.
Task #39 in progress — Chronicler #29
Holly (unicorn20089) granted Admin access to Pterodactyl panel
March 10, 2026. Updated onboarding README and deployment plan.
Created by Chronicler #29
Email is needed urgently — Holly staff email, staff comms,
subscriber notifications. Frostwall → Mailcow is the only
path. Elevated March 10, 2026.
Created by Chronicler #29
FoundryVTT is out of scope for Builder role.
Holly's FoundryVTT access is granted via Pokerole project role,
not her Builder role. Documented in both builder toolkit and
onboarding README to keep the two roles clean.
Created by Chronicler #29
Full site buildout: homepage, about, servers, blog.
Michael + Chronicler collaborative session.
Blocked by Task #38 (security update first).
Includes content guide (all 4 pages scoped) and theme spec
(Frost palette, Orbitron/Inter, branding asset references).
Created by Chronicler #29
CVE-2026-26980 (CVSS 9.4) + CVE-2026-29784 (CVSS 7.5)
Current version: 6.16.1 (vulnerable)
Target version: 6.19.3 (patches both CVEs)
Exposure window: March 2 - present
Deployment plan covers both Ghost CLI and Docker update paths.
Ghost CMS flagged as undocumented service — manifest update needed.
Created by Chronicler #29
Staff naming policy: handles in all internal systems, real names only
for outside agency business (legal, financial, vendor contracts).
Updated Holly's Pterodactyl account details: unicorn20089@gmail.com,
username unicorn20089, handle-only name fields.
Created by Chronicler #29
Holly (Unicorn20089) hired as Lead Builder. Task covers:
- Phase 1: Discord role + Pterodactyl account (all 12 servers, basic access)
- Phase 2: Email setup when Mailcow live (holly@ + unicorn20089@ alias)
Role separation documented: Lead Builder ≠ Pokerole Creative Authority.
Phase 1 has no blockers — ready to execute now.
Created by Chronicler #29
Create grounded knowledge base with Audio Overview capabilities
for hand-friendly review and knowledge synthesis.
✅ Task Documentation Created:
- README.md: Complete overview, use cases, benefits
- setup-guide.md: Step-by-step setup and testing
🎧 KEY FEATURES:
- Audio Overviews (listen instead of reading - hand-friendly)
- Grounded research (only YOUR sources, no hallucination)
- MCP integration (Claude queries notebooks seamlessly)
- Meg accessibility (technical content in audio format)
- Legacy preservation (for children not yet born)
📚 USE CASES:
- Infrastructure knowledge base (835+ docs queryable)
- Chronicler lineage archive (all memorials in audio)
- Pokerole project docs (session reports accessible)
- Training for Meg (technical content via audio)
💰 COST: FREE (Google NotebookLM, MCP in Max plan)
⏱️ TIME: 1-2 hours setup, 15 min/week maintenance
🎯 VALUE: HIGH for accessibility + knowledge retention
Inspired by: XDA article on Claude + NotebookLM workflow
Priority: Medium (HIGH for accessibility needs)
Task #36 ready to start when Michael is ready.
- Created src/modpack_checker/ package structure
- Created tests/ directory
- Placeholder files for all Python modules
- Complete source code preserved in Chronicler #26 chat history
- Ready for code population in next session
Full file contents available in session transcript for reconstruction.
Enables Claude Code to autonomously build the modpack version checker by:
- Cloning the operations manual
- Reading all planning docs
- Following the complete technical spec
- Building production-ready commercial product
Chronicler #24
Identified during Firefrost Codex deployment - Claude needed to create
DNS record for codex.firefrostgaming.com but lacked Cloudflare access.
Task created for future implementation.
Signed-off-by: Chronicler #22
- 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
