HTTP 模型
默认站在标准库上
保留 net/http 的心智模型，让 handler、中间件与测试方式都保持熟悉。
Standard Library First
一个尽量贴近 net/http 的 Go Web 工具包。
Plumego 是一个 stdlib-first 的 Go HTTP 工具包。它让路由、中间件、传输 contract 与应用 wiring 保持显式，而不是把关键控制流藏进框架约定里。
- Go 1.24+
- 稳定根 + x/* 扩展
- agent-friendly 仓库控制面
stable roots 收敛的公开表面
core、router、contract 等长期 API 有意保持窄边界，而不是一路长成框架能力目录。
extensions 可选能力家族
x/* 承接快速演进功能，让内核与默认学习路径保持克制。
reading path reference app → 模块边界 → 扩展家族
服务要显式，不要框架魔法。
下面每个区块都对应一个明确的工程决策：HTTP 模型保持熟悉，模块边界保持可见，仓库控制面保持可判断。
Ownership
边界保持可见
稳定根只承担窄职责，快速演进能力统一放在 x/*，不把内核做成能力目录。
Workflow
让仓库意图更容易判断
docs、specs、manifest 与 task card 分层明确，方便人和 agent 判断 ownership 并做小步改动。
稳定核心一层，能力扩展一层。
公开表面保持收敛是有意设计。稳定根承接长期 API，x/* 家族承接可选能力与快速演进功能。
稳定根
长期公开包，职责显式且边界窄。
- contract
- core
- router
- middleware
- security
- store
- health
- log
- metrics
x/* 扩展
可选能力与快速演进家族，不重定义核心学习路径。
- x/tenant
- x/fileapi
- x/messaging
- x/gateway
- x/rest
- x/websocket
- x/frontend
- x/observability
- x/resilience
- x/data
- x/ai
默认路由规则：内核与 transport 变化归稳定根；能力工作从对应的 x/* 家族开始。
先从唯一的 canonical 路径起步。
先看 reference/standard-service。它定义了 Plumego 认可的目录结构、bootstrap 流程与 route wiring 方式。
阅读参考应用说明bootstrap
先读 main.go
确认应用从哪里启动，以及 server 是怎样被组装起来的。
wiring
再看 internal/app/app.go
检查应用本地 wiring，保持依赖显式。
routes
最后看 internal/app/routes.go
在继续深入 handler 或模块之前，先看清 route 注册。
reference/standard-service/
main.go
internal/app/app.go
internal/app/routes.go
internal/handler/health.go给人看的 docs，给工具看的 specs，给执行的 tasks。
Plumego 把说明、机器可读规则与执行卡拆开，让仓库变更更容易落在明确边界内。
docs/
解释设计意图、架构与 canonical 路径。
specs/
承载机器可读的 ownership、路由与依赖规则。
tasks/
定义执行卡与 milestone 顺序，约束实际改动过程。