Auth Laravel Package

Product Decisions This Supports

• Build vs. buy for authentication and access control. orchestra/auth ships users, roles, ACL tables, and models on top of Laravel's native guards and providers. If a roadmap item reads "role-based access for admin users" or "self-serve password reset," this is a credible adopt-instead-of-build candidate — but only inside the Orchestra Platform, where it is already the sanctioned auth layer.
• A platform bet, not a feature bet. The decision this package actually forces is whether the product is on, or committing to, Orchestra Platform. Outside that context it is a thin wrapper over Laravel auth. Frame it as "are we an Orchestra shop?" — the auth package follows from that answer rather than driving it. If the answer is no, the honest comparison is Laravel's native auth plus a mainstream permissions package.
• Roadmap sequencing on access control. If roles, admin user management, or multi-tier capabilities sit in the next one or two quarters, adoption compresses delivery by removing schema, model, provider, and guard work. If authorization is a product differentiator — policy-driven, attribute-based, multi-tenant — the shallow scope here argues for building or buying a richer layer instead.
• Risk budgeting for a security-sensitive dependency. Zero dependents and a 0.3 score mean no external validation on the login path. The PM decision is whether owning a low-adoption auth dependency — with the audit, upgrade, and support burden that implies — is cheaper than a mainstream alternative with a large community and a disclosure process.
• Release-level triage. v5.0.1 replaces config() with the Config facade to fix a Class config not found exception during migrate:rollback from testing environments. Scope is CI/test stability only; no feature, data-migration, or roadmap implication. Approve as dependency hygiene if already adopted — it is not a signal of active feature investment.

When to Consider This Package

Consider it when:

• The application is built on Orchestra Platform and needs Laravel-consistent auth plus user/role/ACL management without introducing a second auth paradigm.
• You want configuration and APIs close to standard Laravel conventions so existing team knowledge transfers and retraining cost stays low.
• Your CI pipeline exercises migrate:rollback and you can pin ^5.0.1 to avoid the known rollback exception.
• A named owner exists for auth dependencies, and the team already has a relationship with the Orchestra maintainers or deep in-house Laravel auth expertise.
• Access-control requirements are conventional — named roles, coarse permissions, an admin surface separated by its own guard — rather than policy-driven or attribute-based.

Look elsewhere when:

• You are not on Orchestra. Standing up the platform to justify this package is a platform migration disguised as a dependency addition — scope and fund it as such, or skip it.
• You need a proven security posture: large community, frequent releases, third-party bug reports, an established disclosure path. Zero dependents is a weak signal for a security-critical dependency, and "probably delegates to Laravel" is not an acceptable security posture.
• Your roadmap needs advanced authorization — policy-driven, attribute-based, or multi-tenant scoping. The release record here shows maintenance, not feature investment.
• The support model is unstated. Get the maintainer's support expectations in writing before committing; "we use it, we fix it" is acceptable, but it must be explicit.

How to Pitch It (Stakeholders)

For executives. This is the authentication and access-control component of the Orchestra Platform — user, role, and ACL management layered on Laravel's native auth. It is not a strategic capability in itself; the decision is whether our platform commitment justifies relying on a niche, low-adoption dependency in a security-sensitive area. The latest release is a small reliability patch for a test-environment exception, with no feature or roadmap implications. Recommend: approve as hygiene if already in use; do not adopt on the strength of this release if we are not already on Orchestra.

For engineering. The package extends Laravel guards and providers with Orchestra-aware behavior and keeps configuration idiomatic, which limits lock-in at the call site even though the platform dependency is sticky. v5.0.1 is a low-risk patch — pin ^5.0.1 if the suite runs migrate:rollback, and add a CI job that runs migrate then rollback against a throwaway database, since that is the exact regression class fixed. Keep authorization behind Gate::define and policies so roles stay a data source rather than logic leaking into controllers and views. Before any production data touches it: confirm the supported Laravel/PHP matrix, whether the package hard-depends on Orchestra core, what the role/user helpers actually cover (schema and models versus policies and gates), and how password resets, email verification, remember-me, and session invalidation deviate from Laravel defaults. Validate under config caching and console bootstrapping, not just artisan serve.

For product. No roadmap or prioritization change follows from this release. If the package is in use, approve the patch and confirm a named owner for the auth dependency. If it is not in use, do not adopt on the strength of a one-line changelog — evaluate against the platform commitment, maintenance cadence, Laravel version support, and the support burden of owning a lightly adopted auth dependency. Any adoption outside Orchestra should be scoped as a platform migration project with a data-migration workstream and a rollback plan, not as a composer require.