Auditable Log Laravel Package

Product Decisions This Supports

• Build vs. buy for internal audit visibility. For teams already running Laravel Nova and owen-it/laravel-auditing, this is roughly a half-day to one-day accelerator versus hand-building an equivalent Nova resource tool. The trade is saved build time against accepting a near-zero-adoption, sparsely maintained dependency (51 stars, zero dependents, cosmetic-only release since 2022).
• Roadmap scoping and demand validation. Position it as a time-boxed pilot or internal-tools backlog item — a cheap way to test whether "who changed what, when" visibility actually gets used by support, ops, and compliance reviewers before committing budget to a first-class audit capability.
• Use-case prioritization. It supports customer-support forensics, incident investigation, data-correction evidence, internal-controls review, and security-review prep — but strictly as read-only display over records auditing has already captured. It does not create coverage; it surfaces it.
• An explicit scope boundary to communicate upward. This is a presentation layer, not an audit platform. No retention policy, no immutability/WORM storage, no alerting, no export, no advanced search, no certification. Any regulated requirement must be defined well beyond "show the log" — and that gap is a roadmap item, not a configuration flag.
• A positioning correction worth flagging early. The package description markets it as a "simple, configurable audit trail" with automatic Eloquent tracking, but the actual code is a Nova resource tool that only renders what owen-it/laravel-auditing wrote — no schema, no config, no runtime logic. Anyone evaluating off the tagline alone will form the wrong mental model; correct that before it reaches a roadmap or steering discussion.
• Dependency decisions it informs, never drives. It only applies if Nova (paid, licensed, fast-moving) and Laravel Auditing are already committed. It should never be the reason to adopt Nova.
• Ownership planning signal. With one cosmetic release since 2022 and no peer cohort to validate against, plan adoption as "fork and own," not "depend on." Budget one to two days a year for compatibility in steady state, materially more around any Nova major upgrade.

When to Consider This Package

Consider it when:

• You are already on Laravel Nova and owen-it/laravel-auditing, with the audits table migrated and actively capturing the models in scope — verify rows land in audits before installing, or you will debug the wrong layer.
• You are on, or moving to, Nova 4 — v2.0.2 aligns the UI with Nova 4 conventions, modestly lowering presentation risk, though that is a styling claim rather than a tested-compatibility guarantee.
• You need quick, read-only internal admin visibility and read-only is genuinely sufficient for the workflow.
• The audience is internal and low-risk, with access gated through Nova policies and canSee, and PII/secrets stripped upstream via $auditExclude or global config — the tool faithfully renders whatever is stored to anyone with resource access.
• You can pin exact versions, smoke-test against your current stack, and accept fork/maintenance ownership.
• The need is a prototype, stopgap, or narrow internal tool — not a long-term supported compliance capability.

Look elsewhere when:

• You are not on Nova, or not on Laravel Auditing — there is no surface area for this package.
• You require active maintenance on a predictable cadence, SLAs, or vendor support.
• You need immutable/WORM trails, retention, export, alerting, or advanced search — build or buy a real audit platform.
• You operate in a regulated environment, or expect high audit volume on frequently-edited records — an unindexed audits table will degrade Nova detail pages, and it is unclear whether the tool paginates at all.
• You cannot absorb the risk of a near-zero adoption footprint and sparse release history.

Two gate checks before any commitment: confirm installing it does not force a downgrade of Nova or owen-it/laravel-auditing (if resolution forces one, that is the answer), and confirm Nova credentials (COMPOSER_AUTH) are provisioned in CI — that failure comes first and looks like a package problem when it isn't.

How to Pitch It (Stakeholders)

Executive summary. A small Nova UI add-on that speeds up audit-log visibility for teams already standardized on Laravel Nova and Laravel Auditing. The latest release (v2.0.2) is a styling refresh for Nova 4 — a mild positive maintenance signal, not a product investment and not a compatibility commitment for future Nova majors. It saves build time by rendering old/new values and user attribution inside a Nova detail view, but it adds no retention, immutability, alerting, export, or certification. Treat it as a low-cost accelerator or a time-boxed internal pilot, not a strategic compliance platform. Recommendation: pilot, or fork with clear named ownership.

Engineering. It saves custom Nova resource work by rendering audit records — old/new values and user context from Laravel Auditing — inside a Nova detail view; v2.0.2 brings the UI closer to native Nova 4 conventions, reducing visual remediation. There are no functional or breaking changes in this release, but "aligns with Nova 4" is cosmetic, not tested compatibility. Before adoption: verify version resolution does not force a downgrade of Nova or the auditing package; confirm pagination behavior and (auditable_type, auditable_id) indexing against realistic audit volume, not an empty table; gate access via Nova policies and canSee, since the tool has no authorization of its own; and audit $auditExclude for PII and secrets, including rows written before your exclusion rules existed. Pin Nova and this package as a unit — never let a ^ resolve against a new Nova major. Note that debugging is Vue-side (browser console, compiled assets, network response), not laravel.log. Exit cost is near zero — one line removed plus composer remove — which is precisely why a half-day spike on one low-risk model is the right first move.

Recommendation. Run a half-day spike against v2.0.2 on a single low-risk model (Invoice, Ticket, Customer) on a throwaway branch to confirm it renders correctly on our Nova major with proper user attribution. Then choose between fork-and-own and building the roughly one-day in-house equivalent. Define acceptance criteria up front — version compatibility without downgrades, authorization, search/filtering, export, retention — and fall back to a custom Nova resource or a maintained alternative if any go unmet. Pair the panel with a dedicated, filterable Audit Nova resource if investigations are the real driver; the panel answers "what happened to this record," not "who touched anything in this date range." Set a review tied to every Nova major upgrade so version drift is caught.