Core Laravel Package

Product Decisions This Supports

• Build vs. buy for back-office tooling. Craftile Core is the foundation layer of a Laravel admin framework: define a resource around an Eloquent model and the package supplies routing, forms, tables, validation, filtering, and search. Every product org eventually funds some version of this — internal dashboards, support consoles, ops tooling, content management UIs. The decision this package forces is explicit: keep hand-writing bespoke Blade CRUD screens, or adopt a declarative layer and spend those sprints on customer-facing differentiation.
• Roadmap sequencing for internal tooling. If the core covers resource→routing/forms/tables/validation, then an "admin panel for X" epic converts from a multi-sprint custom build into an integration task. That changes estimates, unblocks ops/support stakeholders earlier, and frees engineering capacity for roadmap items that actually differentiate.
• Standardization of the admin surface. Adoption is a platform decision, not a library choice. It implies resources-as-configuration, policy/gate-based authorization as the default, and a consistent shape for every future back-office screen — which affects onboarding, code review norms, and how new internal features get scoped.
• Authorization architecture. Policy-driven authorization "out of the box" is the most quietly valuable claim here. If true, it means back-office permissions inherit the same gates your application already uses, rather than growing a parallel, drifting auth model. That is worth validating as a first-class product concern, not an implementation detail.
• Extensibility as a product bet. The panel API for custom fields, actions, and widgets determines whether this is a CRUD generator (fine for v1, limiting by v2) or a platform you can grow into. The realistic decision it supports today is a timeboxed spike to test that extensibility boundary on a real, non-trivial screen.
• Use cases worth mapping: internal ops dashboards, customer support consoles, editorial/CMS management UIs, approval and review workflows, partner/admin tooling for B2B products, and any multi-tenant back-office where every tenant needs the same CRUD surface.
• Prototype vs. commit gating. Zero stars, zero dependents, and a read-only mirror distribution mean the honest output of an evaluation is information, not adoption. Frame the spend as buying a cheap option on a category you will otherwise build by hand.

When to Consider This Package

Consider it when most of the following hold:

• You are on Laravel and the admin surface lives inside the application, not in a separate tool or SaaS BI product.
• You have a growing admin footprint — multiple models needing list/detail/create/edit, filters, search, and per-role permissions. The value scales with the number of resources; one screen does not justify it.
• You already rely on policies and gates and want back-office authorization to inherit them rather than duplicate them.
• You can absorb pre-1.0 risk: API churn, thin documentation, small-maintainer surface, and a package whose public API is still being discovered by reading source.
• You will consume it via craftile/php, not this repo. This repository is explicitly a [READ ONLY] Subtree split — a distribution and reading artifact with no issue tracker, no PR flow, and an independent release cadence you do not control. Requiring craftile/core directly is an anti-pattern; read it here, install the parent.
• You can wrap it behind an internal interface so a breaking change or abandonment costs one adapter, not a rewrite.

Look elsewhere when:

• Ecosystem validation is a gate. Zero stars and zero dependents mean no third-party production usage, no community-vetted upgrade paths, no Stack Overflow corpus. If your organization gates on maturity signals, this fails today — revisit in two to three quarters.
• You need vendor support, SLAs, security disclosure commitments, or long-term maintenance guarantees.
• Your admin needs are small. A handful of Eloquent models with Blade partials will be cheaper to build than to integrate, wrap, document, and monitor.
• You need enterprise back-office capabilities as first-class features — audit trails, approval workflows, granular field-level permissions, SSO provisioning, export/compliance tooling. Plan to build those on top; do not expect them here.
• Your frontend is opinionated away from server-driven Blade-style rendering (e.g. a heavily custom SPA admin), or you are not on Laravel at all.
• You expect to hand maintenance to a team without Laravel depth. This is a read-the-source dependency; the ramp cost is real and should be staffed, not discovered.

If you proceed: pin exact versions, isolate behind an adapter, assign an owner to track upstream releases for one quarter before any roadmap dependency hardens, and keep a documented exit path to your own resource/CRUD layer.

How to Pitch It (Stakeholders)

To executives: This is a bounded evaluation of a Laravel package that supplies the foundation of an internal admin framework — resources mapped to your data models, with forms, tables, validation, search, filtering, and permission checks handled by the framework instead of hand-written screens. The category is real and recurring: every back-office dashboard, support console, and ops tool we build re-solves the same CRUD problem. The ask is a single timeboxed spike (one to two weeks, one engineer) on one real admin screen to determine whether this removes routine back-office builds from the roadmap. The risk is deliberately capped: we integrate behind our own internal interface, so walking away costs the spike, not a rewrite. The honest caveat is maturity — no adoption signals, no support contract, distributed as a read-only mirror of the real package — so this is "buy information cheaply," not "standardize the platform." A go decision means one less category of undifferentiated work on the roadmap; a no-go means we keep building it ourselves, now with a clearer cost estimate.

To engineering: Treat craftile/core as a reading surface, not a dependency. Require craftile/php; let Composer resolve the split. On the spike, prove the claims that matter: register the provider, publish and migrate, define one resource against a real model, render a table with filter and search, submit a form through validation, and gate the whole thing behind a policy. Then push on the extensibility boundary — add a custom field, a custom action, a small widget — because that is where the framework either holds up or forces you to fork its internals. Wrap the public surface you actually touch (ResourceRepository, a renderer/table adapter, an action registry) behind our own contracts so upstream churn is contained to one namespace. Pin exact versions — no caret ranges on a pre-1.0 package — and no reliance on undocumented internals. Deliverables: a working vertical slice on one real screen, a written inventory of what the core does not cover (audit logging, bulk operations, export, localization), contract tests around our integration points, and a go/no-go with the adapter's replacement cost estimated. If fit is partial, build the gap behind the adapter and keep the option; if fit is poor, keep the adapter and swap the implementation.