Rulerz Bridge Laravel Package

Product Decisions This Supports

• Whether to add a declarative business-rules layer at all. RulerZ lets rules be written as a compact DSL (e.g. customer.orders > 3 and customer.tier in ["gold","silver"]) and compiled to executable queries against arrays, Doctrine ORM/DBAL, or Elasticsearch. This package is only the Symfony DI wiring that registers compilers, operators, and the executor service. The product decision it informs is "do we want pricing/promotion/segmentation/eligibility logic stored as data and evaluated by an engine, instead of expressed as PHP conditionals?"
• Time-to-change for commercial policy. If the org's pain is that changing a free-shipping threshold, a coupon eligibility rule, or a merchandising boost requires a sprint and a deploy, an embedded rules engine converts those into configuration changes. That is the headline business case — measure it as release cadence for policy changes, not as an engineering nicety.
• Build vs. glue vs. buy. Three real options: hand-write conditions with symfony/expression-language (cheap, familiar, no DSL), glue OSS RulerZ into the stack (this package's role, zero license cost but real ownership cost), or buy a managed rules/flagging/decision service (SLA, authoring UI, audit — and a recurring fee). This package represents only the middle option and should be scored on total cost of ownership, not on price.
• Roadmap sequencing: embedded vs. authoring UI. This bridge supports the embedded path only — rules authored by engineers/technical ops in config, no editor, no validation UX, no audit trail, no versioning. If the roadmap eventually needs business users authoring and previewing rules, that is a separate product build (decision tables, dry-run, approvals), and adopting this package now does not get you closer to it.
• Use-case scoping. Concrete candidates worth mapping onto the roadmap: customer segmentation and audience targeting, promotion/coupon eligibility, tiered pricing and free-shipping thresholds, search and category merchandising rules (pin/boost/exclude), content personalization, and feature/limit gating.
• Architecture and competitive context. It originates from Frontastic (commercetools), so it is a visible signal of how that platform models rules internally — useful even if you never take the dependency.
• Make-vs-fork. It is thin, MIT, and small enough to vendor or reimplement as roughly a service provider plus registrations. That makes "fork it" and "skip it" both credible options, which is itself a decision the PM should force rather than let default.

Important framing correction: despite the "Laravel/PHP" label, this is a Symfony bridge, not a Laravel package. There is no Laravel service provider here. On a Laravel stack the realistic path is to adopt RulerZ core directly and write your own small service-provider binding — which means the decision is about RulerZ, and this repository is best treated as a reference implementation of the wiring pattern.

When to Consider This Package

Consider it when all of the following hold:

• The stack is Symfony and rules should be resolved through the DI container, tagged services, or config — this is a bundle/bridge, not framework-agnostic.
• You need one rule syntax evaluated across heterogeneous targets — e.g. a Doctrine query in production and an in-memory collection for preview — which is RulerZ's actual differentiator.
• Rules are authored by engineers or technical ops in configuration, not by business users in a UI.
• You accept that you will own, pin, and possibly vendor the code: 0 stars, 0 dependents, no maintenance signal, no security response, no upstream support.
• You can absorb version drift. Bridges of this vintage typically pin older Symfony/PHP constraints; verify composer.json against your runtime before it enters a roadmap.

Look elsewhere, or plan to fork/wrap, when:

• You are on Laravel. There is no Laravel integration here; budget for hand-wiring RulerZ core behind your own interface instead.
• Supply-chain review matters. Zero stars and zero dependents is a straightforward "no" in a regulated environment without an internal owner and a fork path.
• You need maintained dependencies — PHP 8.2+/Symfony 6–7 guarantees, LTS, or a release cadence. Assume you patch it yourself.
• Business users must author rules. You need a UI, validation, dry-run/preview, versioning, and approval workflow — a product build, not a package.
• The logic is simple conditionals. symfony/expression-language, config flags, or plain feature toggles will be cheaper to own and easier to reason about.
• You need predictable latency at scale. Verify per-target compile and evaluation cost, and that filtering pushes down into the query rather than running in PHP per item.
• You want a vendor relationship or SLA.

How to Pitch It (Stakeholders)

To executives: This is a small, free, MIT-licensed adapter that lets a Symfony service run business rules — promotion eligibility, customer segments, merchandising and content targeting — as configuration rather than code, so a threshold or segment change does not require a deploy. The value is time-to-change for commercial policy, not the package. Be upfront on two caveats: it is Symfony-only (so on our Laravel services it would be RulerZ core plus our own wiring), and it has essentially no adoption or maintenance footprint, so we would own it outright rather than rely on a vendor. Recommendation: fund a time-boxed spike, treat the package as a reference implementation, and come back with a go/no-go on embedding a rules layer this quarter — choosing between an in-house wrapper around RulerZ (our default), plain expression language if the rules stay simple, or a managed rules platform if a business-user authoring UI becomes a requirement.

To engineering: This is Symfony DI glue over RulerZ — it registers rule compilers, operators, and the executor so services can apply the same DSL against Doctrine, arrays, or Elasticsearch. It is thin, readable, and MIT, so it is cheap to fork or replace with roughly a hundred lines of our own service provider. Treat it as a design input: copy the wiring pattern, pin exact versions and commit the lockfile, and verify PHP/Symfony constraints before it touches a production composer.json. Run the spike two ways — install the bridge, then hand-wire RulerZ core directly — and if the hand-wired version works in under a day, take core and drop the dependency. Either way, isolate everything behind our own RuleEngine interface and Rule value object so no domain code imports third-party classes, and land that interface plus a feature flag before any business rule moves into the DSL.

Non-negotiables if we adopt: a named internal owner, a fork/vendor path, rule versioning and validation at authoring time (not evaluation time), cached compiled rules, and dry-run/preview before activation — because the worst failure mode is a silent misclassification after a rule edit, which looks exactly like normal operation. The package gives us none of that; it is our obligation, not its feature set.

Ask: approve a short, time-boxed evaluation to confirm stack compatibility and measure the build-vs-glue delta. The deliverable is a decision, not a dependency.