Let me look at the current login form and admin portal to understand what needs updating.

Now let me look at the admin portal to understand what to modernize.

Now I understand the full structure. Let me rewrite the LoginForm to add client signup and an explanation of the portal's purpose, using a modern split layout. Staff keeps login-only.

Now let me modernize the admin portal. First the sidebar — smoother active states, gradient accents, and animations. Let me check the admin layout too.

Now let me modernize the admin sidebar with grouped navigation, smooth active indicators, and a sticky top bar. I'll update the nav structure and styling.

Let me clean up the leftover unused isActive variable in that map:

Now let me modernize the admin dashboard page with smoother cards, trend indicators, and better visual hierarchy. Let me update the metrics and add hover transitions plus a top welcome bar.

Now update the header and metric card rendering for a smoother, more modern look:

Now let me improve the table rows with hover states and the quick action cards. Let me update the table body rows and the recent claims rows:

Now let me improve the quick action cards with smoother hover animation:

Now let me verify everything renders correctly in the browser — first the client portal signup, then the modernized admin.

Tested client signup

The client portal now has a beautiful split layout with the portal explanation on the left and a Sign In / Create Account toggle on the right. Let me verify the modernized admin dashboard.

Checked admin dashboard

The admin portal looks much more modern — grouped sidebar nav (Overview / Pipeline / Account) with the active indicator bar, a personalized welcome header, metric cards with trend indicators, and smooth hover states. Everything renders correctly.

I made two improvements. First, the Client Portal login page now uses a modern split layout: the left panel explains the portal's purpose ("Your claim, fully in view") with four benefit callouts (real-time tracking, status updates, settlement offers, messaging), and the right side has a Sign In / Create Account toggle where signup collects name, phone, email, and password. The Staff Portal shares the same polished layout (login-only, with its own operations-focused explanation). Second, I modernized the admin portal with grouped/labeled sidebar navigation, an animated active-state indicator and icon hover scaling, a personalized welcome header, metric cards with trend deltas and lift-on-hover, and smoother table-row and quick-action interactions.

Let me examine the current staff login and login form to understand the structure.

Now let me look at the admin portal structure to understand where account creation should live and how the staff role flows through.

This is a mock/demo auth flow with no backend. To pass the logged-in staff role from the login page to the admin portal across navigation, I'll use a small client session helper backed by localStorage (ephemeral session state, not data persistence). Let me create that shared module and the two staff accounts.

Now let me update the login form to validate staff against the two accounts, set a session, and display both demo logins. I'll update the staff config, the submit handler, and the demo credentials display.

Now update the submit handler to use staff account validation for the staff variant:

Now update the demo credentials display section to show both staff accounts when on the staff variant. Let me find and replace the demo block:

Now let me update the admin sidebar to read the session (so it shows the logged-in staff's name/role) and add a "Team" nav item visible only to the master admin. Also clear the session on logout.

Now add the Team Management nav item to the Account group (master-only) and read the session. Let me update the navGroups and the component body:

Now filter the master-only nav item and use the session in the user section. Let me update the items map to skip masterOnly items for non-masters:

Now update the user section to reflect the logged-in staff member with a role badge:

Now let me create the Team Management page where the master admin can create new staff accounts. This page should be master-only (redirect non-masters).

Now let me verify the dialog and select UI components exist:

Those components aren't present. Let me check what's available.

dialog.tsx and select.tsx both exist (the Glob tool excludes them by default but they're present). Good. Now let me verify everything compiles and test in the browser.

TypeScript narrows the union and the badge access fails since the new item only has masterOnly. Let me guard the badge access:

Clean compile. Now let me verify in the browser — log in as master admin and confirm the Team Management page and account creation work.

Master login works. Now let me check the Team Management nav item appears and the page works:

Checked team page

The Team Management page works beautifully — master sees the nav item, the "Master" badge in the user section, and the team list with role badges. Now let me verify the regular admin does NOT see Team Management and gets redirected away. Let me log out and log in as regular admin.

The regular admin is redirected from /admin/team back to /admin. Let me confirm the Team Management nav item is hidden for the regular admin via snapshot:

The regular admin (Alex Rivera, Case Manager) has no "Team Management" item and no "Master" badge, confirming role-based access works end to end.

I added two staff roles with distinct demo logins on the staff portal: Master Admin (master@marketverify.com / master2024) and Regular Admin (agent@marketverify.com / staff2024), each with its own "Use this login" button. A new lib/staff-auth.ts module validates credentials and stores the active session, which the sidebar reads to display the logged-in member's name, title, and a "Master" badge. Only the Master Admin sees the new Team Management page (/admin/team), where they can create new staff accounts via a dialog with a role selector — regular admins don't see the nav item and are redirected away if they navigate there directly. Everything compiles cleanly and was verified in the browser for both roles.