Critical Finding: Bybit demo and live trading use IDENTICAL API endpoints and IDENTICAL trading rules. The ONLY difference is the domain:
https://api.bybit.comhttps://api-demo.bybit.comThis is not an accident - it's intentional design for seamless transition.
After deep architectural analysis, we've discovered the true competitive advantage of Mercury's instance system:
Key Insight: Shadow portfolio's value isn't simulation—it's complete data capture for strategy optimization that demo trading cannot provide.
This is a monorepo-wide architectural problem, not specific to Mercury. Across multiple domains, we've evolved complex optional nested structures that force developers to bypass TypeScript's type safety. The Mercury tournament configurations are just one example of this systemic issue.
After extensive discussion and implementation, we've achieved a clean, minimal architecture that separates concerns properly and avoids over-engineering.
Or: How I Created a Museum for a Single File
Today I discovered that I had created an entire directory structure (platform/infra/tilt/) for a single Tiltfile, complete with FDD.md documentation and .gitkeep files. What started as a simple development tool somehow evolved into a full museum exhibition for one configuration file.
Large codebases inevitably accumulate technical debt. Components that started simple grow complex, abstractions leak, and what once was clean becomes messy. The traditional approach is often "rewrite it all" - but this is risky, expensive, and frequently fails.
Our Mercury trading system has grown organically over time, leading to intertwined services, duplicated code, and complex state management. This document outlines a strategic approach to refactoring key components to improve maintainability, testability, and performance.