5.8 KiB
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
- Activity Domain Model
- Activity Lifecycle
- Activity Service
- Activity Repository
- Activity API
- Activity Permission Integration
- Activity UI Foundation
- Activity Integration Contracts
- Existing Follow-up Gap Analysis
- 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.