Loggable Bundle Laravel Package

Product Decisions This Supports

Audit trails as a platform capability, not a feature ticket. This package's entire value proposition — automatically capturing insert/update/delete on domain entities with field-level old/new values, acting user, and timestamp — maps directly onto a class of product decisions that recur across roadmaps:

• Enterprise/compliance readiness. "Who changed this record, and what did it look like before?" is a procurement gate for SOC 2, HIPAA, GDPR subject-access requests, and financial/insurance buyers. Committing to an audit-logging approach now is what makes that checkbox cheap later instead of a scramble before a security review.
• Support forensics and reduce-to-practice. When a customer claims "my price changed" or "my record vanished," an audit table converts a multi-day engineering escalation into a support-console query. This is a measurable support-cost decision, not just a technical one.
• Customer-facing change history. The same data underpins "Recent activity" panels in B2B admin UIs. If the logging layer exists, that feature is a UI task; if it doesn't, it's a second instrumentation project.
• Build vs. buy vs. borrow-the-pattern. MIT-licensed and free, so licensing is not the variable — ownership is. The real PM decision is "adopt as dependency, vendor the pattern into our own codebase, or buy a maintained package in our actual stack." This repo is most useful as evidence for the third option's cost.
• Roadmap sequencing for adjacent features. Approvals, undo/restore, change notifications, and anomaly alerts all sit downstream of audit logging. The choice made here determines whether those later features are incremental or a rewrite.

The decisive product fact: despite being filed as a Laravel/PHP package, this is a Symfony bundle built on Doctrine ORM event listeners. On a Laravel/Eloquent stack it is not installable in any meaningful sense — it becomes a reference implementation you read in an afternoon. Any PM decision here should be framed as "adopt the pattern," not "add the dependency."

When to Consider This Package

Consider it when:

• The target application is Symfony + Doctrine ORM. This is a hard prerequisite, not a preference — the integration seam is Doctrine's unit of work plus the Symfony DI container.
• The requirement is entity-level change history with actor attribution across a modest number of entities — not event sourcing, not a full temporal database.
• Audit needs are internal-facing or contractual-but-basic: retained rows, human-readable diffs, no tamper-evidence, no cryptographic chaining.
• You intend to read it, not depend on it. With 0 stars and 0 dependents, the sane motion is: read the listener and the log entity (a small, self-contained pattern), reimplement it in your own namespace in a day or two, and eliminate the supply-chain risk entirely.

Look elsewhere when:

• Laravel stack → spatie/laravel-activitylog (broad activity logging) or owen-it/laravel-auditing (field-level before/after model auditing) are the mature, maintained equivalents. Do not port a Symfony bundle to avoid a dependency.
• Symfony stack with real requirements → Gedmo's Loggable extension or a hand-written EntityListener/EventSubscriber beats a zero-adoption bundle on every axis.
• Compliance-grade auditing → you need append-only/immutable storage, tamper-evidence, guaranteed-before-commit writes, and documented retention. A generic CRUD change-log will not survive an auditor's questions.
• PII or data-residency constraints → copying field values into a second table silently duplicates personal data. You need redaction and field allow-listing built in; this package won't provide it.
• High write volume on hot entities → double-writes on every update need batching or async capture. Assume this package does neither.
• Strict supply-chain gating → 0 stars / 0 dependents / no visible maintenance is an automatic flag in most dependency-scanning policies.

How to Pitch It (Stakeholders)

To executives: We evaluated a free, MIT-licensed audit-logging component — the "who changed what, when" trail that enterprise buyers and support teams ask for. It's a zero-adoption Symfony component, so it isn't something we'd depend on; it's something we read. Recommendation: treat it as a design reference and budget 1–2 engineering days to build the same capability natively in our own stack. We get the compliance checkbox, the support-forensics win, and a foundation for customer-facing activity feeds — with no third-party maintenance risk and no licensing cost.

To engineering: Framework mismatch is decisive. This is a Symfony/Doctrine bundle using onFlush-style listeners and DI wiring; on Laravel/Eloquent there is no seam to hook into without a Doctrine bridge, which is disproportionate effort for one concern. The extractable value is small and self-contained: a listener on entity writes that persists an append-only row of (actor, entity type, entity ID, field, old value, new value, timestamp). Two design points to settle before building: PII in log payloads (allow-list fields, redact the rest) and write amplification on hot entities (queue the write; never let an audit failure roll back the business transaction).

Bottom line: Low cost, low risk — if treated as a reference implementation. Poor fit as a live dependency on either framework. Approve as a design input and a source of requirements, not as an addition to the dependency manifest.