ar2

2026-07-07 16:32:26 +07:00
parent 62762fc70c
commit 919d9e4f8a
9 changed files with 2616 additions and 0 deletions
--- a/plans/task-ar.1.md
+++ b/plans/task-ar.1.md
@@ -0,0 +1,698 @@
+# Task AR.1 – Architecture Transition Plan
+
+Status: Completed
+
+Priority: Critical
+
+Type: Solution Architecture / Transition Planning
+
+Depends On
+
+- BU-R.0 Business Blueprint Freeze
+- BU-R.0.1 Workspace & Activity Blueprint
+- BU-R.1 Business Capability Audit
+
+---
+
+# Objective
+
+Produce the complete transition architecture from the current ALLA OS implementation to the approved Relationship-Driven Sales Operating Platform architecture.
+
+This phase defines **how** the future architecture will be introduced while preserving the existing production foundation.
+
+The primary goal is:
+
+> Preserve the current production CRM foundation and extend it through new architectural layers rather than replacing existing domains.
+
+This phase is architecture-only.
+
+No production implementation is allowed.
+
+---
+
+# Background
+
+Business Discovery has completed.
+
+Business Blueprint has been frozen.
+
+Business Capability Audit confirms that:
+
+- Customer
+- Contact
+- Lead
+- Opportunity
+- Quotation
+- Approval
+- Organization
+- RBAC
+- PDF
+- Dashboard
+
+already provide a mature production foundation.
+
+The remaining gaps are primarily cross-cutting capabilities:
+
+- Activity Platform
+- Timeline
+- Calendar Workspace
+- My Day
+- Manager Workspace
+- Executive Workspace
+- Business Event Architecture
+
+AR.1 defines how these capabilities are introduced without breaking the existing architecture.
+
+---
+
+# Architecture Principles
+
+Every proposal must follow:
+
+## Preserve Before Replace
+
+Reuse existing production domains whenever possible.
+
+---
+
+## Extension Before Refactor
+
+Prefer adding new architectural layers.
+
+Avoid modifying existing domains unless unavoidable.
+
+---
+
+## Single Source of Truth
+
+Every business concept must have one owner.
+
+No duplicated lifecycle.
+
+No duplicated status.
+
+No duplicated business meaning.
+
+---
+
+## Projection over Duplication
+
+Timeline
+
+Calendar
+
+Dashboard
+
+Notification
+
+must consume projections instead of storing duplicated business data.
+
+---
+
+## Backward Compatibility First
+
+Existing APIs
+
+Existing UI
+
+Existing Schema
+
+must remain compatible unless a controlled migration is explicitly approved.
+
+---
+
+# Review Required
+
+Review
+
+- Business Constitution
+- BU-R.1 Capability Audit
+- Current Schema
+- Current CRM Modules
+- Current Foundation Modules
+- Existing API Contracts
+- Existing Permission Model
+- Existing Notification Foundation
+- Existing Approval Runtime
+- Existing Dashboard
+- Existing PDF Engine
+
+---
+
+# Scope
+
+## Part 1 — Current Architecture Map
+
+Document the current architecture.
+
+Identify
+
+Relationship Layer
+
+CRM Layer
+
+Foundation Layer
+
+Reporting Layer
+
+Notification Layer
+
+Approval Layer
+
+Storage Layer
+
+Security Layer
+
+Document
+
+Responsibilities
+
+Ownership
+
+Dependencies
+
+Extension points
+
+---
+
+## Part 2 — Target Architecture
+
+Produce the target architecture.
+
+Include
+
+Relationship Layer
+
+Activity Layer
+
+Project Layer
+
+Commercial Layer
+
+Workspace Layer
+
+Analytics Layer
+
+Foundation Layer
+
+Security Layer
+
+Document
+
+Responsibilities
+
+Boundaries
+
+Ownership
+
+Interaction
+
+---
+
+## Part 3 — Transition Architecture
+
+Design the transition path.
+
+For every capability determine
+
+Preserve
+
+Extend
+
+Refactor
+
+Replace
+
+Migration Required
+
+Backward Compatible
+
+Breaking Change Risk
+
+---
+
+## Part 4 — Activity Platform Architecture
+
+Define
+
+Activity Domain
+
+Activity Service
+
+Activity Repository
+
+Activity API
+
+Activity Projection
+
+Activity Ownership
+
+Activity Lifecycle
+
+Integration with
+
+Customer
+
+Lead
+
+Opportunity
+
+Quotation
+
+Notification
+
+Calendar
+
+Timeline
+
+Dashboard
+
+---
+
+## Part 5 — Timeline Projection Architecture
+
+Define
+
+Timeline Source
+
+Timeline Generator
+
+Timeline Projection
+
+Timeline Query
+
+Timeline Security
+
+Timeline Caching
+
+Timeline Event Mapping
+
+Confirm
+
+Timeline is generated.
+
+Timeline is never manually edited.
+
+---
+
+## Part 6 — Calendar Projection Architecture
+
+Define
+
+Calendar Source
+
+Activity Projection
+
+Milestone Projection
+
+Reminder Projection
+
+Approval Projection
+
+Forecast Projection
+
+Calendar Aggregation
+
+Calendar Filters
+
+Calendar Permissions
+
+Calendar Query Strategy
+
+---
+
+## Part 7 — Business Event Architecture
+
+Freeze
+
+Domain Event Ownership
+
+Business Event Types
+
+Publisher
+
+Subscriber
+
+Timeline Consumer
+
+Dashboard Consumer
+
+Notification Consumer
+
+Automation Consumer
+
+Determine
+
+Event Contracts
+
+Event Naming
+
+Event Versioning
+
+Event Payload Strategy
+
+---
+
+## Part 8 — Workspace Architecture
+
+Design
+
+Customer Workspace
+
+Sales Workspace
+
+Manager Workspace
+
+Executive Workspace
+
+Calendar Workspace
+
+My Day
+
+Navigation
+
+Permission Boundary
+
+Workspace Composition
+
+---
+
+## Part 9 — Integration Strategy
+
+Determine
+
+Existing Module Reuse
+
+Adapter Layer
+
+Projection Layer
+
+Service Composition
+
+Shared Components
+
+API Compatibility
+
+Feature Flags
+
+Migration Strategy
+
+---
+
+## Part 10 — Implementation Strategy
+
+Group implementation into Epics.
+
+Example
+
+Epic
+
+Activity Platform
+
+Epic
+
+Timeline Projection
+
+Epic
+
+Calendar Workspace
+
+Epic
+
+Customer Workspace
+
+Epic
+
+Manager Workspace
+
+Epic
+
+My Day
+
+Epic
+
+Business Events
+
+Epic
+
+Notification Expansion
+
+Epic
+
+Forecast Enhancement
+
+---
+
+# Deliverables
+
+Produce
+
+## 1
+
+Current Architecture Diagram
+
+---
+
+## 2
+
+Target Architecture Diagram
+
+---
+
+## 3
+
+Transition Architecture Diagram
+
+---
+
+## 4
+
+Domain Ownership Matrix
+
+---
+
+## 5
+
+Layer Responsibility Matrix
+
+---
+
+## 6
+
+Business Event Architecture
+
+---
+
+## 7
+
+Activity Architecture
+
+---
+
+## 8
+
+Timeline Projection Architecture
+
+---
+
+## 9
+
+Calendar Projection Architecture
+
+---
+
+## 10
+
+Workspace Architecture
+
+---
+
+## 11
+
+Dependency Graph
+
+---
+
+## 12
+
+Migration Strategy
+
+Categorize
+
+Preserve
+
+Extend
+
+Refactor
+
+Replace
+
+---
+
+## 13
+
+Breaking Change Assessment
+
+Risk
+
+Mitigation
+
+Compatibility
+
+---
+
+## 14
+
+Epic Roadmap
+
+Priority
+
+Dependency
+
+Estimated Order
+
+---
+
+## 15. Domain Dependency Matrix
+
+Produce a dependency matrix describing how each business domain depends on and is consumed by other domains.
+
+The objective is to visualize architectural coupling before implementation begins.
+
+For every major domain identify:
+
+- Domain Owner
+- Depends On
+- Used By
+- Shared Services
+- Projection Consumers
+- Potential Breaking Change Impact
+
+Minimum domains:
+
+| Domain | Depends On | Used By |
+|----------|------------|---------|
+| Customer | Foundation | Contact, Activity, Lead, Opportunity |
+| Contact | Customer | Activity, Lead |
+| Activity | Customer, Contact, Lead, Opportunity, Quotation | Calendar, Timeline, My Day, Notification |
+| Lead | Customer | Opportunity |
+| Opportunity | Customer, Lead | Quotation, Dashboard, Forecast |
+| Quotation | Opportunity | Approval, PDF, Timeline |
+| Approval | Quotation | Notification |
+| Timeline | Business Events | Customer Workspace |
+| Calendar | Activity + Milestones | My Day, Manager Workspace |
+| Dashboard | Opportunity + Activity + Events | Manager, Executive |
+
+Deliverables
+
+- Domain Dependency Diagram
+- Domain Dependency Matrix
+- Coupling Analysis
+- High-Risk Dependency List
+- Recommended Decoupling Strategy
+
+---
+
+## 16. Preserve / Extend / Refactor Matrix
+
+Produce the official architectural transition strategy for every major module.
+
+Every module must be classified into one of the following categories:
+
+- Preserve
+- Preserve + Extend
+- Controlled Refactor
+- New Capability
+- Replace (only if explicitly justified)
+
+The objective is to minimize disruption to the existing production architecture.
+
+Minimum matrix:
+
+| Module | Strategy | Notes |
+|----------|----------|-------|
+| Organization | Preserve | Core Foundation |
+| RBAC | Preserve | Existing Permission Model |
+| Customer | Preserve + Extend | Add Customer Workspace capabilities |
+| Contact | Preserve | Existing Sharing Rules |
+| Lead | Preserve + Minor Enhancement | Align Business Blueprint |
+| Opportunity | Preserve + Extend | Forecast, Activity, Hot Project |
+| Quotation | Preserve | Document Lifecycle Owner |
+| Approval | Preserve | Existing Approval Engine |
+| PDF | Preserve | Existing Document Engine |
+| Dashboard | Preserve + Extend | Business-driven Metrics |
+| Notification | Preserve + Extend | Consume Business Events |
+| Activity | New Capability | Shared Operational Domain |
+| Timeline | New Projection | Generated View |
+| Calendar | New Projection | Workspace Layer |
+| My Day | New Workspace | Personalized Operational Workspace |
+| Manager Workspace | New Workspace | Operational Control Tower |
+| Executive Workspace | New Workspace | Strategic Monitoring |
+
+Deliverables
+
+- Preserve Matrix
+- Extension Matrix
+- Refactor Matrix
+- New Capability Matrix
+- Breaking Change Impact Matrix
+- Migration Recommendation
+
+Frozen Rule
+
+Every implementation epic after AR.1 must explicitly reference this matrix before modifying any production module.
+
+If a proposed implementation changes a module classified as "Preserve", the implementation must include an Architecture Decision Record (ADR) explaining the reason, impact analysis, rollback strategy, and backward compatibility assessment.
+
+# Constraints
+
+This phase is architecture only.
+
+DO NOT
+
+- modify schema
+- modify migrations
+- modify APIs
+- modify services
+- modify UI
+- modify permissions
+- modify business logic
+
+No production implementation is allowed.
+
+---
+
+# Success Criteria
+
+A complete transition architecture exists.
+
+Every new capability has a defined architectural location.
+
+Every existing capability has a preservation strategy.
+
+Every integration point is documented.
+
+Every migration path is documented.
+
+Breaking changes are minimized.
+
+Core CRM foundation remains preserved.
+
+Architecture is implementation-ready.
+
+Ready for
+
+AR.2 – Epic & Technical Design
+
+
+## Architecture Governance Rule
+
+AR.1 becomes the official architecture transition baseline.
+
+Every future Epic, ADR, schema change, API change, or implementation task must reference:
+
+- Business Constitution (BU-R.0 / BU-R.0.1)
+- Business Capability Audit (BU-R.1)
+- Architecture Transition Plan (AR.1)
+
+Any implementation that violates the approved transition strategy must provide explicit architectural justification and receive governance approval before implementation begins.