Product Roadmap

Product Roadmap

Where Testosterone (testo-core, CLI testo) stands today and what comes next. Open engineering debt lives in Technical Debt Tracker; the per-phase release checklists from the original plan are in the Archive.

Where it is now

One engine behind every surface. testosterone.yaml → CycleRunService → engine.run_plan() → framework adapters → reporting and persistence. The CLI, the FastAPI backend and the CI wrappers all start runs this way; the Docker-based second execution stack and its uqo run --config contract were removed after 1.0.0. See Architecture Overview.

Area	State
Frameworks	pytest, behave, behavex, plus command for any other runner with JUnit XML import (Command Adapter and JUnit Import)
CLI	testo run (Rich, --stream, --ci NDJSON), reports, diff/summary, config, doctor/clean/watch/init; exit codes 0–4 (Command Reference)
Storage	SQLite by default, PostgreSQL/MySQL through the repository layer (Repository Pattern). Docker and MinIO are not required
UI	React + Vite + Tailwind frontend on the FastAPI /api/v1 API; frontend types generated from the OpenAPI schema (Phase 5 UI Redesign). The Streamlit prototype was removed
Analytics	Dashboard, run-to-run delta with per-stage and per-test changes (Delta Comparison Policy), test pyramid, flaky test detection (Open Source Features)
AI	Bring-your-own-key failure summaries (Phase 4 BYOK and Failure Analysis)
CI	GitHub Action and GitLab template wrapping testo run --ci (CI-CD Pipeline Setup)
Demo	A Pages pipeline runs testosterone on itself and on the deliberately broken fake-api app, then publishes the React UI as a read-only snapshot (GitLab Pages Demo)
Distribution	Version 1.1.0 is cut (pyproject.toml, CHANGELOG.md) but not yet tagged or published; a GitHub Release publishes to PyPI (testo-core), GHCR (testo-runner) and, when configured, JFrog Artifactory (Publishing to PyPI § Current state)

Next

• Release v1.1.0. Tag v1.0.0 and v1.1.0, move v1, and create the GitHub Release.
• Repo allow-list for the API. testo-api binds 127.0.0.1 and can require TESTO_API_TOKEN on mutating requests; before it runs anywhere shared it also needs an allow-list of target repos.
• Parallel stages. Stages run sequentially; only BehaveX parallelizes internally. Opt-in parallel stages need isolated per-stage artifact trees and aggregated exit classification.
• Concurrent run guard. Today the only guard is the API's in-memory check that rejects a second run of the same cycle with 409 (testo_api/cycle_execution_manager.py). Two CLI runs of one cycle on one machine share artifacts/<cycle>/ and overwrite each other, and nothing stops a CI run and a local run from hitting the same deployment at once. Every run enters through CycleRunService.run(), so a guard goes there, before run_plan, without a refactor. Three levels, smallest first:
  1. A lock file per cycle under artifacts/<cycle>/: a second run on the same machine exits 3 with a clear message.
  2. A per-environment lease in the database (an environment: key on the cycle, a row with an expiry): a second run against the same environment waits or fails. Only works across machines that share one database (e.g. Postgres), not per-machine SQLite.
  3. A real run queue. That is a central service and not worth it yet.
• Smaller items (signal-aware exit codes, reporter failure policy): see Technical Debt Tracker.

How it got here

The project started as "UQO", a Docker-and-Streamlit platform, and was delivered in four phases: packaging and a database-agnostic repository layer; drop-in CI wrappers; the React UI, delta engine and unified dashboard; then BYOK AI failure analysis. Each phase had a release checklist; those checklists and the dated plans and audits behind them are kept in the Archive.

---

Generated from docs/Roadmap & Strategy/Product Roadmap.md. Edit it there; changes made in the wiki are overwritten.