Restore Fortify extension contracts and configuration defaults - #486
Merged
Conversation
Restore Laravel-compatible constructor shapes, protected mutable collaborators, protected override methods, and mutable public event payloads. This makes Fortify's supported subclass seams usable again without reopening worker-global configuration state. Remove the unnecessary container dependency from EnsureLoginIsNotThrottled and resolve the lockout response at the operation boundary. The action now accepts the upstream one-parameter constructor while retaining Hypervel's current-guard and listener-aware behavior.
Remove Hypervel-only constructor dependencies from the ten stateless Fortify controllers that are zero-constructor classes upstream. Resolve response contracts and request-sensitive configuration when each operation runs so worker auto-singletons do not capture application state and application response bindings remain authoritative. Retain the deliberate current-guard architecture and the few upstream-shaped constructors that still own real dependencies. Remove duplicated lowercase-username fallbacks where Fortify's merged package configuration already guarantees the key.
Restore Laravel-compatible protected mutable response, limiter, and two-factor provider properties while preserving Hypervel's private OTP clock. Restore mutable redirect payloads and the descriptive SimpleViewResponse callable contract. Return PasswordResetResponse to status-only construction and resolve the current views setting when producing the response. This avoids retaining configuration on a worker-lived response while preserving JSON, disabled-view, and normal login redirects.
Remove duplicated fallback literals from required Fortify configuration reads and route registration. Top-level package defaults are shallow-merged before use, so the merged repository is the single source of truth while optional and replace-whole settings keep their existing fallbacks. Document the worker-lifetime boundary only when feature options mutate global configuration. Keep no-argument feature identifier reads safe at request time, and retain Fortify's six private typed static configuration slots behind the existing public APIs and exhaustive reset hook.
Make the generated Fortify configuration self-explanatory with concise headings for each public group. New applications now publish Laravel's intended lowercase-username default and leave email verification commented out until the user model supports it. Keep Hypervel's guard, middleware, Passkeys, route-path, limiter, and two-factor options intact. The package's unpublished fallback remains deliberately different for applications that do not own a config file.
Document that feature options mutate process-global configuration only when supplied, while no-argument feature identifiers remain safe request-time reads. Explain published versus internal username defaults, email-verification opt-in, and the reset URL requirement when view routes are disabled. Normalize the Fortify and integrated Passkeys READMEs around public documentation links and the required package order. Record only the developer-visible Laravel differences, including Fortify's typed public alternatives to direct static-property writes.
Add counterfactual coverage for zero-constructor controllers, the exact throttle-action constructor, status-only response construction, both view redirect branches, internal package defaults, protected/public extension seams, and private worker-static state. Extend installer coverage for the published lowercase and email-verification defaults. Prove that disabling Fortify views removes the reset form route while retaining both password-reset submission routes.
Mark Fortify complete in the framework lifecycle checklist and record findings fortify-03 through fortify-09 with their architecture, regression coverage, performance budget, retained differences, and rejected complexity. Close the carried Auth, Horizon, and Eloquent revalidation entries using the dependency index's established vocabulary. Remove the obsolete Fortify port todo now that the package and its completion records are current and signed off.
Capture the final evidence, architecture, implementation slices, regression strategy, performance budget, and rejected designs for the Fortify audit. The plan preserves Hypervel's current-guard, OTPHP, Passkeys, rate-limiter, event, and worker-static boundaries while restoring supported Laravel APIs. Record the anti-overengineering constraints and final verification workflow so future maintenance can distinguish deliberate Hypervel adaptations from parity defects without reintroducing duplicate defaults or speculative lifecycle machinery.
Bring in the completed Socialite audit and the latest Support Manager, Object Pool, and Reverb ownership corrections. These changes do not alter Fortify runtime behavior or invalidate any Fortify design assumption. Resolve the shared audit-ledger append conflict by retaining both signed-off work units in chronological order. Preserve both package checklist completions and all dependency-index updates.
Document the guard-selection behavior directly in the published configuration stub. A null value follows the current request guard, while an explicit name pins Fortify's built-in routes to that configured guard. This keeps config/auth.php as the source of truth for guard definitions while making Fortify's optional route-selection override clear where applications configure it.
📝 WalkthroughWalkthroughFortify APIs now use Laravel-shaped construction and extension contracts. Configuration fallbacks and published defaults were aligned. Documentation and audit records were updated. New tests cover API contracts, configuration, installation output, response behavior, and route registration. ChangesFortify audit and implementation
Estimated code review effort: 3 (Moderate) | ~25 minutes Possibly related PRs
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Greptile SummaryRestores Fortify's Laravel-facing construction and extension contracts while retaining Hypervel's coroutine-safe guard and worker-lifetime configuration model.
Confidence Score: 4/5The PR appears safe to merge, with one non-blocking documentation-convention issue in the new feature lifecycle warnings. The changed runtime paths preserve merged configuration, response binding, and coroutine-safe state behavior; only the standardized worker-lifetime warning syntax needs adjustment. Files Needing Attention: src/fortify/src/Features.php
|
| Filename | Overview |
|---|---|
| src/fortify/src/Features.php | Documents process-global option mutation and removes a duplicated feature-list fallback; the new lifecycle warnings need the repository's exact tag-first format. |
| src/fortify/src/Fortify.php | Removes duplicated defaults for guaranteed merged username and email configuration while preserving worker-static configuration ownership. |
| src/fortify/routes/routes.php | Removes duplicated defaults for package-owned route configuration without changing current-guard selection or optional limiter behavior. |
| src/fortify/src/FortifyServiceProvider.php | Uses the merged package configuration as the authoritative route-prefix source. |
| src/fortify/src/Http/Responses/PasswordResetResponse.php | Restores status-only construction and resolves view configuration at response time without retaining request-specific dependencies. |
| src/fortify/src/Http/Controllers/PasswordResetLinkController.php | Restores zero-constructor compatibility and resolves configuration and parameterized responses at the operation boundary. |
| tests/Fortify/FortifyApiTest.php | Adds focused coverage for constructor contracts, property visibility and mutability, override dispatch, response behavior, and private static configuration. |
| src/fortify/stubs/fortify.php | Publishes lowercase usernames and opt-in email verification for new applications with expanded configuration guidance. |
Reviews (1): Last reviewed commit: "docs: explain Fortify's null guard defau..." | Re-trigger Greptile
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
Comment on lines
+143
to
+146
| * Boot-only when options are supplied. Non-empty options mutate the process-global | ||
| * configuration repository and affect every subsequent request in the worker; | ||
| * calling without options performs no mutation and is safe at request time. | ||
| * |
There was a problem hiding this comment.
The new warning starts with Boot-only when options are supplied. instead of the repository's required standalone Boot-only. tag, making the lifecycle restriction less consistently recognizable by humans and tooling. Use the tag-first format here and on passkeys(), followed by the existing explanation of process-global mutation.
Context Used: AGENTS.md (source)
Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!
Collaborator
Author
There was a problem hiding this comment.
Thanks. No change here. These methods are dual-purpose: without options they only return the feature identifier and are safe during request handling; only non-empty options mutate process-global configuration. A standalone Boot-only. would therefore be inaccurate. The conditional wording also matches the repository's existing convention for get-or-configure methods such as Router, ResourceRegistrar, Relation, and the validation rules.
There was a problem hiding this comment.
That's a fair correction — a standalone Boot-only. tag would misrepresent a method that is explicitly safe at request time when called without options. The conditional phrasing is the accurate and appropriate choice here, and matching the existing get-or-configure convention in Router, ResourceRegistrar, Relation, and the validation rules is the right call. Happy to leave this as-is.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@src/fortify/src/Http/Responses/PasswordResetResponse.php`:
- Around line 16-20: Update FortifyServiceProvider registrations for
PasswordResetResponse, FailedPasswordResetLinkRequestResponse,
FailedPasswordResetResponse, and SuccessfulPasswordResetLinkRequestResponse to
use transient bind() bindings instead of singleton bindings, ensuring each
request-specific status is resolved in a fresh response instance.
🪄 Autofix
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: 74630480-7b10-4f68-adf8-88501ad37012
📒 Files selected for processing (48)
docs/plans/2026-07-12-0900-framework-coroutine-state-lifecycle-audit.mddocs/plans/2026-07-12-0915-framework-coroutine-state-lifecycle-audit-ledger.mddocs/plans/2026-08-07-1807-fortify-correctness-current-parity-and-configuration-contracts.mddocs/todo.mdsrc/boost/docs/fortify.mdsrc/fortify/README.mdsrc/fortify/routes/routes.phpsrc/fortify/src/Actions/AttemptToAuthenticate.phpsrc/fortify/src/Actions/ConfirmPassword.phpsrc/fortify/src/Actions/ConfirmTwoFactorAuthentication.phpsrc/fortify/src/Actions/EnableTwoFactorAuthentication.phpsrc/fortify/src/Actions/EnsureLoginIsNotThrottled.phpsrc/fortify/src/Actions/PrepareAuthenticatedSession.phpsrc/fortify/src/Actions/RedirectIfTwoFactorAuthenticatable.phpsrc/fortify/src/Events/PasswordUpdatedViaController.phpsrc/fortify/src/Events/RecoveryCodeReplaced.phpsrc/fortify/src/Events/RecoveryCodesGenerated.phpsrc/fortify/src/Events/TwoFactorAuthenticationEvent.phpsrc/fortify/src/Features.phpsrc/fortify/src/Fortify.phpsrc/fortify/src/FortifyServiceProvider.phpsrc/fortify/src/Http/Controllers/AuthenticatedSessionController.phpsrc/fortify/src/Http/Controllers/ConfirmedPasswordStatusController.phpsrc/fortify/src/Http/Controllers/ConfirmedTwoFactorAuthenticationController.phpsrc/fortify/src/Http/Controllers/EmailVerificationNotificationController.phpsrc/fortify/src/Http/Controllers/EmailVerificationPromptController.phpsrc/fortify/src/Http/Controllers/NewPasswordController.phpsrc/fortify/src/Http/Controllers/PasswordController.phpsrc/fortify/src/Http/Controllers/PasswordResetLinkController.phpsrc/fortify/src/Http/Controllers/ProfileInformationController.phpsrc/fortify/src/Http/Controllers/RecoveryCodeController.phpsrc/fortify/src/Http/Controllers/RegisteredUserController.phpsrc/fortify/src/Http/Controllers/TwoFactorAuthenticationController.phpsrc/fortify/src/Http/Controllers/VerifyEmailController.phpsrc/fortify/src/Http/Responses/FailedPasswordResetLinkRequestResponse.phpsrc/fortify/src/Http/Responses/FailedPasswordResetResponse.phpsrc/fortify/src/Http/Responses/LockoutResponse.phpsrc/fortify/src/Http/Responses/PasswordResetResponse.phpsrc/fortify/src/Http/Responses/RedirectAsIntended.phpsrc/fortify/src/Http/Responses/SimpleViewResponse.phpsrc/fortify/src/Http/Responses/SuccessfulPasswordResetLinkRequestResponse.phpsrc/fortify/src/LoginRateLimiter.phpsrc/fortify/src/TwoFactorAuthenticationProvider.phpsrc/fortify/stubs/fortify.phpsrc/passkeys/README.mdtests/Fortify/Console/InstallCommandTest.phptests/Fortify/FortifyApiTest.phptests/Fortify/FortifyRouteTest.php
💤 Files with no reviewable changes (1)
- docs/todo.md
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
This restores Fortify's expected construction and extension contracts, makes package configuration the single source for guaranteed defaults, and updates the published configuration for new applications.
The changes preserve Hypervel's current-guard model, coroutine-safe guard selection, Passkeys integration, two-factor behavior, dedicated rate limiter, event delivery, and transaction boundaries.
For more details, see: docs/plans/2026-08-07-1807-fortify-correctness-current-parity-and-configuration-contracts.md
What changed
Guard and authentication behavior
fortify.guardstill defaults tonull. In that mode, Fortify follows the current request guard selected byAuth::shouldUse(), then falls back toauth.defaults.guard.An explicit
fortify.guardvalue only selects the guard for Fortify's built-in routes. The guard definition inconfig/auth.phpremains authoritative for the provider, password broker, password-confirmation settings, and authentication separation. Fortify-owned Passkeys routes follow the same selected guard.Compatibility
Laravel-facing constructor, property, response, and override contracts are restored where Hypervel had drifted.
Hypervel-specific behavior remains intentional: current guards are resolved at operation time, static configuration stays typed and resettable for long-lived workers, password brokers follow guard declarations, and integrated Passkeys retain their existing ownership model.
Verification
0.4changes.Summary by CodeRabbit
Configuration
Compatibility
Documentation
Tests