Docs Planned Features

Planned Features

This page describes possible future directions for Plumego.

It is intentionally conservative.

Nothing listed here is guaranteed to be implemented.
Everything listed here is subject to:

  • Design principles
  • Non-goals
  • Long-term maintenance cost
  • Real-world validation

If a planned feature ever violates those constraints,
it will be dropped without hesitation.

How to Read This Page

Important clarifications:

  • “Planned” does not mean “scheduled”
  • “Planned” does not mean “promised”
  • “Planned” means “considered plausible and compatible”

Think of this as a design space exploration, not a roadmap commitment.

Category 1: Documentation and Knowledge Expansion

Documentation is considered a first-class feature.

Possible expansions include:

  • More end-to-end example projects
  • Production-grade reference architectures
  • Migration case studies
  • Failure-mode analyses
  • Performance deep dives
  • Operational playbooks

These changes carry minimal risk
and high long-term value.

Category 2: Reference Completeness

The Reference section may grow to include:

  • More precise API contracts
  • Edge-case behavior documentation
  • Formalized invariants
  • Compatibility notes across versions

This is not feature growth —
it is clarity growth.

Category 3: Optional Companion Packages

Instead of expanding the core,
Plumego may gain optional companion packages, such as:

  • Reference logging middleware
  • Authentication middleware examples
  • Tracing adapters
  • Metrics instrumentation helpers
  • Request validation helpers

Constraints:

  • Must live outside the core
  • Must be optional
  • Must not introduce hidden behavior
  • Must not require framework changes

The core remains untouched.

Category 4: Tooling and Developer Experience

Possible tooling improvements include:

  • Project scaffolding templates
  • Static analysis rules
  • Lint checks for common misuse
  • Documentation generation helpers
  • Debugging aids

Tooling must remain:

  • Optional
  • Non-invasive
  • Build-time or dev-time only

Runtime magic is explicitly forbidden.

Category 5: Testing Support (Non-Intrusive)

Potential additions:

  • Testing helpers
  • Mock utilities
  • Reference test patterns
  • Example test suites

Constraints:

  • No test framework coupling
  • No runtime hooks
  • No framework-managed test lifecycle

Testing support must not leak into production code paths.

Category 6: Better Observability Integration Examples

Not new observability systems, but:

  • Better examples of integration
  • Clearer patterns for trace propagation
  • Structured logging guidelines
  • Metrics boundary clarification

Plumego integrates —
it does not define observability stacks.

Category 7: Performance Analysis Guidance

Possible future content includes:

  • Benchmark suites
  • Allocation analysis examples
  • Load-testing guides
  • Performance regression strategies

These are educational additions,
not framework-level optimizations.

Explicitly Excluded from Planned Features

Even if frequently requested, the following are not planned:

  • Dependency injection containers
  • ORMs
  • Background job frameworks
  • API gateways
  • Configuration systems
  • Convention-based routing
  • Auto-discovery mechanisms
  • “Zero-config” modes

These remain firm non-goals.

Why There Are So Few Planned Features

This is intentional.

Plumego’s design assumes that:

  • Most power lives in user code
  • Most flexibility comes from explicit wiring
  • Most innovation happens outside the framework

A small roadmap is a sign of confidence, not stagnation.

Feature Acceptance Criteria

For any planned feature to become real, it must satisfy:

  1. No hidden control flow
  2. No implicit configuration
  3. No global state
  4. No core bloat
  5. Clear removal story
  6. Long-term maintenance justification

Few ideas pass this filter — by design.

How Planned Features Become Real

The usual path is:

  1. Real-world pain observed
  2. Pattern emerges in multiple codebases
  3. Solution proves stable outside core
  4. Documentation solidifies understanding
  5. Optional tooling or helpers are introduced

The framework evolves after practice, never before.

Summary

Plumego’s planned features are:

  • Sparse
  • Conservative
  • Principle-bound
  • Non-binding

This is deliberate.

The goal is not to grow Plumego’s surface area,
but to protect its clarity over time.

  • Roadmap Overview — overall direction
  • Design Principles — decision constraints
  • Non-Goals — what will never be added

If a future feature is not compatible with these pages,
it will not be implemented — no matter how appealing it sounds.