Laravel Policy Engine Laravel Package

Product Decisions This Supports

• Build vs. buy (buy side): dynamik-dev/marque is a pre-1.0 Laravel package that gives you a facade-driven API plus an internal caching layer and event dispatch. If your roadmap item is "expose X through a consistent Laravel-native API with caching and lifecycle events," this is a candidate to adopt rather than build — the plumbing (cache keys, event timing, facade surface) is the part that is easy to underestimate and tedious to get right.
• Feature scoping: Because the public contract is a facade, integrating it is a small surface area in your codebase. That lowers the cost of prototyping a feature behind it and makes it cheap to rip out if the package doesn't pan out — a useful property for exploratory roadmap bets.
• Roadmap risk flag: v0.2.4 is a patch release with no new features and no breaking changes. It fixes a cache key collision and event timing, plus duplicated logic. Both are silent-correctness bugs: a cache key collision means two logically distinct things can return the same cached value, and event-timing bugs mean listeners fire at the wrong point in the lifecycle. Neither shows up as an exception — they show up as confusing production data. Treat the package as "correctness still settling" and budget for verification work.
• Adoption sequencing: The docs fix ("consistent facade API") tells you the documentation previously diverged from the actual API. Anything your team wrote against the old docs is suspect. If you adopted at v0.2.3 or earlier, schedule a quick audit of your integration against the current facade signature.
• Use cases that fit: internal tooling, admin-panel features, and read-heavy paths where the caching layer is the point. Use cases that don't fit yet: anything where event-ordering is a correctness requirement for money, entitlements, or audit trails.

When to Consider This Package

Adopt (or pilot) when:

• You're on a modern Laravel version and want a facade-shaped API rather than hand-rolling another service class + cache wrapper.
• The caching behavior is a feature you want, not an obstacle — you can tolerate a package owning key derivation.
• You can pin the exact version in composer.json (0.2.4, not ^0.2) and re-verify on each bump.
• The feature is not on the critical path, or you have tests that would catch stale-cache and wrong-order-event bugs (assert the cache key space is disjoint; assert listener ordering explicitly).
• You're comfortable with a small-team, single-maintainer dependency and have a documented fallback if it stalls.

Look elsewhere when:

• You need a stability guarantee — v0.x means the API can break in a minor bump, and there is no 1.0 yet. If your org requires semver-stable dependencies, wait or vendor/fork.
• Event timing is load-bearing for correctness (billing, permissions, audit logs). The v0.2.4 event-timing fix is a signal that this area is still being shaken out; own that ordering yourself or use Laravel's native events directly.
• Your cache strategy is bespoke (tagged caches, per-tenant key namespacing, Redis cluster constraints). A package that derives keys internally will fight you, and the collision fix in this release is direct evidence that internal key derivation is a place where you have no visibility.
• You need breadth of documentation, community answers, or a support contract — none of that exists at this stage.

How to Pitch It (Stakeholders)

For executives: We're evaluating a small open-source Laravel component rather than building equivalent plumbing ourselves. It's early-stage (v0.2.4, pre-1.0) and maintained by a small team, so the recommendation is a contained pilot, not a platform commitment. The latest release is pure bug-fixing — one fix addresses a cache collision that could have produced quietly wrong results, another corrects when internal events fire. That's a healthy maintenance signal (someone is hunting real defects) but also a maturity signal: this is software still finding its footing. Cost of trying it is low because the integration surface is a single facade; cost of being wrong is bounded.

For engineering: v0.2.4 is a patch — no API changes, no migration required. Two things to internalize: (1) the cache key collision fix means caches populated by earlier versions may contain values written under colliding keys; flush the relevant cache namespace on upgrade rather than trusting existing entries. (2) The event timing fix changes when listeners fire; if we have listeners with side effects, review them against the new ordering instead of assuming parity with v0.2.3. The docs correction means our integration notes may reflect an older facade signature — reconcile before we write more code against it. Pin to 0.2.4 exactly, add tests that pin cache-key disjointness and listener order, and re-read the changelog on every bump.