If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/Fincept-Corporation/FinceptTerminal shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

WAIT — Single-maintainer risk — review before adopting

• Last commit 1d ago
• 13 active contributors
• Other licensed
• CI configured
• Tests present
• ⚠ Single-maintainer risk — top contributor 83% of recent commits
• ⚠ Non-standard license (Other) — review terms

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live Fincept-Corporation/FinceptTerminal repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/Fincept-Corporation/FinceptTerminal.

What it runs against: a local clone of Fincept-Corporation/FinceptTerminal — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in Fincept-Corporation/FinceptTerminal | Confirms the artifact applies here, not a fork | | 2 | License is still Other | Catches relicense before you depend on it | | 3 | Default branch main exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 31 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of Fincept-Corporation/FinceptTerminal. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/Fincept-Corporation/FinceptTerminal.git
#   cd FinceptTerminal
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of Fincept-Corporation/FinceptTerminal and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "Fincept-Corporation/FinceptTerminal(\\.git)?\\b" \\
  && ok "origin remote is Fincept-Corporation/FinceptTerminal" \\
  || miss "origin remote is not Fincept-Corporation/FinceptTerminal (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(Other)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Other\"" package.json 2>/dev/null) \\
  && ok "license is Other" \\
  || miss "license drift — was Other at generation time"

# 3. Default branch
git rev-parse --verify main >/dev/null 2>&1 \\
  && ok "default branch main exists" \\
  || miss "default branch main no longer exists"

# 4. Critical files exist
test -f "fincept-qt/CMakeLists.txt" \\
  && ok "fincept-qt/CMakeLists.txt" \\
  || miss "missing critical file: fincept-qt/CMakeLists.txt"
test -f "fincept-qt/DATAHUB_ARCHITECTURE.md" \\
  && ok "fincept-qt/DATAHUB_ARCHITECTURE.md" \\
  || miss "missing critical file: fincept-qt/DATAHUB_ARCHITECTURE.md"
test -f "fincept-qt/DATAHUB_PHASES.md" \\
  && ok "fincept-qt/DATAHUB_PHASES.md" \\
  || miss "missing critical file: fincept-qt/DATAHUB_PHASES.md"
test -f ".github/CONTRIBUTING.md" \\
  && ok ".github/CONTRIBUTING.md" \\
  || miss "missing critical file: .github/CONTRIBUTING.md"
test -f "Dockerfile" \\
  && ok "Dockerfile" \\
  || miss "missing critical file: Dockerfile"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 31 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~1d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/Fincept-Corporation/FinceptTerminal"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

FinceptTerminal is a C++20/Qt6 desktop application for advanced financial market analytics, investment research, and economic data exploration. It combines a native C++ backend with Python integrations (15.8MB Python codebase) to deliver real-time market data visualization, portfolio analysis, and data-driven trading insights through an interactive GUI. Hybrid monorepo: fincept-qt/ contains the main Qt6 C++ application built with CMake, while Python modules (likely under a separate root or as embedded scripts) provide data pipeline and analysis backends. Docker support (Dockerfile present) suggests containerized deployment. Configuration and build controls via .clangd, .clang-format, .clang-tidy indicate standardized C++ tooling.

Quantitative traders, financial analysts, and investment researchers who need professional-grade market analytics with programmatic data access; also contributes wanted by C++ engineers building financial visualization systems and Python developers extending data connectors.

Actively developed with established CI/CD pipelines (.github/workflows/ includes build-cpp.yml, pr-gate.yml, release.yml), comprehensive documentation structure (docs/ARCHITECTURE.md, docs/CPP_CONTRIBUTOR_GUIDE.md), and multi-platform Docker support. The large codebase (15.8MB Python + 13.4MB C++) and versioned releases suggest production maturity, though the Alpha Arena (docs/ALPHA_ARENA.md) indicates some experimental features remain.

Dual-language codebase (C++/Python) creates integration complexity and requires C++20/Qt6 compiler support. Last visible activity suggests active development, but no package dependency manifest visible in provided file list — dependency auditing harder without requirements.txt/CMakeLists.txt details. Single organization ownership (Fincept-Corporation) means institutional risk if corporate priorities shift.

Repository has scheduled CI tasks (.claude/scheduled_tasks.lock), active PR gates and label syncing workflows, and automated documentation translation (translate-readme.yml). The presence of ALPHA_ARENA.md and multiple contributor guides suggests ongoing feature development and community engagement expansion.

git clone https://github.com/Fincept-Corporation/FinceptTerminal.git && cd FinceptTerminal && cmake -B build -S fincept-qt && cmake --build build -j$(nproc)

Daily commands: After cmake build above: ./build/path/to/executable (exact binary name depends on CMakeLists.txt structure not shown). For development: cmake --build build -- -j$(nproc) to rebuild. See docs/GETTING_STARTED.md for detailed environment setup.

