[Feature proposal] Optional SchwabDev integration for self-hosted deployments (read-only first)

[AngeLakers]

Problem or motivation

Would the maintainers be interested in an optional Charles Schwab integration for self-hosted QuantDinger, using SchwabDev?

The goal is to provide a broker-account entry similar to the existing IBKR/Alpaca experience, so users can inspect connection status, balances, positions, orders and market data without putting broker credentials into strategy code.

This is an early feature/design proposal, not a request to merge a production-ready trading connector. A local prototype exists, but it still needs further testing and generalization before an upstream PR.

Proposed solution

Start with a deliberately small, read-only implementation:

• Optional SchwabDev dependency or an opt-in companion service; disabled by default.
• A broker-account panel for authorization status, account access verification, balances, positions and recent orders/order details.
• Quotes and historical candles, subject to the user's Schwab API permissions.
• App credentials and OAuth tokens remain on the self-hosted server. No secrets or authorization callback codes in browser responses, logs or strategy code.
• Explicit account selection and authorization checks. The first version could be restricted to a clearly documented single-owner self-hosted mode rather than claiming multi-tenant support.
• Use the existing authenticated QuantDinger API/frontend entry; no additional public broker-service port.
• Normal service/route registration, OpenAPI documentation, portable configuration, and synthetic tests that do not require a funded account or live order submission.

Out of scope for the first contribution: placing/canceling live orders, automatic Strategy V2 execution, options/short selling, and claims of production trading readiness. Any local preview would be clearly labeled as offline validation, not broker acceptance or simulated execution.

If the read-only integration is useful and the architecture is agreed, Strategy V2 execution could be considered separately, with strategy-owned positions, budget/reservation checks, idempotency, and order/fill reconciliation designed and tested before enabling it.

Alternatives considered

• Keep the integration as a personal extension: workable, but frontend/backend upgrades require maintaining a separate patch.
• Use schwab-py instead of SchwabDev: open to the maintainers' preferred SDK and maintenance trade-offs.
• Keep an isolated companion service versus an in-process adapter: the former separates token management; the latter may fit existing broker infrastructure more naturally.

Questions for maintainers

1. Would a read-only Schwab integration be welcome, or is related work already planned?
2. Would you prefer an in-process adapter, an optional companion service, or another extension mechanism?
3. Would a single-owner self-hosted scope be acceptable for an initial PR?
4. How would you prefer the backend and separate frontend changes to be coordinated?

I would like to continue testing the prototype before preparing a focused contribution. No private configuration, account data or credentials are attached.