task-ep.1.1

plans/task-ep1.1.md

@@ -0,0 +1,445 @@
+# 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.