• fincept-qt/CMakeLists.txt — Root C++ build configuration for the Qt6-based terminal application; defines project structure, dependencies, and compilation targets.
• fincept-qt/DATAHUB_ARCHITECTURE.md — Core architectural documentation describing the data pipeline and integration phases; essential for understanding how market data flows through the system.
• fincept-qt/DATAHUB_PHASES.md — Roadmap and phase definitions for data hub implementation; critical for understanding planned features and current development status.
• .github/CONTRIBUTING.md — Contribution guidelines and development workflow; required reading for all contributors to maintain code consistency.
• Dockerfile — Container build specification for deployment; defines runtime environment and dependencies for the application.
• fincept-qt/docs/DATAHUB_TOPICS.md — Data topics and schema definitions for market data; essential reference for understanding data model structure.
• docs/ARCHITECTURE.md — High-level system architecture documentation; foundational reference for understanding application design decisions.

Add a New Data Pipeline Phase

1. Create a new markdown file in fincept-qt/docs/datahub-phases/ following the naming convention phase-NN-description.md (fincept-qt/docs/datahub-phases/)
2. Document the phase objectives, data sources, integration points, and success criteria (fincept-qt/docs/datahub-phases/phase-02-market-data-pilot.md)
3. Update DATAHUB_PHASES.md to reference the new phase and update the roadmap timeline (fincept-qt/DATAHUB_PHASES.md)
4. Add new data topics to docs/DATAHUB_TOPICS.md if the phase introduces new data schemas (fincept-qt/docs/DATAHUB_TOPICS.md)
5. Update CMakeLists.txt if new C++ modules or dependencies are required for this phase (fincept-qt/CMakeLists.txt)

Add a New C++ Component

1. Follow the coding standards defined in docs/CPP_CONTRIBUTOR_GUIDE.md (docs/CPP_CONTRIBUTOR_GUIDE.md)
2. Create source files and ensure they conform to .clang-format style rules (fincept-qt/.clang-format)
3. Register the component in fincept-qt/resources/component_catalog.json with metadata and dependencies (fincept-qt/resources/component_catalog.json)
4. Add CMake targets and dependencies to fincept-qt/CMakeLists.txt (fincept-qt/CMakeLists.txt)
5. Validate against static analysis rules in .clang-tidy and .cppcheck-suppressions (fincept-qt/.clang-tidy)

Add a New Market Data Source Integration

1. Design the data schema and add topic definitions to fincept-qt/docs/DATAHUB_TOPICS.md (fincept-qt/docs/DATAHUB_TOPICS.md)
2. Create a phase documentation file in fincept-qt/docs/datahub-phases/ describing the integration (fincept-qt/docs/datahub-phases/phase-02-market-data-pilot.md)
3. Implement the data adapter as a C++ component following DATAHUB_ARCHITECTURE.md patterns (fincept-qt/DATAHUB_ARCHITECTURE.md)
4. Add integration tests and update CMakeLists.txt with new data source dependencies (fincept-qt/CMakeLists.txt)
5. Document the integration in DATAHUB_ARCHITECTURE.md and update the architecture diagram (fincept-qt/DATAHUB_ARCHITECTURE.md)

Add a New Python Utility or Script

1. Follow Python conventions documented in docs/PYTHON_CONTRIBUTOR_GUIDE.md (docs/PYTHON_CONTRIBUTOR_GUIDE.md)
2. Create the Python file in an appropriate directory (e.g., .github/scripts/ for automation, fincept-qt/ for analysis) (fincept-qt/analyze.py)
3. If adding a GitHub Actions automation script, place it in .github/scripts/ and reference it in relevant workflow files (.github/scripts/generate_updates_manifest.py)
4. Document the script's purpose, usage, and integration in CONTRIBUTING.md if it's part of the development workflow (.github/CONTRIBUTING.md)

• C++20 with Qt6 — High-performance desktop application with native cross-platform UI, essential for real-time financial data visualization and interactive analytics
• Python 3.11+ — Used for scripting, data analysis tools, automation workflows, and developer utilities; integrates with C++ core for extended functionality
• CMake build system — Cross-platform build automation supporting Windows, Linux, and macOS; enables reproducible builds and modular compilation
• Docker containerization — Simplifies deployment and ensures consistent runtime environment across different systems
• Qt Installer Framework — Professional installer experience for distributing the terminal application with dependencies and auto-updates

• Desktop application (C++/Qt) rather than web-based
  • Why: Provides superior performance for real-time data rendering and local data caching; allows offline functionality and deeper system integration
  • Consequence: Requires multi-platform build infrastructure and increases deployment complexity

