Tartarus Laravel Package

Product Decisions This Supports

• Build vs. buy on "undo" for destructive actions. Every admin panel ships a delete button, and every delete button eventually produces a "can you get that back?" ticket. The real decision is whether to fund a bespoke restore/force-delete console — resource, filters, permissions, audit trail, pruning job — or adopt a package that supplies the browse/restore/purge surface. Tartarus is a buy candidate for a narrow slice: a Filament resource over soft-deleted Eloquent records. It reframes the question from "should we build a recycle bin?" to "is this good enough, or do we need a better one?"
• Turning data retention into an explicit product promise. A retention window plus automatic pruning is a product decision wearing a config value's clothes: how long do we promise recoverability, and how long do we keep deleted data at all? Answering that in writing early — 30/90/365 days, or "never, for regulated records" — is cheap. Discovering your answer accidentally during a customer security review is not. This package makes the question concrete and forces a defensible default into the roadmap.
• Cutting support and incident cost without headcount. The measurable win is not engineering hours saved but a class of tickets that stops arriving: "I deleted the wrong record," "the client removed a project by mistake," "restore this before the board meeting." If support or CS currently has a manual-restore ritual — direct DB edits, one-off scripts, escalating to an engineer — that ritual is the business case, and it is quantifiable from ticket history before you commit a sprint.
• Stack coherence as a roadmap constraint. Tartarus lives in the Lara Zeus/Filament family. If your admin or internal tooling is already Filament-based, this is a plugin-family-coherent option: shared conventions, styling, and upgrade cadence. If you are not on Filament, this is the tail of a much larger adoption decision and should be framed that way up front rather than discovered mid-sprint.
• Forcing the "recycle bin vs. audit trail" distinction. These get conflated in requirements constantly. A recycle bin answers "can we get the record back?" An audit trail answers "who changed what, when, and why?" Tartarus is the former. Deciding explicitly that compliance-grade history is a separate initiative prevents a false sense of coverage and keeps the compliance story from being quietly absorbed by a UI feature.

When to Consider This Package

Adopt when:

• Your admin/support surface is Filament-based and you want a recycle bin without building one. This is the single strongest criterion — outside Filament, the value proposition largely evaporates.
• You already use (or are willing to standardise on) Laravel SoftDeletes for the models in question. The package hooks the trait; it does not invent a deletion model for you.
• There is a recurring, named manual-restore workflow today that you can point at. If nobody has ever asked to restore deleted data, you are buying a feature, not solving a problem.
• The blast radius is containable: start with one or two high-anxiety models (content, contacts, transactional records) where accidental deletion is a support ticket, not regulated data.

Look elsewhere or build your own when:

• You need multi-tenancy. The repository description says "simple multi tenants," while the documentation describes a recycle bin. Assume the description is stale until engineering confirms otherwise; if a tenancy resolver is what you actually need, this is the wrong package (see stancl/tenancy or spatie/laravel-multitenancy). Treat that metadata mismatch as a documentation-hygiene signal on a package with ~10 stars and zero dependents.
• You need audit/compliance-grade history — immutable logs, field-level diffs, chain-of-custody. A recycle bin is not that.
• You are multi-tenant and the bin must respect tenant scoping. If the package's internal queries bypass global scopes, a support user could restore a record into a tenant they should not see. Engineering must verify this in source before you promise anything; it is the highest-risk item on the integration.
• Restoration has business side effects your model does not reverse — cancelled subscriptions, revoked invitations, archived files. That reversal logic is yours to build regardless of the package.
• You need vendor-grade assurance: SLAs, security review artefacts, or a support contract. Small OSS with no dependents means your team is the QA function.

Before committing, demand evidence of one afternoon's viability: installed and migrated on a scratch branch, one model wired end to end, delete → appears in bin → restore → record and relations intact → force-delete → gone. Pin the exact version and wrap it in your own tests. The MIT licence and small source mean forking is cheap — that is the real mitigation, but only if your tests tell you when a fork is needed.

How to Pitch It (Stakeholders)

For executives — the one-paragraph version: "Our admin panel has a delete button and no undo. Every mistaken deletion becomes a support ticket, a manual database edit, or an engineer's afternoon. This package adds a recycle bin to the admin panel — support staff can find a deleted record, see it, and restore it with a click, inside the permissions we already enforce. It is a small, MIT-licensed dependency from a family of plugins we already use, and it converts a recurring operational cost into a feature. The decision it forces is a real one: how long do we promise to be able to recover deleted data, and how long do we retain it? We should answer that deliberately rather than by accident. Proposed approach: a time-boxed trial on our two most-deleted record types, measured against the restore tickets in our queue, before any broader rollout."

For engineering — what you are actually agreeing to:

• Scope is narrow and honest: a Filament UI over Laravel SoftDeletes. It is not a tenancy package and not an audit trail, despite the stale "simple multi tenants" repository description. Confirm the shape by reading src/ and the published config before writing integration code.
• The work is not the install; it is the edges. Unique-constraint collisions on restore (a re-registered email), parent/child relation integrity, side-effect reversal on restore, force-delete gating, and — if we are multi-tenant — whether internal queries bypass global scopes. Budget accordingly.
• Risk posture: ~10 stars, zero dependents, a changelog that is mostly dependency bumps. Pin the version, own the tests (delete → assert in bin → restore → assert intact), and keep customisations in subclasses so upgrades stay cheap. Forking is viable and low-cost because the source is small.
• Ask for: one model wired end to end behind our own feature test, a written retention decision, and an explicit canForceDelete() policy before anything reaches production.

The framing to avoid: selling this as a data-safety or compliance feature. It is a support-ergonomics feature. Presenting it as the former invites a security review it will not survive and sets an expectation the package was never built to meet.