Roadmap
One road: the chapters already delivered, the next twelve months, and the horizon beyond them.
Where SDODS stands today, what the delivered work bought you, what lands month by month over the next year, and which of it is a promise rather than a direction.
The road
Every stop on this road has a goal, the things that land there, and the one fact that tells you it landed. Click a checkpoint to stand at it — Maxi will say why it is on the road at all. The stretch behind the traveller is delivered, the twelve amber and indigo stops are the next year, and the faint ones at the end are direction rather than dated commitment.
In progressJan 20279 / 20
A suite that runs with the network unplugged
Third-party sandboxes stop deciding whether your build is green.
What ships
- HAR fixtures per scenario for the sanity and user-pool suites
- Recording refreshed on demand, with the diff visible in review
- --har-replay --strict as the default in CI
You will know it landed when. The full demo suite passes with outbound network disabled.
Why the delivered stretch has no dates
The five chapters behind the traveller are real: the code is in the repository and the commands in
these pages run against it. They carry no month labels because they were built before SDODS had a
release to date them against. The repository's history starts on 3 September 2026 and the chapters
landed inside those first days, so a month against each one would say little and could not be
checked. SDODS is released now: @sdods/* is published to npm, each version has a GitHub release,
and the server ships as a container image on GHCR. Dates start with those versions; the chapters
that came before them stay undated rather than get a date nobody can verify.
Every checkpoint, in order
The road behind
Five chapters, already delivered. They carry no dates: they were built before the first release, in a repository whose history begins on 3 September 2026, so a month against each one would be a number nobody could check.
Chapter 1 · phases 0, 1
Foundations — One command runs a scenario
A test suite that a new machine can run without a page of setup instructions.
- A monorepo with contracts, runtime and CLI, one project per application
- Six-layer configuration precedence that can say where every value came from
- The organization → workspace → project → module hierarchy and named processes
- The API step library: requests, JSON-path assertions, schemas, variable chaining
Proof. sdods run -p demo-shop -e staging -l api goes green with no browser installed.
Chapter 2 · phases 2, 3, 4
The browser — A UI failure explains itself
When a browser test fails, the report already contains what you would have asked for.
- Page objects with step decorators and heal-aware locators
- Self-healing that records which strategy found the element and why
- Before and after screenshots for every step, with a pixel diff
- Data providers, the leased user pool, captured auth and hybrid scenarios
Proof. A failed step in the run viewer shows the two screenshots either side of it.
Chapter 3 · phases 5, 6
Memory — Runs stop depending on one laptop
History that outlives the terminal window the run happened in.
- One schema on SQLite or Postgres, switchable with a flag, with migrations
- Result ingest from cucumber JSON, NDJSON and runner JSON, and insights over it
- The recorder: capture a flow, replay it, convert it to a feature
- HAR record and replay for UI and API, so a suite can run offline
Proof. The same run appears in the dashboard whichever machine produced it.
Chapter 4 · phases 7, 8
Agents — The suite becomes something an agent can read
An assistant can plan, generate and repair tests against your project, not a generic one.
- An MCP server exposing projects, features, steps, runs and results as tools
- Five agent roles — planner, generator, healer, upgrader, reviewer
- A provider-agnostic adapter, including models that run on your own machine
- Proposals: an agent writes, a person accepts, nothing edits the tree unasked
Proof. sdods mcp install claude, then ask an assistant what a project covers.
Chapter 5 · phases 9, 10, 11, 12, 13
A platform — A team, not a script
Everything a group of people needs around the runner, rather than around one engineer.
- A server with REST, live run streaming, MCP over HTTP and a scheduler
- A web UI: dashboards, run comparison, a Gherkin editor, agents, schedules
- GitHub checks and issues, Jira issues and links, CI workflows
- Onboarding analysis that reads an existing app, and the cross-browser matrix
- This documentation site, packaging and sdods init
Proof. A second person can open the web UI and read yesterday’s run without asking you.
The next twelve months
Close enough to promise, and ordered by what the one before it makes possible. A month marked delivered lists what actually landed, and its proof is a command you can run today.
Oct 2026
Oct 2026 — Every claim on this site is true
No page describes a feature that does not run. Trust is the product.
- @a11y audits the page each tagged scenario ends on with axe-core, failing at a configurable impact
- @perf compares page vitals and live API p95 with the configured budgets when the scenario ends
- sdods run --process evaluates minPassRate, maxFlaky, a11y and perfBudgets, and exits GATE_FAILED on a breach
- Known limitations re-checked line by line against the code, with the stale rows removed
- One source of truth for this roadmap, shared by the docs, the site and the README
Proof. sdods run -p demo-shop -e staging -l ui -b chromium -t "@a11y or @perf" --process release-gate passes every gate, and a deliberate breach fails it.
Nov 2026
Nov 2026 — A first real release
Install SDODS the way you install anything else.
- Versions bumped through changesets, with a git tag per published package
- The @sdods packages published to npm
- A GitHub release per version, with notes generated from the changesets
- A server image on GHCR, built and pushed by the release workflow
Proof. npm view @sdods/cli version answers, and the installer installs from npm without a git checkout.
Dec 2026
Dec 2026 — CI and your laptop agree about a screenshot
Visual tests stop being the suite everyone disables.
- Baselines kept per platform, with the linux/ set rendered by the visual-baselines workflow in the pinned Playwright image
- sdods baselines diff and accept, and Accept as baseline in the web UI, so a person reviews the diff before it becomes the baseline
- Masks and a diff threshold per baseline, and a step that masks inline
Proof. The @visual suite passes on ubuntu inside the Playwright image from committed linux/ baselines, and on macOS from darwin/ ones.
Jan 2027
Jan 2027 — A suite that runs with the network unplugged
Third-party sandboxes stop deciding whether your build is green.
- HAR fixtures per scenario for the sanity and user-pool suites
- Recording refreshed on demand, with the diff visible in review
- --har-replay --strict as the default in CI
Landed when. The full demo suite passes with outbound network disabled.
Feb 2027
Feb 2027 — Flake becomes a number, not an argument
A flaky test is measured and budgeted rather than retried in silence.
- Flake budgets per suite, computed from run history
- Automatic quarantine when a scenario exceeds its budget, with an owner
- A weekly digest naming what got worse and what recovered
Landed when. The dashboard answers “which tests cost us the most time this week”.
Mar 2027
Mar 2027 — One sign-in for the whole team
People reach their runs with the account they already have.
- OIDC single sign-on for the web UI, mapped onto the existing roles
- Tokens scoped to a workspace, revocable from the UI
- An audit line for who looked at what
Landed when. A new joiner opens the dashboard without anyone creating an account for them.
Apr 2027
Apr 2027 — History leaves the laptop
One history the whole team reads, so no one relitigates a failure.
- Hosted run history with retention you choose
- Ingest from CI as a first-class path, not an afterthought
- Comparison across branches and environments
Landed when. Two people looking at the same failure see the same evidence.
May 2027
May 2027 — Runs that know what changed
A pull request runs the tests that its diff can break, and finishes sooner.
- Change-aware selection from the diff, routes and page objects touched
- Scheduled runs that fill in whatever selection skipped
- A stated rule for when the full matrix runs anyway
Landed when. Pull-request feedback lands in minutes without losing a regression.
Jun 2027
Jun 2027 — Agents open pull requests
Locator drift arrives as a reviewable change rather than a red build.
- The healer opens a pull request carrying its heal history as evidence
- A confidence threshold under which it asks instead of proposing
- The same flow on a model running on your own hardware
Landed when. A renamed test id is fixed and merged without anyone writing a selector.
Jul 2027
Jul 2027 — One incident is one item
Forty failures with one cause stop looking like forty problems.
- Failure clustering by cause across a run and across runs
- A first-failure summary that names the shared step or request
- Links from the cluster to every scenario inside it
Landed when. A broken login shows as one item with thirty-nine scenarios attached.
Aug 2027
Aug 2027 — Coverage measured against reality
You learn which journeys real users take that no scenario covers.
- Real traffic compared against covered journeys, with the gaps ranked
- Suggested scenarios for the gaps, as proposals a person accepts
- Coverage reported per business capability, not per file
Landed when. The coverage report names a journey nobody had thought to test.
Sep 2027
Sep 2027 — 1.0, with a promise attached
You can build on SDODS without expecting it to move under you.
- A stable 1.0 of the CLI surface and the run format
- A written compatibility promise and a deprecation policy
- A migration path from every 0.x release
Landed when. A suite written today still runs unchanged on the next minor version.
The horizon
Direction rather than dated commitment. Feature requests move these.
The 2028 horizon
2028 — The suite repairs itself and says what it changed
Maintenance stops being the reason automation gets abandoned.
- Agents open pull requests for drift, with the heal history as evidence
- Coverage gaps found by comparing real traffic against covered journeys
- Test data synthesised per environment, sensitive fields never leaving it
- Failures clustered by cause, so one incident is one item
- Scenarios suggested from a change set, ranked by the risk they cover
Landed when. Most locator drift is fixed and merged without anyone writing a selector.
The 2029 horizon
2029 — Checks, approvals and the release in one place
Confidence is not only tests: it is who approved, and on what evidence.
- Release gates that read the evidence and hold or pass a deployment
- Approvals recorded against the run that justified them
- Event-driven workflows across environments, data and deployments
- Environment provisioning hooks, so a suite can create what it needs
- Connectors for the trackers, chat tools and pipelines already in use
Landed when. The release gate becomes the record teams point at when asked why they shipped.
The 2030 horizon
2030 — An audit trail the people who sign off actually trust
A regulated team can show the chain from requirement to release, complete.
- Policy as code: tagging, coverage and approval rules enforced at run time
- Federation across organisations, with retention and residency controls
- Evidence export shaped for auditors rather than for engineers
- Private and on-premises agent runtimes for regulated environments
- A signed trail from requirement through run to release
Landed when. An auditor follows one requirement to one release without asking a human.
How the delivered work is verified
| Check | Result | Measured |
|---|---|---|
Unit and CLI end-to-end tests bun run testMeasured in the ci workflow, run 34926681357, job lint · typecheck · unit. | 1391 passed, 1 skipped | 2026-09-15 |
Web UI component tests cd packages/web && npx vitest runMeasured in the ci workflow, run 34926681357, job web · build · unit. | 15 passed | 2026-09-15 |
Demo API layer, no browser bun run demo:apiCI runs the same command with --har-replay --strict, run 34926681357. | 10 passed, 0 failed | 2026-09-15 |
Types, lint and formatting bun run typecheck && bun run lintLint reports 0 errors and 13 warnings. | clean | 2026-09-15 |
Linux visual, accessibility and performance suites sdods run -p demo-shop -e staging -l ui -b <browser> -t @regressionThe regression job in the Playwright image, from committed linux/ baselines, run 34926681357. @perf skips webkit, which has no LCP. | @regression green on chromium, firefox and webkit | 2026-09-15 |
Documentation build bun run docs:buildMeasured in the docs workflow, run 34925639854. Counts generated pages in out/. | 4434 internal links across 100 pages, 0 broken | 2026-09-15 |
Moving the road
The twelve months are shaped by what people ask for. The feature request
link on any page moves an item up, and
the open gaps are listed on Known limitations. The phase-level
detail behind the delivered chapters, including the verification commands, lives in
docs/ARCHITECTURE.md; the same five-year ladder is told for a non-technical reader on the
roadmap page.