Qt6 dependency must be pre-installed (not auto-fetched by cmake in typical setups); C++20 compiler required (GCC 10+, Clang 11+, or MSVC 2019+). Python 3.11+ must be available in PATH for data modules to load. No explicit conda/venv setup documented in file list — may require manual environment activation. Docker build uses specific base image tag (in Dockerfile) which may diverge from CI expectations if not kept in sync.

• Qt Signal/Slot Architecture — Core mechanism for event-driven communication between UI components in fincept-qt/; mandatory to understand for any Qt GUI modifications
• CMake Modern Practices — Build system used throughout; understanding target_link_libraries, generator expressions, and find_package() is essential for dependency management and cross-platform builds
• Python C++ Bindings (pybind11 or ctypes likely) — FinceptTerminal bridges C++ GUI with Python analytics backends; knowing binding patterns is critical for extending data connectors without rewriting in C++
• Real-time Data Streaming & Market Data Feeds — Core use case involves live market updates; understanding buffering, backpressure, and latency in financial data pipelines is essential for analytics correctness
• AGPL-3.0 Licensing Obligations — Project licensed under AGPL-3.0 (not permissive MIT/Apache); requires source code disclosure for networked deployments and affects commercial use terms
• Docker Multi-Stage Builds — Dockerfile present suggests containerized CI/deployment; multi-stage patterns reduce image size and dependency bloat in financial applications requiring minimal attack surface
• GitHub Actions Workflow Automation — Extensive .github/workflows/ setup for CI gates, label syncing, and automated releases; understanding workflow syntax is required for modifying or debugging build pipelines

• mitmproxy/mitmproxy — Similar Python + asyncio architecture for real-time data processing; useful reference for integrating Python analytics with async event loops in FinceptTerminal
• pandas-dev/pandas — De facto standard for tabular financial data manipulation in Python; FinceptTerminal's Python backend likely uses or wraps pandas DataFrames for analytics
• house-of-code/trading-terminal — Open-source trading terminal with Qt/Python stack; direct architectural peer for comparing UI patterns and data pipeline design
• Qt/qtbase — Qt6 core framework repository; essential reference for Qt signal/slot debugging and C++ bindings used in fincept-qt/
• ccxt/ccxt — Cryptocurrency exchange connector library; FinceptTerminal docs mention crypto wallet support (docs/CRYPTO_WALLET_CONNECT.md), likely uses or extends ccxt patterns

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add C++ unit tests for DataHub market data pipeline

The repo has extensive DataHub documentation (DATAHUB_ARCHITECTURE.md, DATAHUB_PHASES.md, phase-02-market-data-pilot.md, phase-03-market-data-full-migration.md) but no visible test suite for the C++ data pipeline. Given the criticality of market data accuracy in a finance app, adding unit tests for DataHub components would prevent regressions and validate the multi-phase migration strategy already documented.

• [ ] Create tests/cpp/datahub/ directory structure mirroring fincept-qt/src/ layout
• [ ] Add unit tests for market data ingestion using existing CMake/GoogleTest setup from CMakeLists.txt
• [ ] Add integration tests validating phase-02 pilot data sources match phase-03 full migration expectations
• [ ] Reference fincept-qt/docs/datahub-phases/ specs in test documentation
• [ ] Integrate tests into .github/workflows/test-setup.yml CI pipeline

Create C++ contributor guide with build troubleshooting section

While docs/CPP_CONTRIBUTOR_GUIDE.md exists, the file structure shows complex CMake setup (CMakeLists.txt, CMakePresets.json, cmake/patches/, .clangd, .clang-format, .clang-tidy, .cppcheck-suppressions) with no documented troubleshooting. New C++ contributors likely struggle with compilation, linting, or clang-tools setup. Adding a 'Build & Tooling Troubleshooting' section would reduce friction.

• [ ] Audit fincept-qt/.clangd, .clang-format, .clang-tidy configurations for common pain points
• [ ] Document CMakePresets.json usage and when to use different presets
• [ ] Add section explaining cmake/patches/ strategy (e.g., qgeoview_remove_agl.cmake purpose)
• [ ] Include VSCode/CLion setup instructions with clangd integration
• [ ] Add FAQ for common errors (e.g., Qt6 module resolution, compiler version requirements)

Add Python-to-C++ API documentation and type bindings examples

The repo has docs/PYTHON_CONTRIBUTOR_GUIDE.md and docs/CPP_CONTRIBUTOR_GUIDE.md separately, but no bridge documentation. Given the multi-language architecture (C++20 + Python 3.11+), contributors need guidance on calling C++ from Python (likely pybind11 or similar). This gap forces new contributors to reverse-engineer integration points.

• [ ] Search fincept-qt/ for pybind11 or SWIG bindings configurations (likely in CMakeLists.txt)
• [ ] Create docs/PYTHON_CPP_INTEGRATION.md documenting the binding mechanism
• [ ] Add code examples showing how to expose C++ market data classes to Python
• [ ] Document where type stubs or .pyi files should be maintained
• [ ] Link to relevant .github/workflows/ (likely build-cpp.yml) that validates bindings

