Backend Engineering
For a new project, apply BEP dependency and ownership preferences directly. For an existing project, inspect the affected boundary and preserve its working conventions and supported contracts. Improve local design without turning a feature or fix into an architecture migration.
Read only what the decision needs:
- Ownership: module boundaries, dependency injection, use cases, ports, models, and stable errors.
- Persistence: transactions, repositories, and caches.
- Messaging: queues, durable jobs, and events.
- Lifecycle: startup, readiness, and shutdown.
- Verification: only when designing or auditing formal backend proof inventories and architecture enforcement.
Use $bep-http-engineering only for an HTTP semantic change and
$bep-best-openapi-design only for REST resource or representation design.
These are optional specialist workflows, not prerequisites for backend work.
For implementation, complete local acceptance: run the smallest meaningful
checks and exercise the changed behavior, fix failures caused by the change,
and report evidence. For test design use $bep-software-testing; merely running
existing tests does not require loading it. Review-only requests remain read-only.