Rad Laravel Package

Product Decisions This Supports

• Framework reality check first: this is a Symfony bundle, not a Laravel package — symfony/* 7+, Doctrine ORM 3, PHP 8.4+. If the roadmap assumes Laravel, the decision is closed; nothing here transfers.
• Build vs. buy for "boring glue": the bundle is a thin layer of conveniences, not a platform — BaseController, EntityModel (persist/update/refresh), EntityFieldsTrait (ID + timestamps), ApiResponse/ApiResponseNormalizer, ArgumentBag, ImportData, InMemoryCache, AbilitiesVoter (CAN_* attributes), Linkable, EnumValue, TranslationHelper. The real decision is "adopt these opinions" vs. "write ~500 lines of our own internal conventions." Framing it as a dependency choice overstates it.
• API contract standardization: ApiResponse + ApiResponseNormalizer + user-readable error messages (3.3.0, 3.4.5 createResponse()) is the most defensible adoption driver — a consistent JSON envelope and error shape is a genuine cross-team contract decision affecting mobile/partner consumers.
• Delivery velocity for CRUD/back-office surfaces: consistent entity conventions, base controller service typing (getService() for PhpStan/PhpStorm), and import helpers compress the cost of internal tools — where differentiation is near-zero and speed dominates.
• Authorization posture: the CAN_* abilities voter is an opinionated authorization model; adopting it is an architecture decision, not a utility decision, and should be reviewed by whoever owns the security model.
• Build/maintain cost signal for planning: 2 stars, 0 dependents, single maintainer (apfelbox), agency-internal conventions ("as used by 21TORR"), rapid patch cadence, and a 3.0.0 that removed Model, Routable, sortable handlers, and simple entity search. Plan for it as source you fork, not a vendor you rely on.

When to Consider This Package

Consider it when:

• The stack is already Symfony 7+ / PHP 8.4+ / Doctrine ORM 3 and you are not willing to downgrade for a helper bundle.
• You are building agency-style or internal CRUD/admin/API apps where 21TORR's conventions (unsigned int IDs, clock-based timestamps, standard API envelope, CAN_* voting) are acceptable as house style.
• You have a small team that benefits more from convention-over-configuration than from flexibility, and can absorb a major-version migration.
• You are comfortable vendoring or forking under MIT and owning the upgrade path in-house.
• You want a reference implementation to copy patterns from, not a runtime dependency.

Look elsewhere when:

• The product is Laravel, or you need framework-agnostic PHP — there is no Laravel support here at all.
• You need vendor SLAs, security-response commitments, commercial support, or a community to escalate to. Two stars, zero dependents, and no third-party consumers means no external code review, no StackOverflow surface, and no ecosystem compatibility testing.
• You are on PHP < 8.4 or Symfony < 7 (3.4.0 and 3.0.1 both raised floors) or on Doctrine ORM 2.
• Your org has multiple teams with divergent conventions — you would be importing one agency's opinions as a standard, then fighting them.
• You already have (or plan) an internal shared bundle; the overlap cost exceeds the savings.

How to Pitch It (Stakeholders)

To executives (one paragraph): This is a small, MIT-licensed Symfony helper bundle that shortens delivery of internal CRUD/API features by standardizing controllers, entity handling, and API response shapes. It is not a strategic platform bet — it has negligible community adoption (2 stars, 0 dependents, one maintainer) and encodes one agency's conventions. The risk is contained and reversible: MIT license, no lock-in data, and the code is small enough to fork and own. Recommendation: use it as a time-to-market accelerator and pattern reference for internal tools only, with a pinned version and an internal fork; do not build customer-facing or long-lived product architecture on it. First confirm the stack decision, since this bundle targets Symfony, not Laravel.

To engineering (the actual ask): Evaluate against our stack — Symfony 7+, PHP 8.4+, Doctrine ORM 3. Review the CAN_* abilities voter as a security-model decision, and the API envelope as an external contract decision, before adopting anything else. Treat the repo as upstream source: pin the major, vendor the parts we use, and budget for one migration (2.x→3.x removed Model, Routable, sortable handlers, and DoctrineChangeChecker is already deprecated as of 3.4.5 — expect churn). Verify Doctrine ORM 3 and Symfony 7 compatibility in a spike, not in production. If the spike succeeds, fork and own it; if not, copy the four or five patterns we actually want and close the ticket.