Feature Deep-Dives

The Cathedral Framework is not a copy of existing design systems. It is an original architectural language that translates gothic cathedral geometry into digital UI — void-black backgrounds, manuscript gold illumination, Cinzel serif typography, and apex-light radial gradients. Every component reflects structural permanence: zero border-radius, stone-surface textures, illuminated medallions, and arch-top card borders. The system was built iteratively: first by extracting design tokens from 1Commerce, then by recognizing the pattern was too generic. The rebuild started from first principles — what does "cathedral" mean in software? Answer: weight, permanence, light sourcing from a single apex point, and a sense of being inside a constructed space. Result: A design language that is immediately recognizable, defensible, and impossible to confuse with any other SaaS platform.

Manus AI was integrated not as a chatbot overlay, but as a structural component of the platform. The integration spans three layers: 1. **Floating Chat Widget** (DashboardLayout): Context-aware from current route (Dashboard, Money Manager, Gig Command). Injects live user data (earnings, shift count, miles, tax deduction) into AI prompts. 2. **Dedicated /ai-assistant Page**: Full-screen chat with conversation history sidebar, context selector (10 contexts), suggested prompts, and new/delete/clear controls. 3. **Embedded Insight Panels** (Money Manager, Gig Command): Collapsible "AI Insights" cards that pull live suggestions from user data without leaving the page. The system uses `invokeLLM` server-side with system context that changes per page. Dashboard gets earnings summary context. Gig Command gets platform/mileage context. Money Manager gets tax deduction context. Result: AI that feels native to the platform, not bolted on. Every page can surface AI insights without requiring a dedicated chat page.

Multi-tenancy is not just a database feature — it is an architectural decision that affects every layer of the platform. UnifyOne implements four isolation layers: 1. **Database Layer**: Tenants table with unique slug. All data tables include tenant_id foreign key. Row-level security (RLS) policies enforce tenant isolation at the database level. 2. **Authentication Layer**: Users belong to tenants. JWT tokens include tenant_id. Every tRPC procedure checks ctx.user.tenantId against requested resource. 3. **API Layer**: All tRPC procedures are tenant-scoped. No procedure returns data from other tenants, even if a user somehow bypasses the frontend. 4. **UI Layer**: DashboardLayout includes Tenant Switcher. Users can switch between tenants they own or have been invited to. Active tenant is stored in localStorage and passed to all tRPC calls. The schema includes 19 tables: tenants, users, products, orders, customers, subscriptions, webhooks, analytics, social_posts, referrals, leads, automations, and more. Each table is tenant-scoped. Result: A platform that can scale to thousands of tenants without compromising security or data isolation.

The Stripe → Meta CAPI bridge is the critical link between commerce transactions and Meta's advertising algorithm. Without this bridge, every paid conversion is invisible to Meta, which means higher CPM and CPL over time. The implementation: 1. **Stripe Webhook Handler** (/api/stripe/webhook): Listens for `checkout.session.completed` events. Extracts customer email, order amount, and metadata (user_id, customer_name). 2. **CAPI Event Fire** (firePurchase): Calls Meta's Conversions API with: - event_name: "Purchase" - event_id: Stripe session ID (deduplication) - user_data: email, phone, first/last name, city, state, zip - custom_data: value (order amount), currency (USD) - test_event_code: META_TEST_EVENT_CODE (for sandbox testing) 3. **Webhook Signature Verification**: Stripe signs all webhooks with HMAC-SHA256. The handler verifies the signature before processing to prevent spoofing. 4. **Idempotency**: Event IDs are Stripe session IDs, so duplicate webhooks don't create duplicate CAPI events. Result: Every paid conversion is immediately fed to Meta's algorithm, which learns your customer profile and optimizes future ad delivery. This is the highest-leverage integration for paid acquisition.

Scroll-triggered animations are a common UX pattern, but they are often implemented poorly — using scroll event listeners that fire hundreds of times per second, causing jank and battery drain. UnifyOne uses the modern IntersectionObserver API, which is performant and declarative: 1. **useScrollReveal<T> Hook**: Accepts a ref to a container and an array of child elements. Sets up an IntersectionObserver with threshold 0.1 and rootMargin -40px (bottom). When an element enters the viewport, it adds the `reveal-visible` class, which triggers the `animate-rise` keyframe. 2. **CSS Keyframes**: `@keyframes animate-rise` moves elements from `transform: translateY(40px); opacity: 0` to `transform: translateY(0); opacity: 1` over 0.6s with cubic-bezier easing. 3. **Accessibility**: Respects `prefers-reduced-motion` media query. If the user has enabled reduced motion, animations are skipped entirely. 4. **Staggered Delays**: Each child element has a `data-reveal-delay` attribute (in milliseconds). The hook applies a CSS custom property `--reveal-delay` which is used in the animation-delay property. Result: Smooth, performant animations that enhance the "cathedral being constructed" narrative without causing performance issues.