Core Laravel Package

Technical Evaluation

What this package is, in product terms. craftile/core is the foundation layer of the Craftile admin framework: a Laravel-native, declarative back-office builder. You define resources against Eloquent models, and Core supplies the routing, forms, tables, validation, filtering, search, and policy-driven authorization behind them. The stated value proposition is that it replaces hand-written Blade CRUD with configuration — the tedious, low-differentiation layer of internal tools and admin panels.

Architecture fit. The conceptual fit is strong for any Laravel application carrying a meaningful internal admin surface. It is opinionated in a direction most Laravel teams already lean: Eloquent as the model layer, policies and gates as the authorization story, service provider plus config file as the wiring. That means adoption is a configuration exercise rather than a paradigm shift, which materially lowers the integration risk relative to a framework that brings its own auth, ORM, or frontend runtime. The caveat is that admin frameworks are architecturally load-bearing by nature — once your operations team's daily tooling runs on it, ripping it out is a project, not a commit.

Integration feasibility — and the critical distribution caveat. This repository is explicitly [READ ONLY] Subtree split of the Craftile Core (see craftile/php). That is a distribution artifact, not a supported package entry point. It has no issue tracker, no PR flow, and no independent release cadence; every signal that matters lives in the parent monorepo. The TPM-level consequence is that any evaluation performed against this repo is a proxy, not the real thing. Feasibility must be judged on craftile/php, and the install instruction must be composer require craftile/php — requiring the split directly is an anti-pattern.

Technical risk, ranked for a TPM's purposes.

• Adoption risk (highest). Zero stars and zero dependents mean no third-party production usage, no Stack Overflow corpus, no blog posts, no community-vetted upgrade paths. Every question is answered by reading source. This is the single largest unknown and it is not something a spike can fully resolve — only time resolves it.
• Bus factor. Small or single-maintainer surface. No SLA, no support contract, no visible security disclosure path. If the maintainer stops, the package stops.
• API stability. Pre-1.0, thin documentation. Expect breaking changes in minor or patch releases. Semver discipline is unproven until the changelog is read.
• Split drift and supply chain. The mirror can lag the monorepo, so bugfixes and security patches arrive late or not at all. Tags may not align. A tag deletion or history rewrite upstream is a real (if low-probability) failure mode.
• Scope creep expectations. "Admin framework" invites stakeholders to assume it covers workflows, audit trails, localization at scale, and DAM. It does not — those are build-on-top items. Mis-set expectations here are a roadmap risk, not a technical one.

Key questions to close before any commitment.

1. Which package does the maintainer support as the install target, and does the split track the monorepo per-tag automatically?
2. What is the supported PHP/Laravel matrix, and is there a stated versioning and deprecation policy?
3. Is the split's content byte-identical to the corresponding monorepo directory, including assets?
4. License terms — fully permissive OSS core, or an open core with a commercial tier? Any CLA or usage restriction?
5. Is there a security disclosure path, and who is on the other end of it?
6. What is explicitly out of scope (workflow, localization, audit, media) so the gap list can be costed rather than discovered?

TPM framing. This is a bounded-option evaluation, not a platform standardization decision. The honest ask is one timeboxed spike to determine whether a multi-sprint build can be removed from the roadmap. Frame it that way to stakeholders and the maturity gap becomes an acceptable, quantified risk rather than a blocker.

Integration Approach

Stack fit. The package is Laravel-idiomatic: service provider registration, publishable config, policies and gates you already use, Eloquent as the data layer. It should drop into a conventional Laravel application without architectural disruption, and package auto-discovery should handle provider registration (verify; add manually if not). Fit degrades if the app has standardized on a competing admin stack — Filament, Nova, or a Livewire/Inertia-based back office — in which case this is a replacement conversation with a migration cost, not an addition.

The consuming-dependency rule. Require craftile/php. Let Composer resolve the split if that is how the maintainer distributes it. Consume only documented public API; treat undocumented internals as off-limits so upstream changes stay containable.

Migration path — sequenced to keep the blast radius at one file.

