Tomato Php Laravel Package

Product Decisions This Supports

Pull CRUD-heavy internal surfaces forward — or don't staff them at all. The decision this package actually informs is a scoping one: if the backlog contains a cluster of conventional, model-centric admin screens (back-office tooling, ops dashboards, MVP data management) behind an auth wall, a generator can compress that work from sprints to days. If that cluster doesn't exist, the package has nothing to offer and should be closed out in an hour.

Build vs. borrow for scaffolding. MIT license, plain-PHP output, require-dev install, and an exit path that is literally git revert plus composer remove --dev. That makes "borrow" defensible against an in-house scaffolding investment — provided a named reviewer exists before generation starts. A generator without a reviewer is not an accelerator; it's deferred cleanup.

Reallocate engineering capacity to differentiated work. The ROI is not the lines of code saved. It's the capacity redirected into permissions, audit trails, workflows, integrations, and domain logic — work a generator cannot do and competitors can't copy from a package.

Keep the bet deliberately narrow. Best fit: Laravel apps already committed to Splade or Breeze, generating standard CRUD modules into a bounded namespace. Poor fit: API-first services, event-sourced domains, heavy multi-tenant permission matrices, Inertia/React front ends, or retrofits into a mature domain layer. Do not let a successful admin pilot escalate into "standardize this across all product surfaces" — that's how a two-day experiment becomes an architecture decision nobody voted on.

Decision gate with pre-agreed metrics. Approve a 1–2 day spike plus a one-sprint pilot, measured on: time to first working CRUD screen, generated-vs-handwritten line ratio, percentage of boilerplate eliminated (target ~70%+), defects found in generated output, security findings, and ongoing maintenance effort. Write the kill criteria before the pilot, not after the first demo looks good.

When to Consider This Package

Adopt for a pilot when:

• Your app is Laravel on Splade or Breeze, and you can name the Breeze variant (Blade, Livewire, Inertia). Divergence from the generator's assumed conventions collapses its value to near zero.
• The backlog has roughly 5–50 straightforward resources over relational models, on internal or low-risk surfaces where a defect is embarrassing but not existential.
• You can enforce a review gate and security checklist on generated output before merge. Assume the standard defects are present until checked: open mass assignment, no per-action authorization, N+1 queries on index tables, missing pagination and filtering.
• You can install as require-dev, generate into a fenced namespace, commit raw generator output separately from hand edits, and pin at 1.1.8 or later. Earlier tags emit a broken Splade relation select (remoteRoute where remoteRoot('data') is required) — and the generator exits successfully anyway; the failure appears when an admin opens a create form. Grep existing scaffolding for remoteRoute before evaluating anything already generated.
• Someone verifies overwrite-vs-skip semantics in the generator source before it runs anywhere near hand-edited files. That single check separates a convenience from a data-loss incident.
• You accept that 34 stars, 0 dependents, and one maintainer mean no community depth, no public production references, and no commercial SLA. Name an internal owner and write the knowledge down, or it leaves with whoever ran the spike.
• You treat generated output as a starting commit, not a managed artifact — and confirm published tag dates on Packagist rather than trusting release metadata.

Look elsewhere when:

• You need complex custom workflows, compliance guarantees, or an escalation path with an SLA. The support model is GitHub issues and "read the stubs and fix it yourself."
• Your stack isn't Splade/Breeze — or you're API-first, on Inertia/React, or retrofitting into a mature domain layer.
• Nobody has capacity to review, test, and potentially fork the output. The output is plain PHP you own; that's the whole value proposition and the whole obligation.
• You need a multi-year commitment with a predictable framework-major upgrade story. The generator is coded against a snapshot of Splade's component API — the 1.1.8 fix is exactly what drift looks like. Sibling tomatophp/* packages have shipped the same bug, so keep the constraint tight.
• The work isn't repetitive. A generator earns its keep on the tenth similar resource, not the first.

How to Pitch It (Stakeholders)

For executives — one paragraph: This is a free, MIT-licensed Laravel code generator that scaffolds standard admin CRUD screens for apps already built on Splade or Breeze. We propose a 1–2 day spike plus one sprint against a bounded internal-tools backlog, with kill criteria agreed up front. Cost is a few engineer-days; upside is compressing routine admin scaffolding by roughly 70% and redirecting that capacity to permissions, audit, and workflow work that actually differentiates us. Exit cost is near zero — it installs as a dev-only dependency and removal is a revert plus a composer remove. We are not proposing it as a platform standard, and we are not taking a support dependency: it's a single-maintainer project with no SLA.

For engineering — the operating rules that make it safe:

• composer require --dev, pinned at 1.1.8+, excluded from production images. Verify the tag is real on Packagist.
• Generate into a bounded namespace so generated-vs-handwritten is obvious in every diff; commit raw output as its own commit before hand-editing.
• Read the publishable stubs first. The stubs are the product — controller shape, FormRequest presence, policy wiring, and eager-loading all get decided there in readable PHP. Five minutes of reading prevents hours of cleanup.
• Every generated PR runs the same seven checks (mass assignment, per-action policy, FormRequest emitted and used, eager loading, pagination, middleware/CSRF, every page rendered once in a browser). Generated diffs get rubber-stamped because they look plausible; the checklist is the counterweight.
• The known failure class is "plausible, compile-passing, broken at render." Add one cheap authenticated smoke test that GETs each generated route and asserts 200, and verify relation selects end-to-end: the form must call ->remoteRoot('data') and the JSON endpoint must return a { data: [...] } envelope. You own both halves.
• Confirm the generator's overwrite-vs-skip behavior before running it near existing code. Then publish our own stubs or a small fork — that's the durable extension point, not config flags.

The framing to hold onto: it removes typing, not accountability. The generated code is ours — its tests, its security posture, and its upgrades. Approve it as a scoped accelerator with a named owner and a documented exit path, or don't approve it at all.