logicspike/docs

Project Strategy

LogicSpike: Core Platform Functionality Plan

Last Updated: 2026-02-28

This document outlines the required functionality for the foundational LogicSpike Core Platform. This layer must be fully mature before any end-user services (like the Blog Engine or Chatbot) are built on top of it. It acts as the business operating system.

NOTE

Items marked with ✅ are implemented. Items marked with ⏳ are designed but not yet enforced/built.

1. Identity & Access Management (IAM)

The IAM system is the gatekeeper. It must handle user authentication and granular authorization across all isolated workspaces.

Core Features:

  • ✅ Universal Authentication: Support for Email/Password and OAuth (Google) logins.
  • ✅ Asymmetric JWT Edge Verification: The Identity Provider (manager service) signs tokens with an RS256 Private Key. All downstream services verify the token locally using the Public Key, enabling zero-latency auth checks.
  • ✅ True Multi-Tenancy: A single user identity can belong to multiple workspaces (Tenants).
  • ✅ Permission-Based Access Control (PBAC): Roles (Owner, Admin, Member) are just templates that expand into strict permission strings (e.g., blog:posts.write). Tokens carry the exact permissions for the current active workspace.
  • ✅ Machine-to-Machine (M2M) Auth: Services authenticate via x-gateway-key for inter-service communication and API keys for external integrations.

2. Global API Gateway & Routing

The Gateway is the unified entry point for the entire LogicSpike ecosystem. It routes traffic, enforces rate limits, and validates identities at the edge.

Core Features:

  • ✅ Intelligent Routing: Acts as a reverse proxy via Cloudflare Service Bindings, routing /blog/*, /manager/*, and /media/* to their respective Worker services.
  • ✅ Edge Authentication: Intercepts inbound requests, validates the RS256 JWT, and safely injects verified x-user-permissions, x-tenant-id, and x-user-id into downstream requests.
  • ✅ API Key Authentication: Public-facing routes (e.g., /blog/public/*) accept API keys via x-api-key or Authorization: Bearer headers, enforcing key type, domain locking, and per-service permissions.
  • ⏳ Service Entitlement Enforcement: accessMiddleware exists and reads services: { blog: { enabled: true } } from the JWT, but is not yet applied to any proxy route.
  • ⏳ Global Rate Limiting: rateLimitMiddleware exists but is not yet mounted on any route. Uses in-memory storage (not persistent across Worker invocations).

3. Subscription & Billing Engine

A centralized financial engine that tracks what a workspace has paid for and coordinates entitlements across all isolated services.

Core Features:

  • ✅ Centralized Billing Hub: The manager service handles all Razorpay integrations, invoices, and subscriptions. 19 API endpoints are deployed.
  • ✅ Coin & Add-on Economy: Tenants purchase coin packs and use coins to buy add-ons (extra storage, seats, etc.). Atomic credit/debit operations with full transaction ledger.
  • ✅ Entitlement Rebuilding: When a workspace upgrades or buys add-ons, rebuildEntitlements() upserts tenant_services with merged limits from plan + add-ons.
  • ⏳ Usage Enforcement (Phase 7): checkLimit() guard not yet built — resource-creating endpoints should enforce limits before allowing creation.
  • ⏳ Stripe Provider (Phase 8): Razorpay-only for now. Stripe integration deferred for international billing.

4. The Central Event Bus (The Automation Foundation)

The system that allows isolated microservices to communicate asynchronously. This is the bedrock of the future Zapier-like Automation Engine.

Core Features:

  • Pub/Sub Messaging: Microservices can publish events (e.g., user.created, blog.published, invoice.paid) without knowing who is listening.
  • Cross-Service Workflows: The Billing service can listen for user.created to provision a free trial, while the Communication service listens to the exact same event to send a welcome email.
  • Webhook Infrastructure: A robust system to allow users to subscribe external applications (like Slack or Discord) to internal LogicSpike events securely.

5. Centralized Tenant Administration

The platform acts as the single control plane for a workspace. Users should never have to configure team access or billing inside individual services like the Blog Engine.

Core Features:

  • Team & Membership Management: A single UI to invite users, assign roles (Owner, Admin, Member), and revoke access across the entire workspace ecosystem.
  • Centralized Settings: A unified dashboard for workspace branding, timezones, localization, and global preferences that trickle down to all active services.
  • Centralized Billing & Usage Dashboard: A single pane of glass to view current Stripe subscriptions, track usage quotas (e.g., storage limits, email sends), and upgrade plans.
  • Global Notification Preferences: Users configure how they want to be alerted (email, in-app, Slack) for system events, and the platform enforces these rules universally.

6. Developer & Integration Ecosystem

The platform must expose tools that allow agencies and power users to extend LogicSpike programmatically.

Core Features:

  • ✅ API Key Management: Full CRUD system with two key types (secret with ls_ prefix, publishable with pk_ prefix). Keys are scoped per-service with granular permissions ({ "blog": ["read", "write"] }). Supports domain locking for publishable keys and configurable expiration (30d, 90d, 1y, never). SHA-256 hashed storage.
  • ⏳ Webhooks & Event Subscriptions: A unified portal where users can register outbound webhooks. (Not yet implemented — spec exists as vision.)
  • ⏳ Custom Domain & SSL Manager: A centralized ingress controller where tenants can attach custom domains. (Not yet implemented.)
  • ⏳ Audit Logging (Compliance): Spec exists at docs/settings/audit-log-spec.md. Schema designed but not yet implemented. (See audit-log-spec.md)

7. Development Infrastructure

The internal tooling required to build the ecosystem quickly and safely.

Core Features:

  • Typed SDKs & Shared Packages: Core logic (Database Schemas, Types, Auth verification, RBAC rules) is extracted into NPM workspace packages to ensure absolute consistency across all microservices.
  • Monorepo Architecture (Turborepo): To manage the complexity of dozens of interconnected services and shared libraries with optimal caching and build times.
Project Strategy