Skip to main content

Platform v1 Complete Capability Inventory

Purpose

This document is the exhaustive, evidence-backed inventory of what v1 currently does across the whole monorepo. Status tags used:
  • active: implemented and wired to real logic
  • partial: present but incomplete/TODO/mock-dependent
  • duplicate: multiple implementations for same surface
  • legacy: stale/old preserved implementation
  • uncertain: intent exists but behavior or usage is not fully provable from current code
Architecture-vs-implementation rule used throughout:
  • Preserve architecture ideas separately from code reuse decisions.
  • A capability can be strategically important while its current implementation remains non-reusable.

How v1 Currently Works (System Narrative)

1) Runtime topology (Open to changing or deleting this)

  • Monorepo is organized into deployable apps, shared packages, and a worker service.
  • Core deployables:
    • apps/platform (multi-tenant control plane)
    • apps/chat (public business chat runtime)
    • apps/kb-studio (KB studio UI, scaffold state)
    • services/worker (KB job execution)
  • Evidence:
    • docs/monorepo-architecture.md
    • docs/dokploy-monorepo.md

2) Shell and tenancy flow (Keep this for v2 after stability is verified)

  • Platform root routes authenticated users into admin shell and unauthenticated users to login.
  • Admin shell wraps pages with auth checks, user loading, role context, sidebar, and settings/theme hydration.
  • Tenancy model is Platform -> Agency -> Business with scoped access and role matrix.
  • Evidence:
    • apps/platform/src/app/page.tsx
    • apps/platform/src/app/admin/layout.tsx
    • apps/platform/src/lib/auth.js
    • apps/platform/src/lib/tenant-context.js
    • supabase/migrations/001_multi_tenant_schema.sql
    • supabase/migrations/002_rls_policies.sql

3) Impersonation and effective identity (Keep this for v2 after stability is verified)

  • Impersonation state is stored in local storage and cookie platform_impersonation.
  • Super admin can impersonate agency/business; agency admin can impersonate business in-scope.
  • Effective user/role/tenant ids are normalized on server for scoped APIs.
  • Evidence:
    • apps/platform/src/context/ImpersonationContext.tsx
    • apps/platform/src/lib/tenant-context.js
    • apps/platform/src/app/api/settings/route.js

4) Inheritance and settings resolution (Keep this for v2 after stability is verified)

  • Settings inherit/merge through platform-level settings, then agency-level overrides, then business-level overrides.
  • Same pattern appears for integration sharing and branding controls.
  • Evidence:
    • apps/platform/src/app/api/settings/route.js
    • packages/db/src/integration-sharing.js
    • apps/platform/src/app/api/agencies/[agencyId]/branding/route.js
    • apps/platform/src/app/api/businesses/[businessId]/branding/route.js

5) Module import/catalog model (Unstable. Open to rebuilding this)

  • Platform app catalog supports listing apps, importing app packages, assessing manifests, storing import metadata.
  • Manifest and normalization rules live in app-sdk layer.
  • Evidence:
    • apps/platform/src/features/app-catalog/PlatformAppCatalogScreen.jsx
    • apps/platform/src/app/api/platform/apps/route.js
    • apps/platform/src/app/api/platform/apps/import/route.js
    • packages/app-sdk/src/imports.js
    • packages/app-sdk/src/manifests.js
    • supabase/migrations/008_app_platform_catalog.sql
    • supabase/migrations/20260315120000_platform_app_imports.sql
    • supabase/migrations/20260315180025_create_normalization_reports.sql

