Fast Api Crud Laravel Package

Product Decisions This Supports

• Build vs. buy for boilerplate. The core decision is still whether to hand-write CRUD scaffolding (controllers, form requests, API resources, migrations, route registration, pagination/filtering defaults) or generate it. This package is a candidate only for the "generate" side of that trade-off — it does not solve domain logic, and shouldn't be evaluated as if it does. v3.1.0 does not change that scope; it changes who can drive the generator and how cheaply.
• AI-assisted delivery workflow. New in v3.1.0: an installer (fast-api:install-ai), a packaged fast-api-crud skill, a Claude Code subagent, managed instruction blocks for CLAUDE.md/AGENTS.md/.cursor/rules/Copilot, and MCP server registration. This turns "should we adopt a generator?" into "should we standardize a machine-readable, agent-consumable convention for resource scaffolding?" That is a workflow decision with its own governance weight (committed agent configs, local MCP processes, who owns those files), not a free add-on.
• Onboarding and time-to-first-value. A packaged reference set derived from source, plus build-resource/debug-endpoint prompts and introspection tools (list_controllers, describe_controller, list_routes, model_info, query_reference), lowers the ramp for a mid-level engineer or a new hire. The roadmap case is unchanged — several "expose an existing table over an API" milestones — but the estimated cost per milestone drops again, and the knowledge now lives in the repo rather than in one engineer's head.
• Engineering capacity allocation. Still the PM-level question: senior engineers on uniform, low-differentiation endpoints, or on the two or three features that drive retention? The AI layer strengthens the "convert hours into a repeatable pattern" argument, but it also adds a new ownerless surface (agent configs, MCP registration) that someone must maintain.
• API standardization decisions. The generator still encodes opinions — naming conventions, validation placement, pagination shape, HTTP status usage, error envelope. The new references/*.md set makes those opinions explicit and testable (a test asserts every public helper, responder, date scope, Builder macro, config key and controller property is documented). Documented, drift-tested conventions are a better input to a consistency decision than implicit ones.
• Prototype/POC funding. Unchanged and still the strongest fit: a time-boxed spike to prove a data model or integration surface. The AI scaffolding path makes the spike faster, which makes funding it cheaper to justify.
• Dependency and tooling policy. Now a two-part review: (a) the runtime/composer dependency, and (b) a repo-mutating installer that writes .mcp.json, .cursor/mcp.json, .vscode/mcp.json, CLAUDE.md/AGENTS.md/Copilot instruction files, plus a vendor:publish --tag=ai path into .claude/. Even if idempotent and marker-bounded, that is a diff your reviewers will see on every install/upgrade and a decision about what AI tooling is allowed in the codebase.
• Local introspection as an independent asset. Anil\FastApiCrud\Mcp\Inspector is described as reusable, read-only introspection of controllers, routes and models. If that holds up on inspection, it has value beyond scaffolding — code review, docs generation, architecture Q&A — which slightly widens the "worth a spike" case independent of the generator itself.
• Explicit non-use cases to document. Unchanged: do not use to justify skipping design for authorization, multi-tenancy, audit logging, or money-handling flows. New corollary: an AI assistant that can call scaffold is not a substitute for a design review, and generated endpoints still need an explicit authorization story. Also do not let generated reference docs become the source of truth for security behavior without a human reading the source.

Honest framing for the decision record: with single-digit stars, zero dependents, and a single maintainer, this remains an unvalidated artifact. v3.1.0 is a substantial, well-scoped feature release — it materially improves the developer experience and shows real craft (docs coverage test, idempotent installer, dependency-free MCP server) — but shipping AI integrations is not the same as shipping a maintenance guarantee. The decision this should support today is still "run a two-day spike," not "standardize on it." The generated output is plain Laravel source you own, which keeps exit cost low; the AI artifacts are plain markdown and JSON you also own and can delete. That is the main reason the spike is worth funding.

When to Consider This Package

Consider it when:

• The stack is Laravel (or an equivalent PHP framework the package explicitly targets) and the team is fluent in its conventions. A generator that emits non-idiomatic code creates review friction that erases the time savings.
• You have a high volume of structurally similar resources (10+ tables needing list/filter/paginate/show/create/update/delete) rather than two bespoke endpoints.
• The timeline is dominated by an MVP, internal tool, or demo deadline where speed beats long-term elegance.
• Your team already uses Claude Code, Cursor, Copilot, or a compatible agent harness, and you are willing to treat committed instruction files and a local MCP server as reviewed project infrastructure. If assistants are already in the loop, the marginal governance cost of this package's AI layer is low and the leverage is real.
• You want machine-readable project introspection — routes, controllers, models, config — surfaced to tooling, for onboarding, docs, or review assistance. The MCP server is dependency-free over stdio, which is the least invasive shape for this.
• You can review the generated code in a pull request before merge. Hard gate, unchanged; now it applies twice — to generated endpoints and to the installer's writes into your repo configs.
• MIT licensing is acceptable to legal and there is no procurement requirement for a support contract or SLA.
• You are willing to vendor or fork if upstream goes quiet, and someone is designated to own that fork.

Look elsewhere — or build in-house — when:

• The domain is authorization-heavy, multi-tenant, audited, or regulated. Generated CRUD tends to be permissive by default (mass assignment, coarse middleware), and those gaps are expensive to retrofit.
• Your architecture is DDD/modular/CQRS/event-sourced, where a generic CRUD layer conflicts with boundaries rather than accelerating them.
• The org requires long-horizon maintenance guarantees: SBOM, CVE response, upgrade support across Laravel majors. Single maintainer, no downstream cohort to surface breakage before you do.
• The org restricts or has not yet approved AI coding assistants, or has policy against committing agent instruction files and MCP registrations to shared repositories. The install-ai / vendor:publish --tag=ai path is opt-in, so this is a scope decision rather than a blocker — but if any AI tooling in the repo is a non-starter, the headline feature of this release is unavailable to you and you are evaluating v3.0.x with extra steps.
• You cannot tolerate an installer that mutates checked-in config. The marker-block/idempotent design is the right approach, but install-time edits to .vscode/, .cursor/, .github/ and CLAUDE.md/AGENTS.md are still edits; if the answer is "no tool writes into our repo config," skip the AI layer entirely and use only the generator.
• You already have an in-house generator, a Nova/Filament-style admin layer, or an OpenAPI-first workflow this would duplicate or contradict — the new AI layer increases the overlap surface rather than reducing it.
• Endpoints sit on a critical revenue path with five-plus years of expected life, or you need non-Laravel backends, GraphQL, or client SDK generation.

Gate criteria for the spike itself: confirm package support for your Laravel/PHP version; read the source for query construction and mass-assignment handling; verify generated output passes static analysis and your existing test suite. Add for v3.1.0: diff-audit the installer — run fast-api:install-ai on a throwaway branch and confirm exactly which files change and that re-running is a no-op; verify the MCP tool surface, specifically whether scaffold writes to disk or merely emits code, and confirm the server binds nothing beyond stdio; confirm the reference docs match the behavior you actually observe (the coverage test is a good signal, not a proof); and check release history and CI for signs of an actively maintained project. Also sanity-check release metadata — a last-release date in the future remains a signal that versioning/publishing isn't yet disciplined. v3.1.0 is a sensible additive minor bump, which is a small point in the project's favor.

How to Pitch It (Stakeholders)

For executives (one paragraph): We are evaluating an MIT-licensed Laravel package that generates standard API CRUD endpoints from a data model, and its newest release adds integrations with AI coding assistants. The business case is unchanged and simple: for the uniform "expose this table over an API" class of work, it converts days of repetitive engineering into hours, and the AI integration means the convention is encoded in the repository rather than in one engineer's memory — so new team members and assistants produce consistent code from day one. Cost is zero in licensing terms and the risk is bounded: the tool emits ordinary source code we own, and the AI pieces are plain markdown and JSON files we can delete. There is no vendor lock-in and no third-party runtime dependency. The caveats are maturity and governance — single maintainer, negligible adoption, and a new installer that writes agent configuration into our repo, which we would review like any other infrastructure change. I am recommending a two-day, time-boxed spike against one real resource with a go/no-go review, not adoption on faith.

For engineering leads: treat this as a scaffolding tool evaluated in a branch, never as a production runtime dependency on day one. Success criteria for the spike: generated code is idiomatic and passes linters, static analysis, and the test suite; authorization and validation are explicit rather than assumed; the generator handles our Laravel version and upgrade path; and the diff is something a mid-level engineer can read and safely modify afterwards. For the new AI layer specifically: the install must be a clean, reviewable, idempotent diff; .mcp.json / .cursor/mcp.json / .vscode/mcp.json / CLAUDE.md / AGENTS.md changes must be acceptable to whoever owns repo policy; the MCP server must be read-only in practice except for an intentional generation path; the reference docs must match observed behavior; and nothing about the assistant flow removes the human authorization review. If it clears that bar, we vendor or fork it under the platform team and use it for internal tools and greenfield resource endpoints — not for auth-heavy or money-handling flows, and not as a substitute for design review. If it doesn't, we take the pattern (not the code) and write a small internal generator, which is a few days of work and carries no external dependency.

Ask: approve a two-day spike plus a one-hour review, not a standing dependency. Decision at the review: adopt as an internal forked tool (including whether the AI/MCP layer is enabled by default for the team), replicate the pattern in-house, or drop it.