Skip to content

Last Updated: 2026-05-03 Owner: Docs-Dev Summary: Working list of documentation improvements, follow-up actions, and next-step maintenance items for QuantMatrix.

QuantMatrix TODO and Next Steps

This document captures practical follow-up work for the QuantMatrix documentation and docs experience.

Its purpose is to keep the immediate recommendations visible and easy to update, instead of leaving them buried in chat history.

1. Current Recommendation

Recommended documentation approach:

  1. Keep using the Markdown documents in documentation/docs/ as the source of truth.
  2. Use the MkDocs scaffold as the primary next-generation docs platform.
  3. Keep the current custom local portal working during transition.
  4. Publish the MkDocs site to GitHub Pages once repository hosting is ready.

Why this is the recommended path: - the Markdown source already exists and is in good shape - the MkDocs scaffold is now in place - the current local portal can stay as a fallback during transition - GitHub Pages is a strong free publishing path once the repo is ready

2. Documentation TODOs

Ownership Model

  • [x] Separate UI tasks under UI-Dev
  • [x] Separate API tasks under API-Dev
  • [x] Separate backend process and service tasks under Process-Dev
  • [x] Add testing and validation tasks under QA-Dev
  • [x] Add data and schema tasks under Data-Dev
  • [x] Add operations and deployment tasks under Ops-Dev
  • [x] Add documentation and coordination tasks under Docs-Dev
  • [x] Add strategy logic tasks under Strategy-Dev
  • [x] Add risk enforcement tasks under Risk-Dev

Recommended category meanings: - UI-Dev: screens, widgets, layout, interaction flows, operator usability - API-Dev: FastAPI routes, request/response contracts, UI-facing integration endpoints - Process-Dev: runtime services, async workers, broker/data adapters, orchestration, event processing - QA-Dev: test coverage, validation passes, scenario rehearsal, release confidence checks - Data-Dev: PostgreSQL schemas, Redis key design, persistence, migrations, analytics data capture - Ops-Dev: deployment, environment setup, monitoring, alerting, reconciliation, go-live activities - Docs-Dev: runbooks, checklists, execution tracker maintenance, operational documentation - Strategy-Dev: scanner logic, watchlist flow, allocator logic, entry/exit strategy behavior - Risk-Dev: hard limits, trading halts, exposure controls, duplicate-order and over-trading protection

Immediate

  • [ ] Keep the Markdown documents as the source of truth
  • [ ] Regenerate the documentation portal after doc updates
  • [ ] Review the navigation grouping as the doc set grows
  • [ ] Add newly created docs into the master index and portal sections
  • [ ] Reconcile current UI implementation docs with /Users/dhinakarmanni/projects/MomentumTrader
  • [ ] Add explicit current-state vs target-state notes to UI and API-facing documents
  • [x] Scaffold MkDocs + Material configuration
  • [x] Add docs home page
  • [x] Add documentation contributor workflow
  • [x] Add documentation style guide
  • [x] Add documentation changelog
  • [x] Add GitHub Pages workflow scaffold
  • [x] Add reusable MkDocs build prompt
  • [x] Add documentation catalog page
  • [x] Add MkDocs platform guide covering purpose, storage, versioning, build, deployment, and access
  • [x] Add GitHub Pages publishing checklist

Near Term

  • [ ] Add a landing page section for “What should I read first?”
  • [ ] Add tags or labels such as Architecture, Ops, Analytics, Release
  • [ ] Add last-updated metadata to each document
  • [ ] Add a changelog page for documentation updates

Longer Term

  • [ ] Make MkDocs the primary documentation surface
  • [ ] Publish on GitHub Pages or another free static host
  • [ ] Add richer search and versioning if needed
  • [ ] Add contributor workflow for documentation updates

3. Portal Maintenance Notes

Current portal assets: - documentation/portal/index.html - documentation/portal/styles.css - documentation/portal/app.js - documentation/portal/content.js - documentation/tools/build_docs_portal.py

Current update flow: 1. Edit Markdown in documentation/docs/ 2. Rebuild portal content with documentation/tools/build_docs_portal.py 3. Refresh the portal

4. Suggested Next Step

The best next step is:

Create a Milestone Sprint Plan for the first 2–4 weeks.

Reason: - the architecture and docs foundation are now strong - the next bottleneck is execution, not documentation structure - a sprint plan will turn the roadmap into concrete build tasks, owners, and weekly outcomes

Status: - [x] Milestone Sprint Plan created - [x] Week 1 Execution Board created - [x] Owners assigned in the execution tracker - [ ] Week 1 tasks moved to active execution

5. Secondary Next Step

After the sprint plan, the next useful improvement would be:

Assign owners and statuses in the execution tracker, start Week 1 execution, then decide whether to keep the custom local portal or move to MkDocs.

A simple decision rule: - stay on the current portal if you mainly want local searchable docs and lightweight maintenance - move to MkDocs when you want hosted docs, cleaner publishing, and a more standard documentation workflow