Forgot and reset password
Password recovery request, secure reset link and password replacement flow.
/forgot-passwordFuture Spec 17 →Current-state summary
Password recovery is part of the defined authentication experience, but the request, email delivery, reset landing page and post-reset session behavior have not been exercised against the live product. The current profile therefore records the required surface and explicit verification gaps rather than presenting the flow as complete.
Interface inventory
Anatomy and verified behavior
Verification states separate observed behavior from requirements or assumptions.
| Element | Current behavior | Verification |
|---|---|---|
| Recovery email field | Accepts the email to which recovery instructions may be sent. | Required behavior; live field unverified |
| Send instructions action | Requests Supabase password recovery and returns a neutral confirmation. | Required behavior; end-to-end delivery unverified |
| Neutral confirmation | Should state that instructions were sent if an account exists. | Approved requirement; current copy unverified |
| Reset-password form | Expected to accept and confirm a new password after a valid recovery link is opened. | Required behavior; live form unverified |
| Return to sign in | Expected to provide a clear route back to authentication. | Required behavior; live link unverified |
User journeys
Current flows
Request recovery
- Open Forgot password
- Enter email
- Submit request
- Receive neutral confirmation
- Supabase sends a recovery message when eligible
Set a new password
- Open a valid expiring link
- Establish recovery context
- Enter and confirm a compliant password
- Save
- Revoke or invalidate affected password sessions
- Return to a clear destination
State model
Current and expected states
Email input is available.
Neutral confirmation should appear regardless of account existence.
New password form should become available.
Should explain that a new request is required without exposing token detail.
Should confirm success and offer sign in or safe continuation.
Product rules
Non-negotiable boundaries
- Recovery responses are non-enumerating.
- Reset links are single-use and expiring.
- Tokens must not be placed in analytics, logs or Activity.
- Successful password changes produce a security event and appropriate notification.
- Password policy must be shown before final failure where possible.
Known current limitations · 4 mapped
What is missing, broken or unverified
Future Spec 17 owns closure →- No live end-to-end recovery test has been recorded.
- Email sender, template, domain and delivery status are unverified.
- Expired-link and reused-link behavior are unverified.
- Post-reset session revocation is unverified.
Future alignment
Required evolution
- 01Implement and test recovery per environment.
- 02Connect recovery delivery to the canonical notification and security event model.
- 03Add safe expired-link recovery and resend behavior.
- 04Document password policy and session revocation in Spec 17.
Current baseline
Acceptance record
- The current profile does not claim recovery is working without an end-to-end test.
- The intended neutral-response rule is recorded.
- Token, expiry and session-security gaps are visible.
Reverse-spec completeness
Documentation coverage
The interface is still changing, so visual evidence and repository tracing remain intentionally incomplete.
Purpose and user outcome
DocumentedRoles and access
DocumentedRoutes and entry points
DocumentedPage and component anatomy
DocumentedFields and displayed data
DocumentedPrimary actions
DocumentedForms and validation
DocumentedStates and transitions
DocumentedEmpty, loading and error states
DocumentedResponsive behavior
PartialAccessibility behavior
PartialActivity and audit events
PartialData sources and persistence
DocumentedNotifications and automation
PartialKnown defects and limitations
DocumentedReusable component dependencies
DocumentedFuture-spec conflicts
PartialVisual and repository evidence
DeferredAcceptance of current baseline
Documented