Project_Velocity/.Agent Context/Sprint 1/Founder CRM and Platform Delivery Pack/06 - Execution Backlog_ Founder CRM and Platform Planning.md

Execution Backlog_ Founder CRM and Platform Planning

Date: 2026-04-18
Status: Draft
Owner: Sagnik
Reviewers: Sayan, Sourik
Scope: Sequenced founder workstreams for CRM, client graph, imports, infra truth, and documentation convergence
Purpose: Translate the founder implementation blueprint into an execution-ready planning backlog with ownership, sequencing, and approval gates.
Decision Boundary: This backlog governs planning deliverables and future implementation preparation. It does not itself authorize coding.

1. Purpose

This backlog governs the founder-side convergence work required before Project Velocity can move into a clean CRM-centered implementation phase.

2. Delivery Principles

• reconcile current truth before adding new architecture
• define canonical data before building new UI
• preserve raw evidence before flattening into operator views
• keep Oracle adjacent to CRM, not above it
• respect owner boundaries across Founder, Sayan, and Sourik

3. Workstream Backlog

Workstream A: Repo and Sprint truth reconciliation

• objective: align all founder planning to the current repo rather than outdated assumptions
• tasks:
  • reconcile Sprint 1 fact table against repo and handoffs
  • identify stale vs current claims
  • mark legacy feeders and current owner boundaries
• definition of done:
  • reconciliation matrix completed and usable as a review artifact

Workstream B: Infra and operator truth

• objective: create one founder-safe deployment and routing reference
• tasks:
  • consolidate Linux origin truth
  • consolidate ingress truth
  • consolidate Comfy/GPU/NVMe truth
  • define endpoint ownership matrix
• definition of done:
  • operator can understand the runtime topology without opening multiple older docs

Workstream C: CRM product architecture

• objective: define CRM as a top-level product module
• tasks:
  • define CRM IA
  • define Oracle adjacency
  • define contact/account/opportunity/task/import/client-360 surfaces
  • define reuse strategy for existing Oracle pipeline/detail components
• definition of done:
  • CRM product shell is clear enough for frontend implementation planning

Workstream D: Canonical domains and root API

• objective: define the target persistence and route model
• tasks:
  • define crm_*, intel_*, inventory_*, oracle_*, core_*, workflow_*
  • map current tables into target domains
  • define root route families and ownership
• definition of done:
  • DB/root API spec is approval-ready

Workstream E: Import and stewardship model

• objective: define the raw-to-canonical import architecture
• tasks:
  • define CSV-first ingest pipeline
  • define source profile and mapping manifest model
  • define AI assistance and approval gates
• definition of done:
  • import adapter and schema blueprint are implementable

Workstream F: Synthetic data generation prep

• objective: prepare a coding-agent swarm brief for realistic synthetic client graphs
• tasks:
  • define canonical data requirements
  • define property pool and client personas
  • define deliverable formats
• definition of done:
  • a swarm can generate 250 full synthetic client graphs without further architecture decisions

Workstream G: Monolithic truth consolidation

• objective: create the founder-owned single-reference artifact
• tasks:
  • define chapter order
  • seed initial chapters
  • cross-link founder pack documents into the monolith
• definition of done:
  • a new engineer can navigate the product architecture by chapter

4. Acceptance Gates

Gate 1: Current truth locked

• reconciliation matrix completed
• infra/operator truth completed

Gate 2: CRM and DB architecture locked

• PRD, SRS, blueprint, adapter, and DB spec aligned

Gate 3: Execution readiness locked

• backlog, dependency matrix, and synthetic-data brief completed

Gate 4: Founder reference locked

• monolithic truth artifact created and seeded

5. Ownership Model

• Founder
  • CRM
  • import architecture
  • client graph
  • monolithic truth
• Sayan
  • Oracle template DB
  • inventory and multi-surface implications
  • admin/control implications
• Sourik
  • runtime route-family and orchestration implications

6. Sales Readiness Criteria

• contact list and client 360 story is explainable
• Oracle’s role relative to CRM is clear
• import story is believable for existing CRM users
• infra/operator deployment truth is clean enough for buyer confidence

7. Risks

• route-family sprawl without canonical domains
• overloading Oracle with CRM responsibilities
• designing a perfect AI graph that operators cannot practically use
• under-planning migration from current tables

8. Immediate Next Actions

• finalize all founder pack documents
• review with Sayan and Sourik
• lock canonical domain naming
• approve the synthetic data brief
• use the monolith as the next planning anchor

9. Bottom Line

The founder backlog is not about adding more product ideas. It is about forcing the existing product into one coherent operating model before more code compounds the inconsistency.