From 2293f6a11ca40cf73e9bafba01597300f62c484e Mon Sep 17 00:00:00 2001 From: "Claude (Chronicler #83 - The Compiler)" Date: Sun, 12 Apr 2026 19:00:21 +0000 Subject: [PATCH] =?UTF-8?q?docs(consultation):=20Gemini=20consult=20?= =?UTF-8?q?=E2=80=94=20ModpackChecker=20Phase=2011=20full=20licensing=20sp?= =?UTF-8?q?ec?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Complete implementation spec request covering: - Validation API design (endpoints, schema, security) - Phone-home cron (72hr check, 7-day grace, degradation) - Discord support verification bot - BuiltByBit listing strategy (pricing, updates, structure) - Build/package pipeline - Testing strategy This is the last gate before ModpackChecker goes to market. Claude (Chronicler #83 - The Compiler) --- ...ackchecker-phase11-licensing-2026-04-12.md | 123 ++++++++++++++++++ 1 file changed, 123 insertions(+) create mode 100644 docs/consultations/gemini-modpackchecker-phase11-licensing-2026-04-12.md diff --git a/docs/consultations/gemini-modpackchecker-phase11-licensing-2026-04-12.md b/docs/consultations/gemini-modpackchecker-phase11-licensing-2026-04-12.md new file mode 100644 index 0000000..50c6d9f --- /dev/null +++ b/docs/consultations/gemini-modpackchecker-phase11-licensing-2026-04-12.md @@ -0,0 +1,123 @@ +# Gemini Consultation: ModpackChecker Phase 11 — Complete Licensing & Distribution System + +**Date:** April 12, 2026, ~1:30 PM CDT +**From:** Michael (The Wizard) + Claude (Chronicler #83 — The Compiler) +**To:** Gemini (Architectural Partner) +**Re:** Full implementation spec for the licensing, validation, and distribution system before ModpackChecker goes to market on BuiltByBit + +--- + +## Hey Gemini! 👋 + +We're following through on your Round 3 consultation (licensing/support strategy). The ModpackChecker Blueprint extension and Python CLI have both been code-reviewed and cleaned up (20 bugs fixed today, 71 Python tests passing). The code is ready — now we need to build the complete commercial packaging before we list on BuiltByBit. + +Michael wants to ship a **complete package** — not a v1.0 without licensing that gets bolted on later. So we need the full Phase 11 implementation spec. + +--- + +## What Already Exists (Your Prior Decisions) + +From your Round 3 consultation, the decisions were: + +1. **License key = BuiltByBit Order ID** — no key generation +2. **Lightweight validation API** on our server, phone-home every 72 hours via cron +3. **7-day grace period** if validation fails → graceful degradation +4. **2 activations per license** (dev + production) +5. **Anti-piracy:** No DRM/IonCube. Gated updates + gated support is the real moat +6. **Discord support gating:** `/verify-mvc [order-id]` → bot assigns role → unlocks support channels +7. **SLA:** 24-48 business hours, Mon-Fri 9-5 CST + +--- + +## What We Need You to Spec Out + +### A. Validation API (runs on Command Center — 63.143.34.217) + +We need the full API design: + +1. **What technology?** Standalone Express app? New routes in Arbiter? Cloudflare Worker? What makes the most sense given our existing stack (Arbiter is Node.js/Express on Command Center)? + +2. **Database schema** — What tables do we need? At minimum: + - Licenses (order_id, customer_email, product, max_activations, created_at) + - Activations (license_id, panel_domain, panel_ip, activated_at, last_seen) + - What else? + +3. **API endpoints** — What does the extension call, and what does it get back? + - `POST /api/license/activate` — first-time activation (sends order_id + panel domain) + - `POST /api/license/validate` — the 72-hour phone-home (sends order_id + panel domain) + - `POST /api/license/deactivate` — frees up an activation slot + - Anything else? + +4. **Response format** — What does each endpoint return? What does "graceful degradation" look like in practice? Does the extension hide features? Show a banner? Stop checking for updates? + +5. **Security** — How do we prevent someone from spoofing the validation? HMAC signing? The order_id is essentially a shared secret — is that sufficient, or do we need something more? + +6. **BuiltByBit webhook integration** — BuiltByBit can send webhooks on purchase. Should we auto-provision licenses when someone buys, or require manual activation? What webhook events does BuiltByBit send? + +### B. Phone-Home Cron (runs inside the Blueprint extension on customer's panel) + +1. **Implementation** — Laravel Artisan command scheduled via `conf.yml`? How does Blueprint handle scheduled tasks? + +2. **What gets sent** — Order ID, panel domain, panel IP, extension version, PHP version? What's the minimum needed without being creepy? + +3. **Failure handling** — 72-hour check fails → extension keeps working for 7 days → then what exactly? Disable the dashboard badge? Disable the console widget? Show a "license expired" banner? All of the above? + +4. **First-time activation flow** — Admin installs extension → goes to admin settings → enters BuiltByBit Order ID → extension calls activate endpoint → success/failure → what does the UI look like? + +### C. Discord Support Verification Bot + +1. **Implementation** — New Arbiter command? Standalone bot? + +2. **Flow:** User types `/verify-mvc ORDER_ID` → bot checks validation API → if valid, assigns `ModpackChecker Customer` role → unlocks `#mvc-general` and `#mvc-support` channels + +3. **Edge cases** — What if someone shares their order ID? Rate limiting? Can the same order ID verify multiple Discord accounts? + +### D. BuiltByBit Listing + +1. **Product page structure** — What sections does a successful BuiltByBit listing need? Title, description, feature list, requirements, installation guide, support terms, screenshots, pricing? + +2. **Pricing** — What's the right price point for a Pterodactyl Blueprint extension in 2026? We've seen competitors at $5-$15. What should ModpackChecker be? + +3. **Update distribution** — How do customers get updates? BuiltByBit download page? Our own update server? Both? + +4. **Version numbering** — We're at 1.0.0 internally. Should we ship as 1.0.0 or something higher to imply maturity? + +### E. Build & Package Pipeline + +1. **Blueprint package** — `build.sh` already creates the `.blueprint` file. Does it need modification to include license validation code? + +2. **Obfuscation** — You said no IonCube, but should we do any basic PHP obfuscation to raise the bar slightly? Or is it truly not worth the effort? + +3. **Release checklist** — What's the step-by-step from "code is done" to "listed on BuiltByBit"? Every step. + +### F. Testing Strategy + +1. **How do we test the full license flow** on the Dev Panel before going live? Mock BuiltByBit orders? Test activation/deactivation/grace period? + +2. **What could go wrong** in production that we should build monitoring for? + +--- + +## Our Infrastructure Context + +- **Command Center** (63.143.34.217): Arbiter (Node.js/Express), PostgreSQL, Gitea +- **Dev Panel** (64.50.188.128): Pterodactyl + Blueprint beta-2026-01 (test environment) +- **TX1 Dallas** (38.68.14.26): Game servers, n8n +- **Discord bot:** Arbiter's existing bot (already has command infrastructure) +- **Build tool:** Claude Code on Dev Panel via SSH +- **Existing Arbiter DB:** PostgreSQL `arbiter_db` on Command Center + +--- + +## Constraints + +- Michael has hand surgery limitations — the admin UI for license entry must be dead simple +- We want to minimize ongoing maintenance burden — this should mostly run itself +- No external SaaS dependencies for licensing (we host everything) +- Blueprint beta-2026-01 is our target platform — need to verify any scheduled task approach works with this version + +--- + +Thanks Gemini! This is the last big piece before ModpackChecker starts generating revenue. We want a complete, professional, self-hosted licensing system that makes us look like a legitimate software vendor — because we are one. 🔥❄️ + +— Michael + Claude (Chronicler #83 — The Compiler)