47 posts
This is not about secret indicators. It is a practical knowledge map for programmers who want to build a quant-trading platform: data, factors, strategies, backtesting, risk controls, execution, performance, quality, and the long path from research to real results.
A practical engineering roadmap for building a quant-trading platform around a real GitHub project: Python project structure, A-share rules, data layers, factors, backtesting, paper trading, alerts, daily runs, and operations.
Article 45 adds OpsRunbook, turning execution decisions into operator-readable steps, and reviews the progress made in articles 41-45.
Article 44 adds ExecutionDecision, centralizing the execution judgment for ready, dry-run-ready, and blocked states so the command layer cannot accidentally trigger real paper-trading side effects.
Article 43 adds DailyRunCommandResponse, wrapping daily-run status, summary message, artifact path, and exit code into an object that the command layer can return directly.
Article 42 adds DailyRunArtifact, writing the daily-run plan's summary, request, failed checks, and actions into JSON as stable evidence for debugging and archival.
Article 41 adds DailyRunSummary outside DailyRunPlan, compressing daily-run status, symbol count, failed checks, and execution judgment into a log-friendly and CLI-friendly summary line.
Article 40 composes daily requests, operations checklists, run results, and failure actions into a daily run plan, then reviews the progress across articles 36-40.
Article 39 adds a failure-action policy that maps failed checks such as run_window, data_gaps, and run_health into concrete next-step suggestions.
Article 38 reads the daily report archive directory and generates index entries with trade date, status, and path, making historical reports easier to query and display.
Article 37 converts the operations checklist into a daily run result, distinguishes ready, dry-run-ready, and blocked, and keeps failed check names for later action mapping.
Article 36 adds a daily run request object, collecting trade date, generation time, required symbol list, and dry-run flag into one boundary before building a real runtime entry point.
Article 35 summarizes the run window, history summary, data gaps, and health report into an operations checklist, then reviews the progress made in articles 31-35.
Article 34 compares required symbols with a price snapshot and generates blocker-level data-gap plans so strategies do not silently run with missing prices.
Article 33 reads daily archived reports and calculates report count, latest status, blocker count, and notification success rate, moving paper trading from single-day output to a history view.
Article 32 writes alert messages, run health reports, and review records into stable JSON archives, laying the foundation for paper-trading audits and history statistics.
Article 31 adds a run window to the paper-trading daily flow, preventing jobs from running at the wrong time and returning the next allowed run time.
Article 30 summarizes price snapshots, production checks, and notification receipts into a run health report, classifying each daily paper-trading run as ok, warning, or blocker.
Article 29 adds a target-weight policy that converts candidate stocks into equal-weight targets with controlled gross exposure and normalization, giving rebalance plans more stable input.
Article 28 adds a price-provider protocol and a static price provider, turning the daily paper-trading last_prices dictionary into replaceable input for later real market-data integration.
Article 27 implements a file-based notification channel that writes paper-trading daily reports and receipts into JSONL as a verifiable substitute before real notification platforms are connected.
Article 26 adds a paper-trading notification-channel abstraction, stabilizing the send interface and receipt structure before connecting files, Lark, email, or other channels.
Article 25 adds paper-trading production checks for cash, market prices, target weights, daily reports, and review records, then reviews articles 21-25.
Article 24 saves and restores paper-trading account state with JSON files, persisting only cash and positions instead of derived snapshots so the daily flow can continue after restarts.
Article 23 links account snapshots, risk checks, rebalance plans, recommendation summaries, daily alert messages, and review records into one testable paper-trading daily cycle.
Article 22 adds paper-trading review records, saving daily equity, cash ratio, risk severity, and recommendation action as sortable entries with multi-day summaries.
Article 21 combines account snapshots, risk reports, and rebalance plans into HOLD, REBALANCE, and REDUCE_RISK actions so paper-trading output is easier to review and alert on.
Article 20 combines account snapshots, risk reports, and rebalance plans into paper-trading daily report text, leaving a stable message format for Lark, email, or other notification channels.
Article 19 implements the first rebalance-plan layer, converting gaps between current and target weights into A-share board-lot buy and sell suggestions without modifying the account.
Article 18 implements paper-trading risk checks based on account snapshots, validating total exposure, cash buffer, and single-stock weight with readable violations.
Article 17 builds account snapshots on top of the paper-trading ledger, calculating cash ratio, position market value, floating PnL, and weights as unified input for risk controls and notifications.
Article 16 enters paper trading by adding accounts, positions, and execution results, making buy, sell, cash, and market-value updates testable ledger logic.
Article 15 implements a strategy promotion gate: candidates must satisfy minimum return, max drawdown, trade-count, and baseline-comparison requirements before entering paper-trading observation.
Article 14 implements strategy experiment records by saving parameter-search candidates, baseline results, metric deltas, status, and decisions into structured payloads for later review.
Article 13 implements parameter search by generating short-window, long-window, and position-ratio candidates, running one backtest per group, and ranking results with return, drawdown, and turnover penalties.
Article 12 adds reusable backtest metrics: total return, annualized return, annualized volatility, Sharpe-like ratio, max drawdown, win rate, profit-loss ratio, turnover, and trade count.
Article 11 extends the first single-symbol backtest into a multi-symbol portfolio backtest with equal-weight capital allocation, per-symbol runs, equity aggregation, and trade-count summaries.
Article 10 connects market-data cleaning, factor signals, and A-share order rules to complete the first runnable signal-backtest loop, then reviews the stage from articles 6 to 10.
Article 9 implements factor calculation with the Python standard library: daily return, moving averages, momentum, annualized volatility, and three explainable signals: buy_watch, observe, and risk_watch.
Article 8 implements market-data cleaning: parse trade dates and numeric fields, validate OHLC, deduplicate rows, normalize volume units, and output coverage reports with rejection reasons.
Article 7 implements stock-universe construction: normalize symbols, filter ST and delisted names, deduplicate, cap size, and express the public A-share universe builder as testable pure functions.
Article 6 enters PostgreSQL and Alembic: why a quant platform cannot rely only on in-memory objects, how to inspect SQLAlchemy metadata, and how to turn schema and migrations into testable engineering boundaries.
Article 5 enters the data layer: why data-source abstraction, market and financial data, data-quality checks, provenance, and coverage must come before strategy work. It also reviews the first five articles.
Article 4 puts A-share board lots, T+1, limit-up/limit-down, suspensions, ST names, commission, and stamp duty into order-checking code, adding a testable trading_rules module in ZiQuant.
Article 3 translates terms such as stock universe, K-line, adjusted prices, factors, signals, positions, backtests, max drawdown, and Sharpe into ZiQuant models, fields, and testable objects.
Article 2 builds ZiQuant's Python engineering skeleton: directories, pyproject.toml, .env, configuration loading, health checks, and test commands. Make the project installable, runnable, and verifiable before the data layer.
Quant trading is not mysticism, and it is not passive income from one magic indicator. Article 1 reframes trading as data, rules, validation, risk control, and review, then starts ZiQuant as a runnable project.