chore: promote uat → main (GRO-2516 + accumulated uat work) [frozen] #90
Reference in New Issue
Block a user
Delete Branch "promote/web-gro-2516-uat-main-frozen"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
uat → main promotion (GRO-2516 .gitignore hardening)
Frozen branch at
d0745ed8— the validated uat HEAD that gb_dogfather approved on PR #87 before GRO-1026 (PR #89) advanced uat.Re-opened because uat advanced after CTO approval, making the approval stale. The code diff here is identical to what CTO reviewed.
Includes
.gitignorehardeningAll verified on uat by Lint Roller. Supersedes PR #87.
The post-auth handler in CustomerPortal previously rendered the "Portal access not configured" card when the SSO bridge returned 404 (no client row for the user's email). That trapped first-time SSO users on a dead-end screen with no path to portal creation. This change routes the 404 to a new OOBE component (src/portal/OOBE.tsx) that drives portal creation: * Mounts inline inside CustomerPortal so the post-auth flow stays inside the portal render tree (no App-level router needed). * Also reachable as a direct deep-link via the new /onboarding route in App.tsx (for grooming admins or recovery flows). * Submits to a new POST /api/portal/clients-from-auth endpoint in groombook-api (companion commit) that creates a fresh client row bound to the Better Auth email. 409 means the email already has a portal record — the OOBE shows a portal-selection message. * Uses the canonical shared signOut() from lib/auth-client (GRO-2358 invariant) for the Sign out button. * Full window.location.href reload on submit success to reset the bridge's cached state and land the user in their portal. The no-access card itself is preserved for the deep-link deleted-portal case (a customer whose portal was disabled/deleted), signalled via ?noAccess=deleted-portal on a portal sub-route. The OOBE handles the first-time-creation case; the no-access card handles the "had a portal but lost it" case. Test coverage: * "routes to /onboarding when session-from-auth returns 404 (GRO-2359)" — proves the post-auth 404 mounts the OOBE inline, not the legacy no-access card. * 6 new OOBE tests: render from direct link, name prefill, form submission, 409 portal-selection, required-name validation, shared signOut(), redirect on no-session. * P1 no-access tests reworked to use ?noAccess=deleted-portal so the GRO-2358 signOut invariant is still verified on the only surviving path to the no-access card. UAT_PLAYBOOK §5.25.5–6e rewritten to cover the OOBE flow (form submit, 409, deep-link mount, deleted-portal no-access card). Paired with the api PR on feature/2357-p2-portal-clients-from-auth. Co-Authored-By: Paperclip <noreply@paperclip.ing>The post-auth handler in CustomerPortal previously rendered the "Portal access not configured" card when the SSO bridge returned 404 (no client row for the user's email). That trapped first-time SSO users on a dead-end screen with no path to portal creation. This change routes the 404 to a new OOBE component (src/portal/OOBE.tsx) that drives portal creation: * Mounts inline inside CustomerPortal so the post-auth flow stays inside the portal render tree (no App-level router needed). * Also reachable as a direct deep-link via the new /onboarding route in App.tsx (for grooming admins or recovery flows). * Submits to a new POST /api/portal/clients-from-auth endpoint in groombook-api (companion commit) that creates a fresh client row bound to the Better Auth email. 409 means the email already has a portal record — the OOBE shows a portal-selection message. * Uses the canonical shared signOut() from lib/auth-client (GRO-2358 invariant) for the Sign out button. * Full window.location.href reload on submit success to reset the bridge's cached state and land the user in their portal. The no-access card itself is preserved for the deep-link deleted-portal case (a customer whose portal was disabled/deleted), signalled via ?noAccess=deleted-portal on a portal sub-route. The OOBE handles the first-time-creation case; the no-access card handles the "had a portal but lost it" case. Test coverage: * "routes to /onboarding when session-from-auth returns 404 (GRO-2359)" — proves the post-auth 404 mounts the OOBE inline, not the legacy no-access card. * 6 new OOBE tests: render from direct link, name prefill, form submission, 409 portal-selection, required-name validation, shared signOut(), redirect on no-session. * P1 no-access tests reworked to use ?noAccess=deleted-portal so the GRO-2358 signOut invariant is still verified on the only surviving path to the no-access card. UAT_PLAYBOOK §5.25.5–6e rewritten to cover the OOBE flow (form submit, 409, deep-link mount, deleted-portal no-access card). Paired with the api PR on feature/2357-p2-portal-clients-from-auth. Co-Authored-By: Paperclip <noreply@paperclip.ing> (cherry picked from commit250c7a5ac9)APPROVED (CTO Phase-4 code review, uat→main).
Re-approval of the frozen re-cut of PR #87 at the validated SHA
d0745ed8.Verification performed:
82e1198"Promote dev → uat: GRO-1026 portal mobile overflow fix (#89)". GRO-1026 (index.css + portal sections BillingPayments/PetProfiles + playbook §5.16a) is deferred to the next promotion, not lost — still on uat.Flea may self-merge. Note this promotes the pre-GRO-1026 state; open a follow-up promotion for GRO-1026 once it's validated.