Fincept Terminal — Mental Model Wiki

Pages

1. The Mental Model: A Layered Modular MonolithThe simplest useful picture of Fincept Terminal — six stacked layers (Presentation → Application → Data Plane → Adapters → Infrastructure → Platform), 13 bounded contexts that publish to each other only via DataHub topics or typed events, and one Qt6 binary per OS with embedded Python for analytics. Reading this page should let you guess which directory a new feature belongs in and why cross-context direct calls are forbidden.
2. How Data Moves: DataHub, Adapters, and the Python BridgeThe runtime flow that explains every screen update: DataHub is a one-fetch/many-subscribers pub/sub keyed by topic (`market:*`, `news:*`, `broker:<id>:*`…); CacheManager backs it with a SQLite TTL store on a separate physical DB; BrokerInterface and HTTP/WebSocket clients are leaf adapters that may not call services back; PythonRunner is the subprocess bridge that crosses the C++/Python process boundary for the ~1,423 analytics and data scripts under `fincept-qt/scripts/`. Trace a quote from broker WebSocket → adapter → DataHub topic → subscribed screen and you have the system.
3. Invariants, Failure Modes & Safe-Change RulesThe closing synthesis: the hard rules you must not break and the failure modes they prevent. Dependency direction is one-way down the stack; cross-context calls go through DataHub topics or typed events, never `#include`. `AuthManager::session()` is the canonical source for Fincept credentials — `SettingsRepository` is a fallback copy only. SecureStorage is SQLite + AES-256-GCM keyed off `machineUniqueId` and requires `Database` open first; platform keychains are intentionally unused. Schema migrations under `storage/sqlite/migrations/` are forward-only. Screens are lazy-instantiated via `DockScreenRouter` factories. Use this page as a checklist before merging: which layer am I in, what state do I own, and which invariant am I at risk of violating?