Project_Velocity/.Agent Context/Sprint 1/Sprint 1 Fact Table - 2026-04-12.md

Sprint 1 Fact Table

Date: 2026-04-12
Scope: Reconciliation of userstories.csv and tasks.csv against the current Project Velocity repo, live infrastructure, and evolved product direction
Purpose: Show what is done, partial, changed, deferred to v2, or still missing

Important Note: tasks.csv and userstories.csv contain many items marked Closed. That is treated here as historical planning metadata, not source-of-truth delivery status. This fact table is based on the current repo, live infrastructure, and the product direction clarified after Sprint 1.

---

Status Key

Status	Meaning
Done	Implemented in current mainline or achieved through an evolved equivalent
Partial	Significant work exists, but the original intent is not fully complete
Changed	Original task was superseded or split into a better/different architecture
V2	Intentionally better treated as v2 or later, not a Sprint 1 blocker now
Missing	Not materially implemented in mainline yet

---

Executive Summary

User Story Rollup

User Story	Status	Reality
1.1 Local/Cloud Hardware Config	Changed	The current AWS/Linux stack is simulation hardware for product proving. The client-facing recommendation is now minimum 1x NVIDIA RTX PRO 6000 Blackwell 96GB, recommended 2x, with horizontal scaling and DGX/H100-class builds for HNI clients.
1.2 ComfyUI Visual Workflows	Partial	Dream Weaver, Qwen poster, and Wan 2.2 workflow assets all exist locally as real code and workflow JSONs. The remaining gap is production-grade orchestration, async automation, and canonical packaging.
1.3 System Prompts & UI Logic	Partial	Prompt assets and UI direction exist, but there is no single canonical prompt inventory mapping persona -> function -> file -> model -> API surface.
2.1 Swift/iPad App	Partial	The iOS app is materially implemented and was proven once in simulated form. The blocker is stable endpoint contract and environment passthrough, not absence of implementation.
2.2 FastAPI Neural Core	Done	FastAPI backend, PostgreSQL, auth, Sentinel stack, vault, scenes, videos, and live infra are in place. This is the real operating backend, not a placeholder.
2.3 CRM/WebOS React Wiring	Partial	WebOS shell is strong, but the canonical CRM backend contract is incomplete. Leads/chat/kanban wiring is still not fully landed in mainline.
3.1 Claw Bot Ecosystem	Changed	The original OpenClaw framing is obsolete. The intended truth is NemoClaw as the operating agent inside on-prem or client-cloud deployments, with stronger local-model autonomy planned later.
3.2 MCP Server/Tools	V2	MCP work is deliberate in Sourik's tree, but it is not part of the current mainline operating center yet.
3.3 Marketing Automation	Partial	Meta/Catalyst foundations exist and visual generation is wired conceptually, but Google Ads, autonomous posting, and a unified production-grade campaign loop remain open.
4.1 Future Life and Time & Light Engine	Changed	This story has effectively split: Future Life is now v2, while Time & Light remains a v1 item with significant implementation already present in iOS.
4.2 Engagement Intelligence and Social Proof layer	Partial	Sentinel intelligence exists, and there is a real browser-webcam perception path using Google MediaPipe on the frontend. The sales-facing social proof, room-peak, and wealth/legacy payoff layers are not fully delivered yet.

Summary Counts

Status	Count
Done	1
Partial	6
Changed	3
V2	1
Missing	0

Interpretation:

• Sprint 1 was not a failure
• the repo contains more real implementation than the old fact table gave credit for
• the biggest drift is not infra anymore
• the biggest drift is CRM completion, stable app/backend contracts, prompt inventory, and productized execution paths

---

User Story Fact Table

