Support Core Laravel Package

Product Decisions This Supports

• Build vs. buy for the “shared plumbing” layer. orchestra/support-core is not a feature package — it is a bundle of commodity utilities (base service providers, reusable traits, string/array/HTML helpers, and extension contracts) that every Laravel service otherwise rewrites. The decision it informs is narrow: do we standardize that layer on this package, or maintain a thin internal helper namespace? Since most of its value overlaps illuminate/support (Str, Arr, Htmlable), the answer should be driven by coupling and maintenance cost, not capability.
• Platform standardization across teams. Where multiple teams ship Laravel services, one shared set of contracts and traits reduces drift — the “three slightly different HTML helpers, four incompatible extension interfaces” problem. This is a consistency decision made once at the platform level, not per service.
• Orchestra Platform adoption (the clearest use case). This is the core support component of Orchestra Platform. If the roadmap includes Orchestra extensions or an Orchestra-based admin/back-office, the package arrives as a transitive foundation — the question is not whether to use it but how to govern, pin, and contain it, including whether application code may call its helpers directly.
• Upgrade sequencing and roadmap timing. v7.0.0 changes exactly one thing: the floor is now Laravel 9+ (transitively PHP 8.0+). That makes it an input to dependency-hygiene planning — sequenced behind any Laravel 8→9 upgrade, never treated as an isolated bump. The one-line release note is also a standing warning that future Laravel majors require manual readiness confirmation, not an assumption of support.
• Dependency-risk posture for the portfolio. Zero listed dependents, a 0.3 composite score, no star baseline, no published support or deprecation policy: this is an ecosystem-internal utility, not a de facto standard. Approve it as a scoped foundation for Orchestra-based work, not as a general-purpose library other teams implicitly rely on.
• Lock-in vs. exit cost. Every direct call to its traits and helpers inside application code raises the cost of later replacement. The decision worth recording is a usage policy — wrap helpers behind internal adapters, keep the surface small, document what is in use — so the build-vs-buy answer stays reversible.
• Ecosystem risk acceptance on a business-critical path. If it becomes load-bearing through transitivity, we accept a single-maintainer, near-zero-adoption dependency with no support contract. Acceptable for internal tooling; a materially different risk on a customer-facing request path.

When to Consider This Package

Adopt — or accept as a transitive foundation — when:

• You are building on Orchestra Platform or Orchestra extensions; it is a required foundation and fighting it costs more than pinning it.
• Your services are already on Laravel 9+ / PHP 8.0+ and you have a repeated, genuine need for shared contracts and traits across more than one codebase.
• You want a small, conventional utility surface aligned with Orchestra’s conventions instead of maintaining, documenting, and staffing a bespoke internal helpers package.
• The behavior is already exercised by your own test suite — v7.0.0 is a compatibility refresh, so the right action is re-test and pin, not re-architect.
• It already appears in composer.lock as a transitive install; the work is then a constraint review and a governance decision rather than an adoption project.

Look elsewhere — or hold — when:

• You only need string/array/HTML helpers. Laravel’s own illuminate/support covers most of this; adding a low-popularity dependency for it is a net negative.
• You are on Laravel 8 or earlier. v7.0.0 does not serve you and the raised floor implies no backward-compatibility promise. Stay on the last v6 release if you must, plan the framework upgrade first, and assume v6 receives no security-patch commitment.
• No Orchestra component is on your roadmap and you have exactly one service — there is no drift to consolidate and one more dependency to audit buys you nothing.
• You need a vendor support tier, a formal lifecycle/deprecation policy, or an SLA. None exists here; you would be owning the surface yourself.
• The package would land on a customer-facing critical path. The transitivity risk is fine for internal tooling, not for a revenue-path dependency.

How to Pitch It (Stakeholders)

For executives — one paragraph. orchestra/support-core is a small foundation library, not a product capability. It ships the boilerplate every Laravel service rewrites — base service providers, shared traits, and string/HTML helpers — and it is the mandatory base layer for anything built on Orchestra Platform. Adopting it costs one pinned dependency and saves duplicated plumbing across teams; the v7 release simply moves the floor to Laravel 9+ and PHP 8.0+. The real decision is governance, not capability: we approve it as a scoped foundation for Orchestra-based work, wrap its helpers behind our own thin adapter, and keep the exit cost at a one-line composer require. Risk is manageable but real — single maintainer, no vendor support, zero downstream adoption — so it stays contained and never becomes an implicit platform-wide standard.

For engineering — the operating summary.

• What it is: the shared support component of Orchestra Platform. Utility helpers, contracts, base classes; framework-agnostic where possible; lightweight Laravel integration.
• Why we care: it removes repeated service-provider scaffolding and gives one consistent contract/interface layer, plus it is unavoidable if Orchestra is on the roadmap.
• What v7 actually means: one line — “update support for Laravel Framework v9+.” That is a floor change (Laravel 9+, PHP 8.0+), not a feature change. Treat the release note as a red flag that the changelog is thin: diff src/ between v6 and v7 and assume an undisclosed breaking-change surface in helpers and PHP minimums.
• Non-negotiables for adoption: pin ^7.0 explicitly in every composer.json that inherits it, even transitively, so resolver drift is visible in the diff; sequence the bump behind the Laravel 8→9 upgrade; grep -rn 'Orchestra\\Support' app/ packages/ before and after every bump so the blast radius is a known list, not a guess.
• The one architectural rule: no direct helper calls in application code. Wrap them in a single internal adapter file on day one (Acme\Support\Text::slug() delegating to the package). If the package is abandoned or dropped at the next Laravel major, the swap is one file — not a codebase-wide edit. Apply traits only to classes we own, and bind our own implementations to contracts rather than extending their concrete classes, so Orchestra never appears in our type signatures.
• Known traps to design around: ambiguous illuminate/* constraints (read composer.json yourself — don’t infer from “9+”); global helper collisions from files autoloading (guard with function_exists); helper changes requiring composer dump-autoload, not config:clear; escaping behavior in HTML/string helpers being security-relevant, so write explicit regression tests for entities, quotes, and multi-byte input after the bump; and deferred-provider ordering causing BindingResolutionException on classes that clearly exist.
• Verification loop: composer why → composer show → grep the constraint → php artisan about → config:cache → one end-to-end feature test through the binding. A green suite after the bump is the verification, because v7 changes no behavior.
• Debugging reality: zero dependents, low score, single maintainer, no support policy. Assume we own the helper surface. Document which helpers and traits we use, keep the adapter, and keep the rollback path to one composer line.