Tomato Logs Module Laravel Package

Technical Evaluation

Architecture fit. tomatophp/tomato-logs-module is a Laravel package in the TomatoPHP ecosystem — a family of Composer-installable modules that bolt functionality onto the Tomato admin panel (Filament/Livewire-based). This specific module is a log-viewing/activity-log surface: it ships migrations, a service provider, and a Filament plugin/page set that renders stored log records inside the admin panel. Architecturally it is additive, not invasive: no core framework patching, no middleware hijacking, no separate runtime. For a Laravel shop already on Filament, the fit is high; for a shop on Blade/Vue/Inertia with no Filament, the fit is effectively zero unless you adopt Filament first.

Integration feasibility. Standard Laravel package mechanics: composer require, service provider auto-discovery, php artisan vendor:publish for config/migrations, php artisan migrate, then registering the plugin on a Filament panel provider. Realistic spike effort is half a day to two days for a developer already fluent in Filament, dominated by config tuning (retention, subject types, authorization gate) rather than plumbing.

Technical risk.

• Maturity. v1.0.0 with release notes consisting solely of a changelog link. There is no feature list, no breaking-change statement, no migration note. Absence of release hygiene is itself a risk signal for a package that writes to your database.
• Single-maintainer / ecosystem coupling. TomatoPHP is a small-team (largely single-maintainer) ecosystem. The module's usable version is pinned to whichever Filament major the Tomato panel targets; a Filament major bump can strand this module.
• Data-plane risk. Log tables grow monotonically. The package provides the read UI; retention, pruning, and indexing discipline remain your responsibility.
• Compliance risk. Activity logs routinely capture user IDs, IPs, user agents, and model diffs — potential PII. Access control must be explicitly configured; a default-open log viewer in an admin panel is an audit finding waiting to happen.
• Overlap risk. If you already run spatie/laravel-activitylog or Laravel Telescope, you may get duplicate tables or conflicting model assumptions.

Key questions.

1. Which Laravel and Filament major versions are constrained in composer.json? Is Filament v3 required, or is v2 still supported?
2. Does it depend on spatie/laravel-activitylog (and at what version), or does it define its own log schema?
3. What is the authorization model for the log page — policy, gate, or panel-level access only?
4. Is there a documented retention/pruning command, or is that left to the operator?
5. What is the maintenance signal — commit cadence, issue response time, test coverage/CI badge?
6. Is commercial support available through TomatoPHP, or is this community-only?

Integration Approach

Stack fit. Assumes PHP 8.1+, Laravel 10/11, Filament v3, Livewire 3. Confirm these match your baseline before committing; the cost of adopting Filament solely to consume this module is not justified — adopt the module only because you already have (or independently want) the panel.

Migration path. There is no prior assessment and no incumbent implementation, so this is a greenfield decision rather than a migration. Treat v1.0.0 as a trial dependency: install behind a feature branch, publish config and migrations into version control, and diff the generated files against your conventions before merging. Do not adopt on the strength of the version number alone.

Compatibility. Verify three axes explicitly: (a) Filament major vs. your panel, (b) Laravel major vs. your app skeleton, (c) coexistence with any existing activity-log or audit package. Run composer why-not / a dependency-resolution dry run in a scratch branch to surface conflicts cheaply.

Sequencing.

1. Evaluation spike (1–2 days). Install in a throwaway Laravel + Filament app. Confirm the panel page renders, migrations run cleanly, and authorization behaves as expected.
2. Security review (parallel, 1 day). Decide who can read logs, what fields are captured, and whether redaction is needed. Gate the page before it ever reaches staging.
3. Non-production integration (2–3 days). Wire into the real app on a branch; add retention policy and indexes; document the published config.
4. Production rollout. Behind a feature flag or restricted-role rollout; monitor table growth and query latency for two weeks before opening to all admins.
5. Decision gate at ~30 days. Re-evaluate commitment (pin, fork, or replace) once the maintenance cadence and upgrade behaviour are observed in practice.

Operational Impact

Maintenance. Budget modest but non-zero recurring effort: version pins on Filament/Laravel upgrades, and a periodic review of upstream activity. Because the ecosystem is small, assume you may need to fork for a critical fix; keep published config and migrations in-repo so a fork is a one-line Composer change rather than a rewrite.

Support. Expect GitHub-issues-level support with no SLA. Do not place this on a path where a broken upgrade blocks a release; isolate it so it can be disabled without affecting core admin functionality.

Scaling. The module is a read surface over a growing table. Two operational controls matter more than the package itself: (a) a retention job that prunes or archives beyond N days, and (b) indexes on the columns the UI filters and sorts by (typically created_at, subject_type, causer_id). At high write volume, ensure log writes are queued or otherwise non-blocking on the request path; verify whether the package's logging listener is synchronous.

Failure modes.

• Migration collision with an existing audit/activity table — fails at deploy, blocks release.
• Filament major upgrade breaks the plugin registration — admin panel boot failure, which is a full admin outage, not a degraded feature.
• Unbounded table growth — storage cost creep and slow list views, discovered late.
• Over-permissive default access — log data (including IPs and model diffs) visible to roles that should not see it.
• Abandoned upstream — no fix path for a Laravel/Filament incompatibility.

Ramp-up. Low for developers already writing Filament plugins: hours to productivity. For a team without Filament experience, add roughly a week of panel-familiarity overhead, and note that this cost is attributable to Filament, not to this module. TPM-level effort to a go/no-go: ~1 week elapsed, ~3–5 engineer-days, plus a security review pass. Recommend proceeding only as a pinned, feature-flagged, non-critical dependency — not as a foundational audit system.