Support Facades Laravel Package

Product Decisions This Supports

• Platform standardization, not product differentiation. This package does not unlock a customer-facing feature. Its value is consistency: if the organization builds internal Laravel packages on the Orchestra ecosystem, orchestra/support-facades supplies reusable facade base classes, registration/aliasing helpers, and container-backed accessors so each package does not reinvent the same plumbing. Frame the decision as platform hygiene, not roadmap priority.

• Build vs. buy for facade boilerplate. The package's entire proposition is reducing a few dozen lines of repeated boilerplate. That makes "write a thin internal base class" a genuinely competitive option, not a strawman. Buy when engineering confirms it is genuinely cheaper than owning ~50 lines and you are already inside the Orchestra family, where consistency across orchestra/* components is the deciding factor. Build otherwise.

• Package API design decisions. It enables exposing package APIs through a clean static syntax (Support::helper()) without repetitive container resolution. PM caveat: facade-first APIs hide dependencies and can institutionalize static access across application code, working against testability. Adopt it with an explicit engineering standard that facades are for package ergonomics, while application logic and tests resolve from the container.

• Upgrade-planning and dependency governance decisions. v7.0.0 sets a Laravel 9+ floor. That floor is a minimum to clear, never a target to converge on — Laravel 9 is already past security support. Adopting this package means adding a row to the per-Laravel-major upgrade matrix and to the dependency inventory for the life of the product, in exchange for boilerplate reduction.

• Adoption-risk decision: pilot vs. strategic bet. Zero dependents, negligible star traction, and a low opportunity score indicate this is maintainer-internal ecosystem tooling rather than a battle-tested community dependency. Treat it as internal infrastructure or a scoped pilot. Do not put it on a critical path, and do not standardize broadly across the estate until engineering has reviewed code, tests, license, maintainer activity, and the supported Laravel matrix.

• Candidate use cases if adopted: shared internal services, admin/platform components, and reusable package APIs on Orchestra Platform — specifically where multiple packages need a consistent static accessor layer over orchestra/support helpers.

When to Consider This Package

Adopt when:

• You are already building or maintaining Laravel packages on the Orchestra Platform. In that context this is dependency alignment with the rest of the orchestra/* family, not a net-new adoption decision, and the question becomes version lockstep across those packages.
• You want a consistent static API across Orchestra components and have a written engineering standard for when facades are appropriate versus constructor injection.
• Engineering has confirmed the supported matrix (Laravel 9+, realistically 10/11/12; PHP 8.1+; Composer 2), reviewed the license and supply-chain posture, inspected the code and test suite, and checked maintainer responsiveness and release cadence across prior Laravel majors.
• You have verified that v7.0.0 carried no breaking changes to facade base-class signatures, alias resolution, or accessor behavior beyond raising the framework floor — and that no code of yours subclasses these base classes.

Look elsewhere or defer when:

• You are not on Orchestra Platform. Laravel's native Illuminate\Support\Facades\Facade already covers the need, and a thin internal adapter is cheaper to own than a dependency, an upgrade ticket per Laravel major, and a security review per release.
• You require a community-vetted dependency with a real user base to surface bugs, third-party guidance, or a plausible maintained fork if the maintainer steps away. Zero dependents means no safety net; assume self-support.
• Your architecture prefers constructor injection, or your application code would end up peppered with static calls. Facade-heavy application code complicates test substitution and obscures dependencies.
• You are pinned below Laravel 9 for any estate still to be upgraded. v7 is a hard framework floor, not a shim. Pin legacy estates to v6 with a named owner and a date — after confirming v6 is still receiving fixes and for how long.
• You need enterprise support, long-term guarantees, or a published public roadmap. This is a micro-component with limited external validation.

How to Pitch It (Stakeholders)

To executives: This is a low-cost developer utility, not a customer-facing capability. If we are already standardized on Orchestra Platform, it reduces repeated facade boilerplate across internal packages and makes package APIs more consistent. If we are not, the honest answer is that a small internal base class delivers the same benefit without adding a dependency we must upgrade and security-review every Laravel major. Given negligible public adoption and zero dependents, fund it only as part of existing platform work, validate with a scoped pilot, keep it off critical paths, and do not treat it as a strategic dependency. Record the build-vs-buy decision and its rationale either way.

To engineering: Use it when you need reusable facade base classes inside Orchestra-based packages and the consistency across orchestra/* outweighs the overhead. Otherwise prefer Laravel's native facade support or a ~50-line internal base class you own outright. Before adoption, close these questions: are we already on Orchestra Platform; what specifically does this give us that an internal base class does not, at named call sites; what is the exact supported matrix and what runs in CI; did v7 break facade base classes, aliasing, or resolution beyond the framework constraint, and is there a v6→v7 migration guide; who maintains it and on what cadence; and what is the license and security-disclosure path?

Integration and rollback: Treat v7.0.0 as a planned major, not a patch. Inventory every package and application referencing it, diff facade base classes and published config between majors, bump constraints on a branch, resolve illuminate/* and Symfony constraints against the lockfile, and run targeted regression over every static facade call site — that is the real regression surface, because facade changes fail at runtime, not at install. Upgrade a non-production target first, canary one production application with explicit rollback criteria, then roll out by cohort. Standardize on a currently supported Laravel version, never on the package floor, and keep facade usage behind internal adapters so call-site count stays bounded and the dominant failure mode — assuming a major is a drop-in because the only documented change is the framework constraint — never reaches production.