Cleaver Laravel Package

Technical Evaluation

Architecture fit

• Cleaver is a code generator, not a runtime library. It introspects the existing database schema and emits CRUD controllers, routes, and Blade views. Architecturally it sits at the internal-tooling layer, outside the product's request path — the coupling is to the database schema, not to application code.
• Output is plain Laravel + Blade + Tailwind with no JS framework or external UI dependency. That is an exit-friendly property: the generated admin survives deletion of the package, so the strategic commitment is low.
• Fits: server-rendered Laravel monoliths with Eloquent models over conventional tables, internal back-office users, and data-management surfaces that are explicitly non-differentiating.
• Does not fit: API-only services, Inertia/React/Vue frontends, or anything where the admin UI is customer-facing or a revenue surface.

Integration feasibility

• Mechanically cheap: Composer install, run the generator command, publish views. A spike is measured in hours, not sprints — this is the main reason the opportunity score is high.
• The gating unknown is version compatibility. The last release is 2022-08-28 (Laravel 9 era); support for Laravel 10/11 and PHP 8.2/8.3 is unverified and must be read from composer.json require constraints and proven on a branch, not inferred.
• Secondary unknowns: how routes are registered and whether they accept middleware, whether table selection is scoped or exhaustive, and whether generation is idempotent (safe to re-run after a migration) or destructive to prior customizations.

Technical risk

• Staleness — no release in over two years. Treat the package as a one-time generator rather than a maintained dependency; that reframing removes most of the risk.
• Security surface — the package scaffolds create/update/delete endpoints for every table it discovers. Nothing in the description indicates authorization, validation, audit logging, or CSRF/route middleware wiring. Ungated, this is a direct path to data loss or breach.
• Data integrity — form inputs and validation are inferred from column types. Enums, JSON, foreign keys, nullable columns, casts, soft deletes, and polymorphic relations are the likely failure points, producing writes that bypass the invariants your application code enforces.
• Schema drift — generated resources are a point-in-time snapshot. Every subsequent migration silently invalidates them.
• Destructive affordances — delete is a scaffolded feature; without soft deletes or confirmation flows, one misclick is unrecoverable.

Key questions

1. What Laravel/PHP versions do the Composer constraints actually declare, and does the generator run clean on our current version?
2. Does it register routes through the service provider, and can we wrap them in our existing auth/policy middleware?
3. Can we restrict generation to an explicit allowlist of tables — or does it expose every table including users, sessions, jobs, and password_resets?
4. Is generation idempotent, and does re-running overwrite previously published views?
5. Does it honor $casts, soft deletes, and model-level validation, or does it write directly to the table?
6. Is the output inspectable and reviewable as a normal PR, or does it depend on package internals at runtime?
7. Who maintains the repo, and are there open issues referencing security or Laravel-major incompatibility?

Integration Approach

Stack fit

• Native to Laravel + Blade + Tailwind; no build-step, no npm, no separate frontend. In a Blade monolith it drops in beside existing views.
• In a headless/SPA architecture, it can still serve as a separate Blade-rendered admin area at a distinct route prefix, but that introduces a second rendering stack — acceptable only for internal tooling.

Migration path

1. Branch and install into a non-production environment against a staging database copy.
2. Generate against a single low-risk table; diff the emitted controllers/routes/views and read them line by line — the output is the integration contract.
3. Publish views, then re-run generation to confirm whether published files are preserved or clobbered.
4. Wrap the route group in auth + authorization middleware before any environment with real data.
5. Freeze the package version, commit the generated code, and record the generation commit as an artifact. From that point the package is a build-time tool, not a deployed dependency.

Compatibility

• Validate against the package's declared Laravel/PHP matrix and our exact lockfile, including any schema-introspection dependency it pulls in (DBAL-style packages are a common transitive addition and can conflict with existing versions).
• Confirm behavior against the specific database engine in use — introspection differs across MySQL, Postgres, and SQLite.

Sequencing

• Phase 0 (days): spike on one table in staging. Output: a go/no-go on compatibility plus a read of the generated code.
• Phase 1 (1–2 weeks): internal-only admin behind auth for a bounded allowlist of tables. Ships value immediately for support/ops data management.
• Phase 2: customize published views and controllers; add validation, policies, and audit logging at the controller layer.
• Phase 3: decision point — once customizations outpace regeneration cost, stop re-running the generator and own the code. That is the natural graduation, not a failure.

Operational Impact

Maintenance

• Assume no upstream fixes. The durable mitigation is the same one the integration path enforces: commit generated output and treat the package as a one-off generator. Then maintenance is ordinary Laravel maintenance on code we own.
• If instead we keep regenerating against a live dependency, every migration becomes a follow-up task and each Laravel upgrade becomes blocked on an unmaintained package.

Support

• MIT, no vendor, community issue tracker only, and a 2022-era backlog. No SLA, no security advisory process, no deprecation policy. We are the support organization for anything we ship on top of it.
• Practical consequence: designate an owner at adoption time. Unowned generated code becomes legacy fast.

Scaling

• Adequate for internal admin traffic — tens of concurrent users on paginated Eloquent queries. It is a conventional CRUD layer; pagination and indexing are our responsibility, and search is likely LIKE-based, which degrades on large tables.
• Not appropriate as a high-traffic or public-facing surface: no described caching, no async work, no query optimization.

Failure modes

• Schema drift → 500s on renamed or dropped columns. Highest-frequency failure.
• Ungated routes → unauthorized read/write/delete across all application tables. Highest-severity failure.
• Type inference gaps → invalid writes that bypass model validation and business rules.
• Regeneration → silent loss of hand-edited controllers or views if publish-then-regenerate is not verified.
• Destructive delete → unrecoverable record loss where soft deletes aren't honored.

Ramp-up

• Effectively zero for anyone fluent in Laravel: the generated code is idiomatic Blade and Eloquent, and a developer is productive within a day.
• The real ramp-up risk is institutional, not technical — knowledge of how the generation step works and when to stop re-running it tends to concentrate in one person. Document the generation commit and the cutoff decision, and the generated code onboards like any other Laravel module.

PM note on evidence: the only release artifact available is a v1.6.4 changelog reading "Composer updates." All capability claims above derive from the package description, not from verified docs. Validate the feature set against the README and a hands-on spike before committing roadmap capacity — and frame the decision to stakeholders as "days, not sprints, and the output is ours to keep," which is precisely why the adoption risk is bounded.