Project_Velocity/.Agent Context/Sprint 1/Founder CRM and Platform Delivery Pack/00 - Founder Pack Guide.md

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.