library family / active

go-app + go-toolbelt

Lifecycle orchestration and practical components without dependency-injection magic.

A stable lifecycle core with faster-moving components, adapters, and recipes for explicit Go application assembly.

Core documentation Core repository
explicit application assemblygo
a := app.New(ctx,
    app.WithDependency(cfg),
    app.WithSequentialStartup(
        app.Registered(store),
        app.Registered(server),
    ),
)

if err := a.Run(); err != nil {
    return err
}
01lifecycle corev1.0.0

go-app

Stable startup, runtime, shutdown, rollback, and typed app-scoped dependency contracts.

go get github.com/scotthaleen/go-app
Docs Source Agent skill
02companion moduleevolving

go-toolbelt

Practical components, delivery adapters, infrastructure helpers, and examples built around go-app.

go get github.com/scotthaleen/go-toolbelt
Docs Source Agent skill
Model

Applications have lifecycle semantics whether or not their framework names them. Resources must start in a deliberate shape, runtime work needs cancellation that outlives startup, and successfully initialized components must stop in reverse order when shutdown begins or startup fails halfway through.

go-app owns that stable boundary. It keeps lifecycle and app-layer dependency assembly visible at the call site instead of solving a dependency graph or hiding construction behind reflection. go-toolbelt builds on the core with practical components, adapters, and recipes that can evolve faster as application patterns settle.

The split is intentional: keep orchestration small and conservative, then let concrete integrations such as HTTP servers, databases, embedded NATS, logging, OIDC verification, process execution, strict JSON handling, AI clients, and artifact storage develop outside the core.

Lifecycle

The application owns the shape.

  1. 01

    Construct

    Create concrete application-owned settings, capabilities, and adapters.

  2. 02

    Register

    Place dependencies and lifecycle providers into an explicit startup shape.

  3. 03

    Run

    Start components, use a separate runtime context, and keep handlers on ordinary typed fields.

  4. 04

    Close

    Cancel runtime work and stop successfully started components in reverse order.

Surface

Stable contracts, practical components.

01

Explicit lifecycle

Components own setup and cleanup through visible Start and Stop boundaries.

02

Caller-owned startup

The application chooses sequential and concurrent groups instead of delegating architecture to a graph solver.

03

Typed app scope

Dependencies can be resolved during assembly without turning runtime code into a service locator.

04

Provider-owned readiness

Consumers wait on readiness only when they require a provider's stronger operational guarantee.

05

Practical components

The toolbelt supplies servers, storage, messaging, logging, process, identity, validation, AI, and artifact packages.

06

Portable agent guidance

Each module includes a SKILL.md that teaches agents the intended contracts and boundaries.

Boundaries

Architecture remains visible.

  • No automatic dependency graph solving or reflection-based constructor wiring.
  • No global registry, default application, named values, or value groups.
  • No app-registry lookups spread through handlers, stores, or business logic.
  • No framework-specific infrastructure added to the stable lifecycle core.