alla-allaos-fullstack/plans/task-ep1.1.md

# 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.