Core Interfaces Laravel Package

Product Decisions This Supports

• Architecture / build-vs-buy: This is a contracts-only package (interfaces) for the Trinity Framework. Its real value is conceptual — it demonstrates interface-first, dependency-inverted design. The buy decision is effectively "no"; the build decision is "write our own contracts or adopt PSR/Illuminate."
• Dependency policy: With 0 stars, 0 dependents, and a last release of 2017-07-18, this fails any reasonable third-party dependency gate. It informs a negative roadmap decision: exclude from the approved dependency list unless a legacy Trinity app forces it.
• Feature enablement: No end-user feature can be traced to this package. It does not unlock capabilities; it only defines type contracts. Any feature work should be planned against an actively maintained contracts layer.
• Market/opportunity signal: The 4.16 opportunity score is best read as whitespace, not adoption merit — i.e., there is room for a modern, maintained contracts package. The PM action is to scope a small internal contracts module (typically days, not weeks) rather than inherit dead code.
• Legacy maintenance: The only defensible use case is supporting an existing Trinity-based system, where the interfaces are already baked into the codebase and removing them would be a larger migration than keeping them pinned.
• Vendor-risk budgeting: Adopting this creates an implicit maintenance obligation on our team — forking, PHP-version compatibility, and security triage — with no upstream to escalate to.

When to Consider This Package

Consider only if:

• You are maintaining an existing application already built on the Trinity Framework and need the canonical interfaces to compile/upgrade it.
• You want a read-only reference for how a contracts layer can be structured; you would copy the ideas, not the dependency.
• You have explicit appetite to fork, own, and maintain the package internally, including PHP 8+ compatibility and test coverage.
• Your dependency policy permits abandoned, single-maintainer, zero-adoption packages with a documented exception.

Look elsewhere when:

• You are starting any new build — use psr/*, illuminate/contracts, or symfony/contracts instead. They are maintained, documented, widely depended upon, and PHP-version-current.
• You require security patching, LTS/support commitments, or a release cadence. None exist here; the last release is from 2017.
• You need documentation, tests, CI status, or evidence of production use — 0 dependents and 0 stars mean no validated usage to learn from.
• Composer hygiene matters: no recent version constraints, likely pre-PHP-7.2 syntax, and no compatibility matrix make install and upgrade risk high.
• You want community support for onboarding — there is effectively no user base to draw on.

How to Pitch It (Stakeholders)

For executives: We evaluated trinity/core-interfaces and recommend against adoption. It is a contracts-only package for a niche framework, with zero stars, zero dependents, and no release since July 2017. Adopting it gives us no functional capability, no vendor support, and no security patching — but does create a permanent internal maintenance obligation and supply-chain exposure. The opportunity score suggests a gap in the market for a modern contracts layer, not a reason to take on abandoned code. Recommendation: decline, and if we need equivalent contracts, spend a few engineering days building a thin internal layer or standardize on PSR/Illuminate.

For engineering: The package is interface definitions — no runtime logic worth inheriting. The design ideas (interface-first, dependency inversion) are sound and we already get them from PSR and Illuminate. If a legacy Trinity system forces the dependency, vendor/fork it, pin the exact commit, add it to the unmaintained-dependency register, and wrap it behind our own contracts so it can be swapped out. Do not introduce it into new services, and do not let it appear in a shared library that other teams depend on.