gowthamganesanamibikapthy/supreme-garbanzo

Purpose and Entry Points

This repository appears to implement an “Aura” desktop-oriented application with local backend services, task/auth/data handling, a GUI client, and a separate marketplace-facing JavaScript surface. Primary launch and audit entry points are run_aura.bat and run_sit_audit.py.

Desktop Application Shell

The desktop frontend is the likely user-facing control plane. desktop_frontend/main_client.py likely composes application startup and backend interaction; desktop_frontend/dashboard_hud.py provides the primary dashboard view; desktop_frontend/system_tray.py manages background/tray lifecycle. The frontend boundary is local UI code versus service calls into core_backend/.

Visual Rendering Layer

desktop_frontend/paint_engine.py is a distinct rendering/painting subsystem, separated from dashboard orchestration. This suggests display composition or custom visual effects should remain isolated from business logic and service communication.

Backend Service Boundary

core_backend/app_service.py is the probable application-level coordinator for desktop requests. It should own cross-service workflows rather than placing them in UI code. core_backend/auth_service.py encapsulates identity/session concerns, while core_backend/task_service.py owns task lifecycle and task-oriented operations.

Persistence

core_backend/database.py centralizes database access and is the persistence boundary for backend services. aura_sit_test_sandbox.db is a repository-local database artifact, likely used for sandbox or system-integration testing data. Callers should reach persistence through backend services rather than directly coupling UI modules to the database.

Primary Flow

The expected control flow is:

1. run_aura.bat starts the Aura application.

2. desktop_frontend/main_client.py initializes desktop UI components.

3. Dashboard/tray interactions route through core_backend/app_service.py.

4. The app service delegates authentication and task work to core_backend/auth_service.py and core_backend/task_service.py.

5. Backend services use core_backend/database.py to read/write persisted state.

External-Facing Marketplace Surface

web_storefront/marketplace.js is a separate JavaScript marketplace/storefront integration boundary. It should be treated as independent from the desktop runtime unless explicitly connected through a shared API or data contract. No server framework, cloud provider, or external SaaS dependency is identifiable from the supplied tree.

Verification Boundary

run_sit_audit.py is a system-integration-test or audit entry point. It likely validates the assembled backend/database behavior using the sandbox data path rather than serving as a production runtime component.