Strictly Laravel Laravel Package

Product Decisions This Supports

• Pruning the starter kit is now a viable product decision. Teams can ship an app that keeps only the auth features they actually want (email verification, registration, 2FA, passkeys, password confirmation) without ending up in a half-converted state. Previously this choice carried a hidden engineering tax; v0.3.0 removes that, so feature-scoping decisions can be made on user value rather than tooling limitations.
• Roadmap sequencing for auth features. Adding or removing an auth capability later (e.g. dropping passkeys, deferring 2FA) is now a supported path rather than a one-way door. This makes it cheap to defer auth surface area to a later release and revisit it — useful for MVP scoping and for staged rollouts to different customer segments.
• Build vs. buy on scaffolding and conversion. The package is doing work (file conversion, route declaration, CI verification) we would otherwise hand-roll or re-do per project. This release strengthens the buy case by widening the supported input space to partially-trimmed apps.
• CI as a product-quality gate. ci:check:install and ci:check:generate turn "did someone hand-edit a converted file or leave a stale route declaration?" into a build failure instead of a runtime surprise. That's a decision to enforce consistency mechanically rather than through review checklists.
• Upgrade cost is now quantifiable. The one required manual action — cleaning config/strictly.php of declarations for features the app doesn't have — is a bounded, one-time task with an escape hatch (delete the file, re-run strictly:install, get a correctly scoped config). That's a plannable line item, not an open-ended migration.

When to Consider This Package

Adopt when:

• The app is generated from a Laravel starter kit and you have removed some but not all of the kit's auth features — this is precisely the case v0.3.0 fixes, and the case most production apps land in.
• You want converted, app-owned files plus a declarative config/strictly.php that stays honest about what exists in the codebase.
• You have (or want) CI that fails on conversion drift; the two ci:check:* commands give you that cheaply.
• Full-featured apps: nothing changes, so there's no cost to staying on the package — but also no new benefit from this release specifically.

Look elsewhere or wait when:

• The app doesn't originate from the supported starter kit, or auth has been replaced with a fully custom implementation — the conversion model assumes kit lineage.
• The team isn't willing to treat generated files as app-owned and CI-verified; the value proposition collapses without that discipline.
• You're mid-flight on a release: the required config/strictly.php cleanup after upgrading to v0.3.0 is small but should not be bundled into a code freeze.

How to Pitch It (Stakeholders)

To executives: v0.3.0 closes a gap that made trimming the starter kit's login features risky. Teams that turned off features like two-factor or passkeys used to get a half-converted app and a config file lying about what existed. That's now handled, and CI catches it if it ever regresses — which means we can scope auth to what customers need without paying a hidden maintenance tax, and we can add features later without a rework.

To engineering: Upgrade is low-risk for full-featured apps — no action needed. For apps that kept only some kit auth features, run the upgrade, then reconcile config/strictly.php: delete declarations for features you don't have, or if the file was never hand-edited, delete it and re-run strictly:install to get one published for your actual feature set. Verify with ci:check:install (fails with <file> (not converted) for anything still pending) and ci:check:generate (fails with config/strictly.php declares what doesn't exist). Wire both into the pipeline so the half-converted state can't come back.