Docs Non-Goals

Non-Goals

Every sustainable framework is defined as much by its refusals
as by its capabilities.

Plumego’s long-term viability depends on clear non-goals —
areas it intentionally avoids, regardless of trends, demand, or convenience.

This document enumerates those non-goals
and explains why each refusal is deliberate.

Why Non-Goals Matter

Without explicit non-goals:

  • Feature creep becomes inevitable
  • Boundaries erode silently
  • Short-term convenience wins over long-term clarity
  • Frameworks collapse under their own weight

Plumego documents its non-goals to prevent that outcome.

Non-Goal 1: No Full-Stack Framework

Plumego will never become a full-stack framework.

It will not include:

  • Template engines
  • Frontend build pipelines
  • Asset management
  • SSR abstractions
  • Client-side routing

Plumego’s responsibility ends at the HTTP boundary.

Frontend concerns belong elsewhere.

Non-Goal 2: No Dependency Injection Container

Plumego will not provide:

  • Reflection-based DI
  • Container-managed lifecycles
  • Auto-wiring
  • Scope-based injection
  • Implicit dependency graphs

Dependency injection in Plumego is:

  • Manual
  • Explicit
  • Visible in code

This is a feature, not a limitation.

Non-Goal 3: No ORM or Persistence Abstractions

Plumego will never include:

  • ORMs
  • Active Record patterns
  • Schema migration tools
  • Query builders
  • Database lifecycle management

Persistence is an infrastructure concern.

Plumego integrates with databases —
it does not abstract them.

Non-Goal 4: No Background Job Framework

Plumego will not provide:

  • Job queues
  • Worker orchestration
  • Retry engines
  • Scheduling systems
  • Task dashboards

Background processing is intentionally external.

Plumego documents how to integrate such systems,
but does not implement them.

Non-Goal 5: No API Gateway Features

Plumego will not become:

  • An API gateway
  • A reverse proxy
  • A service mesh component
  • A traffic management system

It will not include:

  • Rate limiting engines
  • Circuit breakers
  • Request shaping
  • Protocol translation layers

These belong at infrastructure or edge layers.

Non-Goal 6: No Convention-Over-Configuration

Plumego explicitly rejects:

  • Auto-discovery
  • Naming conventions
  • Implicit file scanning
  • Magic defaults
  • Environment-based behavior switches

If behavior exists, it must be wired explicitly.

Conventions hide behavior; Plumego exposes it.

Non-Goal 7: No Global Configuration System

Plumego will never introduce:

  • Global config registries
  • Environment-variable-driven behavior
  • Runtime config mutation
  • Implicit configuration loading

Configuration is loaded by the application
and injected explicitly.

Anything else creates hidden coupling.

Non-Goal 8: No Implicit Error Handling

Plumego will not:

  • Auto-map errors to responses
  • Swallow panics silently
  • Retry failed operations automatically
  • Normalize errors behind the scenes

All error handling must be explicit and visible.

Silence is treated as a bug.

Non-Goal 9: No Magic Performance Optimizations

Plumego will not:

  • Introduce hidden caches
  • Perform speculative optimizations
  • Auto-batch requests
  • Apply heuristic shortcuts

Performance optimizations must be:

  • Measurable
  • Explicit
  • Removable

Hidden performance tricks always become liabilities.

Non-Goal 10: No Opinionated Infrastructure Stack

Plumego does not mandate:

  • Logging libraries
  • Metrics systems
  • Tracing providers
  • Authentication providers
  • Deployment models
  • Cloud vendors

It integrates with ecosystems —
it does not define them.

Non-Goal 11: No “Beginner Mode”

Plumego will not:

  • Hide complexity for beginners
  • Provide “easy mode” APIs
  • Add training-wheel abstractions

It assumes:

  • Go proficiency
  • HTTP understanding
  • Responsibility for design decisions

Clarity is preferred over approachability.

Non-Goal 12: No Rapid Feature Expansion

Plumego is intentionally slow-moving.

It will not:

  • Chase trends
  • Mirror popular frameworks
  • Add features “because others have them”

Stability beats novelty.

Non-Goal 13: No Silent Breaking Changes

Plumego will never:

  • Change behavior without documentation
  • Break contracts in minor releases
  • Rely on “bug fixes” to justify breaking changes

Breaking changes are explicit, rare, and versioned.

Non-Goal 14: No Ambiguous Ownership

Plumego will not:

  • Own application lifecycle
  • Own business logic
  • Own deployment behavior
  • Own operational policy

The framework defines structure —
the application owns decisions.

How Non-Goals Are Enforced

When evaluating proposals, the following questions apply:

  • Does this violate any non-goal?
  • Does this pull Plumego into forbidden territory?
  • Can this live outside the core instead?

If yes, the proposal is rejected.

Summary

Plumego’s power comes from restraint.

Its non-goals ensure that:

  • The core remains small
  • Behavior remains explicit
  • Systems remain understandable
  • Evolution remains possible

Plumego does not try to be everything.

It tries to be reliable for a very long time.

  • Roadmap Overview — direction and constraints
  • Design Principles — guiding rules
  • Migration Policy — how change is handled

Non-goals are not limitations —
they are the framework’s strongest guarantees.