Frontend Laravel Package

Product Decisions This Supports

• Frontend layer architecture for Laravel apps that are model-heavy. The package's core job is turning Eloquent models into a frontend-consumable manifest (ManifestService via Spatie\ModelInfo + Luminix Finder), with a single views/embed.blade.php entry point and a config/frontend.php surface. That makes it a candidate when deciding whether the UI should be driven by backend-declared schema (manifest → reducers → payload keys) rather than hand-written per-screen controllers.
• Build vs. buy for admin/embed scaffolding. The real comparison set is Inertia + hand-rolled pages, Filament, Nova, or a bespoke manifest endpoint. This package is the "buy, but from a very small vendor" option — worth pricing out only if the manifest/reducer contract matches how your product already thinks about models.
• Ecosystem bet on Luminix CMS. Adoption is effectively a decision to standardize on luminix/backend (hard dependency for ManifestService, Finder, ModelInfo) and the surrounding package family. That's a stack commitment, not a utility-library pick.
• AI-assisted development strategy. Unusually, the package ships an agent-consumable skill/ tree (SKILL.md + references/) published into the host app via vendor:publish --tag=luminix-skill --force. This is a genuine differentiator for teams standardizing on coding agents: the contract lives in the repo the agent can read, and is versioned to the commit. It supports decisions like "can we let an agent wire up CRUD screens against this manifest without a human reading source?"
• Visibility / multi-tenant policy design. Guest filtering in ManifestService (and its runningInConsole() suppression) is a product-level authorization decision baked into the manifest — relevant when deciding where access rules live (model layer vs. frontend config).
• Roadmap sequencing for public-facing polish. With 0 stars and 0 dependents, the package is pre-traction. PM decisions here are mostly should we be an early adopter and feed requirements back, not should we migrate off something proven.

When to Consider This Package

Consider it when:

• You are already on, or deliberately evaluating, the Luminix CMS stack — luminix/backend is a hard requirement; loosening it "breaks the manifest, not just the models it describes."
• Your app's UI is largely a generic view over models (CRUD, list/detail, embedded admin) and you want one manifest contract instead of per-resource controllers.
• You want the frontend contract to be legible to AI coding agents as a first-class artifact, and your team already runs agents against the repo.
• Your runtime matrix overlaps Laravel 11/12/13 and PHP 8.2–8.5 — that matrix is actually tested in CI (10 jobs).
• You're comfortable being an early adopter: the package is self-contained (src/, one config, one view) and therefore cheap to read, fork, or abandon.

Look elsewhere when:

• You need community validation, plugins, hiring-pool familiarity, or vendor support. Zero stars, zero dependents, and a Portuguese-only README is a real signal for a broadly-facing team.
• You are not on luminix/backend and don't intend to be — ManifestService depends on its Finder facade and Spatie's ModelInfo; adapting it is a fork, not a config change.
• You need a mature, batteries-included admin UI (Filament/Nova) rather than a manifest/embed primitive.
• Repo hygiene matters to your review process: composer lint is declared but unusable (no phpstan in require-dev, no config), and composer.json carries a dead Luminix\Frontend\Tests\ → tests/ autoload-dev entry. Neither breaks runtime, but both signal a package still being cleaned up.
• Documentation must be English-first for your contributors; the Packagist-facing README is Portuguese, with English reserved for the agent skill and internal dev notes.

How to Pitch It (Stakeholders)

To executives: This is a small, low-cost bet inside the Luminix ecosystem, not a platform replacement. It gives us one place where Eloquent models become a frontend manifest — config, one Blade embed, and a visibility filter — so screens stop being bespoke. The differentiated part is that the package ships its own machine-readable usage guide, so AI coding agents can integrate it correctly without reading source; that's a hiring-and-velocity argument more than a feature argument. The honest caveat: it's pre-traction (no stars, no dependents, single-vendor), so treat it as an experiment with an exit ramp, not an infrastructure standard.

To engineering: The product surface is deliberately tiny — src/, config/frontend.php, views/embed.blade.php. It's tested with orchestra/testbench against a throwaway host app, with a 10-job CI matrix across Laravel 11/12/13 × PHP 8.2–8.5, so the support claim is enforced rather than advertised. Two things to flag in review: ManifestService hard-depends on luminix/backend (Finder, and Spatie ModelInfo through it) — that's the real coupling. And the manifest suppresses the guest filter under runningInConsole(), so authorization tests need TestCase::simulateHttpContext(); it's an easy trap for anyone writing feature tests. Semver is derived mechanically from commit subjects, which means version bumps are predictable but also uncurated — pin deliberately. If we adopt, budget for contributing the English README and lint config back rather than absorbing them as internal debt.