稳定根

稳定根是仓库根部那些长期公开的包。它们定义了默认学习路径，承接 Plumego 希望长期保留的最窄公共契约，也为规范应用路径提供稳定支点。

同步稳定根事实

从 `specs/repo.yaml` 与 `specs/task-routing.yaml` 同步

9 稳定根

从 `specs/repo.yaml` 与 `specs/task-routing.yaml` 同步

Change kernel, lifecycle, route structure, transport contracts, transport middleware, auth primitives, or storage primitives.

这些事实块来自仓库 machine-readable specs，而不是 docs 中手工复制的列表。

只有当改动属于 Plumego 希望每个维护者都理解的默认服务路径时，稳定根才是正确归属。

通常来说，这类改动会落在四种事情上：

只要改动开始需要能力策略、租户感知分支、拓扑较重的行为，或者能力家族级发现入口，它就已经在越过稳定根契约。

在你把改动放进稳定根之前，先问自己三个问题。

只要答案开始变成“只对某些能力成立”或“只有特定产品策略开启时才成立”，更安全的归属通常就是某个对应的 x/* 家族，而不是继续拉伸稳定根。

当前仓库已经给出了足够具体的模块级边界，可以直接拿来判断。

稳定根	适合留在这里的工作	一旦变成这些问题就应移出
`core`	应用构造、路由挂载、middleware attachment，以及 `Prepare` / `Server` / `Shutdown` 生命周期	feature catalog、tenant policy、debug metadata 或能力特定运行时行为
`middleware`	request ID、tracing hook、access log、auth/security transport 适配器、HTTP metrics 这类传输层wrapper	tenant resolution、quota policy、API version negotiation 或协议 / payload 适配
`store`	`store/file`、`store/kv`、`store/idempotency`、`store/cache` 这类窄持久化契约与基础抽象	拓扑较重的 cache engine、租户感知适配器、signed URL、文件元数据管理、SQL/provider policy 或 HTTP-facing caching

这些不是抽象的风格偏好，而是当前仓库已经写出来的实际归属边界。

一旦你已经确认改动仍属于稳定表面，就不要停留在概念层，而应继续进入对应模块的 primer。

如果工作主要触及	下一步打开的 primer	为什么这里是更合适的下一跳
lifecycle、显式应用构造、logger injection 与路由挂载	Core Primer	它会把稳定根规则继续落到 `core` 的实际生命周期与内核边界
transport wrapper、request ID、tracing hook、access logging、auth/security HTTP适配器与 rate-limit适配器	Middleware Primer	它会继续说明哪些仍然属于传输层，哪些必须移动到 `x/tenant`、`x/rest` 或 `x/gateway`
文件 contract、cache primitive、KV helper、幂等合约与 DB helper 边界	Store Primer	它给出了稳定持久化原语与 `x/data`、`x/data/cache`、`x/fileapi`、`x/tenant` 之间最清楚的具体拆分

几个反复出现的例子会让判断更清楚。

在 core 中，显式应用构造与单一路径生命周期应该保留在稳定层，但 debug snapshot 应进入 x/observability/devtools，feature-specific wiring 应留在应用本地代码或扩展层。
在 middleware 中，request ID、tracing hook、access logging 与 HTTP metrics 仍然属于稳定层，因为它们依旧是传输层。API version negotiation 应移动到 x/rest/versioning，协议适配应移动到 x/gateway/*。
在 store/file 中，共享文件 contract 与错误类型留在稳定层，但租户感知 storage backend 与 metadata persistence 应移动到 x/data/file，而 upload/download HTTP endpoint 应移动到 x/fileapi。
在 store/cache 中，基础 cache primitive 留在稳定层，但 distributed cache 行为应移动到 x/data/cache，HTTP response caching 应移动到 x/gateway/cache，租户感知 cache适配器应移动到 x/tenant/store/cache。

很多读者会因为某个改动“看起来很基础”，就误以为它应该属于稳定根。当前仓库其实明确反对这种判断方式。

更关键的问题是：实现完成之后，这段行为是否仍然保持窄边界、默认路径属性，以及 capability-agnostic 特征。

一旦某个稳定根候选开始学习扩展语义，就不要继续拉伸根目录，而应转去对应的归属目的地。