Keystone Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for authentication/authorization. This package is the Symfony integration layer for the Keystone auth library — it informs the "do we roll our own RBAC or adopt a library" decision for role/permission checks, user credentials, and back-office access control.
• Artifact selection within a supersession chain. The bundle is explicitly superseded by treehouselabs/keystone-bundle. The decision this supports is which fork to pin in a dependency manifest — not whether to adopt the concept at all.
• Legacy roadmap and decommissioning. If any internal service still resolves this bundle, that is a roadmap item: inventory, replace, and retire. Last release 2014-03-18 and archived status mean ongoing usage is technical debt with a deadline, not a feature investment.
• Use cases it historically served: gated admin panels/CMS back offices, per-role permission checks in controllers, session-based user auth for Symfony 2.x apps. These are now table stakes served by framework-native primitives.
• Explicit non-decision: despite being catalogued as a Laravel/PHP package, this is a Symfony bundle. It should not enter any Laravel roadmap discussion. Flag the taxonomy mismatch in the catalog itself as a diligence defect.

When to Consider This Package

Consider it only under all of the following:

• You are maintaining a Symfony 2.x-era codebase (circa 2013–2014) where Keystone is already a transitive dependency.
• You need a reproducible/hermetic historical build or an archival environment.
• Even then, prefer the named successor over this artifact.

Look elsewhere when any of these hold:

• Greenfield work, Laravel, or Symfony 4+ — hard no.
• You require a security-maintained dependency: archived, no release in 10+ years, 0 dependents, 3 stars means zero community review and zero upstream patching. That is an unpatched-CVE liability, not a component.
• You need SSO/OIDC/MFA, audit logging, or compliance evidence (SOC 2, ISO 27001) — none of that exists here.
• You are evaluating the successor: treehouselabs/keystone-bundle is itself dated; run the same abandonment checks before pinning.

Recommendation: no-go. For Laravel, use framework auth plus a maintained authorization package. For Symfony, use the Security component with voters/attributes. Note the composite score of 0.36 with opportunity at 0.27 — low upside, and every risk flag (archived, abandoned, unmaintained, zero adoption) is present simultaneously.

How to Pitch It (Stakeholders)

Executives: This is an archived Symfony bundle last released in March 2014, superseded by another package, with zero dependent projects and negligible community traction. Adopting it buys no capability we can't get from framework-native auth, while adding an unmaintained code path — a direct security and audit exposure — plus an unhireable dependency. I recommend declining and recording it as an evaluated-and-rejected option.

Engineering: Mechanically it's a thin Symfony wrapper over the Keystone authorization library; the interesting decisions live in that library, not the bundle. If we encounter it in the wild, the sequence is: inventory usage with a short time-boxed spike, migrate to framework primitives (or the named successor if a lift-and-shift is genuinely cheaper), then delete. No new code should take a dependency on it, and we should not vendor-patch it.

The one-line ask: Reject for new work, budget a small discovery ticket to confirm no live usage, and correct the catalog entry so this stops surfacing as a PHP/Laravel candidate.