chore: Release 0.2.0

[nfebe]

Offer providers, so a host's discounts can be listed and created from the
console without this package knowing what stores them.

[sourceant]

Code Review Summary

✨ Release 0.2.0 introduces an offer-provider abstraction so a host's discounts can be listed, created and revoked from the admin console without the package knowing where they are stored. A new OfferProvider contract (with OfferField describing the inputs a provider expects and Offer describing how a discount is shown, including an already-formatted value) is resolved through an OfferRegistry singleton that holds class names and resolves on use. The registry refuses classes that do not implement the contract and refuses two providers claiming one key. GET offers, POST offers/{provider} and DELETE offers/{provider}/{id} answer to the configured owner, the write routes honour admin.write_middleware, an unregistered provider key is a 404, and registering no provider is a supported state that answers with an empty list. New configuration (admin.offer_providers, admin.requests.create_offer) lets a host supply its own validation, defaulting to the shipped CreateOfferRequest so a host that published the config before the key existed still works. The version is bumped to 0.2.0 in composer.json, with matching CHANGELOG.md and README.md documentation, and feature tests cover listing, creation, revocation, owner authorization, request replacement, expiry date formats, config validation failures and unknown providers. Review raises two points: the shared write path validates only that attributes is an array while providers declare required fields, so a payload omitting them can reach OfferProvider::create() and fail with a 500 rather than a 422; and the owner gate is transcribed a second time in the controller rather than shared with the mail-template path.

🚀 Key Improvements

• src/Contracts/OfferProvider.php, src/Contracts/OfferField.php and src/Support/Offer.php define a small contract that lets a host expose discounts of any shape — the console renders the form from the provider's declared fields and shows Offer::$value already formatted, since only the provider knows whether the number means a percentage, pennies or seats.
• src/Support/OfferRegistry.php validates registrations eagerly, rejecting classes that do not implement the contract and two providers sharing a key, while holding class names rather than instances so a singleton does not keep providers and their dependencies alive for the process.
• src/Http/Controllers/AdminController.php treats "no providers registered" as an empty list rather than an error, returns 404 for an unknown provider key instead of failing obscurely, and enforces the owner check in the controller so replacing the request class cannot drop it.
• config/admin.php and AdminController::createOffer() fall back to the shipped request class when admin.requests.create_offer is absent, so hosts upgrading with a previously published config file can still create offers; tests/Feature/OfferProviderTest.php covers that upgrade path alongside creation, revocation, authorization and unknown providers.

📉 Regressions

• The owner gate is now implemented a second time in AdminController::authorizeOffers() alongside the mail-template path's own check against OwnerAuthorizer, giving two independent copies of the same rule that can drift as owner resolution or 403 semantics change.

💡 Minor Suggestions

• This is a second transcription of the owner gate that the mail-template path already implements (UpdateMailTemplateRequest::authorize() and the controller's template authorization both abort/deny against OwnerAuthorizer). Two independent copies of the same rule means the offer endpoints and the template endpoints can drift — e.g. a change to owner resolution or to the 403 semantics applied to one path will not reach the other, even though both are documented as answering to the configured owner. Extract the gate into a single private helper and have the template path use the same helper, so there is exactly one place that decides who may see or change admin-owned data.

🚨 Critical Issues

• The shared write path validates only the shape of the payload (CreateOfferRequest::rules() requires attributes to be an array), while the provider contract advertises per-field requiredness that the console renders (OfferField::$required, serialized by OfferField::toArray() and surfaced as data.N.fields.N.required). A caller that skips the console form — or that posts {"attributes": {}} — passes validation and reaches OfferProvider::create(), which indexes the fields it declared as required (e.g. $attributes['code']) and then constructs a typed Offer property from the missing value, turning what should be a 422 into a 500. The mail-template path does not have this gap because UpdateMailTemplateRequest::rules() enforces its fields. Derive the required entries from the provider's own fields() and validate them through the request's existing validator, rather than introducing a second validator class.

[sourceant]

Review complete. See the overview comment for a summary.

[sourceant]

The shared write path validates only the shape of the payload (CreateOfferRequest::rules() requires attributes to be an array), while the provider contract advertises per-field requiredness that the console renders (OfferField::$required, serialized by OfferField::toArray() and surfaced as data.N.fields.N.required). A caller that skips the console form — or that posts {"attributes": {}} — passes validation and reaches OfferProvider::create(), which indexes the fields it declared as required (e.g. $attributes['code']) and then constructs a typed Offer property from the missing value, turning what should be a 422 into a 500. The mail-template path does not have this gap because UpdateMailTemplateRequest::rules() enforces its fields. Derive the required entries from the provider's own fields() and validate them through the request's existing validator, rather than introducing a second validator class.

Suggested change

	$requestClass = config('admin.requests.create_offer', CreateOfferRequest::class);
	$requestClass = config('admin.requests.create_offer', CreateOfferRequest::class);
	$validated = app($requestClass)->validated();
	$offerProvider = $this->offerProvider($offers, $provider);
	// The fields a provider declares are what the console renders as a
	// form; hold a caller that skips the form to the same requiredness.
	$required = [];
	foreach ($offerProvider->fields() as $field) {
	if ($field->required) {
	$required['attributes.'.$field->name] = ['required'];
	}
	}
	if ($required !== []) {
	$request->validate($required);
	}
	$offer = $offerProvider->create($validated['attributes']);

[sourceant]

This is a second transcription of the owner gate that the mail-template path already implements (UpdateMailTemplateRequest::authorize() and the controller's template authorization both abort/deny against OwnerAuthorizer). Two independent copies of the same rule means the offer endpoints and the template endpoints can drift — e.g. a change to owner resolution or to the 403 semantics applied to one path will not reach the other, even though both are documented as answering to the configured owner. Extract the gate into a single private helper and have the template path use the same helper, so there is exactly one place that decides who may see or change admin-owned data.

Suggested change

	{
	private function authorizeOffers(Request $request): void
	{
	$owner = config('admin.owner');
	$this->authorizeOwner($request, $owner['type'], $owner['id']);
	}
	/**
	* The single owner gate for this controller. The mail template methods
	* should delegate to this too, so both sections answer to one rule.
	*/
	private function authorizeOwner(Request $request, string $ownerType, mixed $ownerId): void
	{
	abort_unless(app(OwnerAuthorizer::class)->authorize(
	$request->user(),
	$ownerType,
	$ownerId,
	), 403);
	}