339 lines
25 KiB
Markdown
339 lines
25 KiB
Markdown
# 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
|