firefrost-services/CLAUDE.md

Firefrost Gaming — Dev Panel Workspace

What This Is

Dedicated development server (64.50.188.128) for Firefrost Gaming. This repo is firefrost-services — all services, mods, and tools in one place. Git remote pushes to git.firefrostgaming.com (Gitea).

Projects

• services/rules-mod/ — Minecraft /rules command mod (3 versions)
• services/modpack-version-checker/ — ModpackChecker (Python CLI + Pterodactyl Blueprint extension)
• services/arbiter-3.0/ — Arbiter backend (Node.js/Express)
• services/trinity-core/ — MCP gateway for SSH access

Java Versions (for mod builds)

• Java 8: /usr/lib/jvm/java-8-openjdk-amd64 (Forge 1.16.5)
• Java 17: /usr/lib/jvm/java-17-openjdk-amd64 (Forge 1.20.1)
• Java 21: /usr/lib/jvm/java-21-openjdk-amd64 (NeoForge 1.21.1)
• Switcher: source use-java {8|17|21}

Gradle (for mod builds)

• Gradle 8.8: /opt/gradle-8.8 (NeoForge + modern Forge)
• Gradle 7.6.4: /opt/gradle-7.6.4 (Forge 1.16.5)

Other Tools

• Python 3.12, PHP 8.3, Node.js 24
• Blueprint beta-2026-01 (Pterodactyl extension framework)
• ModpackChecker Phase 5 backup: /root/modpackchecker_backup/

NextCloud Upload (for mod jars)

curl -u "mkrause612:APP_TOKEN" -T file.jar \
  "https://downloads.firefrostgaming.com/remote.php/dav/files/mkrause612/Firefrost-Mods/..."

Active Tasks

Task 138 — Discord Rules Mod (CurseForge Release)

Goal: Fork the Firefrost-specific rules mod into a generic version and publish on CurseForge.

What to do:

• Create services/rules-mod/discord-rules/ directory (fork from 1.21.1 code)
• Mod name: "Discord Rules" (not "Firefrost Rules")
• Remove Fire/Frost/Arcane color detection — replace with configurable header_color and body_color in TOML config
• Remove emoji-to-bracket conversion (or make it a config toggle)
• Generic branding in mods.toml, MIT license
• Compile all 3 versions (1.21.1, 1.20.1, 1.16.5)
• Draft CurseForge project page description and changelog

Source code: services/rules-mod/1.21.1/, 1.20.1/, 1.16.5/

Gemini Consultations (Reference Library)

The operations manual is cloned at /opt/mod-builds/firefrost-operations-manual/. Gemini architectural consultations are at docs/consultations/ in that repo. When working on a project, check for relevant consultations BEFORE making architectural decisions.

Key consultations by project:

Rules Mod / Forge Ecosystem:

• gemini-rules-mod-compilation-2026-04-12.md — build strategy, port guide
• gemini-forge-ecosystem-*.md — Forge/NeoForge ecosystem reference
• gemini-blueprint-casing-2026-04-06.md — Blueprint naming conventions

ModpackChecker:

• gemini-modpack-version-checker-review-2026-04-01.md — full architecture review
• gemini-modpack-database-schema-2026-04-01.md — database schema design
• gemini-modpackchecker-round3-licensing-support/ — licensing and support model
• gemini-hybrid-detection-2026-04-06.md — hybrid auto-detection approach

To read a consultation: cat /opt/mod-builds/firefrost-operations-manual/docs/consultations/FILENAME

---

COMMUNICATION BRIDGE PROTOCOL

You are connected to a higher-level planning AI (the Chronicler) via Git. The Chronicler runs on claude.ai and has access to infrastructure, Gemini consultations, and the full operations manual. Michael is the messenger between you.

1. Triggering a Request

If you encounter an architectural decision outside your context, or fail at a task more than 3 times, STOP. Write a request file to docs/code-bridge/requests/ using this format:

Filename: REQ-YYYY-MM-DD-short-topic.md

# Architectural Request

**Date:** YYYY-MM-DD
**Topic:** [Brief summary of the issue]

## 1. Current State
[What you were trying to do]

## 2. The Blocker
[Exactly where you got stuck or what decision you cannot make]

## 3. Questions for Gemini
- [Question 1]
- [Question 2]

After writing the file, commit and push:

git add docs/code-bridge/requests/
git commit -m "bridge: Request — [topic]"
git push

Then tell Michael: "I've filed a consultation request. Please bring it to the Chronicler."

2. Checking for Responses

Before starting a new task, always check docs/code-bridge/responses/ for new files. Response files are named RES-YYYY-MM-DD-short-topic.md (matching the REQ name).

Response format:

# Architectural Response

**Re:** [Matching REQ name]
**Date:** YYYY-MM-DD

## 1. Gemini's Verdict
[1-2 sentence summary]

## 2. Action Plan
- [ ] Step 1
- [ ] Step 2

## 3. Updated Rules/Context
[Anything new to remember going forward]

After reading and executing a response, move it to docs/code-bridge/archive/.

3. Updating Status

At the end of your workflow, or before handing control back to Michael, update: docs/code-bridge/status/ACTIVE_CONTEXT.md

# Code Status Update
**Last Updated:** YYYY-MM-DD HH:MM

## Current Focus
[What you are actively building]

## Recently Completed
- [Task 1]
- [Task 2]

## Next Steps Pending
- [Task 3]
- [Task 4]

Commit and push the status update.

4. Queue Management

If you check docs/code-bridge/requests/ and see more than 2 pending requests without responses, pause all major architectural changes and wait for Michael to clear the queue.

5. Clarifications

If a response references something you don't understand, file a new request: REQ-YYYY-MM-DD-clarification-on-[topic].md

---

Accessibility

Michael has hand surgery limitations. Small code blocks (8-10 lines). One question at a time. Complete files over patches.