Last Updated: 2026-05-03 Owner: Docs-Dev Summary: Four-week sprint plan that breaks the early QuantMatrix roadmap into practical weekly execution goals.
QuantMatrix Milestone Sprint Plan: First 4 Weeks¶
This document turns the QuantMatrix roadmap into a practical first 4-week execution plan.
Its purpose is to: - convert milestone ideas into immediate build work - keep the team focused on the right order of operations - make progress measurable week by week - reduce hidden blockers during early implementation
This plan assumes the current priority is: - build the platform cleanly - avoid premature complexity - establish paper-trading readiness later, not immediately
1. Sprint Plan Objectives¶
At the end of these 4 weeks, the goal is to have: - a stable project foundation - a runnable local platform - a usable documentation portal - a working UI shell - core runtime wiring in place - dry-run trading paths available
2. Scope For The First 4 Weeks¶
Included: - repository structure and shared models - config and environment separation - logging, health, Redis, PostgreSQL wiring - local demo runtime - dry-run broker - demo market data - core UI shell - account, radar, watchlist, positions, orders, settings views - docs portal maintenance path
Not included yet: - full paper-trading broker maturity - live trading - advanced strategy logic - full analytics recommendation engine - multi-broker expansion
3. Delivery Model¶
Recommended rhythm: - Week 1: foundation - Week 2: local runtime - Week 3: UI and dry-run trading flow - Week 4: integration hardening and readiness review
4. Week 1: Foundation and Project Skeleton¶
Goal¶
Create a stable technical base so later features do not get built on shaky assumptions.
Tasks¶
| Task ID | Task | Priority | Depends On | Done When |
|---|---|---|---|---|
| W1-01 | Finalize repo structure | P0 | None | Directories and ownership boundaries are clear |
| W1-02 | Implement environment-aware config loader | P0 | W1-01 | Local, paper, live, and backtest config paths are separated |
| W1-03 | Add structured logging baseline | P0 | W1-01 | Logs include service and severity consistently |
| W1-04 | Add API and component health framework | P0 | W1-01 | Health endpoint returns meaningful statuses |
| W1-05 | Add Redis connection module | P0 | W1-02 | Redis connectivity is validated locally |
| W1-06 | Add PostgreSQL connection module | P0 | W1-02 | Postgres connectivity is validated locally |
| W1-07 | Add migration workflow | P0 | W1-06 | Initial migration applies cleanly |
| W1-08 | Define shared domain models | P1 | W1-02 | Shared models exist for orders, positions, signals, and health |
| W1-09 | Define broker abstraction base | P1 | W1-08 | Base broker contract is documented and implemented |
| W1-10 | Define market data abstraction base | P1 | W1-08 | Base market data contract is documented and implemented |
Week 1 Acceptance Criteria¶
- app boots locally
- config separation exists
- health endpoint works
- Redis and PostgreSQL connect
- migrations run
- shared models are usable by downstream modules
5. Week 2: Local Runtime and Demo Services¶
Goal¶
Stand up a safe local end-to-end runtime with no broker dependency.
Tasks¶
| Task ID | Task | Priority | Depends On | Done When |
|---|---|---|---|---|
| W2-01 | Implement dry-run broker adapter | P0 | W1-09 | Orders can be simulated locally |
| W2-02 | Implement demo market data feed | P0 | W1-10 | Demo feed emits normalized events |
| W2-03 | Wire local runtime bootstrap | P0 | W1-04, W2-01, W2-02 | Local runtime starts all expected services |
| W2-04 | Add Redis-backed event bus baseline | P0 | W1-05 | Services can publish and consume normalized events |
| W2-05 | Add basic account summary state source for local mode | P1 | W2-01 | Local account cards return stable values |
| W2-06 | Add demo order and position state persistence path | P1 | W1-06, W2-01 | Demo orders and positions survive within runtime session |
| W2-07 | Add baseline tests for local runtime modules | P1 | W2-01 to W2-06 | Core runtime logic has unit and integration tests |
Week 2 Acceptance Criteria¶
- local runtime starts from one command
- dry-run broker executes simulated order lifecycle
- demo market data reaches the runtime
- event bus works for basic flows
- local account summary is visible
6. Week 3: UI Shell and Core Screens¶
Goal¶
Make QuantMatrix feel like a real product locally, with the main screens working against demo state.
Tasks¶
| Task ID | Task | Priority | Depends On | Done When |
|---|---|---|---|---|
| W3-01 | Build Command Center layout | P0 | W2-03 | Top cards and primary widgets render |
| W3-02 | Build Account screen | P1 | W2-05 | Account summary and performance areas render |
| W3-03 | Build Positions and Orders screens | P1 | W2-06 | Demo positions and orders display correctly |
| W3-04 | Build Risk & Health screen | P1 | W1-04, W2-04 | Health and risk state are visible |
| W3-05 | Build Settings screen | P1 | W1-02 | Runtime settings are visible and structured |
| W3-06 | Connect Momentum Radar demo flow | P0 | W2-02, W2-04 | Radar updates with demo leaders |
| W3-07 | Connect Watchlist actions in local mode | P0 | W3-01, W2-04 | Watch and stop/restart actions behave correctly |
| W3-08 | Keep docs portal updated for new system changes | P2 | Ongoing | Docs reflect the current build reality |
Week 3 Acceptance Criteria¶
- UI loads cleanly
- key screens are navigable
- demo data renders coherently
- watchlist flow works in local mode
- docs portal remains usable and updated
7. Week 4: Integration Hardening and Readiness Review¶
Goal¶
Tighten the first month of work so the base is trustworthy enough to begin the paper-trading core next.
Tasks¶
| Task ID | Task | Priority | Depends On | Done When |
|---|---|---|---|---|
| W4-01 | Tighten tests across config, broker, OMS, radar, and UI-adjacent state | P0 | W1-W3 tasks | Critical core logic has passing tests |
| W4-02 | Review and align Data Dictionary, API Reference, and Event Contract docs | P0 | W1-W3 tasks | Contracts match real code paths |
| W4-03 | Validate docs portal navigation and search against full doc set | P1 | W3-08 | Portal is easy to use and current |
| W4-04 | Run local readiness review using checklist pack | P0 | W1-W3 tasks | Blockers for paper-trading milestone are known |
| W4-05 | Capture technical debt and deferred items clearly | P1 | W4-04 | Deferred items are explicit, not implicit |
| W4-06 | Prepare Milestone 3 paper-trading kickoff list | P1 | W4-04 | Next set of tasks is ready to start |
Week 4 Acceptance Criteria¶
- local mode is stable and explainable
- docs and contracts match implementation
- test baseline is strong enough for further integration
- next milestone start is unblocked
8. Best Next Step After This Sprint Plan¶
After this plan, the best next move is:
Begin execution by assigning owners and statuses in the Notion-Style Execution Tracker.
That closes the loop between: - roadmap - sprint plan - task tracking - delivery accountability