Internal Admin Dashboard template for Lovable

The build prompt

# Context
Build an internal admin dashboard showing what is happening in the product now, for an operator on shift. Every number carries its time window.

## Core Features (Priority Order)
1. Admin-only access: the page calls has_role with 'admin' before rendering any data
2. Four tiles from events, window stated in each: events, errors, warnings and distinct users in the last 24 hours
3. Chart from event_counts_by_day with a 7, 30 or 90 day picker, default 7
4. Recent events from events, newest first, 25 per page; a row opens its payload in a side sheet
5. Separate screens for "no events yet" and "query failed"

## Visual Style & Design
- Data-driven and analytical: dense, right-aligned tabular numbers
- Dashboard layout: four tiles, chart, then the table scrolling in its own container
- IBM Plex Sans for headings and body text, IBM Plex Mono for ids and payloads
- Colours: background #0b0f14, panels #131a22, text #e5e7eb, accent #38bdf8; severity info #94a3b8, warn #f59e0b, error #ef4444
- shadcn/ui Card for tiles, Table for events, Tabs for range, Badge for severity, Sheet for the payload
- Save these style keywords to the project knowledge.

## Signed In and Signed Out
Signed-out visitors go to sign-in. A signed-in user without the admin role sees "You do not have access to this page" and no events query runs.

## States
- Empty: "No events in the last 24 hours" in each tile and on the chart
- Loading: Skeletons sized to the final content
- Error: a failed query shows a dash in the tile, never 0, with "Could not load" and a retry button

## Data & Access
- Tables user_roles and events, the app_role type, has_role, event_counts_by_day and every row-level security policy already exist in the connected Supabase project from schema.sql. Never weaken, drop or bypass them or create tables; if something is missing, stop and ask me.
- Reads run as the signed-in user, so the policies decide what each user sees. event_counts_by_day never becomes security definer.
- Events are append-only. user_roles has no insert policy, so no screen grants roles; I grant admin in the SQL editor.

## Done When
- Signed out, /admin redirects to sign-in
- Signed in with no admin row in user_roles, /admin shows the no-access screen and an events query from that session returns only that account's rows
- A browser attempt to insert an admin row into user_roles for the current user is rejected
- Signed in as admin, the 7-day chart totals match event_counts_by_day for 7 days and the table shows other users' events
- A forced query failure shows the dash and retry in place of 0

## Build Order
Sign-in, the route guard and has_role before any query, one tile end to end, the other tiles and table, the chart last.

## Safe-Guard Instructions
- No policy that lets non-admins read all events, including for testing
- No service role key in client code
- Keep the window label on every number

## Before Building
Ask me any questions you need in order to fully understand what I want from this feature and how I envision it. Save my answers to the project knowledge so later prompts build on them.

Roles, events and policies

-- Internal dashboard schema for Lovable + Supabase
-- Reviewed row-level security. Read the comments before running this.
--
-- The point of this file: role checks live in the database, not only in the UI. A generated
-- dashboard that hides a menu item is not access control.

create type public.app_role as enum ('admin', 'member');

create table public.user_roles (
  user_id uuid not null references auth.users (id) on delete cascade,
  role public.app_role not null default 'member',
  created_at timestamptz not null default now(),

Policy verification queries

-- Verification queries. Run these as an ordinary member first, then as an admin.
-- The member results are the ones that prove the policies work.

-- As a MEMBER (no admin role):

-- 1. Should return only your own events, never the whole table.
select id, name, user_id from public.events order by created_at desc limit 20;

-- 2. Should return only your own role row.
select * from public.user_roles;

-- 3. Should FAIL. There is no insert policy on user_roles, so nobody self-promotes.