Tomato Eddy Laravel Package

Technical Evaluation

Architecture fit

• tomatophp/tomato-eddy sits inside the broader TomatoPHP ecosystem (Laravel admin/CMS family). Assessment assumes the conventional TomatoPHP shape: a service-provider-registered Laravel package with published config, migrations, and Filament/Livewire admin surfaces; this should be validated against the actual composer.json and src/ tree before commitment.
• v1.0.20 is a patch release containing a single bugfix (site_id not exists, PR #16). No new public API, no config schema changes, no deprecations. Architectural fit is therefore unchanged from v1.0.19 — this release does not alter the integration decision.
• The defect class is the notable signal, not the fix: a "column/attribute not found" error implies a site_id reference reaching code paths where the underlying schema or model attribute was absent. That points to a package that carries site-scoped state (multi-site or per-tenant records), which raises the bar on migration discipline and on how the package behaves when a site context is not established.

Integration feasibility

• Low friction: patch-level bump, installable via Composer, no adapter or anti-corruption layer implied. Treat as a drop-in upgrade for anyone already on the 1.0.x line.
• Feasibility is gated less by this release than by the package's Laravel/Filament version constraints, which the release note does not disclose. Confirm illuminate/* and filament/* ranges against the host application before scoping.
• Because the fix touches a schema/attribute expectation, integration testing must include the migrated-from-previous-version path, not just a clean install. Fresh-install-only validation would not have reproduced the original bug.

Technical risk

• Change risk: low. Single-line-scope fix, no breaking surface, semver-consistent.
• Residual risk: moderate, inherited from the 1.0.x line rather than introduced here. A site_id attribute error reaching a tagged release suggests thin coverage on the site-context path — specifically, the "no site selected / site deleted / site record partially seeded" branches. Assume adjacent edge cases in the same code path remain unexercised.
• Supply-chain/ownership risk: single-maintainer package (@3x1io) under an ecosystem umbrella. Bus factor and release cadence are the dominant long-term risks, not code quality.
• Evidence risk: this assessment rests on one changelog line. Weight it accordingly; the risk rating should be revisited once the diff for PR #16 is reviewed.

Key questions

• What was the precise failure mode — missing column after upgrade, missing attribute on an unsaved model, or a null site context? The answer determines whether this is a migration-ordering issue (operational) or a null-handling issue (defect class likely to recur).
• Does the package ship a migration that adds site_id, and is it ordered/guarded correctly for existing installs?
• Are Laravel and Filament version constraints published and tested in CI across supported versions?
• Is the package multi-tenant by design, and does it fail closed or open when site context is absent?
• What is the project's test coverage and release test matrix? Is there a security disclosure channel?

Integration Approach

Stack fit

• Presumptive fit: Laravel 10/11 with Filament 3, standard Composer install, publishable config and migrations. Verify against the host app's pinned versions; this is the single largest unknown.
• Fits naturally where the organisation already runs TomatoPHP admin packages — shared conventions, shared auth model, shared UI layer, one fewer integration seam to own.
• Poor fit where the host app has no Filament footprint: pulling in an admin-panel dependency tree to obtain one capability is rarely justified.

Migration path

• Direct upgrade from v1.0.19: composer update tomatophp/tomato-eddy. No code changes anticipated on the consuming side.
• Upgrade from earlier than 1.0.19: walk the 1.0.x changelog rather than jumping, and run php artisan migrate in a lower environment first to observe whether the site_id schema change lands cleanly on an existing database.
• If the host application has its own migrations touching the same tables, resolve ordering explicitly before promoting.

Compatibility

• Backward compatible at the public API level; no deprecations declared.
• Compatibility risk is concentrated in transitive constraints (Filament major, Laravel major) and in databases where the site-scoped table was created by an earlier migration that predates site_id. Those are the environments to test first.
• Pin to ^1.0.20 rather than a floating constraint so the fix is guaranteed present and future patch drift is bounded.

Sequencing

1. Review the PR #16 diff and the underlying issue thread — cheap, and it converts this assessment from changelog-inferred to evidence-based.
2. Stand up a staging clone of the production database (pre-site_id state) and run the upgrade plus migrations.
3. Exercise the site-scoped paths: create, edit, delete, and view with no site selected. The original bug lives in one of these.
4. Smoke-test the admin surfaces the package registers for auth/permission regressions.
5. Promote to production in a low-traffic window with a database snapshot taken beforehand.
6. If any downstream service consumes the site-scoped data, validate that contract before, not after, cutover.

Operational Impact

Maintenance

• Low ongoing effort: patch releases, standard composer update cadence, no application code to maintain.
• The real maintenance cost is schema ownership. Any package that manages its own migrations in the application's database creates a shared-responsibility boundary; document who owns those tables and who is paged when a migration fails.
• Track the package's release history. A steady stream of small patches is healthy; long silences followed by clustered fixes are a warning sign for an ecosystem dependency.

Support

• Support path is GitHub issues and the maintainer directly — no commercial SLA assumed. Internal teams should be prepared to read the source for anything beyond a trivial defect.
• Because the failure surface is schema-related, first-line support cannot resolve incidents without database access. Reflect that in on-call runbooks.
• Budget for the possibility of a self-patch: with a single maintainer, the pragmatic answer to a blocking bug may be a fork or a pinned local patch.

Scaling

• Scaling characteristics are dominated by the host application's database and the admin UI, not by this package. Site-scoped queries should be indexed on site_id — confirm the migration creates that index; if it does not, add it, because an unindexed tenant key degrades badly as site count grows.
• No background workers, queues, or external services are implied by this release, so horizontal scaling is unaffected.
• Watch the admin surface under many sites: Filament tables with large row counts need pagination and eager-loading review.

Failure modes

• Migration drift (most likely): site_id absent in environments where migrations were run out of order or hand-edited. Mitigate with an automated migrate --pretend check in CI against a production-shaped schema.
• Null site context: code paths that assume a site is always selected. This is the class the v1.0.20 fix belongs to; assume siblings remain.
• Dependency conflict: a Filament or Laravel upgrade in the host app forces a package bump that lags. Mitigate by pinning and by not upgrading the framework and this package in the same change window.
• Maintainer abandonment: package stops receiving updates and blocks a framework upgrade. Mitigate by keeping the footprint small and the fork path rehearsed.

Ramp-up

• Engineering: under a day for a Laravel developer familiar with Filament; the package conventions are idiomatic. Add half a day for anyone who must understand the site-scoped data model.
• Operations: the meaningful ramp is on migration ownership and rollback procedure, not on the package itself — one runbook entry and one rehearsed restore.
• Product/PM: negligible. Do not schedule discovery time for this release; schedule it only if the PR #16 review reveals a broader site-context defect pattern.