1. Read the parent first. craftile/php README, CHANGELOG, issue tracker, and roadmap are the source of truth. This repo is useful only as a clean reading surface for core's class layout and a smaller diff for git log between versions.
2. Spike in a throwaway Laravel app. Install, publish config, run migrations, define one non-trivial resource (a model with relationships, validation, filters, a policy) and take it end to end. This is where you learn what Core does not cover.
3. Wrap it. Define our own thin contracts — a ResourceRegistry / PanelAdapter interface — and adapt Craftile behind them. This is the single highest-leverage decision in the whole integration: it converts abandonment or a breaking change from a rewrite into a swap.
4. Contract tests. Write tests against the specific public surface we touch, so an upstream change fails our CI rather than production.
5. Integrate behind a feature flag into one real, non-critical admin module.
6. Then, and only then, consider widening to operations-critical surfaces.

Compatibility. Pin exact versions in composer.lock — no caret ranges on a pre-1.0 package. Configure Renovate/Dependabot to propose upgrades for this package rather than auto-merge. Check for conflicts with any existing Livewire, Inertia, or Filament usage. If a frontend or asset build step exists, confirm both halves version-match the same release; mismatched halves are the most likely runtime failure.

Sequencing for the decision, not just the code. Run the spike as a gated experiment with named deliverables: a working vertical slice on one real page, a written inventory of gaps against our actual admin requirements, a go/no-go recommendation, and — if no-go — the estimated cost of building the replacement behind the adapter. Timebox it. The output is information, and the spike is the cheapest way to buy it.

Durable options if the pilot succeeds. (a) Continue on the supported package with strict pinning and adapter isolation. (b) Fork to a private VCS repository we control and can patch. For anything production-bound at this maturity, (b) is the honest recommendation — it converts an unowned upstream into an owned, patchable artifact.

Operational Impact

Maintenance. We own it. There is no support contract and no visible issue tracker on the artifact we install. Budget an explicit ongoing line item — call it a fraction of an engineer — for tracking upstream craftile/php commits, evaluating releases, and occasionally back-porting patches. Register it in the SBOM and flag it as a high-risk dependency so it does not get lost among routine updates.

Support. Effectively zero external support. No dependents means no community corpus: every answer comes from reading source. Internal documentation of the integration — the adapter boundary, the resources defined, the gaps we accepted, the upgrade procedure — is mandatory, not optional. Losing the one engineer who did the spike must not lose the knowledge.

Scaling. Depends on how Core stores and renders structured content. If resources serialize to JSON columns and render per request, expect query and rendering overhead that needs a caching layer before traffic grows. Review for N+1 patterns in table and form hydration before any high-traffic admin or content-driven surface depends on it. If it compiles or serves assets, plan cache invalidation on content change.

Failure modes, ranked by likelihood and business impact.

1. Abandonment. Single maintainer stops. Mitigated only by keeping the integration surface small and the adapter honest — the exit cost is the whole risk.
2. Version drift. The split lags a bugfix or security release and we are stuck until the mirror catches up. Mitigated by consuming the parent and pinning deliberately.
3. Breaking change in a patch. Pre-1.0 semver habits are unproven; the adapter contains it to one namespace.
4. Scope disappointment. Stakeholders expected workflows, audit trails, or localization and got CRUD. Mitigated by publishing the gap list early, from the spike.
5. Supply chain. Upstream tag deleted or history rewritten. Mitigated by pinning, mirroring, and hash verification.

Ramp-up. One to two engineer-days for a competent Laravel developer to read the source and ship a working spike; three to five days to production-grade with the adapter, contract tests, and docs. Add half a day if a frontend or asset build step is involved. This is a read-the-source dependency — plan that time explicitly rather than discovering it mid-sprint. For the TPM, the planning implication is that the spike is cheap enough to approve on judgment and the production commitment is not.

Bottom line. The package may well be good, but at zero dependents with the only visible artifact being a read-only mirror, the TPM's job is to convert unknowns into a bounded pilot rather than to render a verdict. Approve a timeboxed spike against craftile/php, pinned and wrapped behind an adapter, with a written gap inventory as the deliverable. Do not approve it as a load-bearing dependency until the split's provenance, versioning discipline, license terms, and maintenance commitment are confirmed — preferably in writing, from the maintainer. Revisit the maturity signal in two to three quarters; the adoption picture, not the code, is what will have changed.