Quicksand Laravel Package

Technical Evaluation

What we are actually evaluating — resolve this first. The supplied materials describe two incompatible products. The repository metadata says scheduled cleanup of old soft-deleted Eloquent data; the package description says a migration dry-run sandbox that executes migrations in a transaction, prints SQL, and rolls back. These are different tools with different blast radii, different stakeholders, and different risk surfaces (a data-retention pruner versus a pre-deploy schema gate). Nothing downstream — scoping, staffing, security review, rollout — is safe until someone reads src/ and composer.json and confirms which one this is. I am proceeding on the assumption that the metadata is correct (soft-delete pruning), because that interpretation is consistent with the archive decision and with Laravel's native capability history, and I flag the sandbox interpretation where it diverges.

Architecture fit — poor as a dependency, good as a reference. Under the pruning interpretation, the core capability (scheduling deletion of aged soft-deleted rows) has been native to Laravel since v8 via Prunable / MassPrunable and model:prune. That is almost certainly why this package was archived: its reason to exist was absorbed by the framework. Adopting a third-party wrapper around a first-party primitive inverts the dependency direction for no gain. Under the sandbox interpretation, the architecture fit is materially better — a dev-only CI tool that validates migration SQL has no production runtime footprint — but the package is still frozen and still unmaintained.

Integration feasibility — technically trivial, organisationally non-trivial. Under either interpretation the code footprint is small: a --dev Composer require, one config publish, a scheduler entry (pruner) or a pipeline step (sandbox). The hard parts are not code. They are: (a) deciding retention windows per entity, which is a product and legal decision, not an engineering one; (b) tenant and legal-hold scoping, so a purge never crosses tenant boundaries or deletes records under hold; (c) relationship safety, so cascading deletes do not orphan or destroy dependent rows; and (d) under the sandbox interpretation, obtaining a database credential set with CREATE/DROP privileges that production grants almost certainly deny.

Technical risk — concentrated in the archive status. The dominant fact is that the repo is archived, the last release was 2024-03-12, and the newest documented change is Laravel 11 compatibility. There will be no Laravel 12 release. There are zero dependents recorded, so you will be the only party discovering breakage. Risk by interpretation:

• Pruning: low runtime risk (a scheduled job deleting rows), high governance risk (data loss if scoping is wrong), and a hard compatibility cliff at the next Laravel major. The compatibility cliff is the one that schedules work for you.
• Sandbox: low production risk (dev-only), moderate pipeline risk (failures can block deploys), and a credential-privilege conversation with platform/security that can stall the project independently of the code.

Key questions to resolve before any commitment.

1. Which product is this, per the source? Owner: engineering, within a day.
2. What Laravel versions does composer.json actually permit? Do not infer from the v2.7.0 release note. What is our upgrade horizon?
3. Under pruning: what are the retention windows per entity, and who signs off? Is there a legal-hold requirement? Are there warehouse/analytics copies that expect to see soft-deleted rows?
4. Under sandbox: do we have — or can we get — a non-production database and credential set with schema-mutating privileges, approved by security?
5. Is there an audit requirement on deletion events? If so, we need an archive or event log before we need a pruner, and this package does not provide one.
6. Who owns the internal fork if we take one? Because with an archived repo, adopting is forking in all but name.

Integration Approach

Stack fit — the pattern fits; the package does not need to. The relevant capability maps cleanly onto first-party Laravel: SoftDeletes on models, Prunable/MassPrunable on those models, prunable() constraints per retention tier, model:prune wired into the scheduler, and tests asserting rows past the window are gone while rows inside it survive. That is days of work, has a maintainer (the framework), and carries no dependency liability. The package's residual value is as a compact, readable reference implementation of the pattern — read it once, reimplement natively, then drop the dependency question entirely.

Recommended migration path — adopt in-core, use the package only as documentation.

