Files
OmniRoute/docs/ROADMAP.md
Diego Rodrigues de Sa e Souza 04683029a6 fix(build): exec native esbuild binary directly in prepublish (dast-smoke base-red) (#9558)
* fix(build): exec native tool binaries directly in runBuildTool

#8858 routed every resolved local bin through process.execPath to avoid
Windows .cmd shims — but esbuild >=0.25 ships bin/esbuild as the NATIVE
platform executable (ELF on Linux), so Node parsed machine code as JS and
build:cli died with 'SyntaxError: Invalid or unexpected token', turning
dast-smoke red for every PR.

runBuildTool now sniffs the entry's magic bytes (ELF / Mach-O / PE) and
execs native binaries directly; JS entries keep going through this Node
binary (the .cmd-shim avoidance #8858 wanted).

Validation (RED->GREEN on this box):
- RED: node node_modules/esbuild/bin/esbuild --version -> SyntaxError (ELF)
- GREEN: the exact failing CI step reproduced via the new logic bundles
  open-sse/mcp-server/server.ts successfully (4.2MB output, 1.3s).

* fix(docs): add MDX frontmatter to the 20 remaining docs without it

Same failure class as AGENTROUTER_WAF (#9503) and DOCKER_RELEASE_CHANNELS
(this run's dast-smoke red): any doc without frontmatter breaks the
fumadocs MDX loader during next build, killing build:cli/dast-smoke for
every PR. Swept ALL of docs/ (i18n mirrors excluded) in one pass so this
class cannot recur one file at a time.

* docs(env): document OMNIROUTE_INTERNAL_SERVICE_TOKEN(+_FILE), OPENROUTER_PROVIDER_STATS_* and embedded-Redis binding vars

Pre-existing env/docs contract drift from recently merged features made
check:env-doc-sync red for any docs-touching PR. Values and defaults read
from the defining modules (internalServiceAuth.ts, openrouterProviderStats.ts).

* fix(build): resolve bundled npm-cli.js in the standard Unix layout + safe npm fallback off-Windows

The opencode-plugin step hard-failed on GitHub runners because
resolveBundledNpmEntry only looked next to the node binary (Windows zip
layout); hostedtoolcache Node keeps npm at <prefix>/lib/node_modules/npm.
Added that candidate, and when neither exists on non-Windows the step now
falls back to plain 'npm' — the .cmd-shim hazard #8858 avoids is
Windows-only.

* test(mutation): register xai-agent-tools-passthrough.test.ts in stryker tap.testFiles

The test landed on release/v3.8.50 covering
open-sse/handlers/chatCore/passthroughHelpers.ts without the stryker
registration, so Fast Quality Gates' drift detection reds any PR that
carries it. Mechanical registration so its mutant kills count.

---------

Co-authored-by: diegosouzapw <diegosouzapw@users.noreply.github.com>
2026-08-06 02:19:57 -03:00

4.9 KiB

title, version, lastUpdated
title version lastUpdated
OmniRoute Roadmap 3.8.50 2026-08-06

OmniRoute Roadmap

Version-gated, not date-gated: each milestone ships when its quality gates pass. Current line: v3.8.x (this branch). Last updated: 2026-07-23.

OmniRoute is heading from a monolithic router to a modular AI platform: a lightweight core engine, a typed SDK, and everything else as installable modules and plugins. The path runs through a stabilization rail (3.8.50 → 3.8.59), an LTS anchor (3.9.0), and the modular 4.0.

The rail at a glance

3.8.50 ─ 3.8.54   PREPARE   non-breaking structural prep (all PRs welcome)
3.8.55 ─ 3.8.59   VALIDATE  stabilization (fixes / docs / i18n / providers only)
3.9.0             LTS       stable/v3 branch · long-term support line
4.0.0-nightly/rc  MODULAR   core + SDK + modules + marketplace (develop branch)
4.0.0             GA        latest switches to v4 · v3 stays supported as LTS

Phase 1 — Preparation (3.8.50 → 3.8.54)

Non-breaking structural work that de-risks the modular split. Every version closes with a mandatory quality-gate battery before new merges open.

Version Focus
3.8.50 CI safety net on release branches · dead-code cleanup · community-reported catalog/topology bug fixes · contributor "golden path" guide
3.8.51 Executor registry (in-place) · end-to-end provider-journey contract test becomes a CI gate · official scoped-test dev loop · CI lane consolidation (shared install/setup across gate jobs, #8084)
3.8.52 combo.ts decomposition · routing-strategy registry · unified model-catalog contract for /v1/models · one CI policy for PRs to release/** and main (#8084)
3.8.53 chatCore.ts decomposition · headless mode (OMNIROUTE_HEADLESS=1) · local candidate build/promote loop
3.8.54 Release infrastructure (dormant): channels, labels, PR templates, merge queue · full-regression authority moves to the merge queue once TIA shadow evidence clears (#8084) · public feature-freeze announcement

Phase 2 — Validation (3.8.55 → 3.8.59)

External feature PRs pause here (they get the v4-feature label and are re-targeted to the v4 channel when it opens). Fixes, docs, i18n, and provider updates keep flowing.

Version Focus
3.8.55 Characterization tests for every extraction candidate · coupling re-measurement
3.8.56 Extended canary · performance baselines (heap, TTFB, build)
3.8.57 Security & compliance sweep · publish provenance (OIDC) rehearsal
3.8.58 Full dry-run of the 3.9.0 cut (branches, channels, forward-port) — includes the PR preview-artifact + build-once promotion rehearsal (#8084)
3.8.59 Final freeze · full-suite audit · GO/NO-GO

Phase 3 — v3.9.0 LTS

After 3.8.59 the next version is 3.9.0 (there is no 3.8.60). It creates the long-lived branch model:

  • stable/v3 — the LTS line (3.9.x). Receives fixes, security patches, and provider updates. npm install omniroute (aka latest) stays on v3 during the whole v4 cycle.
  • develop — v4 development, published as 4.0.0-nightly.*.
  • main — v4 release candidates (next) and, eventually, GA.
  • Fixes merged to stable/v3 are automatically forward-ported to develop with full contributor credit (Co-authored-by).

New features land in the v4 channel. The LTS line is stability-first.

Phase 4 — v4.0: the modular platform

The monolith is intentionally disassembled on develop:

  • @omniroute/core (npm name stays omniroute) — just the engine: /v1/*, routing, combo/fallback, providers.
  • @omniroute/sdk — one typed contract: hooks, extension points, two-phase lifecycle, UI contributions. The five extension systems that exist today (plugins, CLI plugins, skills, MCP tools, A2A skills) collapse into one declarative manifest.
  • Modules (@omniroute/mod-*) — cloud agents, traffic inspection (MITM), evals, webhooks, memory, guardrails, observability and more move out of the core, each with its own version and lifecycle.
  • Providers as plugins — adding a provider stops touching the core.
  • Marketplace — one-click install with verified integrity (hash pinning, signing, sandbox). Free in v1; a paid tier later with revenue share for creators.
  • Ships as 4.0.0-nightly.*4.0.0-rc.N (soak in production) → 4.0.0 GA, when latest switches to v4 and v3 enters its announced LTS support window.

The core is MIT and free, forever.

For contributors

You are sending... Target today From 3.8.55 After 3.9.0
Bug fix / security active release/v3.8.x same stable/v3
Provider update active release/v3.8.x same stable/v3
Docs / i18n active release/v3.8.x same stable/v3
New feature active release/v3.8.x held with v4-feature label develop (v4)

See CONTRIBUTING.md for the golden path per change type.