# Fincept Terminal — Mental Model Wiki

> A reader-side mental model of Fincept Terminal v4: a native C++20/Qt6 modular monolith with embedded Python analytics, an in-process DataHub pub/sub data plane, and 16+ broker adapters. The pages teach how to predict behavior, where state lives, and which rules must hold when you change code.

This is a Grok-Wiki source-grounded repository wiki. Use the complete Markdown link when an agent needs the full repo context.

## Context Links

- [Complete Markdown wiki](https://grok-wiki.com/public/wiki/fincept-corporation-finceptterminal-b8b64fbc871f/llms-full.txt)
- [Complete Markdown alias](https://grok-wiki.com/public/wiki/fincept-corporation-finceptterminal-b8b64fbc871f.md)
- [Human interactive wiki](https://grok-wiki.com/public/wiki/fincept-corporation-finceptterminal-b8b64fbc871f)
- [GitHub repository](https://github.com/Fincept-Corporation/FinceptTerminal)

## Repository

- Repository: Fincept-Corporation/FinceptTerminal

- Generated: 2026-05-23T06:41:59.277Z
- Updated: 2026-05-23T06:42:26.230Z
- Runtime: Claude Code
- Format: Mental Model
- Pages: 3

## Pages

- [The Mental Model: A Layered Modular Monolith](https://grok-wiki.com/public/wiki/fincept-corporation-finceptterminal-b8b64fbc871f/pages/01-the-mental-model-a-layered-modular-monolith.md): The 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.
- [How Data Moves: DataHub, Adapters, and the Python Bridge](https://grok-wiki.com/public/wiki/fincept-corporation-finceptterminal-b8b64fbc871f/pages/02-how-data-moves-datahub-adapters-and-the-python-bridge.md): The 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.
- [Invariants, Failure Modes & Safe-Change Rules](https://grok-wiki.com/public/wiki/fincept-corporation-finceptterminal-b8b64fbc871f/pages/03-invariants-failure-modes-safe-change-rules.md): The 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?

## Source Files

- `docs/ARCHITECTURE.md`
- `docs/CONTRIBUTING.md`
- `docs/CPP_CONTRIBUTOR_GUIDE.md`
- `docs/PYTHON_CONTRIBUTOR_GUIDE.md`
- `fincept-qt/CMakeLists.txt`
- `fincept-qt/scripts`
- `fincept-qt/src/app`
- `fincept-qt/src/auth`
- `fincept-qt/src/core`
- `fincept-qt/src/datahub`
- `fincept-qt/src/mcp`
- `fincept-qt/src/network`
- `fincept-qt/src/python`
- `fincept-qt/src/screens`
- `fincept-qt/src/services`
- `fincept-qt/src/storage`
- `fincept-qt/src/trading`
- `README.md`