Codebase Cleanup & Proposal for Decoupled UI Monitoring Interface

[JaronHA]

1. Codebase Cleanup: Inconsistent Legacy Filenames
   Description:
   Several files and directories in the project still retain outdated names (e.g., tradebot-pro, or other legacy prefixes/suffixes). These inconsistencies may lead to:

Confusion for new contributors navigating the codebase.

Maintenance overhead when aligning documentation, imports, or dependencies.

Version control ambiguities (e.g., if remnants of older iterations remain).

Suggested Action:

Conduct a systematic audit to identify and update all legacy filenames.

Ensure naming conventions align with the current project scope and architecture.

Update references in documentation, imports, and CI/CD pipelines.

2. Feature Proposal: Decoupled UI Monitoring Interface
   Motivation:
   A standalone UI monitoring interface would greatly enhance usability, especially in distributed environments where the trading core runs on a remote server. Key benefits include:

Real-time monitoring of strategy performance, positions, and PnL metrics.

Operational transparency without coupling to the core trading logic.

Accessibility for non-technical users to track system health.

Design Recommendations:

Loose Coupling:

Use APIs or a message bus for communication between the core and UI.

Ensure the UI can run independently (e.g., as a separate service).

Key Features:

Dashboard for real-time metrics (e.g., open orders, balance, latency).

Historical performance visualization (e.g., equity curves, trade history).

Alerts for critical events (e.g., margin warnings, connection failures).

Security:

Implement authentication/authorization.

Encrypt sensitive data in transit/at rest.

Why This Matters
Codebase Health: Removing legacy names reduces technical debt and improves maintainability.

User Experience: A decoupled UI empowers users to monitor strategies flexibly while keeping the core lightweight and focused.

Thank you for your work on this project! Let me know if further details would help.

Note: This proposal intentionally avoids prescribing implementation specifics to respect the maintainers' design priorities.

[river-walras]

1. Codebase Cleanup: Inconsistent Legacy Filenames
   Description:
   Several files and directories in the project still retain outdated names (e.g., tradebot-pro, or other legacy prefixes/suffixes). These inconsistencies may lead to:

Confusion for new contributors navigating the codebase.

Maintenance overhead when aligning documentation, imports, or dependencies.

Version control ambiguities (e.g., if remnants of older iterations remain).

Suggested Action:

Conduct a systematic audit to identify and update all legacy filenames.

Ensure naming conventions align with the current project scope and architecture.

Update references in documentation, imports, and CI/CD pipelines.

2. Feature Proposal: Decoupled UI Monitoring Interface
   Motivation:
   A standalone UI monitoring interface would greatly enhance usability, especially in distributed environments where the trading core runs on a remote server. Key benefits include:

Real-time monitoring of strategy performance, positions, and PnL metrics.

Operational transparency without coupling to the core trading logic.

Accessibility for non-technical users to track system health.

Design Recommendations:

Loose Coupling:

Use APIs or a message bus for communication between the core and UI.

Ensure the UI can run independently (e.g., as a separate service).

Key Features:

Dashboard for real-time metrics (e.g., open orders, balance, latency).

Historical performance visualization (e.g., equity curves, trade history).

Alerts for critical events (e.g., margin warnings, connection failures).

Security:

Implement authentication/authorization.

Encrypt sensitive data in transit/at rest.

Why This Matters Codebase Health: Removing legacy names reduces technical debt and improves maintainability.

User Experience: A decoupled UI empowers users to monitor strategies flexibly while keeping the core lightweight and focused.

Thank you for your work on this project! Let me know if further details would help.

Note: This proposal intentionally avoids prescribing implementation specifics to respect the maintainers' design priorities.

I really like your suggestions:

Currently, our entire system does not have margin warnings or monitoring for connection failures. I think this should be the highest priority.

Then I think we can add a Mock Trading module (not a testnet), in which EMS does not send orders to the exchange but generates a Mock Order based on the current price.

Finally, a Dashboard for performance visualization.

Are you interested in collaborating together?

[JaronHA]

Thank you for the invitation! Your prioritization of tasks is absolutely correct – those critical items should indeed take higher priority.

I appreciate your invitation to collaborate. However, as I'm currently focused on quant research work with significant ongoing commitments, I regrettably won't have capacity to participate in project development in the near term. My apologies. That said, I'll continue following the project's updates closely !