Logical Permissions Laravel Package

Technical Evaluation

Architecture fit. ordermind/logical-permissions is a framework-agnostic PHP library that models permissions as nested arrays evaluated through logic gates (AND/OR/NOT). Architecturally it is an evaluation engine, not an authorization framework: it does not ship a Laravel service provider, config, facade, migrations, or a Gate/Policy bridge. That makes it a plausible domain layer underneath Laravel's native authorization, but it will never be a drop-in. Expect to own the adapter (service provider binding, interface, DTO mapping) ourselves.

Integration feasibility. Composer-installable and conceptually simple; a proof-of-concept wrapping the evaluator behind an interface and exposing it through Gate::before or a custom policy is roughly 1–2 engineer-days. The real unknown is constraint compatibility (PHP version floor, PSR dependencies) against our Laravel/PHP baseline, which must be verified before any commitment. Because the package evaluates in-memory structures, the source of permission data (DB, config, cache) remains entirely our problem — no persistence, no query layer, no tenant model.

Technical risk — high. The maturity signals are poor across the board: 4 stars, 0 dependents, single-maintainer project, overall score 0.05. There is no ecosystem validation, no downstream projects to infer battle-testing from, and no evidence of a security disclosure process — in a security-sensitive domain (authorization), that combination is a material red flag rather than a minor one. Abandonment risk is real, and an abandoned authz dependency can block framework upgrades. The MIT license at least permits vendoring or forking if we choose to internalize it.

Key questions to resolve before adoption.

• What PHP versions and dependency ranges are declared, and do they satisfy our Laravel baseline?
• Is there CI, and what is actual test coverage of gate nesting/precedence edge cases?
• How are AND/OR precedence and deep nesting resolved — is the semantics documented and deterministic?
• Does it handle malformed/cyclic permission arrays safely (exceptions vs. silent mis-evaluation)?
• Is there any caching or memoization, or is every check a fresh traversal?
• What is the maintainer's release cadence and issue responsiveness over the last 12 months?
• Is there a documented security policy / CVE history?

Recommendation. Do not adopt as a production dependency on current evidence. It is acceptable for a time-boxed spike or as reference implementation to copy concepts from. If the gate semantics genuinely fit our model, the defensible path is vendor/fork under MIT with our own tests and ownership — not a live upstream dependency in the authorization path.

Integration Approach

Stack fit. Pure PHP + Composer, so it slots into a Laravel codebase without framework conflict — the absence of framework coupling is simultaneously its main technical virtue and the reason integration cost is non-trivial. Our stack must supply everything around it: permission persistence, tenant scoping, caching, invalidation, and the enforcement point.

Migration path. Position it as an isolated evaluation engine behind a first-party PermissionEvaluator interface. Laravel's Gate/Policy remains the single enforcement choke point; the package is called from the gate, never instead of it. This lets us swap implementations (native gate closures, spatie/laravel-permission, or a fork) without touching call sites. If we currently have bespoke nested-array permission logic, this is a candidate replacement for exactly that slice — nothing wider.

Compatibility. Verify composer why-not against our PHP and Laravel versions during the spike; treat any constraint conflict as a stop signal rather than something to work around with aliasing. Confirm PSR/psr/log-style transitive dependencies do not pin versions we need elsewhere. Because the library is framework-agnostic, Laravel major upgrades will not be gated by it — but PHP minor upgrades might be.

Sequencing.

1. Spike (≤3 days): install in a sandbox branch, encode 10–15 representative permission scenarios from our real policy set, compare output against current behavior.
2. Adapter: define the interface, bind it in a service provider, wrap calls behind Gate.
3. Parity tests: golden-file/table-driven tests asserting old vs. new evaluator agree on every scenario, including negative and malformed inputs.
4. Shadow mode: run the new evaluator in parallel in non-enforcing mode, log divergences, fix or reject.
5. Cutover behind a feature flag with a one-line rollback to the prior evaluator.
6. Decide ownership: if adopted, fork to an internal namespace and pin a commit; do not track upstream dev-main.

Operational Impact

Maintenance. Assume we own it. A single-maintainer package with zero dependents has no implicit maintenance guarantee; we should budget for periodic compatibility patching or a one-time fork. Vendoring converts an unknown upstream risk into a known internal cost, which for authz is usually the better trade.

Support. Community-only, effectively nonexistent at this scale — no vendor SLA, no Stack Overflow corpus, no downstream users to consult. On-call engineers will be reading source, not docs. That is acceptable for a well-understood evaluator and unacceptable if it grows into a core platform capability.

Scaling. Evaluation is CPU-bound array traversal per check, with no visible caching layer. For moderate rule sets (tens of permissions, shallow nesting) this is fine; the risk is rule-set growth and deep nesting turning every request into repeated traversal. Permission data sourcing, request-level memoization, and cache invalidation are all our responsibility and should be designed up front — budget for a cache keyed on user/tenant/role version.

Failure modes to design against.

• Silent mis-evaluation — the worst case: a logic-gate bug grants or denies incorrectly with no error. Mitigate with parity tests and shadow-mode divergence alerting, not just unit tests.
• Malformed or cyclic permission arrays — unknown whether these throw or degrade silently; test explicitly.
• Deep nesting / precedence ambiguity — engineers misreading AND/OR ordering; document semantics and lint permission definitions at authoring time.
• Abandonment drift — upstream goes quiet, PHP upgrade lands, dependency blocks the platform. Mitigate with a fork or a pinned commit and a scheduled review.
• No fallback path — if the evaluator is called directly from controllers, swapping it later is expensive. Enforce the gate/interface boundary in code review.

Ramp-up. The API surface is small, so onboarding cost is low in the happy path — but the team must internalize gate semantics (nesting, precedence, negation) to avoid authoring subtly wrong permission definitions. Treat permission-definition review as a security review, and pair the spike with a short internal write-up of the semantics before any broader rollout.