Repository Direction

Roadmap

What Plumego is hardening now, what comes next, and what stays out of scope.

How to read the roadmap.

The roadmap is not a promise that every package moves at the same speed. It explains what is already treated as baseline, which areas are being hardened now, and which ambitions are still gated by policy, tests, and documentation.

baseline

Read the baseline first

The baseline tells you what already defines the default Plumego path and should not be inferred from planned work.

focus

Use in-progress work as the real near-term signal

If an area is in progress, it is receiving active attention now. Planned work is directional, not a compatibility statement.

non-goals

Treat non-goals as architectural boundaries

The non-goals are as important as the roadmap itself because they prevent the repo from drifting back into hidden compatibility layers.

Current direction

These sections are synchronized from the repository facts, then framed here so a reader can distinguish established baseline, active work, and deferred scope.

baseline

Current baseline

This is the default Plumego path that readers should assume first. It is already part of the repository baseline rather than future aspiration.

stable roots with explicit boundaries: `core`, `router`, `contract`, `middleware`, `security`, `store`, `health`, `log`, `metrics`
extension discovery and task-routing metadata under `specs/*`
a single canonical application layout in `reference/standard-service`
milestone, plan, card, and verify workflow assets under `tasks/*`
repo-wide quality gates in `Makefile` and `.github/workflows/quality-gates.yml`
stable-root compatibility policy in `docs/reference/deprecation.md`
stable-root exported API baseline snapshots under `docs/evidence/stable-api/snapshots`
release evidence checklist under `docs/release/PRE_V1_RELEASE_CHECKLIST.md`
beta promotion checklist and card template under `docs/release/PROMOTION_CARD_TEMPLATE.md`
`x/rest`, `x/websocket`, `x/gateway`, and `x/observability` promoted to `beta`
`v1.0.0` tagged on May 15, 2026; release notes and evidence in `docs/release/v1.0.0.md`

in progress

In progress

These areas are receiving active attention now. They are the clearest near-term signal, but they should still be read together with module maturity before adoption decisions widen.

Phase 16: Active Extension Evaluations

non-goals

Non-goals

These boundaries are deliberate. They protect the repository from drifting back toward hidden compatibility layers and overloaded stable roots.

reintroduce component-style compatibility APIs
add new broad legacy roots for short-term convenience
let scenario reference apps replace the canonical app path
move tenant or topology-heavy logic back into stable roots
leave stale historical drafts inside the active docs surface
mark `x/*` packages as GA without explicit policy, tests, and docs

Design principles

These constraints stay fixed regardless of what phases are active. They explain why the roadmap looks the way it does and which trade-offs are non-negotiable.

Keep `core` as a kernel, not a feature catalog.
Preserve `net/http` compatibility and explicit control flow.
Keep one canonical entrypoint per capability family.
Let `specs/*` and module manifests carry machine-readable authority.
Document only implemented behavior; remove stale drafts instead of preserving them in the active docs surface.

Suggested execution order

When multiple lines of work are open, this sequence shows the intended tightening order rather than a guarantee of exact release timing.

Execution checkpoint

Keep Phase 13 and Phase 15 docs and onboarding sync continuous.

Execution checkpoint

Keep `docs/concepts/extension-maturity.md` aligned with module manifests and evidence records.

Execution checkpoint

Execute task card 1500 (x/tenant GA evaluation) once v1.2.0 release evidence is available.

Execution checkpoint

Execute task card 1501 (x/ai stable-tier subpackages beta evaluation) per-subpackage after release evidence.

Execution checkpoint

Execute task card 1502 (x/openapi module.yaml cleanup and beta evaluation) once release evidence is available.

Execution checkpoint

Clarify `x/data` and `x/fileapi` operational guidance.

Execution checkpoint

Expand `x/gateway/discovery` backends only when explicit adapters are ready.

How to use roadmap in an adoption decision

Roadmap shows direction. Release posture tells you what can actually be adopted today. Docs and the reference app keep the canonical path primary even while the repository grows outward.

adopt today

Use the roadmap to understand direction, not to replace module maturity checks

If your question is about what can be trusted now, the release page should lead. The roadmap tells you what is tightening next and which areas remain intentionally gated.

Inspect releases

Return to the reference path after understanding direction

Once the roadmap explains where the repository is heading, go back to docs and the reference app so the default path stays primary.

Open the reference app

for contributors

Use the execution order when multiple lines are open at once

The suggested sequence is the tightening order for open work. It is not a release calendar, but it is the best clue for what should stabilize first.

Read module maturity