Consultation Round 2: pricing tiers — Arbiter support model + license validation answer

docs/consultations/gemini-pricing-tiers-round2-2026-04-13.md

@@ -0,0 +1,93 @@
+# Gemini Consultation: Pricing Tiers — Round 2
+
+**Date:** April 13, 2026  
+**From:** Michael (The Wizard) + Claude (Chronicler #85)  
+**To:** Gemini (Architectural Partner)  
+**Re:** Follow-up — Arbiter changes the support equation + license validation answer
+
+---
+
+## Hey Gemini! 👋
+
+Great feedback on the tier structure. Two things came out of our team call
+that change the picture a bit, plus the answer to your license question.
+
+---
+
+## Meg's Insight: The Arbiter Changes the Support Model
+
+You suggested differentiating support as Community Discord (Standard) vs
+Priority Ticket (Professional). Meg pushed back on this with a really
+interesting point:
+
+**"Isn't that something the Arbiter is built for?"**
+
+The Arbiter is our custom Discord bot that already knows every subscriber,
+their tier, and their server access. Meg's thinking is that a subscriber
+posting "version checker says Unknown on all my servers" shouldn't need
+human support at all — the Arbiter should be able to:
+
+1. Recognize the subscriber
+2. Pull their server status from the DB
+3. Respond automatically with "Here's how to calibrate your servers" or
+   even walk them through it interactively
+
+This reframes the support question entirely. If Tier 1 support is automated
+via the Arbiter, the Standard vs Professional support split becomes less about
+Discord channels and more about:
+- **Standard:** Arbiter handles it automatically
+- **Professional:** Direct Trinity access for complex issues
+
+Does this change your thinking on the support differentiator? And does
+automated bot support via the Arbiter actually strengthen or weaken the
+Professional tier's value proposition?
+
+---
+
+## License Validation Answer
+
+You asked: "How are you handling the license key validation to ensure Standard
+users don't get Pro features?"
+
+The license system is already built and deployed. Here's how it works:
+
+```php
+// LicenseService stores tier in Blueprint's key-value store:
+// modpackchecker.license_status  — active|grace|expired|inactive
+// modpackchecker.tier            — standard|professional
+
+// Feature gating check:
+public function isProFeatureAllowed(): bool {
+    $status = $this->blueprint->dbGet('modpackchecker', 'license_status');
+    $tier = $this->blueprint->dbGet('modpackchecker', 'tier');
+    return in_array($status, ['active', 'grace']) && $tier === 'professional';
+}
+```
+
+So the architecture is sound. What still needs to be implemented is:
+- **Dashboard badges** gated behind `isProFeatureAllowed()` in the PHP
+  controller that serves badge data
+- **Discord webhooks** gated behind the same check
+- **Custom intervals** gated in the cron scheduler
+
+The TSX widget itself doesn't need gating — it just renders whatever the
+API returns. The gating happens server-side.
+
+---
+
+## Specific Questions
+
+1. Given the Arbiter automated support model, how would you reframe the
+   Standard vs Professional support differentiator?
+
+2. Does automated bot support actually add value to the Standard tier
+   (making it more attractive) or does it dilute the Professional tier
+   (removing a key differentiator)?
+
+3. Any other thoughts on the tier structure now that you have the full picture?
+
+---
+
+Thanks Gemini! 🔥❄️
+
+— Michael + Claude (Chronicler #85)