Roadmap

Wagoe is at 1.0.0. This page is the public view of what is built, what is left before the public launch, and what we intend to build after it.

It is a statement of intent, not a delivery commitment. Dates are deliberately absent — the ordering is the useful part.

Where we are

Thirty-one libraries are published on Clojars under com.wagoe, versioned in lockstep. The framework is feature-complete for the applications it targets; the remaining work is about trust rather than capability.

Table 1. Built and shipping
Area	What exists
Architecture	Functional Core / Imperative Shell throughout, with `ports.clj` protocols per module, enforced in CI by dedicated boundary, dependency-direction and hexagonal-layering gates
Code generation	Scaffolder for modules, fields and endpoints — interactive, flag-driven, or from a natural-language description
Web + admin	Reitit routing, HTMX + Hiccup UI, and an auto-CRUD admin interface generated from entity configuration
Identity	Authentication, JWT, MFA, sessions, and role-based authorization
Data	next.jdbc with PostgreSQL, H2 and SQLite; migrations; multi-tenancy by schema-per-tenant; full-text search
Async	Background jobs over Redis or a durable database-backed queue, with transactional enqueue; an event bus; WebSocket real-time messaging
Integrations	Payments (Mollie, Stripe, Mock), file storage (local, S3, GCS), email over SMTP, SMS/WhatsApp, IMAP, geocoding, push notifications (FCM, APNs)
Domain libraries	Workflow state machines, reports with PDF/Excel/DOCX export, calendar with RRULE recurrence and iCal, audience segmentation
Observability	Interceptor-based metrics, logging and error reporting, with Prometheus, OTLP and Datadog providers, plus distributed tracing spans
Internationalisation	Marker-based i18n with translation catalogues and locale chains; the admin UI is fully translatable
Tooling	`wagoe` CLI, a Babashka task suite (config doctor, setup wizard, migrations, i18n scanning, deploy), framework-aware AI helpers, and an MCP server for editor agents

Shipped in 1.0

Work that earlier drafts of this page listed as future. It is done, in main, and covered by tests.

Scaling out

Wagoe scales vertically through configuration, and the ports.clj seam is what makes scaling out tractable: swap an in-process adapter for a distributed one without touching business logic.

Generic remote-port adapter + RPC envelope — any module protocol can be implemented by a call to another process, built from the protocol’s own signatures, with correlation-id, tenant and auth riding the headers the interceptor pipeline already uses.
Service launch mode — java -jar wagoe.jar service <module>… boots a named subset of modules as its own service, with its RPC endpoint on its own port.
Event-bus port + adapter — wagoe-events, with a Redis Streams adapter (at-least-once, consumer groups) and an in-process one.
Break allowlisted dependency cycles — no module pair is blocked from separation by a cycle any more; bb check:deps now fails on any cycle at all.
Realtime Redis pub/sub adapter, graceful connection draining, default rate-limit wiring, jobs hardening and a deploy topology reference — the replica-safety work.

What is still missing for full functional decomposition — service discovery and the data-ownership decision — and the readiness matrix behind all of the above, are in Sizing & Scaling. That page is the source of truth for what scales; this one does not restate it.

Stability surface

The stability policy defines what is public, what is internal, how deprecations work, and which libraries are incubating rather than covered by the 1.0 promise.

The road to 1.0.0

1.0.0 means the API is one we are willing to be held to. What is left is about earning that, not adding surface.

1. The release gate — done

One JDK baseline, one provider vocabulary, jars that cannot ship stale classes, a version scheme in which a pre-release can never outrank a release, library tiers, and a frozen changelog carrying an explicit decision on every open breaking change. 1.0.0 ships no surprise.

2. A release candidate that is actually exercised — done

Four candidates, 1.0.0-rc-1 to 1.0.0-rc-4, shipped before the tag. Of the twenty-five breaking changes they turned up, twenty-two landed in a candidate and were exercised there; the last three landed in 1.0.0 itself.

3. First-run experience

The bulk of this has landed: install.sh with prerequisite detection, a wagoe new scaffold that produces a project which boots, a setup wizard needing no external services, automatic migrations, seed data, a production build path, and a CI smoke test that walks install → new project → serving app inside a bare container and asserts on HTTP rather than exit codes.

What remains is deliberate QA: the same path exercised across an environment matrix and by people who did not write it. This gates the public launch rather than the tag — a framework gets one first impression.

After 1.0.0

Grouped by the release they would ship in. 1.x work keeps the stability promise; 2.0 is where the things that cannot are collected.

1.1 — Enterprise login and correctness

OIDC / OAuth2 login (authorization code + PKCE)
A transactional outbox, so publishing an event is decoupled from the database transaction that produced it
A decision on multi-tenancy: PostgreSQL-only, or row-level tenancy as an adapter capability
Dependency vulnerability scanning and coverage actually running in CI

1.2 — Contracts

A database-adapter port with a conformance suite across all four adapters
A PSP conformance sweep, finishing the Mollie adapter
wagoe-external sharing the retry and circuit breaker of the RPC client
Finishing the metrics and error-reporting stubs, or removing them and correcting the documentation

1.3 — Batteries

Recurring and cron-scheduled jobs, with an idempotency-key store
Server-driven per-field form validation from Malli schemas
A #secret config reader with pluggable backends (env, file, vault, SOPS)
OpenAPI 3.1 instead of Swagger 2.0
A realtime-to-UI bridge: SSE plus out-of-band fragment responses
A test kit for consumer applications — test system, test tenant, Ring client, job draining
Outbound webhooks: signed, retried, per-tenant
GDPR data export per user and per tenant, and retention policies

Ongoing through 1.x

Component gaps in the shared UI library — dialog, combobox, toast region, sortable tables
wagoe upgrade: a codemod for deprecated config keys, requires and functions. This ships before the first 2.0 pre-release, not after it
A showcase application and a migration guide for people arriving from Kit or Luminus

2.0

Removing the deprecated provider aliases and the duplicate choices that 1.x deprecates — one HTTP client, one config layer, one CSS system, one mail library
Virtual threads for request handling and the jobs worker pool
A decision on the front-end stack

How this page is maintained

This roadmap is the only one. It is reviewed alongside each release; work is tracked on GitHub, and the shipped detail of every release is in CHANGELOG.md.

A CI gate (bb check:roadmap) fails the build if this page plans something Sizing & Scaling already marks as shipped, which is how the three-way contradiction it replaced went unnoticed for months.

If something here matters to you, saying so is the most effective way to move it up the list.