User Story	Original Intent	Current Status	Evidence / Current Truth	What Remains
1.1 Local/Cloud Hardware Config	Define Black Box + provision 8xA100 + split nodes + tunnels	Changed	Current infra is a proving ground: Linux control surface, AWS GPU workers, S3 strategy, stable t4g.micro ingress. For clients, the target recommendation is minimum 1x RTX PRO 6000 Blackwell 96GB, recommended 2x, and horizontal scaling if workload grows. HNI builders can justify DGX/H100-class systems.	Formalize the customer hardware matrix, scaling tiers, and on-prem packaging playbook.
1.2 ComfyUI Visual Workflows	Dream Weaver, poster gen, Wan 2.2, async queue API	Partial	The repo contains real workflow assets and code: comfy_engine/workflows/dreamweaver_phase1_depth.json, dreamweaver_phase2_multicontrol.json, dreamweaver_phase3_batch.json, dreamweaver_a100_human_preservation.json, catalyst_poster_qwen.json, cinematic_wan22_14b.json, plus dw_gateway_v2.py, queue_manager.py, and batch/test scripts.	Standardize canonical workflow packaging, unify gateway/runtime assumptions, and finish end-to-end async automation across all workflows.
1.3 System Prompts & UI Logic	Oracle persona prompts, Catalyst prompts, lock frontend/API design	Partial	Oracle architecture is deeply specified, and prompt assets already exist in backend/nemoclaw_prompts/*.md plus Dream Weaver prompt files. UI language exists.	Build a first-principles prompt inventory: which personas/functions exist, which prompt files are canonical, where Oracle prompts live, where Catalyst prompts live, and what API contracts they expect.
2.1 Swift/iPad App	Native shell + camera + sun path	Partial	The app is materially implemented: ComfyClient.swift, InventoryView.swift, ARSunOverlayView.swift, SunMath.swift, SimulatorSunOverlayView.swift, and slider/camera flow are present in the canonical iOS tree. It has been demonstrated once in simulated form from Sayan's MacBook.	Stabilize environment passthrough and endpoint mapping so the existing app can reliably talk to the current backend/Comfy gateways after code merge.
2.2 FastAPI Neural Core	FastAPI + PostgreSQL + endpoints + websockets	Done	backend/main.py is a real unified backend with DB pool lifecycle, auth, Catalyst, Sentinel, CCTV, scenes, videos, vault, static assets, and websocket support. This is already a live operating backend rather than a stub.	Expand feature breadth, not existence: CRM routes, Oracle mounting/contract cleanup, and stricter API/schema discipline.
2.3 CRM/WebOS React Wiring	Connect WebOS to backend, Kanban, dashboard sentiment	Partial	The WebOS/UI layer is real, but the backend contract is incomplete. backend/api/routes_crm.py is zero bytes, backend/api/routes_oracle.py is zero bytes, and the frontend still uses app/src/components/oracle/mockLeads.ts. PipelineView.tsx and CRM types exist, but they are not backed by canonical live endpoints yet.	Finish the real lead/chat/kanban/oracle endpoints, replace mock lead data, wire CRM websocket updates, define DB structure, and generate synthetic client data for verification.
3.1 Claw Bot Ecosystem	Deploy OpenClaw as primary communication agent	Changed	The product direction is now NemoClaw as the operating agent for client on-prem or client-cloud deployments. Current reality still uses the Python backend as the main runtime center, with future agent hardening planned.	Define the v1 NemoClaw boundary cleanly: what it owns now, how it integrates with CRM and Catalyst, and what shifts to local 30B/70B models in v2.
3.2 MCP Server/Tools	Local files, DB, internet via MCP	V2	MCP work exists deliberately in Sourik's code and should be treated as an explicit future subsystem, not accidental residue.	Revisit only after Sayan approval and after the core CRM/product surfaces stabilize enough to absorb it cleanly.
3.3 Marketing Automation	Meta/Google, bids, content generation, posting	Partial	Mainline has a substantial Catalyst UI in app/src/components/modules/Catalyst.tsx and live Meta-oriented backend routes in backend/api/routes_catalyst.py for campaign creation, creative sync, insights, lookalike audiences, and auth. Qwen/Wan workflow references are already reflected in the UI.	Missing pieces are Google Ads parity, autonomous posting, unified audience/budget/bid loop, production-grade marketing DB/state, and a non-fragmented front-to-back execution path.
4.1 Future Life and Time & Light Engine	Future Life videos + iPad time/light engine	Changed	The story is now two scopes. Future Life is pushed to v2. Time & Light is materially implemented in iOS via AR sun overlay, sun math, SceneKit dollhouse, sliders, and simulator fallback.	For v1, finish endpoint stability, validation on real devices, and tighten the product surface around Time & Light. For v2, Future Life needs a defined cinematic workflow and asset/runtime contract.
4.2 Engagement Intelligence and Social Proof layer	Social proof, emotional anchoring, wealth projection	Partial	Sentinel/QD logic exists, and the repo already contains a live-session browser path for webcam perception: PerceptionPlayer.tsx captures webcam, useMediapipeFaceLandmarker.ts runs Google MediaPipe in-browser, landmarkPacketEncoder.ts emits compact blendshape packets, and backend/routers/sentinel.py ingests them over WebSocket and returns QD updates. Your intended broader testing path can also use browser automation and public/free CCTV feeds.	Validate the live MacBook browser path end-to-end with Sayan, then decide how much additional CCTV/browser testing is needed before productizing the sales-facing social proof and room-peak layers.

---

Task Fact Table

Ref	Task	Status	Fact	Notes
W1-2	Define local Black Box edge server requirements	Partial	The architectural direction is now clear, but the customer-facing hardware matrix is still not formalized in one deployment standard.	Document minimum 1x RTX PRO 6000 Blackwell 96GB, recommended 2x, horizontal scaling, and DGX/H100 escalation path.
W2-3	Provision AWS 8xA100 instance	Changed	Current AWS GPU use is validation hardware, not the final customer recommendation.	The live L4/G6 path served testing; product packaging should now reference Blackwell-class on-prem targets.
W2-4	Virtualize AWS into Node 1 and Node 2	Changed	Not how the system evolved.	Replaced by Linux control plane + ephemeral AWS workers.
W2-5	Secure SSH tunnel access	Changed	Stable ingress, SSM, LAN access, and route sync superseded this.	Current system is better than the original tunnel-only idea.
W1-7	Dream Weaver interior restyling workflow	Partial	Real workflow JSONs, gateway code, prompt expansion, mask preprocessing, A100 executor, and batch processor exist locally.	Convert the local workflow stack into a canonical production package with stable endpoints and validation.
W1-8	Marketing poster workflow using Qwen-Image 2512	Partial	comfy_engine/workflows/catalyst_poster_qwen.json exists and the Catalyst surface references Qwen poster generation directly.	Make the poster flow an operator-safe product path instead of a local workflow asset plus operational runs.
W2-9	Wan 2.2 video generation workflow	Partial	comfy_engine/workflows/cinematic_wan22_14b.json exists and the Catalyst UI explicitly models Wan 2.2 generation states.	Productionize and validate the actual operator/runtime path; keep broader Future Life cinematic orchestration in v2.
W2-10	Expose all ComfyUI workflows via Async Queue API	Partial	dw_gateway_v2.py, dw_gateway_v2_min.py, queue_manager.py, and iOS ComfyClient.swift show a real queue/poll/result model exists.	Unify this into one canonical async API across Dream Weaver, Qwen poster, and Wan video workflows.
W1-12	Draft Oracle persona prompts	Partial	Prompt assets exist across current and parallel work.	Final product-grade persona contract still needs consolidation.
W1-13	Create Catalyst marketing prompts	Partial	Partial logic exists in Catalyst and service layers.	Build a canonical prompt map and separate strategy prompts from execution prompts.
W1-14	Lock frontend UI design and API schemas	Partial	Premium UI direction exists strongly.	API schemas are still evolving, especially for Oracle and CRM.
W1-16	Build native SwiftUI app shell	Done	Mainline iOS shell and modules exist.	Feature stabilization is separate.
W1-17	Camera capture feature to ComfyUI	Partial	Mainline iOS includes CameraPicker and a real ComfyClient talking to a Dream Weaver gateway.	Stabilize live endpoints and prove the flow again after code consolidation.
W1-18	Sun Path overlay in iPad app	Partial	ARKit, CoreLocation, CoreMotion, SceneKit, SunMath, and simulator fallback are implemented in the canonical iOS tree.	Real-device acceptance, UX tightening, and full passthrough validation remain.
W1-20	Marketing page frontend for Sourik	Partial	Mainline has a substantial Catalyst module already, even though Sourik also built a separate marketing page.	Decide whether to port selective Sourik marketing widgets or keep mainline Catalyst as the only truth.
W1-21	Python FastAPI server with PostgreSQL	Done	Implemented and live.	Closed for Sprint 1 baseline.
W1-22	/api/leads, /api/chat-logs for Oracle	Missing	Mainline still lacks real mounted implementations here, and routes_crm.py / routes_oracle.py are zero-byte placeholders.	Strong candidate to import selectively from Sourik and adapt to the mainline DB contract.
W1-23	/api/biometrics, /api/sentiment endpoints for Sentinel	Changed	Current mainline uses Sentinel websocket/session architecture instead of this exact REST shape, but there is a real working browser-webcam perception path using MediaPipe and WebSocket packet streaming.	Functional equivalent exists; the next step is live validation from Sayan's MacBook rather than re-arguing endpoint names.
W1-24	WebSockets to stream real-time updates to WebOS	Partial	Sentinel and notification live flows exist, including QD update broadcasts back into the perception player.	Broader CRM websocket sync is not fully closed.
W2-26	Connect React frontend components to FastAPI	Partial	Mainline has live backend wiring in some modules, but the CRM surface still depends on mocks and incomplete contracts.	Replace mock data, land CRM/oracle routes, and verify contract parity end-to-end.
W2-27	Simplified Kanban CRM pipeline	Missing	The polished implementation exists in Sourik, not in current mainline.	Important gap and likely one of the first selective imports.
W2-28	Dashboard visualizes AI sentiment output	Partial	Sentinel/dashboard UI work exists.	Needs a stricter acceptance pass tied to real CRM data and post-tour actions.
W1-30	Deploy OpenClaw as primary communication agent	Changed	The target concept has shifted to NemoClaw as the future operating agent, not OpenClaw as originally phrased.	Define the actual v1 NemoClaw contract and keep the model-local migration in v2.
W1-31	Connect bot to WhatsApp/Email APIs	V2	Not current mainline truth.	Can return when communication agent architecture is stabilized.
W1-32	Configure DM pairing and security allowlists	V2	More agent-stack specific than current core product need.	Defer.
W1-33	Route parsed transcripts/call durations into CRM DB	Partial	Architectural direction exists.	Concrete integrated mainline path is still incomplete.
W1-35	Set up MCP server	V2	Not part of current mainline critical path.	Defer.
W1-36	Configure HEARTBEAT or Cron background tasks	Partial	Infra timers/services now exist for ops sync and auto-heal.	Agent heartbeat specifically is not mainline yet.
W1-37	Configure Brave Search API for autonomous research	V2	Exists only in parallel/agent-oriented direction.	Defer.
W2-39	Integrate Meta Business API and Google Ads API as skills	Partial	Meta exists in routes_catalyst.py; Google Ads is not landed in mainline.	Keep Google as open and treat the current state as Meta-first.
W2-40	Read insights, manage budgets, execute bidding	Partial	Mainline covers campaign creation, creative sync, realtime insights, and lookalikes.	Budget governance, automated bidding, and unified marketing state are still incomplete.
W2-41	Bridge agent to Sagnik ComfyUI API for posters/videos	Partial	The gateway/queue model exists, but the agent-operable bridge is not yet a polished first-class mainline subsystem.	Candidate for consolidation once NemoClaw/Catalyst boundaries are clarified.
W2-42	Autonomous content posting via headless browser or APIs	V2	Not done in mainline.	Defer.
44	Future Life Simulation workflow	V2	The story is intentionally pushed to v2 now. Wan workflow assets exist, but not the full Future Life product layer.	Keep out of Sprint 1 closure.
45	Time & Light Engine in Swift iPad app	Partial	The underlying implementation is materially there: AR sun overlay, sun math, SceneKit lighting, simulator path.	Finish product hardening and real-device verification.
46	Touch sliders for month/time/obstruction	Partial	Slider-driven control exists in the iOS inventory/time-light surface.	Tighten UX and confirm the final obstruction/massing behavior you want.
48	Legacy Mode wealth projection UI	V2	Not in current mainline.	Good v2 candidate.
49	Social Proof live map	V2	Not closed in mainline.	Good v2 candidate.
50	Sentinel backend for eye-tracking and micro-expression from iPad camera	Partial	This capability exists more clearly in Sourik's parallel Sentinel work than in current mainline. Mainline has the Sentinel backbone, but not the final iPad-first ingestion path you want to test.	Decide the testing source path: iPad camera, browser instrumentation, or public/free CCTV footage for development.
51	Dashboard visualize emotional spike by room	Partial	The data concept exists, but the sales-facing room-peak UI payoff is not clearly delivered in mainline.	Build the actual post-tour anchor surface, not just the data plumbing.

---

What Is Actually Closed in Sprint 1 Terms

These items are reasonably closed if judged by evolved product reality rather than literal wording:

• native app shell exists
• Dream Weaver local workflow stack exists
• Wan 2.2 and Qwen workflow assets exist locally
• FastAPI + PostgreSQL neural core exists
• Sentinel backbone exists
• browser-webcam Sentinel perception path exists
• vault/notifications exist
• scenes/video/session pipeline exists
• live AWS/Linux/ingress infrastructure exists

---

What Is Escaping Attention

These are the most likely to be forgotten because adjacent systems exist:

1. leads and chat-logs APIs

   • easy to assume done because backend exists
   • they are not landed in current mainline routes yet

2. Kanban CRM logic

   • same issue

3. camera-to-Comfy flow in the iPad app

   • implementation exists, but endpoint stability and integration need proving after merge

4. marketing execution path

   • there is a substantial Catalyst module, but the backend and execution loop are not fully unified

5. room-level emotional spike visualization

   • scene-aware data exists
   • explicit sales UI payoff may still be missing

6. prompt inventory

   • prompt files exist in multiple places
   • there is no single canonical map of persona/function -> prompt -> model -> API surface

7. live MacBook webcam validation

   • the path exists in code
   • it still needs a real end-to-end run from Sayan's machine against the current deployed environment

---

Recommended Interpretation for Planning

Keep in active near-term scope

• leads API
• chat logs API
• kanban pipeline
• frontend/backend CRM wiring
• CRM database structure
• synthetic 100-client dataset for system verification
• endpoint stabilization for the iPad app
• room-level emotional spike sales surface
• marketing execution path consolidation
• prompt inventory and persona contract mapping

Treat as explicitly v2

• MCP server and Brave search
• autonomous content posting
• Future Life cinematic product layer
• Legacy Mode wealth projection
• Social Proof live clustering layer

Treat as changed, not failed

• 8xA100 provisioning and node virtualization
• SSH-tunnel-based access model
• OpenClaw-primary communication architecture
• combined Future Life + Time & Light story packaging

---

CRM Remaining Pieces

These are the concrete mainline CRM gaps visible in the repo today:

1. Backend lead and chat routes are not landed.

   • backend/api/routes_crm.py is zero bytes
   • backend/api/routes_oracle.py is zero bytes

2. Frontend CRM still depends on mock data.

   • app/src/components/oracle/mockLeads.ts is still the effective lead source for parts of the UI

3. Kanban is not implemented in mainline.

   • The cleanest working version currently lives in Sourik's tree

4. Chat transcript and interaction ingestion are not unified into one canonical CRM schema yet.

5. Oracle action surfaces and CRM writebacks are not yet a stable contract.

6. Websocket semantics are not yet closed for CRM pipeline movement, lead updates, and interaction feeds.

7. Synthetic verification data does not exist yet.

   • You should generate at least 100 realistic synthetic client/lead records and run the full pipeline against them before treating CRM as stable.

CRM Database Brainstorming Starter

Minimum canonical entities for the next pass:

• projects
• properties
• units
• leads
• lead_contact_methods
• lead_interactions
• lead_messages
• lead_stage_events
• site_visits
• sentinel_sessions
• sentiment_events
• room_interest_events
• tasks
• owners/users
• campaign_attributions
• documents
• oracle_actions

High-value relationships:

• one project has many properties
• one property has many units
• one lead can have many interactions, messages, site_visits, and stage_events
• one sentinel_session can produce many sentiment_events and room_interest_events
• one oracle_action should map back to one canonical CRM write event

---

Prompt Inventory Gap

Prompt work exists, but the system does not yet have one canonical inventory. At minimum the next prompt pass should answer:

1. Which personas exist now:

   • Oracle
   • NemoClaw
   • Catalyst
   • Sentinel/QD evaluator
   • CCTV profiler
   • lead tagger

2. Which files are canonical:

   • backend/nemoclaw_prompts/qd_calculator.md
   • backend/nemoclaw_prompts/lead_tagger.md
   • backend/nemoclaw_prompts/cctv_profiler.md
   • Dream Weaver prompt files under comfy_engine/prompts/
   • any Oracle/Catalyst prompt files that still only exist in docs or parallel code

3. Which model each prompt targets

4. Which runtime/API surface calls each prompt

5. Which prompts are system prompts, tool prompts, UI copy, or generation prompts

---

Updated Active Task List

Must finish for Sprint 1 truth to feel real

• land canonical leads, chat_logs, and kanban backend routes
• replace frontend CRM mock data with live API-backed state
• define and implement the canonical CRM database schema
• generate 100 synthetic client/lead records and verify the end-to-end CRM flow
• validate the Sentinel live-session webcam path from Sayan's MacBook
• stabilize iOS endpoint passthrough and prove camera-to-Dream-Weaver again
• finish the room-level emotional spike sales surface
• create the prompt inventory and persona/function map

Important, but after the CRM spine is stable

• unify Dream Weaver/Qwen/Wan async automation into one canonical queue API
• harden Catalyst execution flow from UI -> backend -> generation -> asset sync
• define the v1 NemoClaw contract inside the product
• decide which Sourik CRM/marketing modules are selectively imported

Explicitly v2

• Future Life cinematic product layer
• MCP server integration
• Brave Search autonomous research
• autonomous content posting
• Legacy Mode wealth projection
• Social Proof live clustering layer

---

Bottom Line

Sprint 1 is best described as:

• infrastructure and core runtime: substantially achieved
• Dream Weaver / Qwen / Wan local workflow assets: materially present
• Sentinel backbone: substantially achieved
• web and iOS implementation surface: materially present
• full CRM operationalization: still incomplete
• agent, marketing, and prompt unification: incomplete and needs explicit ownership

The biggest remaining work is not more infra.

It is:

• completing the CRM layer
• deciding the canonical CRM schema
• stabilizing app/backend passthrough
• unifying frontend/backend contracts
• building a prompt inventory from first principles
• deciding which Sourik subsystems to port into mainline
• explicitly labeling v2 items so they stop pretending to be Sprint 1 leftovers