Filament Logger Laravel Package

Product Decisions This Supports

• Feature scoping: "admin activity visibility" as a bounded deliverable, not a program. The concrete user story this satisfies is internal: "who changed this record, and when?" — for support triage ("the invoice looked different yesterday"), ops accountability, and debugging admin-side edits. It is a one-afternoon integration on a stack we already run (MIT, one-line plugin registration, config-driven), which makes it a cheap answer to a recurring request rather than a sprint-sized investment.
• Roadmap positioning: table stakes, deliberately undersold. Once an admin panel has more than two or three human users, "can we see what people did?" arrives predictably. Scoping this as a small contained feature lets us say yes without opening a compliance workstream we are not staffed to own.
• Build vs. buy: adopt for the narrow version, build for the real one. Adopt when the requirement is literally "see recent admin activity inside the panel" on a current Laravel/Filament stack. Build deliberately — or buy a heavier platform — the moment the requirement includes retention policy, tamper-evidence, legal hold, SIEM export, PII redaction guarantees, or tenant isolation. None of those are in v5.0.0, and pretending otherwise is the main way this decision goes wrong.
• Pricing/effort framing: the license is free; the lockstep is not. v5.0.0 targets Filament 5 / Livewire 4 / Laravel 12–13 / PHP 8.2+, and the Filament 3 line is a separate v3 branch. Adopting means tracking an upstream major cadence in step with our own framework upgrades. That is a recurring maintenance tax on the roadmap, not a one-time install cost — and it belongs in the same line item as the framework upgrade it is chained to.
• Prioritization signal: a time-boxed pilot, not a platform bet. v5.0.0 measurably improves the engineering case — Pest suite, CI across Laravel 12/13 and PHP 8.3/8.4, and fixes for a MySQL-transaction failure on clear, a double-registered email-verification listener, an N+1 on the causer, and Livewire update-request noise. But the adoption evidence is still thin (15 stars, zero dependents, opportunity score 7.3). It is now a better-tested product risk, not a smaller one.
• Use cases that fit: internal admin panels, back-office SaaS at low-to-moderate write volume, support/ops workflows, early incident smoke signals, prototype-stage evidence for a future audit conversation.
• Use cases that don't: SIEM replacement, legal or forensic trails, regulated audit evidence (SOC 2, ISO 27001, HIPAA, PCI), bulk-import-heavy or high-security environments, or any surface where non-admin end users can reach the log page.

When to Consider This Package

Consider it when:

• The product is already Laravel + FilamentPHP for internal surfaces, and is on — or has a dated plan to reach — Filament 5 / Livewire 4, Laravel 12+, PHP 8.2+.
• The need is visibility and troubleshooting, and that framing survives contact with legal/security. The moment someone says "audit trail," escalate before adopting.
• Expected write volume is modest and bounded: admin edits, settings changes, a handful of records per user action — not bulk imports or queued jobs touching thousands of rows (each entry is an INSERT plus a serialized payload).
• The team can pin an explicit major (^5.0 or the v3 equivalent), commit the lockfile, read the source, and verify event coverage against our own auth and impersonation flows.
• Someone owns authorization: a freshly registered plugin page is visible to anyone who can reach the panel. Gating it behind a policy is mandatory work, not a nice-to-have.
• Someone owns retention and redaction: a scheduled prune, indexes on created_at and the causer column, and a stance on never serializing password hashes, tokens, or PII into properties.

Look elsewhere when:

• Audit logging is contractually or regulatorily bound. You need tamper-evidence, formal retention, legal hold, and export — commission that work; do not let this package occupy its roadmap slot.
• You need database-grade querying, alerting, model-level before/after diffs, SIEM export, or long-term archival.
• You need PII redaction, multi-tenant isolation, or granular data-access controls out of the box. Redaction here is a convention, not a guarantee.
• The plan requires the "Clear Activities" button as a retention mechanism. v5 correctly moved from TRUNCATE to DELETE for MySQL transactional safety, but it is a row-by-row purge that degrades as the table grows. Size volume before relying on it.
• You are staying on Filament 3 / Livewire 3 / Laravel 11 or older — that's the v3 branch, a separate maintenance line with no announced support window.
• The product doesn't use Filament, or the admin panel isn't a primary operational surface. The entire value proposition is "review activity without leaving the dashboard."
• You already run spatie/laravel-activitylog. The overlap is now substantial; writing both means two schemas, two tables to prune, and two sources of truth. Pick one per event set.

How to Pitch It (Stakeholders)

To executives: This is a small, low-cost addition to the admin panel that answers a recurring operational question — "who changed this, and when?" It ships in an afternoon on infrastructure we already run, is MIT-licensed, and can be restricted to admins. The caveat belongs in the same breath: this is an operations convenience, not an audit or compliance control. If a regulated audit lands on the roadmap, we budget a separate, purpose-built effort and this package does not substitute for it. Approve it as a contained feature with a named owner for access control and data retention; decline it if the actual ask is auditable evidence.

To engineering: Integration is a single plugin registration plus a config file, but three things are non-negotiable in the PR: (1) pin the major explicitly — v5 requires Filament 5 / Livewire 4 / Laravel 12–13 / PHP 8.2+, and the Filament 3 line is a hard fork on v3; (2) write through FilamentLogger::log(), not Log::info() — anything sent to a Laravel log channel never reaches the panel; (3) log per-model via observers on the models that matter, not globally, or the table becomes an unreadable firehose within a week. Beyond that: set a policy gate on the page before deploy, disable event logging around bulk imports and queued jobs, add a prune job, and redact before write — prefer array_keys($model->getChanges()) over values. Watch the v5-specific behaviour changes (DELETE instead of TRUNCATE, eager-loaded causer, the removed EventServiceProvider subclass) if we're upgrading rather than installing fresh.

To support and ops (the actual users): You get a searchable, filterable "recent activity" view inside the panel you already use — no separate tooling, no ticket to engineering to check whether a record changed. What it will not do is reconstruct full before/after values or serve as evidence in a dispute; for those, escalate to engineering.