Next.js corporate portal (apps/web/companies, port 3002). Currently an auth-only shell: a splash page plus login/signup/forgot-password, all reusing the shared @buyootna/ui forms. No company dashboard exists yet.
Portal is correctly scoped to an auth-only shell (known gap)
P1
Verify that apps/web/companies currently only exposes the splash page and the three auth routes, so that this is tracked as the expected current scope rather than repeatedly filing 'missing dashboard' bugs against a portal that hasn't been built yet.
AC-01/ shows the 'بيوتنا للشركات' splash with working links to login/signup.
AC-02No dashboard, property-management, or service-management routes exist or are linked from the splash — any such link would be a regression against current scope, not a missing feature to test.
AC-03This story should be replaced with real dashboard test coverage once a company dashboard ships.
Test Scenarios
TC-01Crawl all links from the splash page and confirm none 404 and none point to unbuilt dashboard routes.
TC-02Attempt to guess/deep-link a plausible dashboard URL (e.g. /dashboard, /properties) and confirm it correctly 404s rather than partially rendering a broken page.
Signup correctly defaults to and submits the COMPANY role
P0
Verify that SignupForm on this portal is configured with defaultRole="COMPANY" and actually submits COMPANY as the role to POST auth/register, so that a company signing up through this portal doesn't accidentally get provisioned as an individual account.
Shared auth forms validate consistently with the mobile app's rules
P1
Verify that LoginForm/SignupForm/ForgotPasswordForm from @buyootna/ui only enforce plain non-empty/match checks (no zod, no length/regex rules) here, unlike mobile's zod schemas, so that this known validation gap between web and mobile is documented rather than assumed to match.
AC-01Signup accepts a password as short as 1 character and any phone format, since no zod/regex validation runs on web.
AC-02Login accepts any non-empty identifier + password combination for client-side validation (server-side auth still enforces actual credentials).
AC-03Password/confirm-password mismatch is still caught client-side even without zod.
Test Scenarios
TC-01Attempt signup with a 1-character password and a non-Kuwaiti phone number format — confirm it's accepted client-side (contrast with mobile-auth-validation, where the same input is rejected).
TC-02Submit signup with password and confirm-password mismatched — confirm client-side rejection before any network call.
TC-03File a cross-platform consistency ticket if product wants web to match mobile's stricter zod rules — this story exists to make the current gap explicit, not to silently 'pass' it as fine.
Forgot-password flow reaches a clear success state
P1
Verify that ForgotPasswordForm posts to auth/forgot-password and shows a clear 'check your email' success state, so that a company admin who forgets their password isn't left wondering whether the request went through.
AC-01Submitting a registered email shows the success state.
AC-02Submitting an unregistered email either shows the same success state (to avoid account enumeration) or a clear, non-revealing error — confirm which behavior is intended and that it's consistent.
AC-03The success state doesn't allow indefinite resubmission spam without at least a basic client-side debounce/disable-on-submit.
Test Scenarios
TC-01Submit with a known-registered email and confirm the success message appears and (separately, via email/inbox) that a reset email/OTP actually arrives.
TC-02Submit with an obviously fake email and compare the response/UI to the registered-email case for enumeration risk.
TC-03Rapidly click submit multiple times and confirm no duplicate emails/OTPs are triggered by the UI (button disables during submission).