Chatwoot Full Adaptation Plan
## Objective
Analyze the full source code and features of Chatwoot, and decide feature by feature what should be: - Reused (conceptually) - Adapted with major changes - Rewritten from scratch - Completely ignored
WisprX will include a mobile app, real-time messaging, full CRM, inbox system, queues, campaigns, automation engine, and integration ecosystem.
The final system must be: - 100% NestJS backend (no Rails) - 100% React/Next.js frontend (no Vue) - Scalable, modular, testable and multitenant - Architecturally clean — no technical debt
## ✅ Use (Reimplement the Concept)
- Inbox Routing → `src/domains/inbox/` - Conversation Views (`Unassigned`, `Mine`, `All`) → Inbox Frontend + API - Contact Auto-Creation → `src/domains/crm/contacts/` - Webhooks Receiver → `src/shared/webhooks/` - Agent Notes → `src/domains/internalchat/` - Tags System → `crm/tags/` - Templates/Macros → `knowledgebase/templates/` - SLA & First Response Time → `analytics/` - Message Status Tracking → `messaging/` - Roles & Permissions (base) → `core/auth/roles/` - REST API versioning and structure (conceptual)
## ⚠️ Adapt (Rewrite the Architecture, Keep the Idea)
- Contact Management (UI + Model) → `crm/contacts/` - Attachment Handling → `files/` - Campaign Engine → `campaigns/` - Feature Flags → `core/flags/` - Typing Indicator → `messaging/websocket/` - Widget → `shared/widgets/` - Agent Status/Availability → `core/status/` - Email Threading & Replies → `messaging/email/` - OAuth Flows → `core/auth/oauth/`
## 🔁 Rewrite (Goal Is Kept, Code Is Discarded)
- Message Queueing (Sidekiq) → `core/queues/` (BullMQ) - Rails Controllers → `domains/*/controller.ts` - Workers → `core/queues/processors/` - Conversations API → `inbox/` - Automations Engine → `automations/` - Analytics Layer → `analytics/` - Socket Handling → `messaging/gateway/`
## ❌ Ignore (Out of Scope or Useless Legacy)
- Chatwoot React Native App → We'll create a clean RN app from scratch - ActionCable / Rails Channels → Replaced by WebSocket Gateway - Chatwoot Admin Dashboards → WisprX will have its own metrics layer - Rails Feature Flag System → Rebuilt as tenant-level config - Rails Monolith, Sidekiq, ERB views → Not compatible
## 🔗 Integrations: Classification
### ✅ Use - WhatsApp via WPPConnect - Facebook Messenger / Instagram DM / Telegram - Email piping (Inboxes) - Webhooks to external CRMs
### ⚠️ Adapt - Slack integration → `notifications/` - CRM enrichment APIs → `integrations/hubspot`, `integrations/clearbit` - Dialogflow fallback → routed via service/queue - Zapier → via n8n or webhook trigger
### 🔁 Rewrite - CRM sync logic (very embedded) - Lead Capture Widget → Create headless + pluggable version
### ❌ Ignore - Chatwoot internal webhook signature logic → standardize via HMAC - Intercom importers and one-off migration scripts
## Copilot Guidelines
- Analyze source code of Chatwoot, but never copy directly - Follow folder strategy: `domains/`, `core/`, `shared/` - Maintain WisprX semantic naming (`CreateUserDto`, `UserEntity`, etc) - Always use `tenantId` filtering and validation - Document decisions in `/docs/adaptation-map/` - Detect missing modules and propose additions
This blueprint helps you extract only the best, refactor where needed, and build WisprX in a future-proof way.