Strictly Laravel Laravel Package

Technical Evaluation

The package is Laravel/PHP developer tooling focused on converting starter-kit-generated applications according to the auth features an app retained. It operates through Artisan commands (strictly:install), publishes config/strictly.php, and exposes CI checks (ci:check:install, ci:check:generate). As a TPM, this is best treated as build-time/CI and developer-workflow infrastructure rather than a production runtime dependency.

Architecture fit: Good fit for Laravel teams using starter kits with variable auth feature sets. The v0.3.0 fix addresses a real gap: partial-feature apps previously risked half-converted files and stale vendor-route declarations. The CI checks are valuable guardrails because they make incomplete conversion and invalid config/strictly.php declarations visible before merge.

Integration feasibility: Feasible as a dev dependency with a standard Artisan install step and CI validation. The migration path is low-effort for full-featured apps (“need nothing”) but requires explicit action for apps that kept only some auth features. Existing partial-feature apps must either prune config/strictly.php declarations or delete an unedited config and rerun strictly:install.

Technical risk: Low for full-featured apps and new apps. Medium for existing partial-feature apps because v0.3.0 changes install behavior but intentionally does not rewrite the published config. That creates a clean-up requirement and a possible “looks installed but CI fails” state until config declarations are reconciled. Risk increases where app auth files have been customized after starter-kit generation.

Key questions:

• Which Laravel, PHP, and starter-kit versions are supported?
• How does the package detect retained auth features versus customized or removed files?
• Is strictly:install idempotent and safe to rerun after app customizations?
• What is the rollback story if conversion modifies files unexpectedly?
• Are the CI checks intended as required merge gates, and what exit codes/output should teams expect?
• Does deleting and republishing config/strictly.php lose any intentional project-specific configuration beyond feature declarations?

Integration Approach

Stack fit: Strong for Laravel teams already using Artisan, Composer, and CI. The package should be introduced as a development/CI tool, not as a production service dependency. It fits naturally into a starter-kit bootstrap workflow and PR validation pipeline.

Migration path: For v0.3.0:

1. Pin the new version in a branch.
2. For full-featured apps, validate no action is needed by running the CI checks.
3. For partial-feature apps, inspect config/strictly.php. If unedited, delete it and rerun strictly:install; if edited, remove declarations for auth features the app does not have.
4. Run ci:check:install and ci:check:generate.
5. Review generated/converted file diffs before merging.

Compatibility: Confirm the package’s supported Laravel/PHP matrix against the team’s current starter-kit version. The release note implies awareness of individual auth features: email verification, registration, two-factor authentication, passkeys, and password confirmation. Compatibility testing should cover each feature combination the organization actually uses, not only full-featured and minimal apps.

Sequencing: Introduce or upgrade the package immediately after starter-kit generation and before significant app-specific auth customization. In existing apps, run the upgrade in a dedicated branch, reconcile config/strictly.php, run the CI checks, execute the app test suite, and only then make the checks required in CI. Document the config-cleanup requirement in the upgrade notes.

Operational Impact

Maintenance: Low ongoing runtime maintenance because this appears to be build-time tooling. Maintenance effort is concentrated in starter-kit upgrades, auth feature changes, and keeping CI checks aligned with team workflows. The published config file becomes an operational artifact that must be kept consistent with actual auth features.

Support: Support burden is likely moderate during the v0.3.0 rollout for teams with partial auth features. Provide a short runbook covering the two remediation paths: delete and regenerate unedited config, or manually prune edited config. Developers need clear guidance that CI failures like <file> (not converted) and config/strictly.php declares what doesn't exist are actionable and expected in partial-feature apps.

Scaling: Scales well across many Laravel repositories because it is command- and CI-driven. Standardize the version, install sequence, and required CI checks in templates or repository bootstrap docs. Avoid per-repo snowflake config unless a team has intentionally customized auth behavior.

Failure modes: Primary failure modes are half-converted files in partial-feature apps, stale config/strictly.php declarations, false confidence when CI checks are not enforced, and unexpected diffs in customized auth files. The new CI checks reduce silent failure risk, but only if wired into required pipelines. Full-featured apps are largely insulated; partial-feature apps carry the migration risk.

Ramp-up: Low for developers familiar with Laravel Artisan and CI. TPM/engineering enablement should focus on the auth feature matrix, the v0.3.0 config-cleanup requirement, and interpreting CI check output. A brief upgrade note plus one example partial-feature migration should be sufficient for most teams.