Core Entities Laravel Package

Product Decisions This Supports

• Build vs. buy for your domain/entity layer: Trinity Core Entities is a framework-level set of entity/model primitives, not a feature package. The realistic decision it informs is whether to adopt an external entity abstraction at all — and the evidence here (0 stars, 0 dependents, last release 2017) argues for building thin, in-house entity/DTO classes on top of native Eloquent rather than importing a framework's opinion.
• Tech radar placement: Treat as a "Hold / Avoid" entry. Useful as a reference point when engineers propose pulling in an ORM-adjacent abstraction — it illustrates the decay profile of framework-coupled packages (great while the parent framework lives, dead weight the moment it doesn't).
• Legacy estate audit: If any internal service, inherited codebase, or acquired product references the Trinity framework, this repo defines the shape of that inheritance. Worth a one-time inventory before committing roadmap capacity to modernization.
• Architecture pattern input (not a dependency): Reviewing its entity base classes is a cheap way to pressure-test your own conventions — what belongs in a base entity, what should stay in the domain layer. Read it, don't require it.
• Roadmap de-prioritization: No maintenance since 2017 means no security patching, no PHP 8+ compatibility, no Laravel LTS support. Any ticket proposing this package should be closed at triage rather than estimated.
• Vendor/supply-chain risk scoring: A useful calibration example for your dependency intake policy — what a near-zero-signal package looks like, and why the policy should auto-reject it.

When to Consider This Package

Consider only if:

• You are already operating a Trinity-framework application and need to keep an existing install on its original dependency set while you plan extraction. Even then, pin the lockfile and treat it as frozen legacy, not a going-forward dependency.
• You are doing due diligence on the Trinity ecosystem specifically — evaluating whether to inherit, fork, or retire it. The source is readable and MIT-licensed, so it can be studied freely.
• You need a historical reference for how entity primitives were modeled in the Laravel 5.x era. Research value only.

Look elsewhere when:

• Any new build. 0 stars, 0 dependents, and a last release of July 2017 are together a disqualifying signal. There is no community to catch regressions, no issue triage, and no realistic path to a security fix.
• You need PHP 8.x / modern Laravel support. A 2017 release predates typed properties, enums, and current framework conventions; retrofitting it costs more than writing the classes yourself.
• You want PSR-standard, framework-agnostic domain modeling. Native Eloquent models, Doctrine, or a lightweight in-house entity layer give you the same primitives with an actual maintenance story.
• You need vendor accountability. No dependents means no one else has validated this in production. You would be the first, and the only, adopter — absorbing 100% of the maintenance burden.
• Your intake policy requires recent releases, CI, or advisory coverage. This package fails all three by inspection.

How to Pitch It (Stakeholders)

To executives: We evaluated trinity/core-entities and recommend against adoption. It is a framework-coupled entity package last released in 2017 with no downstream users and no active maintenance. The cost of adoption isn't the license — it's that we would become the sole maintainer of an unmaintained dependency, absorbing PHP and framework upgrades ourselves. Recommendation: no spend, no integration, no roadmap impact. If any existing system depends on it, we'll flag the extraction cost separately as part of the legacy modernization line.

To engineering: Do not add this to composer.json. Use it as a read-only reference if you're designing base entity classes or DTO conventions — the patterns are conventional and the MIT license permits study. If you find it already present in an inherited codebase, raise it as tech debt: it will not survive a PHP or Laravel major upgrade, so extraction should be planned alongside the next upgrade window rather than after it breaks. Net position: Hold/Avoid on the tech radar, with a standing note that framework-scoped packages without downstream dependents are a category we should decline by default.