Simulated live trading manual smoke generation solution (live_grid_multi)

Dear user, this chapter is a manual checklist: On a real trading day (or at a time convenient to you), run a simulated live trading session using the repository example ``examples/live_grid_multi.py`, check off each item, and confirm that qteasy’s behavior is consistent with the documentation.

What is smoke testing? Like sea trials before a new ship is launched—it doesn’t need to cover all strategies, but rather uses fixed examples + fixed checks to quickly determine “whether it works and whether the logs are readable.” This manual focuses on real `qt.run` + human verification; during non-trading hours, headless scripts in the repository can also be used for architecture regression (see below).

Strategy baseline: examples/live_grid_multi.py (5-minute VS + multi-mark grid). Maintainers who need to refer to the internal roadmap can refer to the repository .cursor/plans/trader architecture upgrade roadmap_0650f0d5.plan.md (optional, not required to read).

Relationship with headless scripts

tests/notebook_trader_headless_script.py provides phased headless smoke (including 5-A/5-B, 5-C, etc.), which can be called in Notebook cells.
This manual focuses on: you personally launching live, viewing the CLI/logs, and checking the boxes.
Recommended schedule: On trading days follow this manual; During market closures use a headless script to perform regression analysis.

I. Environment and Prerequisites

Python: /opt/anaconda3/envs/py39/bin/python is recommended. If you installed qteasy via pip, the working directory can be any path containing examples/live_grid_multi.py (you don’t need to clone the entire repository, but you must be able to access the example script).
New account, no open positions (to avoid interference from old orders):
- -n/–new_account <username> creates a new account; or
- If an account_id already exists and –restart clears the record, restart only after confirming there are no open positions.
Data: Minute-based strategies require local tables such as stock_1min; the initial refill may take longer, which is normal.
**Logs: sys_log_file_path and trade_log_file_path are writable (check with artifacts).

II. Startup Command Template

Execute in the directory containing the example (adjust according to your account):

/opt/anaconda3/envs/py39/bin/python examples/live_grid_multi.py \\
    -a <ACCOUNT_ID> -n <NEW_USER_NAME_OR_OMIT> \\
    --ui cli \\
    [--debug] [--restart]

Note:

Cold Start: Create a new -n or –restart and confirm that the position is empty.
Do not scale up trade_batch in an unknown environment to avoid financial pressure.
5-C Related CLI It is recommended to add –debug so that run –task diagnose_pending_orders can be executed.

III. Phased Acceptance (Check off each item)

The following stages correspond to internal roadmaps 0-5-C / Stage 11; each item includes what is being verified in this stage, operation, and acceptance.

Phase 0: Baseline, State Machine, and Observability

What to verify: The Trader can start normally, the state transitions are reasonable, and the logs can restore the order of “Startup → Schedule → Critical Tasks”.

Operation: Observe the status (stopped → sleeping/running, etc.) in the CLI/log and the task enqueuing.
Acceptance Test: No unexplained deadlocks; able to reconstruct a complete startup timeline.

Phase 1: Standardized Exit

What to verify: Resources are released after a normal stop/exit, and there are no abnormal truncations in breakpoints and logs.

Operation: Exit normally using Shell; do not forcibly kill the process.
Acceptance Test: No zombie threads; complete logs.

Phase 2: Task Scheduling and Skip

What to verify: Asynchronous price increases and strategy tasks have clear boundaries; when a task is skipped, the log contains readable skip_reason.

Operation: Observe the schedules such as acquire_live_price and run_strategy.
Acceptance: Anomalies/skips are explainable and statistically significant.

Phase 3: Schedule and Catch-up

What to verify: The schedule can be reproduced under the same configuration; the “rerun” behavior when started from the disk is consistent with the documentation.

Operation: Compare the two key moments on the same day, or initiate one during trading.
Acceptance: The schedule output is reproducible.

Phase 3.5: Consistency between Transaction Recording and Payment

What is being verified: The cash/position/order must match after the transaction, with no duplicate deductions.

Operation: Verify the ledger after at least one simulated transaction.
Acceptance: No contradiction of “partial submission”.

Phase 4-A: Transaction Return Path

What is being verified: Transactions are consumed through public paths such as poll_fills, and the SIM can run stably all day.

Operation: Run for half a trading day or a full day.
Acceptance Test: No internal queue class error stack was found.

Phase 4-B: Skip Cause-Based Bucketing

What to verify: The skip_reason= in the logs can be manually categorized (e.g., gate_failed, snapshot_stale).

Operation: Retrieve skip_reason=.
Acceptance: All fields are complete and their meanings are understandable.

Phase 5-A: Strategy Snapshot

What to verify: When split is enabled, prepare before run; skip snapshots that expire and have logs.

Operation: First, set live_trade_split_strategy_prepare=False to establish a baseline; then set True and configure live_trade_prepare_lead_seconds and live_trade_strategy_snapshot_max_age_seconds (must be configured before qt.run).
Acceptance: See prepare for schedule/log; snapshot_stale is explanatory.

Phase 5-B: Activate access control

What to verify: warn only issues a warning; block blocks the policy from being queued in case of a serious failure.

Operations: Test warn / block in different tiers; Shell executes gate.
Acceptance Test: block should not mistakenly block transactions on normal trading days (first use warn for grayscale testing).

Phase 11 / 5-C: Mapping, Rotation, Diagnosis, Reconciliation

What is being verified: Brokerage account write-back, risk log rotation, in-transit order diagnosis, and closing reconciliation JSON.

Order Mapping — Successful orders have broker_order_id; counter rejections have rejected and the broker is empty; risk control rejections have no new order lines, but risk_log has ``.<RISK REJECTED> ``
Products and Rotation — artifacts writable with four keys; rotatelogs --days 30 cleans up expired *.risk.log.
Diagnosis of Pending Orders — DEBUG: run --task diagnose_pending_orders, all fields are complete.
post_close — reconcile JSON containing is_ok, failures, etc.

IV. Supplementary information related to live_grid_multi

Multi-target VS + multi_pars: The grid parameters for each target are initialized reasonably on the first day.
Sub-day frequency refill: For days with smoke, the refill table can be reduced to only the smallest set such as stock_1min.
Acceptance: The behavior on the first day with no open positions was consistent with the example logic; there were no NaN price errors.

5. Notebook emitting smoke without a head (optional)

During market closure, the stage* functions in tests/notebook_trader_headless_script.py can be called within the Notebook; see the script comments for details. This can be used in conjunction with manual live mode.

VI. Daily Work Summary Sheet

When manual smoke testing is complete, you can quickly check off “Which step of today’s testing was completed” using the table below. Each row corresponds to the stage number in Part 3 above; A summary of your actions should be filled in as actually performed, and the checking criteria are from the acceptance specifications for that stage. This table covers Roadmap 0 to 5-C / Stage 11, excluding Broker/QMT integration (see Brokerage Adaptation Layer and Integration).

Column Meanings: Stage is the roadmap number; A summary of your actions is recorded by you; Checkmark Criteria is the minimum requirement to pass this stage.

How to use: After completing a certain stage during the smoke process, write a sentence in the “Action Summary” column (e.g., “Gate passed in warn mode”). If the goal is achieved, check the box in your mind or on the copy; if the goal is not achieved, record it in the “Conclusion” column of §7 Record Template.

stage	Action Summary	Check mark criteria
0	View status/logs	The boot link can be restored
1	Standardized Exit	Normal release of resources
2～4-B	Scheduling and Skip	skip_reason, do you understand?
5-A/B	Snapshots and Access Control	stale/gate is interpretable
11/5-C	Mapping/Rotation/Diagnosis/Reconciliation	See the four sections above.

VII. Record Template (Recommended)

After each smoke signal, record: version number, core live_trade_* configuration, gate result, rejected order sampling, reconcile summary, and conclusion (passed/pending/blocked). This is for comparison on the next trading day.