Cleaner Bundle Laravel Package

Product Decisions This Supports

• Data retention & lifecycle policy. The underlying lamoda/cleaner concept — declarative "cleaners" (what is stale) paired with "purgers" (how it is removed), executed in batches — is directly applicable to retention work: purging expired sessions, old audit/log rows, abandoned carts, soft-deleted records, and PII past its legal window. This feeds decisions about how long we keep data and how we enforce it.
• Compliance roadmap (GDPR/CCPA/DSAR). Supports scoping "automated erasure" as a roadmap item and defining acceptance criteria (dry-run mode, batched deletes, per-entity rules, auditable execution).
• Infrastructure cost / DB bloat. Gives a credible mechanism for a storage-reduction initiative: measurable table growth, pruning cadence, and expected savings.
• Build vs. buy vs. borrow. The strongest PM use of this repo is as a design reference, not a dependency. It informs the decision to build a thin, Laravel-native retention layer (Prunable models + scheduled commands + queued batches) instead of importing a third-party bundle.
• What it does not support. It is not a feature-flag, experimentation, or customer-facing capability. It is internal ops hygiene — low strategic surface area, so it should not consume roadmap capacity beyond a small maintenance workstream.

When to Consider This Package

Consider it only as reference material, not as an install. Signals against adoption are strong and unambiguous:

• Wrong ecosystem. Despite being surfaced as a Laravel/PHP package, this is a Symfony bundle. It will not drop into a Laravel app; you would be pulling Symfony bundle machinery into a framework that has native equivalents.
• Archived, unmaintained. Last release 2021-08-11, repository archived, 0 dependents, 2 stars. There is no security patching path — disqualifying for code that performs irreversible deletes on production data.
• Adoption risk. Zero dependents means no field validation, no community bug reports, and no Stack Overflow surface. Any defect is yours alone to find.
• Tiny value surface. The functionality is a few hundred lines of glue around batch deletes; the "buy" premium is not justified.

Criteria that would flip the decision: an actively maintained fork; verified compatibility with our PHP and framework versions; test coverage on the deletion logic; a documented dry-run/rollback story; and a security review of destructive operations.

Look elsewhere / build in-house when you are on Laravel — the framework already provides Prunable/MassPrunable models, chunked deletes, the scheduler, and queues. If you want off-the-shelf, evaluate maintained Laravel-native cleanup packages. Also look elsewhere if you need audit trails, referential-integrity safeguards, multi-database support, or any vendor SLA.

How to Pitch It (Stakeholders)

Recommendation: do not adopt as a dependency. Adopt the pattern.

We evaluated lamoda/cleaner-bundle for automated data retention. The design is sound — declarative rules, batched purging, framework integration — but the package itself is a poor fit: it is a Symfony bundle (we are on Laravel), it has been archived since 2021, and it has zero dependent projects. Shipping archived, unmaintained code that performs irreversible deletes on production data is an unacceptable operational risk, and the maintenance burden would fall entirely on us.

Proposed alternative: implement the same pattern natively in ~3–5 engineering days using Laravel's built-in Prunable models, queued chunked deletes, and scheduled commands. This gives us the compliance and storage-cost benefits with no third-party dependency, full auditability, and a dry-run mode we control.

Business value: reduced database growth and storage spend, plus a defensible, automated answer to retention requirements — delivered at low cost and low risk. Ask: approve the small build item and a defined retention policy per entity; do not approve a dependency on this package.