Repository Direction

路线图

Plumego 当前在补什么、下一步做什么，以及明确不做什么。

文档状态

怎么阅读这份路线图。

路线图不是在暗示所有包会以同样速度推进。它要说明的是：哪些已经属于默认基线，哪些正在补强，哪些仍然只是方向而不是兼容性承诺。

baseline

先看基线

基线说明哪些东西已经构成默认 Plumego 路径，不应该从计划项里反向推断。

focus

进行中才代表近期真实信号

如果某个方向处于进行中，说明它正在被主动补强。计划中的内容是方向，不是兼容性保证。

non-goals

把非目标当作架构边界

非目标和路线图本身一样重要，因为它们约束仓库不要重新滑回隐藏兼容层。

当前方向

下面这些分组由仓库事实同步而来，这里再补一层解释，帮助读者分清哪些是已建立基线、哪些是当前工作、哪些仍是后续范围。

baseline

当前基线

这里描述的是读者默认应该先假定成立的 Plumego 路径。它已经属于仓库基线，而不是未来才会兑现的愿景。

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

进行中

这些方向正在被主动补强，是近期最值得关注的真实信号；但在扩大采用范围前，仍然应该和发布姿态一起阅读。

Phase 16: Active Extension Evaluations

planned

计划中

计划中的工作表达的是方向与顺序压力，而不是当前兼容性承诺，不应被误读成已经纳入基线。

non-goals

明确不做

这些边界是刻意保留下来的。它们用来防止仓库重新滑回隐藏兼容层和过度膨胀的稳定根。

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

设计原则

无论当前哪些阶段处于活跃状态，这些约束始终保持不变。它们解释了路线图为何如此构造，以及哪些取舍是不可谈判的。

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.

建议执行顺序

当多条工作线同时存在时，这个顺序表达的是优先收敛方向，而不是精确发布时间承诺。

执行检查点

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

执行检查点

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

执行检查点

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

执行检查点

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

执行检查点

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

执行检查点

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

执行检查点

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

怎样把路线图纳入采用判断

路线图说明方向，发布姿态说明今天哪些区域真正可以采用，docs 与 reference app 则负责让 canonical path 在仓库继续外扩时仍然保持主线地位。

adopt today

路线图负责解释方向，不负责替代发布姿态

如果你的问题是“今天哪些区域真正值得信任”，应当先看发布页。路线图说明的是接下来哪里会被继续收紧，哪些区域仍然被刻意设为门控状态。

查看发布页

理解方向之后，回到 reference path

一旦路线图告诉你仓库将往哪里走，就应该回到 docs 与 reference app，保持默认路径始终是主线。

打开参考应用

for contributors

当多条工作线并行时，用执行顺序判断先收紧什么

建议执行顺序表达的是开放工作该按什么节奏收敛，而不是一张发布时间表；它仍然是判断“下一步先稳定哪里”的最好线索。

阅读发布姿态