// Central status-language mapping. Every status indicator in the app resolves
// through here so the dot color + label vocabulary stays consistent:
//   ok      = online / granted / success      -> --ok (green)
//   warn    = pending (gets the consent pulse) -> --warn (amber)
//   bad     = denied / offline / error         -> --bad (red)
//   neutral = not_required / unknown           -> --neutral (slate)

export type StatusTone = "ok" | "warn" | "bad" | "neutral";

/** Badge tones available to features (StatusTone plus the brand `accent`). */
export type BadgeTone = StatusTone | "accent";

/**
 * Map a user role to a badge tone. `admin` is the elevated, distinct tone and
 * gets the brand `accent` so it reads as "privileged" at a glance; `operator`
 * is a normal active role (`ok`); `viewer` is the least-privileged, muted
 * (`neutral`). An unknown role falls back to `neutral`.
 */
export function roleTone(role: string): BadgeTone {
  switch (role) {
    case "admin":
      return "accent";
    case "operator":
      return "ok";
    case "viewer":
    default:
      return "neutral";
  }
}

/** Title-case label for a role; passes unknown roles through verbatim. */
export function roleLabel(role: string): string {
  switch (role) {
    case "admin":
      return "Admin";
    case "operator":
      return "Operator";
    case "viewer":
      return "Viewer";
    default:
      return role;
  }
}

/**
 * Map a user's enabled flag to a status tone. An enabled account is healthy
 * (`ok`); a disabled one is a deliberate block and reads as `bad` so it stands
 * out in the table (a disabled user is an exception worth seeing).
 */
export function userStatusTone(enabled: boolean): StatusTone {
  return enabled ? "ok" : "bad";
}

/** Human label for a user's enabled flag. */
export function userStatusLabel(enabled: boolean): string {
  return enabled ? "Active" : "Disabled";
}

/** Map a machine `status` string to a tone. */
export function machineTone(status: string): StatusTone {
  return status === "online" ? "ok" : "bad";
}

/** Map an attended-consent state to a tone. `pending` pulses. */
export function consentTone(state: string): StatusTone {
  switch (state) {
    case "granted":
      return "ok";
    case "pending":
      return "warn";
    case "denied":
      return "bad";
    case "not_required":
    default:
      return "neutral";
  }
}

/**
 * Human label for an attended-consent state. Kept here next to `consentTone`
 * so the color and the words for a given state never drift apart. `pending` is
 * phrased as the active wait it represents (a tech is blocked on it).
 */
export function consentLabel(state: string): string {
  switch (state) {
    case "granted":
      return "Granted";
    case "pending":
      return "Awaiting consent";
    case "denied":
      return "Denied";
    case "not_required":
      return "Not required";
    default:
      return state;
  }
}

/**
 * Map a support-code lifecycle status to a tone. `pending` is the live,
 * waiting-to-be-redeemed state and gets the same `warn` pulse the
 * awaiting-consent state uses — it reads as "active, watch this". A redeemed
 * (`connected`) code is a positive terminal-for-the-tech outcome -> `ok`.
 * `completed`/`cancelled` are spent and read as muted `neutral`.
 */
export function codeTone(status: string): StatusTone {
  switch (status) {
    case "pending":
      return "warn";
    case "connected":
      return "ok";
    case "completed":
    case "cancelled":
    default:
      return "neutral";
  }
}

/**
 * Human label for a support-code status. Next to `codeTone` so wording and
 * color never drift. `pending` is phrased as the active wait (the tech is
 * watching for the end user to redeem it).
 */
export function codeLabel(status: string): string {
  switch (status) {
    case "pending":
      return "Awaiting redeem";
    case "connected":
      return "Redeemed";
    case "completed":
      return "Completed";
    case "cancelled":
      return "Cancelled";
    default:
      return status;
  }
}