6) Chat runtime model(s) (Unstable. Open to rebuilding this)

  • Business-facing chat runtime is implemented as standalone apps/chat and mirrored in parts of platform APIs.
  • Public chat routes load business runtime config, process AI responses, persist conversations, and capture leads.
  • Platform also has chat-related admin/service surfaces and overlapping API behavior.
  • Evidence:
    • apps/chat/src/app/[accountId]/page.jsx
    • apps/chat/src/app/api/chat/route.js
    • apps/chat/src/app/api/leads/route.js
    • apps/platform/src/app/api/chat/route.js
    • apps/platform/src/app/admin/services/chat/*

7) KB generation and worker pipeline (Unstable. Open to rebuilding this)

  • Onboarding/KB APIs create and manage KB generation jobs.
  • Worker service claims and runs jobs with KB engine functions.
  • KB Studio app exists but is currently scaffold-level.
  • Evidence:
    • apps/platform/src/app/api/kb-jobs/route.js
    • apps/platform/src/app/api/knowledge-base/route.js
    • services/worker/src/index.js
    • services/worker/src/run-job.js
    • packages/kb-engine/src/*
    • apps/kb-studio/src/app/*

8) Auth/permissions/RLS/security behavior (Keep this for v2 after stability is verified)

  • Auth via Supabase helpers and service-role API clients.
  • Role checks are in permissions package and platform auth library wrappers.
  • RLS policies encode tenant-scoped data access across key tables.
  • Evidence:
    • packages/permissions/src/auth.js
    • apps/platform/src/lib/auth.js
    • supabase/migrations/002_rls_policies.sql

9) Theming/branding/white-label/custom domain behavior (Unstable. Open to rebuilding this)

  • Platform/agency/business branding APIs exist with merge/fallback behavior.
  • Login/secure-login/setup-account and domain verification flows support white-label style runtime customization.
  • Custom domains and verification endpoints exist for businesses.
  • Evidence:
    • apps/platform/src/app/api/agencies/[agencyId]/branding/route.js
    • apps/platform/src/app/api/businesses/[businessId]/branding/route.js
    • apps/platform/src/app/api/businesses/[businessId]/domains/route.js
    • apps/platform/src/app/api/verify-domain/route.js
    • apps/platform/src/app/secure-login/page.tsx
    • apps/platform/src/app/setup-account/page.tsx
    • apps/chat/src/app/page.jsx

10) Deployment/runtime operational model (Keep this for v2 after stability is verified)

  • Dokploy deployments are app-specific by workspace/build args/watch paths using root Dockerfile.
  • Required env vars include Supabase and encryption keys with app-specific public URL wiring.
  • Evidence:
    • docs/dokploy-monorepo.md
    • Dockerfile

Capability Index by Subsystem

  • A1 Authentication and session routing
  • A2 Tenancy and impersonation
  • A3 Agency/business/user administration
  • A4 Branding/theming/white-label/custom domains
  • A5 Module catalog/import/manifest normalization
  • A6 Capabilities library (n8n-template and import lane)
  • A7 Integrations/connectors/composio/http requests
  • A8 Chat runtime and conversation handling
  • A9 Lead capture, webhook, email delivery
  • A10 Knowledge base onboarding/jobs/worker pipeline
  • A11 Billing/reporting/account/settings utilities
  • A12 SDK and shared package layer
  • A13 DB schema/migrations/RLS/infra
  • A14 Non-canonical surfaces (duplicate/legacy/partial)

Capability Catalog (Comprehensive)


Capability Labels (Migration + v2 Placement)

Label set 1:
  • Safe To Migrate
  • Rebuild In v2
  • Do Not Migrate
Label set 2:
  • Shell
  • Module
  • Other

Capability Index by Status Tag

active

C-001, C-002, C-003, C-004, C-005, C-006, C-007, C-008, C-009, C-010, C-011, C-012, C-013, C-014, C-015, C-016, C-017, C-018, C-019, C-020, C-021, C-022, C-023, C-024, C-025, C-026, C-027, C-028, C-029, C-030, C-031, C-032, C-033, C-034, C-036, C-037, C-038, C-039, C-040, C-041, C-042, C-043, C-044, C-045, C-050, C-051, C-052, C-054, C-055, C-056, C-057, C-058, C-059, C-064, C-065, C-066, C-067, C-068, C-069, C-070, C-071, C-073

partial

C-046, C-047, C-048, C-049, C-053, C-076, C-077

duplicate

C-035, C-074

legacy

C-063, C-075, C-078

uncertain

C-060, C-061, C-062, C-072

v1 Capability Coverage Matrix (PRD Handoff)


Non-Canonical and Edge Capability Surfaces (Explicit)

  • Whitelabel/custom domains:
    • apps/platform/src/app/api/businesses/[businessId]/domains/route.js
    • apps/platform/src/app/api/verify-domain/route.js
    • apps/chat/src/app/page.jsx
  • Impersonation:
    • apps/platform/src/context/ImpersonationContext.tsx
    • apps/platform/src/lib/tenant-context.js
  • User/tenant-specific UI customization:
    • apps/platform/src/app/admin/branding/page.jsx
    • apps/platform/src/app/admin/dashboard-settings/page.tsx
    • apps/platform/src/app/api/settings/route.js
  • Partial/placeholder and TODO/mocks:
    • apps/platform/src/app/admin/billing/subscriptions/page.tsx
    • apps/platform/src/app/admin/billing/invoices/page.tsx
    • apps/platform/src/app/admin/billing/page.tsx
    • apps/kb-studio/src/app/projects/page.jsx
  • Duplicated implementations:
    • .jsx and .tsx pairs under apps/platform/src/app/admin/**
    • overlapping chat API implementations in apps/platform/src/app/api/chat/route.js and apps/chat/src/app/api/chat/route.js
  • Legacy .old route files:
    • apps/platform/src/app/admin/**/*.old

Cross-Doc Alignment Check

This inventory is aligned with:
  • docs/v1-audit/01-repo-map.md
  • docs/v1-audit/02-foundation-vs-apps.md
  • docs/v1-audit/03a-auth-and-permissions.md
  • docs/v1-audit/03b-module-manifest-system.md
  • docs/v1-audit/03c-branding-and-theming.md
  • docs/v1-audit/03d-chat-core.md
  • docs/v1-audit/03e-kb-engine.md
  • docs/v1-audit/03f-db-client-server-patterns.md
  • docs/v1-audit/04-app-audit-platform.md
  • docs/v1-audit/04-app-audit-chat.md
  • docs/v1-audit/04-app-audit-kb-studio.md
  • docs/v1-audit/05-delete-list-with-reasons.md
  • docs/v1-audit/06-prd-input-summary.md
  • docs/v1-audit/07-multi-tenancy-clean-port-plan.md

Appendix A: Complete Route Surface Inventory (apps/platform)

Appendix B: Complete Route Surface Inventory (apps/chat)

Appendix C: Complete Route Surface Inventory (apps/kb-studio)

Appendix D: Package and Service Capability Layers

D1 packages/*

D2 sdk/packages/*

D3 services/*

Appendix E: Migration Capability Surface (supabase/migrations)