143 lines
5.5 KiB
Markdown
143 lines
5.5 KiB
Markdown
# Founder CRM and Platform Delivery Pack Guide
|
|
|
|
**Date:** 2026-04-18
|
|
**Status:** Draft
|
|
**Owner:** Sagnik
|
|
**Reviewers:** Sayan, Sourik
|
|
**Scope:** Founder-owned CRM, client graph, import architecture, infra truth, and planning consolidation for Sprint 1
|
|
**Purpose:** Provide the canonical founder document system for planning the remaining Velocity CRM and platform work from first principles.
|
|
**Decision Boundary:** This pack defines the planning truth and approval-ready target architecture. It does not itself authorize code or schema migrations without follow-up approval.
|
|
|
|
## 1. Purpose
|
|
|
|
This pack is the founder-owned planning layer for the parts of Project Velocity that still need convergence:
|
|
|
|
- CRM as a first-class product module
|
|
- canonical client graph and AI-native database structure
|
|
- import architecture
|
|
- infra and operator truth
|
|
- ownership boundaries across Founder, Sayan, and Sourik
|
|
|
|
It intentionally mirrors the discipline of the Sayan and Sourik packs, but it is focused on the founder problem: making Velocity legible, operationally grounded, and commercially credible as a Salesforce replacement for premium real estate teams.
|
|
|
|
## 2. Why This Pack Exists Now
|
|
|
|
The current repo has substantial real implementation, but the planning truth is fragmented:
|
|
|
|
- the Sprint 1 fact table is stale in important places
|
|
- CRM exists in overlapping partial forms
|
|
- Oracle already exists as a real runtime and canvas surface
|
|
- inventory truth exists in raw onboarding assets, not yet as a canonical operational database
|
|
- infra truth exists across multiple handoff docs, not one founder-owned operator reference
|
|
|
|
This pack exists to turn that fragmented reality into an approval-ready plan set.
|
|
|
|
## 3. Working Order
|
|
|
|
This pack should be used in the following order:
|
|
|
|
1. read the reconciliation matrix
|
|
2. read the infra/operator truth doc
|
|
3. read the first-principles document
|
|
4. review the PRD and SRS
|
|
5. review the CRM + DB blueprint and root API spec
|
|
6. review the execution backlog and dependency matrix
|
|
7. only then roll the material up into the monolithic truth artifact
|
|
|
|
## 4. Mandatory Metadata
|
|
|
|
Every document in this pack must include:
|
|
|
|
- title
|
|
- date
|
|
- status
|
|
- owner
|
|
- reviewers
|
|
- scope
|
|
- purpose
|
|
- decision boundary
|
|
|
|
## 5. Document Map
|
|
|
|
Use these documents for the following outcomes:
|
|
|
|
- `00 - Founder Pack Guide.md`
|
|
- how to use this pack
|
|
- `01 - First Principles_ Founder CRM and Platform Planning.md`
|
|
- founder problem framing and architecture logic
|
|
- `02 - PRD_ Founder CRM and Platform Planning.md`
|
|
- product scope and user outcomes
|
|
- `03 - SRS_ Founder CRM and Platform Planning.md`
|
|
- technical requirements and interfaces
|
|
- `04 - Sprint Plan_ Founder CRM and Platform Planning.md`
|
|
- sequencing and deliverables
|
|
- `05 - Implementation Blueprint_ Founder CRM and Platform Planning.md`
|
|
- current repo truth and target implementation map
|
|
- `06 - Execution Backlog_ Founder CRM and Platform Planning.md`
|
|
- workstreams, ownership, and delivery order
|
|
- `07 - Contracts and Schema Blueprint_ Founder CRM and Platform Planning.md`
|
|
- canonical artifacts and schema contracts
|
|
- `08 - Adapter Detailed Implementation Spec_ CRM Import and Client 360.md`
|
|
- operational CRM adapter and import workflow
|
|
- `09 - Database Schema and Root API Spec_ Founder CRM Canonical Domains.md`
|
|
- canonical tables and API targets
|
|
- `10 - TypeScript Module Spec_ Founder CRM Surface and Oracle Integration.md`
|
|
- frontend CRM and Oracle integration surface
|
|
- `11 - Role Spec_ NemoClaw Import Intelligence and Data Stewardship.md`
|
|
- AI and human stewardship boundaries
|
|
- `12 - Deployment Operations and Release Readiness_ Founder CRM Platform.md`
|
|
- runtime and release truth
|
|
- `13 - Ticket Breakdown and Dependency Matrix_ Founder CRM and Platform Planning.md`
|
|
- implementation slicing
|
|
- `14 - Reconciliation Matrix_ Sprint 1 Fact Table vs Current Repo.md`
|
|
- what is current, stale, partial, and missing
|
|
- `15 - Infrastructure and Operator Truth_ Linux Ingress GPU Comfy.md`
|
|
- canonical infrastructure reference
|
|
- `16 - Coding Agent Swarm Brief_ Synthetic Client Graph Generation.md`
|
|
- synthetic data generation tasking
|
|
|
|
## 6. Review Rule
|
|
|
|
Every document in this pack should be reviewed by:
|
|
|
|
- Founder for product truth
|
|
- Sayan for UI, Oracle template, inventory, and admin implications
|
|
- Sourik for runtime, route family, and orchestration implications
|
|
|
|
If a document changes ownership or architectural boundaries, it should not be treated as approved until all three views have been checked.
|
|
|
|
## 7. Quality Rule
|
|
|
|
A document in this pack is incomplete if it still contains:
|
|
|
|
- unresolved placeholders presented as facts
|
|
- contradictions against the current repo
|
|
- unresolved ownership ambiguity
|
|
- route families with no stated owner
|
|
- target schemas with no migration posture
|
|
- UI intentions with no operational meaning
|
|
|
|
## 8. Writing Rule
|
|
|
|
All founder-pack docs must do four things at once:
|
|
|
|
1. describe current state truth
|
|
2. define the target state
|
|
3. show the gap between the two
|
|
4. state what still needs approval
|
|
|
|
This pack is not allowed to become a purely aspirational strategy set.
|
|
|
|
## 9. Relationship to Other Packs
|
|
|
|
This pack does not replace:
|
|
|
|
- `Sayan Multi-Surface and Oracle Delivery Pack`
|
|
- `Biomimetic Agentic Orchestration Layer`
|
|
|
|
It complements them by defining the founder-owned platform truth those packs depend on.
|
|
|
|
## 10. Bottom Line
|
|
|
|
This pack is the bridge between the current repo and the future sellable system. It is where Project Velocity stops being a collection of real but uneven subsystems and starts becoming one legible product architecture.
|