sagnik/Project_Velocity
2
1
Fork 2
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
e241ff800ce26560d0befd338b5344bee9f37a30
Project_Velocity/.Agent Context/Bibels/Sourik Code Intake and Compatibility Report.md
sagnik e241ff800c Missed files (#19) 
Co-authored-by: Sagnik <sagnik7896@gmail.com>
Reviewed-on: #19
2026-04-12 19:26:20 +05:30

16 KiB
Raw Blame History

Sourik Code Intake and Compatibility Report

Prepared: 2026-04-12
Scope: Project_Velocity/Sourik only, evaluated against the current non-Sourik Project Velocity codebase, built features, and live operating model
Purpose: Decide what from Sourik is worth merging, what is redundant, what is bloat, and where the conflicts will be

Scoring Model

Score Meaning
1 Banish. Do not merge into main.
2 Archive only. Historical value, no production merge value.
3 Very weak merge candidate. Requires heavy rewrite or extraction.
4 Risky or partial. Import only if a specific owner adopts it.
5 Mixed value. Keep for reference, not direct merge.
6 Useful implementation ideas, but not merge-ready.
7 Good candidate for selective integration.
8 Strong subsystem candidate.
9 High-value, near-merge-ready if wiring assumptions are corrected.
10 Critical import candidate. No direct equivalent or materially better than current mainline.

Executive Summary

The Sourik tree is not one clean feature branch. It is a mixed bundle of:

  • real backend/API work
  • a separate Go agent runtime
  • frontend additions for marketing and analytics
  • a partial iOS spike
  • strong test evidence in some areas
  • large amounts of residue:
    • local env files
    • coverage outputs
    • compiled binaries
    • sqlite prototypes
    • pycache
    • logs
    • duplicate docs

The correct merge posture is:

  • do not merge the tree wholesale
  • extract selected subsystems
  • banish operational residue
  • treat the Go runtime as an alternate architecture, not as an automatic addition

Highest-value areas in Sourik:

  • Python API modules around leads, persona, analytics, websocket, kanban, and Sentinel consent/GDPR patterns
  • test coverage and test cases
  • some Catalyst service abstractions
  • some iOS camera/time-light experiment code

Highest-risk areas:

  • duplicate backend entrypoint and alternate runtime model
  • alternate Nemoclaw + MCP + Go server stack
  • hardcoded stale infrastructure assumptions
  • local SQLite-first assumptions that conflict with current PostgreSQL truth
  • Comfy service hardcoded to stale IPs

What Sourik Actually Contains

Implementation Shape

Sourik/velocity contains:

  • Python FastAPI app:
    • main.py
    • api/*.py
    • services/*.py
    • db/connection.py
  • Go runtime:
    • main.go
    • internal/nemoclaw/*
    • internal/oracle/*
    • internal/mcp/*
    • internal/sentinel/*
    • integrations/*.go
  • frontend additions:
    • frontend/src/app/marketing/page.tsx
    • frontend/src/lib/api.ts
    • dashboard/marketing components
  • iOS spike:
    • VelocityApp/*
  • docs and summaries:
    • README.md
    • SPRINT_SUMMARY_FOR_SAGNIK.md
    • SPEC.md
    • docs/*
  • residue:
    • .env
    • prototype.db
    • coverage outputs
    • binaries
    • logs
    • pycache

Sourik Architecture According to Sourik

The root README.md describes an “Agentic Operations Layer” with:

  • WhatsApp webhook
  • Go OpenClaw/NemoClaw layer
  • MCP server
  • ComfyUI / CRM / visual hub integrations

That is a materially different center-of-gravity from the current mainline, where:

  • FastAPI backend is the operational center
  • Linux control surface and ingress are already live
  • Comfy routing and AWS orchestration are already established

This matters. Sourik is not just “new features.” It contains an alternate operating model.

Compatibility with Current Mainline

Current Mainline Truth

The non-Sourik codebase already has:

  • a live FastAPI backend in backend/main.py
  • active routers for Sentinel, CCTV, videos, scenes, vault
  • a real Nemoclaw client abstraction in Python
  • an Oracle implementation path in backend/oracle/*
  • a premium React app in app/src/*
  • a live ingress plane in infrastructure/desineuron_ingress/*
  • a live Linux AWS control surface in infrastructure/ops_control_plane/*
  • a real iOS app tree in iOS/velocity/velocity/*

So the comparison baseline is not theoretical. It is a partially working system with live infrastructure.

Main Compatibility Findings

Sourik Area Mainline Equivalent Compatibility
velocity/api/leads.py no equally complete current leads CRUD module in mainline backend Good candidate
velocity/api/sentinel.py overlaps with backend/routers/sentinel.py but focuses on consent/GDPR/biometric storage Selective candidate
velocity/api/catalyst.py overlaps with backend/api/routes_catalyst.py Merge conflict likely
velocity/api/ws.py overlaps conceptually with current websocket/event logic Selective candidate
velocity/api/analytics.py weak/no exact current equivalent Good candidate
velocity/api/persona.py likely additive Good candidate
velocity/api/kanban.py no clear current equivalent in mainline Good candidate
velocity/services/comfyui_service.py conflicts with current ingress + Comfy routing + live GPU architecture Poor direct candidate
velocity/main.py conflicts with backend/main.py Do not merge directly
velocity/main.go + internal/* alternate runtime architecture Do not merge directly
VelocityApp/* overlaps with current iOS app Selective candidate only

Scored Intake Table

Sourik Path / Scope Score Merge Recommendation Reason
Sourik/velocity/api/leads.py 8 Selective merge candidate Real CRUD, qualification, demographics endpoints. Mainline has product need here and no equally complete direct equivalent. Needs DB contract alignment.
Sourik/velocity/api/kanban.py 8 Selective merge candidate Kanban behavior is useful and currently underrepresented in mainline implementation.
Sourik/velocity/api/analytics.py 8 Selective merge candidate Adds reporting/analytics surface that appears useful for Marketing and Oracle support.
Sourik/velocity/api/persona.py 7 Selective merge candidate Likely additive business logic and API value.
Sourik/velocity/api/chat_logs.py 7 Selective merge candidate Useful if mapped into Oracle / CRM flows; needs contract alignment with current auth and DB.
Sourik/velocity/api/ws.py 7 Selective merge candidate Useful patterns and tests likely exist, but websocket ownership already exists in current backend.
Sourik/velocity/api/sentinel.py 7 Extract specific features only Valuable for biometric consent, GDPR, and export patterns. But it is SQLite-centered and overlaps with current Sentinel runtime.
Sourik/velocity/tests/api/* 9 Strong import candidate Test suites are high-value, especially for a fragile future merge. Adapt tests even if code is not merged verbatim.
Sourik/velocity/tests/internal/nemoclaw/* 7 Import selectively Good coverage and behavioral protection if Go/Nemo concepts are retained anywhere.
Sourik/velocity/services/ad_network_skills.py 7 Selective merge candidate Likely useful for Catalyst ad automation and may complement current Meta-focused path.
Sourik/velocity/services/social_posting.py 7 Selective merge candidate Useful capability if social publishing remains in scope.
Sourik/velocity/services/catalyst_content.py 7 Selective merge candidate Useful Catalyst logic, but must be aligned with current Comfy and asset pipeline.
Sourik/velocity/services/comfyui_service.py 4 Reference only, do not merge directly Hardcodes stale host/IP and assumes a different Comfy deployment pattern from the current live ingress-managed GPU model.
Sourik/velocity/frontend/src/app/marketing/page.tsx 7 Selective UI import candidate Useful product surface not currently dominant in mainline app. Needs design-system integration and router alignment.
Sourik/velocity/frontend/src/components/marketing/* 7 Selective UI import candidate Likely useful for Catalyst/marketing module.
Sourik/velocity/frontend/src/components/dashboard/* 6 Compare component by component Useful ideas, but mainline already has strong dashboard surfaces. Merge only where functionality is genuinely additive.
Sourik/velocity/frontend/src/lib/api.ts 5 Reference only; do not merge as-is Useful contract hints, but current mainline already has API client layers. This should inform consolidation, not become a second truth.
Sourik/VelocityApp/Features/CameraView.swift 7 Selective import candidate Good feature spike: camera capture + send-to-Comfy flow + time/light controls. Worth comparing to current iOS inventory/AR path.
Sourik/VelocityApp/Features/TimeControlSlider.swift 7 Selective import candidate Likely useful to augment Sun/lighting feature work.
Sourik/VelocityApp/Features/TimeLightEngine.swift 7 Selective import candidate Strong fit with current Velocity iOS sun-path direction.
Sourik/VelocityApp/Core/Router.swift 5 Review only Could help, but current iOS structure already has navigation patterns.
Sourik/velocity/main.py 3 Do not merge directly It creates a second FastAPI root with a different DB model, routing shape, and operational assumptions. Extract modules only.
Sourik/velocity/main.go 3 Do not merge directly Alternate runtime center. Valuable as concept or archived subsystem, but not compatible with current mainline architecture without a deliberate platform decision.
Sourik/velocity/internal/nemoclaw/* 4 Review as architecture experiments only Significant conceptual overlap with current Python Nemoclaw path. A direct merge would create two control centers.
Sourik/velocity/internal/mcp/* 5 Review selectively Interesting if you want future MCP work, but not aligned with current operational center yet.
Sourik/velocity/internal/oracle/* 4 Reference only for now Current mainline already has an Oracle implementation direction in Python. Direct merge would fork the architecture.
Sourik/velocity/internal/sentinel/sentinel_api.go 4 Reference only Sentinel is already active in Python backend.
Sourik/velocity/integrations/*.go 5 Review case-by-case Potentially useful adapters, but only if the Go runtime is retained.
Sourik/velocity/docs/COMFYUI_HANDOFF.md 6 Keep as reference Useful context for intended wire-up, but assumes VPN/headscale-era setup that no longer matches current ingress truth.
Sourik/SPRINT_SUMMARY_FOR_SAGNIK.md 7 Keep as reference artifact Useful for intent, coverage claims, and blocked wire list. Not production code.
Sourik/SPEC.md 5 Archive as historical spec Useful context, but contains stale node IPs, port assumptions, and stage-only instructions that no longer match live infrastructure.
Sourik/PRD.md 2 Archive only Too thin to be operationally meaningful.
Sourik/velocity/README.md 6 Keep as architecture snapshot Good summary of Sourik’s intended architecture.
Sourik/velocity/.env 1 Banish Local secrets/config residue. Must not merge.
Sourik/desineuron-l4-node.pem 1 Banish Private key material in source tree. Never merge.
Sourik/velocity/db/prototype.db 1 Banish Local prototype database, not source.
Sourik/velocity/prototype.db 1 Banish Same issue.
Sourik/velocity/.coverage 1 Banish Coverage artifact.
Sourik/velocity/coverage* 1 Banish Coverage outputs, not source.
Sourik/velocity/.agent/*coverage*, *test_output* 1 Banish CI/test residue.
Sourik/velocity/antigravity_server 1 Banish Compiled binary, not source.
Sourik/velocity/antigravity_test_build.exe 1 Banish Compiled Windows artifact, not source.
Sourik/velocity/__pycache__, .pytest_cache 1 Banish Generated caches.
Sourik/velocity/logs/VALIDATION_FINAL.log 2 Archive only Useful as evidence, not source.
Sourik/velocity/test_out.txt, guide_extracted.txt, guide_utf8.txt 2 Archive only Scratch outputs.
Sourik/velocity/stubs/* 3 Archive or keep in a clearly marked scratch area Potentially useful examples, but not merge targets.
Sourik/velocity/archive/* 2 Archive only Historical material.

Bloat and Residue in Sourik

These are immediate no-merge items:

  • private keys
  • .env
  • .coverage
  • coverage*
  • .pytest_cache
  • __pycache__
  • compiled binaries
  • local sqlite databases
  • raw logs
  • scratch text files

These do not need debate. They are not source code.

Redundant vs Additive Features

Redundant or Architecturally Conflicting

  1. FastAPI root app

    • Sourik/velocity/main.py
    • conflicts with current backend/main.py
    • creates a second root service with different routing and DB assumptions

  2. Go agent runtime

    • Sourik/velocity/main.go
    • internal/nemoclaw/*
    • internal/mcp/*
    • this is an alternate operational center, not a drop-in feature set

  3. ComfyUI service

    • assumes stale IP-based deployment
    • current system already has:
      • stable ingress
      • GPU worker tagging
      • auto-healing route sync
      • Linux AWS control plane

Additive and Potentially Valuable

  1. Lead / Kanban / Persona / Analytics Python APIs

    • mainline can benefit directly from these

  2. Sentinel consent and GDPR patterns

    • these are useful as selective feature imports into current Sentinel

  3. Marketing frontend

    • a real additive surface for the Catalyst/marketing module

  4. iOS camera and time/light features

    • fit directly with current iPad vision and sun/AR direction

  5. Test suites

    • very high value regardless of whether code merges directly

Compatibility with Built Features

Works with Current Mainline Direction

  • property and lead workflows
  • marketing/campaign intelligence
  • camera-driven iOS interactions
  • GDPR/consent handling
  • Kanban CRM motions

Conflicts with Current Mainline Truth

  • SQLite/prototype-first database assumptions
  • hardcoded or stale infrastructure endpoints
  • alternate Go-first NemoClaw/MCP control center
  • separate backend root service
  • stale VPN/headscale-era deployment assumptions

Recommended Intake Strategy

Merge Now Candidates

  • velocity/api/leads.py
  • velocity/api/kanban.py
  • velocity/api/analytics.py
  • velocity/api/persona.py
  • tests supporting the above
  • selected marketing frontend components
  • selected iOS camera/time-light feature files

Extract, Rewrite, Then Merge

  • velocity/api/sentinel.py
  • velocity/api/chat_logs.py
  • velocity/services/*
  • frontend/src/lib/api.ts

Do Not Merge Directly

  • velocity/main.py
  • velocity/main.go
  • velocity/internal/nemoclaw/*
  • velocity/internal/oracle/*
  • velocity/internal/mcp/*
  • velocity/services/comfyui_service.py

Banish Immediately from Merge Candidate Set

  • .env
  • .pem
  • .db
  • coverage*
  • .coverage
  • .pytest_cache
  • __pycache__
  • binaries
  • logs
  • scratch outputs

Final Recommendation

Sourik’s code should be treated as:

  • 30% importable feature work
  • 30% useful reference and test material
  • 40% architectural conflict or residue

The best path is:

  1. strip all residue first
  2. import Python feature modules selectively
  3. import tests aggressively
  4. compare marketing frontend additions against current app
  5. compare iOS camera/time-light features against current iOS app
  6. keep the Go/Nemo/MCP stack out of the first merge unless you deliberately choose to adopt that architecture

That will give you the value in Sourik’s work without poisoning the current mainline with a second operating model.

Reference in New Issue View Git Blame Copy Permalink