Packages & Libraries
Krewire is delivered as Modular Libraries: independent, single-purpose Go packages that you compose, rather than a monolithic framework you inherit.
Every package in the krewire/packages catalog adheres to strict architectural boundaries:
- Strict Downward-Only Dependencies: Domain primitives and rules reside in
packages/kern/model. Higher-level libraries never inject upward dependencies. - Single Source of Truth (SSOT): Facts, constants, and validation rules are owned by exactly one package and imported elsewhere.
- Standard Library Alignment: Zero unnecessary third-party dependencies. Where the Go standard library provides a capability (
net/http,context,slog,embed), Krewire builds upon it rather than replacing it.
What is in this Chapter?
The foundational control plane: workload kinds, lifecycle supervision, error taxonomy, environment detection, and version contracts.
HTTP routing engine, middleware pipelines, RFC 7807 problem details, dependency injection container, and server lifecycle runners.
Hardened security defaults, OWASP Top 10 middleware, CSRF tokens, SSRF protection, PII masking, JWT verification, and basic authentication.
Reusable Single-File Components, design tokens, light/dark themes, and interactive terminal user interface (TUI) toolkits.
Backend-independent object storage (S3, local, memory), atomic file replacements, and mockable filesystem boundaries.
Exponential backoff retries, circuit breakers, dead-letter dispatch, and the spec-driven test harness with traceability citations.
Ecosystem Dependency Hierarchy
As documented in internal/docs/architecture.md, dependencies flow strictly downward:
templates/boost (AI agent starters)
│
▼
tools/kiw (Developer CLI)
│
▼
packages/* (Domain libraries: web, sec, auth, ui, tui, storage...)
│
▼
packages/kern (Kernel model, lifecycle, errors, environment, version)
No library or package may ever import kiw. Domain rules belong in packages/kern/model, and runtime mechanics belong in packages/kern/lifecycle.