import type { UserRole } from '@/types/db'

/**
 * Who counts as INTERNAL — HeavyHaul Agent staff rather than a customer
 * (Task 96, 2026-09-09).
 *
 * Nash: "for pilot testing, we have like a small bar pilot testing bar. That
 * one should be visible only for admin and developer roles. No other users
 * should see it." … "So all the design previews and all the pilot testing
 * bars and buttons should be for admin and developers only."
 *
 * He states the same rule about four separate surfaces (the pilot-testing
 * bar, the dashboard "view as" bar, the company Design-preview bar and the
 * billing Preview-state switcher) plus the `?view=` URL override, so the rule
 * lives in ONE place. A fifth surface added later gates on this function
 * instead of re-deriving the rule.
 *
 * `developer` is not a role in this system today — `UserRole` is
 * broker | dispatcher | driver | admin. Nash says "admin and developer";
 * until a `developer` role is actually added (open question Q1 in
 * docs/TASKS-2026-09-09-MEETING.md), `admin` is the only internal role, so
 * gating on it satisfies the rule exactly. If the role is added, add it to
 * INTERNAL_ROLES here and every surface follows.
 */
const INTERNAL_ROLES: readonly string[] = ['admin']

export function isInternalRole(role: string | null | undefined): boolean {
  return !!role && INTERNAL_ROLES.includes(role)
}

/** Convenience for the session user shape used across server components. */
export function isInternalUser(user: { role: UserRole } | null | undefined): boolean {
  return isInternalRole(user?.role)
}