#Sign-in and account access

Module id: MOD-AUTH
Doc profile: system

Platform auth for TradeForce: email/password registration, verification, sign-in, and password reset, plus the post-auth redirects that send each role into onboarding or their home surface. Target stack is Supabase Auth with a profiles row; Bubble native LogIn / SignUp / SendPasswordResetEmail / ResetPassword are the evidence for behavior, not the runtime provider.

#Purpose

Contractors and companies must be able to create an account, prove email ownership, sign in, and recover a forgotten password so every later authenticated journey can run. Admins sign in on the same surface and go straight to the admin home. This module owns the public auth UI on / and /reset-password, the session client, profile defaults used for routing, and the redirect matrix. It does not own onboarding wizard content, workspace chrome, or shift/marketplace pages.

#Scope boundaries

#Actors

#Auth composition

Auth is one public surface with mode switching, not four separate apps. The index page is a split layout (branding + form column). Mode is the nav query param from NavigationIndex. Casing matters: the source writes and compares the option display — SignIn | SignUp | Reset | Verify — not the lowercase db_value; every index visibility condition is GetParamFromUrl("nav") = OptionValue(navigationindex, …):display, and MOD-ONBOARDING follows the same convention with nav=Contractor|Company. Mode names are written lowercase below as internal mode ids; the target must parse nav case-insensitively so live links from Bubble emails and bookmarks keep working, whichever casing it emits. Primary submit shares one button; its workflow branches on nav. After credentials succeed, redirects read profiles.active, profiles.onboarding_complete, and profiles.role.

Bubble evidence for composition and redirects is listed under Traceability / IR evidence.

#Primary journeys

Journeys are reconstructed from index and reset_pw workflows (triggers → auth actions → ChangePage / SendEmail). Where activation continues on the onboarding page, that page body is out of this module’s implement scope but the activation contract is named here because signup email deep-links into it.

#J1 — Sign in and route by profile

1. Visitor opens / (default or nav=signin) and sees Sign In with Email, Password, Forgot Password?, and Sign Up link.
2. Visitor submits valid email and password; the app calls sign-in and loads the profile used for routing.
3. If the profile is inactive, the app stays on / with nav=verify; if active and onboarding incomplete, it goes to onboarding; otherwise it routes by role to company shifts, contractor shifts, or admin.
4. Invalid credentials show an inline/page error and do not navigate.

#J2 — Sign up, verify email, and activate

1. Visitor opens /?nav=signup, chooses Contractor or Company (Admin excluded), enters email and a password of at least 8 characters, and submits.
2. The app creates the auth user, stores role on the profile with approved false and active false, sends the verification email, and shows the verify panel (nav=verify, signup tab copy).
3. Visitor follows the activation link from the email (onboarding URL with active=yes and role in nav when preserving Bubble semantics, or the ADR-chosen Supabase confirm path when replacing).
4. Password shorter than 8 characters or signup failure blocks success and keeps the user on the form with a clear error.

#J3 — Reset password from email link

1. Visitor opens /?nav=reset, enters email, and chooses Send reset link; the app requests a reset email and shows the reset-specific verify panel.
2. Visitor opens /reset-password from the email with a recovery session and enters New password and Confirm new password.
3. When both fields match, the app updates the password and navigates to onboarding (not back to sign-in).
4. Mismatched passwords or expired recovery show a clear error and do not change the password.

#J4 — Already signed-in visit to the auth index

1. A user who already has a session opens /.
2. PageLoaded rules redirect: non-admin with active and onboarding incomplete → onboarding; admin → admin; contractor with active and onboarding complete → contractor shifts; company with onboarding complete → company shifts (company rule does not require active).

#Navigation contracts

URL values below are internal mode ids; on the wire the source spells them SignIn / SignUp / Reset / Verify (option display) — see Auth composition.

#Vertical slices (decompose)

#Side-effect contracts

#Post-login redirect matrix (after LogIn)

Ordered from the login workflow actions:

1. active false → index with verify nav/tab
2. active true and onboarding incomplete → onboarding
3. role company and onboarding complete → company shifts
4. role contractor and onboarding complete → contractor shifts
5. role admin → admin

#PageLoaded predicates on index (already logged in)

#Style and fidelity

Auth uses the auth_flow shell (section → container → form card). Transcribe visible copy and data-bubble-id on migrated roots (page, form card, primary button, reset card). Shared tokens come from the app-level stylesheet that SHELL-LAYOUT (MOD-SHELL) delivers out of IR styles (ir/slices/styles____part_all.json — 49 styles, 8 color tokens, 1 font token); this cycle's module map has no separate design-system module, so do not defer a token to one. Narrow layout: center the auth column around ≤640px on index; tighten padding around ≤768px on reset.

#Failure modes

#Needs human clarification

#Traceability

#IR evidence

#Module evidence roots

• bTGYf — index page (/pages/bTGbC), auth modes and login/signup/reset/verify UI + workflows
• AAL — reset_pw page (/pages/AAW), new/confirm password + ResetPassword

Supporting segments: ir/slices/bTGbC____root.json, ir/slices/AAW____root.json.

#Path-key ↔ inventory id aliases

Prefer inventory ids in evidence_refs; path keys are locators when chasing the sanitized export.

#Signup activation (chased)

• bTHpx1 SignUp: send_confirm_email false; changes role_option_role ← role dropdown, approve1_boolean ← false; does not set active__boolean.
• bTHqT1 SendEmail: subject “Verify”, sender “TradeForce”, body deep-links onboarding?nav= + current user’s role display + &active=yes.
• bTHqJ1 ChangePage → index with nav = display of navigationindex/verify (i.e. Verify) and tab = display of the signup value — both url_parameters interpolate :display, not db_value.
• Preserve path: onboarding PageLoaded when URL active=yes and user still inactive → ChangeThing active__boolean true (bTHse1). Replace path requires ADR naming the Supabase confirm mechanism instead.

#Privacy & authorization

• Target: RLS on profiles — authenticated users read/update own row only; service role confined to migrations/triggers; SPA uses anon key + user JWT only.
• Bubble privacy roles for wider app pages are out of this module; auth pages are public entry points. No privacy_role* matrix is required for the public auth forms themselves beyond the profiles RLS contract above.

#Option sets used for routing / UI

• navigationindex: db_values signin, signup, reset, verify; displays SignIn, SignUp, Reset, Verify — the URL carries the display (the verify value also carries a tab attribute used for reset vs signup message copy).
• role: contractor, company, admin — signup dropdown excludes admin.