🎮 Playground - Desktop AI Development Platform

📥 Download Latest Release | 🌐 Visit cybrdeck.com

Playground is a native Windows desktop application for multi-model AI development. Build, test, and deploy AI solutions using Claude, Gemini, GPT-5, Qwen, and more—all from a beautiful, responsive interface.

⚡ Quick Start

• Download Installer (Windows 10+, 64-bit)
• Choose MSI or EXE installer
• Run & start building with AI
• Add your API keys in Settings

✨ Features

• 🤖 Multi-Model Support - Claude, Gemini, GPT-5, Qwen, Local Ollama
• 🪟 Native Windows App - System tray integration, auto-updates
• 🎨 Studio Suite - Image generation, video, audio, design tools
• 💻 Developer Tools - Code generation, prompt history, skill system
• 📊 Compare Models - Side-by-side multi-model responses
• 🔐 BYOK Support - Use your own API keys

🕵️‍♂️ Cybrdeck Frontend Portal

**Elite, Offline-Resilient B2B Lead Acquisition Suite & Zero-Egress Security Traps**





Welcome to the Cybrdeck Web Portal. This repository houses the public-facing, premium Next.js application that serves as Cybrdeck’s main brand portal, conversion funnel, and B2B growth-hacking suite.

Designed with sandstone glassmorphism, dynamic container-morph animations, and focus-glowing input HUDs, the platform provides an elite user experience while maintaining a strictly isolated, zero-egress local processing core for sensitive source materials and business intelligence data.

⚡ Key Systems & Architecture

To satisfy our high-security mandates (preventing cloud subpoena or corporate leaks) while guaranteeing 24/7/365 availability, the frontend utilizes a hybrid offline-resilient messaging flow:

sequenceDiagram
    autonumber
    actor User as Prospect / Journalist
    participant UI as Next.js Frontend
    participant DB as Cloud Firestore
    participant BE as Local cybrdeckRAG (Offline)

    User->>UI: Submit Form (/business or /non-profit)
    UI->>DB: Write document to Queue (Status: 'pending')
    Note over UI: Engages 7-second Browser Ping Timer
    
    rect rgb(30, 20, 40)
        Note over BE: Local Machine is Turned On
        BE->>DB: Realtime websocket snapshot listener triggers
        DB-->>BE: Read 'pending' ticket
        BE->>BE: Run Local RAG & Vector Embeddings
        BE->>DB: Update document (Status: 'completed' + Briefing content)
        DB-->>UI: Realtime update UI state (Display results)
    end

    rect rgb(50, 10, 10)
        Note over UI: 7s Timer Expires & Local Backend is Offline
        UI->>UI: Engage High-Availability Cloud Fallback
        UI->>UI: Validate trainee whitelist scope locally
        UI-->>User: Serverless Gemini REST Fallback briefing displayed
    end

1. 📬 Firestore Asynchronous Queue

