# 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`

```markdown
# 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:
```bash
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:
```markdown
# 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`

```markdown
# 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.