1. Verify the product (one day). Read the source. Confirm pruning vs. sandbox. Everything below branches on this.
2. Inventory models using SoftDeletes, row counts on the underlying tables, and current table/backup sizes. This tells you whether the problem is real and where the pain is.
3. Define retention tiers as policy — short for transient records, longer for financial-adjacent, explicit legal-hold exclusions. Get product and legal to sign the windows. This artefact is the deliverable; the cron job is the easy part.
4. Implement Prunable in-core with tenant scoping and legal-hold exclusions written as constraints, plus relationship-safety decisions made explicitly in domain code with tests.
5. Wire model:prune into the scheduler, start in a non-production environment, observe a cycle, then promote. Add an assertion/test that the job is registered — silent scheduler failures are the classic mode here.
6. Only if step 1 returns the sandbox product: invert the plan. require --dev, dedicated sandbox connection and credentials, a CI job path-filtered to database/migrations/**, and a pre-deploy gate immediately before migrate --force.

Compatibility. The repo supports through Laravel 11 and is archived. If our roadmap includes a Laravel 12 upgrade, adoption converts a routine upgrade into an unscheduled fork-and-patch exercise. Treat "supports L11 only" as a dated dependency with a known expiry, not a stable floor. If the sandbox interpretation holds, the exposure is confined to local and CI environments — a failed install breaks builds, not production — which is a materially better risk profile and the one scenario where a time-boxed trial is defensible.

Sequencing. Policy first, then inventory, then implementation, then scheduling, then observation. Do not sequence it as "install package, then figure out retention." The policy is the long-lead item — it involves legal, support, and product — and it is the item that creates durable value. If the sandbox interpretation is confirmed instead, the long-lead item is the privileged credential and the security sign-off, and the sequencing is credential → CI job → pre-deploy gate → developer workflow.

Operational Impact

Maintenance. This is the deciding factor. An archived repository receives no security patches, no framework compatibility updates, and no fixes for edge cases we discover. The maintenance burden does not disappear — it transfers to us, and it transfers at the worst possible time (during an unrelated framework upgrade). In-core Prunable has a maintenance cost of approximately zero because the framework team carries it. Under the sandbox interpretation the ongoing burden is smaller — dev-only, contained blast radius — but we would still own any compatibility breakage, and a tool that blocks deploys is a tool that generates escalations when it misbehaves.

Support. There is no upstream to escalate to. Zero dependents means no community signal on failure modes. Our support model becomes "internal owner reads the source," which only works if we name that owner in advance. For a pruning tool the support questions are predictable and answerable: why did rows survive, why did rows disappear, why did the job not run, why did it run across tenants. Each one needs a documented answer in a runbook, regardless of build-versus-buy.

Scaling. Pruning is a cheap, high-leverage lever on storage, backup duration, index size, and scan performance — often a better first move than a migration-heavy archiving project. Two scaling caveats: (a) MassPrunable deletes in bulk and bypasses model events, so anything relying on deleted/deleting observers will silently not fire — decide deliberately which variant each model uses; (b) large purges on high-volume tables should be batched or chunked to avoid long locks and replica lag. Neither caveat is package-specific; both are reasons to own the implementation.

Failure modes to plan for.

• Silent non-execution. The scheduler is not running, the job was dropped from the kernel, or an exception is swallowed. Mitigation: alert on stale data — assert that the oldest soft-deleted row is never older than the retention window plus a margin.
• Over-deletion. A misconfigured window or missing tenant scope purges live data or crosses a tenant boundary. Mitigation: tenant constraints written into prunable(), legal-hold exclusions, a dry-run count before the first live run, and an irreversible-action review.
• Under-deletion / false compliance. The job runs but excludes the rows that matter, so the retention statement in the DPA is untrue. Mitigation: tests asserting both directions — past-window rows removed, inside-window rows retained.
• Relationship breakage. Parent purge cascades or orphans children. Mitigation: explicit domain rules with tests; do not let cascades surprise you.
• Backup/restore mismatch (pruning interpretation) — restoring an old backup reintroduces rows the policy says should be gone; retention needs to cover backups, not just the primary database.
• Pipeline breakage (sandbox interpretation) — the CI step fails on a connection/config error and looks like a migration error, blocking deploys for the wrong reason. Mitigation: assert the sandbox connection is reachable as the first step; clear and re-cache config around the step; never let the sandbox database name equal DB_DATABASE.

Ramp-up. Low, for either interpretation. A mid-level engineer can read the source in an afternoon and implement the in-core equivalent in one to three days, including tests. The genuine ramp-up cost sits with product, legal, and support — defining and documenting the retention windows, and deciding what a customer sees after a restore window expires. That work is unavoidable and is the actual value of the initiative; the package is incidental to it.

Recommendation. Do not take this as a production dependency. It is archived, unmaintained, and — under the metadata interpretation — superseded by Laravel's own Prunable/model:prune. Use it as a one-time reference implementation, ship the pattern in-core, and make retention windows an explicit, documented, legally-reviewed policy so support and legal have one answer instead of improvised ones. Under the alternate (sandbox) interpretation, the risk profile improves enough to justify a time-boxed, --dev-only trial behind a path-filtered CI check — but only after confirming what the repository actually contains and securing a schema-mutating credential that security has approved.