r0
This commit is contained in:
450
docs/business/relationship-sales-workspace-blueprint-v1.md
Normal file
450
docs/business/relationship-sales-workspace-blueprint-v1.md
Normal file
@@ -0,0 +1,450 @@
|
||||
# Relationship & Sales Workspace Blueprint v1
|
||||
|
||||
Status: Draft Freeze Candidate
|
||||
Last Updated: 2026-07-07
|
||||
Owner: Business Architecture / CRM Governance
|
||||
|
||||
## Purpose
|
||||
|
||||
This document freezes the target long-term business architecture for ALLA OS as a Relationship-Driven Sales Workspace. It is the business source of truth for future capability audits, schema refactoring, API design, workflow design, dashboard design, and workspace navigation.
|
||||
|
||||
This blueprint has higher priority than legacy implementation wording when conflicts exist. Existing accepted ADRs and implementation notes remain historical references until they are reconciled in later phases.
|
||||
|
||||
## Review Baseline
|
||||
|
||||
This blueprint was aligned against:
|
||||
|
||||
- `AGENTS.md`
|
||||
- `docs/standards/project-foundations.md`
|
||||
- `docs/standards/architecture-rules.md`
|
||||
- `docs/standards/ui-ux-rules.md`
|
||||
- `docs/standards/task-review-checklist.md`
|
||||
- `docs/business/crm-terminology.md`
|
||||
- `docs/security/crm-authorization-boundaries.md`
|
||||
- `docs/adr/0011-lead-enquiry-ownership-model.md`
|
||||
- `docs/adr/0015-customer-ownership-contact-sharing.md`
|
||||
- `docs/adr/0016-won-lost-lifecycle-governance.md`
|
||||
- `docs/adr/0018-lead-enquiry-domain-separation.md`
|
||||
- `plans/task-d.5.md`
|
||||
- `plans/task-d.6.2.md`
|
||||
- current CRM schema and opportunity / quotation timeline fields in `src/db/schema.ts`
|
||||
|
||||
## 1. Product Vision Freeze
|
||||
|
||||
### Product Vision
|
||||
|
||||
ALLA OS is a Relationship-Driven Sales Workspace for B2B commercial teams that need one operational system for customer relationships, opportunity execution, quotation control, follow-up discipline, forecasting, and management visibility.
|
||||
|
||||
### Product Mission
|
||||
|
||||
Help teams move from fragmented CRM records into a governed daily operating workspace where relationship context, next actions, sales execution, document progress, and management signals stay connected.
|
||||
|
||||
### Design Philosophy
|
||||
|
||||
- Relationship first, transaction second
|
||||
- Activities are the operating heartbeat
|
||||
- Opportunities own commercial project execution
|
||||
- Quotations own document and approval execution
|
||||
- Calendar and timeline are working views, not isolated modules
|
||||
- Dashboard metrics must come from governed lifecycle state, not ad hoc UI interpretation
|
||||
|
||||
### Core Principles
|
||||
|
||||
1. One business concept should have one primary owner.
|
||||
2. Relationship context must survive handoffs across marketing, sales, and management.
|
||||
3. Activities should be reusable across leads, opportunities, quotations, and customers.
|
||||
4. Forecast and priority signals must be explicit business fields, not derived from loose notes.
|
||||
5. Timeline should be generated from business events instead of becoming a second source of truth.
|
||||
6. Calendar should aggregate actionable work, not act as a standalone isolated domain.
|
||||
|
||||
## 2. Business Terminology Dictionary
|
||||
|
||||
| Term | Official Definition | Primary Owner |
|
||||
| --- | --- | --- |
|
||||
| Customer | A business account already known to the organization and managed as a reusable commercial relationship record. | Shared relationship master |
|
||||
| Prospect | A customer account type representing a relationship not yet established as an active buying customer. | Customer classification |
|
||||
| Contact | A person connected to a customer account and governed by ownership and sharing rules. | Customer relationship layer |
|
||||
| Lead | A marketing-origin or early-stage commercial signal that may later create one or more opportunities. | Marketing |
|
||||
| Opportunity | The sales-owned project lifecycle record for qualifying demand, follow-up, forecasting, and business outcome. | Sales |
|
||||
| Quotation | The sales document lifecycle record for pricing, revision, approval, preview, and approved output. | Sales / Commercial operations |
|
||||
| PO | The external purchase order confirmation that finalizes a won commercial outcome. | Customer-side commercial confirmation |
|
||||
| Activity | A single reusable work record representing planned or completed business interaction or internal execution. | Shared operational foundation |
|
||||
| Follow-up | A sales or marketing activity intended to move a lead, opportunity, or quotation forward. | Activity subtype |
|
||||
| Task | An internal action item assigned to a user with due-date accountability. | Activity subtype |
|
||||
| Reminder | A time-based prompt for upcoming work or business commitments. | Activity / notification layer |
|
||||
| Visit | A physical or remote customer-facing interaction recorded as an activity. | Activity subtype |
|
||||
| Meeting | A scheduled business discussion recorded as an activity. | Activity subtype |
|
||||
| Site Survey | A project qualification or technical assessment activity for an opportunity or quotation. | Activity subtype |
|
||||
| Presentation | A commercial presentation or proposal discussion activity. | Activity subtype |
|
||||
| Timeline | A generated chronological business view assembled from events and activities across related records. | Generated view |
|
||||
| Workspace | A role-oriented working surface that prioritizes decisions, tasks, and context for a specific user group. | Product navigation layer |
|
||||
| Pipeline | The governed set of active leads or opportunities moving toward an outcome. | Lead / opportunity analytics |
|
||||
| Forecast | A forward-looking commercial projection built from active opportunity signals. | Opportunity analytics |
|
||||
| Expected Award Date | The best current estimate of when an opportunity may be commercially awarded or confirmed. | Opportunity |
|
||||
| Expected Delivery Date | The best current estimate of operational delivery timing after commercial confirmation. | Opportunity / quotation execution |
|
||||
| Hot Project | A managed priority signal for opportunities or quotations that need elevated attention because of timing, value, risk, or strategic importance. | Opportunity-led priority model |
|
||||
| Status | A high-level business state shown to users. | Entity-specific |
|
||||
| Process Status | A lifecycle-progress state describing where execution currently stands. | Entity-specific |
|
||||
| Outcome | A business result state such as open, won, or lost. | Entity-specific |
|
||||
|
||||
## 3. Customer Relationship Model Freeze
|
||||
|
||||
The relationship model is:
|
||||
|
||||
```text
|
||||
Customer
|
||||
-> Contact
|
||||
-> Lead
|
||||
-> Opportunity
|
||||
-> Quotation
|
||||
-> PO / Won-Lost Outcome
|
||||
```
|
||||
|
||||
Rules:
|
||||
|
||||
- Customer is the reusable relationship anchor.
|
||||
- Customer ownership remains a first-class governance rule.
|
||||
- Contact visibility remains governed by sharing plus customer access.
|
||||
- Lead represents marketing discovery and early qualification.
|
||||
- Opportunity represents sales execution and owns the project lifecycle.
|
||||
- Quotation represents document execution and owns pricing, approval, and revision history.
|
||||
|
||||
## 4. Activity Model Freeze
|
||||
|
||||
Activity becomes the shared operational model across customer, lead, opportunity, and quotation work.
|
||||
|
||||
Supported activity families:
|
||||
|
||||
- Follow-up
|
||||
- Visit
|
||||
- Meeting
|
||||
- Reminder
|
||||
- Task
|
||||
- Email
|
||||
- Phone Call
|
||||
- Presentation
|
||||
- Site Survey
|
||||
- Internal Task
|
||||
|
||||
Rules:
|
||||
|
||||
- Activity is the single business activity model.
|
||||
- Activities may reference one primary entity and optional related entities.
|
||||
- Timeline entries are generated from activities plus business events.
|
||||
- Calendar surfaces scheduled activities and reminders, not freeform historical notes alone.
|
||||
- Notifications and future automation should subscribe to activity state changes instead of duplicating activity data.
|
||||
|
||||
## 5. Project Lifecycle Freeze
|
||||
|
||||
The official project lifecycle is:
|
||||
|
||||
```text
|
||||
Lead
|
||||
-> Opportunity
|
||||
-> Quotation
|
||||
-> PO Received
|
||||
-> Won
|
||||
```
|
||||
|
||||
Alternative close path:
|
||||
|
||||
```text
|
||||
Lead
|
||||
-> Opportunity
|
||||
-> Lost
|
||||
```
|
||||
|
||||
Ownership by stage:
|
||||
|
||||
- Lead is marketing-owned.
|
||||
- Opportunity is sales-owned.
|
||||
- Quotation is sales-owned and document-controlled.
|
||||
- Won/Lost is decided from opportunity outcome governance.
|
||||
|
||||
## 6. Status Strategy Freeze
|
||||
|
||||
### Ownership Boundaries
|
||||
|
||||
- Lead owns early discovery and marketing follow-up state.
|
||||
- Opportunity owns project process state and commercial forecast state.
|
||||
- Quotation owns document process state, approval state, and revision state.
|
||||
|
||||
### Status Model
|
||||
|
||||
- Process Status answers "where are we in execution?"
|
||||
- Operational Status answers "what is the current working condition?"
|
||||
- Outcome answers "what business result has been reached?"
|
||||
|
||||
### Frozen Rule
|
||||
|
||||
Opportunity owns project process. Quotation owns document status. Quotation status alone must not decide business win/loss.
|
||||
|
||||
## 7. Hot Project Strategy Freeze
|
||||
|
||||
Hot Project is a governed attention flag, not a substitute for lifecycle status.
|
||||
|
||||
Purpose:
|
||||
|
||||
- highlight time-sensitive opportunities
|
||||
- expose management attention needs
|
||||
- support dashboard prioritization
|
||||
- support follow-up discipline and forecast review
|
||||
|
||||
Rules:
|
||||
|
||||
- Hot Project is opportunity-led.
|
||||
- Quotation may inherit or display the same signal for document execution context.
|
||||
- Auto-suggestion is allowed from timeline rules such as near-term award/close windows.
|
||||
- Manual override is allowed and must be preserved.
|
||||
- Hot Project does not automatically mean high probability, won, or urgent delivery.
|
||||
|
||||
## 8. Forecast Strategy Freeze
|
||||
|
||||
### Expected Award Date
|
||||
|
||||
Definition:
|
||||
The current best estimate of when the customer may decide, award, or confirm the opportunity commercially.
|
||||
|
||||
Usage:
|
||||
|
||||
- forecast views
|
||||
- pipeline aging and expected-award monitoring
|
||||
- management dashboard
|
||||
- calendar awareness when follow-up should intensify
|
||||
- reminder generation
|
||||
|
||||
### Expected Delivery Date
|
||||
|
||||
Definition:
|
||||
The current best estimate of when fulfillment or delivery is expected after the opportunity progresses toward execution.
|
||||
|
||||
Usage:
|
||||
|
||||
- delivery coordination awareness
|
||||
- opportunity-to-quotation context
|
||||
- manager workload planning
|
||||
- post-award readiness monitoring
|
||||
|
||||
Rules:
|
||||
|
||||
- Expected Award Date belongs primarily to opportunity forecasting.
|
||||
- Expected Delivery Date belongs to downstream execution planning and may appear on both opportunity and quotation surfaces.
|
||||
|
||||
## 9. Workspace Architecture Freeze
|
||||
|
||||
### Workspace Set
|
||||
|
||||
- Marketing Workspace
|
||||
- Sales Workspace
|
||||
- Manager Workspace
|
||||
- Executive Workspace
|
||||
- Calendar Workspace
|
||||
|
||||
### Role of Each Workspace
|
||||
|
||||
- Marketing Workspace manages lead creation, lead follow-up, awareness analytics, and handoff quality.
|
||||
- Sales Workspace manages opportunities, quotations, project progress, and customer-facing execution.
|
||||
- Manager Workspace focuses on team follow-up, forecast confidence, hot projects, and workload balance.
|
||||
- Executive Workspace focuses on pipeline health, revenue outlook, strategic accounts, and business outcomes.
|
||||
- Calendar Workspace is the time-based operational lens across roles.
|
||||
|
||||
### Philosophy
|
||||
|
||||
- Workspaces are role-oriented views over shared governed data.
|
||||
- Calendar is a workspace, not a disconnected module.
|
||||
- My Day is a personalized subset of calendar, tasks, reminders, and urgent follow-ups.
|
||||
- Timeline is a contextual history view, not a separate entity users maintain directly.
|
||||
|
||||
## 10. Timeline Strategy Freeze
|
||||
|
||||
Timeline is generated dynamically from business events and activities.
|
||||
|
||||
Rules:
|
||||
|
||||
- Timeline owner is the platform, not a user-maintained table of manual history items.
|
||||
- Sources include activities, assignments, status transitions, quotation revisions, approvals, attachments, and outcome events.
|
||||
- Ordering is chronological by event time with deterministic tie-breaking.
|
||||
- Visibility follows the permission of the originating records and related pricing/security boundaries.
|
||||
- Timeline is read-oriented and should not become a second workflow engine.
|
||||
|
||||
## 11. Calendar Strategy Freeze
|
||||
|
||||
Calendar is the scheduled execution workspace.
|
||||
|
||||
Sources:
|
||||
|
||||
- activities with date/time
|
||||
- reminders
|
||||
- follow-up due dates
|
||||
- meeting / visit / presentation / survey schedules
|
||||
- selected opportunity and quotation milestone dates when configured as calendar-worthy events
|
||||
|
||||
Rules:
|
||||
|
||||
- Calendar aggregates action-bearing events from existing records.
|
||||
- Personal Calendar shows a user's owned or assigned work.
|
||||
- Team Calendar shows subordinate or permitted shared work.
|
||||
- Manager View emphasizes overdue work, near-term commitments, and hot projects.
|
||||
- Opportunity and quotation dates may contribute calendar signals without becoming duplicate calendar records.
|
||||
|
||||
## 12. Dashboard Strategy Freeze
|
||||
|
||||
The dashboard stack should answer operational questions, not simply restate table data.
|
||||
|
||||
Core dashboard blocks:
|
||||
|
||||
- pipeline
|
||||
- forecast
|
||||
- hot projects
|
||||
- overdue activities
|
||||
- follow-up health
|
||||
- won/lost outcome visibility
|
||||
- role-specific KPI summaries
|
||||
|
||||
Rules:
|
||||
|
||||
- Lead KPI and opportunity KPI should not be blended into one ambiguous count.
|
||||
- Forecast must be opportunity-based.
|
||||
- Revenue and commercial visibility must continue follow pricing authorization boundaries.
|
||||
- Dashboard cards should prioritize actionability over vanity metrics.
|
||||
|
||||
## 13. Capability Map
|
||||
|
||||
| Capability | Primary Workspace | Owning Domain |
|
||||
| --- | --- | --- |
|
||||
| Relationship master management | Sales / Manager | Customer + Contact |
|
||||
| Prospecting and awareness capture | Marketing | Lead |
|
||||
| Sales qualification and project pursuit | Sales | Opportunity |
|
||||
| Pricing, revision, and approval | Sales / Manager | Quotation |
|
||||
| Follow-up and activity discipline | All | Activity |
|
||||
| Daily scheduling and reminders | All | Calendar workspace |
|
||||
| Contextual business history | All | Timeline |
|
||||
| Forecast review | Manager / Executive | Opportunity analytics |
|
||||
| Priority escalation | Manager / Sales | Hot project model |
|
||||
| Outcome monitoring | Manager / Executive | Opportunity outcome |
|
||||
|
||||
## 14. Journey Views
|
||||
|
||||
### Customer Journey
|
||||
|
||||
```text
|
||||
Prospect Customer
|
||||
-> Relationship Development
|
||||
-> Active Customer
|
||||
-> Repeat Opportunity / Quotation Cycles
|
||||
```
|
||||
|
||||
### Project Journey
|
||||
|
||||
```text
|
||||
Lead
|
||||
-> Opportunity
|
||||
-> Follow-up / Qualification
|
||||
-> Quotation
|
||||
-> Revision / Approval
|
||||
-> PO Received
|
||||
-> Delivery Planning
|
||||
```
|
||||
|
||||
### Activity Journey
|
||||
|
||||
```text
|
||||
Planned Activity
|
||||
-> Due
|
||||
-> Completed / Rescheduled / Cancelled
|
||||
-> Follow-up or Next Action
|
||||
-> Timeline + Calendar visibility
|
||||
```
|
||||
|
||||
## 15. State Machine Freeze
|
||||
|
||||
### Lead
|
||||
|
||||
```text
|
||||
Open
|
||||
-> Qualified / Handoff Ready
|
||||
-> Converted to Opportunity
|
||||
-> Lost / Cancelled
|
||||
```
|
||||
|
||||
### Opportunity
|
||||
|
||||
```text
|
||||
Open
|
||||
-> In Progress
|
||||
-> Quotation in Flight
|
||||
-> Won
|
||||
-> Lost
|
||||
```
|
||||
|
||||
### Quotation
|
||||
|
||||
```text
|
||||
Draft
|
||||
-> Sent
|
||||
-> Under Revision
|
||||
-> Pending Approval
|
||||
-> Approved / Rejected / Returned
|
||||
-> Commercially Referenced by Opportunity Outcome
|
||||
```
|
||||
|
||||
Frozen rule:
|
||||
|
||||
- Opportunity outcome is the business result state.
|
||||
- Quotation approval is a document control state.
|
||||
|
||||
## 16. Gap Summary: Current System vs Blueprint
|
||||
|
||||
| Area | Current State | Blueprint Direction | Gap Type |
|
||||
| --- | --- | --- | --- |
|
||||
| Terminology | Historical docs still mix `enquiry` and `opportunity`. | Opportunity is the official sales project term. | Refactor |
|
||||
| Lead vs opportunity model | Schema already has `crm_leads` and `crm_opportunities`, but older ADR lineage still references shared enquiry history. | Keep split-domain model and retire mixed terminology in governance docs. | Refactor |
|
||||
| Timeline | Follow-up/timeline concepts exist in features, but platform-wide generated timeline philosophy is not yet frozen as one rule. | Generated timeline view from activities + events. | Enhancement |
|
||||
| Calendar | Date fields and follow-up schedules exist, but calendar-as-workspace is not yet fully defined. | Calendar becomes cross-role operational workspace. | New capability |
|
||||
| Forecast fields | Opportunity and quotation timeline fields exist, but business meaning is not yet frozen centrally. | Expected Award Date and Expected Delivery Date become governed forecast concepts. | Enhancement |
|
||||
| Hot Project | Data support exists in opportunity and quotation flows. | Formalize Hot Project as governed priority signal with auto-suggest and override. | Enhancement |
|
||||
| Activity model | Follow-up exists in multiple domains. | Activity becomes the shared model across work types. | Refactor |
|
||||
| Workspace model | Role-oriented pages exist, but workspace philosophy is incomplete. | Freeze marketing, sales, manager, executive, and calendar workspace roles. | Enhancement |
|
||||
|
||||
## 17. Recommended Refactoring Strategy
|
||||
|
||||
### No Change
|
||||
|
||||
- Preserve organization, RBAC, approval, PDF, document artifact, and quotation foundations.
|
||||
- Preserve customer ownership and contact sharing governance.
|
||||
- Preserve won/lost governance where PO received defines won.
|
||||
|
||||
### Enhancement
|
||||
|
||||
- Align dashboard, reporting, and calendar behavior to the frozen forecast and Hot Project definitions.
|
||||
- Expand opportunity and quotation views to expose the frozen timeline and calendar concepts consistently.
|
||||
|
||||
### Refactor
|
||||
|
||||
- Remove remaining business documentation that still treats `enquiry` as the primary sales term.
|
||||
- Consolidate follow-up and activity semantics under one shared business model.
|
||||
- Reconcile older ADR wording with the split lead/opportunity model now reflected in schema and UI direction.
|
||||
|
||||
### New Capability
|
||||
|
||||
- Calendar Workspace
|
||||
- generated cross-entity Timeline
|
||||
- My Day operational surface
|
||||
- broader activity orchestration and automation
|
||||
|
||||
## 18. Governance Notes for Phase R.1
|
||||
|
||||
Phase R.1 should use this blueprint to audit:
|
||||
|
||||
- where code, docs, reports, and APIs still use historical `enquiry` wording
|
||||
- where activity data is duplicated instead of normalized conceptually
|
||||
- where calendar and timeline behavior is implicit rather than governed
|
||||
- where dashboard metrics still need formal mapping to frozen business definitions
|
||||
|
||||
## 19. Entry Criteria for Next Phase
|
||||
|
||||
Phase R.1 may begin when:
|
||||
|
||||
1. this blueprint is accepted as the business baseline
|
||||
2. terminology conflicts are treated as governance backlog instead of hidden assumptions
|
||||
3. capability audit work references this document explicitly
|
||||
@@ -0,0 +1,74 @@
|
||||
# Task BU-R.0 Implementation Report - 2026-07-07
|
||||
|
||||
## Scope
|
||||
|
||||
- start Phase R.0 as a documentation-only business architecture task
|
||||
- review current governance, CRM business rules, ADRs, security boundaries, and current schema direction
|
||||
- produce the first frozen business blueprint artifact and record the baseline findings
|
||||
|
||||
## Review Summary
|
||||
|
||||
Reviewed before writing the blueprint:
|
||||
|
||||
- [AGENTS.md](/C:/Users/mtpphtaps/Documents/gitea/alla-allaos-fullstack/AGENTS.md)
|
||||
- [plans/task-bu-r.0.md](/C:/Users/mtpphtaps/Documents/gitea/alla-allaos-fullstack/plans/task-bu-r.0.md)
|
||||
- [docs/standards/project-foundations.md](/C:/Users/mtpphtaps/Documents/gitea/alla-allaos-fullstack/docs/standards/project-foundations.md)
|
||||
- [docs/standards/architecture-rules.md](/C:/Users/mtpphtaps/Documents/gitea/alla-allaos-fullstack/docs/standards/architecture-rules.md)
|
||||
- [docs/standards/ui-ux-rules.md](/C:/Users/mtpphtaps/Documents/gitea/alla-allaos-fullstack/docs/standards/ui-ux-rules.md)
|
||||
- [docs/standards/task-review-checklist.md](/C:/Users/mtpphtaps/Documents/gitea/alla-allaos-fullstack/docs/standards/task-review-checklist.md)
|
||||
- [docs/standards/task-catalog.md](/C:/Users/mtpphtaps/Documents/gitea/alla-allaos-fullstack/docs/standards/task-catalog.md)
|
||||
- [docs/business/crm-terminology.md](/C:/Users/mtpphtaps/Documents/gitea/alla-allaos-fullstack/docs/business/crm-terminology.md)
|
||||
- [docs/security/crm-authorization-boundaries.md](/C:/Users/mtpphtaps/Documents/gitea/alla-allaos-fullstack/docs/security/crm-authorization-boundaries.md)
|
||||
- [docs/adr/0011-lead-enquiry-ownership-model.md](/C:/Users/mtpphtaps/Documents/gitea/alla-allaos-fullstack/docs/adr/0011-lead-enquiry-ownership-model.md)
|
||||
- [docs/adr/0015-customer-ownership-contact-sharing.md](/C:/Users/mtpphtaps/Documents/gitea/alla-allaos-fullstack/docs/adr/0015-customer-ownership-contact-sharing.md)
|
||||
- [docs/adr/0016-won-lost-lifecycle-governance.md](/C:/Users/mtpphtaps/Documents/gitea/alla-allaos-fullstack/docs/adr/0016-won-lost-lifecycle-governance.md)
|
||||
- [docs/adr/0018-lead-enquiry-domain-separation.md](/C:/Users/mtpphtaps/Documents/gitea/alla-allaos-fullstack/docs/adr/0018-lead-enquiry-domain-separation.md)
|
||||
- [plans/task-d.5.md](/C:/Users/mtpphtaps/Documents/gitea/alla-allaos-fullstack/plans/task-d.5.md)
|
||||
- [plans/task-d.6.2.md](/C:/Users/mtpphtaps/Documents/gitea/alla-allaos-fullstack/plans/task-d.6.2.md)
|
||||
- [task-d55-opportunity-sales-workspace-refinement.md](/C:/Users/mtpphtaps/Documents/gitea/alla-allaos-fullstack/docs/implementation/task-d55-opportunity-sales-workspace-refinement.md)
|
||||
- [schema.ts](/C:/Users/mtpphtaps/Documents/gitea/alla-allaos-fullstack/src/db/schema.ts)
|
||||
- [crm-access.ts](/C:/Users/mtpphtaps/Documents/gitea/alla-allaos-fullstack/src/lib/auth/crm-access.ts)
|
||||
|
||||
## Baseline Findings
|
||||
|
||||
1. The codebase has already moved materially toward a split `lead + opportunity + quotation` model in schema and UI direction, even though older ADR history still contains `enquiry`-centric language.
|
||||
2. `crm_leads` and `crm_opportunities` already exist in [schema.ts](/C:/Users/mtpphtaps/Documents/gitea/alla-allaos-fullstack/src/db/schema.ts), which makes the unresolved terminology conflict a governance problem more than an implementation absence.
|
||||
3. Hot-project and delivery timeline behavior already exist technically in opportunity and quotation fields, but the business definitions for `Hot Project`, `Expected Award Date`, and `Expected Delivery Date` were not frozen in one business document.
|
||||
4. The repo has strong foundations for ownership, authorization, approval, PDF, reporting, and audit, so Phase R.0 should not redesign foundations. It should clarify business meaning that later phases must map onto those foundations.
|
||||
5. Calendar and timeline concepts appear in plans and feature discussions, but there was no single approved statement that timeline is a generated view and calendar is a role-based workspace.
|
||||
|
||||
## Artifacts Created
|
||||
|
||||
- Created the official blueprint draft:
|
||||
[relationship-sales-workspace-blueprint-v1.md](/C:/Users/mtpphtaps/Documents/gitea/alla-allaos-fullstack/docs/business/relationship-sales-workspace-blueprint-v1.md)
|
||||
|
||||
## Freeze Decisions Captured in This Pass
|
||||
|
||||
- ALLA OS is frozen as a `Relationship-Driven Sales Workspace`.
|
||||
- `Opportunity` is frozen as the official sales-owned project lifecycle term.
|
||||
- `Quotation` is frozen as the document lifecycle owner.
|
||||
- `Hot Project` is frozen as a governed priority signal, not a lifecycle status.
|
||||
- `Timeline` is frozen as a generated business view.
|
||||
- `Calendar` is frozen as an operational workspace, not a standalone isolated module.
|
||||
- `Expected Award Date` and `Expected Delivery Date` are frozen as governed business forecast concepts.
|
||||
- `Activity` is frozen as the shared operational model that should unify follow-up-oriented work over time.
|
||||
|
||||
## Remaining Governance Gaps
|
||||
|
||||
1. ADR reconciliation is still needed where accepted historical ADRs use `enquiry` while current schema and blueprint use `opportunity`.
|
||||
2. The blueprint freezes the target activity model, but implementation still contains domain-specific follow-up structures that Phase R.1 should audit for consolidation strategy.
|
||||
3. Calendar Workspace and generated Timeline are frozen conceptually here, but not yet decomposed into implementation contracts, datasets, or APIs.
|
||||
|
||||
## Verification
|
||||
|
||||
- No schema, API, UI, service, or permission code was changed.
|
||||
- No build or test command was needed because this pass only added documentation.
|
||||
|
||||
## Next Recommended Step
|
||||
|
||||
Use this blueprint as the required input for Phase R.1 Business Capability Audit, with special focus on:
|
||||
|
||||
- terminology conflicts
|
||||
- activity model duplication
|
||||
- timeline / calendar capability mapping
|
||||
- dashboard and forecast metric alignment
|
||||
597
plans/task-bu-r.0.md
Normal file
597
plans/task-bu-r.0.md
Normal file
@@ -0,0 +1,597 @@
|
||||
# Phase R.0 – Business Blueprint Freeze
|
||||
|
||||
Status: In Progress
|
||||
|
||||
Priority: Critical
|
||||
|
||||
Type: Business Discovery / Architecture
|
||||
|
||||
---
|
||||
|
||||
# Objective
|
||||
|
||||
Freeze the long-term business architecture and business terminology of ALLA OS before performing any schema refactoring or implementation work.
|
||||
|
||||
This phase focuses on validating business concepts, ownership boundaries, user workflows, lifecycle definitions, and workspace philosophy.
|
||||
|
||||
No database schema, API, UI, or implementation changes are allowed during this phase.
|
||||
|
||||
The output of this phase becomes the official Business Blueprint for all future development.
|
||||
|
||||
---
|
||||
|
||||
# Background
|
||||
|
||||
ALLA OS has evolved from a traditional CRM into a Relationship-Driven Sales Workspace.
|
||||
|
||||
Several new business concepts have emerged during Business Discovery:
|
||||
|
||||
- Relationship First
|
||||
- Activity-Centric Workspace
|
||||
- Opportunity owns Project Lifecycle
|
||||
- Quotation owns Document Lifecycle
|
||||
- Calendar as a Workspace instead of a standalone module
|
||||
- Timeline as a generated business view
|
||||
- Customer Account Type (Customer / Prospect)
|
||||
- Expected Award Date
|
||||
- Hot Project Business Model
|
||||
|
||||
These concepts must be frozen before auditing the existing implementation.
|
||||
|
||||
---
|
||||
|
||||
# Review Required
|
||||
|
||||
Review all existing business decisions before making any proposal.
|
||||
|
||||
Must review:
|
||||
|
||||
- AGENTS.md
|
||||
- Project Standards
|
||||
- Architecture Rules
|
||||
- Task Catalog
|
||||
- Existing CRM Blueprint
|
||||
- Business Discovery notes
|
||||
- Previous ADRs
|
||||
- Existing Schema
|
||||
- Existing API structure
|
||||
- Existing Workspace design
|
||||
|
||||
Do not assume any undocumented business rule.
|
||||
|
||||
---
|
||||
|
||||
# Scope
|
||||
|
||||
## 1. Product Vision
|
||||
|
||||
Freeze:
|
||||
|
||||
- Product Vision
|
||||
- Product Mission
|
||||
- Design Philosophy
|
||||
- Core Principles
|
||||
|
||||
Validate that ALLA OS is positioned as
|
||||
|
||||
Relationship-Driven Sales Workspace
|
||||
|
||||
instead of a traditional CRM.
|
||||
|
||||
---
|
||||
|
||||
## 2. Business Terminology
|
||||
|
||||
Freeze official definitions.
|
||||
|
||||
Examples:
|
||||
|
||||
Customer
|
||||
|
||||
Prospect
|
||||
|
||||
Lead
|
||||
|
||||
Opportunity
|
||||
|
||||
Quotation
|
||||
|
||||
PO
|
||||
|
||||
Activity
|
||||
|
||||
Follow-up
|
||||
|
||||
Task
|
||||
|
||||
Reminder
|
||||
|
||||
Visit
|
||||
|
||||
Meeting
|
||||
|
||||
Site Survey
|
||||
|
||||
Presentation
|
||||
|
||||
Timeline
|
||||
|
||||
Workspace
|
||||
|
||||
Pipeline
|
||||
|
||||
Forecast
|
||||
|
||||
Expected Award Date
|
||||
|
||||
Expected Delivery Date
|
||||
|
||||
Hot Project
|
||||
|
||||
Status
|
||||
|
||||
Process Status
|
||||
|
||||
Outcome
|
||||
|
||||
Every business term must have exactly one official definition.
|
||||
|
||||
---
|
||||
|
||||
## 3. Customer Relationship Model
|
||||
|
||||
Review and freeze
|
||||
|
||||
Customer
|
||||
|
||||
↓
|
||||
|
||||
Contacts
|
||||
|
||||
↓
|
||||
|
||||
Activities
|
||||
|
||||
↓
|
||||
|
||||
Leads
|
||||
|
||||
↓
|
||||
|
||||
Opportunities
|
||||
|
||||
↓
|
||||
|
||||
Quotations
|
||||
|
||||
↓
|
||||
|
||||
PO
|
||||
|
||||
Validate
|
||||
|
||||
Customer Account Type
|
||||
|
||||
- Customer
|
||||
- Prospect
|
||||
|
||||
Confirm that Customer remains the master entity.
|
||||
|
||||
---
|
||||
|
||||
## 4. Activity Model
|
||||
|
||||
Determine whether Activity becomes the single business activity model.
|
||||
|
||||
Review:
|
||||
|
||||
Follow-up
|
||||
|
||||
Visit
|
||||
|
||||
Meeting
|
||||
|
||||
Reminder
|
||||
|
||||
Task
|
||||
|
||||
Email
|
||||
|
||||
Phone Call
|
||||
|
||||
Presentation
|
||||
|
||||
Site Survey
|
||||
|
||||
Internal Task
|
||||
|
||||
Determine
|
||||
|
||||
Activity ownership
|
||||
|
||||
Reference strategy
|
||||
|
||||
Timeline strategy
|
||||
|
||||
Calendar strategy
|
||||
|
||||
Notification strategy
|
||||
|
||||
Future automation capability
|
||||
|
||||
---
|
||||
|
||||
## 5. Project Lifecycle
|
||||
|
||||
Freeze
|
||||
|
||||
Lead
|
||||
|
||||
↓
|
||||
|
||||
Opportunity
|
||||
|
||||
↓
|
||||
|
||||
Quotation
|
||||
|
||||
↓
|
||||
|
||||
PO
|
||||
|
||||
Review ownership of each stage.
|
||||
|
||||
---
|
||||
|
||||
## 6. Status Strategy
|
||||
|
||||
Review
|
||||
|
||||
Lead
|
||||
|
||||
Opportunity
|
||||
|
||||
Quotation
|
||||
|
||||
Determine
|
||||
|
||||
Process Status
|
||||
|
||||
Operational Status
|
||||
|
||||
Business Outcome
|
||||
|
||||
Ownership
|
||||
|
||||
Transition Rules
|
||||
|
||||
State Machine
|
||||
|
||||
Confirm that
|
||||
|
||||
Opportunity owns Project Process
|
||||
|
||||
Quotation owns Document Status
|
||||
|
||||
---
|
||||
|
||||
## 7. Hot Project Strategy
|
||||
|
||||
Freeze business definition.
|
||||
|
||||
Determine
|
||||
|
||||
Purpose
|
||||
|
||||
Owner
|
||||
|
||||
Calculation
|
||||
|
||||
Manual Override
|
||||
|
||||
Approval
|
||||
|
||||
Dashboard behavior
|
||||
|
||||
Forecast relationship
|
||||
|
||||
---
|
||||
|
||||
## 8. Forecast Strategy
|
||||
|
||||
Freeze
|
||||
|
||||
Expected Award Date
|
||||
|
||||
Definition
|
||||
|
||||
Business meaning
|
||||
|
||||
Forecast usage
|
||||
|
||||
Dashboard usage
|
||||
|
||||
Calendar usage
|
||||
|
||||
Reminder usage
|
||||
|
||||
Freeze
|
||||
|
||||
Expected Delivery Date
|
||||
|
||||
Definition
|
||||
|
||||
Business meaning
|
||||
|
||||
Operation usage
|
||||
|
||||
---
|
||||
|
||||
## 9. Workspace Model
|
||||
|
||||
Review
|
||||
|
||||
Marketing Workspace
|
||||
|
||||
Sales Workspace
|
||||
|
||||
Manager Workspace
|
||||
|
||||
Executive Workspace
|
||||
|
||||
Determine
|
||||
|
||||
Daily workflow
|
||||
|
||||
Workspace navigation
|
||||
|
||||
Primary landing page
|
||||
|
||||
Calendar philosophy
|
||||
|
||||
My Day philosophy
|
||||
|
||||
Timeline philosophy
|
||||
|
||||
---
|
||||
|
||||
## 10. Timeline Strategy
|
||||
|
||||
Determine
|
||||
|
||||
Timeline owner
|
||||
|
||||
Timeline generation
|
||||
|
||||
Timeline source
|
||||
|
||||
Timeline ordering
|
||||
|
||||
Timeline visibility
|
||||
|
||||
Timeline permission
|
||||
|
||||
Confirm whether Timeline is generated dynamically instead of stored.
|
||||
|
||||
---
|
||||
|
||||
## 11. Calendar Strategy
|
||||
|
||||
Determine
|
||||
|
||||
Calendar data source
|
||||
|
||||
Activity synchronization
|
||||
|
||||
Opportunity synchronization
|
||||
|
||||
Quotation synchronization
|
||||
|
||||
Reminder synchronization
|
||||
|
||||
Manager View
|
||||
|
||||
Team Calendar
|
||||
|
||||
Personal Calendar
|
||||
|
||||
---
|
||||
|
||||
## 12. Dashboard Strategy
|
||||
|
||||
Review
|
||||
|
||||
Sales Dashboard
|
||||
|
||||
Manager Dashboard
|
||||
|
||||
Executive Dashboard
|
||||
|
||||
Forecast
|
||||
|
||||
Pipeline
|
||||
|
||||
Hot Project
|
||||
|
||||
Overdue Activities
|
||||
|
||||
Follow-up
|
||||
|
||||
KPI
|
||||
|
||||
---
|
||||
|
||||
# Deliverables
|
||||
|
||||
The implementation must produce
|
||||
|
||||
## 1
|
||||
|
||||
Relationship & Sales Workspace Blueprint v1
|
||||
|
||||
---
|
||||
|
||||
## 2
|
||||
|
||||
Business Terminology Dictionary
|
||||
|
||||
---
|
||||
|
||||
## 3
|
||||
|
||||
Core Business Principles
|
||||
|
||||
---
|
||||
|
||||
## 4
|
||||
|
||||
Business Capability Map
|
||||
|
||||
---
|
||||
|
||||
## 5
|
||||
|
||||
Business Lifecycle Diagram
|
||||
|
||||
---
|
||||
|
||||
## 6
|
||||
|
||||
Workspace Architecture
|
||||
|
||||
---
|
||||
|
||||
## 7
|
||||
|
||||
Customer Journey
|
||||
|
||||
---
|
||||
|
||||
## 8
|
||||
|
||||
Project Journey
|
||||
|
||||
---
|
||||
|
||||
## 9
|
||||
|
||||
Activity Journey
|
||||
|
||||
---
|
||||
|
||||
## 10
|
||||
|
||||
State Machine Diagram
|
||||
|
||||
Lead
|
||||
|
||||
Opportunity
|
||||
|
||||
Quotation
|
||||
|
||||
---
|
||||
|
||||
## 11
|
||||
|
||||
Gap Summary
|
||||
|
||||
Current System
|
||||
|
||||
vs
|
||||
|
||||
Business Blueprint
|
||||
|
||||
---
|
||||
|
||||
## 12
|
||||
|
||||
Recommended Refactoring Strategy
|
||||
|
||||
Categorize into
|
||||
|
||||
No Change
|
||||
|
||||
Enhancement
|
||||
|
||||
Refactor
|
||||
|
||||
New Capability
|
||||
|
||||
---
|
||||
|
||||
# Constraints
|
||||
|
||||
During this phase
|
||||
|
||||
DO NOT
|
||||
|
||||
- modify schema
|
||||
- modify migrations
|
||||
- modify database
|
||||
- modify API
|
||||
- modify services
|
||||
- modify UI
|
||||
- modify permissions
|
||||
- modify business logic
|
||||
|
||||
This phase is documentation and architecture validation only.
|
||||
|
||||
---
|
||||
|
||||
# Success Criteria
|
||||
|
||||
Business terminology is fully standardized.
|
||||
|
||||
Every entity has a single owner.
|
||||
|
||||
No duplicated responsibility exists.
|
||||
|
||||
No conflicting business rules remain.
|
||||
|
||||
Customer Journey is finalized.
|
||||
|
||||
Project Journey is finalized.
|
||||
|
||||
Workspace philosophy is finalized.
|
||||
|
||||
Timeline philosophy is finalized.
|
||||
|
||||
Calendar philosophy is finalized.
|
||||
|
||||
Ready for
|
||||
|
||||
Phase R.1 – Business Capability Audit
|
||||
|
||||
without changing the core architecture.
|
||||
|
||||
Architecture Protection Rules
|
||||
|
||||
- Reuse existing Foundation whenever possible.
|
||||
- Prefer Extension over Replacement.
|
||||
- Prefer Composition over Duplication.
|
||||
- Preserve existing API compatibility unless a breaking change is approved.
|
||||
- Preserve Organization, RBAC, Approval, PDF, and Document foundations.
|
||||
- Any schema refactoring must include backward compatibility analysis.
|
||||
- Business Blueprint has higher priority than implementation details.
|
||||
|
||||
---
|
||||
|
||||
# Implementation Progress
|
||||
|
||||
## 2026-07-07
|
||||
|
||||
Status: In Progress
|
||||
|
||||
Summary:
|
||||
|
||||
- Reviewed governance, standards, CRM terminology, security boundaries, ADR lineage, and current schema before proposing any freeze output.
|
||||
- Created the first official blueprint draft:
|
||||
`docs/business/relationship-sales-workspace-blueprint-v1.md`
|
||||
- Recorded the review baseline, freeze decisions, and current governance gaps:
|
||||
`docs/implementation/task-bu-r.0-business-blueprint-freeze-2026-07-07.md`
|
||||
|
||||
Current outcome:
|
||||
|
||||
- Phase R.0 has started as a documentation-only architecture task.
|
||||
- The repo now has one central draft document for business vision, terminology, lifecycle ownership, workspace philosophy, timeline, calendar, forecast, Hot Project, and gap summary.
|
||||
- Historical `enquiry` vs `opportunity` conflicts are documented for follow-up reconciliation in Phase R.1.
|
||||
Reference in New Issue
Block a user