Php Laravel Package

Product Decisions This Supports

• Feature/architecture decision: whether policy logic (eligibility, tiering, discount rules, approval thresholds, entitlement gating) lives in code paths scattered across controllers/models, or in one declarative, testable rules layer. This package is the "centralize it" option.
• Build vs. buy: you're weighing a small maintained dependency against hand-rolling an evaluator. Buying gets you the rule schema + evaluation loop; the cost is a pre-1.0 dependency and coupling to a Laravel major.
• Roadmap sequencing: scope this to internal tooling, admin-configurable rules, or non-revenue surfaces until the package reaches 1.0. Do not schedule it on a revenue-critical path at v0.x.
• What v0.3.0 actually tells us: this is a maintenance-only release — ~30 Dependabot bumps, zero features, zero API changes, zero deprecations. The only product-relevant signal is that illuminate/* moved from 11.x to 12.x (Laravel 12), which is a platform-compatibility axis, not a capability. Plan for no roadmap impact; track it only as a compatibility check for teams still on Laravel 11.
• Secondary signal: the bump set includes Rector, Pint, PHPStan 2.x, phpstan-phpunit, and spaze/phpstan-disallowed-calls. That's a real quality gate for a small library — useful evidence of stewardship when justifying the dependency. Note also the Node bumps (express, cookie, elliptic) — likely a docs site, which hints at a small project footprint.

When to Consider This Package

Adopt when:

• Rules change frequently and are partly owned by non-engineers; you want them declarative, versionable, and unit-testable rather than recompiled into PHP.
• You're on Laravel 12 and can pin the major. This release moved illuminate/http, support, and collections to 12.x; if you're committed to Laravel 11, verify the constraint before adopting — the floor may have moved.
• You can afford to wrap it behind your own internal interface, so a breaking minor release is a one-file change.
• The evaluation surface is internal or recoverable (wrong answer = support ticket, not a billing incident).

Look elsewhere when:

• You have a handful of static rules — plain PHP and a test suite win on cost, clarity, and zero dependency risk.
• You need compliance-grade rule versioning, approval workflows, or an editor UI; that's a BRMS or a build, not this.
• You require long-term support commitments, security SLAs, or a maintainer bench. Pre-1.0 plus a likely single-maintainer footprint is the wrong risk profile for that.
• Your org's policy forbids pre-1.0 dependencies on anything customer-facing.

Gate to watch: the 1.0 milestone (or explicit semver stability statement) is the go/no-go for production-critical placement.

How to Pitch It (Stakeholders)

Executive summary: A lightweight, Laravel-native option for making business policy configurable instead of code-change-bound — faster iteration on eligibility, pricing tiers, and gating logic without engineering rework. It is pre-1.0, so we're recommending a contained pilot on internal surfaces, not a platform commitment. v0.3.0 was pure dependency maintenance: no new capability, no breaking changes, and the team kept its static-analysis and formatting toolchain current — a positive stewardship signal but not a reason to accelerate.

For engineering: Laravel-native consumers of illuminate/http, support, and collections; evaluated with PHPStan 2.x (incl. disallowed-calls), Rector, and Pint. Low integration cost. Recommendation is to adopt behind a thin internal interface so the dependency can be swapped or removed without touching call sites.

Risk statement: Dependency risk, not functional risk. The meaningful axis is Laravel major tracking — we're now on illuminate 12.x. Combined with 0.x semver, expect breaking minors.

The ask: one engineer-week spike — wrap the evaluator behind an internal abstraction, port two real rules, measure whether policy changes actually get faster. Decision date tied to the package's 1.0.