Your application is a demesne graph — pure use cases behind ports. Serve that same graph over HTTP, AMQP or Temporal; only the host changes.
Config (factor III), the DI graph, the error channel and graceful shutdown (factor IX) are shared across every transport.
A zod contract + a demesne-injected handler + a host that owns the process. Hosts are pure transport glue over the kernel's runHandler.
Every example ships a test:integration suite that runs against real Postgres, RabbitMQ and Temporal via testcontainers.
Under construction. start is incubating — all packages are currently private while the API settles. The RFCs in design/ are the source of truth, and everything here may change without ceremony.
Your application is a demesne graph — pure use cases behind ports, adapters wired at the boundary, everything discharged before you run. start adds the process spine and lets you serve that same graph over any transport:
a contract (zod input / output) + a handler (a demesne-injected use case) + a host (owns the process, opens a fork scope per invocation)
The host is the only thing that changes between transports. Config, the DI graph, the error channel, and graceful shutdown are shared.
| Host | Disposition D | Invocation unit |
|---|---|---|
@btravstack/start-api | HTTP status | per request |
@btravstack/start-amqp | ack / requeue / dead-letter | per message |
@btravstack/start-temporal | retryable / non-retryable | per activity |
Each host is pure transport glue over the kernel's runHandler + a total DispositionMap — no DI, lifecycle, validation, or dispatch logic of its own.
start is where the BtravStack packages meet: demesne does the wiring, unthrown carries the errors, and 12-factor falls out of building your app as a graph.