Rather than calling local backend APIs directly (which fail if the operator's hardware is offline), marketing routes write lead details and scan parameters directly to Cloud Firestore collections (pending_prospect_audits, pending_npo_briefings). When the secure local Python daemon is booted up, its multi-threaded websocket snapshot listener (on_snapshot) processes queued tickets in bulk and updates the UI real-time.

2. 🛡️ High-Availability Cloud Fallback (The "Hit by a Bus" Gate)

If our secure local processor is offline, a 7-second browser-side timer triggers our client-side serverless fallback. The browser validates the user's domain/email credentials locally, engages a secure serverless Gemini REST API to construct a safe briefing, and synchronizes the session state back to Firestore. Your funnels remain active and converting, even if our primary servers go dark.

3. 🕸️ Retro Matrix Intruder Redirection Gate

The internal operator route (/leads) is styled as a technical terminal. If unauthorized crawlers or unwhitelisted researchers attempt to enter, they trigger our Matrix Gate. Instead of a dry API block, the system disorients the visitor with retro green terminal visuals, logs their network coordinates, and invites them to request access via a gamified Red Pill / Blue Pill Calendly funnel.

🧭 Directory of Master Blueprints & Guides

Co-founders, operators, and technical trainees should consult our master onboarding guide and design playbooks immediately:

• READ NOW BEN.md: The central operator manual detailing systems architecture, GCP Service Account rotation keys, and local backend batch commands.
• 🛡️ Security threat audit (docs/naysayer.md): Detailed whitehat analysis of five potential threat vectors in our local RAG prototype and Ben's hardening assignments.
• 🎨 Conversion UI/UX Strategy (docs/bruh.md): The conversion psychology and single-serve strategy behind maintaining isolated /business, /non-profit, and /leads funnels.
• 📰 Journalist Protection SOP (docs/journalist.md): Zero-egress whistleblower coordinate sandboxing, isolated DB arrays (db_journalism_<id>.json), and Matrix redirection trap specs.

🛠️ Technical Stack

• Core: Next.js 16 (App Router)
• Logic: TypeScript, Firebase Web SDK (v12)
• Styling: Tailwind CSS 4, Sandstone Glassmorphism dark theme
• Utility Libraries: Lucide React, Recharts, Framer-inspired CSS transitions

🚀 Local Development Setup

To run the Next.js frontend developer portal locally:

1. Prerequisite Environment Configuration

Create a .env.local file in the root folder of this repository:

# Firebase Public API Credentials
NEXT_PUBLIC_FIREBASE_API_KEY="your-api-key"
NEXT_PUBLIC_FIREBASE_AUTH_DOMAIN="your-project.firebaseapp.com"
NEXT_PUBLIC_FIREBASE_PROJECT_ID="your-project-id"
NEXT_PUBLIC_FIREBASE_STORAGE_BUCKET="your-project.appspot.com"
NEXT_PUBLIC_FIREBASE_MESSAGING_SENDER_ID="your-sender-id"
NEXT_PUBLIC_FIREBASE_APP_ID="your-app-id"

# High-Availability Cloud Fallback API Key (Gemini)
NEXT_PUBLIC_GEMINI_API_KEY="your-gemini-api-key"

2. Dependency Installation

Install package dependencies using npm:

npm install

3. Run the Development Server

Initiate the local Next.js server on port 9002 (customized to avoid conflicts with standard local microservices):

npm run dev

Open http://localhost:9002 in your browser to interact with the console.

4. Code Quality & Typechecks

Validate that the TypeScript compiler passes with zero errors:

npm run typecheck

💳 Stripe Setup (Events Page Bookings)

The Events page (/events) uses Stripe Hosted Checkout to take direct payments for paid events and boutique items, replacing the legacy StripeSimulator (now StripeHook). Card data is collected by Stripe on its domain — we stay PCI-DSS SAQ-A and never touch raw card numbers.

1. Install the Stripe dependencies

npm install

This pulls in stripe (server SDK) and @stripe/stripe-js (browser SDK).

2. Get your Stripe API keys

1. Sign up free at <https://dashboard.stripe.com/register> (or sign in if you already have an account).
2. Make sure Test mode is enabled (the toggle in the top-right of the Dashboard).
3. Navigate to Developers → API keys.
4. Copy the two keys into your .env.local:

# Stripe — server-only secret
STRIPE_SECRET_KEY=sk_test_xxxxxxxxxxxxxxxxxxxxxxxx

# Stripe — public key (safe to expose to the browser)
NEXT_PUBLIC_STRIPE_PUBLISHABLE_KEY=pk_test_xxxxxxxxxxxxxxxxxxxxxxxx

[!WARNING]

Never commit .env.local to git. The STRIPE_SECRET_KEY can issue real charges on your account. The repo already gitignores .env.local.

3. Forward webhooks locally (dev only)

While running on localhost, Stripe can't reach your machine from the public internet, so the webhook handler at /api/stripe/webhook never fires without a local forwarder. Use the Stripe CLI for this.

Install the CLI (one-time, ~10 MB):

• Windows: winget install Stripe.StripeCLI
• macOS: brew install stripe/stripe-cli/stripe
• Linux: see <https://docs.stripe.com/stripe-cli>

Authenticate and start forwarding (in a second terminal, alongside npm run dev):

stripe login
npm run stripe:listen

The listener prints a line like:

> Ready! Your webhook signing secret is whsec_xxxxxxxxxxxxxx

Copy that value into .env.local:

STRIPE_WEBHOOK_SECRET=whsec_xxxxxxxxxxxxxx

Then restart npm run dev so it picks up the new env var.

4. Test the full payment flow

1. Open <http://localhost:9002/events> and click any paid event.
2. Click PAY $… WITH STRIPE.
3. On Stripe Checkout, use the standard test card:

• Card number: 4242 4242 4242 4242
• Expiry: any future date (e.g. 12 / 34)
• CVC: any 3 digits
• ZIP: any 5 digits

1. You should redirect to /events/registration-success?session_id=… and see the receipt within ~1 second.
2. Check your Firestore registrations collection — a new doc should appear keyed by the Stripe payment intent id, written by the webhook handler.

[!TIP]

To test webhooks without doing a real checkout, run stripe trigger checkout.session.completed. This fires a synthetic event through stripe listen into your handler — useful for debugging in isolation.

5. Going to production

The Stripe CLI is NOT required in production. Your hosting provider gives Stripe a real public URL to POST to. To go live:

1. Switch the Stripe Dashboard to Live mode and copy your sk_live_… and pk_live_… keys.
2. Set these env vars in your production environment (Firebase App Hosting → Runtime secrets, Vercel → Project Settings → Environment Variables, etc.):

• STRIPE_SECRET_KEY=sk_live_…
• NEXT_PUBLIC_STRIPE_PUBLISHABLE_KEY=pk_live_…
• NEXT_PUBLIC_SITE_URL=https://cybrdeck.com

1. Register a webhook endpoint in the Stripe Dashboard:

• Go to Developers → Webhooks → Add endpoint
• Endpoint URL: https://cybrdeck.com/api/stripe/webhook
• API version: 2024-12-18.acacia (matches the SDK pin in src/lib/stripe.ts)
• Subscribe to events: at minimum checkout.session.completed. Add charge.refunded later if you want to handle cancellations (the handler currently no-ops unknown event types).

1. Copy the Signing secret Stripe displays for your new endpoint into your production env vars as STRIPE_WEBHOOK_SECRET=whsec_….
2. Deploy.

6. Architecture notes (for future-you)

• Hosted Checkout, not embedded Elements — card data stays on stripe.com. Apple Pay / Google Pay work on mobile out of the box.

• Webhook is the source of truth — the registration record is written by /api/stripe/webhook on checkout.session.completed, not by the client. The success page just reads the record the webhook wrote.
• Raw-body signature verification — src/app/api/stripe/webhook/route.ts reads req.text() and verifies the signature before anything else, otherwise constructEvent will throw.
• Idempotent retries — the webhook handler dedupes Stripe retries by event.id in memory. If you ever run multiple Node instances behind a load balancer, swap the in-memory Set for a Firestore flag doc.
• server-only guards — src/lib/stripe.ts and src/lib/env.ts import server-only, so accidentally importing them from a client component fails the build rather than leaking the secret key.

🌐 Production Deployment

This project compiles static builds and is fully optimized for Firebase App Hosting:

# Verify firebase connection
firebase login

# Deploy static and hosting assets
firebase deploy --only hosting

[!NOTE]

OPSEC & DATA SECURITY COMPLIANCE:

Absolutely no sensitive CRM Objection logs, customer contacts, or raw leak databases should be checked into this git repository or committed to public cloud hosts. Maintain strict boundaries between the public web frontends and our local secure Python backend RAG folders.

🕵️‍♂️ [FOR BEN ONLY] - Operator & Systems Manual

Ben, this section is dedicated to your eyes only to quickly configure, maintain, and understand the technical handshake between the public web frontend and your secure local RAG backend.

1. 🎨 Branding Hierarchy & The CYBRLEAD Desktop Shortcut

To keep our corporate identity clean and compliant, our branding operates under a strict hierarchy:

• The Team & Portal: Remains Cybrdeck (public website header shows the lightweight CSS-powered neon brand identifier CYBRDECK).
• The Holding Company: Eve Count Quantum Systems is the parent holding company (footers read © 2026 CYBRDECK - EVE COUNT QUANTUM SYSTEMS. ALL RIGHTS RESERVED.).
• CYBRLEAD: This is your custom private desktop shortcut and taskbar icon name for launching the local RAG orchestrator dashboard!

2. 🚀 Quick Start: How to Sync & Run Your Local Backend

Whenever you boot up your computer, follow these steps to start capturing and processing leads:

1. Ensure your local virtual environment and dependencies are compiled.
2. Place your GCP Service Account JSON credential key locally (DO NOT commit it to Git).
3. Set up a .env file in the backend root directory of the RAG repository:

   GOOGLE_APPLICATION_CREDENTIALS="C:\path\to\your\gcp-service-account.json"
   SMTP_HOST="smtp.gmail.com"
   SMTP_PORT=587
   SMTP_USER="your-email@domain.com"
   SMTP_PASSWORD="your-app-password"

1. Run the master orchestrator to spin up the local RAG FastAPI backend:

   cd "C:\Users\User\Documents\RAG for cybrdeck"
   .\run.bat

3. 🛡️ Essential Operational Playbooks

You have three custom-tailored playbooks copied directly into this repository under the docs/ folder. Review them immediately for security, conversion, and pipeline integrity:

• 🛡️ Security & Threat HARDENING Checklist $\rightarrow$ docs/naysayer.md
• 🎨 UI/UX Conversion Strategy & Landing Design $\rightarrow$ docs/bruh.md
• 📰 Journalist Protection & Leak Sandboxing Protocols $\rightarrow$ docs/journalist.md

4. 🧭 Systems Telemetry Checklist

When you launch your local backend, monitor the console logs. It should register [INFO] Firestore Listener: Listening to pending_prospect_audits... showing that the local websocket snapshot listeners have successfully bound to Firestore. Any leads collected while you were offline will instantly process in bulk!

5. 🎯 The SDR Retention & Moat Psychology (Why We Run RAG Locally)

Beyond core data security, keeping the RAG intelligence suite strictly on our local hardware is our greatest retention and operations moat:

• The Invisible Pipeline: Our hired sales agents and SDRs have absolutely no idea how the system compiles these highly targeted, high-converting lead lists.
• Leverage & Retention: Top-tier sales professionals stay with a company long-term when they are handed hot, pre-compiled accounts and told exactly who to sell to and what to say, bypassing list-building fatigue.
• IP Protection: Keeping the pipeline local keeps our lead generation mechanics completely black-boxed from both competitors and departing employees, ensuring our proprietary prospecting methods remain a secure, in-house secret.

🤖 Agent Skills & Custom Modes

This project utilizes custom AI agent skills to enforce development standards, security, and workflows. These skills are loaded globally (from ~/.gemini/config/skills/) and locally (from .agents/skills/).

Available Global Skills

• 🤖 Google GenAI Developer (google-genai-developer): Use for working with the Gemini API and Google GenAI SDK.
• 🧪 Jest Test Engineer (jest-test-engineer): Use for writing and maintaining Jest test suites.
• 🛠️ Tool Writer (tool-writer): Use for developing custom tools.
• 🔀 Merge Resolver (merge-resolver): Use for intelligent git merge conflict resolution.
• 🧩 Skill Writer (skill-writer): Use for creating and validating Agent Skills packages.
• ✍️ Documentation Writer (documentation-writer): Use for generating technical documentation.
• 🔍 Project Research (project-research): Use for deep codebase investigation and dependency analysis.

Available Workspace Skills

• 🐴 Ponytail (ponytail): Use for writing the shortest, most minimal, laziest solution possible (YAGNI).
• 🐴 Ponytail Audit (ponytail-audit): Whole-repo audit for over-engineering, bloat, and security vulnerabilities (exposed secrets, monoliths).
• 🐴 Ponytail Review (ponytail-review): Code review focused exclusively on cutting over-engineering.
• 🐴 Ponytail Debt (ponytail-debt): Harvests all deferred shortcuts from ponytail: comments.
• 🐴 Ponytail Gain (ponytail-gain): Scoreboard of ponytail's impact.
• 🐴 Ponytail Help (ponytail-help): Quick reference for ponytail commands.