Rule Bundle Laravel Package

Product Decisions This Supports

• Scoping the promotions/pricing roadmap item. The bundle's decomposition — rules composed of conditions and actions, evaluated against a domain entity — is a concrete model of "does this discount/coupon/shipping rule apply?" It lets you reason about the build in three separable slices: rule modeling and persistence, rule evaluation, and rule authoring UI for merchandisers. Most teams over-commit by treating these as one deliverable; this package shows where the seams are.
• The build-vs-buy framing that actually matters. The highest-leverage decision your roadmap unlocks is not "which library" but "who owns pricing logic after launch" — merchandisers editing database-backed rules, or engineers shipping code. A data-driven rules engine (this pattern) is an order-of-magnitude more effort than hardcoded logic and permanently changes that ownership. Use this package as the strawman for that conversation.
• Architecture and vendor-risk input. Zero stars, zero dependents, a read-only mirror with only a README stub, and a dormant upstream suite. As a dependency it is a negative signal; as intelligence it tells you the open-source prior art in this space is thin and unmaintained, which nudges the recommendation toward owned, minimal implementations.
• Design-review prior art. When engineers propose an in-house rules engine, having a Symfony-idiomatic reference (persistable rule entities, expression conditions, discrete actions against a context) shortens the design debate far more than a blank page or a purely abstract spec.
• Legacy triage. If you inherit a Symfony/Elcodi-based commerce app, this is a reference point for judging whether existing promotion logic is recoverable or should be reimplemented.

When to Consider This Package

Consider it when:

• You are already on Elcodi (or inherited a Symfony app depending on it) and accept the read-only constraint as known; track the parent elcodi/elcodi repo, not this split.
• You need a worked example of modeling business rules as first-class, persistable entities in Symfony — as a design reference during a spike, not a runtime dependency.
• Your team is deeply Symfony-native and the alternative is an unvalidated bespoke design with no prior art.

Look elsewhere when:

• Anything requires ongoing support. The repo is explicitly read-only — no PRs, no issues, no maintainers here. A rules engine sits in the checkout/pricing path, which is business-critical; an unmaintained dependency there is an unacceptable concentration of risk.
• You are on Laravel or modern PHP/Symfony. The packaging is Symfony-specific (DI extensions, compiler passes, YAML service definitions) and won't boot under a Laravel kernel; framework-version and PHP 8.x compatibility are unverified. Adopting means forking and owning it forever.
• You need documentation or validation. There is no API documentation, no test suite in this artifact, and no changelog; onboarding cost is unquantified. Zero stars and zero dependents means no production signal — you'd be the first adopter with no path to a second.
• Maintained alternatives exist. Symfony's own ExpressionLanguage (plus a thin domain layer) covers condition evaluation; Sylius's promotion bundle is the live equivalent in the same ecosystem. Either gets you the functionality with a support story.

Bottom line: evaluate the parent Elcodi project or not at all. Do not adopt this artifact as a dependency.

How to Pitch It (Stakeholders)

For executives: This is not a product recommendation — it's competitive and architecture intelligence. elcodi/rule-bundle is a read-only mirror of a rules engine from Elcodi, a dormant Symfony e-commerce suite with no community, no support commitment, and no verified compatibility with current platforms. Recommendation: do not adopt. Its value is conceptual: it shows how a promotions/discount engine decomposes into rules, conditions, and actions, which helps us scope our own roadmap item without paying for discovery. If we pursue configurable promotions, we should build on Symfony ExpressionLanguage or a maintained commerce bundle — and we should decide early whether merchandisers or engineers own pricing rules post-launch. That decision, not the library choice, is the one with real cost implications.

For engineering: Treat elcodi/rule-bundle as prior art, not a dependency. It demonstrates the right conceptual seams — persistable rule entities, expression-based conditions, discrete actions evaluated against a context — and that decomposition is worth mirroring in our own domain model. It does not give us a maintained codebase, current-framework compatibility, docs, or a test suite in this artifact. It's also a read-only subtree split, so any fork is ours to own forever. Concretely: spend a day on a spike reading it for the data model, then design against Symfony ExpressionLanguage for evaluation and our own persistence layer. If someone wants to justify taking the dependency, the burden of proof is a working integration against our current PHP/framework versions plus a named owner for the fork — absent both, we build.