Evaluate, then implement
If fit is still unclear, go back to Why Plumego. If the decision is already made, continue from docs home into the implementation path.
Docs Home
Docs Home
Section titled “Docs Home”Plumego is a stdlib-first Go web toolkit for building explicit, auditable HTTP services. It keeps net/http handler signatures unchanged, provides a structured error and response contract, and organizes capabilities into a stable core plus optional extension families.
What “stdlib-first” means in practice: your handlers are plain func(http.ResponseWriter, *http.Request). They work with Plumego, with http.ServeMux, and in any test that imports net/http/httptest — no framework types to unwrap.
v1.0.0: Stable root APIs carry the v1 compatibility promise.
x/*families remain labeled by maturity and should be adopted according to the support matrix.
Where are you?
Section titled “Where are you?”Just evaluating — not sure if Plumego fits yet? → Read Why Plumego first (fit check, comparison with Gin/Echo/Chi). Then run Getting Started to verify the code shape feels right.
Ready to implement — evaluation done, starting a service? → Open Getting Started for the shortest runnable path. Then copy from Reference App for the full canonical directory layout.
Looking for a specific capability (AI, multi-tenancy, WebSocket, gateway)? → Browse Extensions (x/*) — all families by maturity tier with tags and primer links. Or go to Modules Overview for the full reference view grouped by work type.
Using AI coding agents on this codebase? → Read Agent-First Workflow — how machine-readable specs route agents to the right module before a line is written.
Migrating from Gin, Echo, or Chi? → Go to Migration Hub — handler diff, middleware adaption, cost estimate, and step-by-step guides.
Need to verify stability before committing a dependency? → Read Release Posture for the full support matrix.
First 30 minutes
Section titled “First 30 minutes” 1 go get + go run see Getting Started
2 /healthz data.status is ok
3 /api/v1/greet {"data":{"message":"hello, Alice"}}
4 reference app bootstrap, routes, handlers
5 next page request flow or module boundary
1
Install & run
see Getting Started
2
Verify liveness
data.status is ok
3
Verify a route
{"data":{"message":"hello, Alice"}}
4
Inspect shape
bootstrap, routes, handlers
5
Choose depth
request flow or module boundary
→ Getting Started — install, write one handler, run. Under 5 minutes.
Pick by question
Section titled “Pick by question”| Current question | Open | Result |
|---|---|---|
| How do I run the quickest possible example? | Getting Started | A running service in under 5 minutes |
| What files should I copy from? | Reference App | A file-by-file map of bootstrap, app wiring, routes, and handlers |
| How is the repository structured — stable roots, extensions, canonical path? | Architecture | The three-layer boundary map: kernel / extensions / canonical path |
| How does a request move through Plumego? | Request Flow | A visible path from route registration to contract.WriteResponse |
| Where should a change live? | Repository Boundaries | The docs/specs/tasks control-plane split |
| Which module should I open? | Modules Overview | Stable-root and x/* entrypoints by work type |
| Which x/* families exist and what maturity are they? | Extensions | Card browser — all families with status badges and primer links |
| How do AI agents navigate this codebase? | Agent Workflow | Control plane, task routing, CI-equivalent validation loop |
| How do I migrate from Gin, Echo, or Chi? | Migration Hub | Handler diff, cost estimate, and step-by-step guides per framework |
| Can I depend on this package long term? | Release Posture | The support posture before adoption |
| How do I connect a database / add auth / compare with Gin? | FAQ | Direct answers to common questions |
What is the exact function signature for core.New or contract.WriteError? | API Quick Reference | Full signatures, types, and wire formats for stable modules |
| What does error type X mean and how do I fix it? | Error Reference | All ErrorType constants with trigger scenarios and remediation |
Topic tracks
Section titled “Topic tracks”Concepts
Build the request-flow and repository-boundary model before you open packages at random.
Boundaries
Move into modules and release posture when you need to decide where work belongs.
Stable surface at a glance
Section titled “Stable surface at a glance”| Surface | Use it for | Do not use it for |
|---|---|---|
| Stable roots | Kernel, routing, contracts, middleware, security, storage, health, logging, and metrics basics | Optional product capabilities or protocol-specific feature work |
reference/standard-service | Canonical service shape and runnable examples | Repository ownership decisions |
x/* families | Optional capability work that should not expand stable roots | The default learning path for every service |
docs, specs, tasks | Human intent, machine-readable rules, and execution scope | Runtime package APIs |
Synced repository facts
Section titled “Synced repository facts”module facts
Modules and boundaries
The default learning path starts with stable roots. Capability work starts from the primary extension families.
Stable roots
9
Primary extension families
14
release facts
Release posture
Read the support matrix synced from README before assuming long-term compatibility.
Current version
v1.1.0
Support groups
6
roadmap facts
Current direction
The roadmap summary is synced from docs/release/roadmap.md before each build.
In progress
1
Planned
0
These summaries all come from prebuild-synced repository facts instead of a website-only copy.