Rule Laravel Package

Product Decisions This Supports

• Build vs. buy vs. borrow for a rules layer. If the roadmap includes any "when X happens, do Y" behavior — content targeting, eligibility checks, pricing/promotion logic, notification routing, workflow automation — this package is useful mostly as a reference design for how a rule/subject/condition model can be structured. Use it to inform the decision, not to make the decision.
• Dynamic content assembly and audience targeting. The component comes out of a publishing platform's rule evaluation layer, which is the same problem shape as personalizing a page, deciding which modules render for which segment, or auto-assigning content to a surface. If we are scoping a CMS/merchandising feature, this is a cheap way to pressure-test our data model (rule sets, conditions, matchers, evaluation order) before committing to a schema.
• De-risking custom business logic. Every hard-coded if chain in a product becomes a support burden and a release bottleneck. Reviewing a mature-ish rule-evaluation component helps Product argue for configurability (rules authored by ops, not deployed by engineering) with a concrete cost estimate instead of a vague "it should be configurable."
• Roadmap sequencing. If rule authoring (admin UI, rule builder, dry-run/preview, audit of why a rule fired) is on the roadmap, this code shows the minimum viable domain model we would need to build around it. That directly sizes the "authoring UI" epic.
• Buy-side shortlist construction. Its existence and limitations are useful evidence in an evaluation of alternatives we would actually ship: Symfony ExpressionLanguage, ruler/hoa/ruler style engines, or an external decision service. It sets the floor for "what a small library gets you" and therefore the bar for a paid/commercial option.

When to Consider This Package

Consider it only in these situations:

• You are already inside the Superdesk Web Publisher / Symfony component ecosystem and need the matching component version; the subtree split is the same code as the monorepo, so version alignment matters more than the package itself.
• You want a read-only reference implementation: a compact, real-world example of rule/condition modeling from a production publishing system to study before designing our own.
• You are running a short, time-boxed spike (1–2 days max) where the deliverable is a design note, not shipped code.

Look elsewhere — and by default, plan to not adopt — when:

• You need a Laravel package. This is a subtree split from a Symfony-oriented platform; do not assume service providers, facades, config publishing, or Laravel-native conventions. There is no Laravel integration story here.
• You need maintenance. Last release was 2018-06-11. Zero stars, zero dependents. No evidence of PHP 8.x compatibility, security patching, or an active maintainer. Anything we ship on it becomes our fork to own, forever.
• Licensing is unresolved. The license reports as NOASSERTION, which for a commercial product means legal review before any code is copied, not just before it is installed. Treat "we read it for ideas" and "we vendored it" as very different legal questions.
• You need documentation, tests you can run, or community support. None of that is implied by a 0-star, 0-dependent, read-only split. The issue tracker for real bugs lives in the parent repo, not here.
• The rule logic is core to the product. If rule evaluation is a differentiator, a 2018 snapshot is a bad foundation; either use a maintained expression engine or build a small one we control.

How to Pitch It (Stakeholders)

For executives (30 seconds): This is not a library we should depend on. It is a published snapshot of one component from an open-source publishing platform — zero adoption, no release since 2018, and an ambiguous license. Its value to us is informational: it is a worked example of how to model business rules, which is directly relevant to the configurability work on our roadmap. Recommendation: spend one to two engineer-days reviewing it as an input to a build-vs-buy decision, and do not add it to the dependency tree. Low cost, real design value, near-zero delivery risk.

For engineering (the actual ask): Treat swp/rule as a read artifact. Clone it, read the rule/subject/condition model and the evaluation flow, and produce a short write-up: what domain model would we need, what does this get right, what does it get wrong, and what would we build or adopt instead. Constraints to verify before anyone proposes installing it: PHP version compatibility against our runtime, the NOASSERTION license (legal sign-off required before vendoring or copying code), the subtree-split/read-only nature (patches do not flow back here), and the absence of Laravel integration. If the answer is "we want rules," the deliverable is a design doc and a shortlist — not a composer require.