Getting Started

Install with composer require symblaze/http-bundle. This is a 0.x release — pin it ("symblaze/http-bundle": "0.0.7") rather than using a caret range, since minor bumps have shipped behavioural changes.
Register the bundle's DI extension in your kernel/bundles.php equivalent. Note: this is a Symfony bundle, not a Laravel service provider — it will not be auto-discovered by Laravel. If you are pulling it into a Laravel app, plan to either (a) run it inside a Symfony kernel/console context, or (b) instantiate the underlying classes directly from a custom service provider and skip the bundle wiring entirely.
First place to look: the bundle's validation integration. Release 0.0.7 changed the shape of validation violation output, so read the validation classes and their tests before writing anything that consumes them.
First use case: converting a failed validator run into a structured HTTP 422 response from a controller, instead of hand-rolling the error envelope.

Implementation Patterns

Throw-and-convert. Let your controller/service throw the validation exception and let the bundle's listener turn it into a response. Keeps controllers thin and makes the error envelope consistent across endpoints.
Validate at the boundary, not in the entity. Run the validator against the request payload/DTO in the controller or a form-request equivalent, and let the bundle own the formatting. This is where 0.0.7's change is visible.
Treat the violation payload as a public contract. After 0.0.7 the violations no longer carry a code. Assert in tests on propertyPath + message, not on code, and check any frontend that reads the field.
Custom message mapping. If you need stable machine-readable error identifiers now that code is gone, map messages to your own keys in an application-level normalizer rather than depending on the bundle's output.
Test at the HTTP level. Use functional tests against the endpoint (Symfony KernelBrowser / Laravel $this->postJson) so you catch envelope drift on upgrade. The 0.0.7 psalm-phpunit-plugin change is CI-only and has zero runtime impact — do not spend time on it.
Version-gate in CI. Add a job that runs your suite against the exact pinned version and, separately, against 0.0.x head so you see the next break before it lands.

0.0.7 is a quiet breaking change. "Remove violation code" changes the response body. Anything that asserted on code in tests, logged it, or exposed it to API clients will silently degrade (missing key) rather than fail loudly. Audit consumers before upgrading.
0.x semver means every release is a potential break. Skim the changelog on each bump; don't assume patch-level = safe.
Framework mismatch is the biggest pitfall. The bundle assumes Symfony's container, event dispatcher, and validator interfaces. In Laravel you get the illuminate/* equivalents, which are compatible in spirit but not in wiring. Budget for glue code, and don't expect the bundle's exception listener to be registered.
Debugging swallowed exceptions. If validation errors come back as a generic 500 or an empty 422, temporarily disable the bundle's exception listener so the raw exception surfaces; the listener is usually the thing masking the real failure.
Extension points to reach for first: a custom violation normalizer (to reinstate your own error codes), and a custom message catalogue — both let you keep the bundle while owning the contract that 0.0.7 changed.
CI-only changes aren't free signal. The psalm/phpunit plugin addition tells you the maintainers are tightening static analysis; your own Psalm/PHPStan baseline may start flagging new things if you inherit their config. Your runtime is unaffected.