Core

The Core section describes the absolute minimum Plumego guarantees.

This is not where you learn how to build features.
It is where you learn what Plumego promises to do — and what it explicitly refuses to do.

Understanding this boundary is critical.

If you misunderstand the Core, you will either:

Fight the framework, or
Expect it to solve problems it deliberately avoids

What “Core” Means in Plumego

Plumego’s core is intentionally small.

It provides:

A predictable request lifecycle
A minimal context abstraction
Explicit routing
Explicit middleware execution
Zero hidden global behavior

It does not attempt to be:

An application framework
A dependency injection container
A validation engine
A logging system
An ORM
A policy engine

Plumego is a runtime skeleton, not a platform.

Why the Core Is Small

Every additional responsibility in the core creates:

More implicit behavior
More coupling
Less architectural freedom
Higher long-term cost

Plumego follows a strict principle:

Anything that can be implemented outside the core, should be implemented outside the core.

This keeps the framework stable and predictable over time.

Core Guarantees

Plumego’s core guarantees only a small set of things:

1. Deterministic Request Flow

Requests move through middleware in a defined order
Handlers are invoked exactly once
No hidden retries
No implicit interception

What you see wired is what runs.

2. Explicit Context Propagation

Each request has its own context
Context is request-scoped
No global request state
No implicit mutation

Context is a carrier, not a container of logic.

3. Explicit Routing

Routes are registered directly
No auto-discovery
No reflection-based magic
No convention-over-configuration traps

Routes are part of the system contract.

4. Middleware Is Just Code

Middleware is ordinary Go code
Execution order is explicit
No hidden middleware layers
No implicit defaults

Middleware is control flow — and treated as such.

What the Core Will Never Do

Plumego intentionally avoids:

Automatic dependency injection
Global configuration registries
Implicit authentication
Implicit validation
Implicit logging
Hidden lifecycle hooks

If Plumego ever starts doing these things,
it would no longer be Plumego.

Core vs Ecosystem

Plumego’s philosophy is:

Core stays minimal
Capabilities grow outward

Features like:

Authentication
Observability
Persistence
Messaging

Belong in user space, not in the core.

This keeps Plumego adaptable across vastly different systems.

Reading the Core Documentation

The Core section is intentionally short.

It is meant to be:

Read once, carefully
Revisited when expectations drift
Used to resolve design disagreements

If a design question arises, ask:

“Is this a core responsibility, or an application concern?”

The Core section defines the answer.

When Core Matters Most

You should pay special attention to this section if:

You are evaluating Plumego vs other frameworks
You are onboarding engineers
You are tempted to add “just one more feature” to the framework
You are debugging unexpected behavior

Most confusion comes from misplaced expectations.

Summary

The Core section defines Plumego’s contract with you:

Plumego is minimal
Plumego is explicit
Plumego is predictable
Plumego does not hide behavior
Plumego does not make decisions for you

Everything else — architecture, guides, patterns — builds on this foundation.

To understand the core in detail, continue with:

→ Context — the request-scoped data carrier
→ Router — explicit path matching and dispatch
→ Middleware — controlled execution flow

These documents explain the only abstractions Plumego truly owns.