OSS & Maintainers
FactorForge is maintained as a reusable research workbench: deterministic quant engines, visible data provenance, safe public demo defaults, and contributor workflows that make review, testing, release notes, and security checks easier.
Safe demo
No live order execution, no live trading, no required market-data or LLM key. Optional read-only Alpaca paper mirror for local paper-account sync.
Reviewable engines
Numbers come from code paths covered by tests; prose is labeled as template or LLM.
Contributor path
Issue templates, PR checklist, contributing guide, roadmap, and maintainer backlog.
Release hygiene
Manual release checklist, changelog expectations, and CI gates before tagging.
The project turns the common quant-research workflow into an inspectable app: data source status, factor definitions, strategy rules, cost-aware backtests, portfolio risk, paper observation, and generated research memos sit in one place. It is intentionally research software, not a trading system.
- • Quant researchers who can improve assumptions, fixtures, edge-case tests, and methodology notes.
- • Frontend contributors who can improve dense dashboards, search, accessibility, and mobile ergonomics.
- • Documentation contributors who can keep setup, Vercel deployment, security notes, and release checklists current.
- • Security-minded reviewers who can inspect auth/session boundaries, env validation, rate limits, and logging.
- • Backtest edge-case tests for next-open execution, fees, stops, and uneven calendars.
- • Provider fallback tests for Yahoo, Polygon, Alpha Vantage, and deterministic fallback data.
- • Documentation drift fixes between the UI, README, environment examples, and release notes.
- • Accessibility and keyboard navigation improvements for dense research pages.
- • Portfolio export options and clearer reporting around benchmark assumptions.
- • Route-level search, command palette, and discoverability improvements.
- • CI runs lint, typecheck, and tests on pushes and pull requests targeting main.
- • PR review starts with deterministic metric integrity, then data provenance labels, fallback disclosure, tests, and docs drift.
- • Issue triage asks for route, provider/fallback status, reproduction steps, expected/actual behavior, and redacted env context.
- • Releases are manual: update changelog, run the release checklist, verify Vercel-safe env behavior, then tag.
- • Generate edge-case tests for backtest math.
- • Review PRs touching quant logic, auth/session handling, provider fallback, and environment validation.
- • Draft release notes from merged changes.
- • Create issue triage and reproduction checklists.
- • Identify documentation drift between UI, README, and code.
- • Help maintain provider adapter tests.
- • Support security review for headers, session handling, rate limits, and secrets.
Security and safety boundaries
- No brokerage credentials should be added for trading: the only broker touchpoint is an optional read-only Alpaca paper mirror (GET-only account/positions/orders), and there is no order-submission path.
- No order routing, real-money account state, or financial-advice workflow is in scope.
- Security-sensitive reviews cover auth/session handling, bcrypt validation, rate limits, CSP, provider keys, the Alpaca paper credentials, LLM payloads, and secret logging.
- Optional provider, broker, and LLM keys must stay server-side; do not prefix them with NEXT_PUBLIC_.
- Public demo account features are limited to saved research preferences and watchlists.
- Fallback/demo data and template memos must remain labeled wherever they appear.
Current work focuses on better extension points, provider test coverage, release automation, export options, route-level search, accessibility, and more strategy edge-case tests. The backlog is scoped as future maintainer issues, not adoption claims.