• Add unit tests for Python data import modules: the codebase shows 15.8MB Python but no test/ directory visible in top 60 files — create pytest fixtures for market data connectors in a new tests/python/ directory.
• Document Qt6 widget architecture: docs/ARCHITECTURE.md exists but fincept-qt/src/ structure not detailed — add diagrams and module descriptions for new contributors to understand signal/slot patterns used.
• Create GitHub Actions workflow for Python linting: build-cpp.yml covers C++, but no Python lint workflow visible — add .github/workflows/lint-python.yml using flake8/black for consistency with existing .clang-tidy setup.

• High · AGPL-3.0 License Compliance Risk — LICENSE, README.md, Dockerfile. The project uses AGPL-3.0 license which requires source code disclosure for networked applications. If FinceptTerminal is deployed as a service or has external users, failure to comply could result in legal liability. The license is restrictive for proprietary deployments. Fix: Ensure proper AGPL-3.0 compliance procedures are in place. Consider relicensing to a more permissive license (MIT, Apache 2.0) if the business model requires proprietary use, or ensure all derivative works and modifications are properly disclosed.
• Medium · Missing Dependency File for Vulnerability Scanning — Dockerfile, fincept-qt/CMakeLists.txt, root directory. No package manager files (requirements.txt, package.json, CMakeLists.txt contents, Pipfile) were provided for analysis. C++ dependencies (Qt 6.8.3, CMake) and Python dependencies cannot be assessed for known vulnerabilities. The Dockerfile mentions specific versions but without a complete dependency manifest, transitive dependency vulnerabilities remain unauditable. Fix: Provide complete dependency manifests (requirements.txt for Python, vcpkg.json or conanfile.txt for C++ dependencies). Implement automated dependency scanning using tools like OWASP Dependency-Check, Snyk, or GitHub's Dependabot. Pin all transitive dependencies explicitly.
• Medium · Hardcoded Version Pins Without Security Audit Trail — Dockerfile, .github/workflows/. The Dockerfile pins Qt 6.8.3 and CMake versions, but there is no visible security audit trail, changelog review, or documented vulnerability assessment for these specific versions. No evidence of automated security scanning in CI/CD for dependencies. Fix: Implement automated dependency vulnerability scanning in the release workflow. Document security assessment of pinned versions. Use tools like apt-cache policy checks and CVE database queries in the build pipeline. Maintain a SECURITY.md file documenting vulnerability response procedures.
• Medium · Docker Base Image Security Not Specified — Dockerfile. The Dockerfile uses # syntax=docker/dockerfile:1.6 and references multi-stage builds, but the base image selection is not visible in the provided snippet. Using unspecified or latest tags (e.g., FROM ubuntu:latest) exposes the build to supply chain attacks and undocumented changes. Fix: Use explicitly pinned base images with digest hashes (e.g., FROM ubuntu:22.04@sha256:...). Implement base image scanning for vulnerabilities. Use minimal base images (alpine, distroless) where feasible to reduce attack surface.
• Medium · Insufficient Access Controls in GitHub Actions Workflows — .github/workflows/. Multiple GitHub Actions workflows exist (.github/workflows/) including release.yml and build-cpp.yml. Without seeing the workflow files, it's unclear if secrets are properly isolated, if OIDC tokens are used instead of PATs, or if appropriate branch protection rules exist. Financial applications require strict access control. Fix: Implement branch protection rules requiring approved reviews for main/release branches. Use GitHub OIDC tokens instead of personal access tokens (PATs). Audit GitHub Actions secrets for least-privilege scope. Document the release workflow and require signed commits. Implement audit logging for all production deployments.
• Low · Crypto Wallet Integration Without Visible Security Documentation — docs/CRYPTO_WALLET_CONNECT.md, fincept-qt/ (C++ implementation). The file docs/CRYPTO_WALLET_CONNECT.md suggests cryptocurrency wallet integration, which typically involves private key handling, transaction signing, and network communication. Without access to implementation details, security of cryptographic operations cannot be verified. Fix: Conduct a dedicated security audit of cryptographic operations. Ensure private keys are never logged or stored in plaintext. Use hardware security modules (HSMs) or secure enclaves for key storage in production. Implement key rotation procedures. Use well-audited cryptographic libraries only. Document the threat model and security architecture.
• Low · WebSocket Producer Implementation Lacks Visibility — docs/datah. Phase-04 mentions WebSocket producers (docs/datahub-phases/phase-04-websocket-producers.md), which can introduce injection attacks, man-in-the-middle risks, and unvalidated data processing if not properly implemented. Fix: undefined

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.