Tracker Bundle Laravel Package

Product Decisions This Supports

Framing correction that changes the decision: despite the request describing it as a Laravel/PHP package, kronhyx/tracker-bundle is a Symfony bundle. It assumes Symfony kernel/DI wiring and, in practice, Doctrine ORM lifecycle events. It will not install into a Laravel application without a port of the event-listener layer onto Eloquent observers. If our stack is Laravel, this package does not inform a build-vs-buy decision — it is the evidence for "build."

Where the underlying capability — entity change tracking / audit history — legitimately informs product decisions:

• Enterprise sales qualification. "Who changed this record, when, and from what value to what value" is a recurring checkbox in B2B security questionnaires and an increasingly common blocker in security reviews. This is often deal-qualifying, not a nice-to-have.
• Compliance and audit readiness. Supports SOC 2 / internal-control narratives and financial or healthcare-adjacent verticals. Note the distinction the package cannot resolve for us: internal audit trail (debuggability) versus regulator-facing evidence (tamper-evidence, retention management, access control). They are different products with different price tags.
• Record history UI / activity feed. A cheap, high-signal trust feature on detail pages. Directly supports retention and reduces "what happened to my account?" support volume.
• Support and incident tooling. Answers "what did this record look like before the customer complained?" without database forensics and shortens time-to-resolution.
• Roadmap fork: audit log vs. versioning. Once history exists, "restore this revision" and rollback become obvious next requests. Deciding now whether we are selling history or versioning prevents scope creep later.
• Build-vs-buy input. The package's real value to a PM is as a reference implementation: reading it de-risks an in-house estimate of 1–2 engineer-days to build a focused listener, versus an unbounded maintenance obligation for an unmaintained dependency.

What it does not support: any decision requiring production confidence. Zero stars, zero dependents, single-vendor namespace, near-zero maturity score, no compatibility matrix, no issue history. There is no evidence anyone runs this in production. Do not let it anchor a timeline, a "we get this free" assumption, or a compliance commitment to a customer.

When to Consider This Package

Consider it only if all of the following hold:

• We are on Symfony with Doctrine ORM. Non-negotiable — the Doctrine event model is the entire product. Any Laravel roadmap is a clean no.
• The requirement is internal-facing — debugging, support, activity feed — not regulator-facing, where certified, tamper-evident, retention-managed logging is needed.
• We are prepared to vendor or fork the code and own it under our namespace. Treat it as source we copy, not a dependency we inherit.
• We need something lightweight, not a full audit platform with diffing, replay, and a query API.
• Someone can read the source in an afternoon and confirm behavior under our write volume, transaction boundaries, relation changes, and queue/CLI contexts.

Look elsewhere — or build — when:

• We are on Laravel. Framework mismatch. Standardize on spatie/laravel-activitylog or owen-it/laravel-auditing, both adopted and maintained. This is the likely case and the answer is no.
• We need a maintained dependency. No community, no CVE response, no upgrade path when Symfony or Doctrine majors move. A single-maintainer package with zero adoption is a deferred migration project.
• Compliance is contractual. Audit tables are a second copy of personal data with their own retention and erasure obligations. Redaction, retention policy, and access control must be designed in, not bolted on.
• Write volume is high. Synchronous per-change row insertion on hot tables is a throughput tax and a schema-weight decision that should precede adoption, not follow it.
• Maintained alternatives exist. Doctrine listeners, gedmo/doctrine-extensions Loggable, or damonjones/auditor-style bundles give a supported option; a focused in-house listener is often cheaper than adopting an unvetted one.

How to Pitch It (Stakeholders)

To executives: Change tracking is a recurring enterprise-sales requirement and a support-efficiency lever, and it deserves a roadmap slot. This specific package is not the vehicle: it is an unproven, single-maintainer Symfony bundle with zero adoption, and it does not fit our Laravel stack. Recommend a 2–3 engineer-day, time-boxed spike on the audit-trail capability using a maintained library, and hold the buy decision until scope is confirmed (audit log vs. versioning), along with retention policy and PII handling. Low cost, low risk, no committed dependency, no customer commitment made on the back of it.

To engineering: Treat kronhyx/tracker-bundle as prior art, not a dependency. Read it as a reference for Doctrine change-tracking, then either adopt a maintained alternative or implement observers/listeners directly in our framework. Before writing code, pin down: what counts as a "change" (field-level diff? relations? soft deletes?), whether the audit write sits inside or outside the business transaction and what happens when it fails (silent gaps are worse than no logging — they create false confidence in incident review), how actor context is resolved in queue and CLI contexts where there is no authenticated user, how PII is redacted, and the retention window. Flag audit-table growth and query cost as a schema concern up front, and plan a feature-flagged canary on one non-critical entity before broadening.

Bottom line: The capability earns a roadmap slot. The package does not earn an adoption decision — zero stars, zero dependents, no compatibility matrix, and a framework mismatch make it a reference artifact. Validate the capability with a short, time-boxed spike and choose a maintained implementation.