# EP.1.1 – Activity Domain Foundation Status: Planning Priority: Critical Type: Feature Foundation Depends On - BU-R.0 Business Constitution - BU-R.0.1 Workspace & Activity Blueprint - BU-R.1 Business Capability Audit - AR.1 Architecture Transition Plan - AR.2 Epic Technical Design - AR.2 Workspace UI/UX Design Note - ENG.0 Engineering Constitution --- # Objective Introduce the shared Activity Domain as the operational foundation of ALLA OS. This epic establishes the Activity aggregate, ownership model, business rules, service boundaries, and integration points while preserving all existing CRM modules. This phase delivers only the Activity foundation. Timeline, Calendar, My Day, Dashboard, and Notification are intentionally excluded and will consume Activity in later epics. --- # Background Business Constitution defines Activity as the shared operational model. Architecture Constitution defines Activity as the source domain for future projections. Engineering Constitution requires: - Preserve existing CRM domains - Extend rather than replace - Keep Activity as the single operational write model Current implementation already contains several activity-like concepts: - Follow-up - Reminder - Site Visit - Meeting - Internal Task These must be audited and unified without breaking existing production behavior. --- # Review Required Review before implementation: Business - Relationship & Sales Workspace Blueprint - Activity Blueprint Architecture - AR.1 Architecture Transition Plan - AR.2 Epic Technical Design Engineering - Engineering Constitution UI - Workspace UI/UX Design Note - layout.md - ui-ux-rules.md - ui-ux-pro-max Implementation - Existing Follow-up modules - Existing Customer detail - Existing Opportunity detail - Existing Quotation detail - Existing Notification logic - Existing Permission model --- # Scope ## Part 1 — Activity Domain Model Create Activity Aggregate Define - Activity - Activity Owner - Activity Assignee - Activity Type - Activity Status - Activity Priority Freeze ownership. Activity becomes the only operational work entity. --- ## Part 2 — Activity Lifecycle Define Draft Scheduled In Progress Completed Cancelled Skipped Overdue Define Allowed transitions Completion rules Reschedule rules Assignment rules --- ## Part 3 — Activity Relationship Model Activity may reference Customer Contact Lead Opportunity Quotation PO Internal Only Exactly one source context is required. --- ## Part 4 — Activity Business Rules Freeze Assignment Ownership Visibility Permission Completion Deletion Editing History Determine Recurring activities Parent / Child activities Future dependency support --- ## Part 5 — Activity Service Introduce Activity Service Responsibilities Create Update Assign Complete Cancel Reschedule Permission validation Audit logging Business validation Route Handlers remain thin. --- ## Part 6 — Activity Repository Create repository abstraction. Separate Write model Read model Prepare for future projections. --- ## Part 7 — Activity API Introduce REST endpoints Create Update Delete Assign Complete Cancel Reschedule List Get Detail API must follow existing CRM conventions. --- ## Part 8 — Permission Model Integrate with existing CRM authorization. Support Owner Assignee Manager Administrator Respect Organization Branch Product Type Pricing visibility boundaries. --- ## Part 9 — Existing Module Integration Integrate Activity with Customer Lead Opportunity Quotation without changing their ownership. Do not migrate Follow-up yet. Only establish extension points. --- ## Part 10 — Future Projection Preparation Publish integration contracts for Timeline Calendar Notification My Day Dashboard Do NOT implement projections. Only define extension interfaces. --- # UI Scope Implement only foundational UI. Review - layout.md - ui-ux-rules.md - ui-ux-pro-max Deliver - Activity Sheet - Activity Form - Activity Detail - Activity Badge - Activity Status Badge - Activity Priority Badge Do NOT build - Calendar - Timeline - My Day - Manager Workspace UI must extend existing CRM patterns. --- # Deliverables 1. Activity Domain Model 2. Activity Lifecycle 3. Activity Service 4. Activity Repository 5. Activity API 6. Activity Permission Integration 7. Activity UI Foundation 8. Activity Integration Contracts 9. Existing Follow-up Gap Analysis 10. Migration Preparation Report --- # Constraints Must preserve - Customer - Lead - Opportunity - Quotation - Approval - RBAC - Organization - Existing APIs No Calendar. No Timeline. No Dashboard. No Notification Expansion. No projection implementation. No migration of existing Follow-up records. --- # Acceptance Criteria - Activity becomes the official operational domain. - Existing CRM behavior remains unchanged. - Activity is reusable by all future workspaces. - Existing Follow-up implementation continues working. - Projection interfaces are prepared without implementation. - Thin Route Handler pattern is preserved. - Service-owned business logic is preserved. - All new UI follows layout.md, ui-ux-rules.md, and ui-ux-pro-max. - Existing shadcn/ui patterns are reused. - No breaking changes are introduced. --- # Success Criteria ALLA OS now has a production-ready Activity Foundation. Future epics can consume Activity without redesign. Ready for EP.1.2 – Activity Integration & Follow-up Consolidation. ## Compatibility Strategy During EP.1.1, existing Follow-up implementations remain operational. The new Activity Domain must coexist with legacy Follow-up structures. No existing API contracts may be removed. No database records are migrated. No UI flow changes are introduced. Activity is introduced as an additive capability only. Legacy Follow-up consolidation is deferred to EP.1.2 after Activity Foundation has been validated.