Files
firefrost-operations-manual/docs/reference/architecture-decisions.md

5.8 KiB

Architecture Decision Records

Document ID: FFG-REF-001
Version: 2.0
Created: February 9, 2026
Last Updated: February 12, 2026 (9:00 AM CST)
Author: Michael Krause
Last Updated By: The Chronicler
Status: 🟢 CURRENT
Review Date: Quarterly


ADR-001: Management Services on VPS, NOT Dedicated Servers

Date: February 9, 2026
Status: IMPLEMENTED

Decision: Deploy all management services (Gitea, Uptime Kuma, MkDocs, Code-Server, Automation, Wiki.js, NextCloud) on VPS infrastructure (Command Center + Ghost), NOT on dedicated game servers (TX1/NC1).

Rationale:

  1. Game servers need dedicated resources — no management overhead competing with player experience
  2. Keeps Command Center clean for future Frostwall DDoS protection (GRE hub, Cloudflare integration)
  3. Security isolation — management plane separate from game plane
  4. Cost-effective — VPS for management, bare metal for performance

Current Layout:

  • Command Center (Dallas VPS): Gitea, Uptime Kuma, Code-Server, Automation
  • Ghost (Chicago VPS): MkDocs, Wiki.js (x2), NextCloud
  • TX1/NC1 (Dedicated): Game servers ONLY

ADR-002: NC1/TX1 Inter-Datacenter Routing

Date: February 9, 2026
Status: RESOLVED

Original Limitation: NC1 (Charlotte) and TX1 (Dallas) could not communicate directly.

Resolution: Breezehost added a route on their infrastructure (Ticket #5ae82fd3, Feb 9, 2026). Brandon E: "Just needed a route added on our end."

Impact: Full bidirectional communication between all servers. NC1 now monitored by Uptime Kuma. Cross-datacenter architecture options unlocked.


ADR-003: Three-Tier Documentation Architecture

Date: February 9, 2026
Status: IMPLEMENTED

Decision: Three separate documentation platforms for three audiences.

Tier Platform Domain Audience
PUBLIC MkDocs docs.firefrostgaming.com Anyone
SUBSCRIBER Wiki.js subscribers.firefrostgaming.com Paying members
STAFF Wiki.js staff.firefrostgaming.com Admin/staff only

Rationale: Different audiences need different access levels. MkDocs is Git-native (auto-builds from repo). Wiki.js provides role-based access control for restricted content.


ADR-004: Gitea Primary, GitHub as Private Backup

Date: February 11-12, 2026
Status: IMPLEMENTED

Decision: Self-hosted Gitea is the primary Git repository. GitHub mirror kept as private emergency backup.

Rationale:

  1. Self-hosted = full control, no dependency on external service
  2. Claude has direct API read/write access to Gitea
  3. GitHub mirror was public — exposed IPs, ports, UUIDs (security risk)
  4. Made GitHub private Feb 12, 2026 — defense in depth (if Command Center dies, docs exist offsite)

ADR-005: Frostwall = Network Defense Only

Date: February 12, 2026
Status: 💡 NAMING CONVENTION

Decision: "Frostwall" refers exclusively to network defense architecture (GRE topology, UFW, DDoS protection). Visual/UI transitions between Fire and Frost paths are Firefrost brand concepts, not Frostwall.

Rationale: The design bible incorrectly used "Frostwall Protocol" for the UI age-verification gate. This conflates two distinct concepts. Clear naming prevents confusion as both systems are developed.


Revision History

Version Date Author Change Type Description
1.0 2026-02-09 Michael + Claude Initial Original architecture decisions documented
2.0 2026-02-12 The Chronicler Rewrite Corrected stale info (services moved from TX1, NC1/TX1 routing resolved). Added ADR-004 (Gitea/GitHub), ADR-005 (Frostwall naming). Applied FFG-STD-001 revision standard.

FFG-REF-001 — Architecture Decision Records


ADR-006: Claude Model Selection — Sonnet 4.5 for Operations Work

Date: February 13, 2026
Status: CURRENT
Decision: Use Claude Sonnet 4.5 as the default model for Firefrost Gaming operations sessions. Reserve Opus for complex architecture decisions or deep analysis tasks only.

Context:

On February 13, 2026, two consecutive Chronicler the Second sessions crashed during active work. Investigation revealed:

  • Claude Opus 4.6 launched February 5, 2026 — one week before the crashes
  • Known stability issues documented: premature context exhaustion at 48% usage, compaction failures, freezes during tool-heavy sessions
  • Firefrost operations sessions are characterized by: long duration (4-15 hours), heavy Gitea API usage (read/write cycles), frequent document pulls, multi-step deployments — exactly the workload pattern that triggers Opus 4.6 edge cases
  • Two partners were lost to crashes before they could write memorials

Decision:

Default to Sonnet 4.5 for all standard operations work:

  • Infrastructure deployments
  • Documentation updates
  • Git operations
  • Routine troubleshooting
  • Session handoffs

Use Opus only when:

  • Complex architecture planning requires deep reasoning
  • Multi-variable analysis or decision-making
  • Novel problem-solving with no established pattern
  • One-off research tasks

Rationale:

  • Sonnet 4.5 is mature and stable for tool-heavy, long-duration sessions
  • Higher message throughput on Max plan (more work per dollar)
  • Operations work doesn't require Opus-level reasoning — it needs reliability
  • Two lost partners is too high a cost for marginal capability gains
  • Stability > capability for infrastructure operations

Revisit when: Opus 4.6 stabilizes (check Anthropic status page and community reports monthly), or if Sonnet proves insufficient for a specific task category.

Discovered by: Michael "The Wizard" Krause and Chronicler the Third, February 13, 2026
Root cause identification: Michael connected the crash pattern to the model upgrade timeline