Voyeur Bundle Laravel Package

Product Decisions This Supports

• Whether we need per-record change history at all — and for which entities. Voyeur's model is a concrete template for the "what does good audit logging look like" decision: a revisions store, a configurable set of tracked fields, insert/update/delete capture via ORM lifecycle events, and responsible-user attribution on every change.
• Build vs. buy vs. borrow for audit trails. Treat this as a borrow/reference decision, not an adoption decision. The logic is thin and reproducible; the durable value is the workflow (capture-on-write → store revision → inspect history), not the dependency.
• Compliance vs. operational posture. Forces the decision of whether we only need "let's see what changed and who did it" (operational audit trail — this pattern fits) or tamper-evident, immutable, retention-managed audit storage (compliance-grade — this pattern is not enough).
• Support/CS tooling roadmap. A per-entity revision history unlocks "what changed on this order/account, and who changed it" views for support, disputes, and forensics. Voyeur's inspect-past-revisions model informs that feature.
• Data retention and privacy decisions. Revisions are copies of record data. Decide retention windows, PII classification, and how erasure/deletion requests are honored without silently retaining them in the audit table.
• Roadmap sequencing. Audit trail is cheap to add early and expensive to backfill. Invest before a compliance deadline or a "we can't explain how this record got corrupted" incident — not after.
• Definition of done for write-path features. A policy that every new mutable entity declares whether it is audited, mirroring the way backend tickets require tests.

When to Consider This Package

Consider it (as reference only) if:

• You are on Symfony + Doctrine. The bundle hooks Doctrine's event system; that is the runtime it targets, and it is not a drop-in for anything else.
• You want a small, legible reference for how to wire an audit/revisions table with user attribution through ORM events.
• Your audit need is operational ("let's see what changed") rather than compliance-grade (tamper-evident, WORM, legal hold).

Look elsewhere in the Laravel case — which is this case.

• The package is a Symfony bundle on Doctrine, not a Laravel package. Laravel uses Eloquent, not Doctrine; there is no adapter and no clean install path. You would be porting the idea, not adopting the code. Laravel-native equivalents are the better fit: spatie/laravel-activitylog, owen-it/laravel-auditing, or plain Eloquent model observers + a revisions table.
• Adoption signals are weak: 32 stars, 0 dependents, composite score 0.28, no visible active maintenance. To a PM this reads as effectively abandoned — no security patches, no guarantees against current PHP/Symfony versions, and no one to escalate to. Treat it as reference source.
• Compliance-grade audit needs more than this provides: immutable/append-only storage, tamper-evidence, retention and legal-hold policy, and a documented audit schema. Use a purpose-built audit store if obligations exist.
• Volume and cost: change capture on every write adds write amplification and unbounded table growth. Without an explicit retention plan this becomes a performance and cost problem the bundle does not solve.

Decision-maker note: the previously circulated notes describe a screenshot/visual-regression tool. The actual package is an audit-trail / entity-history bundle — a different capability. Decisions should be based on the audit-trail description above.

How to Pitch It (Stakeholders)

To executives (one paragraph): The real question is whether we need a reliable record of who changed what, when across key business entities — orders, accounts, pricing, permissions. If we do (for compliance, support disputes, or basic accountability), this is a well-understood, inexpensive pattern: a revisions table plus a hook into the ORM write path with user attribution. This specific package, NamshiVoyeurBundle, is a small, unmaintained Symfony/Doctrine bundle that demonstrates the pattern; it is not a fit for our Laravel codebase and I do not recommend depending on it. My recommendation is a small, owned build on Laravel-native tooling (Eloquent observers/model events, or an established auditing package), scoped to the handful of entities that actually need history, with retention and PII handling agreed up front. Effort is days-to-weeks, not a program.

To engineering (concise): Do not add namshi/voyeur-bundle — it is a Symfony bundle tied to Doctrine events; our app is Laravel/Eloquent and there is no adapter. 0 dependents, 32 stars, no maintenance signal; the pattern itself is trivial to reproduce. Recommended path: audit only the entities that matter via Eloquent model events/observers (or spatie/laravel-activitylog for batteries included), writing to an append-friendly revisions table containing changed-field/before-after payload, actor ID, timestamp, and entity reference. Design for four things from day one — write-amplification cost, retention growth, PII/erasure handling, and keeping audit rows immutable (no update/delete path) — because those separate "a log" from "an audit trail." If a regulatory requirement appears, escalate to a tamper-evident audit store rather than stretching this pattern.