Auditable Log Laravel Package

Technical Evaluation

Architecture fit. This is a Nova resource tool — a Vue presentation layer plus a tool-registration entry — that renders rows from the audits table written by owen-it/laravel-auditing. It contributes no schema, no config file, and no application runtime logic. Fit is therefore strictly conditional: it only applies to teams already standardized on both Laravel Nova and Laravel Auditing. The coupling is to Nova's tool-registration contract and front-end component API, not to Laravel itself, which means the blast radius of a break is the admin UI, not the application.

Positioning correction (flag before roadmap). The package description markets it as a "simple, configurable audit trail" with automatic Eloquent tracking. That is the behavior of owen-it/laravel-auditing, not this package. Evaluators working from the tagline alone will form the wrong mental model — and a wrong scope estimate — before anyone reads the code. Fix that framing upstream.

Integration feasibility. High when prerequisites hold, and cheap to prove: two registration lines (tools() in NovaServiceProvider, then attachment in the resource's fields()) plus a Composer require. Realistic effort is a half-day to one-day accelerator versus hand-building the equivalent Nova tool. The near-zero exit cost (remove the line, composer remove) is the main reason a spike is the right first move rather than a design exercise.

Technical risk. Four material items:

• Abandonment / adoption. 51 stars, zero dependents, a 2022 core release and one cosmetic v2.0.2 styling patch. There is no peer cohort to validate against and no vendor.
• Nova major drift. "Aligns with Nova 4" is a styling claim, not a tested-compatibility guarantee. Unpinned resolution can silently walk into a new Nova major and break the panel.
• Authorization and data exposure. The tool has no authorization of its own — it inherits the resource's Nova policy. It will faithfully render whatever is stored in old_values/new_values, including secrets and PII captured before exclusion rules existed.
• No extension surface. No hooks, no published config. Divergence from the default panel means forking.

Key questions to close before commitment.

1. Which Nova major are we on, and does resolution force a downgrade of Nova or owen-it/laravel-auditing? (A downgrade is a no-go.)
2. Are COMPOSER_AUTH / Nova credentials provisioned in CI? This failure comes first and masquerades as a package problem.
3. Does the tool paginate, and is (auditable_type, auditable_id) indexed on our audits table at realistic volume?
4. Which models in scope actually implement Auditable, and which events are excluded in config? Coverage gaps produce a clean-looking but incomplete log.
5. Do pre-existing audits rows contain PII that predates our exclusion rules?
6. Is read-only display sufficient, or does the requirement include export, retention, search, or alerting?
7. Who owns the fork, and what is the annual maintenance budget?

Integration Approach

Stack fit. Prerequisites are hard gates, not preferences: Laravel Nova (paid, licensed, private Composer repo) and owen-it/laravel-auditing installed, migrated, and actively capturing the models in scope. Non-Nova or non-Auditing environments have no surface area — stop the evaluation there. This should never be a reason to adopt Nova.

Migration path. There is none, in either direction — and that is a feature. The package owns no data and writes no schema, so adoption is purely additive and reversal is a registration removal plus composer remove. That symmetry de-risks the pilot and makes "try it on one model" the correct default posture. Conversely, there is no incremental path into the prerequisite stack; if auditing isn't already capturing, the work is in owen-it, not here.

Compatibility. Pin Nova and this package as a unit at exact versions (laravel/nova: 4.32.*, devpartners/auditable-log: 2.0.2); never allow a ^ to resolve across a Nova major. Treat v2.0.2 as a cosmetic refresh only — no functional or breaking changes, and no signal of tested compatibility against specific Nova releases. If your stack is older than Nova 4, fork the 2022 build; if you need custom display, fork v2.0.2 specifically to inherit the styling and point Composer at a private VCS.

Sequencing.

1. Provision COMPOSER_AUTH in CI before anything else.
2. Prove audits are already being written — require owen-it/laravel-auditing, publish config and migrations, add the Auditable trait to one model, edit a record, confirm rows land. If this fails, stop; the panel will render empty and you'll debug the wrong layer for an hour.
3. Spike on a throwaway branch against one low-risk internal model (Invoice, Ticket, Customer): confirm old/new values render with correct user attribution on our Nova major.
4. Gate access in the resource policy and with canSee() before the panel reaches a broader audience; strip secrets via $auditExclude / global config at capture time, and review existing rows.
5. Test against realistic audit volume, not an empty table — confirm pagination behavior and index coverage.
6. Decide: fork-and-own v2.0.2, or build the roughly one-day in-house equivalent.
7. Expand per-resource, opt-in only, where "who changed this?" is a real support question — not globally.
8. Build the companion Audit Nova resource over OwenIt\Auditing\Models\Audit, filterable on event, auditable_type, user_id, created_at. That answers a different question ("who touched anything in this window") and is the piece that actually earns its keep in daily support work.

Operational Impact

Maintenance. Plan for "fork and own," not "depend on." Budget one to two days per year in steady state, materially more around any Nova major upgrade. Tie a review to every Nova upgrade so version drift is caught deliberately rather than in production. There is no extension point, so any requirement divergence converts directly into fork work — that is the intended maintenance model given the adoption footprint.

Support. No vendor, no SLA, no predictable cadence, no community cohort to lean on. Name an internal owner at adoption; otherwise the panel becomes unowned infrastructure that nobody can safely change. Document a debugging runbook: a blank panel is diagnosed in the browser (compiled assets, Vue console, network response for the tool's data fetch, and whether npm run dev/build picked up the component after the last Nova update) — storage/logs/laravel.log will tell you nothing.

Scaling. Two distinct concerns:

• Presentation: if the tool pulls full history on render and (auditable_type, auditable_id) is unindexed, a frequently edited record makes the detail page slow or memory-hungry. Validate pagination and index coverage before attaching the panel to high-churn models.
• Storage: the audits table grows unbounded, and this package provides no retention policy. Growth is owen-it's domain and must be planned separately.

Failure modes.

• Silent blank panel after a Nova upgrade or an asset build — the most likely break, and it fails quietly.
• Silent incompleteness — a model that doesn't implement Auditable, or excluded events, yields a clean-looking log that's wrong. Worse than no log if anyone treats it as authoritative for incident review.
• Over-exposure — secrets or historical PII rendered to anyone with resource access, because authorization is inherited and exclusions apply only going forward.
• CI resolution failure misattributed to the package when it's missing Nova credentials.
• Not evidence-grade — no immutability/WORM, retention, alerting, export, or advanced search; audit rows remain mutable at the database level.

Ramp-up. Engineering onboarding is trivial (two registration lines), so the real ramp is organizational: the debugging runbook, the policy/canSee gating decision, the PII exclusion review, and the governance conversation about what the log is and isn't allowed to mean. Scope it explicitly as read-only internal visibility — a pilot or stopgap — and route any regulated requirement (immutability, retention, export, certification) to a purpose-built audit platform. Acceptance criteria for the spike should be written up front: no forced downgrades, authorization verified, search/filtering and export requirements assessed, retention addressed — and a fallback to a custom Nova resource or a maintained alternative if any go unmet.