jjrune/mykiwoom

1. Repository purpose

- This is a Windows-only, Python-based automated trading system for Kiwoom Securities.

- It is not a single app, but a set of coordinated executables/scripts for login, live trading, market-data collection, backtesting, and daily DB maintenance.

2. Top-level execution model

- The system is driven by .bat launchers, which are intended to be scheduled by Windows Task Scheduler.

- Typical startup flow is: version update → auto-login → trader app.

- Separate batch files also run day-data download, tick updates, and multiple backtest modes.

3. Core runtime boundary: trader/

- trader/ is the main live trading application and UI.

- It contains:

- window.py for the main PyQt desktop UI,

- worker.py for background processing,

- query.py for Kiwoom/OpenAPI requests,

- strategy_*.py for short/mid/long/tick trading logic,

- updater_chart.py and updater_hoga.py for chart and order-book refresh,

- telegrammsg.py and sound.py for external notifications.

- This folder is the central integration point between market data, strategies, order execution, and user-facing controls.

4. Live trading data flow

- The trader app logs into Kiwoom, initializes required DB tables, and registers market/sector/event subscriptions.

- Real-time data then feeds into strategy modules.

- Strategy decisions trigger order actions through the Kiwoom request layer.

- Trade events, charts, and order-book state are reflected back into the UI.

- Notifications are sent through Telegram and sound alerts.

5. Strategy partitioning

- Strategies are split by timeframe:

- strategy_short.py

- strategy_mid.py

- strategy_long.py

- strategy_tick.py

- The live system can operate with different timing horizons, while the tick strategy handles very short-term behavior.

- The README indicates that some buy/sell strategy internals are intentionally private, so the visible architecture is modular even if the decision logic is partially hidden.

6. Market data collection: tick/

- tick/ focuses on second-level tick capture and analysis.

- updater_tick.py, worker.py, and window.py support collecting and managing tick data.

- backtester_tick.py, backtester_tickm.py, and backfinder_tick.py operate on stored tick history.

- The tick/graph/ directory suggests result visualization artifacts are generated and stored locally.

7. Historical/day-level analysis: day/

- day/ contains daily-bar workflow for short, mid, and long strategies.

- download_daydata.py fetches day-level historical data.

- updater_short.py, updater_mid.py, updater_long.py update the local DB after market close.

- backtester_short.py, backtester_mid.py, backtester_long.py evaluate strategies against historical day data.

- This folder is the offline research/maintenance side of the system, distinct from live execution.

8. Database as shared state

- db/stg.db is the central persistent store.

- It appears to hold:

- historical tick/day data,

- backtest results,

- trade history,

- UI/reporting data,

- possibly watchlists and strategy state.

- The repo is architected so both live trading and offline backtesting use the same local SQLite database as the source of truth.

9. Login and environment preparation: login/

- login/ contains account automation and version management:

- autologin1.py, autologin2.py for two accounts,

- manuallogin.py for fallback manual login,

- versionupdater.py for Kiwoom client/version synchronization.

- login/user.txt stores account configuration.

- This is a separate pre-trading boundary: the trading system depends on the brokerage client being authenticated and up to date before live modules can function.

10. Common configuration and utilities: utility/

- utility/setting.py holds paths, UI colors, fonts, and environment-specific configuration.

- utility/static.py provides shared helper functions/constants.

- This folder is the repo’s configuration spine and is expected to be edited when relocating the installation or changing the UI theme.

11. External integrations

- Kiwoom Securities OpenAPI / HTS is the primary external trading and market-data source.

- Telegram is used for operational notifications.

- Local audio is used for alerts.

- The README also mentions HTS condition-search formulas, which are part of the external trading platform setup and feed the live trader.

12. UI and operator controls

- The main UI is a large PyQt desktop application optimized for a specific screen resolution.

- It provides charts, order-book panels, trade history, profit summaries, and system controls.

- There are explicit modes for:

- test mode: manual command-by-command execution,

- simulated trading: live server connection without real orders,

- live trading: actual order transmission.

- This makes the UI not just a dashboard, but an operational control surface.

13. Batch/script orchestration as infrastructure

- The .bat files are part of the architecture, not just launch shortcuts.

- They define how the system is sequenced across boot, login, updater, trader, and backtest workflows.

- Some batch files are intended for unattended operation and others are used for debugging with pause, which suggests the repo is designed for both scheduled execution and manual validation.

14. Operational artifacts

- log/ stores runtime logs.

- icon/ contains UI assets used by the desktop application.

- These are supporting assets rather than core logic, but they reinforce that this is a local desktop trading workstation with persistent operational history.

15. Diagram takeaway

- If you draw the architecture, the clearest layout is:

- Scheduler / batch scripts at the top,

- branching into login/version control, live trader UI, tick/day data pipelines, and backtest engines,

- all converging on a shared SQLite DB,

- with external connections to Kiwoom OpenAPI/HTS and Telegram.