antonyrajancloud1/plutusai

Purpose and Entry Points

This is a Django-based trading automation/control system (“Plutus AI”) with browser dashboards, manual-order workflows, strategy modules, and integrations for Angel One and Exness brokers. Primary process entry points are manage.py, plutus/wsgi.py, and plutus/asgi.py; route composition starts in plutus/urls.py and app routes in plutusAI/urls.py.

Web Application Boundary

The Django application exposes HTML-oriented operational interfaces through plutusAI/views.py, backed by templates such as plutusAI/templates/dashboard.html and plutusAI/templates/manual.html. Client-side dashboard and trading-console behavior is implemented under static/js/ui/App.js and static/js/ui/utils/api.js. This UI boundary should invoke server endpoints rather than broker SDKs directly.

Domain Persistence and Administration

Persistent Django domain state is defined in plutusAI/models.py, with schema history under plutusAI/migrations/0001_initial.py. The repository includes a local SQLite database, db.sqlite3, and a SQL dump, madara_db.sql, indicating development or deploy-time relational-state handling. Django admin registration resides in plutusAI/admin.py.

Broker Abstraction and Authentication

Broker connectivity is organized behind a shared broker layer in plutusAI/server/broker/Broker.py. Concrete implementations target Angel One (plutusAI/server/broker/AngelOneBroker.py) and Exness (plutusAI/server/broker/exness/ExnessBroker.py), with Angel One authentication isolated in plutusAI/server/broker/AngelOne/AngelOneAuth.py. Application-level Angel One orchestration appears in plutusAI/server/AngelOneApp.py; credential/session handling should remain contained within these broker/authentication boundaries.

Market Data and Trading Execution Flow

The likely operational flow is: browser/API action or automated strategy → server orchestration → broker abstraction → external broker order/market-data APIs. Real-time Angel One connectivity is separated in plutusAI/server/websocket/WebsocketAngelOne.py. Manual execution is handled by plutusAI/server/manualOrder.py, while automated price-action strategies are grouped in plutusAI/server/priceAction/FlashTrade.py, plutusAI/server/priceAction/Scalper.py, and plutusAI/server/priceAction/hft.py.

Strategy and Signal Components

Trading logic is decomposed into price-action and support/resistance modules rather than being embedded in Django views. Key strategy-stage modules include plutusAI/server/priceAction/NSEPriceAction.py, plutusAI/server/priceAction/priceActionScalper.py, and plutusAI/server/supportResistance/AngelOneSR.py. These components consume market/broker data and should produce decisions or orders through the broker interface, preserving a boundary between signal generation and execution.

Runtime and Deployment

The system supports conventional Django HTTP serving plus asynchronous/background execution via plutus/celery.py; ASGI support is available through plutus/asgi.py, relevant to websocket-capable deployments. Container deployment is defined by Dockerfile, with operational scripts start_server.sh and stop_server.sh. Dependencies are declared in requirements.txt; external material services are the Angel One and Exness broker platforms.